Engineering Culture
리뷰할 수 있는 크기로 변경 나누기, 다음 실험으로 이어지는 회고
기능 추가와 이름 변경, 포맷 수정이 한 번에 섞이면 리뷰어가 실제 동작 변화를 찾기 어렵다. 변경을 나누는 기준은 파일 수보다 설명 가능한 목적이다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.
THE BUILDER’S NOTE
Engineering.
01 / INSIDE THE BUILD만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.
최근 이야기
작은 발견부터 깊이 있는 고민까지.
Backend
트랜잭션의 경계를 정하는 법, 다음 실험으로 이어지는 회고
서로 연결된 두 번의 저장 중 하나만 성공하면 데이터의 의미가 깨질 수 있다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.
AI & Data
전처리에서 생기는 데이터 누수, 다음 실험으로 이어지는 회고
모델에 평가 데이터를 직접 넣지 않았어도 전처리 단계에서 평가 정보가 전달될 수 있다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.
DevOps
생존 확인과 준비 상태를 나누는 헬스 체크, 다음 실험으로 이어지는 회고
프로세스가 떠 있다는 사실과 요청을 처리할 준비가 됐다는 사실은 다르다. 데이터베이스 연결이 잠시 끊겼을 때 프로세스를 계속 재시작하면 복구를 더 어렵게 만들 수 있다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.
DevOps
Git bisect로 회귀가 들어온 범위 좁히기, 유지보수할 때 남겨 둘 예제
과거에는 되던 동작이 언제 깨졌는지 모를 때 모든 커밋을 순서대로 읽는 것은 비효율적이다. 명확한 재현 명령이 있으면 변경 범위를 이분 탐색할 수 있다. 다시 읽을 수 있는 최소 맥락를 중심으로 작은 예제와 확인 기준을 정리합니다.
Engineering Culture
아키텍처 결정에 당시의 맥락 남기기, 다음 실험으로 이어지는 회고
결론만 남은 설계 문서는 시간이 지나면 왜 그런 선택을 했는지 설명하지 못한다. 제약이 달라졌을 때 바꿀 부분과 지킬 부분을 구분할 수 있어야 한다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.