Engineering Culture
첫 변경으로 검증하는 온보딩 문서, 실패를 설명할 단서 남기기
설치 설명이 길어도 새 동료가 실제 변경을 실행하고 확인하지 못하면 개발 환경을 이해하기 어렵다. 작은 결과를 만드는 경로가 필요하다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
THE BUILDER’S NOTE
Engineering.
01 / INSIDE THE BUILD만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.
최근 이야기
작은 발견부터 깊이 있는 고민까지.
AI & Data
정밀도와 재현율의 질문, 실패를 설명할 단서 남기기
모델을 개선했다는 말이 어떤 종류의 실수를 줄였다는 뜻인지 분명하지 않을 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Backend
오래된 페이지를 위한 키셋 조회, 실패를 설명할 단서 남기기
큰 offset으로 뒤쪽 페이지를 읽으면 앞부분의 많은 행을 건너뛰는 비용이 생길 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
DevOps
비밀 값을 로그 밖에 두는 설정 관리, 실패를 설명할 단서 남기기
연결 문자열과 인증 헤더를 통째로 기록하면 장애 분석용 로그가 자격 증명의 복사본이 된다. 설정 확인 편의와 접근 권한을 함께 생각해야 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
DevOps
환경 설정을 시작 시점에 검증하기, 실패를 설명할 단서 남기기
누락된 환경 변수가 특정 기능을 누르는 순간에야 드러나면 배포 성공 표시를 믿기 어렵다. 기본값으로 조용히 우회하는 설정은 원인 파악도 어렵게 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
Backend
중복 방지는 데이터베이스에서도, 실패를 설명할 단서 남기기
먼저 같은 값이 있는지 조회하는 방식만으로는 동시에 들어오는 중복 생성을 막기 어렵다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.