Backend
입력 검증의 소유권, 실패를 설명할 단서 남기기
화면에서 검증한 값이라고 믿고 서버 검증을 생략하면 다른 클라이언트가 제약을 우회할 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
THE BUILDER’S NOTE
Engineering.
01 / INSIDE THE BUILD만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.
최근 이야기
작은 발견부터 깊이 있는 고민까지.
DevOps
잠금 파일로 CI 의존성 설치 고정하기, 실패를 설명할 단서 남기기
로컬에서는 통과한 코드가 CI에서 다른 의존성 버전을 받으면 문제 원인이 코드인지 환경인지 구분하기 어렵다. 설치 과정도 검증의 입력으로 취급한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Frontend
목록의 key와 항목의 정체성, 실패를 설명할 단서 남기기
목록 앞에 항목을 추가했을 때 입력값이나 선택 상태가 다른 행으로 옮겨갈 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Engineering Culture
회의 기록을 결정과 행동으로 정리하기, 실패를 설명할 단서 남기기
발언을 길게 받아 적어도 무엇을 결정했고 누가 다음 행동을 하는지 찾기 어려울 수 있다. 회의의 결과를 실행 가능한 형태로 남겨야 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
DevOps
한 번 만든 산출물을 환경 사이에서 이동하기, 실패를 설명할 단서 남기기
같은 커밋이라도 배포할 때마다 의존성을 다시 풀면 다른 결과가 나올 수 있다. 코드 식별자와 실행 산출물 식별자를 연결해야 재현이 쉬워진다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
AI & Data
실험을 다시 실행할 수 있게 기록하기, 실패를 설명할 단서 남기기
같은 코드인데 실행할 때마다 점수가 바뀌면 변경의 효과를 판단하기 어렵다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.