본문으로 건너뛰기

← 블로그 · Projects

프로젝트 회고 30편을 정리하고 남은 세 가지 기준

#회고 #1인개발 #품질 #프로젝트

유주환 · Founder, Full Stack Developer

토리스(Toris) · 발행

프로젝트를 돌아보는 30일 · 30/30
과거 프로젝트 경험을 날짜별로 엮은 회고입니다. 표시 날짜는 연재 기준일이며, 실제 작업일과 다를 수 있습니다.

8월 12일부터 9월 10일까지의 날짜에 맞춰 프로젝트 경험을 한 편씩 정리했다. 이 연재는 그날마다 새 기능을 완성했다는 작업 일지가 아니라, 이전에 했던 일을 하루 한 주제씩 다시 읽는 회고다. 교육 콘텐츠부터 계약과 여행 추천, 모바일 앱까지 다시 보니 서로 다른 기술 아래에 비슷한 질문이 남아 있었다.

첫째, 값보다 경계를 먼저 정하기

교육 플랫폼에서는 원본과 풀이 상태를 나눠야 했다. 장면의 ID와 표시 번호도 역할이 달랐다. 전자계약에서는 사용자별 화면이 달라도 계약 상태의 의미가 같아야 했다. 문제의 시작은 값이 없어서가 아니라 같은 값에 여러 의미를 맡긴 데 있는 경우가 많았다.

다음 프로젝트에서는 저장소나 라이브러리를 고르기 전에 누가 데이터를 바꾸는지, 언제 없어지는지, 무엇과 연결되는지부터 적겠다. 이 세 질문에 답할 수 있으면 구현 선택의 이유도 설명하기 쉬워진다.

둘째, 성공 다음이 아니라 실패 다음을 보기

Drawer의 저장 시점, 경기 기록의 재진입, 사진 공유의 부분 실패는 모두 사용자가 작업을 이어 갈 수 있는지와 연결됐다. 데이터가 남았다는 것과 사용자가 다시 열 수 있다는 것은 달랐다. 요청이 성공했다는 것과 다른 사용자가 결과를 볼 수 있다는 것도 달랐다.

그래서 다음 완료 기준에는 중간에 떠났다가 돌아오는 시나리오를 넣겠다. 무조건 많은 테스트를 추가하기보다 데이터와 권한, 외부 요청이 만나는 경로를 우선하겠다. 한 번의 정상 동작보다 실제로 중단되었을 때의 상태가 설계의 빈틈을 더 잘 드러낸다.

셋째, 결과를 설명할 근거 남기기

성능 기록은 측정 조건이 있어야 하고, 추천 개선은 비교할 입력이 있어야 한다. 배포 사실과 사용자 효과도 같은 결과가 아니다. 과거 회고에 남아 있는 테스트·문서화의 아쉬움을 이번 글에서 없었던 일로 바꾸지 않았다. 아직 하지 않은 개선은 다음 기준으로 남기는 것이 더 도움이 됐다.

이 연재를 정리하며 가장 경계한 것은 경험을 그럴듯한 성공담으로 바꾸는 일이었다. 선택에는 당시의 제약이 있었고 지금 보면 아쉬운 부분도 있다. 무엇을 만들었다는 목록보다 그 조건에서 왜 그렇게 판단했는지가 다음 개발에 더 쓸모 있었다.

다음 작업을 시작할 때 이 세 가지를 다시 묻고 싶다. 데이터의 경계를 설명할 수 있는가. 중간에 실패해도 이어 갈 수 있는가. 완료라고 말할 근거가 남아 있는가. 좋은 회고는 지난 일을 멋지게 마무리하는 글보다 다음 선택을 조금 더 정확하게 만드는 기록이었다.

연재 첫 글: 교육 콘텐츠의 상태 경계

READERS / LIVE

읽고 난 뒤의 대화

조회

댓글은 바로 공개됩니다. 개인정보와 공격적인 표현은 남기지 말아주세요.