멀티플라이어는 이제 일이다: 에이전틱 AI가 모든 것을 바꾸는 이유

Source: Dev.to

번역할 텍스트가 제공되지 않았습니다. 번역을 원하는 본문을 알려주시면 한국어로 번역해 드리겠습니다.

개요

이번 주 어느 저녁에 Claude Code와 10분을 보냈습니다. 프롬프트를 입력하거나, 조정하거나, 올바른 주문을 찾으려는 10분이 아니라—실제로 작업에 10분을 보냈습니다. 그 시간 동안 대략 48 000줄의 코드를 생성했습니다.

그 숫자는 너무 터무니없어 즉시 회의감을 불러일으키며, 저 역시도 마찬가지였습니다. 그래서 저는 그것을 측정했습니다. 무슨 일이 일어나고 있었는지, 제가 실제로 얼마나 관여했는지, 그리고 그 출력을 우리가 일반적으로 엔지니어링 작업을 논할 때 사용하는 단위로 변환했을 때 어떤 모습인지 추적했습니다.

저를 불안하게 만든 것은 단순히 코드의 양이 아니었습니다. 제 작업 속도가 거의 의미가 없다는 점이었습니다. 제가 빠르게 타이핑하든 아니든 시스템은 계속해서 코드를 생성했습니다. 제 역할은 거의 즉시 결정하고, 방향을 바꾸며, 때때로 도움이 되지 않는 방향으로 가는 것을 멈추는 일로 전환되었습니다.

엔지니어링‑경제 대시보드

호기심이 계측으로 이어졌습니다. 실제로 무슨 일이 일어나고 있는지 보기 위해 Grafana 대시보드 몇 개를 만들었습니다. 1시간 동안 시스템은 약 48 000줄의 코드를 생성했습니다. 그 기간 동안 제 직접적인 참여 시간은 대략 10분 정도였습니다.

개발자 1시간당 75줄의 생산 품질 코드라는 매우 관대한 추정치를 사용하면, 해당 산출량은 거의 4주 분량의 작업에 해당합니다. 두 개의 리포지토리에서 여러 에이전트를 병렬로 실행했을 때는 비율이 더 상승하여 잠시 다섯 자리 수에 이르기도 했습니다.

저는 코드 줄 수가 가치의 의미 있는 대리라고 생각하지 않습니다. 제 경력 동안 충분히 많은 코드를 삭제해 보았기에 확신합니다. 하지만 코드 줄 수는 여전히 조직이 예산을 책정하고, 인력을 배치하며, 견적을 산정하는 방식입니다. 그런 맥락에서 그 수치는 무시하기 어려운 계산이 됩니다.

Source:

생산성‑비율 게이지

시니어 엔지니어는 연간 약 $150 k–$200 k 정도의 비용이 듭니다(전체 비용 포함). 계산을 단순히 하기 위해 시간당 $100이라고 가정합니다. 이 비율이면, 생산 코드 한 줄당 비용은 약 $1 정도가 됩니다.

제가 여기서 관찰한 라인당 비용은 몇 센트도 안 되는 금액이었습니다.

저는 월 $200 플랜을 사용하고 있습니다. 한 시간 안에 시스템이 $70 이상의 동등한 API 출력을 생성했습니다. 그 시간 동안 제 구독 비용은 $0.30 이하에 불과했습니다. 이 설정에 대해 어떤 의견을 갖든, 비용이 비싸다고 할 수는 없습니다.

Daily/Weekly Summary Dashboard

이 시점에서 보통 반대 의견이 나오는데, 때로는 말로, 때로는 말 없이 나타납니다:

“수만 줄의 코드를 검토하고 있을 리가 없잖아요. 그런 양이면 품질이 무너질 수밖에 없어요.”

물론 저는 한 줄씩 읽고 있는 것이 아닙니다. 그렇게 하면 의미가 없고, 여기서 일어나고 있는 더 중요한 변화를 놓치게 됩니다.

품질에 대한 책임은 업스트림으로 이동합니다.

• 테스트가 크게 그리고 빨리 실패하도록 자동화된 테스트에 의존합니다.
• 테스트가 통과했는지만 보는 것이 아니라, 테스트가 코드를 얼마나 잘 검증하는지도 추적합니다: 분기 커버리지, 변이 테스트, 구현이 시작되기 전에 작성된 행동‑수준 수용 기준 등.
• 서로의 출력을 비판하는 특수 에이전트를 사용합니다.
• 위험한 작업이 발생하기 전에 방지하는 가드레일을 둡니다.
• 무언가가 깨지면 즉시 확인할 수 있습니다.

제가 시간을 쓰는 방식은 예전과 매우 다릅니다. 저는 제약을 정의하고, 의도를 명확히 하며, 추진할 가치가 충분한 것과 초기에 포기해야 할 것을 결정합니다. 시스템이 스스로 모순될 때는 개입하고, 올바르게 동작할 때는 대부분 손을 떼어 둡니다.

Claude Code Metrics Dashboard

이는 팀에게 불편한 함의를 가지고 있습니다.

단일 개발자가 이러한 도구와 사용 방법에 대한 약간의 규율을 갖추면, 이제는 이전에 전체 조직이 필요했을 원시 출력을 만들 수 있습니다. 이는 판단력, 감각, 혹은 아키텍처 감각이 무의미해졌다는 의미는 아닙니다. 오히려 그것들이 더 중요해졌습니다. 왜냐하면 이제 그것들이 제한 요소가 되었기 때문입니다.

엔지니어링 조직이 직면한 질문은 이것이 철학적으로 만족스러운가가 아니라, 이를 무시할 여유가 있는가입니다. 이러한 레버리지를 마주했을 때, 실험하지 않기로 선택하는 것은 신중함이라기보다 부정처럼 보이기 시작합니다.

일 자체의 형태가 변했습니다. 이전에는 코드 생산이 업무였습니다. 이제는 점점 결과 정의, 경계 설정, 행동 검증에 관한 일이 됩니다. 타이핑보다는 연출에, 건설보다는 편집에 더 가깝게 느껴집니다.

If you want to dismiss this as “v… (the original text cuts off here).

“코딩을 작성한다”고 할 수 있습니다. 만약 주니어 엔지니어나 그 자체의 장인 정신에 어떤 의미가 있는지 걱정하고 싶다면, 그런 우려는 정당하고 논의할 가치가 있습니다. 하지만 경제적 요인은 이미 여기 있으며, 조용히 인센티브를 재배치하고 있습니다.

배수는 더 이상 좋은 보너스가 아닙니다.

그것이 바로 일입니다.