[한영자막] Claude Code 개발팀이 Claude Code를 쓰는 방법

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude Code 개발팀은 세부 코드 작성을 지시하는 데서 나아가, 팀 맥락을 아는 에이전트에 목표를 맡기고 검증·리뷰·피드백으로 결과를 확인하는 방식으로 일한다.

📌 핵심 요점

1. Slack에서 일하는 Claude Tag에 더 복잡한 목표를 맡긴다. 팀의 제품 논의와 의사결정 맥락을 활용하며, 한 출연자는 업무의 70~80%를 이 환경에서 수행한다고 말한다.
2. 모델 발전에 맞춰 보조 기능도 바꾼다. 과거 장기 작업의 누락을 줄였던 할 일 목록처럼, 당시 유용했던 장치도 모델이 개선되면 제거하거나 다른 도구로 대체할 수 있다는 설명이다.
3. 클라우드 실행은 일회성 세션을 반복 업무로 확장한다. 매일 피드백을 모아 중요도를 분류하고, 수정에 자신 있는 문제를 처리하는 루틴이 사례로 제시된다.
4. 코드 리뷰는 병렬 탐색과 재검증을 결합한다. 에이전트가 버그 후보를 찾고 여러 관점에서 검토한 뒤, 사람은 API 설계와 서비스 경계 같은 큰 맥락에 집중한다.
5. 자율성의 기반은 실행·검증 환경이다. 테스트, 스크린샷, 사용 기록, 피드백을 연결하고, 개발자는 개별 도구 호출 감시보다 목표 설정과 결과 판단에 더 많은 주의를 쓴다.

🧩 배경과 문제 정의

이 영상은 Claude Code 개발팀이 자신의 도구를 어떻게 사용하며 일하는 방식이 달라졌는지 돌아보는 대화다. 처음에는 프롬프트를 주고 피드백과 권한 요청을 처리했다면, 이제는 Slack의 팀 맥락과 클라우드 실행 환경을 활용해 더 큰 목표를 맡긴다고 설명한다.

핵심 문제는 빠르게 발전하는 모델에 맞춰 개발 도구와 사람의 업무 방식을 어떻게 바꿀 것인가다. 대화는 보조 도구의 수명, 반복 실행, 병렬 리뷰, 검증 환경을 거쳐 개발자의 관심이 세부 구현에서 아이디어와 문제 해결로 이동하는 과정까지 이어진다. 제시되는 성과는 출연자들의 내부 활용 경험이며 독립적인 비교 실험은 아니다.

🕒 시간순 섹션별 상세정리

1. 다음 해도 예측하기 어려운 변화 속도

• 앞으로의 1년을 묻자 두 달 뒤도 생각하기 어렵다는 반응이 나오며, 빠른 변화가 대화의 출발점이 된다. [00:06]
• 합류 후 거의 1년을 돌아보며, 프롬프트와 피드백·권한 요청을 처리하던 시절에서 현재의 업무 방식이 얼마나 달라졌는지 묻는다. [00:34]

2. Slack 맥락을 활용하는 목표 중심 위임

• 한 출연자는 Slack 기반 에이전트가 제품 맥락과 팀의 결정을 찾아 활용하기 때문에, 클래스나 함수 작성보다 복잡한 문제를 맡길 수 있다고 보여준다. [01:20]
• 다른 출연자는 업무의 70~80%가 Cloud Tag에서 이뤄진다고 말하며, 개별 도구 호출을 살피던 방식에서 목표를 전달하는 방식으로 이동했다고 정리한다. [01:52]

3. 짧아지는 기술 수명과 제품 개발의 균형

• 검증·코드 리뷰·브레인스토밍·모니터링까지 업무 범위가 넓어진 가운데, 기존 소프트웨어 제품과 현재의 개발 경험을 비교한다. [02:21]
• 기술 기반이 수년간 유지되던 경험과 달리 AI 모델은 두 달마다 근본적으로 달라진다고 표현하며, 미래 역량을 탐색하면서 현재 사용자에게도 가치를 제공해야 한다고 보여준다. [03:11]

4. 할 일 목록과 하네스의 역할 변화

• Sonnet 3.5 무렵에는 다섯 가지 일을 주면 세 가지만 하고 멈추는 문제가 있었고, 할 일 목록이 이를 보완하는 데 효과적이었다고 회고한다. [03:45]
• 이후 더 복잡한 메모리 상태 등을 활용하게 되면서 기존 장치의 필요성이 줄었으며, 모델의 실패를 보완하던 기능도 작업 규모와 역량 변화에 맞춰 교체해야 한다고 드러낸다. [04:47]

5. 작은 팀의 빠른 재설계와 질문 인터페이스

• 모델 발전에 맞춰 능동형 에이전트를 만들면서 권한 시스템과 아티팩트도 개발해야 한다며, 엔지니어가 모델 역량에 대한 이해를 계속 갱신해야 한다고 강조한다. [05:38]
• 사용자에게 질문하는 도구를 설계한 경험에서 출발해, 최근에는 HTML과 목업을 담은 아티팩트로 질문을 주고받는 방식까지 활용한다고 보여준다. [06:40]

6. 로컬 실행에서 클라우드 반복 업무로

• 노트북을 닫으면 에이전트가 멈추는 불편 때문에 원격 개발 환경을 사용했고, 이후 웹의 호스팅 컨테이너로 이어졌다고 보여준다. [07:43]
• 개발 환경 접근 설정은 번거롭지만 가치가 있었다며, 한 출연자는 도입 이후 생산성이 10배 높아졌다고 개인적인 체감을 드러낸다. [08:04]
• 클라우드에서 매일 피드백을 수집·분류하고 수정에 자신 있는 문제를 처리하는 루틴을 예로 들며, 단일 세션보다 상위 수준에서 작업을 지시하는 변화를 보여준다. [08:50]

7. 코드 리뷰에서 사람이 집중할 대상

• 생성되는 코드가 늘면서 리뷰 방식도 바뀌며, Claude가 작은 지적을 찾아 처리해 사람이 집중할 부분을 고르는 데 도움을 준다고 드러낸다. [09:57]
• 사람에게 중요한 검토 대상으로 API 구조의 이유와 서비스 경계의 배경을 들며, 줄 단위 지적보다 설계 맥락을 살피는 역할을 강조한다. [10:42]

8. 병렬 탐색과 반대 관점의 재검증

• 코드 리뷰에서 여러 갈래로 버그를 탐색한 뒤 결과를 합치는 방식을 사용했고, 이를 문제 해결에 추론 시간과 연산을 더 투입하는 사례로 보여준다. [11:05]
• 버그 후보마다 세 가지 관점에서 실제 문제인지 재검토해 주의가 필요한 항목을 추리는 방식이 워크플로의 출발점이었다고 드러낸다. [11:46]

9. 워크플로의 확장과 코드로 보장하는 반복

• 같은 구조를 성능 문제나 여행 조사에도 적용할 수 있으며, Claude가 에이전트 간 결과 연결과 최종 요약을 위한 실행 구조를 만들 수 있다고 보여준다. [12:28]
• 병렬로 모은 정보는 사람이 읽을 수 있도록 다시 선별해야 하므로, 검색·정렬·검증·요약으로 이어지는 맵리듀스 형태의 문제라고 드러낸다. [13:23]
• 하위 에이전트의 실행을 코드로 조율하면 반복문이 각 항목에 같은 처리를 적용하므로, 에이전트의 판단과 정해진 실행 절차를 결합하는 데서 신뢰를 얻는다고 보여준다. [14:03]

10. Claude Tag 자체 개발과 메시지 중심 사용 경험

• Claude Tag로 Claude Tag를 개발하며, 에이전트가 사람이 하던 구현과 전체 동작 테스트를 수행하도록 개발 환경과 반복 과정을 다듬는 데 집중한다고 드러낸다. [14:49]
• Slack에는 메시지 도구로 전달한 내용이 표시되고 전체 실행 기록은 별도 링크로 확인하는 구조여서, 사용자가 매 순간의 세부 실행을 지켜보는 경험과 분리된다고 보여준다. [15:28]
• 처음에는 낯설었지만 상세 기록을 계속 감독하지 않아도 좋은 결과를 받는 경험이 쌓이며, 모델에 더 큰 작업을 맡기게 됐다고 드러낸다. [16:11]

11. 제품 개선을 연결하는 피드백과 검증

• 새 도구의 이해관계자 탐색부터 목업·구현·내부 배포·사용 모니터링까지 Slack에서 이어가고, 피드백 알림을 받아 대응하는 사례를 보여준다. [17:03]
• 특정 수정안을 지시하려다가 사용자 전환 과정 자체를 개선해 달라고 요청하면서, 더 높은 수준의 목표를 함께 다루는 방식이 와닿았다고 드러낸다. [17:25]
• 검증·리뷰·피드백을 주요 구성 요소로 정리한다. PR 테스트와 스크린샷, 사용 녹화로 결과를 확인하되 출연자가 직접 복제해 사용해 본 사례도 나온다. [18:31]

12. 세부 구현에서 아이디어와 문제 해결로

• 자동 모드·메모리·워크플로를 따라가는 부담 속에서도, 지금 가능한 자동화와 더 큰 목표를 다시 생각하는 태도가 필요하다고 드러낸다. [19:15]
• 성능 개선과 정교한 UI 구현을 직접 하던 즐거움을 돌아보면서, 이제는 아이디어를 프로토타입과 실제 제품으로 빠르게 옮기고 기술적 장벽이 있던 작업에도 도전한다고 보여준다. [21:43]
• 마지막에는 소프트웨어 공학을 계속 변화하는 직업으로 바라보며, 도구와 해결할 문제가 달라져도 핵심은 문제 해결이라는 데 의견을 모은다. [22:16]

🧾 결론

• 개발팀의 사용 방식은 함수 단위 요청에서 제품 목표와 개발 과정 전체를 맡기는 방향으로 이동하고 있다.
• 모델이 발전할수록 기존 기능을 유지하는 관성보다, 현재의 실패 양상과 작업 규모에 맞춰 도구를 재설계하는 태도가 중요해진다.
• 사람의 역할은 사라지기보다 설계 의도, 검증 결과, 사용자 반응을 해석하고 다음 문제를 정하는 쪽으로 옮겨간다.
• 출연자들은 세부 구현의 즐거움 일부를 덜 느끼게 된 대신, 새로운 아이디어를 빠르게 구현하고 더 넓은 문제에 도전할 수 있게 됐다고 설명한다.

📈 투자·시사 포인트

• 제품 경쟁력을 볼 때 모델 성능뿐 아니라 팀 맥락 접근, 개발 환경 연결, 검증과 피드백 통합을 함께 살펴볼 필요가 있다. 영상 속 활용 확대는 이 연결을 중심으로 설명된다.
• 현재 모델의 약점을 보완하는 기능은 유효 기간이 짧을 수 있다. 특정 보조 기능의 지속성보다 모델 변화에 맞춰 제품을 수정하는 역량이 관찰 지점이다.
• 병렬 탐색과 다중 검증은 추론 연산을 더 투입하는 방식이다. 품질 향상과 함께 비용·지연이 어떻게 변하는지 확인해야 하지만, 영상에는 해당 수치가 없다.
• 생산성 향상은 개발자 개인의 체감 사례로 제시된다. 이를 기업 전체의 수익성이나 투자 성과로 직접 환산할 근거는 제공되지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 자막에는 Cloud Code와 Claude code, Cloud Tag와 Claude Tag처럼 표기가 혼재한다. 본문은 제목과 후반 발언에 맞춰 Claude Code·Claude Tag로 통일했으며, 2E처럼 의미가 불명확한 표기는 특정 제품명으로 단정하지 않았다.
• 업무의 70~80%를 맡긴다는 설명과 생산성이 10배 높아졌다는 표현은 출연자 개인의 경험이다. 측정 방법, 비교 조건, 팀 전체의 재현성은 확인되지 않는다.
• 할 일 목록이 더는 필요하지 않다는 발언은 해당 팀의 모델·작업 환경에 대한 회고다. 모든 모델과 장기 작업에 적용되는 일반 원칙으로 보기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복 업무 하나를 골라 원하는 결과, 필요한 팀 맥락, 완료 확인 방법을 적고 목표 단위로 위임해 본다.
• 에이전트가 개발 환경에서 구현부터 테스트까지 수행할 수 있는지 확인하고, 막히는 설정과 접근 경로를 정리한다.
• 결과를 확인할 테스트·스크린샷·실행 기록을 정하고, 초기에는 직접 사용한 결과와 대조한다.
• 코드 리뷰에서 자동화할 세부 지적과 사람이 확인할 API 의도·서비스 경계를 구분한다.

❓ 열린 질문

• Slack에 남아 있지 않은 설계 배경이나 암묵적인 팀 지식은 에이전트에 어떻게 전달할 수 있을까?
• 병렬 탐색과 반대 관점의 재검증은 실제 결함 탐지율과 오탐률을 얼마나 개선할까?
• 사람이 상세 실행 기록을 덜 보는 상황에서, 어떤 검증 결과가 충분한 신뢰의 기준이 될까?