런던 시스템, 어디에 쓰는 제품인지 다시 정했습니다

런던 시스템을 만들면서 기능은 꽤 많이 붙였습니다. 자연어로 요구사항을 적으면 그래프가 만들어지고, 실제로 돌려 보고, eval과 비용을 확인하고, 코드로 내보낼 수 있습니다. 처음 만들 때 그렸던 큰 흐름은 이제 거의 한 바퀴 돌아갑니다.

그런데 요즘 제품을 설명할 때마다 한 문장에서 자꾸 막혔어요. 그래서 이걸 누가, 어떤 순간에 꼭 쓰는 건데? 할 수 있는 일을 길게 설명하는 건 쉬운데, 꺼내 쓰는 순간을 짧게 말하기가 어려웠습니다. 이건 기능 문제가 아니라 목적 문제였습니다.

그래서 이걸 언제 쓰는데?

목적을 다시 정하게 만든 질문

처음에는 끝까지 다 하려고 했습니다

지난 6월에는 런던 시스템을 자연어 요구사항을 운영 가능한 에이전트로 컴파일하는 AI Agent CAD라고 소개했습니다. 요구사항을 그래프로 바꾸고, 시뮬레이션과 eval을 거쳐 API나 코드로 내보내는 제품이었어요. 틀린 설명은 아니었습니다. 실제로 그 흐름은 지금도 돌아갑니다.

다만 너무 멀리까지 한 번에 말했습니다. 자연어 빌더, 그래프 스튜디오, 실행, 비용, 정책, 배포를 전부 같은 무게로 들고 가다 보니 제품은 계속 커지는데 왜 꼭 필요한지는 오히려 흐려지더라고요. 다 할 수 있다는 말은, 아직 어디에서 제일 잘 쓰이는지 못 정했다는 말이기도 했습니다.

사내 플랫폼이 있어도 첫 그래프는 저절로 안 나옵니다

이번에 새로 잡은 장면은 LangGraph 코드를 실행하는 사내 에이전트 플랫폼이 있는 기업입니다. 플랫폼이 있으면 배포할 길은 생깁니다. 그렇다고 개발자가 만들 에이전트 그래프까지 저절로 생기는 건 아니더라고요.

개발자 입장에서는 낯선 것이 두 개입니다. LangGraph의 분기·상태·루프를 익히면서, 동시에 회사가 만든 SDK와 보안 규칙, 배포 방식까지 배워야 합니다. 처음부터 둘을 한꺼번에 붙이면 막혔을 때 더 답답합니다. 그래프가 잘못된 건지, 프롬프트 문제인지, 사내 플랫폼 연동이 문제인지 한 덩어리로 섞이기 때문입니다.

제가 London System에 맡기고 싶은 일은 바로 그 앞부분입니다. 사내 플랫폼에 들어가기 전에 그래프를 먼저 만들고, 직접 돌려 보고, 실패할 지점을 확인하는 것.

그래서 가운데 한 구간만 맡기로 했습니다

흐름은 단순합니다. 사내 플랫폼에 올릴 에이전트의 요구사항을 적고, 그래프 전체나 필요한 일부를 만든 뒤, 실행·eval·비용·정책을 확인합니다. 괜찮으면 LangGraph 코드로 내려받습니다. 그다음부터는 개발자가 자기 IDE에서 업무 로직과 도구, 보안 규칙을 붙여 사내 플랫폼으로 가져갑니다.

• 요구사항 입력 — 만들려는 에이전트와 그래프 범위를 자연어로 적습니다.
• 그래프 설계 — 전체 또는 일부를 만들고 구조를 눈으로 확인합니다.
• 사전 검증 — 실행·eval·비용·정책 검사로 문제를 먼저 찾습니다.
• LangGraph export — 읽고 고칠 수 있는 코드로 내려받습니다.
• 사내 플랫폼으로 이식 — 조직의 로직과 규칙을 붙인 뒤 내부 환경에 배포합니다.

그래서 핵심 결과물도 달라졌습니다. "에이전트 하나 만들었습니다"에서 끝나면 안 됩니다. 수정 가능한 LangGraph 코드와 eval·회귀 케이스, 런당 비용과 정책 검사 결과가 같이 나와야 합니다. 개발자가 안심하고 가져가서 자기 환경에 맞게 완성할 수 있어야 하니까요.

자연어 입력은 편한 입구이고, 그래프 화면은 구조를 보는 작업대입니다. eval과 비용은 가져가도 되는지 판단할 증거고, export가 이제 이 흐름의 목적지입니다.

안 하는 일을 정하니 오히려 선명해졌습니다

London System은 각 기업의 사내 에이전트 플랫폼을 대체하지 않습니다. 회사마다 다른 SDK와 런타임, 데이터 접근 규칙, 최종 보안 검증까지 제가 전부 책임진다고 말하는 것도 맞지 않습니다. 그 부분은 결국 해당 조직의 개발팀이 자기 환경에서 마무리해야 합니다.

대신 그 앞에서 아이디어를 구조로 바꾸고, 실제로 돌려 보고, 문제가 생길 만한 곳을 먼저 잡고, 고칠 수 있는 코드로 넘깁니다. 운영 플랫폼이 아니라 설계·검증 브리지라고 정리하니 기존 기능의 우선순위도 훨씬 또렷해졌습니다.

쓰는 사람과 먼저 돈 내는 사람은 다를 수 있습니다

여기서는 두 가지를 일부러 나눠서 보고 있습니다. 제품을 쓰는 장면의 중심에는 사내 플랫폼에 올릴 그래프를 만드는 개발자와 그 도입을 돕는 AI CoE·플랫폼 팀이 있습니다. 반면 첫 유료 고객은 여러 고객사의 에이전트를 반복해서 납품하는 AI 에이전시나 SI·컨설팅사의 AI Delivery 팀일 수도 있습니다.

후자는 고객마다 품질과 비용을 증명해야 하고, 검증한 코드를 고객 환경으로 넘기는 일을 반복하니 돈을 낼 이유가 더 빨리 생길 수 있습니다. 하지만 이건 어디까지나 첫 판매 경로에 대한 가설입니다. London System의 사용 목적을 에이전시용 운영 도구로 다시 바꾼 것은 아닙니다. 누가 쓰는지와 누가 먼저 사는지는 따로 검증하려고 합니다.

기능은 버리지 않고, 판단 기준을 바꿨습니다

기존의 compile → simulate → eval → policy gate → deploy/export 흐름은 그대로 필요합니다. 다만 이제 새 기능을 볼 때 "에이전트를 끝까지 대신 운영해 주는가"보다 "개발자가 가져가 직접 완성할 만한 출발점을 만드는가"를 먼저 묻게 됩니다.

그래서 당장은 커넥터 수를 늘리는 것보다 export한 코드가 정말 읽고 고치기 쉬운지, 함께 만든 eval이 다른 환경에서도 이어지는지, 개발자의 첫 시행착오를 얼마나 줄이는지가 더 중요합니다.

아직 정한 것뿐입니다

목적을 다시 적었다고 시장 검증까지 끝난 건 아닙니다. 실제 개발자가 코드를 받아 자기 환경에 붙일 수 있는지, eval 결과를 신뢰하는지, 그래프 설계 시간이 정말 줄어드는지는 파일럿으로 확인해야 합니다. 솔직히 여기서 안 먹히면 정의를 또 고쳐야 합니다.

그래서 다음 할 일도 기능 하나를 더 붙이는 게 아닙니다. 실제 에이전트 하나를 이 흐름으로 만들고, 검증하고, 고객 환경으로 넘기는 한 바퀴를 돌아보는 일입니다. 그 과정에서 어디가 끊기는지 다시 적어 두려고 합니다.

이제야 이름값을 하는 것 같습니다

런던 시스템이라는 이름은 체스 오프닝에서 가져왔습니다. 화려한 한 수보다 먼저 반복 가능한 구조를 세우고, 그 위에서 다음 수를 준비하는 방식이 제가 만들고 싶은 제품과 닮았다고 생각했거든요.

돌이켜 보면 저는 한동안 운영 환경 전체를 다 가지려고 했습니다. 이번에는 판 전체를 차지하려는 대신, 운영에 들어가기 전 가장 불안한 구간을 단단하게 만드는 쪽을 골랐습니다. 기능을 줄인 게 아니라, London System을 꺼내야 하는 순간을 정한 겁니다. 범위를 줄였다고 꿈이 작아진 건 아닙니다. 이제 첫 수가 조금 분명해졌습니다.