코딩 에이전트가 실무에 스며들면서, 언어 설계자들 사이에서 낯선 질문이 떠오르고 있다. 인간이 더 이상 대부분의 코드를 직접 작성하지 않는다면 프로그래밍 언어는 어떻게 변할까. Dashbit 블로그의 한 글은 이 물음을 두 축으로 나눠 다룬다. 하나는 언어와 그 생태계·커뮤니티에 대한 다소 사변적인 성찰이고, 다른 하나는 지금 당장 손댈 수 있는 도구에 대한 구체적인 제안이다. 결론을 단정하기보다는, 이미 현실이 된 변화 앞에서 우리가 무엇을 다시 생각해야 하는지를 정리한 글에 가깝다.
커뮤니티와 생태계라는 접착제
언어에는 대개 공통 감수성을 중심으로 뭉친 커뮤니티가 있다. 파이썬은 '하나의 분명한 방법'을, 루비는 프로그래머의 행복을, 리스프 계열은 언어 자체를 다시 빚는 능력을 소중히 여겨 왔다. 그런데 사람이 코드를 거의 쓰지 않게 되면 이런 소속감은 무엇으로 대체될까. 생태계 역시 미묘한 긴장에 놓인다. 알려진 알고리즘 구현, 논문 아이디어의 이식, 언어 간 포팅처럼 반복적인 작업을 에이전트가 빠르게 처리해 준다면, 규모가 작은 커뮤니티도 큰 커뮤니티를 훨씬 빨리 따라잡을 수 있다. 하지만 무언가를 만드는 비용이 충분히 싸지면, 사람들은 굳이 같은 라이브러리에 힘을 모아 협업할까. 필요한 기능이 있으면 그냥 에이전트에게 딱 맞는 것을 만들어 달라고 할 수도 있다. 생태계를 싸게 구축하게 해 주는 힘이, 동시에 생태계를 형성시키던 동력을 약화시키는 셈이다.
문법 편의성의 가치는 떨어진다
언어는 오랫동안 문법적 편의와 사용성을 다듬으며 진화해 왔다. 지난 10년간 여러 언어가 도입한 옵셔널 체이닝 연산자는 사람이 널 체크를 길게 늘어놓는 것보다 훨씬 쓰기 편하다. 그러나 에이전트는 보일러플레이트에 지치지 않고, 그 차이를 인간만큼 크게 느끼지 않는다. 토큰 효율이라는 명분도 있지만, 모델이 저렴해지고 컨텍스트 창이 커지는 흐름에서 토큰 효율은 언어가 최적화해야 할 특성의 맨 끝자락에 가깝다. HTML, CSS, 자바스크립트, Elixir, 러스트, Lean을 두루 다뤄 보면, 사람에게는 거대하게 느껴지는 문법 차이가 에이전트에게는 그저 토큰 입력과 출력의 문제일 뿐이다. 그래서 '에이전트를 위한 언어'를 표방하면서 결국 문법에 집중하는 시도는 오늘의 한계에 맞춰 설계하는 것이라는 지적은 새겨들을 만하다.
그렇다면 언어 자체가 사라지고 에이전트가 어셈블리를 직접 쓰게 될까. 글은 이를 회의적으로 본다. 데스크톱 애플리케이션 하나만 해도 지원하는 아키텍처마다 별도의 어셈블리를 유지할 수는 없으니, 결국 아키텍처 독립적인 중간 표현과 그것을 낮추는 계층, 즉 컴파일러와 상위 언어의 일부를 다시 발명하게 된다. 게다가 시스템 프로그래밍, 정리 증명기, 동시성·분산·내결함성 언어, 질의 언어, 하드웨어 기술 언어처럼 모든 것을 하나로 잘 해내는 계산 모델은 아직 없다. 언어는 사라지지 않는다는 얘기다.
최적화의 초점을 '보장'으로 옮기기
사람을 위한 최적화가 밀려난다면, 언어는 무엇을 위해 다듬어져야 할까. 글은 표현력·보장·사용성의 균형을 다시 잡자고 제안한다. 대표적인 예가 함수 시그니처 추론이다. 타입을 명시하는 수고가 인간에게는 번거롭지만 에이전트는 개의치 않으며, 오히려 타입과 의도를 명시하면 컴파일러와 다른 에이전트, 그리고 우리 자신이 활용할 정보가 늘어난다. 완전한 추론이 가능한 언어는 대체로 타입 검사가 가능한 언어의 부분집합이므로, 추론 편의를 좇다 보면 표현력과 보장의 폭이 함께 좁아진다. 보장을 정적으로만 세울 필요도 없다. 메모리 안전성은 가비지 컬렉션 같은 런타임으로도 지킬 수 있고, 모델 검사는 실행 트레이스로 모델과 구현을 잇는다. Erlang/Elixir가 격리된 프로세스와 메시지 전달로 동시성을 제약하며 고립성과 내결함성을 얻는 것처럼, 어떤 대가를 치르고 어떤 성질을 얻을지의 조합이 앞으로 언어를 차별화하는 축이 될 것이다.
LSP 이후의 도구: 질의 가능한 프로그램
두 번째 파트는 코드의 20%만 에이전트가 쓰더라도 유효한 실용적 제안이다. 언어 서버 프로토콜(LSP)은 IDE를 위해, 파일·행·열이라는 위치 중심으로 설계됐지만 에이전트는 그런 좌표를 정확히 추적하지 않는다. Tidewave를 만든 경험상, 에이전트에게는 정확한 소스 위치를 요구하기보다 "foo_bar 문서가 어디 있나", "BarBaz는 어디 정의됐나"를 물을 수 있는 인터페이스가 더 맞는다. 언어 서버는 이미 심벌, 참조, 호출 그래프, 타입 정보 같은 자료를 갖고 있으니, 이를 SQLite나 Datalog, 전용 DSL 같은 질의 언어를 갖춘 프로그램 데이터베이스로 노출하자는 것이다. 사람에게 참조 검색을 위해 질의를 짜게 하는 건 무리지만, 에이전트에게 질의 작성은 CLI 호출과 다를 바 없다. "이 함수를 결국 호출하는 모든 공개 함수"나 "어떤 값이 nil이 될 수 있는 모든 경로"처럼 개별 IDE 기능으로는 만들기 힘든 조합도 가능해지고, 이런 데이터베이스는 린터로도 쓸 수 있다.
다만 이 접근은 지역성(locality)을 더욱 중요하게 만든다. 몽키패칭, 암묵적 훅, 동적 재바인딩처럼 한 곳의 코드가 시스템 전체 동작을 원격에서 바꾸는 기능은 프로그램 데이터베이스가 있어도 추적을 어렵게 한다. 디버거와 운영 관측도 마찬가지다. 사람은 중단점을 걸고 한 줄씩 밟지만, 에이전트는 코드를 계측하고 트레이스를 모아 훨씬 빠르게 상관관계를 짚는다. 코드 대부분을 에이전트가 쓴다면 프로덕션 진단까지 맡기는 흐름도 자연스럽고, 그렇다면 런타임과 상태를 프로그램적으로 질의·탐색할 수 있게 열어 두어야 한다. 프로세스, 소켓, 슈퍼바이저, ETS 테이블, 메시지 큐를 런타임 차원에서 들여다보는 데 능한 Erlang VM은 여기서 유리하지만, 남은 과제는 이 능력을 도구든 질의 언어든 샌드박스든 안전하게 에이전트에게 여는 일이다. 문법 경쟁이 아니라 이런 관측성과 보장의 설계가 언어의 미래를 가른다는 관점은, 지금 도구를 고르는 실무자에게도 유효한 기준이 된다.