요구사항을 출시 가능한 범위로 나누고, 운영에서 다시 확인할 기록을 남깁니다.

스타트업 전문 에이전시에서 여러 초기 제품을 만들며 요구사항 정리, 기능 범위 정의, 구현, 배포, 유지보수까지 이어지는 흐름을 맡아 왔습니다. 웹 서비스, 모바일 WebView 앱, 백오피스, 결제/정산, 외부 API 연동처럼 제품이 실제로 돌아가는 데 필요한 영역을 풀스택으로 다뤘습니다.

빠른 개발을 좋아하지만, 단순히 많은 기능을 빨리 쌓는 방식에는 조심스럽습니다. 먼저 요구사항을 사용자가 끝내야 하는 일로 나누고, 지금 만들 범위와 나중으로 미룰 범위를 구분합니다. 그래야 MVP가 작아져도 화면, API, 데이터, 배포가 같은 출시 기준을 향해 연결된다고 봅니다.

협업에서는 요구사항 자체보다 그 뒤의 상황을 먼저 이해하려고 합니다. 기획, 디자인, 운영, 외부 파트너가 함께 얽힌 작업일수록 같은 단어를 서로 다르게 이해하고 있을 가능성이 큽니다. 그래서 결정 전에 기준과 제약, 놓치면 안 되는 실패 지점을 맞춰 둡니다.

결제, 외부 API, WebView 앱, 백오피스처럼 운영 기준이 필요한 작업은 구현만으로 끝났다고 보지 않습니다. 정상 흐름과 예외 흐름을 로그, 문서, Git 이력으로 다시 확인할 수 있게 남겨야 다음 배포와 장애 대응이 추측에 기대지 않습니다.

최근에는 AI 페어링으로 코드 생성과 리팩터링 초안을 만들고, 복잡한 작업의 현황 조사와 영향 범위 분석도 함께 진행합니다. 생성된 결과는 테스트, 로그, 문서, Git 이력으로 확인한 뒤 반영하고, 반복되는 수동 작업은 스크립트와 GitOps 흐름으로 옮깁니다.

작업이 끝나면 결정과 다음 할 일을 프로젝트별 Markdown과 index로 남깁니다. 다시 시작할 때는 과거 판단을 그대로 믿기보다 현재 상태와 함께 다시 확인합니다. 오래 가는 제품일수록 코드만큼이나 이런 기록이 유지보수 비용을 줄인다고 봅니다.

관심사는 특정 기술 이름보다 제품을 실제 사용자에게 전달하고 계속 개선 가능한 상태로 유지하는 쪽에 있습니다. 요구사항 정리, 기능 구현, 비용, 성능 병목, 배포 표준화처럼 출시 전후에 드러나는 문제를 다시 개발 과제로 바꾸는 일을 중요하게 생각합니다.