Engineering Culture
진행 중인 일을 줄여 흐름 보기, 실패를 설명할 단서 남기기
많은 작업을 동시에 시작하면 각각의 완료가 늦어지고 맥락 전환이 늘어난다. 바쁜 정도보다 끝나는 흐름을 보는 지표가 필요하다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
THE BUILDER’S NOTE
Engineering.
01 / INSIDE THE BUILD만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.
최근 이야기
작은 발견부터 깊이 있는 고민까지.
AI & Data
회귀 오차의 크기를 읽는 방법, 실패를 설명할 단서 남기기
평균 오차가 줄었어도 드물게 발생하는 큰 실수는 더 커졌을 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Frontend
상태를 필요한 곳에 두기, 실패를 설명할 단서 남기기
검색창의 입력 상태가 페이지 전체에 있으면 무관한 컴포넌트까지 변경을 따라가야 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
DevOps
평균 뒤에 숨은 느린 요청 보기, 실패를 설명할 단서 남기기
일부 요청이 매우 느려도 평균 응답 시간은 괜찮게 보일 수 있다. 분포의 긴 꼬리를 보려면 관측 창과 집계 방식을 함께 이해해야 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Backend
외부 요청에 시간 제한 두기, 실패를 설명할 단서 남기기
응답하지 않는 외부 서비스 하나가 애플리케이션의 작업 자원을 오래 붙잡을 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Engineering Culture
페어 프로그래밍의 역할과 전환 주기, 실패를 설명할 단서 남기기
두 사람이 같은 화면을 본다고 항상 지식이 공유되지는 않는다. 한 사람이 계속 입력하고 다른 사람이 수동적으로 따라가면 이해의 차이가 남는다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.