If agents both build and use software…

<소프트웨어를 만드는 것도, 쓰는 것도 에이전트가 된다면...>

최근 50층이 넘는 대형 건물의 3D 물류 시뮬레이션 프로젝트를 고민하면서, 소프트웨어에 대한 제 생각이 꽤 많이 바뀌었습니다. 지하로 들어온 트럭이 화물을 내리고, 로봇과 사람이 이를 받아 엘리베이터를 타고 각 층으로 배송합니다. 도크와 화물 엘리베이터는 몇 개가 필요한지, 적재 공간과 동선은 어떻게 설계해야 하는지, 물동량이 30% 증가해도 버틸 수 있는지를 건물이 지어지기 전에 검증해야 합니다. 처음에는 건축·물류·로봇·법규·BIM·시뮬레이션 전문가를 모두 모아야 하는 일이라 생각했습니다. 현재 인력으로는 어렵겠다는 생각이 들었지만, 이번에는 반대로 “사람으로 팀을 꾸리기 어렵다면 에이전트 팀으로 한번 풀어보자”고 주말 동안 붙잡고 있었습니다.

여러 전문 역할의 에이전트에게 기준과 사례를 조사시키고, 3D/BIM 도구와 시뮬레이션 방법을 찾게 하고, 서로의 결과를 비판하게 해보았습니다. 흥미로웠던 것은 정답이 바로 나왔다는 것이 아닙니다. 오히려 그럴듯한 물동량 숫자 하나가 등장했을 때 다른 에이전트가 “그 숫자의 근거는 무엇인가?”라고 되묻는 순간이 더 중요했습니다. 에이전트가 예상보다 많은 전문 작업을 수행할 수 있다는 가능성과 함께, 에이전트가 더 많은 일을 할수록 근거와 검증은 오히려 더 엄격해야 한다는 사실도 보이기 시작했습니다.

생각해보면 첫 번째 시대에는 소프트웨어를 만드는 것도 사람이고, 사용하는 것도 사람이었습니다. 개발자가 업무를 분석해 기능과 workflow를 만들고, 사람은 그 소프트웨어를 배우고 사용했습니다. 지금은 두 번째 단계가 빠르게 진행되고 있습니다. 소프트웨어를 사용하는 것은 여전히 사람이지만, 만드는 것은 Claude Code나 Codex 같은 에이전트가 대신할 수 있습니다. 하지만 결국 사람이 다시 그 소프트웨어를 배워 사용한다면, Software가 최종 산출물이고 Human이 최종 사용자라는 기존 전제는 아직 남아 있습니다.

제가 더 흥미롭게 보는 것은 세 번째 단계입니다. 소프트웨어를 만드는 것도 에이전트이고, 사용하는 것도 에이전트인 경우입니다. 사람은 “엘리베이터를 몇 대 설치해야 하는가?”, “이 설계의 병목은 어디인가?”, “수요가 30% 증가해도 괜찮은가?”라는 질문을 던집니다. 그러면 에이전트 팀이 필요하면 BIM을 읽고, 시뮬레이터를 만들고, 외부 3D 엔진을 사용하고, 여러 설계안을 실험한 뒤 필요한 근거와 결론을 가져옵니다. 이때 Software는 사람이 직접 사용하는 완제품이라기보다, 문제를 해결하기 위해 에이전트가 만들고 사용하는 중간 산출물에 가까워집니다.

그렇다고 인간의 역할이 줄어드는 것만은 아닐 것 같습니다. 오히려 역할이 바뀝니다. 실행의 주체가 AI가 된다면 인간은 모든 버튼을 직접 누르는 Operator라기보다, 목표와 선호를 주고 AI가 제대로 일하고 있는지 감독하는 Supervisor에 가까워집니다. “비용보다 안전을 우선하라”, “이 가정은 아직 신뢰하지 마라”, “이 조건에서는 사람의 승인을 받아라” 같은 기준을 주고, 정상적인 업무는 AI가 처리하되 불확실하거나 위험한 경우만 사람이 개입하는 방식입니다. 앞으로의 소프트웨어 화면도 사람이 일을 수행하는 workflow보다, AI가 무엇을 하고 있는지 보고 근거를 확인하고 방향을 수정하는 control plane에 가까워질 수 있습니다.

이 변화가 흥미로운 이유는 Software Engineering의 중심도 달라질 수 있기 때문입니다. 코드 자체를 만드는 비용이 크게 낮아진다면, 더 중요한 것은 어떤 문제를 풀 것인지 정의하고, 어떤 데이터와 제약을 사용할지 명시하고, 결과가 재현 가능한지 검증하고, 누가 어떤 조건에서 최종 책임을 질 것인지를 설계하는 일이 됩니다. KAIST에서 학생들을 지도할 때나 오믈렛에서 산업 문제를 풀 때도 그래서 특정 도구의 숙련도보다, 산업에서 중요한 문제를 발견하고 구조화하고 실험과 검증을 거쳐 실제 의사결정까지 가져가는 Problem-Solving Capability를 점점 더 중요하게 보게 됩니다.

그러다 보니 기업이 앞으로 무엇을 구매하게 될지도 생각해보게 됩니다. 사람이 더 편리하게 사용할 새로운 SW를 원하는 것인지, 아니면 그 일이 더 효과적으로 수행되는 것 자체를 원하는 것인지에 따라 답은 달라집니다. 후자라면 완성된 소프트웨어 하나를 구축해 턴키로 공급하는 것보다, 특정 역할을 지속적으로 수행하는 Problem-Solving Capability를 공급하는 방식도 중요해질 수 있습니다.

오믈렛이 만들고자 하는 것도 이 capability를 표준화하는 것입니다. 좋은 의사결정이 반복적으로 수행되고, 인간이 그 목표와 선호를 통제하며, 결정 당시의 맥락과 근거와 실행 결과가 고객의 자산으로 축적되어 다음 의사결정을 더 좋게 만드는 구조입니다. Agent 시대에 장기적으로 남아야 할 것은 프로그램 그 자체보다, 사람의 감독 아래 조직과 함께 학습하고 진화하는 문제 해결 능력일 수 있다고 생각합니다.

Omelet