AI 시대에도 변하지 않는 소프트웨어 엔지니어링의 본질
엔지니어링 과정에서의 편법, 허술한 보안, 기본 원칙을 가볍게 여기는 태도는 애플리케이션이 AI 모델과 에이전트가 지닌 잠재력에 도달하지 못하도록 막고 있다.
X에서 앤드루 응, 페이지 베일리, 데미스 허사비스, 톰 울프, 산티아고 발다라마 등 대표적인 AI 전문가들을 따라가다 보면 새로운 AI 과제가 부상하는 양상과 이를 해결하려는 개발자의 방식이 보이기 시작한다. 이들 전문가가 보여주는 메시지는 분명하다. 현재 개발자는 2가지 힘에 동시에 맞서고 있다. 눈부신 성능 향상이 이루어지는 한편, 여전히 고질적인 소프트웨어 문제가 발목을 잡는다. 모델은 갈수록 똑똑해지지만, 애플리케이션은 늘 같은 지점에서 무너진다. 시연용 데모와 실제로 오래 쓸 수 있는 제품 사이의 간극, 바로 그 사이에서 대부분의 엔지니어링이 이뤄지고 있다.
그렇다면 개발팀은 이 교착 상태를 어떻게 풀고 있을까? 답은 기본으로 돌아가는 것이다.
에이전트가 무너질 때
앤드루 응은 많은 개발자가 경험으로 체득한 사실을 꾸준히 강조하고 있다. “데이터 에이전트는 실패할 때 종종 조용히 실패한다. 자신감 넘치는 답변을 내놓지만 실제로는 틀린 경우가 많으며, 무엇이 실패 원인인지 파악하기 어렵다”라는 것이다. 응은 단순히 최종 정확도에만 주목할 것이 아니라, 에이전트가 밟는 각 단계마다 체계적인 평가와 관측 가능성을 확보해야 한다고 설명한다. ‘바이브 코딩(vibe coding)’이라는 용어가 매력적으로 들릴 수 있지만, 숙련된 개발자는 에이전트의 계획, 도구, 메모리에 유닛 테스트, 트레이스, 헬스 체크를 적용해 검증한다.
다시 말해, 개발자는 에이전트를 분산 시스템처럼 다루고 있다. 오픈텔레메트리(OpenTelemetry) 로 모든 단계를 계측하고, 반복 가능한 평가를 위해 소규모 ‘골든 데이터 세트’를 유지하며, API를 검증하듯 에이전트의 계획과 도구에도 회귀 테스트를 실행한다. 이 접근법은 단순한 실험용 애플리케이션을 넘어 본격적인 에이전틱 시스템을 설계하는 단계에서 특히 중요하다. 앤드루 응은 이 과정에서 에이전트가 다른 에이전트를 검증하기 위해 직접 테스트를 작성하고 실행하는 사례가 늘고 있다고 설명한다. 겉보기에는 자기참조적으로 보일 수 있지만, 테스트 환경을 실제 소프트웨어처럼 버전 관리하고 리뷰하며, 정량적으로 측정할 때 효과적인 방식이다.
산티아고 발다라마 역시 같은 우려를 제기하며 때로는 과감히 한발 물러서는 태도를 권했다. 모든 것을 에이전트로 만들려는 유혹을 뿌리치라는 발다라마의 조언은 화려하지 않지만 실질적이다. 발다라마는 “이유 없이 복잡성을 추가하고 싶은 유혹은 정말 강하다. 그러나 그 유혹을 피하는 편이 훨씬 낫다”라고 말했다. “일반 함수가 거의 항상 더 낫다”라는 발다라마의 말처럼 단순한 함수로 충분하다면 그대로 사용하는 것이 바람직하다.
모델뿐 아니라 데이터를 바로잡아라
모델을 손보는 것보다 먼저 해야 할 일은 검색 성능을 개선하는 것이다. 앤드루 응은 RAG(Retrieval-Augmented Generation) 시스템에서 발생하는 “잘못된 답변” 대부분이 모델 문제가 아니라 부실한 청킹(chunking), 누락된 메타데이터, 체계적이지 못한 지식 베이스 때문에 생긴다고 지적했다. 즉, 모델 문제가 아니라 데이터 문제다.
성과를 내는 팀은 지식을 하나의 제품으로 다룬다. 구조화된 코퍼스를 구축하고, 때로는 에이전트를 활용해 개체와 관계를 추출해 가벼운 그래프 형태로 정리한다. 또 이들은 RAG 시스템을 검색 엔진처럼 평가한다. 최신성, 커버리지, 기준 질문 집합에 대한 적중률 등을 기준으로 성능을 측정한다. 청킹은 단순히 라이브러리 기본값에 맡기는 것이 아니라, 계층 구조, 제목, 안정적인 ID를 설계하는 인터페이스로 다뤄야 한다.
또한 JSON을 간과해서는 안 된다. 많은 팀이 이제는 “자유 텍스트와 운에 맡기는 방식”에서 벗어나 엄격한 검증기를 포함한 스키마 우선(schema-first) 프롬프트를 채택하고 있다. 처음에는 지루하게 느껴질 수 있지만, 파서가 더 이상 깨지지 않고 도구가 엉뚱하게 동작하지 않는다는 점에서 효과적이다. 이렇게 제약된 출력은 대형 언어 모델을 수다스러운 인턴이 아니라, 다른 서비스를 안정적으로 호출할 수 있는 서비스로 바꿔놓는다.
코딩 툴에 가드레일을 설치하라
오픈AI 공동 설립자 그렉 브록먼은 최신 GPT-5-코덱스(GPT-5-Codex)가 단순한 ‘자동 완성’ 기능을 넘어, 저장소를 읽고 오류를 찾아내며 직접 풀 리퀘스트까지 생성하는 AI ‘로봇’에 가깝다고 설명했다. 브록먼은 특히 코덱스 CLI에서 잘못된 저장소를 지정했을 때도 스스로 올바른 경로를 찾아내는 자동 코드 리뷰 기능을 강조했다. GPT-5-코덱스는 리스폰스 API(Responses API)를 통해 일반 개발자에게도 제공되기 시작했다. 이는 저장소 인식 능력이 한 단계 진화했음을 보여준다.
하지만 복잡한 문제도 따른다. 지나친 위임 위험이다. 발다라마는 이를 두고 “AI에 모든 코드를 맡기는 건 소믈리에에게 내 와인을 전부 마시게 하는 것과 같다”라고 비유했다. 즉, 개발자가 스스로 책임질 수 있는 코드를 더 빠르게 작성하는 데만 AI를 활용해야 한다. 판단 자체를 아웃소싱해서는 안 된다. 실제로는 AI가 제안한 변경(diff)을 개발자의 CI(Continuous Integration)와 긴밀히 연결하고, 모든 AI 생성 코드 변경에 대해 테스트를 강제해 빌드가 실패하면 병합을 막아야 한다.
이 모든 흐름은 생성형 AI가 아직 ‘자동 조종 모드’에 도달하지 못했다는 사실을 다시금 일깨운다. 예를 들어 구글 딥마인드는 최근 제미나이 2.5 딥 싱크(Deep Think)를 통해 장기적 추론 능력을 강화한 모델을 선보였다. 이는 복잡한 다단계 논리를 일일이 감독하지 않고도 이어갈 수 있어 개발자에게 의미 있는 발전이다. 하지만 이는 여전히 리더보드 점수와 실제 SLO(service-level objective) 사이의 신뢰성 격차를 메우지는 못한다.
코드 품질을 위한 조언도 중요하지만, 토마즈 튕구즈가 지적했듯 비용 문제 또한 빼놓을 수 없다. 프런티어 모델에 대한 API 호출은 항상 과금되고 있으며, 데모 단계에서는 훌륭해 보이는 기능이 실제 서비스 규모로 확장되면 재정적 블랙홀로 변할 수 있다. 동시에 레이턴시에 민감한 애플리케이션은 GPT-4처럼 느리고 비싼 모델이 단순 응답을 생성할 때까지 기다릴 수 없다.
이런 상황은 비용과 성능 최적화에 초점을 맞춘 새로운 AI 엔지니어링 분야를 만들어냈다. 똑똑한 팀들은 이를 부차적 고려가 아닌 핵심 아키텍처 과제로 다루고 있다. 이들은 지능형 라우터 또는 모델 캐스케이드(model cascade)를 구축해 단순한 질의는 하이쿠(Haiku)나 제미나이 플래시(Gemini Flash) 같은 더 저렴하고 빠른 모델에 보내고, 복잡한 추론이 필요한 작업에만 고성능 모델을 할당한다. 이 접근법은 초기에 사용자 의도를 정확히 분류하는 과정을 필요로 하는데, 이는 이제 LLM 오케스트레이션에 적용되는 고전적인 엔지니어링 과제다.
캐싱 전략도 진화하고 있다. 단순히 레디스로 기본 캐싱을 구현하는 수준을 넘어, 이제는 시맨틱 캐싱(semantic caching)이 새로운 흐름으로 떠오르고 있다. 이는 프롬프트의 정확한 텍스트가 아니라 응답의 의미를 저장해, 의미상 유사한 미래 질의에도 캐시된 결과를 반환할 수 있도록 하는 방식이다. 결과적으로 비용 최적화가 단순한 보조적 활동이 아니라, 체계적이고 필수적인 엔지니어링 프랙티스로 자리 잡고 있다.
초대질량 블랙홀은 ‘보안’
생성형 AI 시대에 보안은 전혀 다른 차원으로 확장되고 있다. AI가 생성한 코드에 가드레일을 설치하듯, 사용자 입력에도 동일한 원칙을 적용해야 한다. 모든 프롬프트는 잠재적으로 적대적일 수 있다고 전제해야 한다.
여기서 말하는 위협은 전통적 취약점에 국한하지 않는다. 악의적인 사용자가 LLM의 지침을 무시하도록 속여 숨겨진 명령을 실행하게 만드는 프롬프트 인젝션(prompt injection)이 대표적이다. 이는 단순한 이론적 위험이 아니라 실제로 발생하고 있으며, 개발자는 이제 OWASP가 꼽은 가장 치명적인 LLM 취약점과 씨름하고 있다.
해법은 기존 보안 습관과 새로운 접근 방식을 결합하는 것이다. 에이전트가 사용할 수 있는 도구를 엄격하게 샌드박싱해 최소 권한만 부여해야 한다. 출력 검증은 물론이고, 그보다 더 중요한 것은 LLM이 생성한 명령을 실행하기 전에 의도를 철저히 검증하는 절차다. 이는 단순히 문자열을 정제하는 수준을 넘어, 강력하면서도 쉽게 왜곡될 수 있는 모델의 추론 능력에 둘러싼 방어막을 구축하는 일이다.
표준화로 가는 길
지난해 출시된 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 등이 점차 표준으로 자리 잡으며, 도구와 데이터를 모델에 연결하는 방식이 정형화되고 있다는 점은 성과로서 주목받지 못했다. MCP 자체는 화려하지 않지만, 그렇기 때문에 더욱 실용적이다. 수많은 스크립트를 붙여 쓰지 않고도 공통 인터페이스를 제공하기 때문이다. 하루가 다르게 모든 것이 변하는 업계에서 MCP가 1년 넘게 대체되지 않고 살아남았다는 사실만으로도 의미 있는 성취라 할 수 있다.
이 움직임은 AI 환경에서도 최소 권한 접근을 제도화할 기회를 제공한다. 에이전트가 활용하는 도구를 운영 환경의 API처럼 다뤄야 한다는 것이다. 범위, 할당량, 감사 로그를 적용하고, 민감한 작업에는 명시적 승인을 요구해야 한다. 툴 계약을 엄격하게 정의하고, 다른 서비스 계정처럼 자격 증명을 정기적으로 교체해야 한다. 이는 새로운 문제에 대응하는 구식 보안 원칙의 재해석이라 할 수 있다.
사실 이런 베스트 프랙티스가 보여주는 가장 큰 흐름은 실용주의다. 에이전트 테스트, 모델 라우팅, 프롬프트 검증, 도구 표준화 등 무엇을 이야기하든 핵심은 같다. AI 업계가 마침내 화려한 기능 시연을 넘어, 이를 안정적인 소프트웨어로 만드는 진지하고도 단순한 작업에 착수하고 있다는 것이다. 이는 한때 틈새 영역에 머물던 분야가 본격적인 전문 영역으로 발전하는 과정이라 할 수 있다.
앞으로도 더 큰 컨텍스트 윈도우와 새로운 추론 능력을 좇으며 과대광고가 이어질 것이다. 그것은 연구이자 과학의 영역이니 문제될 것 없다. 하지만 수십 년간의 소프트웨어 엔지니어링에서 얻은 교훈을 적용하는 팀이 실질적인 비즈니스 가치를 열고 있다. 이들은 데이터를 제품처럼 다루고, API를 계약처럼 관리하며, 보안을 전제 조건으로 삼고, 예산을 현실적인 자원으로 취급한다.
결국 AI로 무언가를 구축하는 미래는 마술 쇼가 아니라 잘 운영되는 소프트웨어 프로젝트에 훨씬 더 가깝다. 그리고 바로 그곳에서 진짜 돈이 만들어진다.
※위 포스팅이 문제될 경우 삭제하겠습니다.
