아마 개발 지식과 상관없이 뚝딱 짜주는 코드 때문일 수도 있고, 복잡한 작업을 대신 처리해주는 편리함 때문일 수도 있습니다. 그런데 실제로 클로드 코드를 오래 써온 분들에게 물어보면, 답은 조금 다른 곳에서 나옵니다. 이 도구가 좋은 진짜 이유는, 쓰는 사람마다 자기 방식대로 "길들일" 수 있다는 데 있다고들 합니다.

스킬로 반복되는 업무를 자동화하고, CLAUDE.md로 맥락을 관리하고, 팀 전체의 표준으로까지 확장하는 방식으로 말이죠. 물론 사람마다, 팀마다 환경은 다를 겁니다. 그만큼 자신에게 맞는 방식을 찾기까지 시행착오도 따를거고요. 그렇다면 “어떻게 클로드 코드를 길들여야 할까요?”

요즘IT는 이 질문에 힌트가 될 만한 이야기들을 모아봤습니다. 지난 5월 27일과 6월 10일, 두 차례에 걸쳐 클코나잇 시즌2 웨비나가 진행됐는데요. 여기서 발표자로 참여한 프리랜서 개발자, 대기업 비개발자 PM, 1인 빌더, AI 스타트업 CTO, AX 기획자, BizOps 리드까지. 클로드 코드를 실무에서 각자의 방식으로 길들여 온 6인이 직접 부딪히고 배운 것들을 한 권의 사례집과 발표 영상으로 엮어봤습니다.

참고로 이들의 이야기는 완벽한 성공담보다는 삽질하고, 실패하고, 다시 시도하는 과정 속에서 배운 점, 그렇게 자신만의 방식 혹은 팀의 방식을 찾아간 과정에 가깝습니다. 이번 글에서는 사례집에 담긴 이야기 중 두 가지만 먼저 소개해 드리겠습니다.

전국 30개 캠퍼스의 정산 이의제기, 두 번의 피벗 끝에 5일 만에 뒤집은 이야기

IT 교육기업 AX 전략팀에서 기획자로 일하는 이현 님의 이야기입니다.

그가 맡은 첫 AX 과제는 슬랙 기반의 정산 비효율을 해결하는 일이었습니다. 전국 30개 이상의 캠퍼스가 저마다 슬랙 채널로 정산 업무를 처리하다 보니, 전체 현황이 한눈에 보이지 않았고, 사람이 손으로 계산하니 오류가 났고, 그 위에서 이의제기가 반복됐습니다. 그런데 피그잼으로 업무 흐름을 하나하나 뜯어보고 현장 데이터를 들여다보니, 진짜 병목은 예상과 다른 곳에 있었습니다. 본사가 통보한 정산값에 대한 이의제기와 확인 절차, 바로 그 지점이었죠. 그는 여기서 "이의제기 자체가 생길 수 없는 구조"라는 기획으로 방향을 잡았습니다.

문제는 이걸 무엇으로 구현하느냐였습니다. 처음엔 슬랙 안에서 해결하려 했지만 현장 반응이 좋지 않았습니다. 다음엔 노코드 툴을 조합해 봤지만, 툴 간 의존성과 하드코딩 이슈에 부딪혔습니다. 두 번의 피벗 끝에 그가 선택한 건 클로드 코드였고, 놀랍게도 여기서부터는 5일이면 충분했습니다.

런칭까지는 순조로웠습니다. 그런데 배포 다음 날, "로그인이 느리다"는 피드백이 들어왔습니다. 코드에는 문제가 없었습니다. 문제는 코드 밖, 인프라의 기본값에 숨어 있었습니다.

비개발자였던 그는 이 문제를 어떻게 알아챘고, 또 어떻게 해결했을까요? 두 번의 실패를 거듭한 피벗이 오히려 5일 런칭의 발판이 된 이유는 무엇이었을까요? 자세한 과정은 사례집에서 직접 확인해 보세요.

사례집에서 확인할 수 있는 것들

업무 프로세스 맵보다 현장 데이터를 먼저 봐야 하는 이유, 그리고 진짜 병목을 찾아낸 과정
슬랙 → 노코드 → 클로드 코드, 두 번의 피벗을 거치며 MVP를 좁혀나간 전체 흐름
5일간의 실제 작업 순서 (Day1 빌드 → Day2~3 검증 → Day4 사용자 교육 → Day5 배포)
배포 다음 날 터진 로그인 지연 이슈와 원인을 알아챈 과정
클로드 코드의 첫 제안을 그대로 따르지 않고 도메인 지식으로 역제안해, 로그인 속도를 80% 개선한 방법

1인 개발자가 혼자서 9개 프로젝트를 굴리게 된 이야기

1인 빌더로 활동하는 김상욱 님의 이야기입니다.

그는 원래 한 스타트업의 백엔드 개발자였습니다. 프론트엔드 채용이 안 돼서 얼떨결에 프론트까지 혼자 맡게 됐고, 그렇게 익숙해지던 차에 갑작스레 해고를 당했습니다. 다시 취업 준비를 하거나, 뭐라도 혼자 만들어 보거나의 선택에서 그는 후자를 택했고, 그때 처음 클로드 코드를 만났습니다.

혼자서 만드니 속도가 달랐습니다. 예전엔 MVP 하나에 1~2주씩 걸렸는데, 이제는 단 몇 시간이면 나왔죠. 신이 나서 계속 프로젝트를 찍어냈고, 손에 쥔 프로젝트가 순식간에 아홉 개로 불어났습니다. 초등학교 학급 경영 서비스, 진정서를 자동으로 써주는 서비스, 방치형 RPG 게임, 웹소설 팬 위키까지, 만드는 것만큼은 정말 쉬웠습니다.

문제는 그 다음이었습니다. 세션을 켤 때마다 "내가 어디까지 했더라?"를 매번 다시 더듬어야 했고, 같은 지시를 프로젝트마다 반복해서 입력해야 했습니다. 어제 바로잡은 실수를 오늘 또 저지르기도 했죠. 그는 "만드는 건 쉬워졌지만, 만드는 것에서 끝이 아니구나"를 깨달았다고 말합니다. 그리고 이 문제를 하나씩 시스템으로 풀어, 지금은 혼자서 한 컴퓨터로 13개의 프로젝트를 굴리고 있습니다.

어떻게 가능했을까요?세션이 늘어날수록 관리 비용도 함께 늘어나지 않았을까요? 어떻게 혼자서 프로젝트를 13개까지 유지할 수 있었을까요? 고민 끝에 그가 만든 다섯 가지 장치, 그리고 선택과 집중에 대해서는 사례집에서 직접 확인해 보세요.

사례집에서 확인할 수 있는 것들

세 가지 통증(진행 상황 까먹기·같은 지시 반복·같은 실수 반복)을 각각 다른 장치로 해결한 방법
home/CLAUDE.md 하나로 13개 프로젝트의 맥락을 관리하는 실제 구조
"핸드오프"라는 한마디로 세션 전환 비용을 0으로 만드는 방법과, 이걸 CLAUDE.md에 규칙으로 적용하는 법
세션을 시작하고 끝낼 때 실제로 어떤 순서로 작업하는지와 그가 만든 다섯가지 장치
AI에게 정답 대신 컨텍스트를 던지고 함께 답을 찾는 실제 작업 방식

이 두 이야기 외에도, 4명의 실무자가 각자의 자리에서 부딪히고 배운 기록이 사례집에 담겨 있습니다. 어떤 내용들이 있는지 아래에서 함께 살펴보겠습니다.