첫 시도는 95%가 쓰레기: Claude Code와 함께한 Staff Engineer의 여정

• 한 스태프 엔지니어가 Claude Code를 활용해 AI와 함께하는 개발 워크플로우를 6주 동안 실험한 경험을 공유
• AI를 ‘학습하지 않는 주니어 개발자’로 간주하는 사고방식이 성공적 통합의 핵심
• 첫 시도는 대부분 95% 실패하지만 반복 과정을 통해 점차 쓸모 있는 코드로 다듬어짐
• 프로젝트별 컨텍스트 파일(Claude.md) 과 MCP 기반 툴 통합을 활용해 AI의 컨텍스트 부족 문제를 해결
• 개발자의 역할은 코드 작성에서 문제 해결과 아키텍처 설계로 이동하며, 이는 AI 활용 시대의 새로운 생산성 패턴

---

배경과 접근

• 글쓴이는 원래 모든 코드를 직접 작성했으나, 최근에는 80%를 AI가 작성하고 자신은 아키텍처와 리뷰, 멀티스레드 개발 관리에 집중함
• 이 글은 'AI가 혁신을 이끈다'는 장밋빛 논조가 아니라, 실제 프로덕션 개발 워크플로우에 AI를 통합하며 겪는 혼란과 현실적 방법론을 공유함
• AI를 ‘학습하지 않는 주니어 개발자’로 대하는 것이 성공적 활용의 핵심

개발 패러다임의 변화 과정

• 초기 5년간은 책과 SDK 문서를 참고하는 개발 방식 유지
• 이후 12년간 검색(google) 기반 군중 지식 활용으로 전환
• 최근 18개월간은 Cursor를 통한 AI 보조 코딩 실험
• 직전 6주 동안은 Claude Code를 활용한 전체적 AI 위임으로 급격한 변화 경험
• Claude Code 적응은 단 몇 시간 만에 생산성 체감이 가능했음

실제 AI 기반 프로덕션 워크플로우

• 프로덕션에 들어갈 코드 작업시, 주로 AI를 "생각하는 데" 이용함
• 한번에 완벽한 코드 생성은 불가능함. 엔지니어로서의 임무는 문제에 대한 최선의 해결책을 찾는 것
  • 첫 시도 (95% 실패): AI가 시스템 맥락을 쌓고, 개발자가 문제를 규명하는 단계지만 코드는 거의 틀림
  • 두 번째 시도 (50% 실패): 맥락 이해가 향상되고 접근 방식이 구체화되지만 여전히 절반은 무용지물
  • 세 번째 시도 (가용 코드): 반복·리뷰를 거쳐 실제로 사용할 수 있는 기반 코드가 나오며 이후 개선 가능
• 이 과정은 실패가 아니라, 일부러 계획된 실험과 반복적 최적화 과정임

맥락 문제와 해결책

• AI는 세션 간 기억을 유지하는게 불가하여 매번 같은 설명을 반복해야 하는 한계가 있음
• 해결책으로 Claude.md 파일을 활용해 아키텍처 결정, 패턴, 문서 링크 등을 기록
• MCP 통합을 통해 Linear, Notion, GitHub, 코드베이스, 데이터베이스와 연결하여 컨텍스트를 자동 제공
  • Linear로 티켓 컨텍스트 제공
  • Notion 또는 Canvas로 문서 접근
  • 비프로덕션 데이터베이스로 데이터 구조 확인
  • GitHub에서 과거 PR의 배경 정보 활용

병렬 Claude 인스턴스 운용 및 핵심 전략

• 여러 Claude 인스턴스를 병렬로 운영하면서 ‘매일 메모리를 잃는 작은 개발팀’을 관리하는 느낌으로 접근함
• 동일 문제 영역에 병렬화 금지, 모든 작업을 Linear 등 프로젝트 관리 도구에 기록, 인간이 직접 수정한 코드 명확히 표시 등의 전략 수립
• 코드 작성뿐 아니라 코드 리뷰에서도 AI 적극 활용: 테스트 누락, 명백한 버그, 개선점을 빠르게 도출해 반복 작업을 절감함
• 나의 회사(Sanity) 정책상, AI가 생성한 코드라도 최종 품질 책임은 엔지니어에게 있음
• AI와 인간이 구별되지 않는 코드 생성 환경에서, 감정적 애착이 줄고 더 비판적이고 객관적인 코드 리뷰 가능해짐

3단계 코드 리뷰 프로세스

• 코드 작성은 업무의 일부이지만, 코드 검토 또한 마찬가지
• 1차 리뷰 : Claude의 초기 검토
  • 테스트 커버리지 누락과 명백한 버그 탐지
  • 개선 제안으로 동료 검토 시간 절약
• 2차 리뷰 : 내가 검토
  • 유지보수성, 아키텍처, 비즈니스 로직, 통합성 확인
  • AI 생성 코드라도 엔지니어가 최종 책임을 짐
• 3차 리뷰 : 팀의 일반 검토
  • 어느 부분이 AI 생성 코드인지 알지 못함. 동일한 품질 기준 적용
  • 감정적 애착 없이 객관적인 검토 가능
• AI가 작성한 코드에 대한 정서적 애착이 줄어 객관적 리뷰 가능

Slack-Triggered Agent 및 업무 자동화 실험

• Cursor로 슬랙 연동 에이전트를 파일럿: 간단한 비즈니스 로직 수정에 성공, 복잡한 CSS 레이아웃에는 실패함
• 현 시점에서 비공개 NPM 패키지 미지원, 서명 없는 커밋, 공식 추적 우회 등 한계 존재
• 하지만, 단순 반복 티켓을 에이전트가 야간에 처리할 미래 시나리오에 기대감이 있음

비용 및 ROI

• Claude Code 사용 비용은 회사에서 엔지니어에게 지급하는 적지 않은 금액임
• 하지만, 그 투자로 생산성 향상 효과를 얻음
  • 기능 출시 속도 2~3배 향상
  • 다수 개발 스레드 동시 관리 가능
  • 반복적·보일러플레이트 코드 직접 작성하는 일 없어짐
• AI 도입 초기에는 시니어 엔지니어에게 월 $1000~1500 예산 필요, 숙련도 증가에 따라 비용 효율 개선 기대

AI 보조 개발의 지속적 문제와 한계

• 학습 문제: AI가 실수에서 배우지 못해 동일 오해 반복, 해결책은 풍부한 문서화와 명시적 지시 강화
• 신뢰 문제: AI가 잘못된 코드를 확신 있게 내놓으므로 반드시 검증 필요, 특히 복잡한 상태관리, 성능, 보안구간에서 주의 강화
• 컨텍스트 한계 문제: 대규모 코드베이스는 AI 맥락 창을 초과하므로 문제를 작은 단위로 쪼개고 명확한 맥락 제공이 필수

코드에서 문제로의 정서적 변화

• 코드에 대한 집착을 내려놓고 문제 해결 중심 사고로 전환
• 잘못된 코드의 빠른 삭제, 더 객관적인 리뷰, 리팩토링에 대한 부담이 줄어듦 => 긍정적 변화
• 더 나은 AI 툴이 나오면 즉시 교체할 의향이 있음
• 본질은 ‘코드 자체’가 아니라 해결해야 할 문제의 가치임

엔지니어 관점의 AI 도입 조언

• 1. 여러 AI 솔루션 실험 허용: 팀이 다양한 도구를 직접 사용해보며 실무 역량 제고 필요
• 2. 반복적이고 단순한 업무부터 AI 적용: 빠른 효과 기대 가능
• 3. 시행착오 예산 확보: 첫 달은 혼란을 감수해야 함
• 4. 리뷰 프로세스 재설계: AI 코드 특성에 맞는 점검 강화
• 5. 철저한 문서화: 우수한 컨텍스트가 생산성 배가

• 새로운 AI 워크플로에 적응하는 엔지니어는 도구 상자에 새로운 날카로운 칼이 들어 있는 것을 깨닫게 될 것
• AI 워크플로우를 받아들이는 엔지니어들은 복수의 AI 에이전트를 오케스트레이션하며 아키텍처, 리뷰, 복잡한 문제해결에 집중하는 새로운 역할로 진화

당신의 다음 단계

• 작지만 잘 정의된 기능 하나를 선택하고,
• AI에게 해당 기능을 구현할 수 있는 세 번의 기회를 주고,
• 마치 초보 개발자를 멘토링하듯 결과를 검토해 볼 것

• 그거면 끝. 큰 변화도, 프로세스 개편도 필요 없음
• 단 하나의 기능, 세 번의 시도, 그리고 솔직한 리뷰만 있으면 됨

• 미래는 AI가 개발자를 대체하는 것이 아님
  • 개발자들이 더 빠르게 작업하고, 더 나은 솔루션을 개발하고, 최고의 도구를 활용하는 것

[helio]

"이런 정교한 절차라면 그냥 본인이 직접 코드를 작성하는 것이 낫다고 생각함"

[skageektp]

팀원들에게 일을 안시키고 직접 일을 처리하는 팀장님의 자세 ㅋㅋㅋㅋ

[greenbhj]

그럴것 같지만 전혀 그렇지 않음.
지난 6개월간 소규모,대규모 반복 실험해봄.

[iolothebard]

작지만 잘 정의된 기능 하나를 선택하고,
AI에게 해당 기능을 구현할 수 있는 세 번의 기회를 주고,
마치 초보 개발자를 멘토링하듯 결과를 검토해 볼 것
내가 없이 그걸 할 수 있으면 “득”인데… 내가 있어야 한다면… 그냥 내가 하는게 “득”임.

[GN⁺]

Hacker News 의견

• 에이전트의 인지적 한계를 고려해서 명령을 내리는 것이 중요함을 느낌, 예를 들어 큰 변화는 요구하지 않고 계획을 세운 뒤 작은 단계별로 실행을 지시하고 각 단계를 테스트하면서 진행해야 하고, 복잡한 단계에서는 문제와 해결 방안을 시각화하는 코드를 작성하게 하면 좋음, 어떤 단계에서 실패하면 코드에 로깅을 추가하고 로그를 저장한 뒤 테스트하고 로그를 검토해 원인을 파악하는 과정을 반복적으로 시도해야 효과적임, 기존 코드의 설계 방식을 통해 모델이 변경해야 할 부분을 파악하게 하면 AI가 전체를 한 파일에 몰아넣지 않게 할 수 있음, 여러 사람이 이러한 팁을 공유한 블로그를 봤는데 여전히 완벽하진 않지만 쓸모없는 결과가 95%까지 나오진 않는 경험임

  • 나는 이런 것들을 이미 다 시도하는데도 대부분 쓸모없는 코드가 나오고, 그나마 제대로 동작할 때도 결국 직접 손을 봐야 쓸 만해짐, 정말로 잘 작동하는 경우가 있긴 해서 그땐 신나지만 개인적으로 효율성 향상은 크게 못 느끼고 있음
  • 큰 규모의 복잡한 작업에서는 "지금 당장 코드를 작성하지 마세요. 각 단계를 자세히 설명할 거예요"라고 지시하는 방식이 효과적임을 느낌, 예를 들어 입력 읽기, 후보 생성, 후보 점수 부여, 우선순위 및 정렬, 출력 데이터 구조 생성, DB에 저장 등으로 단계적 개요를 제시함, Claude는 이 단계들을 TODO 리스트와 문서로 정리해서 다음에 이어서 진행하기 편하게 관리함, 실제로 한 시간 작업하다가 그만두고 “완료한 스테이지는 코드 생성하고 코멘트 남겨서 다음에 이어서 하자”라고 시키면 쉽게 연속 작업이 가능했음
  • 여러 LLM/에이전트를 오래 써도 여전히 유용한 결과를 얻기가 힘듦, 쓸데없는 출력을 피하려면 직접 작업할 때보다 더 많은 에너지를 프롬프트 작성에 써야 하고, 프롬프트 문구나 말투, 원하지 않는 연관이 생기지 않게 신경 쓰다 보니 괜히 불안해짐, 별도의 프론트엔드 프레임워크처럼 LLM 프롬프트를 관리해주는 도구가 있으면 좋겠음, 일반적인 프롬프트 구조를 정리하거나 모범 사례를 기본값으로 적용해서 코드에서 뭔가 찾거나 새 기능 설계, 테스트 작성할 때 고민을 많이 줄여주길 바람
  • 이런 정교한 절차라면 그냥 본인이 직접 코드를 작성하는 것이 낫다고 생각함
  • 개인 프로젝트에서 AI와 vibe coding을 시도해 보니, 테스트 주도 개발 방식이 vibe coding과 상당히 궁합이 좋았음, 문제를 작은 테스트 가능 단위로 분해하고, 먼저 AI에게 유닛 테스트부터 작성하게 한 뒤 실제 코드를 구현하는 방식을 추천함

• 이제는 이런 기사들이 단순한 리팩토링 작업이나 React 보일러플레이트가 아닌, 실제로 "에이전트가 분산 처리하는" 구체적인 작업 예시를 포함해야 할 시점임을 느낌, Sanity에 오랫동안 요청된 기능들이 있다는데, 에이전트가 상당량을 병렬화 처리한다고 주장함, 그런데 "코드의 80%를 학습하지 않는 주니어 개발자가 썼다"는 식의 주장은 믿기 어려움

  • 내 생각에 "학습하지 않는 주니어 개발자"라는 표현은 잘못됨, Claude는 오히려 실전 경험이 없는 문헌 속 정답만 아는 고학력 시니어에 가깝고, 백과사전적인 지식은 탁월하지만 실전 감각이 부족함, 최근 Claude로 커머셜 코드베이스를 구축하는데 대부분의 입력이 '코드의 맛'과 성공의 정의에 집중되고, 코드 자체는 일회용에 불과함
  • 이렇게 AI 코드가 늘고 있는데, 여전히 오픈소스에는 미해결 이슈가 쌓여 있음, 이 점이 참 아이러니함
  • 실제 AI에 맡긴 작업 예시와 결과를 보여준다면 과장된 기대에 의문을 제기할 기회를 제공할 수 있는데, 실전 예시 없이 Claude Code가 대단하다는 이야기만 계속 올라오는 현실임
  • 세일즈화된 엔지니어가 "레슨" 대신 "러닝스(learnings)" 같은 표현을 사용하는 기술 블로그를 보면, 개발 경력이 쌓이면서 오히려 구글 검색에 덜 의존하고 그냥 문서만 챙겨보는 내 경로와 반대임을 느낌

• 작성자가 생산성 향상이 있다고는 했지만, 흔히 지적되는 한계도 그대로 언급해서 실질적으로는 별 얘기가 없었던 것 같음, 누구도 핵심 기능 개발을 Claude Code에 위임하지는 않을 거라고 확신함

  • Anthropic에서 실현 가능한 방향(특히 프로토타이핑 위주)에 대한 현실적인 시각을 제공한 글이 있다고 생각함 https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135ad8871e7658.pdf

• 보일러플레이트를 피하는 게 개발자의 일이자, 미래의 자신에게 편의를 제공하는 추상화임, AI로 보일러플레이트를 생성하면 추후 전체 인스턴스를 일일이 변경해야 할 때 오히려 불편함이 커지고, 여러 군데에 흩어진 보일러플레이트 코드가 불일치하면 문제는 더 커짐

  • 프레임워크나 도구들이 이미 대부분 보일러플레이트 자동 생성기를 포함하고 있는데 굳이 AI에 토큰과 비용을 들여서 이걸 시키는 게 그리 큰 가치인지 의문임

• 흥미로운 점은 이 사람은 AI로 기초 구현을 시도하는데, 나는 반대로 반드시 기반을 직접 먼저 구축함, 그래야 구조와 작동 원리를 정확히 이해할 수 있으므로 이후엔 AI에게 반복성 있는 보일러플레이트만 맡기면 됨, AI는 따라 쓰기는 잘 하지만 아키텍처 설계에는 굉장히 취약함

  • LLM은 유지보수 가능한 아키텍처를 계획하는 것이 매우 약함, 코드가 발전함에 따라 구조를 리팩터링하지 못하고, 맥락 이해 한계로 여기서 한계가 있을 수 있음

• 기본 연봉도 비싼데 거기에 월 1천에서 1.5천 달러씩 추가 비용을 들여 생산성이 오를지도 모르는 사소한 문제에 투자해야 한다는 주장에 의문임, 최소한 내 상사는 좋아하지 않을 것 같음

  • 하드웨어 업체들은 개발자 인건비보다 비싼 각종 EDA 툴 라이선스를 연례적으로 구매함, 만약 생산성이 눈에 띄게 좋아진다면 1천 달러쯤은 아무것도 아닌 셈임
  • 개발자 연봉이 그렇게 비싸다면 오히려 투자하지 않는 게 비합리적임, 월 1-1.5k 달러로 생산성을 확실히 높일 수 있다면 그걸 망설이는 쪽이 비효율적이고, 이런 관점에서 AI 투자 비용만 따지는 것은 너무 단순화된 시각임을 강조함, AI로 개발자 수를 줄일 수 있다면 그 역시 실제 절감 효과임
  • 본인은 intellij pro AI로 월 20달러도 채 못 쓰고 있는데, Claude가 정말 그렇게 비싼지 의문이 들어 찾아보니 실제로 그럴 수 있긴 함, 어쨌든 어딘가의 예산에 AI 구독료가 추가되는 게 현실이고, 이미 회사가 고성능 인터넷 비용을 지불하는 것과 똑같이 AI 비용도 기본이 되고 있음
  • 그리고 이 가격도 사실 보조금 기반임을 기억해야 함
  • 앞으로 기업들이 어떻게 변화할지 흥미롭게 보고 있음, 확실한 건 결국 개발자가 어떤 기준으로 평가받을지가 관건임, AI 사용으로 인해 인사고과/해고 등에서 불이익을 받을 위험이 커지는지, 그리고 LLM이 아닌 본인이 성과의 주역임을 어떻게 입증할지가 중요 이슈임

• 본문에서 언급된 MCP(Multi-Channel Processor) 활용 방식이 이해가 잘 안 됨, Claude code는 curl이나 gh 등으로 셸에서 써드파티 서비스를 거의 다 호출할 수 있는데, MCP를 쓰면 오히려 문제가 있을 수 있음(예: linear MCP 서버는 이슈가 너무 길면 자르지만, 직접 API 호출하면 이런 제한이 없음), 뭔가 내가 빠뜨린 점이 있는지 궁금함

• Anthropic이 Boris Cherny(Claude Code의 창시자)와의 인터뷰를 올렸는데, Claude Code의 에이전트 코딩 미래와 활용법에 대한 아이디어도 공유함 https://youtu.be/iF9iV4xponk

• "$1000-1500/월 예산" 언급을 보며, 혹시 API 키만 쓰고 claude MAX 같은 월정액 플랜 정보를 모르는 건 아닌가 하는 생각이 듦, $100~200/월이면 무작정 쿼리만 반복하는 게 아니라면 충분히 커버된다 봄

  • $1k-1.5k는 너무 비싼 수치임을 느낌, 20배짜리 Max 플랜도 월 $200에 충분히 많은 사용량을 커버하고, 5시간마다 사용량이 초기화됨, 그럼에도 불구하고 한도를 매일 초과한다면 그 정도면 토큰 단위 결제가 오히려 더 비쌀 수도 있음

• Claude나 기타 에이전트 쓸 계획이면 반드시 로깅을 강추함, 로그 파일 전체를 AI에 넣으면 문제를 정리해서 답을 얻거나 다음 단계로 진입할 수 있는 확률이 높아짐, 로깅은 정말로 모든 것임