지난 5월 27일과 6월 10일, 요즘IT는 '클코나잇 2' 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 "고수의 경험을 나눠 받을 수 있는 기회", "찐 실무자의 현장감 넘치는 사례", "다음에 또 오고 싶은 웨비나" 등의 반응을 보였습니다. 이번 글에서는 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

클코나잇 2 웨비나의 두 번째 발표였던 '1인 빌더가 9개 프로젝트를 Claude Code로 동시 운영하는 법'입니다. 발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요. 클코나잇 시즌 2 발표를 맡은 김상욱입니다. 오늘 저는 '1인 빌더가 9개 프로젝트를 클로드 코드로 동시에 운영하는 법'을 이야기하려고 합니다. 어쩌다 혼자서 아홉 개나 되는 프로젝트를 동시에 굴리게 됐는지, 그 배경부터 살펴보겠습니다.

백엔드 개발자가 해고 뒤 클로드 코드를 켜기까지

저는 작년 1월, 한 스타트업에 백엔드 개발자로 입사했습니다. 그런데 프론트엔드 채용이 안 돼서, 결국 프론트엔드 업무까지 혼자 다 맡게 됐습니다. 그때는 커서(Cursor)로 개발했는데, 처음으로 플러터(Flutter)를 써서 IoT 앱도 만들어 봤습니다. 쉽진 않았지만 강의를 보며 따라 만들다 보니, 한 가지 확신이 생겼는데요. AI와 함께라면 혼자서도 프로젝트 하나는 충분히 굴릴 수 있겠다는 확신이었습니다.

그렇게 업무에 막 익숙해지던 차에, 갑작스럽게 해고됐습니다. 당황스러웠지만, 제 앞에는 두 갈래 길이 있었습니다. 다시 취업 준비를 하거나, 뭐라도 혼자 만들어 보거나였죠. 저는 후자를 선택했고, 그때 처음 클로드 코드를 켰습니다. 올해 2월의 일입니다.

혼자서 해보니 개발에서의 차이는 곧바로 드러났습니다. 작년만 해도 프론트엔드·백엔드를 오가며 MVP 하나를 만드는 데 보통은 1~2주, 길게는 3~4주를 잡았는데요. 그런데 클로드 코드를 쓰기 시작하니 MVP가 단 몇 시간 만에 나오기 시작했습니다. 그러헥 신이 나서 프로젝트를 계속 찍어냈죠. 그런데 진짜 문제는 그 다음에 벌어졌습니다.

빠르게 만들수록 빠르게 무너졌다: '9개의 폐허'

만드는 속도가 빨라지자 손에 쥔 프로젝트가 순식간에 아홉 개로 불어났습니다. 이 중 일부는 도메인을 띄워 실제로 운영 중인 것들입니다.

대표적인 사례 몇 개만 소개해 보겠습니다.

클래스코인(ClassCoin): 초등학교 학급 경영 관리 서비스로, 2024년부터 초등 교사인 지인과 함께 만들어 운영하고 있습니다.
패티션(petition): 진정서를 자동으로 작성해 주는 서비스인데요. 제가 해고되며 직접 진정서를 쓰게 됐는데, 여러 AI를 번갈아 쓰며 작성하다 보니 관리도, 작성 자체도 까다로웠습니다. 이 경험이 정리돼 있으면 누군가에게 도움이 되겠다 싶어 만들었습니다. 여기엔 RAG(검색 증강 생성)로 법률 정보를 끌어왔는데, 프론트엔드·백엔드를 합쳐 쓸 만한 서비스를 만드는 데 사흘밖에 걸리지 않았습니다. 이때 클로드 코드의 가능성이 정말 무궁무진하다고 느꼈죠.
던전 버디(dungeon-buddy): '데스크톱 컴패니언'이라는 새 장르의 게임입니다. 방치형 RPG로 만들어 스팀(Steam)에 출시도 해 봤습니다.
바바리안(barbarian): 웹소설 '게임 속 바바리안으로 살아남기'의 팬 위키입니다. 주인공의 성장 스토리를 정리하면 재밌겠다 싶어 만들었는데, 팬들 반응이 좋아서 이를 기반으로 게임까지 만들어 운영하게 됐습니다.

문제는 MVP까지는 순식간인데 막상 운영을 시작하면, 고도화해야 할 것이 끝없이 쏟아진다는 점이었습니다. 그러면서 세 가지 통증이 한꺼번에 터졌죠.

"내가 어디까지 했더라?" - 세션을 켤 때마다 진행 상황을 다시 더듬어야 했습니다.
같은 지시를 매번 다시 입력 - 예를 들어, 게임 스프라이트를 만들 때 "스프라이트는 이렇게 만들어 줘" 같은 지시를 프로젝트마다 반복해야 했습니다.
같은 실수를 반복 - 어제 바로잡은 실수를 오늘 또 저지르곤 했습니다.

이걸 가장 아프게 확인시켜 준 사례가 바로 '톡비서'였습니다. 가장 먼저 상용화에 도전한 프로젝트인데요. 카카오톡과 연동한 1:1 AI 비서였습니다. 당시 채팅 기반 AI 에이전트 서비스가 흥행하기 시작했는데, 텔레그램이나 왓츠앱(WhatsApp)은 비전공자가 쓰기엔 진입 장벽이 있다고 봤습니다. 그래서 우리에게 더 친숙한 카카오톡과 연동하면, 일반 사용자가 쉽게 쓰지 않을까 싶었고요.

다만 카카오톡은 텔레그램·왓츠앱과 구조가 많이 달라, 에이전트를 만드는 것도 쓰는 것도 진입 장벽이 있더군요. 만들어 둔 게 아까워서, 스토어 기반 서비스와 일대일로 연동해 스토어에 들어오는 FAQ를 1인 사업자가 쉽게 세팅할 수 있도록 방향을 틀었습니다. 기획하고 MVP를 만들어, 직접 상가를 찾아가 사장님들과 미팅하며 한 건 계약까지 했고요.

하지만 결국 접었습니다. 여러 개를 만드는 건 쉬운데, 여러 개를 영업하고 파는 건 전혀 다른 일이었거든요. 만드는 건 클로드가 해 줬지만, 파는 건 결국 제 몫이었습니다. 아홉 개를 동시에 만들면서 아홉 개를 동시에 영업할 수는 없었죠. 그때 깨달았습니다. “만드는 건 쉬워졌지만, 여기서 끝이 아니구나.”라는 사실을요.

한 사람이 13개 프로젝트를 굴리려면: 다섯 가지 장치

저는 만드는 일보다 운영하는 일이 더 어렵다는 걸 깨닫고, 이를 하나씩 시스템으로 해결하기 시작했습니다. 지금 저는 혼자서 한 컴퓨터로, 13개의 프로젝트를 굴리고 있습니다. 그 바탕이 된 다섯 가지 장치를 소개합니다.

① 중앙 허브 한 장: home/CLAUDE.md

가장 먼저 모든 프로젝트의 목차와 공용 워크플로우를 한 문서에 담았습니다. home 디렉터리에 둔 CLAUDE.md입니다. 진행 중인 프로젝트마다 설명을 충분히 달아 두고, 태스크는 어떻게 관리할지, 리서치나 아이디어 검증은 어떤 절차로 할지를 마크다운에 적어 하나씩 정리해 나갔습니다. 어느 프로젝트로 들어가든 클로드가 이 파일을 가장 먼저 읽기 때문에, 매번 맥락을 처음부터 설명할 필요가 없어집니다.

② 핸드오프: 세션 전환 비용을 0으로

"어디까지 했더라"라는 통증은 핸드오프(Handoff) 시스템으로 해결했습니다. 세션을 끝낼 때 '핸드오프'라고 한마디만 치면, 클로드가 HANDOFF.md에 오늘 한 일·현재 상태·다음에 할 일을 정리해 둡니다. 다음 세션을 켜면 그 파일을 자동으로 읽고 곧장 이어서 작업하죠.

이게 중요한 이유는 따로 있습니다. 맥락을 압축하는 컴팩트(/compact)를 쓰면 정리되는 내용이 워낙 길어 세션이 멈춰 있는 시간이 길어지고, 저는 바바리안 같은 프로젝트는 같은 터미널 세션을 한 번에 세 개씩 동시에 켜기도 하거든요. 핸드오프 덕분에 이 프로젝트 전환 비용이 거의 0에 가깝게 줄었습니다.

핸드오프의 사용법(규칙)을 CLAUDE.md에 적어두면 클로드가 매 세션 그대로 따릅니다.

③ 병렬은 클로드가 알아서

동시에 여러 개를 굴리는 일도 한결 가벼워졌습니다. 예전에는 tmux 멀티세션으로 기획자·프론트엔드·백엔드 에이전트를 따로 띄워 병렬로 작업했는데요. 어떤 에이전트가 무슨 일을 하는지 눈으로 확인하고 싶었기 때문입니다. 그런데 이제는 작업 방식이 어느 정도 보편화돼서, 굳이 멀티세션을 쓰지 않고 한 세션에서 그냥 던져두면 백그라운드로 알아서 돌아갑니다.

④ 스킬: 만든 것 + 받아서 쓰는 것

"같은 지시를 매번 다시 입력하는" 병목은 스킬(Skill)로 풀었습니다. 멘토 스킬, 리서치 스킬, 이사회(board of advisors)처럼 에이전트로 구성한 스킬을 특히 많이 썼죠. 외부에서 유명하다는 스킬도 받아서 써 봤는데, 어떤 건 큰 도움이 됐고 어떤 건 너무 무거워 오히려 방해되기도 했습니다.

회사에서 일할 때는 CI/CD를 직접 구축해야 해서 깃허브 액션이나 젠킨스(Jenkins)로 세팅하곤 했는데요. 지금은 그런 일도 배포(deploy) 스킬 하나를 만들어 간단히 처리합니다. 필요할 때마다 원하는 스킬을 만들어 쓰는 셈이죠.

⑤ 메모리: 같은 실수를 반복하지 않도록

같은 실수를 반복하는 건 메모리로 막았습니다. 우선 제가 하는 프로젝트에 대한 정보를 클로드에게 충분히 주입했습니다. 프로젝트에서 중요하게 보는 것, 잊으면 안 되는 것은 무조건 메모리에 기억하게 했더니, 자주 되풀이되던 실수가 눈에 띄게 줄었습니다.

지금은 이렇게 씁니다: 한 주에 2개만 집중

지금의 작업 방식은 꽤 단순합니다. 백로그(backlog)를 정리해 그 주에 할 일을 정하고, 집중할 프로젝트 두 개를 고릅니다. 세션을 켤 때는 핸드오프를 먼저 읽고 시작하며, 끝낼 때는 핸드오프를 갱신하며 마무리합니다.

여기서 발표 이후에 살짝 업데이트된 내용이 있다면, 발표 땐 루틴을 수동으로 돌렸지만, 지금은 /schedule로 "매주 월요일 아침 backlog 정리" 같은 작업을 클라우드 크론으로 예약해 둡니다. 덕분에 자리에 없어도 자동으로 실행할 수 있죠. (세션을 켜둔 채 반복시키는 /loop과는 별개입니다.)

그렇다면 왜 프로젝트를 두 개로 제한할까요? 여러 프로젝트를 운영에 올리고 CS까지 받으며 굴려 보니, 사람이 풀스택으로 한 서비스를 끌고 가는 것만으로도 버거웠습니다. AI의 도움을 받아도 운영까지 동시에 감당하는 데는 분명한 한계가 있었죠. 아홉 개를 한꺼번에 굴렸더니 어느 것도 진전이 없었거든요. 그래서 한 주에 진짜로 손대는 건 두 개까지로 못 박고, 나머지는 동결했습니다.

실제 운영 사례도 살펴볼게요. 클래스코인은 버셀(Vercel) 애널리틱스로 보면, 초등 교사 80명 정도가 사용하고, 교사당 학생이 20명쯤이니 약 1천 명 이상이 쓰는 서비스입니다. 방문자 수가 폭발적이진 않지만, 작년부터 이어 온 이 프로젝트에 클로드 코드를 도입하자 기능 추가와 개선 속도가 확연히 빨라졌습니다. 저는 비전공자인 형과 함께하다 보니 소통이 매끄럽지 않을 때가 많았는데요. 이런 간극도 클로드 코드가 많이 메워줬습니다.

다음으로 바바리안 게임의 경우, 고도(Godot) 엔진으로 처음 만들어 본 프로젝트입니다. 오픈하고 한 달 동안 약 4만 7천 회 조회에 2만 9천여 회 플레이됐고, 거의 매일 업데이트하며 하루에 열 개씩 배포하고 있습니다.

이렇게 활발하게 굴러가는 프로젝트에는 공통점이 하나 있습니다. 바로 오픈채팅으로 건의를 받아, 곧바로 반영한다는 점인데요. 팬 커뮤니티를 만들어 유저들이 원하는 방향과 건의를 받고, 즉시 업데이트해 주니, 유저분들도 훨씬 재밌어하고 좋아하시더라고요.

프로젝트 9개를 굴린 진짜 이유는 ‘도구’가 아니다

여러 프로젝트를 거치며 제가 내린 결론은 이렇습니다. 아홉 개를 동시에 굴릴 수 있게 된 진짜 이유는 클로드 코드가 다 해줬기 때문이 아닙니다. 사실 허브, 핸드오프, 병렬, 스킬, 메모리 같은 장치는 마음만 먹으면 누구나 금방 따라 만들 수 있으니까요.

정작 중요한 건 AI와 친숙해지는 과정, 즉 클로드를 동료처럼 다루는 일입니다. 잘 못하면 알려주고, 잘하면 칭찬하며 다음에도 그렇게 해 달라고 말하고, 같은 실수를 반복하면 메모리나 마크다운 파일로 줘서 다시는 그러지 않게 다잡습니다. 마치 사람을 대하듯 다루는 거죠.

작업을 시킬 때도 마찬가지입니다. AI에게 "이거 해 줘"라고 정답을 던지면, 딱 그 정답만큼만 돌아옵니다. 그래서 저는 정답 대신 제가 가진 고민과 배경, 컨텍스트를 전부 풀어 놓습니다. 그러고는 "이건 아닌 것 같다", "다른 방법은 없을까?" 하며 브레인스토밍하듯 함께 답을 찾습니다. 그러면 제가 미처 생각하지 못한 답이 돌아옵니다.

예전에는 새 프로젝트를 시작하거나, 새 언어를 배울 때 늘 책을 사고 강의부터 들었는데요. 이번에 고도 엔진을 쓸 때는 강의도 책도 없이 맨땅에서 시작했습니다. 모르는 건 클로드에게 묻고, 더 나은 방법이 있는지도 체크하며 진행했죠.

그래서 마지막으로 제가 드리고 싶은 말은 하나입니다. “AI에게 정답을 주지 말고, 가진 컨텍스트를 다 풀어 놓은 다음에 같이 답을 찾으세요.”라는 거죠. 발표 들어주셔서 감사합니다.