이제 코드는 에이전트가 씁니다. 개발자의 일은 이렇게 바뀌었습니다.

집안에 개발자가 한 명 있는 자리라면 어디서든 나오는 질문이 있습니다. 기계가 코드를 쓰면, 남는 건 뭐냐는 것입니다.

솔직한 답은, 그 질문이 이 일의 엉뚱한 부분을 겨냥하고 있다는 것입니다. 코드를 쓰는 일이 이 직업의 전부였던 적은 없습니다. 그것은 눈에 보이는 부분, 책상 뒤를 지나가는 사람에게 일처럼 보이는 부분이었습니다. 그리고 대부분의 주에는 가장 작은 부분이기도 했습니다.

자동화된 부분은 애초에 이 일의 전부가 아니었습니다

프로덕션까지 나가는 것은 무엇이든 여섯 개의 고리를 지나갑니다:

1. 누군가 무언가를 원하고, 그것을 서툴게 말합니다.
2. 누군가 그것이 할 만한 일인지, 그리고 언제 할지를 정합니다.
3. 누군가 그것을 실행할 수 있을 만큼 정확한 설명으로 바꿉니다.
4. 누군가 그것을 만듭니다.
5. 누군가 다른 것이 깨지지 않았는지 확인합니다.
6. 누군가 배포하고, 요청한 사람에게 알립니다.

에이전트는 네 번째 고리를 가져갔습니다. 설득력 있게 가져갔고, 앞으로도 계속 더 잘하게 될 것입니다. 거의 아무도 소리 내어 말하지 않는 부분은 그것이 나머지 다섯 개에 무슨 일을 했느냐입니다. 다섯 개는 가벼워진 것이 아니라 무거워졌습니다.

이유는 처리량입니다. 만드는 데 2주가 걸리던 시절에는 주변의 다섯 고리에도 2주가 주어졌습니다. 가운데가 느리니까 다섯 개도 느렸고, 느리다는 사실을 아무도 눈치채지 못했습니다. 만드는 데 반나절이 걸리기 시작하면, 나머지 전부가 한꺼번에 병목이 됩니다.

고리 하나가 무너졌습니다. 그 고리가 가리고 있던 무게를 이제 나머지 다섯이 짊어집니다.

이야기는 그게 전부이고, 이 글의 나머지는 그 다섯 개를 매일 실제로 해내야 할 때 각각이 어떤 모습인지에 대한 것입니다.

고리 1: 절반을 흘리지 않고 무엇을 만들지 듣기

새로운 실패 방식은 구체적이고, 비쌉니다. 무엇이든 만들 수 있으니 잘못된 것을 더 빨리 만듭니다.

요청은 사방에서 들어옵니다. 고객 응대 스레드의 메시지 하나. 통화 끝머리의 한 문장. 소셜 미디어의 불평. 사실은 기능 요청인데 버그 리포트로 위장하고 있는 글. 예전에는 이게 크게 문제 되지 않았습니다. 어차피 2주에 하나밖에 만들 수 없었고, 뻔한 것 하나를 고르면 대개 맞았으니까요. 일주일에 다섯 개를 만들 수 있게 된 지금은, 맞는 다섯 개와 틀린 다섯 개의 차이가 한 해의 대부분을 결정합니다.

두 가지가 일어나야 하고, 이 둘은 서로 다른 일입니다.

먼저, 요청하는 사람 입장에서 등록이 싸야 합니다. 사용자가 계정을 만들고, 폼을 찾아내고, 자기 문제를 두 번 설명해야 한다면 대부분은 그냥 그만두고, 끝까지 하는 사람들은 대표성 있는 표본이 아닙니다. 누구나 요청을 올리고, 스크린샷을 붙이고, 그 요청이 어떻게 되는지 따라갈 수 있는 공개 피드백 보드는 그 마찰을 없앱니다. 제품을 쓰는 사람들이 자기 말로, 맥락을 붙여서, 요청을 직접 씁니다.

다음으로, 분류가 자동이어야 합니다. 날것의 피드백은 오래 쓸모 있게 남아 있지 않기 때문입니다. 거의 같은 말을 하는 메시지 스무 개는, 누군가 스무 개를 다 읽고 그게 하나라는 것을 알아채기 전까지는 문제 스무 개처럼 보입니다. 그리고 그것이 정확히 아무도 시간을 낼 수 없는 일입니다. Idea Radar가 저희의 답입니다. 날것의 신호가 손대지 않은 채로 들어와 스스로 주제별로 묶이고, 중복은 두 개의 작업이 되기 전에 서로 짝지어지며, 아이디어마다 그것을 요청한 서로 다른 사람의 수가 붙습니다. 원문은 절대 다시 쓰지 않습니다. 그 사람이 쓴 정확한 표현이 곧 데이터이기 때문입니다.

이 고리가 내놓는 것은 백로그가 아닙니다. 읽어 볼 수 있는 원문 더미입니다.

고리 2: 정하기, 이제 희소해진 자원

아이디어 보드는 계획이 아닙니다. 하나를 다른 하나로 바꾸는 것은 판단이고, 예전에는 한 분기에 얇게 펴져 있던 그 판단이 이제는 매주 일어나야 합니다.

여기서 중요한 동작은 두 가지입니다.

승격은 의도적입니다. 아이디어는 등록되는 순간이 아니라 누군가 만들 가치가 있다고 정하는 순간에 백로그 티켓이 됩니다. 나머지는 요청한 사람 수를 단 채로 레이더에 계속 남아 있고, 그것이 솔직한 상태입니다: 들었지만, 일정에 넣지는 않았다. 여든 퍼센트가 영영 만들어지지 않을 백로그는 계획이 아니라, 사람을 속이는 레이아웃을 쓴 보관함입니다.

범위 잡기는 만드는 도중이 아니라 만들기 전에 합니다. 흐릿한 피드백은 요청한 사람이 직접 보고 확인할 수 있는 검증된 목업이 됩니다. 확인에 쓰는 5분이 잘못된 화면을 만드는 반나절보다 낫고, 그 반나절이 다른 데 쓸 수도 있었을 에이전트 시간이 된 순간 이 교환은 훨씬 더 유리해졌습니다.

고리 3: 브리핑, 타이핑을 대신한 기술

진짜 기술이 옮겨 간 곳이 여기입니다.

에이전트는 동료처럼 모호한 지시에 되묻지 않습니다. "잠깐, 결제 흐름이 두 개인데 어느 쪽이요?"라고 말해 주지 않습니다. 빈칸을 그럴듯한 추측으로 채우고, 앞뒤는 맞으면서 틀린 것을 건네줍니다. 모호함의 대가는 예전에는 대화 한 번이었습니다. 지금은 diff입니다.

좋은 결과를 얻는 사람과 하루 종일 에이전트와 씨름하는 사람을 가르는 것은 프롬프트의 영리함이 아닙니다. 재사용 가능한 맥락입니다. 네 종류이고, 돌아오는 것이 큰 순서로 적습니다.

에이전트가 탐색에 들어가기 전에 읽는 맥락. 저장소에 커밋해 둔 컨벤션 파일(CLAUDE.md, AGENTS.md), 그리고 아키텍처 결정과 과거에 밟은 지뢰, 지금 이렇게 되어 있는 이유를 담은 프로젝트 메모리입니다. 한 번 쓰면 모든 머신의 모든 에이전트가 언제까지나 읽습니다. 오늘 개발자가 쓰는 글 중 되돌아오는 것이 가장 큰 글인데, 여기에 시간을 배정하는 사람은 거의 없습니다.

절차는 절차로 저장하기. 릴리스 체크리스트를 열 번째로 설명하고 있다면, 그건 브리핑이 아니라 재타이핑입니다. 스킬 라이브러리는 반복되는 절차를, 작업이 맞아떨어질 때 에이전트가 알아서 불러오는 것으로 바꿔 줍니다. 프롬프트 라이브러리는 브리핑 자체에 대해 같은 일을 합니다.

설명하지 말고 보여 주기. 어긋난 버튼을 설명하는 한 문단보다 어긋난 버튼을 찍은 그림 한 장이 낫습니다. 화면의 한 부분을 그대로 보내거나, 그 위에 그려서 말하려는 대상을 짚어 주세요. 웹 페이지라면, 살아 있는 DOM을 에이전트에게 그대로 넘기는 쪽이 그것을 설명하는 것보다 언제나 낫습니다.

치지 말고 말하기. 세 문장짜리 구술 브리핑에는, 굳이 타이핑했을 한 문장보다 많은 뉘앙스가 담깁니다. 짧은 지시에는 음성 받아쓰기를, 키보드를 건드리지 않고 주고받고 싶을 때는 음성 모드를 쓰세요. 편의 기능처럼 들리지만, 실제로는 대역폭 기능입니다. 사람은 타이핑하는 것보다 많이 말하고, 에이전트는 당신이 말해 준 것까지만 할 수 있습니다.

앞의 셋은 작업할 때마다 값을 치릅니다. 넷째는 한 번만 치르고 계속 거둬들입니다.

고리 4: 알맞은 머신에서 작업 굴리기

에이전트 하나는 도구입니다. 에이전트 여럿은 시스템이고, 시스템에는 운용하는 사람이 필요합니다.

실무적인 질문들은 하나도 폼 나지 않는데, 그게 바로 이 일입니다. 두 에이전트가 같은 모듈을 건드리지 않으면서 병렬로 돌릴 수 있는 것은 무엇인가? 돌아가는 동안 내 주의를 받을 자격이 있는 작업은 어느 쪽이고, 아닌 쪽은 어느 쪽인가? 내가 자는 동안 무엇이 돌고 있어야 하는가?

마지막 질문이 작업을 어디서 실행할지를 결정합니다. 도중에 끊거나 고치거나 방향을 틀어야 할 수 있는 것은 눈앞의 머신에 둡니다. 길고, 잘 정의되어 있고, 모호한 구석이 없는 작업은 다른 데로 보냅니다. 본인이 가진 다른 컴퓨터나 SSH로 붙는 서버로요. 그래야 두 시간짜리 작업이 노트북을 붙잡고 있지 않습니다. 반복되는 작업은 예약 작업으로 갑니다. 판단을 가르는 질문은 언제나 순수한 성능이 아니라, 본인이 개입해야 할 가능성이 얼마나 되느냐입니다.

한 건의 작업이 성격이 정말로 다른 단계들로 나뉘어 있다면, 에이전트 하나는 잘못된 모양입니다. 만든 다음 테스트하고 그다음 검토해야 하는 작업은 서로 다른 세 가지 능력이 필요한 세 개의 일이고, 에이전트 팀은 단계마다 맥락을 다시 설명하는 대신 그 인수인계를 명시적으로 그릴 수 있게 해 줍니다.

그리고 이 중 어느 것도 당신이 자리에 앉아 있기를 요구하지 않기 때문에, 휴대폰에서 조종하는 것은 더 이상 신기한 기능이 아닙니다. 기차 안에서 에이전트의 질문을 읽고 20초 만에 답해 주는 것이, 끝난 작업과 당신을 네 시간 기다린 작업의 차이입니다.

고리 5: 검토, 책임이 사는 자리

이 고리는 위임되지 않고, 그 이유는 기술적인 것이 아닙니다.

에이전트는 이미 줄을 읽는 일의 대부분을 대신하고 있습니다. 가져갈 수 없는 것은 서명입니다. 책임은 모델로 이전되지 않습니다. 마이그레이션이 프로덕션에서 컬럼 하나를 날렸을 때 "그건 에이전트가 쓴 겁니다"는 아무도 받아들이지 않는 문장이고, 받아들여져서도 안 됩니다.

달라지는 것은 검토의 존재가 아니라 그 모양입니다. 모든 줄을 읽는 방식은 에이전트 다섯 개가 병렬로 도는 현실을 견디지 못하고, 저녁 여섯 시에 900줄짜리 diff를 훑는 사람은 지식 없이 서명만 만들어 냅니다. 버티는 원칙은 폭발 반경에 비례해서 검토하는 것입니다. 문구와 스타일은 훑고 지나가되, 인증과 결제, 권한, 개인 데이터, 마이그레이션은 매번 줄 단위로, 직접 쓸 줄 아는 사람이 읽습니다.

이걸 실행 가능하게 만드는 것이 두 가지 있습니다. 하나로 뭉친 더미가 아니라 에이전트별로 diff를 볼 수 있는 것은, 셋이 같은 저장소에서 일했을 때 누가 무엇을 바꿨는지 알려 줍니다. 그리고 대화를 커밋에 붙여 두는 것은 여섯 달 뒤에 진짜로 시간을 잡아먹는 질문에 답해 줍니다. 그 질문은 언제나 무엇이 바뀌었는가가 아니라 왜였는가입니다.

사용자 인터페이스가 있는 것이라면 확인은 diff에서 끝나지 않습니다. 진짜 브라우저를 직접 조작하는 에이전트는 방금 만든 흐름을 처음부터 끝까지 밟아 보고 무엇을 봤는지 보고할 수 있는데, 이것이 소스만 읽으면 아주 멀쩡해 보이는 종류의 버그를 잡아냅니다.

그 주의를 어디에 써야 하는지에 대해서는 글 한 편을 통째로 썼습니다: 여전히 AI 에이전트의 코드를 검토해야 할까요.

고리 6: 배포, 그리고 고리 닫기

배포는 이 고리에서 쉬운 쪽 절반입니다. 건너뛰게 되는 절반은 요청한 사람에게 알리는 일입니다.

그리고 돌아오는 것이 가장 큰 쪽도 그 절반입니다. 무언가를 제보하고 나중에 그게 배포됐다는 소식을 들은 사용자는 다음 것도 제보합니다. 침묵 속으로 제보한 사용자는 제보를 그만두고, 그러면 고리 1을 먹여 살리던 입력이 사라집니다. 공개 요청에서 나온 티켓이 닫힐 때, 그것을 올린 사람은 누가 메일 보낼 일을 기억해 내지 않아도 소식을 들어야 합니다.

그 앞에는 대개, 그게 돌아가는 걸 봐야 하는데 당신의 개발 환경은 갖고 있지 않은 사람이 있습니다. 클라이언트, 디자이너, 다른 대륙에 있는 동료 같은 사람들입니다. 로컬 머신을 가리키는 공개 HTTPS URL은 그것을 배포가 아니라 링크 하나로 만들어 주고, 거기서 돌아오는 피드백은 곧장 고리 1로 들어갑니다.

사슬이 닫힙니다. 이것이 이 일을 대기열이 아니라 직업으로 만드는 지점입니다.

실제로 줄어든 것과 실제로 커진 것

이 표를 정직하게 읽으면 불안의 모양이 달라집니다. 줄어든 부분은 사람을 뽑기가 가장 쉬웠던 부분입니다. 커진 부분은 시스템과 사용자와 결과를 이해하는 사람이 필요한 부분입니다. 더 작아진 일이 아니라 더 어려워진 일이고, 하루 종일 타이핑하던 시절보다 훨씬 덜 외롭습니다.

이 모든 것에서 AgentsRoom이 있는 자리

저희는 사슬 전체를 붙잡는 도구를 만듭니다. 대안은 서로를 모르는 도구 여섯 개이기 때문입니다.

구체적으로는 이렇습니다. 요청이 보드에 도착해 스스로 아이디어로 정리되고, 티켓으로 승격되고, 에이전트가 잘못 읽을 수 없는 것으로 범위가 잡히고, 당신의 머신이나 원격 머신에서 에이전트 하나 또는 에이전트 팀이 실행하고, 대화가 붙은 채로 에이전트별로 검토되고, 요청한 사람에게 알리면서 닫힙니다. 창 하나, 작업의 상태가 진짜인 자리 하나.

조각들은 다른 곳에도 있습니다. 아무도 내놓지 않던 것은 조각들 사이의 연결이고, 일이 새는 곳이 바로 그 연결입니다.

사람들이 실제로 묻는 질문

AI가 소프트웨어 개발자를 대체할까요?

AI가 대체한 것은 타이핑이지 직업이 아닙니다. 코드를 쓰는 일은 하나의 고리이고, 같은 사슬에는 사용자에게 무엇이 필요한지 듣는 일, 무엇이 만들 가치가 있는지 정하는 일, 그것을 정확하게 명세하는 일, 작업을 굴리는 일, 확인하는 일, 배포하는 일이 함께 들어 있습니다. 에이전트는 고리 하나의 비용을 무너뜨렸고, 그 결과 나머지 다섯 개가 병목이 되었습니다. 코드 줄을 찍어 내는 대가로 돈을 받는 사람은 줄어들 것입니다. 어떤 줄이 존재해야 하는지 정하고 그 줄이 프로덕션에 올라간 뒤에 책임까지 지는 대가로 돈을 받는 사람은 늘고 있습니다.

에이전트가 코드를 쓰는 시대에 개발자는 실제로 무엇을 합니까?

여섯 가지이고, 그중 코드로 가득 찬 화면에 보이던 것은 하나뿐이었습니다. 사람들이 무엇을 요청하는지 모으고, 무엇을 어떤 순서로 만들지 정하고, 에이전트가 잘못 읽을 수 없을 만큼 정확하게 작업을 브리핑하고, 여러 건을 동시에 굴리면서 흐름을 놓치지 않고, 각 변경이 무엇을 깨뜨릴 수 있는지에 비례해서 검토하고, 배포한 뒤 요청한 사람에게 알립니다. 기술은 변경을 만들어 내는 쪽에서 그것을 명세하고 책임지는 쪽으로 옮겨 갔습니다.

여전히 코딩을 할 줄 알아야 합니까?

네, 그리고 읽는 쪽으로는 전보다 더 그렇습니다. 일 년에 두 번 만지는 언어의 문법을 외우고 있을 필요는 없습니다. 그건 에이전트가 씁니다. 대신 diff를 열고 몇 초 안에 판단할 수 있어야 합니다. 이 마이그레이션은 되돌릴 수 있는지, 인증 검사가 자리를 옮기지는 않았는지, 이 쿼리가 트래픽 열 배에서도 버티는지. 코드를 읽지 못하는 사람은 에이전트를 검토할 수 없고, 에이전트를 검토하지 못하는 사람은 그것을 조종하는 것이 아니라 그저 잘되기를 바라고 있을 뿐입니다.

코딩을 에이전트에게 넘기면 무엇부터 무너집니까?

우선순위 결정입니다. 만드는 데 2주가 아니라 반나절이 걸리면 잘못된 것을 만드는 비용이 눈에 보이지 않게 되고, 그래서 그것이 만들어집니다. 팀에는 배포된 기능만 늘어나고 해결된 문제는 하나도 늘지 않습니다. 두 번째로 무너지는 것은 피드백 고리입니다. 사용자 요청이 누구도 분류할 수 없는 속도로 들어와 대화 스레드에 쌓인 채 사라지고, 같은 요청인 줄 아무도 알아채지 못해서 같은 것이 두 번 만들어집니다.

이 새로운 방식에서 가장 어려운 능력은 무엇입니까?

에이전트가 잘못 읽을 수 없는 브리핑을 쓰는 일입니다. 에이전트는 동료처럼 모호한 지시에 되묻지 않습니다. 빈칸을 그럴듯한 추측으로 채우고, 앞뒤는 맞으면서 틀린 결과물을 내놓습니다. 좋은 결과를 얻는 사람들은 영리한 프롬프트를 가진 사람들이 아니라, 재사용 가능한 맥락을 갖춰 두는 사람들입니다. 저장소에 커밋해 둔 컨벤션 파일, 반복되는 작업마다 저장해 둔 절차, 에이전트가 탐색에 들어가기 전에 읽는 프로젝트 메모리, 그리고 화면을 문단으로 설명하는 대신 건네는 스크린샷이나 스케치입니다.

코딩 에이전트는 내 머신에서 돌려야 합니까, 원격 머신에서 돌려야 합니까?

둘 다이고, 작업마다 고릅니다. 도중에 지켜보거나 끊거나 고치고 싶은 것은 눈앞의 머신에 둡니다. 길고, 잘 정의되어 있고, 모호한 구석이 없는 작업은 본인이 가진 다른 머신이나 SSH로 붙는 서버에 두어서, 두 시간짜리 작업이 노트북을 붙잡고 있지 않게 합니다. 판단을 가르는 질문은 성능이 아니라, 본인이 개입해야 할 가능성이 얼마나 되느냐입니다.

요약

이 직업은 사라지지 않았습니다. 에디터 밖으로 나가, 그 주변을 둘러싼 사슬로 자리를 옮겼습니다.

이번 달에 딱 하나만 바꾸겠다면 고리 1을 고르세요. 그 아래에 있는 전부는 잘못된 문제를 겨냥하는 순간 낭비된 노력이 되고, 당신의 주의 한 시간이 에이전트 시간 한 시간을 여전히 이기는, 그것도 아무도 잴 수 없는 배율로 이기는 유일한 고리이기 때문입니다.