LLM 기반 제품 개발의 변화 (2025년을 지나며)
AgentOps가 무엇이고 왜 점점 중요해지고 있는지를 이해하려면, 먼저 지금의 개발 환경이 어떻게 변화해왔는지를 돌아볼 필요가 있습니다. 이 글을 쓰기 시작하며 2024년 처음 인라인 AI 어시스턴트를 사용하기 시작했을 때부터 2025년 말에 이르기까지 개발 방식이 어떻게 달라졌는지를 되짚어보았습니다. 하지만 그 변화를 하나로 정리하는 일은 쉽지 않았습니다. 변화의 폭이 컸고, LLM을 사용하는 방식은 개발자 개인의 습관이 자리 잡기도 전에 계속해서 바뀌고 있었기 때문입니다.
처음 모델과 상호작용하던 방식은 거의 의식에 가까웠습니다. 코드를 직접 복사해 채팅창에 붙여넣고, 문제를 길게 설명한 뒤, 충분한 맥락이 전달되기를 기대하는 방식이었습니다. 분명 도움이 되기는 했지만, 여전히 실제 개발 흐름과는 분리된 외부 도구라는 인식이 강했습니다.
2024년 중반에 접어들면서 상황이 달라졌습니다. IDE 확장 형태로 인라인 힌트를 제공하고, 개발 환경 안에서 바로 모델과 상호작용할 수 있는 도구들이 빠르게 등장하기 시작했습니다. 이때부터 LLM은 일상적인 개발 워크플로의 일부가 되었습니다. 그리고 2025년 초, 저 역시 Windsurf로 완전히 전환하게 되었습니다. 더 정교한 힌트, 정확한 맥락 관리, 그리고 모델이 실제로 프로젝트를 이해하고 있다는 느낌은 개발 속도를 눈에 띄게 높여주었고, 동시에 피로도도 줄여주었습니다.
이와 동시에 더 근본적인 변화도 진행되고 있었습니다. MCP의 발전, 컨텍스트 윈도우의 확장, RAG의 도입, 도구 호출이 가능한 모델의 등장 등 여러 아키텍처 변화가 겹치면서, 보조 도구와 실제 작업 수행자 사이의 경계가 점점 흐려지기 시작했습니다. 어느 순간부터는 특정 작업에 한해서는 사람이 매 단계 개입하지 않아도 결과가 나오는 지점에 도달했습니다.
바로 이 시점에서 문제가 분명해졌습니다. 기존의 통제 방식과 책임 구조로는, 이렇게 높아진 속도와 자율성을 더 이상 감당할 수 없다는 사실이었습니다. 새로운 관리 레이어가 없는 상태에서의 속도와 자율성은, 점차 우리에게 이점이 아니라 부담으로 작용하기 시작했습니다
LLM을 사용하는 방식의 변화
지난 몇 년간 소프트웨어 개발은 단번에 바뀐 것이 아니라, 누적된 변화의 결과로 달라졌습니다.
2023년에는 LLM이 흥미롭지만 여전히 실험적인 도구였고, 2024년에는 실무에 활용되는 보조 수단이 되었으며, 2025년에 이르러서는 더 이상 하나의 도구가 아니라 업무를 조직하는 새로운 방식이라는 점이 분명해졌습니다.
개발 속도만 달라진 것이 아니라, 요구사항 정의부터 프로덕션 배포에 이르기까지 전체 프로세스의 구조 자체가 달라지고 있습니다.
Copilot에서 시작된 접근
초기의 접근 방식은 비교적 명확하고 안전했습니다. LLM은 ‘코파일럿’의 역할을 맡았습니다. 개발자 옆에 앉아 힌트를 제공하고, 개발 속도를 높이며, 인지 부담을 줄여주되, 스스로 결정을 내리지는 않는 방식입니다. 책임은 여전히 개발자에게 있었고, 통제도 명확했습니다. 이 때문에 IDE 통합, 코드 자동 완성, 채팅형 어시스턴트가 가장 빠르게 확산될 수 있었습니다.
하지만 곧 이것이 빙산의 일각에 불과하다는 점이 드러났습니다. 팀들이 LLM을 개별 파일이 아니라, 기능이나 모듈 단위의 작업에 사용하기 시작하면서 더 완전한 형태의 해법이 필요해졌습니다. 내부 코드, 문서, 티켓, 조직의 비즈니스 로직을 함께 다루는 폐쇄형 LLM 시스템이 등장했고, 이들은 더 이상 단순한 보조 도구가 아니라 조직 지식의 일부로 기능하기 시작했습니다.
속도와 안전 사이에서 시도된 절충안
그 다음 단계에서는 사람과 모델이 책임을 나누는 하이브리드 접근이 시도되었습니다. 어떤 작업은 자동으로 처리하고, 어떤 작업은 승인 과정을 거치며, 어떤 작업은 사후 조정을 통해 보완하는 방식입니다. 이론적으로는 속도와 안정성을 모두 만족시키는 이상적인 구조처럼 보였습니다. 그러나 실제로는 이전에는 없던 형태의 문제가 나타나기 시작했습니다.
LLM 활용 과정에서 드러난 문제들
가장 먼저 드러난 문제는 주니어와 시니어 개발자 간의 격차였습니다. LLM은 결과물의 양과 속도에서는 격차를 줄였지만, 그 결과가 가져올 영향에 대한 이해까지 줄여주지는 못했습니다. 주니어 개발자들은 더 많은 코드를 작성하게 되었지만, 항상 더 나은 코드를 작성하는 것은 아니었습니다. 반대로 시니어 개발자들은 구현보다 테스트와 설명에 더 많은 시간을 쓰게 되었고, 팀 내 역할의 균형도 달라졌습니다. 코드 리뷰는 구현만큼이나 중요한 단계가 되었습니다.
프로젝트 관리 측면에서도 새로운 문제가 나타났습니다. 기능 개발 속도가 빨라지면 자연스럽게 전체 일정도 빨라질 것처럼 보입니다. 하지만 실제로는 병목 지점만 이동했을 뿐이었습니다. 승인 절차, 비즈니스 로직 검증, 보안 및 규제 준수 단계에서 새로운 지연이 발생했습니다. 생성 속도는 빨라졌지만, 예측 가능성은 오히려 낮아졌습니다.
대규모 프로젝트에서는 맥락 관리가 특히 큰 과제가 되었습니다. LLM은 로컬한 작업에는 강하지만, 코드와 문서, 구두 합의, 의사결정 이력이 흩어져 있는 복잡한 환경에서는 문제가 발생하기 쉽습니다. 모델은 국지적으로는 완벽해 보이는 코드를 생성할 수 있지만, 전체 아키텍처 원칙이나 팀 내부의 암묵적인 규칙을 위반하는 경우도 있습니다. 프로젝트 규모가 클수록 이러한 오류의 비용은 더 커집니다.
리뷰의 성격도 달라졌습니다. 한때 품질 개선을 위한 과정이었던 리뷰는 점차 리스크를 차단하기 위한 단계로 변했습니다. 이제는 코드뿐만 아니라, “왜 이런 결정을 내렸는가”, “어떤 맥락을 기준으로 생성되었는가”까지 확인해야 했습니다. 하지만 이런 질문에 명확히 답할 수 없는 경우가 많았습니다.
여기에 문서가 부족하거나 오래된 상태라는 문제까지 더해지면 상황은 더욱 복잡해집니다. LLM은 빈칸을 그럴듯하게 채우는 데 매우 능숙하지만, 그것이 항상 올바른 것은 아닙니다. 프로젝트의 스타일에는 잘 맞추지만, 규칙까지 정확히 따르지는 않습니다. 그 결과, 시스템은 겉보기에는 일관돼 보이지만, 내부적으로는 논리적으로 취약한 상태가 됩니다.
이 지점에서 분명해집니다. 문제는 모델이 아닙니다. 개발자도 아닙니다. 문제는 관리 레이어의 부재입니다. 그리고 바로 여기에서 AgentOps라는 개념이 등장하게 됩니다. 이는 특정 제품이나 프레임워크가 아니라, 하나의 사고 방향이자 실천 방식입니다.
AgentOps란 무엇인가
AgentOps는 사람, 서비스, 프로세스를 관리하듯이 에이전트를 어떻게 관리할 것인가라는 질문에 답하려는 시도입니다. 에이전트에게 어떤 작업을 맡길 수 있는지, 어디까지 허용해야 하는지, 그 행동을 어떻게 관찰할 것인지, 오류가 발생했을 때 어떻게 대응할 것인지가 핵심입니다. 이런 의미에서 AgentOps는 속도를 높이기 위한 개념이 아니라, 리스크를 관리하기 위한 접근에 가깝습니다.
에이전트의 등장으로 책임의 개념 자체도 달라졌습니다. 과거에는 오류가 특정 개인이나 팀에 귀속되었지만, 이제는 모델이 관여한 일련의 의사결정이 누적된 결과로 오류가 발생할 수 있습니다. 이는 관측성, 로깅, 재현성, 감사에 대한 새로운 접근을 요구합니다. 우리는 점점 에이전트를 라이브러리가 아니라, 프로세스의 참여자로 보기 시작했습니다.
AgentOps가 다루는 책임 영역
AgentOps의 핵심 축은 점차 명확해지고 있습니다.
에이전트가 허용된 지식 범위 안에서만 동작하도록 하는 맥락 통제, 권한을 넘어서는 행동을 하지 않도록 하는 접근 및 행위 관리, 예상치 못한 결과가 발생했을 때 무엇이 일어났는지를 이해할 수 있는 관측성과 추적성, 그리고 실험 단계부터 운영 단계까지 이어지는 에이전트 라이프사이클 관리입니다.
이를 추상적인 개념이 아니라 실무 관점에서 보면 AgentOps는 ‘똑똑한 에이전트’를 만드는 일과는 거리가 있습니다. 실제로는 에이전트를 둘러싼 일련의 규율과 운영 원칙에 가깝습니다. 에이전트는 거의 항상 명확한 역할을 부여받고, 제한된 데이터 소스와 허용된 행동 범위 안에서 동작합니다. 전체 코드베이스가 아니라, 버전 관리되고 검증 가능한 특정 맥락에서만 작업합니다.
모든 행동은 프로덕션 서비스처럼 로그로 남습니다. 어떤 입력을 받았고, 어떤 단계를 거쳤으며, 어떤 도구를 호출했고, 어떤 결과에 도달했는지를 확인할 수 있습니다. 중요한 지점에서는 사람의 확인을 요청하거나, 다음 단계로 결과를 넘길 뿐 임의로 프로세스를 종료하지 않습니다. 오류는 숨기지 않고 사고로 다루며, 원인 분석과 규칙 수정, 지침 업데이트를 통해 개선됩니다. 이를 통해 에이전트는 블랙박스가 아니라, 점진적으로 자율성을 부여할 수 있는 관리 가능한 구성 요소가 됩니다.
AgentOps의 미래
앞으로 이 분야는 더 똑똑한 모델을 향해 발전하기보다는, 모델을 둘러싼 시스템이 성숙해지는 방향으로 진화할 가능성이 큽니다. 에이전트는 더 저렴해지고, 더 쉽게 접근 가능해지며, 더 자율적으로 변할 것입니다. 그렇기 때문에 오히려 그 행동을 예측 가능하고 안전하게 만드는 인프라의 중요성은 더욱 커집니다.
AgentOps를 엔지니어링 문화 안에 먼저 정착시킨 기업은, 단순한 속도 향상을 넘어 지속 가능성을 함께 확보하게 될 것입니다. 그렇지 않은 조직은 기술 부채뿐 아니라, 운영과 관리 부채까지 뒤늦게 감당해야 할 수도 있습니다.
마치며
AgentOps는 미래의 이야기가 아닙니다. 이미 많은 팀에서 에이전트는 개발에 참여하고, 의사결정에 영향을 주고 있으며, 제품의 일부가 되고 있습니다. 중요한 것은 이것이 의식적으로 관리되고 있는가, 아니면 자연스럽게 방치되고 있는가입니다.
이 질문에 대한 답이, 앞으로 많은 팀과 기업의 성패를 가르게 될 것입니다.
