혼자서 4개의 제품 출시하기
1년 동안 네 개의 제품을 출시했습니다.
spectr-ai, Scry, Argus, Lomi가 포함되며, 보안, Web3, 브라우저 확장 프로그램, B2B SaaS 분야를 다룹니다.
이 제품들을 혼자 만들면서 단일 프로젝트로는 배울 수 없었던 교훈들을 얻었습니다.
제가 배운 점은 다음과 같습니다.
- 지루한 작업에 시간과 에너지를 할당하세요.
저는 어려운 기술적 문제에 에너지를 쏟았습니다. AI 분석과 바이트코드 재구성(bytecode reconstruction)에 집중했습니다. 이 부분들은 어려웠지만 예측 가능했습니다.
진짜 위협은 화려하지 않은 작업들이었습니다. Chrome Web Store 리뷰, 프록시 해결(proxy resolution), 배포 설정 등이 제 프로젝트를 거의 무너뜨릴 뻔했습니다.
진짜 작업은 종종 가장자리에서의 통합(integration at the edges) 작업입니다. 저는 매번 이 부분에 필요한 리소스를 과소평가했습니다.
- AI는 시작을 쉽게 만들 뿐, 끝을 쉽게 만들지는 않습니다.
사람들은 AI 덕분에 혼자서도 회사를 세울 수 있다고 말합니다. 진실은 좀 더 구체적입니다.
AI는 기능의 첫 80%를 처리합니다. 보일러플레이트(boilerplate)를 구축하고 테스트 초안을 작성합니다. 덕분에 혼자서도 작업이 가능해집니다.
하지만 AI는 마지막 20%를 처리하지 못합니다. 여기에는 예외 상황(edge cases), 보안 리뷰, 불안정한 연결 디버깅 등이 포함됩니다. 그 부분은 여전히 느리고, 여전히 온전한 집중력을 필요로 합니다.
- 이름 변경은 발전입니다.
프로젝트가 성장함에 따라 여러 번 이름을 바꿨습니다. 예전에는 이름을 바꾼다는 것이 노력을 낭비하는 것이라고 생각했습니다.
제 생각이 틀렸습니다. 이름을 바꾼다는 것은 마침내 제품을 제대로 이해했다는 뜻입니다. 코드는 그대로지만, 명확성은 향상됩니다.
- 다듬기보다 로직이 우선입니다.
예쁜 UI는 함정입니다. 기능이 바뀌면 디자인을 다시 해야 합니다. 이는 시간 낭비입니다.
제 규칙은 간단합니다. 스타일을 입히기 전에 로직과 테스트를 먼저 끝내는 것입니다. 기능은 테스트를 통해 증명될 때만 작동하는 것입니다. 제대로 작동하기 전까지는 예쁘게 만들지 마세요.
- 실패에 대해 쓰세요.
빌딩 인 퍼블릭(Building in public)은 좋지 않은 부분도 공유하는 것을 의미합니다.
저는 편법(hacks), 실패한 접근 방식, 버그에 대해 썼습니다. 이는 침묵 속에서 작업하는 것보다 더 많은 것을 가르쳐 주었습니다. 또한 여러분의 과정에 관심을 갖는 오디언스를 구축해 주었습니다.
혼자 제품을 만든다면, 다음 규칙을 따르세요:
• 핵심 기능보다 통합(integration)에 더 많은 시간을 할애하세요. • 단순 반복 작업(grunt work)에는 AI를 사용하되, 어려운 20%는 직접 하세요. • UI보다 테스트를 우선시하세요. • 진행하면서 실수를 공유하세요.
출시(Shipping)는 동사입니다. 완료된 상태가 아닙니다. 네 번의 출시를 경험한 것은 하나의 제품을 완벽하게 만드는 것보다 훨씬 더 많은 것을 가르쳐 주었습니다.
Optional learning community: https://t.me/GyaanSetuAi