AI 네이티브 시대, 어떤 엔지니어가 살아남을까?

6,600 커밋 개발자가 증명한 결과 중심 사고의 힘

1. 알고리즘을 사랑한 엔지니어 vs. 제품을 출시하고 싶은 엔지니어

소프트웨어 엔지니어라는 직업은 오랫동안 두 가지 서로 다른 유형의 사람들을 끌어들여 왔다. 한쪽에는 복잡한 알고리즘 퍼즐을 풀 때 희열을 느끼는 사람들이 있다. 이들은 코드 한 줄 한 줄의 우아함에 집착하고, 자료구조의 효율성을 최적화하는 데서 깊은 만족감을 얻는다. 다른 한쪽에는 무언가를 만들어서 세상에 내놓는 것 자체를 즐기는 사람들이 있다. 이들에게 코드는 목적이 아니라 수단이며, 진정한 보상은 사용자가 실제로 쓸 수 있는 제품이 완성되는 순간에 찾아온다. 지난 수십 년간 소프트웨어 산업은 이 두 유형 모두를 필요로 했고, 두 유형 모두 성공할 수 있는 길이 열려 있었다.

그러나 AI 에이전트가 개발 워크플로우의 중심에 들어서면서, 이 두 유형의 엔지니어가 마주하는 현실은 극적으로 달라지기 시작했다. 구현의 세부사항에 깊이 몰입하고 알고리즘 퍼즐 풀기를 좋아하는 엔지니어들은 AI 네이티브 개발 환경으로의 전환에 어려움을 겪고 있다. 반면 제품을 출시하는 것을 좋아하고 결과물에 관심을 집중하는 엔지니어들은 이 새로운 환경에 훨씬 빠르게 적응하고 있다. 이것은 단순한 관찰이 아니라, AI 에이전트를 활용해 전례 없는 생산성을 달성한 개발자들이 직접 경험하고 증언하는 현상이다.

2026년 1월, 한 개인 개발자가 소프트웨어 개발 커뮤니티에 충격을 안겼다. Peter Steinberger라는 이름의 이 개발자는 단 한 달 만에 6,600회 이상의 커밋을 기록했다. 이 숫자만 보면 수십 명 규모의 개발팀이 운영하는 스타트업의 활동량처럼 보인다. 그러나 실제로는 집에서 재미로 코딩하는 한 사람이 만들어낸 결과물이었다. 그가 개발한 Moltbot은 GitHub 역대 가장 빠른 스타 성장률을 기록했으며, 지난 주 Google 검색량에서 Claude Code와 Codex를 합친 것보다 더 많은 검색량을 기록했다. Tailwind CSS와 비교해도 성장 곡선이 전례 없는 수준이라는 평가가 나올 정도다.

Peter Steinberger의 사례가 특별한 이유는 단순히 생산성 수치가 높기 때문이 아니다. 그의 워크플로우와 철학이 AI 시대에 어떤 유형의 엔지니어가 번성할 것인지를 명확하게 보여주기 때문이다. 그는 5개에서 10개의 AI 에이전트를 동시에 운영하면서 개발을 진행한다. 코드 리뷰에 시간을 쓰는 대신 아키텍처 논의에 집중한다. 세부적인 구현보다는 시스템 전체의 설계와 방향성에 에너지를 투자한다. 이러한 접근 방식은 구현의 아름다움에 집착하는 전통적인 엔지니어 마인드셋과는 근본적으로 다르다.

흥미로운 것은 Peter가 처음부터 이런 사고방식을 가졌던 것은 아니라는 점이다. 그는 PSPDFKit이라는 글로벌 개발자 도구 비즈니스를 창업하고 70명 이상의 개발팀을 운영한 경험이 있다. 그리고 바로 그 경험이 그에게 완벽주의를 내려놓는 법을 가르쳤다. 대규모 팀을 이끌면서 모든 코드가 자신의 취향에 맞을 수 없다는 사실을 받아들여야 했고, 결과적으로 이 능력이 현재 AI 에이전트와의 협업에서 엄청난 효율성을 발휘하게 해주고 있다. 코드가 완벽하지 않아도 괜찮다고 생각할 수 있는 사람만이 AI 에이전트를 진정으로 활용할 수 있다는 것이다.

AI 네이티브 개발 환경은 엔지니어에게 새로운 질문을 던진다. 당신은 코드 자체에 관심이 있는가, 아니면 코드가 만들어내는 결과물에 관심이 있는가. 알고리즘의 우아함에서 만족을 얻는가, 아니면 제품이 사용자에게 전달되는 순간에 만족을 얻는가. 구현의 세부사항을 직접 통제하고 싶은가, 아니면 시스템 전체의 방향을 설계하는 역할에 더 끌리는가. 이 질문들에 대한 답이 AI 시대에 당신이 어떤 위치에 서게 될지를 결정할 것이다.

2. 완벽한 코드에 대한 집착을 내려놓을 때 일어나는 일

앞서 기술한 것처럼 Peter Steinberger는 PSPDFKit의 창업자다. PDF 관련 개발자 도구를 만드는 이 회사를 그는 글로벌 비즈니스로 성장시켰고, 전성기에는 70명 이상의 개발팀을 운영했다. 개발자 출신 창업자로서 그는 코드의 품질에 대한 높은 기준을 가지고 있었다. 자신이 직접 작성했다면 이렇게 쓰지 않았을 코드, 자신의 스타일과 맞지 않는 구현 방식, 더 우아하게 해결할 수 있었을 문제들.

초기에는 이런 것들이 눈에 거슬렸을 것이다. 그러나 70명의 개발자가 동시에 코드를 작성하는 환경에서 모든 코드가 창업자 한 사람의 취향에 맞을 수는 없다. 그는 이 현실을 받아들여야 했고, 그 과정에서 완벽주의를 내려놓는 법을 배웠다.

3년간의 휴식 후 그가 개발 현장에 복귀했을 때, 세상은 완전히 달라져 있었다. LLM과 AI 에이전트가 개발 워크플로우의 핵심 도구로 부상해 있었다. Peter는 이번에는 AI 에이전트를 워크플로우의 중심에 배치하기로 결정했다. 그리고 여기서 과거의 경험이 예상치 못한 방식으로 빛을 발했다. 70명의 개발자와 일하면서 체득한 완벽주의를 내려놓는 능력이 AI 에이전트와의 협업에서 결정적인 효율성을 가져다준 것이다.

AI 에이전트가 작성하는 코드는 인간 개발자가 작성하는 코드와 다르다. 때로는 개발자 본인이라면 선택하지 않았을 패턴을 사용하고, 때로는 불필요해 보이는 중복이 있으며, 때로는 스타일 가이드와 미묘하게 어긋난다. 완벽주의적 성향을 가진 개발자라면 이런 코드를 보는 순간 수정하고 싶은 충동을 느낄 것이다. 그리고 그 충동에 따라 행동하는 순간, AI 에이전트를 활용하는 이점의 상당 부분이 사라진다. 에이전트가 생성한 코드를 일일이 자신의 스타일에 맞게 다듬고 있다면, 차라리 처음부터 직접 작성하는 것과 크게 다르지 않기 때문이다.

Peter가 발견한 것은 간단하지만 실천하기 어려운 진실이었다. 코드가 항상 자신의 취향에 맞지 않을 수 있다는 사실을 받아들이면, 에이전트를 다룰 때 훨씬 더 효율적으로 일할 수 있다. 이것은 코드 품질을 포기하라는 의미가 아니다. 코드가 동작하고, 테스트를 통과하며, 시스템의 전체적인 아키텍처와 조화를 이루면 그것으로 충분하다는 관점의 전환이다. 변수명이 자신이 선호하는 컨벤션과 다르거나, 함수의 분리 방식이 자신의 직관과 약간 다르더라도 그것이 큰 그림에 영향을 주지 않는다면 넘어갈 수 있어야 한다.

이 마인드셋의 전환이 가져오는 생산성 향상은 극적이다. Peter는 한 달에 6,600회 이상의 커밋을 기록했는데, 이는 그가 AI 에이전트를 고용된 개발자처럼 대할 수 있었기 때문에 가능한 일이었다. 에이전트에게 작업을 할당하고, 결과물이 기능적으로 정확한지 확인하고, 다음 작업으로 넘어간다. 코드 스타일의 미세한 차이에 대해 에이전트와 논쟁하거나 수정을 요청하는 데 시간을 쓰지 않는다. 그 시간에 다른 에이전트에게 다른 기능을 할당할 수 있기 때문이다.

흥미롭게도 이 능력은 가르치기 어렵다. 혼자서 또는 소규모 팀에서 오랫동안 일해 온 개발자일수록 자신만의 코딩 스타일과 기준이 확고하게 형성되어 있다. 그리고 그 기준에 맞지 않는 코드를 받아들이는 것은 심리적으로 불편한 경험이다. 반면 대규모 팀에서 다양한 배경의 개발자들과 협업한 경험이 있는 사람은 이미 타협의 기술을 체득하고 있다. 코드베이스 전체가 한 사람의 작품처럼 일관될 수 없다는 것을 알고 있으며, 그 불완전함 속에서도 제품이 동작하고 가치를 전달할 수 있다는 것을 경험으로 배웠다.

Peter의 사례가 시사하는 바는 분명하다. AI 에이전트 시대에 완벽주의는 미덕이 아니라 병목이 될 수 있다. 코드의 모든 세부사항을 통제하려는 욕구를 내려놓을 수 있는 개발자만이 AI 에이전트의 잠재력을 온전히 활용할 수 있다. 그리고 역설적이게도, 이렇게 완벽주의를 내려놓은 개발자가 더 많은 것을 만들어내고, 더 빠르게 제품을 출시하며, 결과적으로 더 큰 영향력을 발휘하게 된다.

3. 대부분의 코드는 지루한 데이터 변환일 뿐이다

소프트웨어 개발이라는 직업에는 일종의 낭만이 있다. 복잡한 문제를 우아한 알고리즘으로 해결하고, 정교한 자료구조를 설계하며, 성능을 극한까지 최적화하는 장인의 이미지가 그것이다. 컴퓨터 과학을 전공하고 코딩 인터뷰를 통과하기 위해 수많은 알고리즘 문제를 풀어온 개발자들은 이런 낭만적 이미지를 내면화하고 있는 경우가 많다. 그러나 실제 현업에서 개발자들이 작성하는 코드의 대부분은 이 이미지와 거리가 멀다.

Peter Steinberger는 이 현실을 직시한다. 대부분의 코드는 지루한 데이터 변환일 뿐이라는 것이다. API에서 데이터를 가져와서 다른 형식으로 변환하고, 데이터베이스에 저장하고, 사용자 인터페이스에 표시하기 위해 또 다른 형태로 가공한다. JSON을 파싱하고, 필드를 매핑하고, 유효성을 검사하고, 에러를 처리한다. 물론 이 과정에서도 깔끔한 코드를 작성하고 예외 상황을 고려하는 것은 중요하다. 그러나 솔직히 말해 이런 작업에는 창의적인 알고리즘 설계가 필요하지 않다. 패턴이 정해져 있고, 모범 사례가 알려져 있으며, 경험 있는 개발자라면 거의 자동적으로 처리할 수 있는 종류의 작업이다.

바로 이 지점에서 AI 에이전트가 게임의 규칙을 바꾸고 있다. 패턴화된 작업, 반복적인 데이터 변환, 보일러플레이트 코드 생성은 AI 에이전트가 인간 개발자만큼 혹은 그 이상으로 잘 수행할 수 있는 영역이다. API 연동 코드를 작성하고, CRUD 기능을 구현하며, 폼 유효성 검사 로직을 만드는 것은 더 이상 인간 개발자가 직접 시간을 투자해야 하는 희소한 작업이 아니다. AI 에이전트에게 명확한 지시를 내리면 충분히 동작하는 코드를 생성해낸다.

문제는 많은 개발자들이 바로 이런 종류의 작업에서 자신의 정체성과 가치를 찾고 있었다는 점이다. 데이터 변환 로직을 깔끔하게 작성하고, 에러 처리를 빈틈없이 하며, 코드 리뷰에서 동료의 실수를 잡아내는 것. 이런 활동들이 자신이 유능한 개발자라는 증거였고, 팀에 기여하고 있다는 확인이었다. 그런데 AI 에이전트가 이 영역을 빠르게 잠식하면서, 이런 종류의 작업에 집착하는 것이 더 이상 경쟁력이 되지 않는 상황이 펼쳐지고 있다.

Peter는 이 현실을 인정하고, 에너지를 다른 곳에 집중한다. 그것은 시스템 설계다. 그는 자신을 소프트웨어 아키텍트로 규정하면서, 프로젝트의 고수준 구조를 머릿속에 유지하는 것을 자신의 핵심 역할로 본다. 아키텍처, 기술 부채, 확장성, 모듈성. 이런 것들에 그는 깊이 신경 쓴다. Moltbot이 빠르게 성장할 수 있었던 이유 중 하나도 바로 이 확장성이다. 새로운 기능을 추가하기 쉽도록 처음부터 시스템을 설계했고, 그 결과 AI 에이전트들이 생성하는 코드가 자연스럽게 전체 시스템에 통합될 수 있었다.

여기서 AI 에이전트에게 위임할 수 있는 것과 없는 것의 경계가 드러난다. 개별 기능의 구현, 데이터 변환 로직, 테스트 코드 작성, 버그 수정. 이런 것들은 명확한 입력과 출력이 정의되어 있다면 AI 에이전트에게 위임할 수 있다. 그러나 시스템 전체가 어떤 방향으로 진화해야 하는지, 어떤 기술적 결정이 6개월 후에 부메랑이 되어 돌아올 것인지, 현재의 아키텍처가 예상되는 규모 증가를 감당할 수 있는지. 이런 판단은 여전히 인간 개발자의 몫이다. 그리고 이런 판단을 내릴 수 있는 능력이야말로 AI 시대에 개발자가 집중해서 키워야 할 역량이다.

Peter의 표현을 빌리자면, 그는 프로젝트의 선량한 독재자다. 방향과 스타일의 일관성을 유지하는 것이 그의 역할이다. AI 에이전트들이 각자 다른 기능을 병렬로 작업하더라도 전체 시스템이 하나의 비전을 향해 나아갈 수 있도록 조율한다. 개별 구현의 세부사항에는 개입하지 않지만, 아키텍처적 결정과 큰 방향성에는 깊이 관여한다. 이것이 AI 에이전트 시대에 개발자가 취해야 할 새로운 역할이다.

구현 세부사항에 에너지를 쏟는 것은 더 이상 개발자의 경쟁력이 아니다. 그 에너지는 시스템 설계에 투자해야 한다. 대부분의 코드가 지루한 데이터 변환이라면, 그 지루한 작업은 AI에게 맡기고 인간은 지루하지 않은 부분에 집중해야 한다. 어떤 데이터를 어떻게 변환할 것인지를 결정하는 것, 그 변환이 시스템 전체에서 어떤 의미를 갖는지를 이해하는 것, 현재의 결정이 미래에 어떤 영향을 미칠지를 예측하는 것. 이것이 AI가 대체할 수 없는 인간 개발자의 고유한 영역이다.

4. 루프를 닫는 자가 승리한다

AI 에이전트에게 코드 작성을 맡기는 것은 어렵지 않다. 원하는 기능을 설명하고 프롬프트를 입력하면 에이전트는 코드를 생성해낸다. 문제는 그다음이다. 그 코드가 실제로 동작하는지, 기존 시스템과 충돌하지 않는지, 예상치 못한 버그를 포함하고 있지는 않은지를 누군가는 확인해야 한다. 만약 이 확인 작업을 인간 개발자가 매번 직접 수행해야 한다면, AI 에이전트를 활용하는 이점은 크게 줄어든다. 코드 생성 시간은 단축되지만 검증 시간은 그대로이기 때문이다. 여기서 루프를 닫는다는 개념이 등장한다.

Peter Steinberger가 강조하는 AI 에이전트 활용의 핵심 원칙 중 하나는 바로 이 루프를 닫는 것이다. 에이전트가 코드를 작성하고, 그 코드를 스스로 컴파일하고, 린트를 실행하고, 테스트를 돌리고, 결과를 검증할 수 있어야 한다. 이 모든 과정이 에이전트 내부에서 완결되어야 한다는 의미다. 인간 개발자가 중간에 개입해서 빌드 버튼을 누르거나 테스트 결과를 확인해주어야 하는 구조라면, 그것은 닫힌 루프가 아니다. 열린 루프에서는 인간이 병목이 되고, 에이전트의 속도가 인간의 응답 속도에 묶이게 된다.

닫힌 루프의 설계는 단순히 편의의 문제가 아니다. 이것은 AI 에이전트를 진정으로 자율적인 개발 파트너로 활용할 수 있느냐 없느냐를 결정하는 구조적 조건이다. 에이전트가 스스로 검증할 수 있는 환경에서는 인간 개발자가 잠든 사이에도 작업이 진행될 수 있다. 에이전트가 코드를 생성하고, 테스트가 실패하면 스스로 수정하고, 다시 테스트를 돌리는 과정을 반복한다. 아침에 일어나면 동작하는 기능이 완성되어 있다. 반면 인간의 확인을 기다려야 하는 구조에서는 에이전트가 아무리 빠르게 코드를 생성해도 결국 인간의 근무 시간에 맞춰 작업이 진행된다.

이 원칙을 실현하기 위해서는 개발 환경 자체를 재설계해야 한다. 먼저 에이전트가 접근할 수 있는 빌드 시스템이 필요하다. 코드를 작성한 후 컴파일 명령을 실행하고 결과를 확인할 수 있어야 한다. 컴파일 에러가 발생하면 에러 메시지를 읽고 스스로 수정할 수 있어야 한다.

린트 도구도 마찬가지다. 코드 스타일 가이드 위반이나 잠재적 문제를 자동으로 감지하고, 에이전트가 그 피드백을 바탕으로 코드를 개선할 수 있어야 한다. 가장 중요한 것은 테스트다. 단위 테스트, 통합 테스트가 갖춰져 있고 에이전트가 이를 실행하고 결과를 해석할 수 있어야 한다.

여기서 로컬 CI의 중요성이 부각된다.

전통적인 개발 워크플로우에서 CI, 즉 지속적 통합 시스템은 보통 원격 서버에서 실행된다. 개발자가 코드를 푸시하면 원격 CI 서버가 빌드와 테스트를 수행하고, 몇 분에서 십여 분 후에 결과를 알려준다. 인간 개발자에게 이 정도의 지연은 감수할 만하다. 코드를 푸시한 후 다른 작업을 하거나 커피를 마시며 기다리면 된다. 그러나 AI 에이전트의 관점에서 10분의 대기 시간은 치명적인 비효율이다. 에이전트는 그 10분 동안 수십 번의 반복 작업을 수행할 수 있기 때문이다.

Peter는 원격 CI 대신 에이전트가 로컬에서 직접 테스트를 실행하는 방식을 채택한다. 코드를 작성하고, 즉시 로컬에서 테스트를 돌리고, 실패하면 바로 수정하고, 다시 테스트를 돌린다. 이 사이클이 몇 초 단위로 반복된다. 원격 CI에서 10분을 기다리는 동안 로컬에서는 수십 번의 수정과 검증이 이루어질 수 있다. 물론 최종적으로 원격 CI를 통한 검증이 필요할 수 있지만, 그것은 에이전트가 로컬에서 충분히 검증한 후의 마지막 단계일 뿐이다. 일상적인 개발 루프는 로컬에서 완결된다.

이 접근 방식은 개발 환경에 대한 초기 투자를 요구한다. 에이전트가 접근할 수 있는 테스트 환경을 구축하고, 빌드 시스템을 자동화하고, 린트 규칙을 정비해야 한다. 테스트 커버리지가 낮은 프로젝트에서는 먼저 테스트를 보강해야 할 수도 있다. 그러나 이 투자는 복리로 돌아온다. 한 번 닫힌 루프를 구축하면, 그 위에서 에이전트가 자율적으로 작업할 수 있는 범위가 기하급수적으로 확장된다. 인간 개발자의 개입 없이도 기능이 구현되고, 버그가 수정되며, 코드베이스가 성장한다.

루프를 닫는 자가 승리한다는 말은 과장이 아니다. AI 에이전트 시대의 개발 생산성은 에이전트의 성능만으로 결정되지 않는다. 에이전트가 얼마나 자율적으로 작업하고 검증할 수 있는 환경이 갖춰져 있느냐가 더 중요하다. 같은 AI 에이전트를 사용하더라도 닫힌 루프를 가진 개발자는 열린 루프에 머무는 개발자보다 몇 배, 몇십 배의 생산성 차이를 만들어낼 수 있다. 루프를 닫는 것은 선택이 아니라 AI 네이티브 개발의 필수 조건이다.

5. Pull Request의 시대는 끝났다 — Prompt Request의 부상

소프트웨어 개발 팀에서 Pull Request와 코드 리뷰는 오랫동안 품질 관리의 핵심 메커니즘이었다. 개발자가 코드를 작성하면 동료가 그 코드를 검토하고, 개선점을 제안하며, 승인을 거쳐 메인 브랜치에 병합된다. 이 과정에서 버그가 조기에 발견되고, 지식이 팀 내에 공유되며, 코드베이스의 일관성이 유지된다. Pull Request 기반 워크플로우는 GitHub가 대중화된 이후 거의 모든 개발 조직의 표준이 되었고, 코드 리뷰 없이 프로덕션에 코드를 배포하는 것은 무책임한 행위로 여겨졌다.

그러나 Peter Steinberger의 워크플로우에서 Pull Request는 더 이상 중심적인 역할을 하지 않는다. 그는 이를 두고 Pull Request는 죽었다고 선언한다. 대신 그가 주목하는 것은 Prompt Request다. AI 에이전트가 코드를 생성하는 시대에, 코드 자체를 리뷰하는 것보다 그 코드를 생성한 프롬프트를 검토하는 것이 더 중요해졌다는 의미다. 프롬프트가 명확하고 올바른 방향을 제시하면 생성되는 코드도 대체로 올바르다. 프롬프트에 문제가 있으면 아무리 코드를 수정해봐야 근본적인 해결이 되지 않는다.

이 관점의 전환은 개발 협업의 성격 자체를 바꾼다. 전통적인 코드 리뷰에서 동료 개발자는 변수명이 적절한지, 함수가 너무 길지는 않은지, 에러 처리가 빠짐없이 되어 있는지를 확인했다. 구현의 세부사항에 대한 논의가 리뷰의 핵심이었다. 그러나 Prompt Request 기반 워크플로우에서 논의의 초점은 완전히 달라진다. 이 기능을 이런 방식으로 구현하는 것이 맞는가, 시스템 전체의 아키텍처와 조화를 이루는가, 장기적으로 유지보수 가능한 구조인가. 구현의 세부사항보다 설계의 방향성이 논의의 중심에 놓인다.

Peter는 Discord에서 핵심 팀과 소통할 때 코드를 논의하지 않는다고 말한다. 대신 아키텍처와 큰 결정만을 논의한다. 특정 함수의 구현이 마음에 들지 않는다고 해서 그것을 팀 회의의 주제로 삼지 않는다. 그런 것은 에이전트에게 수정을 지시하면 된다. 팀이 함께 논의해야 할 것은 시스템의 방향성, 기술 스택의 선택, 모듈 간의 경계 설정 같은 고수준의 결정들이다. 코드 리뷰에 쓰던 시간이 아키텍처 논의로 전환되면서, 오히려 더 본질적인 문제에 집중할 수 있게 되었다.

이러한 워크플로우의 변화는 동시에 여러 에이전트를 운영하는 것을 가능하게 한다. Peter는 평소 5개에서 10개의 AI 에이전트를 동시에 운영하며 개발을 진행한다. 각 에이전트가 서로 다른 기능을 병렬로 작업한다. 한 에이전트가 사용자 인증 모듈을 구현하는 동안 다른 에이전트는 데이터 시각화 컴포넌트를 작성하고, 또 다른 에이전트는 API 엔드포인트를 추가한다. 만약 각 에이전트의 코드를 일일이 리뷰해야 했다면 이런 병렬 작업은 불가능했을 것이다. 코드 리뷰가 병목이 되어 에이전트의 속도를 따라갈 수 없기 때문이다. 그러나 프롬프트 수준에서 방향만 제시하고 세부 구현은 에이전트에게 맡기는 방식이라면 동시에 여러 작업 흐름을 관리할 수 있다.

흥미로운 것은 이 병렬 작업 방식이 오히려 개발자의 몰입 상태를 유지하는 데 도움이 된다는 점이다. 전통적인 개발에서 몰입이 깨지는 순간은 대기 시간이다. 빌드를 기다리거나, 테스트가 돌아가는 것을 지켜보거나, 코드 리뷰 승인을 기다리는 동안 집중력이 흐트러진다. 그러나 여러 에이전트를 동시에 운영하면 한 에이전트가 작업 중일 때 다른 에이전트의 결과를 확인하거나 새로운 작업을 할당할 수 있다. 대기 시간이 사라지고, 항상 무언가를 진행하고 있는 상태가 유지된다.

Peter는 계획 수립에 상당한 시간을 투자한다. 에이전트에게 작업을 할당하기 전에 무엇을 어떻게 구현할 것인지를 명확히 정의한다. 이 과정에서 그는 Codex를 선호한다고 밝혔다. 에이전트와 반복적으로 대화하면서 견고한 계획을 수립한다. 계획에 도전하고, 수정하고, 반박한다. 에이전트가 제안하는 접근 방식에 의문을 제기하고 대안을 탐색한다. 이 과정에서 계획이 정교해지고, 예상치 못한 문제점이 사전에 드러난다. 계획에 만족하면 실행을 지시하고 다음 작업으로 넘어간다.

도구의 선택도 중요하다. Peter에 따르면 Codex는 장시간 작업을 독립적으로 수행하는 데 강점이 있다. 작업을 할당하면 스스로 진행하고 완료될 때까지 방해하지 않는다. 반면 Claude Code는 명확화를 위해 자주 돌아온다. 작업 중간에 질문을 하고 확인을 요청한다. 어떤 맥락에서는 이것이 장점일 수 있지만, 여러 에이전트를 동시에 운영하며 몰입 상태를 유지하려는 워크플로우에서는 오히려 산만함의 원인이 된다. 에이전트마다 특성이 다르고, 그 특성을 이해하고 적절한 작업에 배치하는 것도 개발자의 역할이다.

때로는 의도적으로 덜 구체적인 프롬프트를 사용하기도 한다. 너무 상세하게 지시하면 에이전트는 지시받은 대로만 구현한다. 그러나 방향만 제시하고 세부사항을 열어두면 에이전트가 예상치 못한 솔루션을 제안하는 경우가 있다. 인간 개발자라면 생각하지 못했을 접근 방식, 익숙하지 않은 라이브러리의 활용, 더 효율적인 알고리즘의 적용. 이런 발견은 구체적인 프롬프트에서는 나오지 않는다. 에이전트에게 창의적 공간을 주는 것도 효과적인 협업의 일부다.

Pull Request에서 Prompt Request로의 전환은 단순한 도구의 변화가 아니다. 개발자가 무엇에 시간을 쓰고 무엇에 책임을 지는지에 대한 근본적인 재정의다. 코드의 세부사항을 검토하는 것에서 프롬프트의 방향성을 설계하는 것으로, 구현을 직접 하는 것에서 구현을 지시하고 검증하는 것으로 역할이 이동한다. 이 전환에 적응하는 개발자는 동시에 여러 작업 흐름을 관리하며 전례 없는 생산성을 달성할 수 있다. 적응하지 못하는 개발자는 여전히 한 번에 하나의 Pull Request를 리뷰하며 병목이 되어갈 것이다.

6. 소프트웨어 엔지니어링은 죽지 않았다, 진화했다

AI가 코드를 작성하는 시대가 도래하면서 소프트웨어 엔지니어링의 종말을 예언하는 목소리가 커지고 있다. AI 에이전트가 점점 더 복잡한 코드를 생성할 수 있게 되면 인간 개발자의 역할은 축소되고, 결국 프로그래머라는 직업 자체가 사라질 것이라는 전망이다. 코딩 부트캠프의 등록률이 떨어지고, 컴퓨터 과학 전공에 대한 회의적인 시각이 퍼지며, 개발자 커뮤니티 곳곳에서 불안감이 감지된다. 그러나 Peter Steinberger의 경험은 정반대의 이야기를 들려준다. 그는 단호하게 말한다. AI로 인해 소프트웨어 엔지니어링이 죽은 것이 아니라 오히려 그 반대라고.

AI가 대체하는 것과 대체할 수 없는 것 사이에는 분명한 경계가 있다. AI 에이전트는 명확하게 정의된 작업을 수행하는 데 탁월하다. 함수를 구현하고, 버그를 수정하며, 테스트를 작성하고, 코드를 리팩토링한다. 입력과 출력이 명확하고, 성공과 실패의 기준이 분명한 작업이라면 AI 에이전트는 인간 개발자만큼 혹은 그 이상으로 잘 해낸다. 그러나 이런 작업들이 소프트웨어 엔지니어링의 전부도 아닐뿐더러 가장 중요한 부분도 아니다.

Peter는 자신을 소프트웨어 아키텍트로 규정한다. 그의 핵심 역할은 프로젝트의 고수준 구조를 머릿속에 유지하는 것이다. 개별 함수가 어떻게 구현되어 있는지는 기억하지 않아도 된다. 그것은 언제든 코드를 열어보면 확인할 수 있고, 필요하면 AI 에이전트에게 설명을 요청할 수도 있다. 그러나 시스템 전체가 어떤 구조로 이루어져 있는지, 각 모듈이 어떻게 상호작용하는지, 데이터가 어떤 경로로 흘러가는지에 대한 큰 그림은 반드시 누군가의 머릿속에 살아 있어야 한다. 이것을 AI에게 맡길 수는 없다.

아키텍처에 대한 깊은 관심은 Moltbot의 성공 요인 중 하나다. 이 프로젝트가 빠르게 성장하고 새로운 기능이 계속 추가될 수 있었던 것은 처음부터 확장성을 염두에 두고 설계되었기 때문이다. 새로운 기능을 추가하기 쉬운 구조, 모듈 간의 명확한 경계, 변경이 다른 부분에 미치는 영향을 최소화하는 설계. 이런 것들은 AI 에이전트가 스스로 결정하지 않는다. 에이전트는 주어진 작업을 수행할 뿐, 그 작업이 시스템 전체에 어떤 영향을 미칠지를 고려하며 아키텍처를 재설계하지는 않는다. 그것은 인간 아키텍트의 몫이다.

기술 부채에 대한 감각도 AI가 대체하기 어려운 영역이다. 기술 부채란 당장은 동작하지만 장기적으로 문제를 일으킬 수 있는 기술적 결정들이 누적된 것을 말한다. 빠른 출시를 위해 임시방편으로 작성한 코드, 제대로 설계하지 않고 덧붙인 기능, 문서화되지 않은 암묵적 의존성. 이런 것들은 개별적으로는 작아 보이지만 쌓이면 시스템 전체를 경직시키고 새로운 개발을 어렵게 만든다. AI 에이전트는 현재 주어진 작업을 완수하는 데 집중한다. 그 작업이 기술 부채를 늘리는지 줄이는지는 판단하지 않는다. 기술 부채의 존재를 인식하고, 언제 갚아야 할지를 결정하며, 새로운 부채가 쌓이지 않도록 감시하는 것은 인간 개발자의 책임이다.

확장성과 모듈성에 대한 고민도 마찬가지다. 현재 천 명의 사용자를 처리하는 시스템이 백만 명의 사용자도 처리할 수 있을까. 새로운 기능을 추가할 때 기존 코드를 얼마나 수정해야 할까. 한 팀이 작업한 내용이 다른 팀의 작업과 충돌하지 않으려면 시스템을 어떻게 분리해야 할까. 이런 질문들은 코드 수준에서는 답할 수 없다. 시스템 전체를 조망하고, 미래의 요구사항을 예측하며, 현재의 결정이 가져올 장기적 결과를 추론해야 한다. AI 에이전트는 이런 종류의 전략적 사고를 하지 않는다.

Peter는 자신을 프로젝트의 선량한 독재자라고 표현한다. 이 개념은 오픈소스 커뮤니티에서 유래한 것으로, 프로젝트의 최종 결정권을 가진 사람을 의미한다. 민주적 합의가 아니라 한 사람의 비전이 프로젝트의 방향을 결정한다. 이것이 독재적이라면, 그것이 프로젝트의 일관성과 품질을 위한 것이라면 선량한 독재다. Peter의 역할은 바로 이 선량한 독재자로서 프로젝트의 방향과 스타일의 일관성을 유지하는 것이다.

AI 에이전트들이 각자 다른 기능을 병렬로 작업할 때, 누군가는 그 결과물들이 하나의 일관된 시스템으로 통합되도록 조율해야 한다. 에이전트 A가 작성한 코드와 에이전트 B가 작성한 코드가 스타일적으로, 구조적으로, 개념적으로 조화를 이루어야 한다. 사용자 경험이 일관되어야 하고, 코드베이스가 이해하기 쉬운 구조를 유지해야 한다. 이 조율자의 역할은 AI가 수행할 수 없다. 각 에이전트는 자신에게 할당된 작업만 볼 뿐, 프로젝트 전체의 비전을 공유하지 않기 때문이다.

선량한 독재자의 역할은 단순히 코드를 승인하거나 거부하는 것이 아니다. 프로젝트가 어디로 가야 하는지를 정의하고, 그 방향에 맞지 않는 결정을 걸러내며, 팀 전체가 같은 목표를 향해 나아가도록 이끄는 것이다. AI 에이전트 시대에 이 역할은 더욱 중요해진다. 에이전트의 수가 늘어나고 작업 속도가 빨라질수록, 일관성을 유지하는 것이 더 어려워지기 때문이다. 누군가 큰 그림을 보고 있지 않으면 프로젝트는 빠르게 방향을 잃고 혼란에 빠질 수 있다.

소프트웨어 엔지니어링이 죽지 않았다는 것은 이런 의미다. 코드를 직접 작성하는 행위의 비중은 줄어들 수 있다. 그러나 시스템을 설계하고, 아키텍처를 결정하며, 기술 부채를 관리하고, 프로젝트의 방향을 이끄는 역할은 사라지지 않는다. 오히려 AI 에이전트가 더 많은 코드를 더 빠르게 생성할수록, 이런 고수준의 역할이 더욱 중요해진다. 소프트웨어 엔지니어링은 코드 작성에서 시스템 설계로, 구현에서 조율로, 개별 작업에서 전체 방향성으로 그 중심이 이동하고 있다. 죽은 것이 아니라 진화하고 있는 것이다.

7. 결과 중심 사고를 가진 엔지니어의 시대

Peter Steinberger의 사례는 하나의 질문으로 수렴한다. AI 에이전트 시대에 어떤 엔지니어가 번성할 것인가. 그 답은 이제 분명해졌다. 구현의 세부사항보다 결과물에 관심을 가진 엔지니어, 알고리즘 퍼즐을 푸는 것보다 제품을 출시하는 것을 즐기는 엔지니어, 코드의 우아함보다 시스템의 방향성에 집중하는 엔지니어. 이들이 AI 네이티브 개발 환경에서 전례 없는 생산성을 발휘하고 있다.

알고리즘 퍼즐을 사랑하는 엔지니어들이 AI 네이티브 전환에 어려움을 겪는 이유는 그들의 능력이 부족해서가 아니다. 오히려 그 반대다. 그들은 너무 유능하기 때문에 어려움을 겪는다. 복잡한 문제를 우아하게 해결하는 능력, 코드 한 줄 한 줄을 최적화하는 집중력, 자료구조와 알고리즘의 미묘한 차이를 구분하는 감각. 이 모든 것이 그들의 자부심이자 정체성이었다. 그런데 AI 에이전트가 이 영역에 들어오면서 그들의 고유한 가치가 흔들리고 있다. 자신이 평생 연마해온 기술이 기계에 의해 대체될 수 있다는 사실을 받아들이기란 쉽지 않다.

반면 제품 출시를 좋아하는 엔지니어들에게 AI 에이전트는 위협이 아니라 기회다. 그들에게 코드는 애초에 목적이 아니라 수단이었다. 중요한 것은 사용자에게 가치를 전달하는 것이고, 코드는 그 가치를 구현하는 도구일 뿐이다. 그 도구가 더 강력해졌다면 환영할 일이지 두려워할 일이 아니다. AI 에이전트를 활용하면 이전보다 더 빠르게, 더 많은 기능을, 더 적은 노력으로 출시할 수 있다. 결과물에 집중하는 사람에게 이보다 좋은 소식은 없다.

Peter의 워크플로우는 이 결과 중심 사고의 극단적인 형태를 보여준다. 한 달에 6,600회 이상의 커밋을 기록하면서도 그는 코드 리뷰에 시간을 쓰지 않는다. 코드가 자신의 취향에 맞지 않아도 개의치 않는다. 5개에서 10개의 에이전트를 동시에 운영하면서 세부 구현이 아닌 시스템 설계에 집중한다. 그가 신경 쓰는 것은 오직 결과물이다. 기능이 동작하는가, 사용자에게 가치를 전달하는가, 시스템이 원하는 방향으로 진화하고 있는가. 이 질문들에 예스라고 답할 수 있다면 나머지는 부차적인 문제다.

그러나 Peter 자신도 인정하듯이, 이 접근 방식이 모든 상황에 적용되는 것은 아니다. Moltbot은 실험적이고 빠른 반복을 전제로 한 프로젝트다. 아직 완성된 제품이 아니라 진행 중인 작업이다. 이런 프로젝트에서는 빠르게 움직이고 부수기라는 접근 방식이 유효하다. 완벽함을 추구하기보다 일단 만들어서 시장의 반응을 보고, 피드백을 바탕으로 빠르게 수정한다. 실패해도 빨리 실패하고, 배움을 바탕으로 다음 시도를 한다. 이런 환경에서 AI 에이전트는 반복의 속도를 극적으로 높여주는 증폭기가 된다.

모든 팀이나 제품에 이 방식을 동일하게 적용하기는 어렵다. 금융 시스템, 의료 소프트웨어, 항공 관제 시스템처럼 오류의 대가가 큰 영역에서는 빠른 반복보다 신중한 검증이 우선이다. 대규모 조직에서 수십 명 혹은 수백 명의 개발자가 협업하는 환경에서는 개인의 생산성보다 팀 전체의 조율이 중요하다. 레거시 코드베이스를 유지보수하는 상황에서는 새로운 기능 추가보다 기존 시스템의 안정성이 우선한다. Peter의 워크플로우가 보여주는 것은 가능성의 극단이지, 모든 상황에 적용해야 할 표준은 아니다.

그럼에도 불구하고 이 사례가 의미 있는 이유는 AI 네이티브 개발이 어디까지 갈 수 있는지를 보여주기 때문이다. 대형 AI 연구소들조차 예상하지 못한 수요가 존재한다는 것이 증명되었다. Moltbot이 Claude Code와 Codex를 합친 것보다 많은 검색량을 기록하고, GitHub 역대 가장 빠른 스타 성장률을 달성한 것은 개발자들이 AI 에이전트를 활용한 새로운 워크플로우에 목말라 있었다는 증거다. 수요가 있다는 것은 시장이 존재한다는 것이고, 시장이 존재한다는 것은 그 방향으로의 전환이 불가피하다는 것을 의미한다.

AI 네이티브 개발자로 진화하기 위해 필요한 것은 무엇인가.

첫째, 완벽주의를 내려놓아야 한다. 코드가 자신의 취향에 맞지 않아도 결과물이 목표를 달성한다면 받아들일 수 있어야 한다.

둘째, 루프를 닫아야 한다. AI 에이전트가 스스로 검증할 수 있는 환경을 구축해야 한다.

셋째, 코드에서 시선을 들어 시스템 전체를 조망해야 한다. 세부 구현은 에이전트에게 맡기고, 아키텍처와 방향성에 집중해야 한다.

넷째, 코드 리뷰 대신 프롬프트 설계에 능숙해져야 한다. 무엇을 어떻게 지시할 것인지가 결과물의 품질을 결정한다.

가장 근본적인 변화는 마인드셋의 전환이다. 알고리즘 퍼즐러에서 제품 출시자로, 구현자에서 설계자로, 코더에서 아키텍트로. 이 전환은 하룻밤에 이루어지지 않는다. 오랜 기간 체화된 습관과 가치관을 바꾸는 것이기 때문이다. 그러나 AI 에이전트 시대에 적응하고자 하는 개발자라면 이 전환을 시작해야 한다. 코드를 작성하는 즐거움에서 벗어나 결과물을 만들어내는 즐거움으로, 문제를 푸는 희열에서 제품을 출시하는 성취감으로 보상 체계를 재정의해야 한다.

Peter Steinberger의 한 달 6,600 커밋은 숫자 이상의 의미를 갖는다. 그것은 AI 에이전트와 인간 개발자가 협업할 때 무엇이 가능한지를 보여주는 증거다. 모든 개발자가 이 수준의 생산성을 달성해야 하는 것은 아니다. 그러나 모든 개발자가 이 사례로부터 배워야 할 것은 있다. 코드 자체에 집착하지 말 것, 결과물에 집중할 것, 시스템 전체를 조망할 것, 완벽주의를 내려놓을 것. AI가 코드를 작성하는 시대에 인간 개발자의 가치는 더 이상 코드에 있지 않다. 그 코드가 만들어내는 결과물, 그 결과물이 향하는 방향, 그 방향을 결정하는 비전. 거기에 인간의 자리가 있다.

결과 중심 사고를 가진 엔지니어의 시대가 열리고 있다. 알고리즘의 아름다움에 취해 있을 시간은 없다. 제품을 출시하고, 사용자에게 가치를 전달하며, 세상에 영향을 미치는 것. 그것이 AI 네이티브 시대의 개발자가 추구해야 할 목표다.