Python + LangChain의 정체. 우리는 AI를 사용해 과거의 '운영으로 커버'라는 부채를 속이고 있는 것뿐인가.

AI 기술의 진전에 따라, Python과 「LangChain (랭체인)」을 이용한 업무 자동화 안건이 급증하고 있습니다. 하지만 이 프레임워크가 이토록 필요로 여겨지며 급속히 보급된 배경에는, 많은 기업이 걸어온 「시스템 개발의 태만」의 역사가 깊게 관련되어 있습니다.

오랫동안 많은 기업에서는 소스 코드의 개수나 재설계가 용이하지 않은 레거시 (Legacy) 기간 시스템과, 명확한 규칙화를 포기하고 담당자의 수작업에 의존해 온 일상적인 업무 데이터의 「차이」로 인해 고민해 왔습니다.

시스템 본체 측은 쉽게 변경할 수 없다. 반면 현장에 모이는 데이터는 포맷이 통일되어 있지 않아, 기존의 확정적인 프로그램으로는 자동 처리가 불가능하다.

이러한 막다른 상황에서, 시스템에는 손을 대지 않고 그 전 단계에 문맥을 이해할 수 있는 LLM (대규모 언어 모델)을 배치하여, 다양한 데이터를 시스템이 받아들일 수 있는 구조화 데이터로 강제로 변환·정리한다. 이 「유연한 시스템 간 연계를 위한 인터페이스 (접착제)」로서 기대되고 있는 것이 바로 LangChain이라는 프레임워크의 진정한 역할입니다.

먼저 전제로서, LangChain이라는 프레임워크의 사양과 기술적인 메커니즘을 정리합니다. 이 컴포넌트의 본질은 확률적인 접근 방식으로 출력을 생성하는 LLM과, 확정적인 처리 (100%의 정확성)를 요구하는 기존의 시스템이나 프로그램 사이를 효과적으로 「가교」하여, 일련의 처리를 자동화하기 위한 개발 프레임워크입니다.

LLM은 단독으로는 「원칙적으로 모델이 학습한 시점의 일반적인 지식」에 기반하여 동작합니다. LangChain을 사용함으로써 최신 사내 문서, 데이터베이스, Web 검색, 혹은 기존 기간 시스템의 API와 LLM을 접속 (RAG 등의 기술을 활용)하여, 실시간이자 전문적인 컨텍스트를 고려한 처리를 가능하게 합니다.

LangChain Expression Language (LCEL) 등의 메커니즘을 사용하여, 여러 AI 처리나 시스템 조작을 파이프라인 (일련의 공정)으로 기술할 수 있습니다.

체인 (Chains): 「문서를 읽어온다」 $
ightarrow$ 「요건을 불렛 포인트로 추출한다」 $
ightarrow$ 「기존 시스템이 읽을 수 있는 JSON으로 변환한다」와 같이, 미리 정의된 절차를 자동 실행합니다.

에이전트 (Agents): 절차를 고정하지 않고, 주어진 목표에 대해 「LLM 스스로 다음에 어떤 도구를 사용하고 어떻게 움직여야 할지」를 추론하게 하여, 동적으로 실행 단계를 결정하게 합니다.

기존의 프로그램이라면 API의 응답을 해석하고, 문자를 추출하고, 프롬프트에 삽입하여 다음 API를 호출하는…… 식의 개별 중계 코드가 대량으로 필요했으나, LangChain은 데이터 형식의 자동 변환이나 관리를 수행하며, 서로 다른 AI 모델 (Gemini나 OpenAI 등)을 조합한 적재적소의 바통 터치를 최소한의 기술로 실현합니다.

데이터의 형태를 정돈하여 시스템에 투입하는 공정 자체는, 요건 정의만 명확해진다면 나머지는 위의 LangChain 라이브러리를 이용한 통상적인 시스템 개발 단계로 이행할 수 있습니다.

하지만 현재의 Python + LangChain 프로젝트 대부분은 개발 전의 「요건 정의 (업무 분석)」 단계에서 이상할 정도로 난항을 겪으며 현장이 불타오르고(炎上) 있습니다.

세상의 컨설턴트나 아키텍트들은 이를 「암묵지를 언어화하는 고도의 히어링 스킬이 필요하기 때문에」 혹은 「AI의 불확정 요소로 인해 계획 수립이 어렵기 때문에」라는 그럴듯한 이유로 설명하려 합니다.

하지만 본질은 다릅니다. 「요건 정의가 어려운」 것이 아닙니다. 지금까지 아무도 사양화하지 않았던 현장의 그레이 존 (Gray Zone)의 책임을, AI라는 『모호함을 허용하는 도구』에 통째로 떠넘기려 하고 있기 때문에 현장이 불타오르는 것입니다.

과거의 시스템 개발에서 개발 비용이나 스케줄의 제약으로 인해 시스템화를 보류하고, 「이 부분은 사람이 판단하여 운영으로 커버합시다」라며 회피했던 그레이 존. 이것이야말로 현재의 Python + LangChain 안건이 타겟으로 삼고 있는 주요 영역의 실태입니다.

야간 대응의 효율화 사례를 들어보겠습니다.

데이터 전송 에러나 배치 처리 에러를 검지했을 때, 이전에는 야간 대기 중인 오퍼레이터가 로그를 육안으로 확인하고, 파일 파손 등의 원인을 특정한 후, 과거의 운영 매뉴얼을 참조하며 텍스트 에디터 등으로 CSV를 「올바른 형식」으로 수동 수정하고 배치를 재실행했습니다.

이러한 「운영으로 커버」하던 업무를 AI로 대체하려고 시도하는 순간, 현장은 "매뉴얼에 없는 예외 패턴이 너무 많다", "담당자가 그 자리에서의 직관이나 경험으로 임의로 판단하여 복구해 왔다"라는 현실에 직면하게 됩니다.

즉, 지금까지 「운영 대응」이라는 이름의 장인 정신에 맡김으로써 사양화(Specification) 비용을 계속해서 회피해 온 프로세스를 하나씩 파헤치고 있기 때문에, 초기 사양이 모호해지고 업무 분석에 막대한 리소스가 발생하는 것입니다. 구조적으로는 설계 시의 "운영으로 커버합시다"를 AI를 사용하여 시스템화(속임수)하려고 하는 것에 불과합니다.

사전 스코프(Scope) 정의나 예외 처리 설계가 불충분한 상태에서 LLM의 "그럴듯한 유연성"에 의존하여 출시된 시스템은, 운영 개시 직후부터 비참한 유지·보수 비용을 계속해서 지불하게 됩니다.

LLM에 읽히는 이메일이나 서류 형식은 거래처의 변경이나 운영의 변화에 따라 쉽게 변동됩니다. 이전까지는 문제없이 처리할 수 있었던 패턴이 미세한 문맥의 변화나 미지의 패턴에 의해 오판을 일으키는 순간, 시스템은 침묵하거나 폭주합니다. 그때마다 프롬프트(Prompt) 미세 조정이나 재검증 같은 "끝없는 튜닝"에 엔지니어의 시간이 녹아내립니다.

거시적인 관점에서 보면, 이는 과거 90년대 후반에 VB6(Visual Basic 6.0)나 Excel 매크로(VBA) 등을 사용하여 각 기업이 현장 주도로 구축했던 「간편한 개별 최적화 도구」의 현대판 그 자체입니다.

당시 아무도 전체 아키텍처(Architecture)를 관리하지 않고, "임시방편으로 돌아가는 편리한 도구"를 블랙박스(Black box) 상태로 양산한 결과, 기업은 나중에 막대한 레거시 시스템(Legacy system) 쇄신 비용을 지불하게 되었습니다.

우리는 지금 Python과 LangChain, 그리고 프롬프트라는 「인간에게는 블랙박스인 자연어 로직」을 사용하여, 완전히 똑같은 역사(레이와의 VB6 스파게티)를 더욱 대규모로, 더욱 고액의 API 이용료를 해외에 지불하면서 반복하려 하고 있습니다. 이것이 파일럿 단계(Pilot phase)에서 실운용으로 이행하지 못하는 많은 기업의 정체입니다.

하지만 이러한 시스템 구조와 과제의 본질(AI 붐 이면에 있는 요구사항 정의로부터의 도피)을 냉철하게 이해하고 있는 엔지니어에게는, 이곳이야말로 가장 가치 높은 제안을 할 수 있는 영역입니다.

AI 기술의 특성(불확실성)을 올바르게 이해하고, 기존의 견고한 시스템과 인간의 업무 사이에 「안전하게 착륙시키는 설계」를 수행하기 위해서는, 다음과 같은 두 가지 접근법을 철저히 적용하여 요구사항을 명확히 구분해야 합니다.

AI의 처리 범위(Scope)를 철저하게 좁히기:

「복잡한 문맥 해석」이나 「AI에 의한 자율적인 업무 판단」과 같은 꿈의 자동화에서는 일단 내려옵니다. AI에게 맡길 태스크(Task)는 패턴이 정해진 데이터 분류나 입력 포맷의 CSV 변환 등, 확실성이 높은 「한정적인 처리」로 요구사항 정의 단계에서 완전히 깎아냅니다. -
「Human-in-the-loop (인간의 개입)」를 처음부터 포함하기:

AI의 판단 신뢰도가 일정 기준을 밑돌 경우, 혹은 미지의 예외 패턴을 감지한 경우에는 시스템 측에서 강제로 처리를 진행하지 않고, 즉시 에러로 처리하여 멈춘 뒤 인간에게 에스컬레이션(Escalation)하는 안전한 업무 플로우를 처음부터 설계에 포함합니다.

최첨단 도구를 사용하여 「고객 유치 놀이」나 「자동화 놀이」라는 어트랙션(Attraction)에 시간과 돈을 낭비하는 것을 그만두고, 과거의 부채를 직시하는 것.

애매한 업무를 애매한 AI에 통째로 맡기는 것이 아니라, 어디까지를 명확히 구분하고 어디서부터를 인간에게 맡길지를 뺄셈을 통해 결정할 수 있는 설계자야말로, 현재 시장에서 확고한 신뢰를 얻고 프로젝트를 진정한 성공으로 이끌 수 있습니다.