"코드를 덜 쓰고, 에이전트를 관리하는 데 더 많은 시간을 씁니다." Santiago Valdarrama(@svpino)가 LinkedIn에 올린 이 한 문장이 개발자 커뮤니티를 뒤집어놨어요. 칭찬이 아니라 고백처럼 들렸거든요. 코드를 덜 쓴다니 — 그게 개발자가 할 말인가?
그런데 이건 한 사람의 취향 고백이 아니에요. 당신 직함은 그대로인데, 그 직함이 가리키는 일이 통째로 바뀌는 중이라는 신호예요. 키보드로 코드를 치던 사람에서, 코드를 치는 여러 대의 에이전트를 부리는 사람으로요. 문제는 이 전환이 조용히 일어나고 있다는 거예요. 공지도, 사내 교육도 없이.
이미 벌어지고 있는 일
NYT 매거진이 개발자 70여 명을 인터뷰했어요. 그중 샌프란시스코의 스타트업 창업자 Manu Ebert는 하루 종일 Claude Code 에이전트 여러 대와 대화해요. 하나는 새 기능을 구현하고, 하나는 테스트하고, 세 번째가 전체를 감독하죠. 예전엔 하루가 걸리던 기능 요청이 이제 30분이면 끝나요.
핵심은 "AI가 코드를 대신 써준다"가 아니에요. 그건 너무 작은 이야기예요. 진짜 변화는 질문이 바뀌었다는 거예요. "어떻게 구현할까"에서 "무엇을 원하는가"로. 키보드 앞에서 보내는 시간이 줄고, 원하는 걸 설명하고 결과를 검증하는 시간이 늘었어요.
"나는 아직 직접 코드 쓰는데?" 싶다면, 숫자를 보세요. Microsoft는 프로덕션 코드의 30%가 AI 생성이라고 밝혔고, 개발자의 73%가 매주 AI 도구를 써요. GitHub CEO는 자기 다음 직함이 "코드 크리에이티브 디렉터"가 될 거라고 했고요. 얼리어답터 몇 명의 자랑이 아니라, 바닥 전체가 이동 중이라는 뜻이에요.
Santiago를 자극한 Tonkotsu라는 도구가 이 변화를 한 화면에 압축해서 보여줘요. 전 Facebook 엔지니어들이 만든 데스크톱 앱인데, 개발자를 대놓고 "코딩 에이전트 팀의 매니저"로 세워요. 작업을 계획하고(Plan), 여러 에이전트에게 동시에 던지고(Delegate), 돌아온 diff를 검토하는(Verify) 루프 — 이걸 하나의 인터페이스로 묶었죠. 도구 이름이 중요한 게 아니에요. 도구가 전제하는 역할이 중요해요. IDE는 당신을 타이피스트로 봤지만, 이런 도구는 당신을 매니저로 봐요.
코더와 오케스트레이터, 무엇이 갈리는가
2026년의 코딩 에이전트는 이미 세 갈래로 수렴했어요. CLI 에이전트(Claude Code, Codex CLI), IDE 네이티브(Cursor, Windsurf), 클라우드 엔지니어링 에이전트(Devin, GitHub Coding Agents). 겉모습은 달라도 메모리 파일, 도구 사용, 장기 실행, 서브 에이전트 오케스트레이션이라는 같은 뼈대를 공유해요. 즉 어느 도구를 잡든, 당신이 익혀야 할 근육은 같아요 — 부리는 법.
그 근육이 어디에 쓰이는지, 옛 방식과 나란히 놓고 보면 분명해져요.
| 기존 개발 방식 | 에이전트 관리 방식 | |
|---|---|---|
| 핵심 활동 | 코드 직접 작성 | 에이전트에게 의도 전달 + 결과 검증 |
| 병렬성 | 개발자 1명 = 작업 1개 | 개발자 1명 = 에이전트 N개 동시 운영 |
| 핵심 스킬 | 프로그래밍 언어 숙련도 | 컨텍스트 설계 + 아키텍처 판단력 |
| 생산성 지표 | 작성한 코드 라인 수 | 검증 완료된 머지 PR 수 |
| 팀 구조 | 시니어 1 + 주니어 5 피라미드 | 오케스트레이터 1 + 에이전트 N 허브 앤 스포크 |
토스의 정세훈 개발자는 이 전환을 한 단어로 정리해요 — 추상화. AI에게 일을 맡기는 건 결국 그 일을 추상화하는 거예요. "이 부분은 더 이상 신경 쓰지 않겠다"는 선언이죠. 그런데 함정이 여기 있어요. 잘못된 추상화는 추상화가 없는 것보다 나빠요. "알아서 잘 처리해줘"라고 던지면 반드시 실패해요. 매니저로 산다는 건, 무엇을 위임하고 무엇을 손에 쥘지 매번 정확히 긋는 일이에요.
채용 시장도 같은 방향을 가리켜요. HackerEarth의 2025년 데이터를 보면, 기업이 개발자를 평가할 때 프로그래밍 능력(+54배), 문제 해결 능력(+39배), 데이터 시각화(+35배)의 비중을 확 끌어올렸어요. 더 이상 "이 문법을 아는가"가 아니라 "이 문제를 풀 수 있는가"를 물어요.
스타트업은 "10~100배 빨라졌다"고 말하는데, Google의 Sundar Pichai가 공개한 수치는 엔지니어링 속도 10% 향상이에요.
온도 차가 왜 이렇게 클까요? 수십억 줄이 쌓인 대기업 코드베이스에선, 새 코드를 잘못 넣으면 수백만 명의 서비스가 멈추니까요. 빠르게 만드는 능력보다 틀린 걸 막는 능력이 비싸지는 환경이에요. 이게 다음 경고로 이어져요.
속도의 청구서는 따로 날아온다
AI가 생성한 코드의 30%에 보안 취약점이 섞인다는 연구가 있고, 코드 이탈률(Churn)은 AI 이전 대비 2배로 늘었어요. 그래서 시니어의 가치는 떨어지는 게 아니라 오히려 올라가요. 에이전트가 순식간에 뽑아낸 코드를 "이게 정말 맞나" 판단하는 사람, 추상화가 깨진 순간 시스템과 홀로 마주할 수 있는 사람 — 그 자리는 더 비싸졌어요. 매니저가 된다고 손에서 코드를 완전히 놓는 게 아니에요. 결정적인 순간을 위해 손을 비워두는 거예요.
오늘부터 매니저처럼 일하는 5단계
그래서 뭘 하면 되냐고요. 거창한 전환 선언은 필요 없어요. 다음 작업 하나부터 아래 순서로 굴려보세요.
- "무엇을 원하는가"부터 못 박기
"이 기능 만들어줘"는 위임이 아니라 도박이에요. 요구사항·제약조건·예상 결과를 구조화해서 건네세요. CLAUDE.md나 AGENTS.md에 프로젝트 컨텍스트를 한 번 정리해두면, 매번 처음부터 설명할 필요가 없어져요. - 위임보다 검증 루프를 먼저 깔기
에이전트가 쓴 코드를 한 줄씩 눈으로 읽으려 하지 마세요. 그건 매니저가 아니라 검수원이에요. 테스트를 자동으로 돌리고, CI를 통과해야만 PR이 열리게 만드세요. "에이전트가 스스로 자기 결과를 검증하는 시스템"이 진짜 레버리지예요. - 위임 범위를 한 칸씩 넓히기
정세훈 개발자가 권하는 방법이에요. 작업을 끝낼 때마다 "이걸 AI에게 어떻게 맡길 수 있었을까?"를 자문하세요. 다음에 비슷한 작업이 오면, 조금 비효율적이더라도 일부러 에이전트에게 넘겨보세요. 위임은 한 번에 느는 게 아니라 한 칸씩 늘어요. - 병렬 운영을 한 번은 직접 겪어보기
Tonkotsu 같은 도구로 에이전트 여러 대를 동시에 돌려보세요. 하나는 새 기능, 하나는 테스트, 하나는 문서화. 개발자 1명이 팀 리드처럼 여러 작업선을 동시에 굴리는 감각 — 이건 글로 못 배워요, 한 번 해봐야 알아요. - 코드베이스를 AI가 읽을 수 있게 청소하기
죽은 코드, 반쯤 끝난 마이그레이션, 서로 경쟁하는 패턴을 걷어내세요. 에이전트는 확률적으로 작동해서, 코드베이스에 모순된 신호가 섞여 있으면 이상한 코드를 뱉어내요. 깨끗한 코드베이스는 이제 위생이 아니라 생산성 인프라예요.
직함은 안 바뀔지 몰라요. 하지만 1년 뒤 당신이 자랑하는 숫자가 "이만큼 짰다"에서 "이만큼 검증해서 머지했다"로 바뀌어 있다면, 당신은 이미 코더가 아니라 오케스트레이터예요. 지금 그 첫 작업 하나를 위임하는 데서 시작하면 돼요.
