제2장 Agent-First란 무엇인가

지난 장에서 우리는 왜 '사이드바 챗봇' 방식이 점점 답답해졌는지 살펴봤습니다. 이제 한 걸음 더 들어가 보겠습니다. 도대체 Agent-First란 무엇일까요?

겉으로만 보면 별것 아닌 변화처럼 보일 수 있습니다. 예전에는 AI에게 질문했고, 이제는 AI에게 일을 시킨다. 문장만 바뀐 것 같지요. 하지만 실제로는 개발의 중심축이 이동하고 있습니다. 입력창에 무엇을 물을지 고민하던 방식에서, 어떤 일을 어떻게 맡기고 어떤 기준으로 검토할지 설계하는 방식으로 넘어가고 있기 때문입니다.

이 장의 핵심은 단순합니다. AI를 쓰는 개발자와 에이전트를 운영하는 개발자는 비슷해 보이지만, 사고방식이 완전히 다르다는 점입니다. Agent-First는 기능 하나의 이름이 아니라, 개발자가 AI와 협업하는 기본 자세를 바꾸는 개념입니다.

질문하는 개발자에서, 위임하는 개발자로

기존의 AI 코딩 경험은 대체로 이런 흐름이었습니다. 개발자가 묻습니다. "이 에러가 왜 나지?" "이 함수 리팩터링해줘." "테스트 코드 하나 써줘." 그러면 AI가 대답하거나 코드 조각을 내놓습니다. 그다음은 다시 사람 차례입니다. 붙여넣고, 실행하고, 깨지면 다시 묻고, 설명이 부족하면 또 묻습니다.

이 방식은 분명 유용했습니다. 하지만 구조적으로는 여전히 사람이 모든 작업의 중심에 서 있습니다. AI는 늘 대기 중인 조수입니다. 손을 들기 전까지 움직이지 않고, 한 번에 한 질문씩만 처리합니다.

Agent-First는 여기서 출발점을 바꿉니다. 질문이 아니라 미션이 중심이 됩니다. "이 코드가 왜 실패하지?"라고 끝내는 대신, "원인을 찾아 수정하고, 테스트를 돌린 뒤 무엇이 바뀌었는지 보고해줘"라고 맡깁니다. "로그인 버튼 만들어줘"가 아니라, "기존 인증 구조와 충돌 없이 Google 로그인 플로우를 붙이고, 필요한 설정 변경과 검증 방법까지 정리해줘"라고 위임합니다.

즉, Agent-First에서 AI는 답변 기계가 아니라 작업을 수행하는 주체가 됩니다. 물론 완전한 자율은 아닙니다. 목표를 정하고, 제약을 걸고, 멈춰야 할 지점을 지정하는 것은 여전히 사람의 몫입니다. 다만 사람의 개입 위치가 바뀝니다. 한 줄 한 줄을 직접 써 내려가는 자리가 아니라, 전체 흐름을 설계하고 결과를 판단하는 자리로 이동하는 것입니다.

동기적 대화에서 비동기적 위임으로

Agent-First를 가장 잘 설명하는 대비는 이것입니다. 동기적 대화에서 비동기적 위임으로.

동기적 대화는 메신저처럼 작동합니다. 내가 묻고, 상대가 답합니다. 다시 내가 추가 설명을 하고, 상대가 다음 답을 줍니다. 이 방식은 즉각적이고 편하지만, 작업이 길어질수록 사람이 계속 붙어 있어야 합니다. AI와의 대화가 마치 탁구 랠리처럼 이어집니다. 공이 멈추면 일도 멈춥니다.

비동기적 위임은 조금 다릅니다. 여기서는 내가 먼저 일을 정의합니다. 목표가 무엇인지, 하지 말아야 할 것이 무엇인지, 끝났다고 볼 기준이 무엇인지 정합니다. 그리고 에이전트가 그 틀 안에서 스스로 움직이게 합니다. 사람은 매 순간 키보드를 두드리며 대화하지 않아도 됩니다. 대신 중간 산출물을 검토하거나, 방향이 틀어졌을 때 개입합니다.

이 차이는 생각보다 큽니다. 예를 들어 버그 수정 하나를 맡긴다고 해보겠습니다.

동기적 방식에서는 이런 일이 자주 벌어집니다. 에러 로그를 붙여넣고, 관련 파일을 지정하고, 시도해볼 만한 수정안을 받고, 직접 고치고, 테스트하고, 다시 실패 로그를 붙여넣고, 또 대화를 이어갑니다. AI는 똑똑해 보여도, 실제로는 내 손을 떠나지 못합니다.

반면 비동기적 위임에서는 흐름이 달라집니다. "재현 → 원인 분석 → 수정 → 테스트 → 변경 요약"이라는 작업 묶음을 통째로 맡깁니다. 에이전트는 중간에 필요한 파일을 열고, 수정을 제안하거나 적용하고, 테스트를 돌리고, 최종적으로 무엇을 했는지 보고합니다. 사람은 처음과 끝, 그리고 중요한 검토 지점에 집중합니다.

여기서 중요한 것은 속도만이 아닙니다. 집중력의 구조가 바뀐다는 점입니다. 동기적 대화는 개발자의 주의를 계속 잘게 찢습니다. 비동기적 위임은 반대로, 개발자의 주의를 더 비싼 판단에 쓰게 만듭니다. 무엇을 맡길지, 어디까지 허용할지, 어떤 결과를 통과시킬지 같은 판단 말입니다.

Agent-First는 단순한 '긴 프롬프트'가 아니다

이쯤 되면 어떤 독자는 이렇게 생각할 수 있습니다. "그냥 프롬프트를 더 자세히 쓰면 되는 거 아닌가?" 절반은 맞고, 절반은 틀립니다.

물론 좋은 위임은 좋은 지시에서 시작합니다. 하지만 Agent-First는 단지 프롬프트 길이가 길어지는 현상이 아닙니다. 핵심은 책임 단위가 커진다는 데 있습니다. 예전에는 AI가 코드 조각 하나를 제안하고 끝났다면, 이제는 계획을 세우고, 실행하고, 결과를 남기고, 검토를 요청하는 흐름까지 포함합니다.

즉, Agent-First는 다음 네 요소가 함께 움직일 때 성립합니다.

• 목표를 작업 단위로 정의한다.

• 에이전트가 그 목표를 향해 여러 단계를 수행한다.

• 사람은 중간 결과와 최종 결과를 검토한다.

• 작업 과정이 흔적과 증거를 남긴다.

이 네 가지 중 하나라도 빠지면, 그냥 성능 좋은 챗봇일 가능성이 큽니다. Agent-First의 본질은 AI가 더 말을 잘하는 데 있지 않습니다. 일의 덩어리를 다룬다는 데 있습니다.

개발자의 역할은 세 갈래로 다시 나뉜다

Agent-First 시대의 개발자를 이해할 때 유용한 틀이 있습니다. 바로 Craftsman, Power User, Manager라는 세 역할입니다. 이 셋은 서로 다른 직업이 아니라, 한 사람이 상황에 따라 오가게 되는 운영 모드에 가깝습니다.

Craftsman: 여전히 손으로 만드는 사람

Craftsman은 전통적인 개발자상에 가장 가깝습니다. 코드의 디테일을 읽고, 설계의 균형을 맞추고, 성능과 안정성을 챙기는 사람입니다. 함수 시그니처 하나, 상태 관리의 흐름 하나, 예외 처리의 위치 하나까지 꼼꼼하게 다룹니다.

Agent-First 시대에도 Craftsman은 사라지지 않습니다. 오히려 더 중요해집니다. 왜냐하면 에이전트가 만든 초안을 진짜 제품 수준으로 끌어올리는 일은 여전히 세밀한 눈을 필요로 하기 때문입니다. 특히 아래와 같은 영역에서는 Craftsman의 감각이 결정적입니다.

• 복잡한 비즈니스 규칙이 얽힌 핵심 도메인 로직

• 성능, 보안, 동시성처럼 실수 비용이 큰 영역

• 장기 유지보수성을 좌우하는 아키텍처 결정

Agent-First가 손기술을 무시하는 패러다임이라고 생각하면 오해입니다. 오히려 손기술이 쓰이는 위치가 더 비싸고 중요한 지점으로 올라간다고 보는 편이 맞습니다.

Power User: 도구의 힘을 증폭시키는 사람

Power User는 AI 도구를 단순 사용자가 아니라 레버리지 장치로 다루는 사람입니다. 어떤 작업은 빠르게 넘기고, 어떤 작업은 검토 중심으로 돌리고, 어떤 작업은 세 개로 쪼개 병렬로 처리할지 감각적으로 판단합니다.

예전의 Power User가 단축키, 스니펫, 매크로, CLI를 잘 쓰는 사람이었다면, Agent-First 시대의 Power User는 여기에 한 가지 능력이 더 필요합니다. 바로 위임 설계 능력입니다. 일을 어떻게 쪼개야 에이전트가 잘 수행하는지, 어떤 제약을 걸어야 사고를 줄일 수 있는지, 어디에 리뷰 포인트를 두어야 다시 하지 않는지를 아는 사람입니다.

쉽게 말해, Power User는 AI를 한 번 써보고 "오, 똑똑하네" 하고 끝내는 사람이 아닙니다. AI가 가장 잘 움직이는 작업 구조를 찾아내고, 그 구조를 반복 가능한 습관으로 만드는 사람입니다.

Manager: 방향과 판정을 책임지는 사람

Manager는 Agent-First를 가장 잘 상징하는 역할입니다. 여기서 말하는 매니저는 직급이 아닙니다. 사람을 관리하는 관리자라는 뜻도 아닙니다. 작업의 방향, 범위, 우선순위, 성공 기준을 관리하는 개발자를 뜻합니다.

이 역할의 핵심은 세 가지입니다.

• 무엇을 맡길지 정의한다.

• 언제 개입할지 정한다.

• 무엇을 통과시킬지 판정한다.

좋은 Manager는 프롬프트를 화려하게 쓰는 사람이 아닙니다. 문제를 명확히 정의하는 사람입니다. 예를 들어 "회원가입 만들어줘"라고 말하는 대신, "이메일 가입만 우선 구현하고, 소셜 로그인과 비밀번호 재설정은 제외하며, 기존 사용자 모델은 유지하고, 성공 기준은 가입 후 대시보드 리다이렉트와 기본 검증 테스트 통과"라고 말할 수 있는 사람입니다.

이런 사람은 AI에게 일을 많이 맡기면서도 통제력을 잃지 않습니다. 왜냐하면 처음부터 범위와 기준을 잘 정했기 때문입니다.

세 역할은 경쟁하지 않고 순환한다

많은 사람이 여기서 한 가지 오해를 합니다. Agent-First가 오면 개발자는 전부 Manager가 되어야 한다고 생각하는 것입니다. 하지만 실제 현장에서는 그렇지 않습니다. 한 사람 안에서 세 역할이 계속 순환합니다.

아침에는 Manager처럼 요구사항을 쪼개고 우선순위를 정할 수 있습니다. 점심 전에는 Power User처럼 세 개의 작업을 병렬로 돌리며 피드백 루프를 설계할 수 있습니다. 오후에는 Craftsman처럼 가장 위험한 로직을 직접 손으로 다듬을 수 있습니다.

중요한 것은 "나는 이제 코드를 안 써"가 아닙니다. 나는 언제 직접 쓰고, 언제 맡기고, 언제 검토하는가를 더 의식적으로 결정하게 된다는 점입니다.

이것이 Agent-First가 개발자를 약하게 만드는 것이 아니라, 오히려 더 상위 레벨의 판단으로 끌어올리는 이유입니다.

"Don't write code, manage agents"의 진짜 의미

이제 가장 도발적인 문장을 살펴봅시다. "Don't write code, manage agents."

처음 들으면 꽤 자극적입니다. 개발자에게 코드 쓰지 말라니, 셰프에게 칼을 내려놓으라는 말처럼 들립니다. 그래서 이 문장을 문자 그대로 받아들이면 곤란합니다. 이 선언의 진짜 의미는 코드를 절대 쓰지 말라가 아니라, 개발의 출발점을 키보드에서 문제 정의로 옮기라는 뜻에 가깝습니다.

예전에는 일이 생기면 곧바로 파일을 열고 코드를 쓰기 시작했습니다. Agent-First에서는 먼저 이렇게 묻습니다.

• 이 일을 하나의 미션으로 정의할 수 있는가?

• 어디까지 맡기고 어디서 멈추게 할 것인가?

• 끝났다는 증거를 무엇으로 받을 것인가?

이 질문이 먼저 나오면, 개발은 더 이상 '타이핑 경기'가 아닙니다. 운영과 설계의 성격을 띠기 시작합니다.

이 문장이 강조하는 것은 세 가지 전환입니다.

첫째, 생산의 중심이 입력에서 지시로 이동합니다. 내가 모든 줄을 직접 쓰는 대신, 올바른 작업 단위를 만들고 적절한 제약을 겁니다.

둘째, 가치의 중심이 구현에서 판정으로 이동합니다. 중요한 것은 얼마나 많이 쳤는지가 아니라, 어떤 결과를 통과시키고 어떤 결과를 되돌렸는지입니다.

셋째, 실력의 중심이 속도에서 구조화로 이동합니다. 손이 빠른 사람보다, 문제를 잘게 쪼개고 성공 기준을 분명히 적는 사람이 더 큰 성과를 낼 수 있습니다.

그러니 이 선언은 개발자를 모욕하는 말이 아니라, 개발자의 시간을 더 비싼 곳에 쓰라는 말입니다.

하지만 코드를 모르면 에이전트도 못 다룬다

여기서 균형을 꼭 잡아야 합니다. Agent-First를 오해하면 "이제 코드는 몰라도 되겠네"라는 위험한 결론으로 가기 쉽습니다. 현실은 정반대입니다. 코드를 모르면 에이전트가 잘못 간다는 사실도 늦게 알아차립니다.

에이전트를 잘 운영하려면 오히려 더 많은 기술 감각이 필요합니다. 왜 이런 설계를 택했는지, 테스트가 충분한지, 표면적으로는 돌아가지만 장기적으로 위험한 선택은 아닌지 판단해야 하기 때문입니다. 사람이 이해하지 못하는 시스템을 사람 대신 AI가 운영해주리라고 기대하는 것은, 지도도 없이 자동운전에 올라타는 것과 비슷합니다.

Agent-First의 성숙한 태도는 이렇습니다. 반복적이고 기계적인 부분은 과감히 맡긴다. 그러나 위험이 큰 결정, 핵심 설계, 품질 기준은 사람이 끝까지 책임진다. 다시 말해, 코드를 덜 쓰더라도 코드에 대한 책임은 더 무거워진다는 뜻입니다.

좋은 Agent-First 개발자는 무엇이 다른가

그렇다면 Agent-First를 잘하는 개발자는 어떤 사람일까요? 이들은 대체로 공통된 습관을 갖고 있습니다.

먼저, 일을 바로 던지지 않고 작업 단위를 설계합니다. "버그 고쳐줘"보다 "재현 조건은 이렇고, 원인은 여기까지 의심되며, 이 테스트를 통과하면 완료로 본다"에 가깝게 말합니다.

또한, 결과를 막연히 보지 않고 검증 기준으로 봅니다. "대충 된 것 같다"가 아니라 "명세에 맞는가, 테스트가 보장하는가, 기존 동작을 깨지 않았는가"로 판단합니다.

마지막으로, 맡긴 일을 무조건 믿지도, 무조건 의심하지도 않습니다. 잘 맡길 것은 맡기고, 직접 볼 것은 직접 봅니다. 신뢰를 감정이 아니라 절차로 만든다고 할 수 있습니다.

이런 태도는 팀 전체의 개발 방식도 바꿉니다. 개인의 요령이 아니라, 반복 가능한 운영 체계가 생기기 때문입니다.

Agent-First가 가져오는 일상의 변화

이 패러다임은 철학처럼 들리지만, 사실은 아주 실무적인 변화로 나타납니다. 하루의 리듬 자체가 달라집니다.

예전에는 이렇게 일했습니다. 이슈를 읽고, 코드를 열고, 직접 수정하고, 막히면 AI에게 물어보고, 다시 수정하고, 브라우저를 새로고침합니다.

Agent-First에서는 이런 흐름이 자연스러워집니다. 이슈를 읽고, 작업을 명세로 바꾸고, 에이전트에게 위임하고, 중간 계획이나 산출물을 검토하고, 방향을 수정하고, 최종 결과를 승인합니다.

겉보기에는 사람이 덜 일하는 것처럼 보일 수 있습니다. 하지만 실제로는 일이 사라지는 것이 아니라, 사람이 하는 일의 종류가 바뀌는 것입니다. 손의 노동이 줄고, 판단의 노동이 늘어납니다.

이 변화는 특히 세 부류의 독자에게 크게 다가옵니다.

첫째, 이미 Cursor나 Copilot을 진지하게 쓰고 있는 개발자는 "어떻게 더 많이 자동화할까?"보다 "어떻게 더 크게 위임할까?"를 고민하게 됩니다.

둘째, 테크 리드나 CTO는 개인 생산성보다 팀 차원의 운영 모델에 관심을 갖게 됩니다. 누가 어떤 작업을 에이전트에게 맡기고, 어떤 검토 절차를 표준으로 삼을지 정해야 하기 때문입니다.

셋째, 1인 창업자나 PM은 처음으로 '개발'이라는 일을 세부 구현이 아니라 작업 지휘의 문제로 다루기 시작합니다. 물론 한계는 분명하지만, 진입장벽은 실제로 낮아집니다.

Agent-First의 본질은 통제 가능한 자율성이다

마지막으로, Agent-First를 한 문장으로 요약해보겠습니다.

Agent-First는 AI에게 더 많은 자유를 주는 방식이 아니라, 사람이 더 높은 수준의 통제를 행사하기 위해 자율성을 구조화하는 방식이다.

이 문장이 중요한 이유는, 많은 사람이 자율성과 통제를 반대로 생각하기 때문입니다. 맡기면 통제력을 잃는다고 느끼지요. 하지만 실제로는 그 반대일 수 있습니다. 작업 단위를 잘 정의하고, 검토 지점을 잘 설계하고, 결과를 흔적으로 남기면 사람은 매 순간 타이핑하지 않고도 더 넓은 범위를 통제할 수 있습니다.

Agent-First는 바로 그 전환을 제안합니다. AI를 똑똑한 자동완성으로만 두지 않고, 책임 있는 실행 단위로 올려놓는 것. 그리고 개발자는 단순 사용자에서 운영자로 진화하는 것.

이제 Antigravity를 바라보는 관점도 조금 달라질 것입니다. 중요한 것은 "얼마나 그럴듯한 코드를 써주느냐"가 아닙니다. "얼마나 잘 맡길 수 있고, 얼마나 잘 검토할 수 있느냐"입니다.

그리고 바로 그 지점에서 다음 장의 주제가 등장합니다. 에이전트에게 일을 맡길 수 있다면, 결국 가장 큰 질문은 이것이 됩니다.

그 결과를 우리는 어떻게 믿을 것인가?

다음 장에서는 Antigravity가 풀려는 가장 중요한 문제, 바로 신뢰의 격차를 다룹니다.