LLM과 AI 에이전트가 소프트웨어 엔지니어링에서 중요한 이유는 초인적 속도로 코드를 작성할 수 있기 때문이 아니다. 앞서 강조했듯 적절한 가드레일이 없으면 그런 속도는 결국 기술 부채를 대량 생산하는 결과로 이어질 뿐이다. 에이전트 기반 코딩이 중요한 이유는 좋은 소프트웨어 엔지니어링의 기준 자체를 근본적으로 바꾸기 때문이다.

오랫동안 개발자는 개인 취향에 맞춰 코드를 작성해도 큰 문제가 없었다. 어떤 프레임워크가 자기 사고방식에 잘 맞고 어떤 워크플로우가 우아하게 느껴지고, 어떤 코드베이스가 소프트웨어를 어떻게 만들어야 하는지에 대한 자기 나름의 이론을 반영한다면, 그것 만으로 충분한 경우가 많았다. 기계는 결국 사람이 지시한 대로 움직였기 때문이다. 에이전트는 이런 공식을 바꾸고 있다. 에이전트는 가장 영리한 워크플로우에 보상을 주지 않는다. 가장 읽기 쉽고, 점점 더 에이전트에 맞게 최적화된 워크플로우에 보상을 준다. 불안하게 들릴 수 있지만 실제로는 건강한 변화이다.

하멜 후세인에게 물어보면 알 수 있다.

머신과 대화하기

무엇을 써서 개발해야 하는지에 대해 강한 의견을 가진 박식한 해커뉴스 개발자를 찾는 일은 어렵지 않다. 하지만 후세인은 다르다. 후세인이 nbdev 사용을 접었다는 글을 썼을 때, 사이드 프로젝트 하나를 버린 것이 아니었다. 직접 만드는 데 참여했고 수년간 지지한 프로젝트를 내려놓았다. 이유는 AI 친화적이지 않았기 때문이다. 후세인은 nbdev의 독특한 접근 방식 때문에 “거슬러 헤엄치고 있었다”라고 적었고, 그 방식이 “AI와 협력하는 대신 AI와 싸우는 것 같았다”라고 설명했다. 대신 AI가 “가장 높은 성공 확률”을 가질 수 있는 환경에서 일하고 싶다고 말했다. 이제 후세인은 기계가 선호하는 방식에 맞춰 개발하고 있으며, 반드시 자기 취향을 따르지는 않는다. 후세인만이 아니다.

개발자는 늘 도구를 자기표현의 한 형태로 여기길 좋아했다. 때로는 실제로 그렇다. 하지만 에이전트는 도구를 인프라에 더 가까운 것으로 바꾸고 있다. 후세인은 커서(Cursor)가 익숙하게 느껴졌기 때문에 승리했다고 말한다. 커서는 개발자에게 첫날부터 새로운 세계관을 요구하는 대신 습관을 점진적으로 바꾸게 해줬기 때문이다. 이런 설명은 필자가 앞서 “개발 툴 시장의 승부처는 ‘혁신’이 아니라 ‘지루함’이다’에서 제시한 주장과 매우 비슷하다. 익숙함은 예전에는 주로 인간이 마찰이 적은 도구를 좋아하기 때문에 중요했다. 이제는 모델도 그런 도구를 선호하기 때문에 중요하다. 학습 데이터 분포와 비슷한 저장소 구조, 프레임워크, 언어는 모델이 유용한 작업을 해낼 가능성을 더 높여준다. 에이전트 시대에 순응은 항복이 아니다. 지렛대다.

깃허브의 최신 옥토버스 분석은 데이터를 통해 같은 점을 보여준다. 2025년 8월 타입스크립트는 깃허브에서 가장 많이 사용되는 언어로 파이썬과 자바스크립트를 모두 제쳤다. 깃허브는 AI 호환성이 기술 선택 이후에 붙는 보너스가 아니라 기술 선택 자체의 일부가 되고 있다고 설명한다. 또 타입스크립트가 전년 대비 66% 성장했다고 밝히며 그 이유도 설명했다. 강한 타입 시스템을 가진 언어는 모델에 더 분명한 제약 조건을 제공하고, 그런 제약 조건은 모델이 더 신뢰할 수 있고 맥락에 맞는 코드를 생성하는 데 도움이 된다. 후세인은 파이썬 전용 경로를 버리고 타입스크립트를 쓰기로 한 결정에 대해 “타입이 있는 언어는 AI가 생성한 코드를 프로덕션 환경에서 더 신뢰할 수 있게 만든다”라고 말했다.

그렇다고 모든 팀이 타입스크립트로 재작성하는 경쟁에 곧바로 뛰어들어야 한다는 뜻은 아니다. 하지만 별나고 문서화가 부족하며 “믿어봐, 우아하다”라고 주장하는 엔지니어링 방식의 설득력이 약해진 것은 분명하다. 에이전트는 명시성을 좋아하고 스키마를 좋아하며, 가드레일을 좋아한다.

한마디로 정리하면, 에이전트는 평범한 방식을 좋아한다.

엔지니어링 경제학 101

이 지점이 소프트웨어 엔지니어링의 더 깊은 변화이다. 에이전트 서사의 핵심은 사실 코드 생성이 아니다. 엔지니어링 경제학이다. 코드를 만드는 비용이 낮아지면, 병목은 다른 곳으로 이동한다. 필자는 이전에도 타이핑은 소프트웨어 엔지니어링의 진짜 제약이 아니라고 설명했다. 진짜 제약은 검증과 통합이다. 에이전트는 그 문제를 없애주지 않는다. 오히려 결과물 생산은 싸게 만들고 검증은 비싸게 만들어 소프트웨어 개발 수명주기 전체의 순서를 다시 짠다.

이런 변화를 보여주는 강력한 증거는 전혀 다른 두 곳에서 나왔다. 정확히 말하면, 서로 모순돼 보이는 두 사례에서 나왔다.

첫 번째는 숙련된 오픈소스 개발자를 대상으로 한 METR 연구이다. 무작위 실험에서 2025년 초 AI 도구를 사용한 개발자는 이미 익숙한 저장소의 이슈를 해결하는 데 19% 더 오랜 시간이 걸렸다. 그런데도 개발 자체는 더 빨라졌다고 생각했다. 반면 오픈AI의 최근 “하네스 엔지니어링” 에세이에서는 소규모 팀이 코덱스를 활용해 5개월 동안 약 100만 줄의 코드를 만들고 약 1,500건의 풀 리퀘스트를 병합했다고 설명한다. 두 결과는 겉으로 보면 상충하는 것처럼 보인다. 하지만 METR 조사는 AI를 순진하게 사용한 경우를 측정했고, 오픈AI 사례는 기존 워크플로우에 에이전트라는 “*요술 가루”*를 뿌리는 대신 팀이 소프트웨어 개발을 에이전트 중심으로 다시 설계했을 때 어떤 일이 벌어지는지를 보여준다.

오픈AI의 실험에서 엔지니어는 더 이상 코드를 작성하라는 요구를 받지 않았다. 대신 엔지니어의 주된 업무는 에이전트가 신뢰할 수 있는 작업을 하도록 만드는 “환경을 설계하고, 의도를 명세하고, 피드백 루프를 구축하는 것”이었다. 파일럿이 진행되는 동안, 오픈AI는 처음에는 에이전트가 작동할 환경을 충분히 구체적으로 정의하지 못했다는 점을 확인했다. 하지만 결국에는 생성된 코드를 신뢰할 수 있는 시스템을 만드는 데 초점을 옮겼다.

물론 이런 변화는 AI 주도 코딩이 이전만큼 많은 인간 개입을 여전히 필요로 한다는 뜻이기도 하다. 다만 개입의 종류가 달라졌을 뿐이다.

필자가 지금 이 글을 쓰는 순간에도 이런 변화는 채용 시장에서 나타나고 있다. 켄턴 바르다는 최근 “소프트웨어 개발자 일자리가 사라질 것이라는 걱정은 거꾸로 됐다”라고 말했다. 큰 방향에서는 맞는 말이다. 에이전트가 소프트웨어 구축 비용을 낮추면, 그 결과는 소프트웨어 감소가 아니라 증가일 가능성이 크다. 바르다가 시사했듯 이전에는 수고에 비해 가치가 없었던 틈새 애플리케이션, 내부 도구, 맞춤형 시스템이 더 많이 등장할 것이다. 실제로 AI가 개발자 일자리를 빼앗으러 온다는 주장과 달리 소프트웨어 개발자 채용 시장은 전체 채용 시장보다 훨씬 빠르게 성장하고 있다.

그렇지 않다. 에이전트가 실행 업무를 더 많이 맡더라도 방향을 잡을 사람은 여전히 필요하다.

에이전트 점검하기

이 대목에서 후세인이 평가에 집중하는 이유가 매우 중요하다. 후세인은 자신의 LLM 평가 FAQ에서 함께 일한 팀이 개발 시간의 60%에서 80%를 오류 분석과 평가에 쓴다고 말했다. 또 에이전트 시대 소프트웨어 개발이 어떻게 작동하는지를 명확하게 요약했는데, 문서화는 에이전트가 무엇을 해야 하는지를 알려주고, 텔레메트리는 작업이 제대로 수행됐는지 알려주며, 평가는 결과물이 좋은지 알려준다. 앤트로픽도 클로드 코드 베스트 프랙티스에서 거의 같은 말을 한다. 앤트로픽은 모델이 테스트, 스크린샷, 예상 출력값을 통해 자기 작업을 스스로 검증할 수 있는 방법을 제공하는 일이 사용자가 할 수 있는 “가장 효과적인 일”이라고 설명했다.

이런 변화에 따라 저장소의 의미도 변한다. 기존 저장소는 사람이 소스 코드를 보관하고 다른 사람을 위해 약간의 흔적을 남기는 공간이었다. 하지만 이제 저장소는 에이전트를 위한 운영 매뉴얼이 된다. 오픈AI는 코덱스가 처음에는 AGENTS.md 파일로 시작했지만, 거대한 단일 에이전트 매뉴얼은 금세 낡고 쓸모없어지는 문제를 겪었다고 밝혔다. 더 잘 작동한 방식은 AGENTS.md를 구조화된 저장소 내 지식 베이스로 연결하는 짧은 안내 지도로 다루는 것이었다. 이 통찰은 매우 에이전트 친화적이다. 빌드 명령, 테스트 지침, 아키텍처 노트, 설계 문서, 제약 조건, 비목표는 더 이상 부수 문서가 아니다. 이런 요소는 개발 자체를 위한 실행 가능한 맥락의 일부가 되고 있다.

더 직설적으로 말하면 맥락이 이제 인프라가 됐다.

이제 수많은 팀은 자신들의 소프트웨어 개발 프랙티스가 생각보다 훨씬 나빴다는 사실을 곧 깨닫게 될 것이다. 문서화되지 않은 스크립트, 마법처럼 굴러가는 로컬 설정, 불안정한 테스트, 구전 지식에 의존하는 아키텍처, 모호한 티켓, 일관성 없는 이름 붙이기, 그리고 “선임 엔지니어마다 조금씩 다르게 한다”라는 관행이 그렇다. 인간은 그냥 이런 문제를 흡수하며 버텨왔다. 에이전트는 이런 허점을 바로 드러낸다. 불충분하게 정의된 환경은 창의성을 낳지 않는다. 쓰레기를 만든다. 어수선한 코드베이스에 에이전트를 투입했는데 에이전트가 허우적거린다면, 그 장면이 반드시 에이전트에 대한 기소장은 아니다. 많은 경우 그 장면은 팀의 엔지니어링 규율을 매우 효율적으로 감사한 결과이다. 저장소가 마침내 자기 실상을 솔직하게 말해주는 셈이다.

그래서 필자는 AI 코딩이 개발자에게 더 나은 관리자 역할을 요구한다는 기존 제안이 맞지만, 충분하지는 않다고 생각한다. 개발자는 물론 머신을 더 잘 관리하는 사람이 되어야 한다. 하지만 더 중요한 점은 개발자가 전통적 의미에서 더 나은 엔지니어가 되어야 한다는 사실이다. 다시 말해 명세, 경계, 표준 경로, 기타 기본 원칙을 더 잘 다뤄야 한다는 뜻이다. 에이전트 시대는 영리함보다 규율에 훨씬 더 큰 보상을 준다.

그래서 코딩 에이전트의 가장 큰 이야기는 코드를 작성할 수 있다는 점이 아니다. 평범한 챗봇도 이미 그 부분은 그럴듯하게 흉내 낼 수 있다. 가장 큰 이야기는 코딩 에이전트가 유능한 소프트웨어 엔지니어링의 모습을 바꾸고 있다는 점이다. 에이전트는 개발자가 오랫동안 가치 있다고 주장했지만, 실제로는 회피하던 요소에 정확히 보상을 준다. 명시성, 일관성, 테스트 가능성, 그리고 증명이다.

에이전트 시대에는 따분한 소프트웨어 엔지니어링이 더 잘 확장할 뿐 아니라 협업, 디버깅 같은 거의 모든 면에서 더 뛰어나다.