스타트업, 법무법인, 부동산, 교육, 커머스, 의료… 업종을 가리지 않고 111개의 프로젝트를 진행했습니다. 매번 새로운 도메인을 이해하고, 새로운 요구사항을 구현하면서 쌓인 인사이트를 공유합니다.
1. 클라이언트가 원하는 것과 필요한 것은 다르다
“쇼핑몰 만들어주세요”라는 요청 뒤에는 항상 더 깊은 목표가 있습니다. 재고 관리 부담을 줄이고 싶다거나, 오프라인 매장 고객을 온라인으로 전환하고 싶다거나. 표면적 요구를 그대로 구현하는 것보다, 진짜 문제가 무엇인지 먼저 파악하는 것이 좋은 결과물로 이어집니다.
2. 범위를 명확히 해야 일정이 지켜진다
첫 계약서에서 “추가 수정 3회 포함”이라고 써도, 수정의 범위가 불명확하면 분쟁이 생깁니다. 이제는 기능 목록과 화면 수를 명시하고, 변경사항은 별도 견적으로 처리합니다. 처음에는 딱딱해 보여도 결국 클라이언트도 편해합니다.
3. 빠른 프로토타입이 100장의 기획서보다 낫다
긴 문서로 설명하면 각자 다르게 상상합니다. 클릭 가능한 Figma 프로토타입이나 작동하는 MVP를 2~3일 안에 보여주면, 피드백이 구체적으로 바뀝니다. “이 버튼이 여기 있으면 안 되겠어요”처럼요. 오해를 줄이는 가장 빠른 방법입니다.
4. 기술 선택보다 완성이 중요하다
처음엔 최신 기술을 쓰고 싶은 욕심이 있었습니다. 하지만 납기일을 지키지 못한 채 완벽한 코드를 추구하는 것은 클라이언트에게 아무 가치가 없습니다. 지금은 검증된 스택으로 빠르게 납품하고, 다음 단계에서 점진적으로 개선합니다.
5. 배포 후 2주가 진짜 프로젝트의 완성이다
많은 프리랜서가 배포를 끝으로 봅니다. 하지만 실제 사용자가 접속하면서 발견되는 이슈들이 있습니다. 배포 후 2주 동안 모니터링하고 빠르게 대응하는 것이 클라이언트 만족도를 가장 크게 올리는 방법이었습니다. 이 기간을 계약에 포함하면서 재의뢰율이 크게 높아졌습니다.
111개의 프로젝트가 모두 성공적이진 않았습니다. 하지만 실패한 프로젝트에서 더 많이 배웠습니다. 앞으로의 112번째, 113번째 프로젝트에서도 이 인사이트들이 쌓여갈 것입니다.