본문으로 건너뛰기

요구사항 정리부터 출시 검증까지 연결하는 6년차 Full Stack Developer

고객 요구사항을 초기 제품의 출시 기준과 운영 흐름으로 구체화합니다.

기능 목록을 그대로 구현하기보다 사용자가 끝내야 하는 일, 운영자가 확인할 상태, 출시 후 실패하면 안 되는 지점을 먼저 맞춥니다.

스타트업 초기 서비스와 XR/AR 콘텐츠 운영 도구를 만들며 화면, API, 데이터, 배포, 운영 절차가 같은 출시 기준을 향하도록 맞춰 왔습니다. React, Next.js, Rails, Django, NestJS처럼 프로젝트마다 다른 스택을 제품 단계와 팀 제약에 맞춰 사용했습니다.

고객사와 직접 이야기해야 하는 작업에서는 먼저 같은 단어를 같은 의미로 쓰는지 확인합니다. 기획, 디자인, 운영, 외부 파트너가 얽힌 작업일수록 요구사항보다 기준, 제약, 놓치면 안 되는 실패 지점을 먼저 맞춰야 구현 범위가 흔들리지 않습니다.

결제/정산, 외부 API, WebView 앱, 백오피스, 인프라 운영처럼 제품이 실제로 돌아간 뒤의 예외 흐름까지 함께 다뤘습니다. 구현이 끝났다는 말은 배포 후 확인할 근거까지 남았을 때 의미가 있다고 봅니다.

로그, 문서, Git 이력, 테스트 절차로 정상 흐름과 예외 흐름을 다시 확인할 수 있어야 다음 배포와 장애 대응이 추측에 기대지 않습니다.

AI-assisted 작업도 같은 기준으로 다룹니다. 초안 생성과 조사 속도는 활용하되, 반영 여부는 현재 코드, 실행 결과, 문서, Git 이력과 대조한 뒤 결정합니다.

Working style

  1. Style 01

    요구사항은 기능 목록이 아니라 고객사 맥락, 사용자 작업, 제약, 실패 지점으로 다시 나눕니다.

  2. Style 02

    MVP는 작게 만들되 화면, API, 데이터, 배포, 관리자 운영 흐름이 같은 출시 기준을 향하게 맞춥니다.

  3. Style 03

    운영에서 다시 확인할 로그, 문서, Git 이력, rollback 기준을 구현 범위와 함께 남깁니다.

Links