본문으로 바로가기
Builder Shin.
Engineering
Builder Shin.

더 나은 내일을 만드는, 오늘의 기록.

THE BUILDER’S NOTE

Engineering.

01 / INSIDE THE BUILD

만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.

최근 이야기

작은 발견부터 깊이 있는 고민까지.

CATEGORIES

전체 글FrontendBackendAI & DataDevOpsEngineering Culture
Frontend

중복 제출을 다루는 화면 상태, 실패를 설명할 단서 남기기

저장 버튼을 빠르게 두 번 누르면 같은 요청이 반복될 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 02. 09.
Engineering Culture

팀의 용어를 같은 의미로 사용하기, 실패를 설명할 단서 남기기

같은 단어를 화면, API, 데이터베이스에서 다르게 쓰면 조건을 잘못 이해하기 쉽다. 특히 상태 이름은 사용자 행동과 연결되어야 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 02. 06.
AI & Data

예측 확률과 실제 빈도, 실패를 설명할 단서 남기기

높은 확률을 출력하는 모델이 그만큼 자주 맞는다고 바로 믿을 수는 없다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 02. 05.
Engineering Culture

코드 소유권을 연락 가능한 책임으로 보기, 실패를 설명할 단서 남기기

담당자가 있다는 사실이 다른 사람의 변경을 막는 경계가 되면 병목이 생긴다. 소유권은 판단과 운영 책임을 찾기 쉽게 만드는 장치여야 한다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 02. 02.
Backend

검색 필드의 허용 목록, 실패를 설명할 단서 남기기

클라이언트가 보낸 정렬 열이나 필터 이름을 SQL에 그대로 붙이면 데이터 노출과 쿼리 오류 위험이 커진다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 01. 31.
Frontend

폼 오류를 수정 가능한 문장으로 쓰기, 실패를 설명할 단서 남기기

폼 제출이 실패했는데 잘못된 입력이라는 문구만 표시되면 사용자는 무엇을 고칠지 알기 어렵다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.

2024. 01. 30.
1…787980…140