외주 시장이라는 정글에 맨몸으로 던져진 기분입니다. 직장 생활 5년이면 웬만한 시스템 아키텍처는 다 꿰고 있다고 자부했습니다. 하지만 회사라는 안전한 울타리를 벗어나 제 서비스를 직접 팔아보겠다고 나선 순간 제가 가진 기술 스택이 얼마나 편협했는지 깨닫는 데는 그리 오랜 시간이 걸리지 않았습니다. 회사 보안 정책 때문에 제 코드는 외부로 한 줄도 유출할 수 없었고 정작 제 이름으로 된 포트폴리오는 전무했습니다.

프리랜서 시장이나 1인 창업의 세계에서 포트폴리오는 곧 신용등급과 같습니다. 아무리 실력이 좋아도 보여줄 결과물이 없으니 대화의 기회조차 얻기 힘들더군요. 특히 많은 외주 프로젝트가 요구하는 결제 시스템 연동 경험이 없다는 사실은 제 몸값을 깎아먹는 치명적인 약점이었습니다. 그래서 저는 기다리는 대신 직접 부딪히기로 했습니다. 시장에 올라온 외주 기획안을 제 공부 주제로 삼아 직접 구현해 보는 시리즈를 시작합니다.

포트폴리오가 없어서 겪는 닭과 달걀의 문제

프리랜서 플랫폼에 들어가 보신 분들은 공감하실 겁니다. 기업들은 늘 실전 경험이 풍부한 사람을 찾습니다. 그런데 그 실전 경험을 쌓으려면 일단 프로젝트에 참여를 해야 하죠. 포트폴리오가 없으니 참여를 못 하고 참여를 못 하니 포트폴리오가 안 쌓이는 무한 루프에 빠지게 됩니다.

저 또한 이 루프에 갇혀 한참을 헤맸습니다. 웹과 앱 개발은 자신 있었지만 막상 돈이 오가는 결제 로직 앞에서는 작아졌습니다. 단순히 API를 연결하는 수준을 넘어 취소, 환불, 부분 취소, 그리고 정산까지 이어지는 비즈니스 로직을 다뤄보지 않았다는 공포가 컸기 때문입니다. 하지만 도망만 다녀서는 인디 해커로서의 생존은 불가능하다는 것을 깨달았습니다.

결제 시스템이라는 거대한 벽을 마주하며

외주 시장의 기획안들을 훑어보니 수익 모델이 있는 거의 모든 서비스는 결제 기능을 포함하고 있었습니다. 커머스, 구독형 SaaS, 중개 플랫폼 등 분야를 막론하고 결제는 비즈니스의 심장이었습니다. 제가 이 심장을 다루지 못한다면 결국 반쪽짜리 개발자로 남을 수밖에 없겠다는 위기감이 들었습니다.

특히 단순 결제창 호출보다 까다로운 것은 예외 상황에 대한 처리입니다. 유저가 결제 도중 브라우저를 닫아버리거나 네트워크 오류로 승인 결과가 서버에 전달되지 않는 상황 등을 어떻게 관리할 것인가가 진짜 실력의 차이를 만듭니다. 저는 이번 시리즈를 통해 이 과정을 정면으로 돌파해 보려 합니다.

외주 기획안을 내 커리큘럼으로 만드는 역발상 전략

전략은 단순하지만 확실합니다. 실제 외주 플랫폼에 올라온 프로젝트 중 요구사항이 명확한 것들을 수집합니다. 그들이 원하는 기능이 무엇인지 시장에서 지금 당장 필요로 하는 기술 스택이 무엇인지 파악한 뒤 제 로컬 환경에서 그대로 구현해 보는 것입니다.

• 현실적인 니즈 파악: 클라이언트가 왜 이 기능을 필요로 하는지 기획 의도를 분석합니다.
• 기술 스택의 동기화: 실제 시장에서 가장 많이 찾는 라이브러리와 프레임워크를 사용해 봅니다.
• 실전 수준의 구현: 클론 코딩이 아니라 실제 계약을 맺은 것처럼 엄격한 비즈니스 로직을 적용합니다.

누군가 저를 채용해 주기를 기다리는 대신 제가 먼저 시장이 원하는 결과물을 만들어 증명해 보이기로 했습니다. 이것이 포트폴리오가 없는 개발자가 취할 수 있는 가장 공격적인 생존 방식입니다.

포트원(Portone)을 첫 번째 실전 도구로 선택한 이유

이번 시리즈의 첫 단추로 포트원을 선택했습니다. 과거 아임포트로 잘 알려진 이 서비스는 국내외 다양한 PG사를 하나의 인터페이스로 통합해 주기에 외주 시장에서 선호도가 매우 높습니다. 제가 직접 포트원 연동을 시작하며 마주할 이슈들은 다음과 같습니다.

• 결제 시퀀스 설계: 유저가 결제 버튼을 누르는 순간부터 정산 데이터가 확정되기까지의 흐름도 작성.
• 웹훅(Webhook) 처리: 클라이언트와 서버 간의 통신이 끊겨도 데이터의 무결성을 유지하는 비동기 처리 기법.
• 결제 상태 머신 관리: 준비, 완료, 실패, 취소 등 복잡한 결제 상태를 안전하게 관리하는 DB 설계.
• 테스트 환경 구축: 실제 결제가 발생하지 않으면서도 실무와 동일한 검증 과정을 거치는 법.

💡 Tip: 비즈니스 로직을 설계할 때는 해피 패스(성공 케이스)보다 실패 케이스에 80%의 시간을 써야 합니다. 결제 도중 발생할 수 있는 수십 가지의 예외 상황을 코드로 방어하는 능력이 곧 시니어의 가치입니다.

직접 만들어보며 확장될 빌더의 시각

PMF Verify나 드림스토어 같은 프로젝트를 직접 만들 때도 그랬지만 제작자가 곧 사용자가 되어보는 경험은 제 서비스의 가치를 완전히 다르게 만듭니다. 결제 시스템도 단순히 코드 구현에 그치지 않고 정산 리포트가 어떻게 나와야 사용자가 편할지 결제 실패 시 어떤 메시지를 띄워야 이탈률을 줄일 수 있을지 고민하는 과정을 거칠 예정입니다.

사용자로서 느끼는 불편함이 곧 제가 구현해야 할 기능이 됩니다. 바라는 게 많아진다는 건 그만큼 제가 서비스의 본질에 다가가고 있다는 증거입니다. 결제 연동 경험이 없다는 꼬리표를 떼기 위한 제 삽질이 저와 비슷한 고민을 하는 다른 개발자들에게도 실질적인 이정표가 되길 바랍니다.

---

요약 및 앞으로의 실행 계획

• 포트폴리오 부재를 극복하기 위해 외주 기획안을 직접 구현하는 프로젝트 시리즈를 시작합니다.
• 첫 번째 타겟은 비즈니스의 필수 요소인 결제 및 구독 시스템 연동입니다.
• 포트원 SDK를 활용해 실무 수준의 결제 프로세스와 예외 처리 로직을 마스터할 계획입니다.

오늘의 Action Item: 지금 바로 외주 플랫폼에서 본인이 ‘해본 적 없어서’ 포기했던 프로젝트 하나를 골라 요구사항만 메모해 보세요. 다음 일지에서는 제가 포트원 테스트 환경을 세팅하며 겪은 첫 번째 삽질기를 들고 오겠습니다.