4개의 제품을 혼자 출시하며: 1년간의 빌딩 인 퍼블릭(Building in Public)이 내게 가르쳐준 것들

지난 1년 동안 저는 주로 혼자서 네 가지 제품을 출시했습니다: spectr-ai (AI 스마트 컨트랙트 감사 도구), Scry (모든 EVM 컨트랙트와 채팅), Argus (트랜잭션 방화벽 확장 프로그램), 그리고 Lomi (멀티 테넌트 SaaS)입니다. 이 제품들은 보안, Web3, 브라우저 확장 프로그램, B2B SaaS를 아우릅니다. 이토록 다양한 것들을 혼자 만드는 과정은 단일 프로젝트로는 배울 수 없었던 교훈들을 가르쳐 주었습니다. 여기 제 작업 방식을 실제로 변화시킨 교훈들이 있습니다.

교훈 1: 가장 무서운 부분은 당신이 생각하는 부분인 경우가 드물다

이 모든 프로젝트에서 저는 기술적으로 어려운 부분에 대해 두려움의 예산을 책정했습니다. spectr-ai의 AI 분석, Scry의 바이트코드 재구성(bytecode reconstruction), Lomi의 이중 범위 RLS(dual-scope RLS) 같은 것들 말이죠. 그것들은 어려웠지만, 노력해서 해결할 수 있는 '알 수 있는' 난이도였습니다.

실제로 각 프로젝트를 침몰시킬 뻔했던 부분은 가장자리(edges)에 있는 지루한 부분들이었습니다. Argus의 경우 방화벽 로직이 아니라 Chrome 웹 스토어 심사였습니다. Scry는 채팅 기능이 아니라 프록시 해상도(proxy resolution)였습니다. spectr-ai는 잘 작동하는 감사 엔진이 아니라, 여전히 발목을 잡고 있는 배포와 인증(auth) 문제입니다. 교훈은 이렇습니다: 해자(moat)는 대개 매력적이지 않은 통합 작업(integration work)에 있으며, 저는 지속적으로 이 작업에 대한 예산을 과소평가해 왔습니다.

교훈 2: AI는 1인 개발의 경제성을 변화시켰지만, 사람들이 말하는 방식과는 다르다

떠들썩한 주장은 "AI가 한 사람이 회사를 세울 수 있게 해준다"는 것입니다. 제가 직접 경험한 더 조용한 진실은 더 구체적입니다: AI는 모든 기능의 '초기 80%'에 드는 비용을 무너뜨렸고, 그 80%가 바로 1인 개발을 불가능하게 느껴지게 만들었던 바로 그 부분이었습니다.

저는 예전에 혼자 보일러플레이트(boilerplate)를 작성하던 것보다 더 빠르게 기능의 뼈대를 잡고, 테스트 초안을 작성하며, 작동하는 첫 번째 버전을 만들어낼 수 있습니다. AI가 무너뜨리지 못한 것은 마지막 20%입니다: 엣지 케이스(edge cases), 보안 검토, "왜 불안정한 연결 상태에서 이것이 깨지는가"에 대한 디버깅 같은 것들 말이죠. 그 부분은 여전히 저의 몫이며, 여전히 느리고, 여전히 진짜 작업이 이루어지는 곳입니다. 따라서 AI가 저를 팀으로 만들어준 것은 아닙니다. AI는 단순 반복 작업(grunt work)을 충분히 저렴하게 만들어 주어, 제가 하나 대신 네 개의 제품을 출시할 여력을 갖게 해주었습니다.

교훈 3: 이름을 바꾼 제품은 낭비된 제품이 아니다

AbiLens는 Scry가 되었습니다. repo-malware-scanner는 Argus Lens가 되었습니다. 초기 이름들은 임시 명칭(placeholders)이었고, 저는 이름을 바꾸는 것이 원래의 노력을 낭비하는 것이라고 느끼곤 했습니다. 제가 틀렸습니다. 이름 변경은 제품이 제대로 된 정체성을 가질 만큼 충분히 명확해졌다는 신호입니다. 이름이 바뀔 때 코드가 바뀐 것은 아니었습니다. 바뀐 것은 제가 무엇을 만들었는지, 그리고 그것에 적절한 이름을 붙일 수 있을 만큼 충분히 이해하게 되었다는 점입니다. 그러한 명확함은 낭비가 아니라 진전입니다.

교훈 4: UI보다 기능을 먼저 완성하라, 매번

특히 혼자 작업할 때 유혹에 빠지기 쉬운 것은, 예쁜 스크린샷이 마치 진전이 있는 것처럼 느껴지기 때문에 초기에 보기 좋게 만드는 것입니다. 저는 이를 저항하는 법을 배웠습니다. 절반만 작동하는 기능 위에 얹어진 아름다운 UI는 함정입니다. 기능이 다른 형태를 요구하게 되면 UI를 다시 만들어야 하며, 스스로가 실제보다 더 많이 진행했다고 착각하게 만들기 때문입니다.

모든 제품에 대해 저의 규칙은 다음과 같았습니다: 모든 기능은 어떤 다듬기(polish) 작업을 하기 전에 반드시 로직(logic)과 테스트(tests)가 완료되어야 합니다. 저는 curl 명령이 성공하거나 타입(types)이 컴파일되었다고 해서 무언가가 작동한다고 주장하지 않습니다. 그것이 망가졌을 때 실패할 테스트가 존재할 때 비로소 작동하는 것입니다. 그러고 나서, 오직 그때만이 제가 그것을 예쁘게 만드는 단계입니다. 이 단 하나의 규율이 그 어떤 프레임워크(framework) 선택보다 더 많은 재작업을 줄여주었습니다.

교훈 5: 작업이 미완성일 때라도 공유하라

빌딩 인 퍼블릭(Building in public)은 제대로 작동하지 않는 부분을 포함하여, 진행 과정 중의 각 단계에 대해 글을 쓰는 것을 의미했습니다. 본능적으로는 무언가 인상적일 때까지 기다리게 됩니다. 하지만 보상은 그 반대에서 왔습니다. KelpDAO 해킹에 대해, 실패한 접근 방식에 대해, 그리고 제 자신의 위협 모델(threat model)에서 발견한 버그에 대해 쓰는 것이 조용히 출시하는 것보다 더 많은 것을 가르쳐 주었으며, 출시뿐만 아니라 과정 자체에 관심을 갖는 오디언스(audience)를 구축해 주었습니다.

"프록시 컨트랙트(proxy contract)를 정확히 어떻게 해결했는지"에 대한 오디언스는 규모는 작지만, 바로 그들이 적합한 사람들입니다. 그들이 바로 사용자가 되고, 협업자가 되며, 다음 아이디어의 원천이 됩니다.

시작하려는 사람에게 해주고 싶은 말

만약 당신이 혼자 무언가를 만들려고 한다면:

흥미로운 핵심 기능(core)이 아니라, 지루한 통합의 경계(integration edges)를 위해 시간을 예산화하세요. 그 경계들이 당신을 놀라게 할 것입니다.
모든 기능의 초기 80%를 저렴하게 만들기 위해 AI를 사용하되, 나머지 20%는 여전히 당신의 느리고 신중한 작업이 필요하다는 점을 받아들이세요.
다듬기(polish) 전에 기능과 테스트를 먼저 출시하세요. 항상 그래야 합니다. 예외는 없습니다.
거친 부분들을 포함하여 진행 과정 그대로에 대해 글을 쓰세요. 가르치는 것이 학습의 절반입니다.

1년 동안 4개의 제품을 출시한다는 것은, 그중 대부분이 "완성"되지 않았다는 사실을 깨닫기 전까지는 많게 느껴질 수 있습니다. spectr-ai는 여전히 배포(deploy)와 인증(auth)이 필요합니다. 그것은 괜찮습니다. 출시(Shipping)는 상태가 아니라 동사이며, 매우 다른 4개의 도메인에 걸쳐 이를 4번 수행한 것은 하나의 제품을 완벽하게 만드는 것보다 저에게 더 많은 것을 가르쳐 주었습니다.