Engineering Culture
실행할 수 있는 문서 예제 유지하기, 실패를 설명할 단서 남기기
설명과 예제가 서로 어긋나면 처음 사용하는 사람이 어디를 믿어야 할지 알기 어렵다. 예제의 전제와 기대 결과를 함께 관리해야 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
THE BUILDER’S NOTE
Engineering.
01 / INSIDE THE BUILD만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.
최근 이야기
작은 발견부터 깊이 있는 고민까지.
DevOps
빌드 캐시의 입력을 빠뜨리지 않기, 실패를 설명할 단서 남기기
오래된 산출물이 캐시에서 복원되면 코드가 수정됐는데도 변경이 반영되지 않을 수 있다. 캐시 키는 결과에 영향을 주는 입력을 설명해야 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Backend
호환성을 지키는 스키마 변경, 실패를 설명할 단서 남기기
새 코드와 이전 코드가 잠시 함께 실행되는 배포에서는 한 번에 열을 바꾸기 어렵다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
AI & Data
코사인 유사도가 묻는 것, 실패를 설명할 단서 남기기
벡터 두 개가 비슷하다는 말에는 방향과 크기라는 서로 다른 기준이 섞일 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Frontend
모달을 닫은 뒤 포커스 돌려주기, 실패를 설명할 단서 남기기
모달을 닫은 뒤 키보드 포커스가 사라지면 사용자가 작업 위치를 잃는다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Engineering Culture
구현 모양보다 동작을 지키는 테스트, 실패를 설명할 단서 남기기
내부 함수 호출 순서까지 고정한 테스트는 리팩터링마다 깨지지만 실제 오류를 놓칠 수 있다. 어떤 계약을 보호하는지 먼저 분명히 해야 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.