프롤로그
4주 동안 무언가를 만들어본 사람들이 모였다.
어떤 사람은 사주 앱을 세 번 뜯어고쳤고, 어떤 사람은 음성 다이어리를 만들다가 비용이 연 55만원이 나올 것을 발견하고 89% 줄였다. 어떤 사람은 파이프라인을 만드는 파이프라인을 만들려다 세 번 엎었고, 어떤 사람은 교회 번역 봉사팀을 위한 대시보드를 점심시간마다 조금씩 만들었다.
이날 베스트 발표자는 라멘님이었다. 스터디가 끝나고 "준비하겠습니다"라고 했지만 준비할 것은 없었다. 이미 충분했다.
1. 에보시님 — 초보가 회사 시스템을 만들다
에보시님은 회사 대표다. 그런데 이번에 직접 서비스를 만들었다. AI를 안 쓰는 직원들에게 "이 정도 되는 사람도 만들 수 있다"는 것을 보여주기 위해서.
구현한 것들: Sign up, 어드민 권한, Search 기능. 구현하려다 멈춘 것들: 유저 매니지먼트, 페이지 이탈 시 자동 로그아웃. 리미트에 계속 걸렸다.
스터디장님이 E2E 테스트를 제안했다.
"유저 플로우 작성 → 기능 체크 → 빠진 것 리포트. Claude Code에 '이 서비스의 타겟 유저 기준으로 E2E 테스트해서 빠진 기능 체크해줘'라고 하면 된다."
로그아웃 버튼이 없으면 AI가 "로그아웃이 없는데요?" 하고 찾아준다. 사람이 미처 못 본 것을 AI가 본다.
클린 아키텍처 강의를 들었다. 어렵게 들렸지만 핵심은 간단했다. A를 고쳤을 때 B가 망가지지 않게 만드는 것. 초보에게 당장 필요하진 않지만, 나중에 서비스가 자꾸 망가지기 시작하면 그때 검토하라고 했다.
원샷 인사이트 #1
에보시님이 직원들을 위해 만들었다는 말이 기억에 남는다.
나도 마찬가지다. 내가 쓰는 것을 만들 때 다른 사람에게도 보여줄 수 있는 것이 된다. 단순히 도구가 아니라 증거가 된다.
E2E 테스트는 나도 당장 써볼 수 있다. "지금까지 만든 시스템에서 내가 놓친 기능이 있는지 유저 플로우로 체크해줘." 이 명령 하나로 내가 미처 생각 못 한 빈틈을 찾을 수 있다.
2. 강지인님 — PRD 700줄이 모든 것을 바꿨다
처음 만든 사주 앱이 마음에 안 들었다. "이걸로 돈은 못 벌겠다"는 생각이 들었다. 다시 만들기로 했다. 단, 이번엔 다르게.
코드부터 시작하지 않았다. 기획부터 했다.
Claude 채팅으로 경쟁사 5개를 분석했다. 990원 서비스들이 왜 잘 팔리는지, 왜 까이는지, 사람들이 어떤 점을 아쉬워하는지를 수집했다. 그리고 PRD를 썼다. 700줄.
디자인은 pencil.dev로 3가지 버전을 만들었다. 밝은 버전, 어두운 버전, 고급진 버전. 핀터레스트에서 레퍼런스를 가져와 PRD에 넣었다. 그 PRD를 bkit에 던졌다.
"PRD가 완벽하다고 얘가 생각했던 것 같아요. 딱히 질문이 없었어요."
보통 짧게 던지면 AI가 질문을 많이 한다. 어떤 기능이 필요해요? 범위는 어디까지예요? 그런 질문이 없었다. PRD가 이미 다 담고 있었기 때문이다.
시장조사도 AI로 했다. CEO, 디자이너, 마케터, 개발자 4가지 관점에서 보고서 5개가 자동으로 나왔다. 한 달에 200만원 벌려면 DAU, MAU가 얼마여야 하는지까지 계산해줬다.
결제는 아직 고민 중이다. 사업자가 있어야 카카오페이, 네이버페이를 붙일 수 있다. 사업자 없이 테스트하려면 레몬스퀴즈라는 해외 서비스를 쓸 수 있다고 했다. 수수료가 높지만, 결제가 실제로 일어나는지 먼저 확인하고 사업자를 내도 된다.
원샷 인사이트 #2
핵심은 PRD 700줄이다.
처음 한 줄로 던지면 AI는 질문을 50개 한다. 내가 이미 대답을 다 담아서 던지면 AI는 바로 만든다. 요청의 품질이 결과의 품질을 결정한다.
강지인님이 한 것 중에 특히 인상적인 것은 CEO/디자이너/마케터/개발자 4 페르소나로 시장조사를 시킨 것이다. 혼자서 4명의 관점을 갖는 것. AI에게 역할을 주면 그 역할의 관점으로 분석해준다. 내가 Claude Code에 스킬 파일을 만들 때 역할 설정을 더 구체화해볼 것이다.
3. 라멘님 — 4년치 기록이 AI 코치가 됐다
베스트 발표자
라멘 님은 4년 동안 엑셀을 썼다. 40개 컬럼, 단백질 섭취량, 칼로리, 수면 시간, 운동, 감사일기, 명상, 읽은 책... 매일 채워왔다.
이것을 AI 다이어리로 만들었다.
텔레그램에 말을 하면 Whisper가 전사하고, AI가 분류해서 구글 시트에 기록한다. 이미지를 올리면 GPT-4가 분석한다. 하루가 끝나면 AI가 오늘을 요약하고 패턴을 찾아서 조언해준다.
이런 피드백이 왔다.
"일요일 오후 MIT 절반도 못 건드렸는데 이 흐름이 오늘의 계획대로 회복될 거라고 보고 있나요?"
뜨끔했다고 했다. AI가 내 하루를 알고 있다. 그리고 나를 코치한다.
그런데 비용을 계산해봤더니 연 55만원이 나왔다. 혼자 쓰는 서비스에 연 55만원. 원인은 Claude Opus를 매번 쓴 것이었다. 비용의 90%가 Opus였다.
Sonnet으로 전환하고, 하루 1번 요약으로 제한하고, 품질이 덜 중요한 곳은 GPT-4로 바꿨다. 89~98% 절감했다.
그리고 코드를 뜯었다. 수민님의 3계층 구조 강의를 들은 후, Claude Code에 TRD(기술 요구사항 문서)를 작성하게 했다. Claude Code가 "현재 코드는 3레이어 구조가 아니다. 대규모 리팩토링이 필요하다"고 했다.
회사에서 개발자에게 이 말을 들으면 긴장된다. 몇 달이 걸린다는 뜻이니까. 그런데 Claude Code에게 "지금 해봐"라고 하니까 오래 걸리지 않았다.
CLAUDE.md에 역할을 넣었더니 달라졌다.
"너는 시니어 소프트웨어 개발자다. CTO다."
이 한 줄 추가로 AI의 접근 방식이 바뀌었다고 했다. "영혼이 달라졌다"는 표현을 썼다.
원샷 인사이트 #3
세 가지를 배웠다.
첫째, 비용 추정을 먼저 하라. 만들기 전에 "이 구조로 한 달에 비용이 얼마 나오는지 추정해줘"라고 물어보는 것. 나는 Claude Code를 쓰면서 비용을 신경 쓴 적이 거의 없다. 라멘님처럼 먼저 계산해보는 것이 필요하다.
둘째, CLAUDE.md에 역할을 주라. "너는 시니어 개발자다"라는 한 줄이 AI의 접근 방식을 바꾼다. 나의 CLAUDE.md에는 어떤 역할이 있는지 확인해볼 것이다.
셋째, 버그가 나면 재발 방지 보고서를 쓰게 하라. "원인 분석하고 재발 방지 방안을 CLAUDE.md에 추가해줘." 이것이 쌓이면 시스템이 학습한다.
4. 민지님 — 점심시간마다 조금씩, 팀을 위한 도구
민지님은 교회에서 번역 봉사를 한다. 한국어 영상을 영어로 번역하는 일이다. 수작업으로 진행되던 모든 과정을 자동화하겠다고 마음먹었다.
Google Docs 링크를 넣으면 자막이 추출되고, 번역되고, 팀원에게 이메일이 가고, 대시보드에서 교정 현황을 관리할 수 있다. 계정은 3종류다. 관 리자, 팀장, 팀원. 각자 볼 수 있는 것과 할 수 있는 것이 다르다.
점심시간마다 짬짬이 만들었다. 회사 컴퓨터에서, 점심시간에.
한계가 하나 있다. Whisper가 로컬 서버에서만 돌아서 컴퓨터를 끄면 서버도 꺼진다. 24시간 운영이 안 된다. 그래서 대시보드에 서버 운영 시간을 표시해뒀다.
스터디장님이 해결책을 제안했다. 서버리스 Lambda. 요청이 있을 때만 서버가 켜지고, 끝나면 꺼진다. Claude Code에 "Lambda로 띄워달라"고 하면 구현 가능하다고 했다.
팀원들 반응은 어땠을까. "번역이 빨리 된다. 자막 추출도 잘 된다. 신기하다." 팀장 선생님도 기대감을 표했다.
원샷 인사이트 #4
민지님이 보여준 것은 기술이 아니라 배려다.
팀원 계정에서는 번역 실행 버튼이 안 보인다. 팀원이 실수로 잘못 누르면 안 되니까. 각 컬럼에 마우스를 올리면 설명이 나온다. 처음 쓰는 사람이 헤매지 않도록.
사용자를 생각하며 만든 것이 보인다.
나도 스킬 파일이나 CMDS 가이드를 만들 때 "이걸 처음 보는 사람이 읽으면 이해할 수 있는가"를 기준으로 다듬어볼 것이다.
5. 아루나님 — 3번 엎어서 얻은 것
아루나님은 파이프라인을 만드는 파이프라인을 만들려고 했다.
bkit의 개발 9단계 파이프라인이 있다. 도메인을 몰라도 따라가면 결과가 나오는 구조가 좋았다. 이것처럼 어떤 도메인이든 적용할 수 있는 파이프라인을 자동으로 만들어주는 메타 파이프라인을 원했다.
그런데 막혔다.
깨달음 1: 파이프라인은 컨베이어벨트가 아니다.
"넣으면 뽕 하고 나오길 바랐어 요. 그렇게 안 됩니다."
bkit 개발 파이프라인도 단계를 따른다고 결과가 자동으로 나오지 않는다. N8N, Make도 노드를 연결해 놓는다고 되는 게 아니다. 노드 하나하나마다 API 연결, OAuth 설정을 해줘야 한다. 껍데기와 실제 동작은 다르다.
깨달음 2: 파이프라인이 길면 결과를 예측할 수 없다.
9단계를 다 돌리고 나서야 결과가 나온다. 마음에 안 들면 처음부터 깎아야 한다. 지난하다.
그래서 방향을 바꿨다. 지피터스 학습 툴이 사례를 따라하기 방식으로 가르치는 것처럼, 작은 단위로 테스트하면서 연결하는 방식으로.
세 번을 엎었지만 얻은 것이 있다. 자동화의 한계와 가이드의 가치, 그리고 작은 단위로 검증하는 방법.
원샷 인사이트 #5
아루나님의 3번 엎기가 사실 가장 솔직한 이야기였다.
잘 만든 것을 발표하기는 쉽다. 세 번 실패한 과정을 발표하기는 어렵다. 그리고 그 과정에서 배운 것이 더 깊다.
나도 어떤 작업을 "한 번에 완성하자"고 설계한 적이 많다. 아루나님의 말이 맞다. 작은 단위로 테스트하고, 결과를 확인하고, 연결하는 방식이 더 빠른 길이다.
한 번에 너무 크게 설계하지 말 것. 작동하는 가장 작은 단위부터.
6. 바이브로님 — 4명의 AI가 제안서를 함께 쓴다
바이브로님은 제안서 작성에 1~2주가 걸리는 것이 아깝다고 생각했다. AI 에이전트 4개로 그 과정을 단축시키려 했다.
PM, 디자이너, 마케터, 개발자. 각 역할을 가진 에이전트가 각자의 관점에서 기여하고, 통합된 제안서가 나온다.
팀장들에게 테스트했을 때 첫 반응은 이랬다. "우리 자르려고 하 는 거냐?"
아니었다. 오히려 반대다. AI가 사람을 대체하는 게 아니라, AI를 잘 쓰는 사람이 그렇지 않은 사람보다 더 많은 일을 해낸다.
전자책 작가님의 사례에서 영감을 받았다. 작가 14명의 페르소나를 디테일하게 만들었더니 AI 감지 테스트에서 "AI가 쓴 것이 아니다"라는 판정이 나왔다. 페르소나가 구체적일수록 결과가 달라진다.
4주 소감으로 이 말을 했다.
"처음엔 너무 어렵게 시작했는데, 겁이 없어졌어요. 일단 기획안 만들고 터미널 열어서 시작해보는 게 자연스러워졌어요."
원샷 인사이트 #6
"겁이 없어졌다"는 말이 가장 인상적이었다.
기술을 배운 게 아니라 태도가 바뀐 것이다. 머릿속에만 있던 아이디어가 "일단 해볼까?"로 바뀌는 것. 그게 4주가 준 가장 큰 것이다.
페르소나 아이디어는 바로 적용할 수 있다. 글을 쓸 때 "독자 A, 독자 B, 독자 C 관점에서 각각 어떤 점이 와닿는지 피드백해줘"라고 물어보는 것. 내 글을 다각도로 검토받는 방법이다.
7. Ssuv님 — 분석 코드를 모든 사람이 쓸 수 있게
Ssuv님은 임상 데이터 분석을 한다. 분석 코드는 있는데, 매번 돌리는 과정이 번거로웠다. 이것을 웹으로 만들어서 누구나 파일을 올리고 분석 결과를 받을 수 있게 하고 싶었다.
Vercel 없이 Supabase와 Shiny만으로 구현했다. Gemini 2.0 Flash로 계속 막혔었는데, Gemini 2.5로 전환하니 작동했다. "자그마한 대성공"이라고 했다.
발표 당일에는 토큰이 부족해서 데모가 안 됐다. 밤 11시에 리셋된다고 했다. 그럼에도 과정을 설명했다.
"제가 너무 초보이기도 하고, 다른 분들 발표는 참 화려하다는 생각도 많이 했습니다. 그래도 만족하면서 계속 공부해 보겠습니다."
원샷 인사이트 #7
화려하지 않아도 괜찮다.
전문 분야가 있고, 그 분야의 반복적인 작업을 자동화했다. 그것이 서비스다. 멋진 UI가 없어도, 데모가 안 돼도, 내 문제를 해결하는 도구를 만든 것 자체가 의미가 있다.
나도 내가 매일 하는 반복 작업을 떠올려봐야 한다. 꿈기록 분류, 주간요약 작성, 사례게시글 저장. 이것들을 하나씩 자동화하는 것이 나의 프로젝트다.
에필로그 — 4주가 남긴 것
스터디장님이 마지막에 말했다.
"여기서 하셨던 것들이 완성된 것도 있고, 완성되지 않은 것도 있는데 이게 완성될 때까지 계속 서포트해드리고 싶습니다."
7명 중에 완성된 서비스를 배포한 사람도 있고, 세 번 엎은 사람도 있고, 데모가 안 된 사람도 있다.
그런데 4주 전과 비교하면 모두 달라졌다. 터미널이 무섭지 않아졌고, PRD를 먼저 쓰게 됐고, AI에게 역할을 주는 방법을 알게 됐고, 비용을 계산하는 습관이 생겼다.
만드는 것보다 기획이 먼저라는 것도 배웠다. 700줄 PRD가 AI에게 질문할 여지를 없앴다.
완성이 목표가 아니었다. 만드는 사람이 되는 것이 목표였다.
