Claude Code 개발팀이 Claude Code를 쓰는 방법

날짜: 2026-09-03
채널: Tech Bridge
원문 제목: [한영자막] Claude Code 개발팀이 Claude Code를 쓰는 방법
URL: https://www.youtube.com/watch?v=Bo2ImHzgOwc

---

📌 핵심 질문 / Claude Code 개발팀은 어떻게 AI에게 개발 목표를 위임하는가

==Claude Code의 진짜 변화는 개별 프롬프트와 도구 호출을 감시하는 방식에서 벗어나, 목표를 주고 검증·리뷰·피드백까지 이어지는 자율적인 개발 루프를 운영하는 방식으로 이동한 데 있다.==

• Claude Tag는 Slack 네이티브 에이전트(Slack-native agent)로서 대화, 제품 결정, 이벤트, 이슈 등 개발 환경 바깥의 맥락까지 가져와 판단에 반영한다.
• 모델은 약 두 달마다 근본적으로 바뀌므로, 현재 모델의 실패를 보완하던 하네스(harness) 기능을 과감히 없애고 더 큰 작업을 처리할 새 도구를 계속 만들어야 한다.
• 클라우드 컨테이너, 루프(loops), 루틴(routines), 팬아웃(fan-out), 워크플로우(workflows), 검증(verification)이 세션 단위의 코딩을 지속적인 자율 개발 시스템으로 확장한다.

Claude Code 팀의 업무는 모델에게 “이 함수를 작성하라”고 시키는 수준에서 “이 목표를 달성하라”고 위임하는 수준으로 이동했다. 그 결과 엔지니어의 가치는 모든 토큰과 도구 호출을 직접 통제하는 데서 제품 맥락을 제공하고, 큰 방향을 정하고, 결과를 검증하며, 더 나은 문제를 선택하는 데로 옮겨간다.

1. 목표 중심 위임으로 바뀐 Claude Code 사용법

1.1. 1년 사이에 바뀐 작업 단위

Claude Code 팀은 짧은 코드 조각을 생성하는 도구를 세션 전체의 목표를 수행하는 에이전트로 확장했다.

1. 초기의 작업 방식은 프롬프트와 도구 호출을 세밀하게 관리하는 방식이었다.

   1. 출발점: 약 1년 전에는 Claude Code에 프롬프트를 입력하고, 결과에 피드백을 주고, 권한 프롬프트(permission prompt)를 하나씩 승인하는 흐름이 중심이었다.
   2. 현재와의 대비: 당시에는 모델의 각 도구 호출과 개별 의사결정을 따라가는 일이 중요했지만, 지금은 그 과정을 확대해서 보지 않고 달성할 목표를 먼저 정의한다.

2. 현재의 작업 단위는 목표(goal)다.

   1. 위임 방식: “이 클래스(class)를 구현하라”나 “이 함수를 작성하라”보다 복잡하고 긴 작업을 목표로 전달하고 Claude가 목표를 달성하도록 맡긴다.
   2. 엔지니어의 시선: 어떤 도구를 어떤 매개변수로 호출하는지 매 순간 감시하기보다, 원하는 결과를 명확히 표현하고 결과가 목표에 부합하는지 확인한다.

1.2. Slack 네이티브 에이전트 Claude Tag의 맥락 활용

Claude Tag는 Slack 안에서 작동하며 대화와 팀의 제품 지식을 개발 업무에 연결한다.

1. 복잡한 문제를 Claude Tag에 맡긴다.

   1. 업무 비중: 한 엔지니어는 현재 업무의 70~80%가 Claude Tag에서 일어나고, 나머지 약 20%는 무언가를 다듬거나 직접 세밀하게 관리해야 할 때 TUI(terminal user interface) 또는 데스크톱 앱을 연다고 설명했다.
   2. 문제의 수준: Claude Tag에 주는 문제는 초기의 단순한 클래스·함수 구현보다 훨씬 복잡하고 어렵다.

2. Slack의 제품 맥락이 에이전트의 판단을 개선한다.

   1. 추가 정보: Claude Tag는 Slack 네이티브 에이전트이므로 “이 제품의 맥락은 무엇인가”, “팀이 이 제품에 관해 어떤 결정을 내렸는가”를 Slack에서 찾아볼 수 있다.
   2. 판단의 질: 제품의 의도와 팀의 결정을 이해한 뒤 그 정보를 자신의 선택에 반영하므로, 코드 저장소만 읽을 때보다 상황에 맞는 결정을 내릴 가능성이 높아진다.

3. 개발 생명주기 전체가 연결된다.

   1. 연결되는 활동: Claude Code 팀은 Claude Tag를 검증(verification), 코드 리뷰(code review), 브레인스토밍(brainstorming), 모니터링(monitoring)에 사용한다.
   2. 의미: 코드를 생성하는 순간뿐 아니라 제품 결정을 세우고, 구현을 확인하고, 사용자의 반응을 수집하는 과정까지 하나의 에이전트 업무 흐름으로 묶인다.

2. 모델의 변화 속에서 제품을 만드는 법

2.1. 기술의 수명이 몇 년에서 두 달로 줄어들다

AI 제품의 기반 기술은 제품이 완성된 뒤에도 계속 바뀌므로, 현재의 요구를 충족하면서 다음 모델의 능력까지 대비해야 한다.

1. 모델은 제품 아래에서 계속 교체된다.

   1. 기존 소프트웨어의 기대: 과거에는 제품을 만들면 그 기반 기술이 몇 년 이상 유지될 것이라는 확신을 어느 정도 가질 수 있었다.
   2. AI의 현실: AI 모델을 사용하는 제품에서는 기반 기술이 약 두 달마다 근본적으로 바뀐다.
   3. 변화의 압축: 시간이 갈수록 이 변화 주기가 더 짧아질 수도 있으므로, 엔지니어는 프런티어(frontier)를 따라가고 때로는 프런티어보다 앞서야 한다.

2. 현재 사용자 가치와 미래 기술 사이의 균형을 잡아야 한다.

   1. 현재의 의무: 아직 오지 않은 모델만 기다릴 수 없으므로, 오늘 사용자가 쓰는 모델로 지금 당장 가치를 제공해야 한다.
   2. 균형의 성격: 빠르게 움직이는 기술을 위한 설계는 일부 예술(art)이면서 일부 과학(science)인 균형 잡기다.
   3. 엔지니어의 역할: 모델의 능력이 어디로 향하는지 이해하는 동시에, 현재 능력의 경계에서 제품이 유용하게 작동하도록 만든다.

2.2. “파도를 탄” 기능과 빠른 소멸

To-do list는 특정 시점의 모델 약점을 정확히 보완했지만, 모델이 좋아지자 더 이상 필요하지 않게 된 대표적인 사례다.

1. Sonnet 3.5 시기의 장기 작업 한계가 기능을 만들었다.

   1. 실패 양상: 당시 모델은 긴 시간 범위의 작업(long-horizon work)을 잘 수행하지 못했다.
   2. 구체적 예: 할 일을 다섯 개 주면 세 개를 처리한 뒤 포기해버리는 경우가 많았다.
   3. 해결책: 팀은 To-do list를 제공하면 모델이 작업을 끝까지 이어갈 수 있을 것이라고 판단했고, 실제로 매우 잘 작동했다.

2. 모델 개선은 기능의 수명을 끝낸다.

   1. 당시의 적합성: To-do list는 그 시점에 정확히 필요한 기능이었고, 팀은 “바로 이것이 지금 필요한 것”이라는 확신을 얻었다.
   2. 1년 뒤의 변화: 약 1년 후에는 더 복잡한 메모리 상태(memory state) 등을 활용할 수 있게 되어 To-do list에 의존할 필요가 거의 사라졌다.
   3. 설계 태도: 만드는 기능에 애착을 갖지 않아야 한다. 모델이 좋아지면 기능은 빠르게 사라질 수 있기 때문이다.

3. 하네스는 실패를 가리고, 동시에 다음 능력을 담는 구조다.

   1. 현재 모델 보완: Claude Code 하네스에 들어간 기능 상당수는 현재 모델이 보이는 실패 모드를 보완하기 위해 추가됐다.
   2. 과감한 삭제: 모델이 나아지면 예전에 넣은 기능이 더 이상 관련 없다고 판단하고 제거할 자유가 생긴다.
   3. 새로운 요구: 모델이 더 큰 작업을 맡게 되면, 일관성을 유지하고 결과를 잘 내도록 돕는 도구의 종류도 달라진다.

2.3. 작은 팀이 프런티어에서 제품을 다시 쓰다

Claude Code 팀은 모델의 능력 변화에 맞춰 짧은 시간 안에 제품의 큰 부분을 바꾸는 조직적 속도를 요구받는다.

1. 모델 변화가 팀 운영까지 바꾼다.

   1. 큰 변화의 필요: 모델이 갑자기 좋아지면 “이제 완전히 새로운 능동형 에이전트(proactive agent)가 필요하다”고 판단하고 빠르게 대규모 변경을 시작해야 한다.
   2. 동시 진행: 새로운 에이전트를 만드는 동안 권한 시스템(permission system)을 다시 쓰고, 아티팩트(artifact)를 만드는 기능도 함께 구축해야 한다.
   3. 조직 형태: 빠른 변화와 동시에 여러 기반 요소를 바꾸려면 작은 팀이 긴밀하게 움직여야 한다.

2. Claude Code 팀은 소프트웨어 개발의 미래를 압축해서 경험한다.

   1. 비유: 일반 제품보다 훨씬 짧은 수명 주기와 프런티어 유지 압력을 받으므로, 팀은 소프트웨어 개발이 향하는 방향을 압축해서 보여주는 “쌍곡선 시간 챔버(hyperbolic time chamber)”처럼 작동한다.
   2. 일반 엔지니어에게 주는 요구: 모든 제품이 같은 속도로 움직이지는 않지만, 엔지니어는 능력이 어디로 가는지 이해하고 Claude에 대한 자신의 멘털 모델(mental model)을 계속 갱신해야 한다.

2.4. AskUserQuestion에서 인터랙티브 아티팩트로

모델과 사용자의 상호작용 방식도 모델 능력에 따라 빠르게 변한다.

1. AskUserQuestion 도구는 상호작용을 위한 원시 기능이었다.

   1. 초기 구상: Claude가 사용자와 상호작용하도록 만들고, 처음에는 계획(planning) 단계가 끝난 뒤 사용자에게 질문하도록 설계했다.
   2. 설계 전환: 이후 계획 단계에 고정하지 않고 Claude가 필요할 때 호출하는 도구로 바꿨다.
   3. 어려움: Claude가 도구를 적절한 순간에, 올바른 방식으로 호출하게 만드는 설계에 오랜 시간이 걸렸다.

2. 모델이 좋아지자 질문 방식이 아티팩트로 이동했다.

   1. 능력의 변화: AskUserQuestion을 잘 호출하지 못하던 모델이 점점 도구를 잘 사용하게 됐다.
   2. 현재의 대안: 이제는 직접 질문 도구를 많이 쓰기보다, Claude에게 아티팩트를 만들게 하고 그 아티팩트가 사용자에게 질문하도록 한다.
   3. 표현 수단: 아티팩트는 HTML, 다이어그램(diagram), 목업(mock-up) 등을 포함해 질문을 단순한 텍스트보다 풍부한 인터페이스로 만든다.

3. 원시 프리미티브가 층층이 결합해 제품이 된다.

   1. 프리미티브(primitive)의 예: 권한은 어떻게 작동하는가, 시각화(visualization)는 어떻게 작동하는가와 같은 기초 기능을 먼저 만든다.
   2. 결합 효과: 개별 프리미티브가 권한, UI, 에이전트 실행, 피드백 루프와 함께 층층이 쌓이며 Claude Tag 같은 더 높은 수준의 경험을 만든다.

3. 로컬 세션에서 클라우드 루프와 루틴으로

3.1. 노트북을 끄지 못하던 문제에서 시작하다

루프는 “에이전트가 실행되는 장소와 시간이 현재 세션에 묶여 있다”는 문제를 해결하는 과정에서 나왔다.

1. 로컬 실행은 물리적 제약을 만들었다.

   1. 초기 방식: 한 엔지니어는 모든 작업을 자신의 노트북에서 로컬로 실행했다.
   2. 중단 문제: 집에 돌아가야 해서 노트북을 닫으면 에이전트도 더 이상 실행되지 않았다.
   3. 농담 섞인 불편: 노트북을 켜둔 채 주차장까지 가야 하는 상황을 상상하면, 사람들이 이상하게 볼 것이라는 웃음이 나왔다.

2. 원격 개발 박스는 실행을 분리했다.

   1. 전환: 팀은 원격 호스팅 개발 박스(remote hosted developer box)를 사용하기 시작했다.
   2. 장점: 노트북을 계속 켜둘 필요 없이 호스팅 환경에서 에이전트를 실행할 수 있었다.
   3. 남은 마찰: 여전히 환경에 SSH로 접속하고 다시 호스팅된 개발 표면(hosted surface)으로 돌아가야 하므로 사용 경험이 완전히 만족스럽지는 않았다.

3. Claude Code on the web은 백그라운드 실행 표면을 만들었다.

   1. 구조: 웹 환경은 계속 실행될 수 있는 호스팅 컨테이너(hosted container)를 제공한다.
   2. 변화: 에이전트가 사용자의 노트북이나 현재 터미널 세션에 묶이지 않고 뒤에서 계속 일할 수 있게 됐다.
   3. 설정 비용: 컨테이너를 개발 환경으로 쓰려면 컨테이너에 실제 개발 환경 접근 권한을 줘야 하므로 시작 설정이 다소 번거롭다.
   4. 생산성 효과: 그 설정은 충분히 할 만하며, 해당 기능을 도입한 뒤 생산성이 10배(10x) 높아졌다고 평가했다.

3.2. 클라우드 실행이 루틴을 가능하게 하다

에이전트가 클라우드에서 계속 실행되면 한 번의 대화가 아니라 반복적인 업무를 맡길 수 있다.

1. 루틴(routine)은 주기적인 관찰과 조치를 자동화한다.

   1. 예시 명령: 매일 들어오는 모든 피드백을 확인한다.
   2. 분류: 피드백을 중요도별 버킷(bucket)으로 나눈다.
   3. 조치: Claude가 고칠 수 있다는 확신이 높은 항목을 골라 직접 수정한다.

2. 루프(loop)는 세션의 경계를 한 단계 위에서 깨뜨린다.

   1. 기존 단위: 사용자가 한 세션 안에서 모델에게 프롬프트를 주고, 모델은 해당 대화의 범위 안에서 작업한다.
   2. 새 단위: 이제는 세션 안의 모델을 호출하는 대신, 세션보다 한 단계 위에 있는 시스템에 목표를 프롬프트로 전달한다.
   3. 결과: 상위 에이전트가 여러 세션을 만들고 버그를 고치거나 사용자를 대신해 일을 수행한다.
   4. 연속성: Boris가 자주 이야기하는 루프의 여정은 한 번의 모델 호출에서 시작해, 모델이 계속 관찰하고 조치하는 운영 체계로 넘어가는 과정이다.

4. 코드 리뷰에서 동적 워크플로우를 만들다

4.1. 사람의 코드 리뷰는 작은 흠잡기에서 큰 맥락 확인으로 이동한다

코드가 더 많이 생성될수록 사람은 줄 단위 검토를 모두 떠안는 대신, AI가 걸러낸 결과에서 설계와 맥락을 판단해야 한다.

1. 기존 리뷰에는 읽었다는 신호를 보내는 니트픽(nitpick)이 섞여 있었다.

   1. 전형적 상황: 사람이 코드를 리뷰하면서 작은 지적 세 개를 남긴다.
   2. 숨은 목적: 그 지적들은 실제로 중요한 결함이라기보다, 코드를 꼼꼼히 읽었다는 신호를 보내는 역할을 하기도 했다.

2. Claude가 사소한 수정 사항을 먼저 처리한다.

   1. 자율 처리: Claude가 작은 문제를 찾아 고치고, 사람이 굳이 그 항목을 리뷰하지 않아도 되게 한다.
   2. 사람의 초점: 사람은 사소한 표현이나 스타일보다 더 큰 그림에 집중한다.

3. 사람에게 남는 핵심 질문은 제품 맥락이다.

   1. API 구조: Claude가 왜 이 API가 이런 구조여야 하는지에 대한 전체 맥락을 완전히 이해하지 못할 수 있다.
   2. 서비스 경계: 서비스 경계가 특정 지점에 그어진 이유가 있을 수 있으며, Claude가 코드를 작성할 때 그 조직적·제품적 이유를 충분히 내면화하지 못할 수 있다.
   3. 정보 전달: Claude는 리뷰 과정에서 이런 큰 맥락을 찾아 사람에게 전달하고, 사람은 줄 단위 니트픽에서 벗어나 추상화 수준을 높여 판단한다.

4.2. 팬아웃과 테스트 타임 컴퓨트

코드 리뷰는 여러 에이전트를 동시에 투입한 뒤 결과를 압축하는 팬아웃·수렴 구조의 출발점이 됐다.

1. 팬아웃(fan-out)은 가능한 결함을 넓게 탐색한다.

   1. 탐색 방식: 코드를 여러 관점과 여러 작업으로 나눠 동시에 살피며 모든 버그 후보를 찾는다.
   2. 수렴 단계: 동시에 생성된 많은 결과를 다시 모아 사람이 처리할 수 있는 핵심 결과로 줄인다.
   3. 개념: 많은 추론 시간과 계산을 문제에 투입하는 이 방식을 테스트 타임 컴퓨트(test-time compute)라고 부른다.

2. 적대적 리뷰(adversarial review)는 거짓 양성을 줄인다.

   1. 검증 방식: 발견된 각각의 버그 후보를 세 가지 서로 다른 의견이나 관점에서 다시 검토한다.
   2. 필터링: 여러 관점에서 실제 버그인지 확인한 뒤, 중요하고 사람의 주의가 필요한 항목만 남긴다.
   3. 효과: 단순히 후보를 많이 생성하는 데서 끝나지 않고, 결과에 대한 신뢰도를 높인다.

3. 팬아웃은 코드 리뷰 밖의 문제에도 적용된다.

   1. 성능 문제: 성능 버그나 성능 저하 원인을 여러 방향에서 조사할 수 있다.
   2. 일반 심층 조사: 특정 주제에 대한 깊은 리서치에도 같은 구조를 쓸 수 있다.
   3. 여행 계획 사례: 다음 주 부모님과 Tahoe에 갈 장소를 찾는다면 숙소와 할 일을 여러 검색으로 넓게 조사하고 결과를 다시 추려낼 수 있다.

4.3. 워크플로우는 에이전트가 만드는 에이전트 오케스트레이션이다

워크플로우(workflow)는 결정론적 코드와 에이전트의 유연한 추론을 결합해 대량 탐색 결과를 인간이 신뢰할 수 있는 출력으로 바꾼다.

1. Claude는 팬아웃의 하네스 자체를 설계할 수 있다.

   1. 토폴로지(topology): 어떤 하위 에이전트를 몇 개 만들고 어떻게 연결할지 Claude가 결정한다.
   2. 데이터 연결: 한 에이전트의 출력을 다음 단계 에이전트의 입력으로 넘기는 방식을 구성한다.
   3. 최종화: 각 단계의 결과를 마지막에 요약해 사용자에게 돌려주는 구조를 만든다.
   4. 확장성: 이런 구조가 워크플로우와 데이터 스택(data stack)의 발전을 이끈 출발점이 됐다.

2. Tahoe 여행 검색은 맵리듀스(map-reduce) 구조를 보여준다.

   1. 맵 단계: Tahoe의 배스하우스, 호텔, Airbnb, 갈 만한 장소처럼 서로 다른 검색 요청을 열 개가량 동시에 보낸다.
   2. 정렬 단계: 여러 에이전트가 수집된 결과를 정렬하고 흥미롭거나 적합한 후보를 고른다.
   3. 검증 단계: 다른 에이전트가 후보의 사실과 품질을 확인한다.
   4. 리듀스 단계: 검증된 결과를 사람이 읽고 의사결정할 수 있는 최종 답으로 요약한다.

3. 정보량을 줄이는 과정이 신뢰를 만든다.

   1. 팬아웃의 문제: 넓게 조사하면 정보가 너무 많아져 사람이 원시 결과를 그대로 읽을 경우 오히려 처리할 수 없게 된다.
   2. 맵리듀스의 필요: 넓게 펼친 정보를 다시 필터링해 인간 소비(human consumption)에 맞는 크기로 줄여야 한다.
   3. 추론 계산의 역할: 테스트 타임 컴퓨트를 더 투입해 후보를 상호 검증하면 최종 답에 대한 확신을 높일 수 있다.

4. 결정론적 코드가 에이전트 행동에 일관성을 부여한다.

   1. 혼합 구조: 에이전트는 하위 에이전트를 오케스트레이션하는 코드를 직접 작성하므로, 정해진 코드 동작과 에이전트형 언어 모델 행동이 섞인다.
   2. 신뢰의 근거: Claude가 작성한 워크플로우 안에 모든 항목을 순회하는 for 루프가 있으면, 특정 항목 하나를 건너뛰지 않고 동일한 기법을 모든 항목에 적용한다는 점을 알 수 있다.
   3. 감독 수준의 변화: 사람은 하위 에이전트의 모든 추론을 감시하지 않고, 워크플로우 구조가 의도한 반복과 연결을 보장하는지 확인한다.

5. Claude Tag로 Claude Tag를 만들고 운영하다

5.1. 개발 환경 자체를 자율 에이전트에 맞추다

Claude Tag는 단순한 사용 대상이 아니라 자신을 개발하고 테스트하는 개발 표면이 됐다.

1. Claude Tag가 자기 자신을 개발한다.

   1. 사용 방식: Robert Boyce는 Claude Tag를 매우 공격적으로 사용해 Claude Tag 자체를 만들고 있다.
   2. 개발자의 집중점: Claude Tag가 자기 자신을 개발하는 일을 막힘없이 수행하도록 만드는 일이 주요 업무가 됐다.
   3. 개발 루프: Claude가 사람이 소프트웨어를 만들고 엔드투엔드(end-to-end)로 동작을 테스트할 때 필요한 모든 일을 수행할 수 있도록 개발 환경과 개발 루프를 단순하게 만든다.

2. 통합 시스템이 복잡해질수록 에이전트의 개발 능력이 중요해진다.

   1. 복잡성 증가: 여러 시스템이 강하게 통합된 소프트웨어를 만들수록 빌드, 실행, 테스트, 확인 과정은 어려워진다.
   2. 목표: Claude가 복잡한 통합 기능도 직접 만들고 끝까지 확인할 수 있도록 환경을 설계한다.

5.2. Slack UI는 토큰 트랜스크립트에서 한 단계 떨어진다

Claude Tag의 Slack 인터페이스는 모델의 내부 실행을 모두 보여주는 대신, 에이전트가 판단한 메시지만 사용자에게 전달한다.

1. 사용자 인터페이스(UI)가 트랜스크립트와 분리됐다.

   1. 새로운 추상화: 이것은 Claude가 출력하는 실제 토큰 수준에서 한 단계 위의 추상화다.
   2. 메시지 전달: Slack에서 Claude Tag가 보내는 메시지는 사용자에게 메시지를 전송하는 도구를 호출한 결과다.
   3. 숨겨진 내부 과정: 에이전트의 내부 독백(internal monologue)은 Slack에 보이지 않으며, 필요할 때 전체 Claude 트랜스크립트를 볼 수 있는 링크만 제공된다.

2. 트랜스크립트를 보지 못하는 불안이 자율성의 조건이 된다.

   1. 초기 불안: 모델이 무엇을 생각하는지 전부 볼 수 없고, 어떤 도구와 매개변수를 쓰는지 모른다는 점은 처음에는 두려웠다.
   2. 얻은 자유: Claude가 사용자에게 무엇을 언제 말할지 스스로 선택하므로, 사용자는 각 도구 호출의 세부사항을 계속 관리하지 않아도 된다.
   3. 강제 함수: “Claude가 요리하게 두기(let Claude cook)”를 강제받으면서, 세부 트랜스크립트를 감독하지 않아도 좋은 결과를 내는 모델이 실제로 충분히 좋아졌다는 사실을 체감하게 됐다.

5.3. 아이디어 검증부터 사용자 피드백까지 Slack에서 연결하다

Claude Tag는 새 도구를 만들 때 이해관계자 조사, 목업, 구현, 배포, 사용 분석, 피드백 대응을 한 흐름으로 이어준다.

1. 아이디어의 매입과 설계를 함께 진행한다.

   1. 이해관계자 탐색: 새 도구를 만들기 전에 자신의 아이디어에 관심을 가질 사람과 누구에게 이야기해야 할지를 Claude에 묻는다.
   2. 목업 제작: 이해관계자를 정한 뒤 Slack 안에서 목업을 만든다.
   3. 모바일 접근성: Slack 기반이므로 휴대전화에서도 목업을 확인하고 다음 작업을 지시할 수 있다.

2. 구현과 관측 가능성(observability)을 동시에 넣는다.

   1. 구현: Claude가 아이디어를 실제 도구로 구현한다.
   2. 이벤트 추가: 도구가 실제로 잘 작동하는지 확신할 수 없으므로 사용 단계마다 많은 이벤트(event)를 심는다.
   3. 내부 배포: 도구를 내부에 배포하고 사람들이 실제로 어떻게 사용하는지 관찰한다.

3. Claude Tag가 사용 현황과 피드백을 감시한다.

   1. 모니터링: Claude Tag가 이벤트를 모니터링하고 사람들이 도구를 어떻게 사용하는지 확인한다.
   2. 피드백 알림: 다른 사람이 피드백을 주면 Claude Tag가 해당 개발자에게 알려준다.
   3. 업무 효과: 개발자는 즉시 대화에 들어가 더 빠르게 반응할 수 있고, 도구가 제대로 작동한다는 확신도 높아진다.

4. 퍼널 최적화도 목표 수준에서 위임한다.

   1. 발견된 문제: 이벤트를 살펴보니 사용자가 퍼널(funnel)의 끝까지 진행하지 않는 흐름이 보였다.
   2. 기존 접근: 처음에는 개발자가 자신의 개선 아이디어를 직접 구현하려 했다.
   3. 새 접근: 대신 “퍼널을 개선하라”고 Claude에 요청하고, 자신의 아이디어는 예시로만 제공하면서 더 많은 개선안을 스스로 제안하게 했다.
   4. 고도화: 구현 방법을 일일이 지시하는 대신 목표와 사례를 주고 더 높은 수준에서 협업한다.

5.4. 검증·코드 리뷰·피드백은 세 가지 핵심 프리미티브다

자율 개발을 신뢰하려면 생성만 자동화할 것이 아니라 결과를 확인하고 사용자 반응을 되돌려보내야 한다.

1. 세 가지 프리미티브가 자율 루프를 닫는다.

   1. 검증: 코드나 제품이 의도대로 동작하는지 확인한다.
   2. 코드 리뷰: 변경의 품질과 더 큰 설계 맥락을 검토한다.
   3. 피드백: 데이터 저장소(data store), 이벤트 저장소(event store), 메트릭(metrics), Slack, GitHub 이슈 등에서 실제 사용 반응을 가져온다.

2. 검증은 Claude Code 팀이 특히 중시하는 분야다.

   1. PR 검증: Claude가 Claude Code용 풀 리퀘스트(PR)를 만들면 테스트를 실행한다.
   2. 시각적 확인: 변경 결과가 어떻게 보일지 스크린샷을 보내 사용자가 코드뿐 아니라 화면 결과까지 확인하게 한다.
   3. 신뢰 형성: 생성된 코드, 실행 테스트, 시각적 결과를 함께 확인하면 에이전트가 만든 변경을 받아들일 근거가 생긴다.

3. 사람의 최소 확인은 여전히 유효하다.

   1. 기록 요청: 새 도구를 만들 때 먼저 Claude에게 TUI를 사용해 스스로 동작을 녹화하게 했다.
   2. 직접 실행: 그 뒤 개발자가 직접 복제하고 실행해 보며 최소한의 sanity check를 했다.
   3. 전망: 모델과 검증 루프가 더 좋아지면 직접 복제해 확인하는 단계도 줄어들 수 있지만, 현재는 신뢰를 위한 합리적인 보조 절차다.

6. AI 시대에 소프트웨어 엔지니어의 가치가 바뀌다

6.1. 프리미티브가 늘어날수록 멘털 모델과 거시적 사고가 필요하다

지난 1년의 발전은 기능 몇 개를 추가한 수준이 아니라, 엔지니어가 시스템을 바라보는 추상화 수준을 바꿨다.

1. Claude Code 위에 자동 모드·메모리·워크플로우가 쌓였다.

   1. 진화 순서: Claude Code를 만든 뒤 자동 모드(auto mode), 메모리(memory), 워크플로우 같은 프리미티브를 차례로 추가했다.
   2. 인지 부담: 개발자는 동시에 무슨 일이 일어나는지, 각 기능을 언제 써야 하는지 계속 파악해야 하므로 추적해야 할 것이 많아졌다.

2. 소프트웨어 엔지니어링은 가능한 일을 다시 정의하는 일이다.

   1. 지속된 질문: 엔지니어는 원래도 “지금 무엇이 가능한가”, “무엇을 더 자동화할 수 있는가”를 계속 물어왔다.
   2. AI 시대의 확대: 이제 자동화 가능한 범위와 에이전트가 맡을 수 있는 작업의 규모가 빠르게 커졌다.
   3. 거시적 사고: 세부 구현에서 잠시 물러나 더 큰 문제와 목표를 생각하는 능력이 더욱 중요해졌다.

6.2. 성능 최적화의 즐거움에서 아이디어의 실현 속도로

AI가 세부 구현을 잘 수행하면서 엔지니어의 만족과 주의가 향하는 지점이 바뀐다.

1. 성능 엔지니어링(performance engineering)은 AI가 대신하는 영역이 됐다.

   1. 과거의 즐거움: 한 엔지니어는 시스템 내부를 깊이 파고들어 성능을 높이는 성능 엔지니어링에서 큰 즐거움을 얻었다.
   2. 현재의 평가: 이제는 Claude가 자신보다 성능 개선을 더 잘한다고 느낀다.
   3. 남은 보상: 직접 모든 최적화를 수행하지 않아도 실제 성능 향상의 혜택은 계속 누릴 수 있다.

2. 아이디어를 현실로 옮기는 속도가 새 관심사가 됐다.

   1. 가속된 경로: 아이디어에서 프로토타입(prototype)을 거쳐 프로덕션(production)에 도달하는 시간이 크게 짧아졌다.
   2. 관심의 이동: 엔지니어의 주의가 특정 구현의 깊은 내부를 파고드는 일에서 어떤 새 아이디어를 얼마나 빨리 현실로 만들지로 이동했다.
   3. 추상화 변화: 세부 사항을 완전히 버리는 것이 아니라, 필요한 때 내려다볼 수 있는 더 높은 줌아웃(zoomed-out) 관점에서 일한다.

6.3. 세밀한 UI 구현이 누구나 접근 가능한 능력이 되다

AI는 기술적 장벽 때문에 포기하던 아이디어를 구체적인 소프트웨어로 바꾸는 도구가 된다.

1. 과거에는 UI 디테일에 하루를 썼다.

   1. 개인 사례: 한 엔지니어는 개인 웹사이트에서 Mac OS X 10.4 Aqua의 버튼을 CSS로 정밀하게 재현했다.
   2. 구현 방식: 여러 방사형 그라디언트(radial gradient)를 층층이 쌓아 원본과 같은 모습을 만드는 데 하루 정도를 썼다.
   3. 현재의 선택: 이제 Claude가 이런 세부 작업을 대신할 수 있으므로 직접 처음부터 수작업으로 구현하지 않는다.

2. PowerPoint에서 소프트웨어 엔지니어링 전체로 접근성이 확장됐다.

   1. 어린 시절의 도구: 일곱~여덟 살 무렵 비디오게임을 만들고 싶었지만 코딩을 몰랐고, PowerPoint에서 도형을 그리고 클릭 가능한 요소를 만들어 게임처럼 작동시켰다.
   2. 도구의 의미: 당시에는 PowerPoint가 기술 지식 없이 아이디어를 표현하게 해주는 도구였다.
   3. Claude의 확장: 지금의 Claude는 소프트웨어 엔지니어링 전체를 그런 방식으로 접근 가능하게 만든다.
   4. 작업 방식: 기술적 능력이 부족해 문제를 풀 수 없다고 멈추는 대신, 달성하려는 것을 말하고 작은 문제로 나눠 Claude와 해결한다.
   5. 결과: 소프트웨어 엔지니어링 영역 전체가 자신의 능력 범위 안에 들어온다는 감각과 흥분을 준다.

6.4. 도구는 바뀌어도 문제 해결은 남는다

소프트웨어 엔지니어링의 본질은 기술의 변화가 아니라 변화하는 도구로 새로운 문제를 해결하는 데 있다.

1. 소프트웨어 엔지니어링은 변화의 직업이다.

   1. 과거와 현재: 10~20년 전에는 프레임워크 없이 JavaScript를 직접 작성했지만, 이후 프레임워크와 컴파일러 같은 추상화가 발명됐다.
   2. 현재의 속도: 그 변화가 이제 더 빠르게 일어나고 있을 뿐, 소프트웨어가 도구를 사용해 놀라운 것을 만들고 더 좋은 소프트웨어를 만드는 일이라는 본질은 같다.

2. 문제의 종류는 바뀌어도 문제 해결은 지속된다.

   1. 공통 핵심: 엔지니어가 푸는 문제는 달라지지만, 여러 도구를 조합해 답을 찾는 문제 해결(problem solving)은 그대로 남는다.
   2. 실천적 결론: 특정 기술이나 기능을 영원히 숙달하려 하기보다, 새 능력을 빠르게 이해하고 목표·검증·피드백 루프를 설계하는 역량을 키워야 한다.

주요 발언 모음

“다음 두 달을 생각하기도 어려운데, 하물며 다음 1년을 어떻게 생각하겠나.”

“만드는 것에 애착을 갖지 않아야 한다. 꽤 빠르게 사라질 테니까.”

“사람은 줄 단위로 읽다가 사소한 것을 흠잡는 데 머무르지 말고, 인간 코드 리뷰어로서 생각하는 추상화 수준으로 올라가야 한다.”

“Claude가 요리하게 두는 것, 그리고 세부 트랜스크립트를 감독하지 않아도 좋은 결과를 돌려받는 것이 모델이 실제로 좋아졌다는 사실을 강제해서 보여줬다.”

“소프트웨어 엔지니어링은 변화의 직업이다. 더 빠르게 변하고 있을 뿐, 여전히 문제를 해결하는 일이다.”

핵심 데이터 & 수치

• 약 1년: Claude Code에 합류한 뒤 프롬프트·권한 승인 중심의 사용에서 목표 위임·자율 루프 중심으로 이동한 기간이다.
• 70~80%: 한 엔지니어가 현재 Claude Tag에서 처리한다고 밝힌 업무 비중이다.
• 약 20%: TUI나 데스크톱 앱에서 직접 다듬거나 세밀하게 관리하는 업무 비중이다.
• 약 2개월: AI 기반 제품의 기반 모델이 근본적으로 바뀌는 주기다.
• 5개 중 3개: Sonnet 3.5 시기에 모델이 다섯 가지 작업을 받으면 세 가지를 처리하고 포기하곤 했던 예다.
• 10배: 클라우드 호스팅 환경을 구축한 뒤 체감한 생산성 향상이다.
• 3가지 관점: 코드 리뷰에서 각 버그 후보가 실제인지 확인하기 위해 사용하는 적대적 검토 관점 수다.
• 약 10개 검색: Tahoe 여행 계획에서 숙소·배스하우스·Airbnb·할 일을 폭넓게 찾는 팬아웃 예시의 규모다.
• 7~8세: PowerPoint로 클릭 가능한 비디오게임을 만들려 했던 어린 시절의 시점이다.
• 10~20년: 프레임워크 없는 JavaScript에서 프레임워크와 컴파일러로 이동한 소프트웨어 개발 변화의 회고 범위다.

결론 및 시사점

1. 목표 단위로 위임하라: 도구 호출을 지시하는 대신 달성할 목표와 필요한 제품 맥락을 제공하라.
2. 기능에 애착을 갖지 말라: 모델이 좋아지면 실패 보완용 하네스 기능을 제거하고 더 적합한 프리미티브로 교체하라.
3. 세션을 넘어 루프를 설계하라: 클라우드 컨테이너와 루틴을 이용해 에이전트가 지속적으로 관찰·분류·수정하게 하라.
4. 팬아웃 뒤에 수렴을 배치하라: 여러 에이전트로 탐색 범위를 넓힌 뒤 맵리듀스, 적대적 리뷰, 테스트 타임 컴퓨트로 사람에게 필요한 결과만 남겨라.
5. 결정론과 추론을 결합하라: 에이전트 행동은 유연하게 두되 반복과 데이터 전달은 코드로 고정해 신뢰성을 높여라.
6. 검증·리뷰·피드백을 필수 프리미티브로 만들라: PR 테스트, 스크린샷, 이벤트, 메트릭, Slack, GitHub 이슈를 자율 개발 루프에 연결하라.
7. 추상화 수준을 높여라: 내부 토큰과 도구 호출을 항상 감시하기보다 제품 의도, 서비스 경계, 사용자 가치, 큰 목표를 판단하라.
8. 아이디어의 실현 속도를 활용하라: AI가 구현 세부를 맡는 동안 엔지니어는 더 많은 아이디어를 프로토타입에서 프로덕션으로 옮겨라.
9. 새 기술을 문제 해결 도구로 받아들여라: JavaScript, 프레임워크, 컴파일러, 에이전트가 바뀌어도 문제를 해결해 소프트웨어를 만든다는 본질은 유지된다.

핵심 요약 (20줄)

Claude Code 팀은 개별 도구 호출을 감시하는 방식에서 목표를 맡기고 결과를 검증하는 방식으로 이동했다. Claude Tag는 Slack의 대화와 제품 결정을 읽어 개발 판단에 필요한 맥락을 확보한다. 한 엔지니어의 업무 70~80%는 Claude Tag에서 처리되고 약 20%만 TUI나 데스크톱 앱에서 직접 다듬는다. AI 모델의 기반 기술은 약 두 달마다 바뀌므로 제품은 현재 가치와 미래 능력을 동시에 고려해야 한다. Sonnet 3.5 시기의 To-do list는 다섯 작업 중 세 작업만 처리하던 장기 작업 실패를 보완했다. 모델이 좋아지면 과거의 하네스 기능이 사라지므로 엔지니어는 구현물에 애착을 갖지 않아야 한다. AskUserQuestion은 계획 뒤 호출되는 도구에서 아티팩트가 질문하는 인터랙티브 UI로 발전했다. HTML, 다이어그램, 목업을 포함한 아티팩트는 텍스트 질문보다 풍부한 협업 표면을 제공한다. 노트북 로컬 실행의 중단 문제는 원격 개발 박스와 클라우드 호스팅 컨테이너로 해결됐다. 클라우드 실행은 에이전트가 매일 피드백을 분류하고 확신도 높은 버그를 고치는 루틴을 가능하게 했다. 코드 리뷰에서 Claude는 사소한 니트픽을 처리하고 사람은 API 구조와 서비스 경계를 판단한다. 팬아웃은 여러 에이전트가 버그와 성능 문제를 동시에 찾게 하고 수렴 단계가 결과를 줄인다. 각 버그 후보를 세 관점에서 적대적으로 검토하면 실제로 중요한 문제만 사람에게 전달된다. Tahoe 여행 검색은 여러 검색과 정렬·검증 에이전트를 연결하는 맵리듀스 사례다. 워크플로우의 결정론적 for 루프는 에이전트가 모든 항목에 같은 처리를 적용하도록 신뢰를 높인다. Claude Tag는 자기 자신을 개발하고 테스트하며 Slack에서 내부 트랜스크립트와 분리된 UI를 제공한다. 이해관계자 탐색부터 목업·구현·이벤트 계측·배포·피드백 알림까지 하나의 자율 루프가 이어진다. 검증·코드 리뷰·피드백은 생성된 코드와 제품 결과를 신뢰하기 위한 세 가지 핵심 프리미티브다. 엔지니어의 관심은 성능 최적화의 세부에서 아이디어를 프로토타입과 프로덕션으로 옮기는 속도로 이동한다. AI가 접근성을 높여도 소프트웨어 엔지니어링의 본질인 문제 해결과 변화의 직업이라는 성격은 남는다.