2026년 2월, 절반은 손으로 짜던 시절
Kiro, Cursor, GPT 창을 번갈아 쓰며 일의 절반은 손으로 짰다. 나머지 절반을 AI에 넘기려고 프롬프트를 다듬는 데 정작 더 많은 시간을 썼다. AI를 신뢰하지 않았다. 똑똑한데 전부 맡기기엔 미덥지 않았다.
판을 바꾼 건 한 시니어 개발자였다. 오래 자리를 비웠다 복귀했는데 속도가 이상했다. 쌓인 변경을 며칠 만에 따라잡고, 레거시를 거침없이 정리했다. 나중에 알고 보니 Claude Code 상위 플랜을 쓰고 있었다. 그 소문이 윗선에 닿았고, 회사는 전사 AI 도입을 선언했다.
이날이 AI와 정면으로 마주한 첫날이다.
Claude Code — 직접 코딩을 멈추기로 한 순간
받은 건 Claude Code였다. 모델 바꾸는 법을 몰라서 2~3주를 Sonnet으로만 일했다. 그 Sonnet만으로도 속도는 비약적으로 올랐다.
보일러플레이트, 반복 CRUD, 기존 패턴을 따라가는 리팩터링 — 손으로 치면 지루하기만 하던 것들을 Sonnet이 충분히 해냈다. 그러자 내가 직접 타이핑할 이유가 사라졌다. 남는 건 타이핑이 아니라 판단이었다.
결정했다 — 직접 코드를 짜는 일을 그만두고, 대신 감독한다. 다만 AI 결과물을 한 줄씩 뜯어보며 검증하는 습관은 남겼다. 지금 돌아보면 이게 이후 가장 잘한 선택이다.
using-superpower — 자동화의 편의, 토큰 누수라는 대가
3월 중순에 using-superpower를 깔았다. Claude Code에 얹는 스킬 묶음으로, 브레인스토밍·설계 리뷰·TDD를 자동으로 처리해줬다. 적극적으로 쓰기 시작하자 문제가 생겼다.
훅(hook) 기반 자동 발동 구조가 원인이었다. 가벼운 질문 하나에도 훅이 맥락을 감지해 무거운 스킬 본문을 프롬프트에 주입했다. 5시간 토큰과 주간 토큰이 거덜났다.
이 시기 팀 화두가 '하네스 엔지니어링'이어서 나도 사내용 하네스 도구를 직접 만들겠다고 일주일을 갈아 넣었다. 결과는 폭망이었다. '항상 켜두고 알아서 다 해주게' 만들려다 필요 없는 순간까지 스킬을 욱여넣었고, 토큰만 잔뜩 먹은 괴물이 나왔다.
교훈 1: 자동화의 비용은 안 쓸 때도 든다. 훅이 똑똑할수록 안 부른 순간에도 토큰 한도가 깎인다.
gstack — 명확화의 빛, 오버엔지니어링의 그림자
토큰이 빠듯하던 시기에 gstack을 써봤다. 기획서도 없이 "앱 전체를 새로 짓자"는 결정만 있던 상황에서 gstack의 명확화는 절묘하게 맞았다. 모호한 지점을 수십 개 질문으로 쪼개줬고, 답해가다 보면 흐릿하던 정책이 또렷해졌다.
계속 쓰자 그림자가 보였다. 5~10년 버틸 설계를 만들겠다며 오버엔지니어링이 꼬리를 물었다. 쌓인 과잉 설계를 쳐내는 데 명확화보다 더 많은 시간을 썼다.
각 도구를 쓰며 쌓은 구체적인 관찰과 시행착오 전체는 원문에서 확인할 수 있다.
→ 원문 전체 읽기: k3nta.com/ko/blog/ai-adoption-journey-1-tools
speckit — 주력이 된 도구, 그리고 남은 벽
speckit은 명세를 먼저 잡고 그 명세로 구현까지 끌고 가는 워크플로우 도구다. gstack의 비대한 명확화도, using-superpower의 과도한 토큰도 없었다. 지금도 주력으로 쓴다.
그런데 쓸수록 두 가지가 걸렸다.
clarify가 한 번에 최대 다섯 개 질문만 내놓는다. 몇 번을 더 돌려야 충분한지 알 수 없었다.- 질문 문체가 AI가 읽기 좋게 정돈된 장황한 형식이라 사람이 읽기 힘들었다.
근본 원인을 팠다 — clarify는 코드를 안 본다
피로가 쌓이면 보통 새 도구를 찾는다. 이번엔 원인을 팠다.
speckit의 clarify는 실제 코드베이스를 보지 않는다. 주어진 명세만으로 추측해 질문을 만든다. 그래서 코드만 열면 답이 나오는 것까지 사람에게 되물었다. "이 엔티티에 이 필드가 이미 있나요?" — 코드가 답을 쥔 질문들이다.
훅에서 코드베이스를 탐색하게 만들어봤다. 질문마다 코드를 뒤지고 "이 질문이 필요한가"를 판정하니 이번엔 토큰이 샜다. using-superpower에서 본 함정을 내 손으로 반복했다.
직접 만든 스킬 — prefill
그래서 prefill 스킬을 직접 만들었다. 훅 자동 발동 대신, specify와 clarify 사이에 끼워 필요할 때 직접 부르는 단계로 뒀다.
# ❌ 훅에서 매 질문마다 코드 탐색 → 질문 수만큼 조회 비용
# ✅ specify 직후 prefill 한 단계에서 코드 조회를 1회로 몰아둠clarify가 질문을 던지기 전에, 코드베이스와 프로젝트 도메인 지식을 담은 LLM 위키를 함께 뒤져 코드·기록만으로 답할 수 있는 항목을 미리 채워 명세에 박아둔다. 결과는 세 칸으로 적힌다.
## Resolved
- User 엔티티에 deleted_at 필드 존재 → soft-delete 처리 가능 (user.entity.ts:45)
## Assumed
- soft-delete 패턴을 따른다고 가정 (rule-04 참고 — 사람 확인 필요)
## Needs Clarification
- 탈퇴 후 데이터를 30일 유예 보관할지, 즉시 삭제할지 — 정책 결정 필요사람에게 넘어가는 건 마지막 칸뿐이다. clarify를 반복하는 횟수와 사람이 답해야 할 질문 수가 줄었다. 팀원들에게 공유했고 실제로 쓰는 게 보였다.
교훈 2: 증상이 반복되면 새 도구부터 찾기보다 원인을 파라. clarify 질문 폭탄의 원인은 '코드를 안 보는 추측' 하나였다.
지금의 워크플로우
- Claude와 대화하며 작업 맥락을 쌓는다
- speckit
specify로 명세를 잡는다 prefill로 코드·기록이 답할 부분을 미리 채운다clarify로 남은 핵심만 명확화한다plan→tasks→analyze→implement
이 만족이 오래가지 않을 것도 안다. 패러다임은 길어야 몇 주 단위로 바뀐다. 중요한 건 하나를 고르고 나머지를 버리는 일이 아니라, 각 도구가 잘하는 지점과 비는 지점을 읽어 조합하는 일이다.
정리
- 자동화의 비용은 안 쓸 때도 든다 — 훅 자동 발동은 편의의 대가로 토큰을 태웠다
- 강한 모델 ≠ 명확한 요구사항 — 모델이 좋아져도 명확화는 남는다
- 증상이 반복되면 원인을 파라 — 새 도구보다 근본 원인이 먼저다
다음 편은 이 과정에서 더 크게 바뀐 것 — 의심 많던 내가 검증을 어떻게 시스템으로 굳혔는지다.
prefill 구현 방식, 각 도구의 비교, 그리고 4부작 시리즈 전체는 원문에서 읽을 수 있다.
→ 원문 전체 읽기: k3nta.com/ko/blog/ai-adoption-journey-1-tools
