Claude Code가 우리 팀을 망칠까요?

Source: Hacker News

Claude Code의 Opus 4.5를 처음 사용해 소프트웨어를 만들었을 때, 그 성능이 믿기 어려울 정도로 뛰어났습니다.
다음 생각은 이것이 소프트웨어 팀 내부의 역학을 바꿀 것이라는 것이었습니다.

역할 간의 교착 상태

Marc Andreessen은 최근 이 순간을 “멕시코식 교착 상태”(Mexican standoff)라고 설명했습니다 (video):

• 이제 모든 엔지니어는 자신이 PM이자 디자이너가 될 수 있다고 생각한다.
• 모든 PM은 자신이 코딩과 디자인을 할 수 있다고 생각한다.
• 모든 디자이너는 자신이 나머지 두 역할을 할 수 있다고 생각한다.

위험은 많은 개인 기여자들이 더 이상 다른 사람들을 필요로 하지 않는다고 믿게 된다는 점이다. 단기적으로 이는 팀 문화에 엄청난 혼란을 초래할 것이다.

희귀 기술이 더 쉽게 접근 가능해지면, 사람들은 자신의 가치를 증명하기 위해 “스택 위로” 올라가야 한다는 압박을 느낀다.
Kent Beck은 이 감정을 X에 표현했다 (link):
“내 기술 중 90 %의 가치는 $0로 떨어졌다. 남은 10 %의 레버리지는 천 배 상승했다.”

내가 우려하는 것은 모두가 같은 10 %를 향해 재조정하고 있다는 점이다—개인 기여자들이 같은 레버리지 층을 향해 경쟁하고 있다.

Ben Werdmuller의 글 “AI coding works now”에서 그는 엔지니어들에게 네 가지 고레버리지 스킬에 집중하라고 조언한다:

1. 제품 목표 설정하기
2. 사용자가 실제로 원하는 것을 이해하기
3. 만들고 있는 경험과 가치를 명확히 정의하기
4. 견고한 소프트웨어 아키텍처를 설계, 구축, 유지하기

Ben의 조언에 대한 도전은 많은 사람들이 자신이 이 스킬들을 가지고 있다고 믿는다는 점이다:

• 회사 리더십은 목표와 전략을 장악하고 싶어한다.
• 제품 매니저는 사용자가 원하는 것을 이해하는 데 자신만의 독특한 자격이 있다고 본다.
• 디자이너는 사용자 경험을 설계하는 것을 통제하고 싶어한다.
• 마케팅과 영업은 고객에게 가치를 어떻게 전달할지 정의하고 싶어한다.
• 엔지니어는 아키텍처—성능, 확장성, 보안—를 계획하고 구현하는 것을 담당한다. 이는 모두 실질적인 전문 지식이 필요하다.

AI와 함께라면, 이 모든 역할은 더 유동적이 된다. 더 많은 사람들이 소프트웨어를 만들고 사이클 타임이 압축되면서, 동료들이 수십 년 동안 배워야 했던 교훈들을 스스로 흡수하게 될 것이다. 궁극적으로 더 많은 개인이 가장 높은 레버리지를 가진 정체성을 차지하고 싶어한다: “내 역할에서 나는 문제를 해결하고 사용자에게 가치를 제공한다.”

통제되지 않으면, 포지션을 놓고 경쟁하거나 팀 구성원 간 적대감이 증가할 위험이 있다.

What I’m hearing from software teams

• Founder: “맞는 말인 것 같아요. 우리는 이미 보고 있어요 — 주로 PM들이 코드를 쓰고 싶어 하는 경우가 많아요.”
• Another founder: “우리 팀에서도 확실히 느끼고 있어요. 모두가 다른 사람의 일을 할 수 있을 것 같은 느낌이에요.”
• President of an established software company: “우리 팀은 Head of Product와 엔지니어 15명으로 구성돼 있습니다. 작은 프로젝트에서는 그가 개발자와 상의 없이 직접 많은 PR을 배포하고 있어요.”
• Hiring impact: “우리에게서 실제로 영향을 보는 부분은 더 이상 채용하지 않는 사람들, 즉 specialists입니다. 이 새로운 시대에는 generalists가 승리합니다.”
• John O’Nolan, founder of Ghost: “확실히 격동의 시기이지만 전체적으로는 꽤 낙관적이에요. 아직 일어나지 않았지만 앞으로 일어날 것이라고 기대하는 것은, 기존 역할이 압축되는 동시에 새로운 역할이 등장한다는 점입니다.”

Source: …

대치 이후

내가 바라는 바(먼지가 가라앉은 뒤)는 더 많은 협업이 이루어지는 것입니다. 레버리지를 놓고 경쟁하기보다, 개별 기여자들이 새로운 방식으로 함께 일할 수 있기를 바랍니다.

예시: 제품 관리자와 엔지니어가 AI‑구동 페어 프로그래밍을 할 수 있습니다. PM은 고객 행동과 제품 목표에 집중하고, 엔지니어는 아키텍처, 보안, 유지보수성을 평가합니다. 두 사람은 LLM을 활용해 실시간으로 함께 반복 작업을 진행합니다.

Matt Stauffer, Tighten의 CEO는 바로 이런 방식을 설명합니다:

“나는 내 Biz Dev 매니저(이 내부 프로젝트의 제품 소유자)에게 작업을 시연하고, 그녀는 변경을 요청합니다. 그리고 우리는 실시간으로 LLM에 프롬프트를 입력합니다. 나는 프롬프트 작성과 검토에 더 능숙하고, 그녀는 도메인에 대해 나보다 더 잘 알고 있죠. 이런 형태의 페어 프로그래밍은 훌륭합니다. 왜냐하면 나는 빠르게 진행하고, 그녀는 내가 검토하고 반복할 때 나중에 콜에서 떠날 수 있기 때문이죠.”

Ben Werdmuller의 원칙은 여전히 유효합니다: “모든 코드는 책임을 질 인간 소유자를 가져야 합니다.” 이 시나리오에서는 PM과 엔지니어가 풀 리퀘스트를 공동 소유하게 됩니다.

37signals는 두 사람 팀(디자이너 1명, 엔지니어 1명)으로 유명합니다. AI 시대에는 이 패러다임이 표준이 될 수도 있습니다.

혼란이 가라앉으면, 팀은 AI와 협업을 동시에 활용해 더 나은 소프트웨어를 만들기 위한 새로운 비전을 필요로 할 것입니다.

감사합니다,
Justin Jackson