~fpereiro

URL: https://federicopereiro.com/llm-high/

Title: ~fpereiro

가설: LLM 에이전트는 새로운 고수준 프로그래밍 언어다

(원문은 여기에 처음 게시됨)

이 가설을 따르면, C가 어셈블러에 했던 것, Java가 C에 했던 것, Javascript/Python/Perl이 Java에 했던 것을, 이제 LLM 에이전트가 모든 프로그래밍 언어에 하고 있다.

여기서 LLM 에이전트란 무엇을 의미하는가? 곧 인간의 주요 개발 스택은 다음과 같아질 것이라는 뜻이다:

• 다중(Multiple): 여러 에이전트가 병렬로 작업한다.
• 자율(Autonomous): 그 에이전트들은 가끔 인간의 피드백만 필요로 하고, 대부분은 자율적으로 일한다.

이 가설이 참인지 어떻게 판단할 수 있을까? 인간 개발자가 여러 자율 에이전트를 사용함으로써, 사용하지 않을 때에 비해 한 자릿수(10배) 더 많은 것(10x)을 만들 수 있다면, 가설은 참이다. 아직은 확신하지 못한다(2026년 1월 기준). 하지만 진지하게 고려하고 있다.

소프트웨어 업계에 오래 있었던 많은 사람들에게는, 반론이 꼬리를 물고 떠오를 것이다. 쉬운 것부터 다뤄보자:

• 코드 라인을 10배 만든다고 10배 더 만드는 게 아니다. 그건 그냥 잡탕(sloppiness)일 뿐이다: 측정은 코드 라인이 아니라 실제로 전달되는 기능적 산출물에 대해 이루어져야 한다. 이 가설을 따른다면, “코드 라인”은 사실 LLM에게 주는 지시(instructions)다.
• LLM은 코딩을 모르는 사람을 위한 것이다: LLM 덕분에 많은 신규 프로그래머가 생기겠지만, 그렇다고 숙련된 프로그래머가 LLM 에이전트를 써서 이득을 못 본다는 뜻은 아니다. 많은 숙련 개발자들이 LLM으로 산출량이 크게 늘었다는 증거가 있다.
• LLM은 생각/일하기 싫은 사람을 위한 것이다: LLM을 써서 이전보다 더 많은 일을 한다면, 생각과 노동은 줄어드는 게 아니라 늘어난다. 에이전트 함대를 관리하는 일은 더 요구 수준이 높고, (같은 시간에 이전의 x배를 만들기 때문에) 설계도 훨씬 더 많이 해야 한다.
• LLM은 우리의 코딩 실력을 썩게 만들 것이다: 아마도. 하지만 직장에서는 대개 어셈블러 실력이나 C 실력이 썩는 것을 걱정하지 않는다(그런 실력이 애초에 있다 해도). 대부분은 여가 시간에 그런 실력을 연마한다. 왜냐하면 직장에서 어셈블러나 C로 일하면 더 생산적이라고 방어하기 어렵기 때문이다(대부분의 소프트웨어 개발 유형에서).
• LLM이 만드는 코드는 내가 쓰는 것보다 훨씬 나쁘다: 거의 확실히 그렇다. 하지만 이는 당신의 어셈블러 코드나 C 코드에도 똑같이 말할 수 있다. LLM이 생성하는 것이 충분히 효율적이기만 하면, 실행될 것이고 이미 준비된 상태일 것이다. 시스템은 더 못생겨지겠지만, 그래도 동작은 한다.
• LLM 에이전트를 쓰는 건 비싸다: 생산성이 이미 50%만 늘어도, 그리고 당신의 급여가 평균적인 수준이라면, 비싸지 않다. 게다가 LLM은 더 싸질 것이다. 절대 비용은 비싸 보일 수 있어도, 상대적으로는 비싸지 않다.
• 어느 오후 LLM 에이전트를 써봤는데 시간만 낭비했다: 학습 곡선이 있다. 여러 LLM 에이전트와 함께 일하는 감을 잡는 데 시간이 걸린다. 당신이 프로그래밍 스택의 도구와 문법과 싸우며 시간을(몇 시간, 며칠) 보냈다가 어느 정도 익숙해졌던 것을 떠올려보라.

(위의 것들 중 어느 것도 논리적으로는 방어하기 어렵다고 본다. 다만 감정적으로 받아들이기 쉽지 않을 뿐이다)

이제 본질을 찌르는 두 가지 반론으로 가보자:

• 품질(Quality): LLM이 생성하는 코드가 곧 쓰레기 더미(dumpster fire)가 되지 않을까? 모래 위에 기초를 쌓는 게 아닐까?
• 이해가능성(Understandability): LLM이 너무 많은 코드를 생성해서 우리가 도저히 이해할 수 없게 되지 않을까? 시스템이 동작한다 해도, 우리가 이해하지 못해서 영원히 통제하지 못하는 위험에 빠지는 게 아닐까?

나는 LLM 프로그래밍에서 받아들일 만한 어떤 프레임워크든 그 목표를 품질과 이해가능성으로 두고 싶다. 경제적으로 보면 목표로서 방어 불가능한 것은 오직 ‘품질’뿐이다. 이해가능성은 낭만적인 꿈일 수도, 장기적으로 좋은 베팅일 수도 있다(나는 후자라고 보지만, 당신은 물론 불가지론적이어도 된다).

이제 다소 구식(quaint)인 이야기: LLM은 이전의 고수준 언어들보다 훨씬 비결정적(nondeterministic)이다. 또한 이전 어떤 계층도 자기 자신을 다루는 방식으로는 할 수 없었던 수준에서, 고수준(설명)에서의 문제 파악을 도와줄 수 있다.

어떻게 보일까?

이 가까운 미래가 어떤 모습일지 공통 요소를 찾아보자:

• 문서(Documentation): 시스템의 명세를 담은 마크다운 페이지들의 집합: 목적, 주요 엔티티, 엔드포인트, 제약, 핵심 플로우, 코딩 표준.
• 구현(Implementation): 코드베이스와 모든 데이터. 이것이 실행되고 상태를 보유한다. 코드베이스는 문서로부터 재구성 가능해야 하며, 데이터는 문서에서의 설명과 일관되어야 한다.
• 대화(Dialogs): 여러 에이전트가 각자의 과제를 처리하느라 분주하다. 해법을 생각하는 동안 텍스트를 생성하고, 그 일부는 코드다: 이것이 대화다(마크다운 페이지로 표현 가능). 인간은 언제든 이 텍스트 스트림, 코드 변경, 명령을 검사할 수 있고, 대화에 참여할 수도 있다. 어떤 대화는 인간 입력을 기다리고 있을 수 있다. 에이전트가 작업을 완료하면 대화는 더 이상 ‘살아 있지’ 않지만, 접근은 여전히 가능하다.
• 작업(Tasks): 마크다운 페이지로 표현되는, 동적으로 변하는 이산적인 작업 조각들의 집합. 작업은 문서 + 코드베이스의 기존 상태로부터 재구성 가능해야 한다. 작업은 중첩될 수 있다. 작업에는 상태(완료됨, 보류, 진행 중, 인간 상호작용 대기, 완결)가 있다.

이를 보면 ‘저장량(stock)’ 두 개와 ‘흐름(flow)’ 두 개가 있다. 두 저장량은 “-tion”들(문서와 구현)인데, 이것이 시스템의 축적물이다. 그리고 두 흐름, 즉 대화와 작업도 있다. 대화와 작업이 문서와 구현을 모두 만들어낸다. 인간이 문서와 구현을 직접 수정하는 것도 가능하지만, 그리 자주 일어나지는 않을 것이다. 대부분의 흐름이 에이전트 중심(agentic)일 것이고, 인간은 대부분의 시간을 에이전트와 상호작용하는 데 쓰게 될 것이다.

에이전트는 어떻게 구조화될까? 에이전트는 여러 역할을 수행할 수 있다(기반 모델이 범용이기 때문에). 여기서는 가능한 한 자유도를 많이 남길 수 있다고 본다. 어떤 에이전트든 어떤 대화에든 들어갈 수 있고, 인간도 어떤 대화에든 들어갈 수 있다면, 인간이 다양한 가능성을 실험하게 둘 수 있다:

• 에이전트들이 작업을 독립적으로, 시작부터 끝까지 처리.
• 다음에 무엇을 할지 조율하는 오케스트레이션 담당 관리 에이전트.
• 새 기능을 깨뜨려보는 QA 에이전트.
• 빌더의 맥락 없이 병합되지 않은 새 기능을 가져와 리뷰하는 리뷰 에이전트.
• 충돌을 해결하는 머지(merging) 에이전트.

중요한 점은 인간이 수동 또는 자동으로 에이전트를 띄울 수 있어야 하며, 지시는 일회성일 수도 있고 문서의 한 덩어리(chunk)일 수도 있다는 것이다.

새로운 형태의 월드 와이드 웹에 대한 기회가 있다—정확히는 기존 웹을 훨씬 더 자유롭고 웹답게 만들어, 애플리케이션의 사일로를 깨는 기회다. 그 기회가 MCP다. MCP(LLM의 도구 호출(tool calling)을 위한 표준)는 모두가, 그리고 그들의 어머니까지도 지원하려고 달려들고 있는데, 이를 일반화된 XMLHTTPRequest로 볼 수 있다. 이는 AI 에이전트가 기존 애플리케이션에 갇혀 있던 기능과 데이터를 가져와, 당신이 선택한 동적 캔버스에 올려놓을 수 있는 가능성을 연다.

cell에 대한 나의 원래 비전은, 완전히 이해 가능하고 이미 배포된 코드와 데이터의 그리드(데이터스페이스)였다. 하지만 이것만으로는 충분하지 않다. 이것은 단지 “그리드”일 뿐이다. 그리드를 둘러싸는 것은 동적 페이지들의 집합일 텐데, 거기서는 문서와 기능이 하나로 합쳐진다.

문서는 단지 문서가 아니라: 기능을 임베드할 수 있을 것이다. 그것은 당신 자신의 애플리케이션에서 올 수도 있고(그리드에서 지원됨), 외부 애플리케이션에서 올 수도 있다. 전체 화면으로 띄울 수 있는 미니 대시보드나 위젯을 둘 수 있다. 혹은 다른 페이지로 이동할 수도 있다. 당신의 cell은 페이지들의 모음 + 그리드 + 그 위에서 작업하는 에이전트들로 구성될 것이다. 그리고 그중 많은 부분은 외부에서 접근 가능할 수 있다.

이 모든 것은 여전히 서버를 필요로 한다. 이유는 다음과 같다:

• 당신이 온라인이 아닐 때도 요청을 수신해야 한다.
• 데이터를 영속화해야 한다.
• 에이전트가 계속 작업하도록 유지해야 한다.
• 많은 호출은 보안상의 이유로 브라우저에서 직접 할 수 없으므로, 서버가 대신 요청을 해야 한다.

품질과 이해가능성은 어떻게 되는가? 큰 스택 대신 좋은 서브스트레이트(substrate)를 사용한다면, LLM 출력의 라인 수는 훨씬 줄어들고 더 이해하기 쉬워질 것이다. 그렇다면 우리가 만드는 시스템의 품질과 성능을 크게 끌어올릴 수 있다.

이제 시스템의 프런트엔드는 문서와 에이전트이며, 백엔드는 스택/서브스트레이트다.

열린 질문(Open questions):

• 구현과 함께 문서와 대화를 어떻게 저장할까?
• 버전 관리 시스템은 어떻게 사용할까?