Claude Code 도입 3개월째 - 삽질에서 N개 동시작업까지

Claude Code 도입 3개월째 - 삽질에서 N개 동시작업까지

Claude Code 도입 3개월째 - 삽질에서 N개 동시작업까지

안녕하세요. 물먹고하자입니다.
회사에도 AI 도입이 본격적으로 시작되면서, 개발 흐름이 1~2달 사이에 크게 바뀌고 있어요.

맡고 있는 프로젝트들이 규모도 작지 않고 안정성도 중요하다 보니, 첫 도입이 쉽지만은 않았습니다. 초반엔 토큰 녹여가며 구조를 이리저리 바꿔봤고, 지금은 어느 정도 자리가 잡혔네요. (거의 주마다 새로운 게 나와서 따라가기 벅차요 ㅠㅠ)

지금까지 겪으면서 작업 흐름이 바뀐 부분을 공유드릴게요. (AI 덕분에 블로그 스타일도 바꿨네요~!)

1. 처음엔 그냥 "만들어줘"였습니다

다들 이렇게 시작하잖아요. 채팅창에 "이 기능 만들어줘" 한 줄. 작은 거는 잘 됐어요. 문제는 우리 앱 구조였습니다. 레이어가 View → ViewModel → UseCase → Service → 네트워크로 딱딱 나뉘어 있어서, 기능 하나 넣으면 파일을 기본 4~5개씩 건드려야 하거든요.

여기서부터 AI가 자꾸 중간에 퍼졌습니다. 파일을 한꺼번에 많이 맡기면 작업 기억(컨텍스트)이 꽉 차서 뚝 끊겨요. 10개 고쳐야 하는데 7번째쯤에서 멈추고, 정작 "다 했어요"라고 합니다. 열어보면 절반만 돼 있고요. 이게 은근 사람 빡치게 합니다 — 차라리 처음부터 안 됐으면 다시 시키지, "됐다"는데 절반만 된 걸 일일이 찾아내는 게 더 일이거든요.

도입 초기 멀티파일 작업, 어디까지 가고 멈췄나 · 체감 기준

파일 1~3개
거의 항상 완주 ✅
파일 4~6개
중간에 헷갈리기 시작
파일 7개+
끊김 · "다 했다"는데 절반

※ 정밀 측정이 아니라, 두 달 굴려보며 몸으로 느낀 감입니다.

여기서 얻은 결론은 하나였어요. AI 하나한테 큰 덩어리를 통째로 던지면 안 된다. 사람도 일 나눠 맡기잖아요. AI도 똑같이 "전체 보는 놈"이랑 "한 덩어리 처리하는 놈"을 갈라야 했습니다.

2. 그래서 역할을 쪼갰습니다 (오케스트레이션)

구조는 의외로 단순합니다. 메인 대화가 지휘만 하고, 실제 작업은 역할별 서브에이전트한테 넘깁니다. 각자 별도 기억 공간에서 도니까, 한 놈 머릿속이 무거워질 일이 없어요. 이렇게 넷으로 나눴습니다.

🗂 planner — 설계
소스 뒤져보고, 작업량 재고, 잘게 쪼갠 계획서를 씀. 내가 OK 하기 전엔 코드 한 줄도 안 건드림.
⚙️ implementer — 구현
쪼개진 덩어리(청크) 하나씩 실제로 코딩. 매번 새로 시작해서, 맥락은 그때그때 받아감.
🔍 verifier — 대조
계획서랑 결과물 맞춰봄. 통과/실패 판정. 빵꾸 나면 구현 다시 시킴.
✅ reviewer — 최종검토
다 끝나면 레이어 규칙·스레드 안전성·금지패턴 점검. 커밋 직전 마지막 관문.

핵심은 "청크 분할" 하나입니다. 큰 작업을 파일 3~4개짜리 묶음으로 쪼개서 한 묶음씩 완주시키는 거예요. 파일 10개짜리도 묶음1 → 검증 → 묶음2 → 검증 → … 식으로 가니까, "어디까지 했더라" 하고 더듬는 일이 사라졌습니다.

그러니까 위 1번 그래프가, 구조 바꾸고 나서 이렇게 바뀌었어요.

파일 7개+ 작업 완주율 · before(단발 요청) vs after(청크 분할)

Before
35% 어딘가서 멈춤
After
92% 묶음 단위로 완주

딱 하나 운영하면서 제일 많이 깨진 지점만 짚고 갈게요. 서브에이전트끼리는 서로를 모릅니다. planner가 짠 계획을 implementer는 모른다는 거예요. 그래서 메인 대화가 부를 때마다 "전체 계획 + 지금까지 한 거 + 이번에 할 거"를 매번 손에 쥐여줘야 합니다. 이거 빼먹으면 산으로 가요. 도입 초기 두 번째 삽질이 정확히 이거였습니다.

말로만 하면 잘 와닿지 않으니, 실제로 이 흐름이 어떻게 도는지 한 케이스를 그림으로 옮겨봤어요. 로그인의 자동로그인과 생체인증을 분리하는 작업이었는데, 파일이 8개에 레이어가 4개라 한 번에 던지면 딱 퍼지는 크기였습니다. 그래서 청크 4개로 쪼개서 아래처럼 굴렸어요.

1
오케스트레이션 예시 (ex. 로그인 · 생체인증 분리)
신규 기능 개발 · 8개 파일 · 4레이어 · 🔴 대규모 → 4청크
/feature
💬 사용자 요청
자동로그인과 생체인증을 독립 상태값으로 분리
🗂 planner
8파일 분석 · 4청크 계획 수립
✋ 사용자 승인
계획서 확인
⚙️ Chunk 1 — UseCase 레이어
🔍
verifier
PASS
⚙️ Chunk 2 — Service 레이어
🔍
verifier
PASS
⚙️ Chunk 3 — View 레이어 (Setting)
🔍
verifier
PASS
⚙️ Chunk 4 — View 레이어 (Login/Main)
🔍
verifier
PASS
✅ reviewer
전체 파일 레이어 검토
📦 커밋
developer · 머지 시 README
🔵 분할 이유 — 레이어 간 의존성: UseCase 완성 후 Service, Service 완성 후 View 참조 가능
🔵 Chunk 4 — 로그인 화면 컨트롤러 2000줄+ 복잡 파일 → 별도 청크로 리스크 격리
🔵 매 청크 — 전체 계획서 + 완료 청크 요약 + 현재 청크 상세, 3가지 재주입

3. 덤으로, 토큰까지 아꼈습니다

역할을 쪼개니까 의외의 데서 이득이 났는데, 바로 토큰 사용량이었어요. 예전엔 대화 하나에 파일 10개를 통째로 물려놓고 작업을 시키니, 갈수록 맥락이 불어나서 뒤로 갈수록 같은 작업에도 토큰을 훨씬 많이 먹었거든요. (그러다 컨텍스트 꽉 차서 끊기기도 하고요.)

근데 서브에이전트는 각자 필요한 만큼만 들고 도는 별도 기억 공간이라, 메인 대화는 "지휘"에 필요한 최소한만 유지하면 됩니다. 무거운 소스 분석·구현은 그때그때 새로 뜬 에이전트가 자기 청크 분량만 보고 끝내고요. 덩어리째 던지던 시절보다 같은 작업을 더 적은 토큰으로 쳐내게 됐습니다.

토큰 관점에서 본 이득
핵심은 "메인 대화를 가볍게 유지한다"예요. 맥락이 한 곳에 계속 쌓이면 토큰도 비용도 같이 불어나는데, 역할별로 기억 공간을 나누니 무거운 맥락이 한쪽에 고이지 않습니다. 덤으로 컨텍스트가 꽉 차서 중간에 끊기는 일도 거의 사라졌고요.

같은 작업, 토큰이 어떻게 쌓이나 · 통으로 실행 vs 청크 분할

❌ 통으로 실행 (기존)
계획서 ~1,000 토큰
소스 읽기 (파일 10개) ~10,000 토큰
코드 작성 중 (누적) ⚠ 한계 초과
context 한계
하나의 기억 공간에 전부 쌓임.
중간에 한계 도달 → 작업 미완료로 끊기는 문제.
✅ 청크 분할 실행 (개선)
Chunk 1 — 새 인스턴스 파일 3개
Chunk 2 — 새 인스턴스 파일 3개
Chunk 3 — 새 인스턴스 파일 4개
각 청크는 신선한 기억 공간으로 시작.
여유 토큰으로 완주 보장, 메인 대화만 가볍게 히스토리 유지.
통으로 실행
한계로 미완료
vs
청크 분할
여유 있게 완주
1청크 = 파일 3~4개
완주 보장 단위

※ 토큰 수치는 흐름을 보여주기 위한 대략값입니다.

4. 매번 손으로 시킬 순 없으니까 — 명령어로 박제

위 흐름을 매번 프롬프트로 풀어쓰는 건 노가다라, 아예 슬래시 명령어로 등록해버렸습니다. 이제 작업 종류에 맞는 거 한 줄 치면 planner → implementer → verifier → reviewer가 알아서 돕니다.

개발용

/feature
신규 기능 — 새 화면, 새 API, 새 모듈
/bugfix
버그 수정 / 로직 개선 — 함수 손보기, 조건 바꾸기, 크래시 잡기
/refactor
리팩토링 — 레이어 정합성, 비대해진 ViewModel 다이어트
/jira-plan <이슈키>
티켓 번호만 던지면 본문 받아와서 과거 유사사례 찾고 → 소스 뒤져서 → 개발계획서까지 뽑음

운영·품질용

/csap-check
보안 지침(에러 정보 노출, 포맷 스트링 삽입 등) 기준으로 프로젝트 전체 정적 스캔
/blog
작업하다 만난 케이스를 블로그 초안으로 정리 — 사실 이 글도 이걸로 뽑았습니다 😅
/a10-all
형제 레포들에 같은 규칙을 한 방에 적용·커밋·푸시 (5번에서 자세히)

배포용

/deploy-a10 · /deploy-omni · /deploy-csap
스킴별 TestFlight 배포. 빌드번호 자동 +1, 버전 갱신, 배포 기록 커밋까지 CI/CD가 묶어서 처리

스킬의 진짜 효과는 따로 있어요. 명령어 안에 "우리 팀 일하는 방식"이 박제된다는 거. 누가 시키든 같은 절차로 도니까 결과가 사람 컨디션을 덜 탑니다. 새로 온 사람도 명령어만 알면 팀 규칙대로 굴러가고요.

그래서 스킬을 둘로 나눠서 둡니다. 기준은 간단해요. "이거 팀이 같이 지켜야 하나?"

프로젝트 스킬 vs 전역 스킬
📂 프로젝트 스킬 (공유) — 팀이 같이 쓰고 규칙을 맞춰야 하는 건 레포 안에 넣어 커밋합니다. /feature·/bugfix·/csap-check·/deploy-* 같은 거요. 받아서 실행만 하면 누가 하든 같은 절차로 돌아가니까, 규칙이 사람 따라 흔들리지 않아요.

🙋 전역 스킬 (비공유) — 블로그 정리(/blog)나 여러 프로젝트 폴더를 통째로 넘나드는 작업처럼 나한테만 필요한 건 내 계정 전역에만 둡니다. 레포엔 안 올라가니 팀에 부담 줄 일도 없고요.

5. 그래서, 하루가 이렇게 바뀌었습니다

구조랑 스킬이 자리 잡으니까 생긴 제일 큰 변화가 "동시성"이었어요. 예전엔 작업 하나 붙잡으면 그게 끝날 때까지 다른 걸 못 했는데, 지금은 성격 다른 작업 서너 개를 동시에 굴립니다. 이걸 가능하게 한 장치가 셋이에요.

가능하게 한 장치는 크게 셋이에요. ⓐ git worktree로 같은 레포를 여러 작업 폴더로 펼쳐 서로 안 부딪히게 하고, ⓑ 백그라운드로 오래 걸리는 스캔·검토는 뒤로 돌려두고 알림 올 때까지 딴 일을 하고, /a10-all로 여러 형제 레포에 같은 변경을 한 방에 순회 적용합니다.

근데 장치 설명을 늘어놓는 것보다, 실제 하루가 어떻게 바뀌었는지 보는 게 빠를 것 같아요. 아래는 같은 일을 제가 혼자 하던 날AI를 붙인 지금의 하루 일과입니다.

도입 전 나 혼자 — 한 번에 하나씩
91011121314151617
👤 나
A 기능개발
회의
점심
A 기능개발
검수
기획

하루를 다 써도 A 기능 하나 + B 기획 살짝. 회의·점심 끼면 흐름이 계속 끊겨요.

도입 후 회의·면접은 내가, 개발·보안·Jira는 AI가 동시에
91011121314151617
점심
👤 나(회의)
회의
🟦 A 기능개발
/feature 청크 구현
이어 개발
🟪 기획검토
AI 초안
🟧 보안검토
/csap-check
/csap-check (오늘 길게)
🔷 Jira 처리
Jira
🟩 지침자동화
/a10-all
👤 면접검토
이력서

⚡ 10~11시 회의를 듣는 중에도 A 기능개발·보안검토는 계속 돌았고, 13~14시엔 개발·기획검토·보안 세 갈래가 한꺼번에. 막판 17~18시 면접 이력서 검토만 제가 직접 봤어요.

오해는 마세요. 동시에 굴린다고 사람이 손 놓는 거 아닙니다. 각 갈래가 지금 어디쯤인지 추적하고, 돌아온 결과 검토하고 이어붙이는 건 여전히 제 몫이에요. "분배는 과감하게, 판단은 직접" — 이 선만 안 넘으면 됩니다.

그리고 시간이 어디로 가느냐도 확 바뀌었어요. 예전엔 "AI 기다리고, 됐다는 거 절반만 됐나 다시 확인하는" 데 시간을 꽤 썼는데, 지금은 그 둘이 줄고 진짜 작업과 검토에 시간이 모입니다.

작업 시간이 어디로 가나 · 체감 비중

도입 전
기다림 35%
재확인 25%
실작업 40%
지금
8%
12%
실작업·검토 80%

🔴 기다림 · 🟡 "됐다는데 절반"이라 다시 확인 · 🟢 진짜 작업+검토

결국 좋아진 건 둘로 요약돼요. 끊김으로 날리던 시간이 거의 사라졌고, 혼자서도 여러 갈래를 동시에 굴릴 수 있게 됐다는 거. 같은 시간에 쳐내는 일의 양 자체가 늘었습니다.

⚠️ 그래도 이건 남아요
이 구조는 메인 대화가 전체 상태를 잘 들고 있어야 돌아갑니다. 맥락 재주입 빼먹으면 산으로 가고요. 그리고 AI가 뱉은 결과를 사람 검토 없이 그냥 커밋하는 건 절대 금물입니다. 이건 자동화돼도 안 변하더라고요.

솔직히 생산성은 확실히 올라갔어요. 근데 그만큼 뇌가 과부하 걸리는 느낌도 같이 옵니다 ㅠㅠ. 일을 동시에 굴리는 건 AI가 해줘도, 검수·검토는 결국 사람이 해야 하거든요. 갈래가 늘수록 "지금 뭐가 어디까지 됐지"를 머릿속에 들고 있어야 하니까, 동시작업 수만큼 머리도 같이 바빠져요.

그래서 요즘 붙잡고 있는 숙제는 이거예요. 어디까지를 내가 일일이 판단하지 않고 그냥 진행시켜도 되는가. 전부 다 들여다보면 동시성의 이점이 사라지고, 너무 놓으면 사고가 나니까 — 그 "맡겨도 되는 선"을 찾는 게 다음 단계 같습니다.

마무리

어느덧 14년차(?) iOS 개발자로 일하고 있는데요. 그동안 iOS 업데이트 때문에 터지는 이슈들, 정부 지침이 갑자기 바뀌어 빠르게 대응해야 했던 일들까지 — 참 별의별 대응을 다 해왔습니다.

"AI 때문에 개발자가 없어진다?!" 같은 뉴스들을 보면서 '이게 진짜일까?' 싶었고, 그 궁금증 반 걱정 반으로 저도 AI 도입을 시작했어요. 근데 막상 써보니, 개발자가 사라진다기보다 'AI를 활용하지 못하는 개발자가 밀려나겠다'는 생각이 문득 많이 들더군요. 확실히 개발의 패러다임이 바뀌는, 큰 획이 하나 그어진 것 같습니다.

거의 격주 단위로 AI가 발전하고 도입할 거리가 늘어나서, 저도 열심히 공부하면서 부지런히 따라가야겠네요.

오늘은 이만~
즐거운 코딩 되세요.

끝.

댓글