링크드인은 이제 트위터가 아니다. 훨씬 과감하다.

이제 링크드인은 예전의 트위터를 대신해, 과감한 주장들이 넘치는 공간이 되었다. 최근 누군가는 에이전트형 개발(agentic development)에 대한 자신감이 너무 크다며 iOS나 안드로이드 수준의 운영체제를 생성형 AI로 직접 만들겠다고 선언했다. 필자는 늘 그렇듯 회의적인 입장에서, 해당 운영체제를 직접 배포하거나 설치할 일은 절대 없을 것이라고 지적했다.

또 다른 인물은 대형 언어 모델(LLM)이 사람보다 더 많고 더 높은 품질의 풀 리퀘스트(PR)를 생성하고 있다고 주장했다. 근거는 특정 도구에서의 PR 수와 승인율이었다. 필자는 그것이 사실일 수 없다고 응수했다. 직접 분류 모델을 만들 동기는 없었지만, 약 20개 정도를 표본으로 살펴봤다. 해당 대시보드는 실은 사람들이 개인 프로젝트에서 생성형 AI의 PR을 YOLO식으로 무조건 승인한 경우를 주로 집계하고 있었다. 많은 커밋이 사실상 불필요한 문서화였으며, 누군가는 병합 수락 시 “쓸모없는 쓰레기가 많지만 일단 관련 있어 보인다. 기본선으로 병합하고 나중에 정제하자”라고 말했다.

그렇다고 LLM을 쓰지 말라는 이야기는 아니다. 오히려 반드시 써야 한다.

통계나 보고된 수치가 맞다면, 대부분의 사람들은 어느 정도는 이미 사용 중이다. 그러나 동시에, LLM이 현재 무엇을 할 수 있고 무엇을 할 수 없는지 과장하지 말아야 한다고 본다.

앞서도 언급했듯, 현재의 모든 LLM 기반 도구는 어느 정도 제한적이고 솔직히 말해 성가시다. 그래서 직접 만들기로 했다. 솔직히 말해, 단순히 ‘바이브 코딩’으로 패치 시스템을 만들 수 있을 거라 기대했다. LLM이 자기 패치를 받아들이는 시스템을 만드는 법쯤은 알 거라 생각한 것이다.

완전히 착각이었다.

우선, 디프(diff)와 패치(patch)는 겉보기보다 훨씬 복잡한 컴퓨팅 분야다. 그 사실을 잠시 잊고 있었다. 게다가, 정제되지 않은 패치를 생성하는 존재로부터 패치를 받아들이는 시스템을 만드는 일은, 정확한 알고리즘으로 패치를 만드는 존재를 위한 시스템을 설계하는 것보다 훨씬 어렵다. 더 나아가, 각기 다른 방식으로 패치를 생성하는 여러 모델을 지원하는 시스템을 만드는 일은 매우 까다로웠다. 결국 포기하고, 이미 잘 만든 시스템을 찾아 베껴 쓰기로 했다.

시험과 오류

이번 실험에서 찾은 가장 뛰어난 패치 시스템은 에이더 AI의 시스템이었다. 에이더는 모든 LLM에 대해 원샷(one-shot) 패치 생성 성능을 벤치마크로 측정하고 있다. 이 시스템은 최신 기술을 사용하지도 않고, 도구 호출도 지원하지 않는다. 거의 전적으로 수작업으로 만든 파이썬 코드다. 당연히 떠오른 생각은, 이걸 타입스크립트로 포팅해서 직접 만든 VS Code 플러그인에 쓰자는 것이었다.

어차피 에이더의 구현은 대부분 문자열 유틸리티로 구성되어 있었다. 판다스도 없고, MATLAB도 없다. 그냥 문자열 치환이다.

또 하나의 비교 실험도 하고 싶었다. 오픈AI의 o3를 커서 환경에서 실행하고, 앤트로픽의 클로드 오퍼스 4를 클로드 코드에서 실행하여, 두 모델에게 서로의 계획을 평가하게 했다. 요약하자면, o3는 오퍼스의 계획이 너무 복잡해서 실패할 운명이라고 평가했다. 반면 클로드 오퍼스는 o3의 접근법이 너무 단순하고 모든 복잡성을 마지막에 몰아서 결국 실패할 것이라고 혹평했다.

그리고 둘 다 처참히 실패했다.

이 과정에서 클로드 오퍼스가 기초적인 문제조차 식별하지 못하는 것에 신뢰를 잃었고, ‘asko3’라는 명령줄 도구를 만들어 클로드가 실수하기 전에 o3에게 미리 물어보도록 했다. 반면 커서 쪽은 백엔드가 너무 불안정해서 요청에 제대로 응답조차 못 했고, 그래서 o3는 기본적으로 실격 처리했다. 다음 조합은 독립 실행형 클로드 오퍼스 4가 독립 실행형 o3의 조언을 받아 수행하는 방식이었다.

이 계획도 처참히 실패했다.

o3는 오퍼스가 만든 설계를 에이더 알고리즘의 ‘카고 컬트(cargo cult)’적 구현이라고 표현했다. 필자가 사용하는 설계 방식 자체가 문제라고도 했다. 그래서 단일 문서 기반 설계 방식을 만들었다. 이후 o3에게 구현을 맡겼다(클로드 코드 내에서). 결과는 엉망진창이었다.

클로드에게 이 설계를 o3에게 리뷰하게 시켰다. 단, 그것이 본인의 설계임은 밝히지 않았다. o3는 냉정하게 혹평했고, 클로드는 이를 “잔인하지만 정확한 평가”라고 인정했다.

결국 성공한 방식

그래도 타입스크립트용 패치 시스템이 필요했고, 직접 손코딩하고 싶지는 않았다. 그래서 클로드에게 에이더 구현에서 주석만 옮기게 하고, 메인 메서드를 테스트 코드 형태로 작성하게 했다. 이후 하나씩 포팅하게 시켰다. 실패하면 각 메서드별로 다시 정렬하도록 했다. 모든 결정 과정을 검토했고, 전체 과정을 함께 리뷰했다. 결과적으로 성공했다.

하지만 이 과정은 ‘바이브 코딩’과는 가장 거리가 먼 작업이었다. 직접 치는 것보다도 빠르다고 말하긴 어려웠다. 그리고 이것은 단지 문자열 패치 알고리즘일 뿐이었다.

운영체제를 만들겠다는 사람은 수많은 장애물을 마주하게 될 것이다.

LLM은 CRUD 웹앱 코드를 대량으로 학습했다. 만약 CRUD 웹앱을 만든다면, LLM을 마음껏 쓰면 된다. 그러나 알고리즘 설계 수준으로 깊이 들어가면, 직접 이론을 이해하고 끊임없이 조정해야 하며, 그 작업은 결코 단순하지 않다.

시행착오의 기록

이러한 분석은 개인적인 견해에 그치지 않는다. 여러 연구 결과에서도 동일한 결론이 도출되고 있다.

대형 언어 모델은 널리 알려진 템플릿을 조합할 수 없는 중간 및 고난도 문제에서는 실패한다. 또한 문제의 길이가 길어질수록 성능이 급격히 저하되는 ‘반감기’ 현상도 나타난다. 이번 사례에서 o3는 필자가 설계한 계획 수립 시스템이 문제의 원인이라고 오해했지만, 실제로 이 시스템은 문제를 더 작은 단위로 쪼개고, 모델이 전체 맥락을 이해하지 않고도 특정 설계에 정렬되도록 유도함으로써 대부분의 경우 성공을 이끌어낸다. 요약하면, 성공 가능한 소규모 작업 단위로 나눠주는 방식이다.

그럼에도 실패가 발생한 이유 중 하나는, 수많은 도구가 존재함에도 불구하고, 공개된 패치 시스템이 전 세계에 50개 정도밖에 존재하지 않기 때문이다. 학습 가능한 예제가 부족하니, LLM은 ‘유니파이드 디프(unified diff)’ 방식이 적절하다고 잘못 추론한 것이다 (실제로는 그렇지 않다). 반면 웹 애플리케이션 분야는 예제가 풍부하고, LLM은 해당 영역에 대해 매우 높은 이해도를 보인다.

과대광고는 무시해야 한다. 대형 언어 모델은 분명 도움이 되며, 완전한 자율형 에이전트가 실제 서비스 수준의 코드를 작성하는 단계에는 아직 도달하지 못했을 뿐이다. LLM은 반복적이고, 이미 널리 이해된 소프트웨어 개발 영역에서 가장 뛰어난 성능을 보인다. 반면 새로운 개념이나 고유한 알고리즘 설계에는 실패한다. 깃허브에 예제가 거의 없는 영역에서는 성공 가능성이 매우 낮다.

그러나 그렇다고 해서 LLM이 완전히 쓸모없다는 결론을 내려서는 안 된다. CSS와 HTML, CRUD 코드까지 ‘장인정신으로’ 일일이 손코딩해야 한다는 생각도 불필요하다. 어려운 문제를 다룬다고 해서 LLM이 도움이 안 되는 것도 아니다. 전체를 구현하지는 못하더라도, 분명히 유용한 지원 역할을 한다.

예를 들어, 파이썬 라이브러리에 대응하는 타입스크립트 문자열 라이브러리를 일일이 검색하지 않아도 되었다. 대형 언어 모델이 이를 대신 처리해줬기 때문이다. 애초에 그러한 계획부터 시작했더라면 훨씬 빠르게 작업을 마칠 수 있었을 것이다.

CRUD 앱을 작성하거나 반복적인 작업을 하거나, 학습 자료가 풍부한 문제 영역을 다룬다면 대형 언어 모델을 충분히 신뢰할 수 있다. 하지만 운영체제를 작성하고자 한다면, 해당 분야에 대한 전문 지식은 반드시 필요하며, LLM은 타이핑 보조 수준의 역할만 수행할 수 있다. 과거 C로 만들었던 스케줄러를 이번에는 러스트(Rust)로 작성하려는 경우처럼, 핵심 개념을 알고 있는 상황에서만 의미 있는 결과를 기대할 수 있다. Node.js 기반 풀스택 개발자라고 해서, 단지 애플이 마음에 들지 않는다는 이유로 생성형 AI만으로 iOS 대체 운영체제를 성공적으로 만들어낼 수는 없다.
dl-itworldkorea@foundryco.com