솔직히 말하면, 요즘 AI 코딩 도구들 잔뜩 깔아도 뭔가 시원찮았다. 처음에는 이것저것 설치해 보면서 기대가 컸는데, 막상 써보면 생각만큼 생산성이 폭발적으로 오르지는 않았다. 오히려 도구들끼리 겹치거나 내가 뭘 놓치고 있나 싶은 기분도 들었다. 다들 비슷한 경험을 하지 않았을까 싶다. 그런데 오늘 흥미로운 글 두 편을 보면서 내가 놓쳤던 부분이 뭔지, 그리고 이 흐름이 어디로 가고 있는지 좀 더 명확해졌다.

도구만으로는 부족하다: 레이어를 보는 눈이 필요하다

이정민 님의 "AI 코딩 승부처: 도구 아닌 레이어를 보는 눈"이라는 글이 특히 인상 깊었다. 저자는 단순히 여러 AI 코딩 도구를 설치하는 것을 넘어 '레이어'를 구분하고 활용하는 능력이 중요해졌다고 말한다. 마치 내가 그랬던 것처럼, 저자 역시 [gstack](github.com/garrytan/gstack), Superpowers, Compound Engineering 같은 좋은 도구들을 깔아봤지만 큰 생산성 향상을 느끼지 못했다고 했다. 이유가 궁금했다.

저자가 제시한 세 가지 레이어는 이렇다. 첫째는 '의사결정 레이어'다. "만들지 마"라고 말해주는 관문이다. Garry Tan이 YC를 운영하며 강조한 [gstack](github.com/garrytan/gstack)의 `/plan-ceo-review`와 `/plan-eng-review`가 대표적이다. 제품 관점에서, 아키텍처 관점에서 작업을 미리 검증해서 아예 불필요한 코딩을 막는다. "잘 만드는 능력"보다 "안 만들 걸 거르는 능력"이 아웃풋 차이를 더 크게 만든다는 말이 꽤 설득력 있었다. 정말 그랬다.

둘째는 '프로세스 레이어'다. 즉흥적인 작업이 아닌, 절차를 심어주는 워크플로우를 만드는 것이다. Superpowers의 `brainstorm → plan → execute → review` 같은 흐름이 여기에 속한다. 12만 스타를 받은 이유가 분명했다. "AI 한테 대충 시키기"에서 "구조화된 워크플로우"로 넘어가는 중요한 관문이다. 이것만으로도 큰 발전이지만, 저자는 세션을 넘기면 지식 축적이 안 되는 빈칸이 느껴진다고 지적했다. 딱 내가 겪었던 문제였다.

셋째는 '지식 레이어'다. 어제 삽질한 기록이 오늘의 자산이 되는 구조를 만드는 것이다. Compound Engineering의 `/ce:compound` 명령어가 그렇다. 버그를 고치거나 기능을 완성한 뒤 실행하면 5개 subagent가 병렬로 작동하며 대화 맥락, 해법 추출, 중복 검색, 재발 방지 전략, 카테고리 분류까지 자동으로 `docs/solutions/`에 기록한다. 일주일 뒤 비슷한 에러를 만났을 때 이전 기록을 먼저 찾아줘서 몇 시간짜리 디버깅이 몇 분으로 줄어들었다는 부분이 가장 매력적이었다. 이게 진짜 생산성 향상이다.

결국 AI 코딩 시대에 개발자의 역할은 단순히 코드를 더 빨리 쓰는 '작업자'가 아니라, 이 세 가지 레이어를 이해하고 조율하는 '조율자'로 바뀌고 있다는 이야기였다. 도구를 무작정 깔기만 해서는 안 되는 시대가 온 것이다. 원문의 저자는 '내 워크플로우에서 의사결정 게이트가 빠져 있는지, 프로세스가 정리되지 않았는지, 지식이 세션마다 증발하는지. 빈 레이어를 먼저 찾고 그 칸을 채우는 SKILL.md 하나를 직접 써보는 것을 추천한다'고 했다. 단순한 도구 도입을 넘어선 이야기였다.

AI는 팀의 문제 해결 주도권을 가져왔다

개인 생산성 이야기에 이어, 이경훈 님의 "클로드 코드: 생산성 넘어 팀 문제 해결 주도권" 글을 보면서 AI가 팀 단위에 미치는 영향은 또 다른 차원이라는 걸 알게 됐다. 클로드 코드를 전사 도입한 지 한 달 만에 변화의 속도가 예상보다 훨씬 빨랐다는 대목이 눈길을 끌었다. 처음에는 다들 AI를 문장 다듬기나 초안 작성 같은 개인 생산성 도구로만 생각했단다. 그런데 한 달이 지나고 보니 상황이 달랐다.

글에서는 두 가지 변화를 언급했다. 첫째, 클로드 코드가 소수의 숙련자만 쓰는 도구가 아니었다. 각 팀이 자신들의 반복 업무나 불편한 작업을 하나씩 자동화하는 방식으로 빠르게 적응했다. "AI를 잘 쓰는 몇 명"의 이야기가 아니라, 팀 단위로 확산되었다는 점이 신기했다.

둘째, 생각보다 빨리 '쓰기'에서 '만들기'로 넘어갔다는 점이다. CSM팀은 콜 로그, 미팅 로그, 결제 더블체크처럼 반복 업무를 자동화했다. 예전에는 문장을 다듬는 정도였다면, 이제는 실제 업무 흐름을 줄이고 바꾸는 방향으로 확장되었다. CX팀의 발표는 더 놀라웠다. 사용가이드 자동화, FAQ 자동 생성, TASK 자동 생성, 서류 자동 발급, 온보딩과 평가 보조까지, 지난 한 달 동안 여러 앱을 직접 만들었다고 했다. 단순히 생산성을 높이는 도구를 쓰는 것을 넘어, 각 팀이 자기 문제를 해결하는 도구를 직접 만들게 된 것이다.

이 부분에서 정말 멈칫했다. 예전에는 팀 안에서 반복적으로 생기는 불편함이나 비효율이 있어도, 보통은 참고 쓰거나 개발팀을 기다리거나 사람을 더 투입하는 방식으로 해결했다. 개발 리소스는 항상 한정적이었다. 그런데 AI 도구, 특히 클로드 코드 같은 것이 팀 단위에 보급되면서 비개발 직군도 자기 팀의 문제를 직접 자동화하고, 앱으로 만들고, 해결 가능한 형태로 바꾸기 시작한 것이다. AI는 일을 조금 더 빨리 하게 만드는 도구라기보다, 문제 해결의 주도권을 팀 안으로 다시 가져오는 도구에 가까웠다. 이것은 팀의 자율성과 문제 해결 속도를 크게 높여주는 모습이다.

결국 AI는 단순히 개인의 코딩 속도를 높이는 것을 넘어, 우리가 무엇을 만들고 어떻게 만들지에 대한 의사결정의 무게를 더하고, 팀 단위의 문제 해결 방식과 주도권까지 바꾸고 있었다. 개인적으로는 아직 '레이어'를 보는 눈을 기르는 중이다. 어떤 레이어가 비어있는지 아직 명확하지 않았다. 하지만 AI가 던지는 가장 큰 질문은 이것 같다. 우리가 만드는 것이 도구에 불과한지, 아니면 일하는 방식 자체를 바꾸는 동료인지.

참고