카테고리 없음

ch10. 스프린트6 종료, 솔로프리너 전환

biz-ninza 2026. 7. 4. 16:40

더보기

24.11 - 25.9 (ch1~ch5): 노션에서 자체사이트로

커뮤니티 글과 노션으로 시작 운영하며 만족도와 리퍼럴이 높았던 1:1스터디를 누적 300명 운영. 이를 웹사이트에 옮겨 시스템화 시도 하였으나 기획-디자인-프론트엔드-백엔드 체제로 결과물을 만드는데 어려움을 겪음.

일단 만들고 기능 확장을 하면서 '새로운' BM을 붙이자는 생각이 뼈아픈 패착이었음. MVP는 그 자체로 돈을 지불할 가치가 있는 최소기능이어야한다는걸 깊이 깨달음.

내가 가리킨 달을 바라보지 못하고 움직이는 손가락만 바라보는 상황을 여러번 경험했음 (돌아보면 내가 명확히 달을 가리킨게 맞나. 지금 돌아보면 나 역시 뜬구름을 잡으며 멍하니 허공을 가리킨게 아닌가 싶다)

또한 주1회 디스코드 비대면 기반이라는 점, 게다가 퇴근 후 비동기로 각자 작업하다보니 에러도 과다하고 기능누락도 많아 노션에서 수동관리하는 것만 못하게 되며 유저 전환이 어려웠음.

기획자 즉 PM의 역할이 가장 중요하며 비젼을 가장 선명히 그리고 있는 내가 키를 쥐는게 맞다는 것을 깨닫게 되었음.

 

💡얼라인은 팀 생사의 문제

 

한편, 이 때 웹으로 넘어오면서 가입은 200명이상 세자리수로 전환까진 되었으나 참여 유저가 많이 빠졌는데 그 이유는 노션에서 참여자/휴식자 관리하면서 서로 학습 성향이나 목표에 맞게 이어주며 매주 새 페이지로 TIL을 적게하고 매 기수 톡방으로 학습독려하며 관리해주던 서비스가 단순히 매칭만 기능하게 되면서 본질이 빠졌기 때문이었다.

기획자가 최소 기능만 넣고 조금씩 더해나가자고 했을때 강하게 반대하지 않았다. 나는 이전할거면 기존 학습장치들을 다 넣는게 맞다고 봤지만 개발 리소스와 사용자 편의를 바라보며 내린 그 친구의 '합리적'인 결정을 존중해서였다.

사이트로 이전한 이유는 유저간의 상호작용을 통해 학습밀도를 높이며 관리를 자동화하여 참여가능한 회원 수를 늘리는 것이 주목적이었고 그를 발판으로 새로운  기능으로 확장하려는 전략이였다. 아무리 글로 적고 미팅에서 반복해말해도 울리지 않았다.

 

많은 스타트업 팀들이 "문제를 얼마나 이해하고 공감하는지" 를 중요하게 생각하는지, 즉 왜 그토록 미션과 비젼의 정의와 구성원으로의 전파를 그토록 강조하는지를 지나고서야 뼛속깊이 깨달았다.

예를들어 주간 학습을 밀하게 하고 성취감을 느끼게 할지를 고민하며, 당장 수는 적더라도 기존 유저를 확실히 지키거나 유입시키며 늘리는 것에 집중해야하는데 멀쩡한 UI를 고친다던지, 매칭 알고리즘을 개선한다던지, 코드 오버엔지니어링을 한다던지 엉뚱한 곳에 리소스를 퍼붓는것이 너무나 답답했다.

 

유저입장에서는 처음 느꼈던 본질과 점점 계속 멀어지며 어느새 기억속에서 잊혀지는 서비스가 되어버리고 말아 다시 복구하는 것이 어려웠다. 또한 팀원입장에서도 새로운 기능을 만들면서도 본질이 정렬되지 않다보니 각자 의사결정과 방향이 제각각으로 가며 점점 산으로 가는 것을 바라보는 형국이었다.

이 모든 것이 서비스의 본질 즉 유저가 어디에서 어떠한 가치를 느끼고 왜 우리 서비스를 이용하는지를 초기에 제대로 파악하고 정의하여 얼라인하지 않았거나 부족했기 때문이다.

이게 생략되면 모두가 열심히 삽질하게 되며 또 나중에 바꾸려면 너무나 큰 힘이 든다. 차라리 모든걸 엎고 다시하는게 낫다. 이런 본질적인 맥락을 팀원 모두가 아주 자세하게 얼라인 하여 하나가 되어 움직이는 것이 매우 중요하다는 것을 이 시점에 깨달았다.

 

또 그래서 PM이 중요하다. 기획으로 팀원 전체를 얼라인시키지 못하면 모두가 쓸데없는 짓을 열심히 하며 제풀에 나가떨어지게 되어버린다.


이 시점에서는 내가 누군가에게 나의 생각과 의도 맥락을 100% 전달하기가 어렵고 리소스가 많이든다고 판단해서 이 때부터 내가 기획을 주도하기 시작했다.

 

 

25.10  - 25.11 (스프린트1): 그룹 스터디

여차저차 1:1스터디를 런칭하고 개발자들이 스스로 스터디를 개설하고 참여하는 그룹 형식의 스터디를 다음 아이템으로 삼게됨.


에자일을 지향하기 위해 프로젝트를 스프린트N으로 네이밍하며 기획의 키를 잡고 와이어프레임과 디스크립션기반으로 개발을 진행하였으나 기획자 디자이너 개발자 이해하는 바가 미묘하게 다르고 또한 내가 첫 기획이다보니 해피/엣지케이스 놓치는 경우가 많아 속도와 의사소통비용이 증가함.

또한 모두 만드는 것, 그중에 자기 파트 산출물 만드는 것에만 집중하지 어떻게 쓰일지 어떻게 알릴지를 고민하며 만드는 사람이 없었고 엉터리같은 결과물이 불쑥 튀어나오는 경우가 많았음.

막히거나 어려우면 가만히 있다던지, 팀 간 미팅을 요청하며 해결할 생각보단 은근한 책임회피로 사일로를 형성한다던지, 소통없이 본인만의 그림을 그리면서 프로젝트를 엉뚱한 방향으로 끌고간다던지, 우선순위를 엉뚱하게 생각하며 팀 속도를 저해한다던지, 일의 결과를 생각하지 않고 본인 맡은 Task 단위로만 생각한다던지.

뭐가 문제인지 답이 안나와 기획자 출신 CEO께 자문을 구하고 PM강의를 들으며 기획역량을 키우고자 하였고, 팀별로 미팅을 늘려 피드백을 주고 받게하며 생각을 정렬코자 하였고 필요한 것들은 문서화를 제대로 해놓고 따로 그로스팀을 만들어 유입과 체류를 고민하는 조직을 빼놓음.

지금 우리가 하는 방식이 에자일이 맞나? 에자일의 본질이 무엇인가에 대해 생각해보게 됨. 에자일의 본질은 팀내부 그리고 고객과의 피드백이라고 결론을 내게됨.


25.12 - 26.1 (스프린트2): 유료스터디

그룹형식의 스터디에 유료결제 기능을 붙여서 서로 신뢰하며 끝까지 진행하는 스터디를 만들고자함.

스프린트1보다는 나았으나 여전히 에러가 많고 단순히 팀원을 늘리거나 팀을 쪼갠다고 속도와 퀄리티가 높아지거나 서비스가 성장하지 않는다는 것을 깨달음.

한두사람만 예상을 빗나가도 팀 전체일정에 영향이 미칠 수 있는 것이 IT프로젝트구나라는 것을 깨달았고, 사람이 많아지면 오히려 리스크가 늘고 또 '팀에 물어볼게요' 한 주 한 주 지나가며 실행속도가 확 느려지는 것을 경험함.

팀규모를 절반이하로 축소하고 프로덕트팀으로 개편하여 기획 아이데이션부터 함께 의견을 내고 얼라인하며 산출물이 아닌 목표를 바라보는 조직으로 개편하고자함.

소규모더라도 도메인에 대한 관심/ 성장의지/ 소통능력 있는 사람끼리 뭉치는 것이 결과물이 좋다는 것을 깨달음.


26.1 - 26.3 (스프린트3,4): 멘토링과 커뮤니티

빌더 한 명이 프로토타입 디자인과 개발까지 진행하는 체제를 실험해봄. 또한 오프라인 미팅을 필수로 두어 최대한 생각을 맞추며 피보팅하며 나아갈 수 있도록 얼라인하고자 하였음.

신년을 맞아 우리의 MVC와 타겟부터 재정의하면서 서비스 대상을 개발자가 아닌 IT에 입문하고자 하는 일반인(바이브코더)으로 리타겟팅하며 1:1멘토링과 커뮤니티를 만들었음.

(1) 온프레미스 서버로 인프라 고정비를 줄이며 자원활용도를 높이고 (2) 프로덕트 개발에서 반복적인 코드작성은 AI를 최대 활용하며 (3)컨텐츠 마케팅 에이전트를 만들어 AI마케팅 시스템을 구축함.

의사소통 비용은 크게 줄었으나 상위챕터에서 합의가 없어 기술/디자인 부채가 쌓이는 것은 아쉬움으로 남았음.

또 우리가 빠른 실험검증을 위해 빌더체제로 개발하며 리소스를 최소화했지만 에러를 다 잡고 공개하려다보니  사용자 활성화까지 공백이 있었고 나 포함 팀원들의  예상치못한 번아웃 리스크를 만났음.

처음 빌더체제를 주장한 팀원이 가장 먼저 힘이 빠졌고, 이 과정에서 방관자가 있으면 오히려 팀원들을  하나로 뭉치게 하지 못하고 더욱 힘들게한다는 점, GTM(시장진입)전략을 스프린트 시작부터 설계해서 마케팅을 개발 끝나고가 아니라 시작부터 들고가면서 fit을 맞추며 가야된다는 점을 깨달음.


26.4 - 26.5 (스프린트5): 바이브코딩 입문자 코스

입문자를 대상으로 피보팅함. 게이미피케이션 기반의 입문자 코스를 만들었음. 

피보팅을 하고 한두달만에 그럴싸한 형태가 갖춰짐. 

 

컨퍼런스도 같이 다녀오고, 얘기하다보면 좋은 아이디어가 나오고, 생각의 해상도가 높아지는 경험을 했다. 

이전에는 팀원들과 얘기하다보면 오히려 힘이 빠지거나, 생각이 분산되기도 했었는데 말이다.

 

AI워크플로우로 전면으로 내세우면서 구현 문제는 해결이 되었음. 팀의 컬쳐핏을 고민해봄. 


1) 프로덕트 역량 (해당 문제로 고통을 겪는 유저에 대해 얼마나 이해하고 공감하는가)

2) 문제해결력과 성장역량 (얼마나 다방면에서 깊이 배우고 도전할 준비가 되어있느냐)

3) 커뮤니케팅션 역량 얼마나 팀의 목표를 잘 이해하며 자신의 상황과 생각을 잘 구조화하여 표현하느냐

 

한동안 고민하던 문제였는데 결국 작은 팀에서는 프로세스와 워크플로우보다 한 사람의 역량과 컬쳐핏이 수십 배 중요하다는게 내 결론이다.

 
 
 

26.6(스프린트6 회고): 바이브코딩 입문자 코스 런칭 준비

 
[혼자서 한 것]
 
LLM wiki를 도입해 프로젝트 컨텍스트를 쌓고 있다. 개인 Wiki를 만들어 로컬 stdio MCP 서버를 열어두고 생각이나 아이디어를 바로 프로젝트에서 가져갈 수 있도록해서 정보관리의 효율성을 높이고 있다.
 
WSL2위에서 가상화하다보니 불안정한 부분들이 있어서 온프레미스 서버를 ProxmoxOS로 베어메탈위에서 전가상화시켰다.
 
마케팅 에이전트를 안정화시키면서 컨텐츠 OSMU를 시작중. 
 
 
[팀에서 한 것]
 
바로 온라인 입문자코스를 유저에게 오픈하면 테스트가 어렵다고 판단해 (아직 데이터나 후기 등으로 증명된 것이 없으므로) 제로테스트를 제안했다. 수강한 유저들에게 보상을 주어 꼼꼼한 피드백을 받는 것.
 
또한 온라인 기반으로 한 테스트 수집은 현장에 못미친다고 판단해 주말 바이브코딩 원데이 세미나를 열어 실시간 학습 데이터를 체크하고 플랫폼 콜드스타트 문제를 해결하고자 하였다. 
 
본 코스 이외에 커뮤니티나 인사이트 등의 컨텐츠를 통해 리텐션을 높이고 고객 메일링을 통해 잠재고객으로 묶어두는 작업을 세웠다.
 
나는 수업자료에 집중하며 내용 가독성을 다듬고 테스터를 모집하고 운영하는 작업에 대한 작업은 팀원들에게 부탁했다.

그러나 미온적이거나, 현재 중요하지 않는 작업에 몰두하며 우선순위를 배분을 못하거나, 대충 AI 결과물을 가져와서 피드백달라는 모습을 보고 확신을 느꼈다.
 
지금 더이상 나아가기 힘든 구조다.
 
 
[1년 반 최종 결정]
 
1년 반이상 정말 많은 시도를 했다.
 
- 무작정 기다려도 봤고, 마이크로 매니징도 해봤고, 한없이 잘해줘도 봤고, 무뚝뚝하고 퉁명스럽게도 해봤다.
 
- 디테일하게 직접 문서화도 해봤고, LLM WIKI도 도입해봤고, 미팅 방법이나 주기를 바꾸고, 대면 모임을 강제하고, 밋업이나 단체복을 통해 소속감을 높이려고도 해봤고, 스쿼드를 나눠도 봤고, 단체로 일장 연설을 하기도 했고, 한 명씩 상담하면서 고충을 들어도 보았다.
 
- AI 워크플로우를 도입하며 앞으로 무엇에 집중해야할지 설득했고, 프로덕트 스테이지 별로 어떤 것에 포커스를 둬야하는지, 기획디자인은 문서가 아니라 실제로 유저가치가 중요하며, 엔지니어링은 주먹구구식 에이전트 코딩이 아니라 학습과 기술적 판단이 중요하다는 것을 수없이 전달했다.
 
이제는 결론을 낸다. 이 조직은 안된다.
 
 
원인 종합 분석 : PMF 발견 이전의, 컬쳐핏이 안맞는 사람들과, 책임의무 강하지 않은 비대면작업
 
매일매일 만나서 얘기하고 실행하고 점검해도 모자랄 판에 공허한 미래가치만 약속하며 주간 1~2회 미팅으로는 사람들의 집중도를 유지하기 어렵다. 
 
확실하게 돈주고 출근시켜서 안하면 의무를 걸어 관리하는 직원이거나, 같이 공동 투자해서 프로젝트의 성공이 본인의 미래와 연결되는 공동창업자여야지 이도저도 아닌 상황은 그냥 대학 조별과제 수준의 참여도이상을 만들어낼 수가 없다.
 
또한 기본적으로 인간의 본질을 넘겨짚고 나와 비슷하겠거니 했다. 성실도, 판단능력, 학습능력은 각자 천차만별인데 믿고 문서화하고 가시화시키면 각자 잠재력을 발휘할 것이라고 생각했다. 
 
더구나 대부분 취준생/주니어 관점에서 알고 경험한 것이 적은데 내가 진심을 가지고 대하며 비젼을 보여주면 사람들이 다 나처럼 깨지고 부셔져가면서 매순간 성장하며 발전할 것이라는게 내가 굉장히 오만한 생각이었다.
 

더보기

<이제서야 말하는 속풀이>


기획 : 비젼과 디테일한 얘기 다 납득시키면 그제서야 노션 문서정돈 정도나 하지 직접 유저리서치나 벤치마킹 등을 통해서 고객과 비지니스를 이해하며 서비스의 성공을 기획하는 사람을 못만났다. 사업 감각이라는 것을 찾기가 어려웠다.

디자인 : 와이어프레임이나 기획문서 다 정의된 상태에서 이쁘게 만드는데에 집중, 유저가치를 생각하면서 소통을 통해 '되는 디자인'을 하려는 사람을 만나기 어려웠음. 

개발 : 데드라인을 줘도 안지키며 'API가 안되어서요' 변명을 늘어놓고 상황공유가 안되는게 태반. AI워크플로우 도입을 제안하기 위해서 혼자 
앤트로픽 코스 300개정도를 들으면서 이거 진짜 꼭 공부해야한다고 공유를 해도 이모지나 누르지 제대로 알면서 에이전틱 코딩을 하려는 사람이 드물었음. 화면이 느리거나 서버가 다운됐다면 패킷분석을 하거나 운영체제 관점에서 생각해보며 문제를 해결하지는 않고 그냥 '그러게요ㅠ 안되네요ㅠ' 넘어가거나 AI돌려서 얼버무리는 경우가 태반.

마케팅 : 문서 정리나 정의에 1개월 이상 쓰며 정작 실행은 0. 돈주고 돌리는 퍼포먼스 마케팅 외에 SEO, 바이럴, 컨텐츠 등등에 대한 종합적인 유저 획득과 리텐션에 대한 고민을 하는 모습을 못봄.

 
 

26.7(스프린트7): 솔로프리너 전환 

 
그냥 혼자한다. PMF 찾기 전까진 혼자할거고 아마 충분한 매출을 달성해도 일손을 덜어줄 파트타임 직원 아니면 같이 하지 않을 것 같다.
 
내 강점 중 하나가 아이디어와 후킹 그리고 실행력이다. 에이전트한테 100만원 정도 쓴다는 생각으로 투자하며 아이템 생각나는대로 바로 시장에 던지고 알리고 깎아나간다.
 
유일하게 디자인이 내가 자신없는 부분이었는데 이제 스킬 잘 찾아서 서브에이전트 장착하니 그전에 만났던 3~10년차 디자이너 정도 퍼포먼스는 충분히 내는듯하다.
 
Network/OS/DB를 좀 더 깊이 파면서 유저 규모가 스케일업되어도 혼자 컨트롤할 수 있는 내공을 쌓아간다. 
 
 
 
본 프로젝트 같은 경우에는 그냥 예정대로 오프라인 세미나를 통해 로컬 기반의 소규모 학습 커뮤니티부터 시작하려고 한다.
 
당분간은 내 개인기로 사람들을 가르치고 교육가치를 제공하면서 그들의 니즈를 찾아서 기능을 만들고 컨텐츠를 만들어간다는 생각.
 
항상 팀원들 설득하고, 증명하고, 동기부여해야한다는 무거운 부담이 있었는데 마음이 너무 가볍고 앞으로가 기대가 된다.
 
 
 
내가 큰 사업을 하는 것도 아니고 그냥 월에 천정도 만들어내는 정도 수준은 누구나 다 할 수 있다 생각했는데 고객니즈를 보고 영업하고 마케팅하며 아이템기획하는게 굉장히 드문 능력이라는 것을 알게 되며 한층 더 자신감이 생겼다.
 
한편 1년 반동안 나에게 기획~디자인~개발~운영~마케팅 전반적인 간접 실무 경험을 가져다 준 팀원들에게 고맙고 언젠간 다시만나 도움을 줄 수 있는 존재로 고속성장할 것임을 다짐해본다.