본문은 빈센트 퀴글리(Vincent Quigley)의 글 <First attempt will be 95% garbage: A staff engineer's 6-week journey with Claude Code>을 번역한 글입니다. 빈센트 퀴글리는 현재 콘텐츠 운영 시스템 플랫폼 세니티(Sanity)의 선임 소프트웨어 엔지니어로 일하고 있습니다. 필자에게 허락받고 번역과 게재를 진행했습니다.

18개월 전까지 모든 코드를 제 손으로 직접 작성했습니다. 그러나 이제는 구현한 코드의 80%를 AI가 작성하고, 저는 아키텍처, 리뷰, 여러 개발 작업을 이끌고 조율하는 데 집중합니다.

이 글은 또 다른 “AI가 모든 것을 바꿀 것이다”라는 글이 아닙니다. 그보다는 AI를 실제 프로덕션 개발 워크플로우에 통합할 때 발생하는 복잡한 현실에 관한 것입니다. 무엇이 실제로 작동하는지, 무엇이 시간을 낭비하게 만드는지, 그리고 그 이유에 대해 다룹니다. AI와의 협업 모델에서는 무엇보다 AI를 “학습하지 못하는 주니어 개발자”처럼 대하는 것이 성공적인 방식이 되었습니다.

제가 속한 Sanity에서는 매월 엔지니어링 워크숍을 열어 누군가가 실험한 내용을 발표합니다. 지난번에는 제 차례였고 저는 클로드 코드(Claude Code)를 어떻게 사용해 왔는지 보여주었습니다. 이 글 역시 내부 워크숍 발표에서 소개한 내용입니다.

네 번의 코딩 전환점

제 경력에서 코드에 발생한 문제를 해결하는 방식은 네 차례 전환되었습니다.

처음 5년은 책과 SDK 문서를 읽는 것이었습니다.

그 후 12년은 구글링을 통해 집단 지성을 활용하는 것이었습니다.

그다음 18개월은 커서(Cursor)를 이용하며 AI의 도움을 받는 것이었습니다.

마지막으로 최근 6주는 클로드 코드를 사용해 AI에 완전 위임하고 있습니다.

각 전환은 이전의 전환보다 더 빨리 일어났습니다. 특히 클로드 코드로 전환할 때는 고작 몇 시간 쓰는 것으로 생산성이 향상되었습니다.

나에게 실제로 통하는 AI 개발 방법

지금부터 거품을 빼고, 실제 환경에서의 제 작업 흐름을 설명하겠습니다. 저는 AI를 주로 ‘함께 생각하는 도구’로써 사용하며, 프로덕션 코드 작성에 활용합니다.

보통 세 번의 시도가 필요하다

한 번에 완벽한 코드를 얻겠다는 기대는 잊으세요. 엔지니어로서 할 일은 단순히 코드만 쓰는 것이 아니라 문제에 대한 최적의 해법을 찾는 것입니다.

첫 번째 시도: 생성된 코드의 95%는 쓰레기

클로드가 당신의 시스템에 대한 맥락을 구축한다
당신이 진정한 도전 과제를 찾아낸다
코드는 대개, 전혀 쓸모없는 수준이다

그런 다음 이 시도에서 배운 점을 받아들여 다시 개선합니다.

두 번째 시도: 생성된 코드의 반은 쓰레기

클로드 코드가 뉘앙스를 이해한다
구체적인 접근법을 정의하게 된다
다만, 여전히 쓰는 시간의 반은 불필요한 일로 보인다

세 번째 시도: 드디어 작동하는 코드

클로드 코드가 결과를 정제해서 쓸 만한 코드를 구현한다
끊임없이 검토하고 방향을 수정한다
최종 코드가 아니라 코딩의 시작점을 만들어 준다

이것은 실패의 연속이 아닌 프로세스입니다! 첫 번째 시도에서 완벽함을 기대하는 것은, 주니어 개발자가 맥락 이해 없이 복잡한 기능을 딱 맞게 구현하길 바라는 것과 같습니다.

맥락의 문제 그리고 해결책

가장 큰 도전 과제가 뭘까요? AI는 대화를 이어가면서 학습을 유지하지 못한다는 겁니다(당신이 시간을 써서 직접 ‘기억’을 주입해 주지 않는 한). 그래서 보통 모든 대화는 새로 시작됩니다.

이에 대한 저의 해결책을 알려드리겠습니다.

Claude.md 파일들

다음 내용을 포함하며, 프로젝트에 특화된 컨텍스트 파일을 만듭니다.

아키텍처 결정 사항들
당신의 코드에서 쓰이는 공통 패턴
주의할 점과 우회 방법
관련 문서 링크

도구 통합

MCP 덕분에 이제 AI를 다음 도구들과 연결할 수 있습니다.

이슈 트래커*에 이슈 혹은 티켓 등록
노션과 같은 지식 공유 서비스 문서**
개발 용도로 접근할 수 있는 데이터베이스
실제 코드 저장소
Github(과거 PR에 대한 맥락 정보를 얻을 수 있어야 함)

*원문에서는 각각 Sanity에서 쓰는 프로덕트인 Linear, 지식 공유 서비스 Canvas 문서로 표기했지만, 국내에는 일부 생소할 수 있어 보편적으로 해석할 수 있도록 번역했습니다. 이와 같은 컨텍스트가 없으면 같은 제약 조건을 반복 설명해야 하지만, 두 번째 시도부터는 문서 형태로만 전달해도 적용할 수 있습니다.

복수의 AI 개발자를 관리하기

저는 이제 다수의 클로드 인스턴스를 동시에 돌립니다. 마치 매일 아침 메모리를 초기화하는 소규모 개발팀을 관리하는 것과 비슷하죠.

핵심 전략

같은 문제 영역을 복수의 AI에게 시키지 마세요: 어떤 문제를 해결 중인지 헷갈리고 관리가 어렵습니다
모든 작업과 이슈는 Linear(또는 사용하는 다른 프로젝트 관리 툴)에 꼼꼼히 기록하세요
사람이 수정한 코드는 명확히 표시해야 합니다: AI가 자기가 쓴 부분과 수정된 부분을 혼동하기 쉽습니다

3단계 리뷰 프로세스

코딩이 끝났다고 일이 끝난 것은 아닙니다. 코드 리뷰도 마찬가지로 중요합니다. AI 도입은 제 코드 리뷰 프로세스도 발전시켰습니다.

1단계: 클로드 코드로 먼저 리뷰하기

테스트 커버리지 누락 부분을 찾아냅니다
명백한 버그를 발견합니다
개선 사항을 제안합니다

덕분에 저와 동료들이 추가로 수정하는 데 드는 시간이 절약되었습니다.

2단계: 내가 리뷰하는 내용

Sanity에서는 AI로 코드를 생성했더라도 자신이 배포하는 코드에 대해 책임을 집니다. 저는 제가 배포하는 코드가 다음 규칙을 확실히 지켰기를 원합니다.

수정하기 쉬운 코드 형태
적절한 아키텍처 결정
올바른 비즈니스 로직
적절한 코드 통합

3단계: 팀 리뷰가 필요한 이유

리뷰를 안 하면 어떤 코드가 AI가 생성한 것인지 알기 어렵습니다
AI가 작성한 코드에 대해서도 코드 품질 기준은 변함없이 동일하게 유지해야 합니다

핵심은 많은 코드를 직접 타이핑하지 않아서 ‘내 코드’에 대해 더 비판적이이어 졌다는 것입니다. 감정적 애착이 없으니 리뷰가 더 나아집니다.

백그라운드 에이전트 초기 테스트 사례

우리는 간단한 작업에 대해 커서(Cursor)를 이용한 슬랙(Slack) 트리거 에이전트를 테스트 중입니다. 아래 성과를 거뒀습니다.

2개의 비즈니스 로직 수정 성공
1개의 CSS 레이아웃 수정 실패

다만, 현재 한계점은 이렇습니다.

제한적인 NPM 패키지 접근 제어 방법이 없음
AI가 커밋에 서명할 수 없으니, 서명이 없는 코드 발생
이슈 트래커에 등록되지 않아 추적 과정 우회

그래도 잠재력을 생각해 보세요. 에이전트가 당신이 잠든 사이 백로그의 작은 티켓들을 처리하는 것을요. 우리는 Sanity에서 이를 활발히 탐구하며, 여러 팀이 효과적인 방안을 찾아 공유하고 있습니다.

숫자로 본 실질적 비용

돈 이야기를 해봅시다. 클로드 코드의 사용 비용은 월급의 적지 않은 비율을 차지합니다.

하지만 그 투자로 아래 효능이 생깁니다.

기능 배포 속도가 2~3배 빨라졌습니다
여러 개발 작업을 동시에 관리할 수 있습니다
반복적으로 쓰이는 뻔한 코드 작성에는 전혀 시간을 쓰지 않습니다

물론 투자수익은 명확하지만, AI 개발에 전념하는 시니어 엔지니어 한 명당 월 1,000~1,500달러 예산을 사용합니다. 엔지니어들이 AI 사용에 능숙해지면서 비용 효율성이 올라가는 것은 당연하겠지만 시간이 필요합니다.

실제 문제 발생 원인

게다가 AI 지원 개발이 항상 순조로운 것만은 아닙니다. 다음은 제가 지속해서 경험하는 문제점들입니다.

학습 문제

AI는 실수에서 배우지 못합니다. 같은 오해를 반복해서 고쳐야 합니다. 해결책은 더 나은 문서화와 명확한 지침입니다.

자신감 문제

AI는 망가진 코드를 훌륭하다고 주장하며 자신감 있게 작성합니다. 항상 검증하세요, 특히 다음 경우에는요.

복잡한 상태 관리
성능이 민감한 부분
보안에 민감한 코드

컨텍스트 한계 문제

대규모 코드 베이스는 AI 컨텍스트 창을 압도합니다. 문제를 작은 덩어리로 나누고 AI에게 초점을 맞출 컨텍스트를 알려 주세요.

코드에 얽매이던 감정에서 문제 해결로의 마음가짐 변화

가장 어려운 부분은 코드 소유권을 놓아주는 것입니다. 하지만 저는 이제 ‘내 코드’에 신경 쓰지 않습니다. 단지 검토하고 다듬을 출력물으로 바라볼 뿐입니다.

이러한 감정적 분리는 사실 꽤 해방감을 줍니다!

잘못된 해결책을 더 빠르게 제거합니다
더욱 객관적인 코드 리뷰를 진행합니다
감정 개입(자존심) 없이 리팩토링에 임합니다

그렇기에 더 나은 AI 도구가 나타난다면, 즉시 바꿀 것입니다. 코드는 중요하지 않습니다. 그보다는 우리가 푸는 문제가 중요합니다.

기술 리더 입장에서 팀에 주는 의미

기술 리더로서 AI 도입을 고려한다면, 엔지니어 관점에서 다음 5가지를 조언할 수 있습니다.

엔지니어들이 다양한 AI 솔루션을 시도하고 테스트하도록 허용하세요. AI 지원 코딩은 직접 연습하며 익혀야 하는 기술입니다.
가장 반복적인 작업부터 시작하세요. AI가 즉시 빛을 발하는 영역입니다.
실험을 위한 여력을 확보하세요. 첫 달은 혼란스러울 수 있습니다.
코드 리뷰 프로세스를 조정하세요. AI 생성 코드는 다른 검토가 필요합니다.
모든 것을 문서화하세요. 훌륭한 컨텍스트가 효율성을 극대화합니다.

새로운 AI 워크플로우에 빠르게 적응하는 엔지니어는 날카로운 도구를 새로 얻게 됩니다. 그들은 여러 AI 에이전트를 다루면서 아키텍처, 리뷰, 복잡한 문제 해결에 집중하는 지휘자가 됩니다.

개발자가 나아가야 할 다음 방향

작고 명확한 기능 하나를 선택해, AI에게 세 번 구현할 기회를 주세요. 그리고, 주니어 개발자에게 멘토링하듯 결과물을 검토하세요.

그게 전부입니다. 큰 변화나 프로세스 전면 개편은 필요 없습니다. 단지 하나의 기능, 세 번의 시도, 그리고 솔직한 리뷰가 필요합니다.

AI가 개발자를 대체하는 것이 아닙니다. 개발자가 더 빠르게 일하고 더 나은 해결책을 만들 최고의 도구로 AI를 활용하는 것입니다.