모델이 사람 대신 일하도록, 에이전트의 구조를 만드는 선행개발파트
Cultures
선행개발파트는 제논 R&D그룹에 속한 조직으로, 지금 제품에 없는 능력을 먼저 만들어 검증한 뒤 그 결과를 제품 코드로 넘기는 일을 합니다. 현재 파트가 가장 많은 시간을 쓰는 대상은 사용자를 대신해 브라우저와 컴퓨터를 직접 조작하는 데스크톱 AI 에이전트 원에이전트(OneAgent)이며, 에이전트 엔진과 평가 체계, 자체 모델 후속 학습까지 파트 안에서 함께 다룹니다. 사람을 대신해서 모델이 일을 하게 만드는 일이 실제로 어떻게 진행되는지, 선행개발파트장에게 직접 들어봤습니다.
저희 파트는 원에이전트에 해당하는 Actionable Agent를 만드는데, 요즘은 이 일을 하네스 엔지니어링이라고 생각하고 있습니다. 모델은 밖에서 계속 좋아지지만, 그 모델이 실제로 일을 끝내려면 도구를 쥐여 주고 화면을 읽게 하고 실패했을 때 되돌려 주는 층이 필요합니다. 저희가 만드는 게 그쪽이라는 뜻입니다.
그래서 푸는 문제도 대부분 모델의 추론과 실제 동작 사이의 간극에 있습니다. 어떤 도구를 언제 어떤 인자로 부를지 정하는 일, 그 호출이 실패했을 때 되돌리고 다시 계획하는 일, 화면을 모델이 읽을 수 있는 형태로 만들어 주는 일이요. 여기에 그게 정말 나아졌는지 재는 평가 체계, 그리고 하네스만으로 풀리지 않는 부분은 모델을 직접 학습시켜 푸는 일까지 파트 안에서 같이 합니다. 결국 저희 일은 모델을 더 똑똑하게 만드는 쪽이 아니라, 모델이 사람 대신 일할 수 있는 구조를 만드는 연구에 가깝습니다.
선행개발파트는 지금 제품에 없는 능력을 먼저 만들어 검증한 뒤 제품 코드로 넘기는 조직입니다. 담당 범위가 하네스 한쪽에만 있지는 않습니다. 에이전트 엔진(도구 호출, MCP 커넥터, Browser Use, Computer Use)과 그 성능을 재는 평가 체계가 한 축이고, 다른 한 축은 모델 자체입니다. 화면 요소를 식별하고 직접 조작하는 능력을 강화한 훈민 VLM처럼 자체 파운데이션 모델을 후속 학습시키는 일, 그리고 LLM의 입력과 출력을 검사하는 가드레일 모델과 개인정보 마스킹 모델을 만드는 일이 같은 파트 안에서 진행됩니다.
파트 안에는 이 일을 나눠 맡는 두 개의 TF가 있습니다. 원에이전트(OneAgent) TF와 Physical AI TF인데, 모델의 판단을 실제 행동으로 옮기는 층을 만든다는 점은 같고 행동하는 무대가 다릅니다. 원에이전트는 브라우저와 컴퓨터라는 화면 안에서 움직이고, Physical AI TF는 휴머노이드 젠피(GenP)에 들어가는 지능을 만들어 실제 공간에서 움직입니다. 무대가 다르면 관측 대상과 실패의 성격도 갈립니다. 저희는 화면을 모델이 읽을 수 있는 형태로 정제하고 잘못된 조작은 되돌린 뒤 다시 계획하지만, 물리 세계에서는 공간과 사람을 읽어야 하고 한 번 움직인 것을 되돌릴 수 없어 시뮬레이션 검증이 앞에 붙습니다. 화면 밖으로 나온 AI 이야기는 Physical AI TF 인터뷰에서 따로 만나실 수 있습니다.
여러 도구를 넘나드는 업무를 자동화할 때마다 사람이 그 경로를 미리 설계해야 한다는 문제를 풀기 위해 만들어졌습니다. 기존 방식은 설계해 두지 않은 상황이 오면 멈추고, 새로운 유형이 생길 때마다 다시 만들어야 했습니다. 원에이전트는 경로를 미리 그리지 않고 모델이 그 자리에서 판단하도록 만든 제품이며, 그래서 저희가 만드는 것도 업무 로직이 아니라 모델이 판단할 수 있는 환경입니다.
브라우저와 컴퓨터를 직접 조작하는 이유는 대부분의 업무 시스템이 API를 제공하지 않기 때문이고, 데스크톱 앱인 이유는 고객 대부분이 데이터를 외부로 보낼 수 없는 환경이기 때문입니다. 사용자 PC에서 실행되면 사내망에 직접 접근할 수 있고 개인 계정으로 동작하므로, 자료를 찾는 일부터 본인 명의로 결재를 올리는 일까지 기존 업무 방식 그대로 대신할 수 있습니다.
세 가지를 붙잡고 있습니다. 첫째는 관측입니다. 업무 시스템의 화면은 사람 눈에만 의미가 드러나도록 만들어져 있어서, 모델이 읽을 수 있는 형태로 화면을 정제하는 계층을 따로 두어야 합니다.
둘째는 행동의 결과 확인입니다. 에이전트의 실패는 조작을 못 해서가 아니라, 해놓고 결과를 확인하지 않은 채 성공으로 판단해서 생기는 경우가 훨씬 많습니다. 이는 프롬프트로 당부해서 해결되지 않고, 무엇을 근거로 성공을 판정할지 하네스가 규정해야 하는 문제입니다.
셋째는 사람이 개입해야 하는 순간입니다. 업무 중간에 추가 인증이나 보안 확인이 요구되는 경우가 있어, 이럴 때 실패로 끝내지 않고 제어권을 사용자에게 넘겼다가 다시 이어받는 구조를 두었습니다.
어려운 점은 이 세 가지가 서로 영향을 준다는 것입니다. 화면을 더 자세히 보여 주면 판단은 정확해지지만 느려지고, 결과 확인을 엄격하게 걸면 정확도는 오르지만 중간에 멈추는 일이 늘어납니다. 하나를 개선했을 때 다른 쪽이 나빠지지 않았는지 같이 봐야 하는데, 그걸 수치로 확인하기 위해 지금 벤치마크를 만들고 있습니다.
세 가지를 준비하고 있습니다. 첫째는 제공 방식으로, 지금까지 개인 PC에 설치하는 앱이었던 것을 서버에서 제공하는 구조로 넓히는 일입니다. 무인 스케줄 실행과 여러 사용자가 함께 쓰는 형태를 지원해야 하기 때문인데, 최근 실측에서 리눅스 서버 한 대로 동시 16세션 규모가 수용되는 것을 확인하고 사용자별 실행 공간을 분리하는 작업을 진행하고 있습니다.
둘째는 하네스 엔지니어링 자체를 평가할 수 있는 지표를 만드는 일입니다. 도구 사용과 터미널 작업, 웹사이트 조작을 각각 재는 벤치마크를 사내에 세워, 하네스를 바꿨을 때 성능이 실제로 올라갔는지 수치로 확인할 수 있게 하는 것입니다.
셋째는 그 지표를 근거로 모델이 아닌 부분을 개선하는 연구입니다. 무엇을 기억하고 무엇을 버릴지 정하는 메모리 구조, 행동한 뒤 언제 화면을 다시 확인할지 정하는 관측 시점처럼 지금까지 대체로 고정값으로 처리해 온 영역이 대상입니다. 여기에 하네스만으로 풀리지 않는 부분은 모델 학습으로도 접근해, 도구 호출과 화면 조작을 더 잘 수행하는 모델을 직접 후속 학습시키는 트랙을 함께 두고 있습니다.
규격은 새로 만들지 않고 따르는 것을 원칙으로 합니다. MCP처럼 업계가 합의한 프로토콜은 그대로 채택하고, 스킬도 사내 포맷을 만들지 않고 공개 규격을 사용해 외부 생태계의 자산을 바로 활용할 수 있게 했습니다.
구현 패턴을 받아들일 때는 개인 학습으로 두지 않고 프로젝트로 관리합니다. 올해 상반기에는 참고할 구현체 하나를 정해 열 개 영역으로 나눠 전수로 분석하고, 우리와의 격차를 열두 항목으로 정리한 뒤 항목마다 설계 문서를 만들어 한 달 안에 열 건을 반영했습니다.
다만 새로운 것을 전부 수용하지는 않습니다. 저희 고객은 편의보다 예측 가능성이 중요한 경우가 많아, 사용자가 인지하지 못한 사이에 동작이 바뀌는 기능은 의도적으로 제외한 사례도 있습니다.
각자 맡은 영역에 애정을 갖고 결론이 날 때까지 서로 토의하는 것이 저희 제논의 연구 문화라고 생각합니다. 중부발전 프로젝트를 수행할 때가 대표적이었습니다. 원에이전트에 어떤 기능을 어떤 방식으로 구현할지 정할 때마다 팀 동료들과 오래 논의했고, 각자 자신이 담당한 부분에 대한 기준이 분명해서 "일단 동작하게만 하자"로 넘어가지 않았습니다. 결론이 나기까지 시간이 걸렸지만, 그렇게 충분히 논의한 결정들은 대부분 오래 살아남았습니다.
지금도 새 기능을 설계할 때는 각자의 의견을 충분히 내놓고 부딪히는 과정을 먼저 거칩니다. 빠르게 합의하는 것보다 각자가 납득할 때까지 이야기하는 편이 결과적으로 더 빠르다고 보기 때문입니다.
스택은 주로 TypeScript입니다. Electron 데스크톱 앱과 백엔드 에이전트 서버, 그 안의 에이전트 런타임이 중심이고, 브라우저 제어와 MCP 커넥터가 함께 붙으며 평가 파이프라인과 모델 학습에는 Python을 씁니다.
다만 언어나 프레임워크 경험보다 중요한 것은 에이전트가 어떻게 판단하는지를 이해하고 있는지입니다. 저희는 공개된 에이전트 하네스에서 출발해 독자적으로 확장한 코드베이스를 쓰기 때문에, 프레임워크를 가져다 쓰는 것이 아니라 안쪽을 직접 고치는 작업이 많습니다. 도구를 어떤 모양으로 쥐여 주고 컨텍스트에 무엇을 넣을지 정하는 일이 대부분이고, 같은 입력에도 결과가 갈린다는 것을 전제로 설계해야 해서 일반적인 서버 개발과는 감각이 다릅니다.
그래서 에이전트 개발 경험 자체가 필수는 아닙니다. 기본적인 개발 경험은 필요하지만 어떤 언어를 써 봤는지는 덜 중요하고, 규모가 작아도 에이전트를 직접 만들어 왜 실패하는지 들여다본 경험이 있다면 그쪽이 훨씬 도움이 됩니다. 실제로 인턴으로 합류해 에이전트 간 통신 구조를 직접 설계하고 구현한 사례도 있습니다.
토의 과정에서 자신의 의견을 적극적으로 전달하는 분이 잘 맞습니다. 저희는 설계를 혼자 결정하지 않고 서로 부딪혀 가며 만들기 때문에, 생각을 정확히 전달하는 능력이 실무 역량의 상당 부분을 차지합니다.
하네스를 구성하는 요소가 넓어서 처음부터 전부 알고 합류하는 경우는 없습니다. 따라서 연구 기반이 다소 부족하더라도, 모르는 것을 편하게 질문하고 아는 것은 먼저 설명하면서 서로의 이해를 채워 갈 수 있는 분이면 충분합니다. 실제로 그런 분들이 팀 업무에 가장 빠르게 적응했습니다.
10. 마지막으로, 앞으로 어디까지 가보고 싶으신가요?
원에이전트를 특정 사이트에 맞추는 수준을 넘어, 어떤 환경에서도 동작하는 범용 에이전트로 끌어올리는 것이 목표입니다. 지금까지의 자동화 구현은 고객 환경마다 개별 대응이 필요한 부분이 남아 있었습니다. 앞으로는 더 다양한 프로젝트에서 자동화를 구현하면서 그 과정에서 반복되는 문제를 하네스 엔지니어링 관점의 벤치마크로 정리하고, 그 지표를 기준으로 성능을 확장하려 합니다.
무엇이 좋은 하네스인지 측정하는 기준 자체가 아직 정립되지 않은 분야이므로, 그 기준을 만드는 일에 기여할 여지가 크다고 봅니다. 원에이전트의 성장에서 멈추지 않고 하네스 엔지니어링이라는 영역 전반의 성장에 보탬이 되는 것이 지향점입니다.
