본문으로 건너뛰기

© 2026 Molayo

X요약2026. 06. 23. 11:37

Claude Code/Cowork 리드 @Nerdi_Yogi로부터 얻은 가장 큰 교훈들

요약

Anthropic의 Claude Code/Cowork 리드로부터 얻은 개발 문화와 운영 전략에 대한 교훈을 다룹니다. 코드 배포 검증 방법, 에이전트 협업 환경에서의 엔지니어링 문화, 그리고 제품 개발 및 팀 관리 원칙을 공유합니다.

핵심 포인트

  • 배포 증가에 따른 'bad vs sad' 검증 프레임워크 도입
  • 에이전트 협업 시대의 고립 방지를 위한 페어 프로그래밍 문화
  • 사용자 경험(UX) 측정을 위한 욕설 집계 대시보드 활용
  • 잠재적 수요(Latent Demand)를 통한 새로운 비즈니스 기회 포착
  • 6개월 로드맵 대신 적기(Just-in-time) 방식의 월간 계획 운영

Claude Code/Cowork 리드인 @Nerdi_Yogi로부터 얻은 저의 가장 큰 교훈들은 다음과 같습니다:

  1. 엔지니어들이 1년 전보다 8배 더 많은 코드를 배포하게 될 때 (Anthropic의 사례처럼), 가장 큰 문제는 검증 (verification)이 됩니다. 여러분이 배포한 경험이 의도한 대로인지 어떻게 알 수 있을까요? Fiona의 팀이 사용하는 한 가지 전략은 “bad vs. sad” 추적 프레임워크입니다: 'bad'는 복구 불가능한 오류(크래시와 같은)를 의미하며, 'sad'는 복구 가능한 불편함(깜빡임이나 대화의 끊김과 같은)을 의미합니다. 그들은 각 팀에 빠르게 구축하고 배포할 수 있는 자율성을 부여하되, 각자의 영역에서 발생하는 bad와 sad 이벤트를 추적하여 문제를 신속하게 식별합니다.

  2. 엔지니어들이 자신만의 에이전트 (agents) 팀과 함께 점점 더 독립적으로 작업함에 따라, 외로움이 엔지니어들에게 하나의 도전 과제로 떠오르고 있습니다. 이를 돕기 위해 Fiona의 팀은 “페어 프로그래밍 점심 (pairwise programming lunches)”을 시작했습니다. 여기서 엔지니어들은 반드시 같은 작업을 하지는 않더라도 나란히 앉아 작업하며, 다른 사람들이 Claude Code와 Cowork을 어떻게 사용하는지 관찰함으로써 새로운 패턴을 익힙니다.

  3. Anthropic은 사용자들이 Claude Code에 얼마나 자주 욕설을 하는지 집계하는 대시보드를 구축했습니다. 사용자의 좌절감이 눈에 띄게 나타났던 지난 9월, 한 엔지니어가 욕설을 추적하자고 제안했고 Fiona는 이를 매우 마음에 들어 했습니다. 이는 평가 (evals)가 포착하기 어려운 부분, 즉 경험이 단순히 기술적으로 정확한지를 넘어 실제로 즐거운지를 나타내는 대리 지표 (proxy)가 되었습니다.

  4. 새로운 비즈니스 기회를 발견하기 위해 잠재적 수요 (latent demand)를 찾아보세요. Cowork은 팀이 코딩을 하지 않는 사람들이 MRI 분석이나 웨딩 사진 복구와 같은 작업을 위해 Claude Code를 사용하는 것을 발견했을 때 등장했습니다. 제품을 작동시키기 위해 사람들이 번거로운 과정을 감수하는 것과 같은 신호는 그곳에 무언가 가치 있는 것이 있다는 것을 알려줍니다.

  5. Fiona의 팀은 6개월 단위의 로드맵 (roadmaps)에서 적기 (just-in-time) 방식의 월간 계획으로 전환했습니다. 그녀는 Claude Code에 합류했을 때 가벼운 6개월 로드맵을 시도해 보았지만, 몇 달 후 팀원들이 이를 거의 참조하지 않는다는 것을 깨달았습니다. 이제 그들은 이번 달의 우선순위 목록이 담긴 간단한 스프레드시트를 사용하여 월간 계획을 세웁니다.

  6. Claude Code의 문화적 가치 중 하나는 다음과 같습니다: 작동하지 않는 프로세스는 무엇이든 종료할 권한이 당신에게 있습니다. Fiona는 이전 경험에서 가져온 6개월 단위 계획법을 도입했으나, 그것이 팀에 도움이 되지 않자 직접 폐기했습니다. 항상 질문하세요: 이 프로세스가 여전히 그 목적에 부합하는가?

  7. 또 다른 핵심 원칙은 "내가 직접 하는 것보다 더 나은 방법은 무엇인가? 바로 Claude가 하는 것이다"입니다. 이는 모델 출시를 알리는 포스트를 작성하는 일조차도, 모든 구성원이 해당 작업이 자동화될 수 있는지 계속해서 확인하도록 독려합니다. Fiona는 수십 년 동안 소프트웨어를 수동으로 출시해 온 경험 때문에, 여전히 스스로에게 (자동화할 수 있는지) 물어보라고 상기시켜야 한다고 인정합니다.

  8. Fiona가 매니저를 채용할 때는 반드시 개별 기여자 (Individual Contributor)로 시작해야 합니다. 이를 통해 그들은 관리 책임을 맡기 전에 코드베이스를 학습하고, 팀과 유대감을 쌓으며, 팀의 엔지니어가 된다는 것이 어떤 것인지 이해할 시간을 갖게 됩니다. 이는 구체적인 맥락을 배우는 대신 즉시 "매니저 도구 상자 (manager toolbox)"를 꺼내 드는 함정을 방지합니다.

  9. Fiona는 매니저로서의 일상적인 의례를 자동화하기 위해 "루틴 (routines)"을 사용합니다. 예전에는 커피를 마시며 사용자 피드백 채널을 읽고 수정 사항을 직접 골라 팀원들에게 할당하곤 했습니다. 이제는 매일 아침 Claude "루틴"이 실행되어, 여러 채널의 피드백을 분석하고, 테마를 식별하며, 문제를 해결하기 위한 PR (Pull Request)을 생성하는 에이전트 (agents)들을 가동합니다. 그녀의 예측에 따르면, 업무는 수동적인 동기식 프롬프팅 (synchronous prompting)에서 비동기식 에이전트 관리 (asynchronous agent management, 즉 루프 (loops))로 전환되고 있습니다.

  10. 그녀를 밤잠 설치게 하는 것은 코드가 아니라 문화입니다. Fiona에게 문화란 벽에 붙은 포스터가 아니라 살아있는 생명체입니다. 그녀가 가장 두려워하는 것은 방 안에 불이 나고 있는데 "모든 것이 괜찮다"라고 말하는 매니저입니다. 그녀는 무엇이 잘 풀리지 않는지에 대해 공개적으로 이야기하도록 강력히 추진하는데, 그것만이 팀이 함께 문제를 해결할 수 있는 유일한 방법이기 때문입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 X 토픽: Claude/Anthropic의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0