요구사항 정리부터 출시 검증까지 연결하는 6년차 Full Stack Developer
고객 요구사항을 초기 제품의 출시 기준과 운영 흐름으로 구체화합니다.
기능 목록을 그대로 구현하기보다 사용자가 끝내야 하는 일, 운영자가 확인할 상태, 출시 후 실패하면 안 되는 지점을 먼저 맞춥니다.
스타트업 초기 서비스와 XR/AR 콘텐츠 운영 도구를 만들며 화면, API, 데이터, 배포, 운영 절차가 같은 출시 기준을 향하도록 맞춰 왔습니다. React, Next.js, Rails, Django, NestJS처럼 프로젝트마다 다른 스택을 제품 단계와 팀 제약에 맞춰 사용했습니다.
고객사와 직접 이야기해야 하는 작업에서는 먼저 같은 단어를 같은 의미로 쓰는지 확인합니다. 기획, 디자인, 운영, 외부 파트너가 얽힌 작업일수록 요구사항보다 기준, 제약, 놓치면 안 되는 실패 지점을 먼저 맞춰야 구현 범위가 흔들리지 않습니다.
결제/정산, 외부 API, WebView 앱, 백오피스, 인프라 운영처럼 제품이 실제로 돌아간 뒤의 예외 흐름까지 함께 다뤘습니다. 구현이 끝났다는 말은 배포 후 확인할 근거까지 남았을 때 의미가 있다고 봅니다.
로그, 문서, Git 이력, 테스트 절차로 정상 흐름과 예외 흐름을 다시 확인할 수 있어야 다음 배포와 장애 대응이 추측에 기대지 않습니다.
AI-assisted 작업도 같은 기준으로 다룹니다. 초안 생성과 조사 속도는 활용하되, 반영 여부는 현재 코드, 실행 결과, 문서, Git 이력과 대조한 뒤 결정합니다.
Working style
- Style 01
요구사항은 기능 목록이 아니라 고객사 맥락, 사용자 작업, 제약, 실패 지점으로 다시 나눕니다.
- Style 02
MVP는 작게 만들되 화면, API, 데이터, 배포, 관리자 운영 흐름이 같은 출시 기준을 향하게 맞춥니다.
- Style 03
운영에서 다시 확인할 로그, 문서, Git 이력, rollback 기준을 구현 범위와 함께 남깁니다.