LLM에게 기술 문서를 주고 작업 일정을 YAML로 뽑아 달라고 하면 처음 몇 번은 그럴듯하게 나온다. 그러다 어느 날 작업 하나가 빠지거나 대기 시간이 바뀐 채로 나오는데 형식은 멀쩡해서 파서도 통과하니 틀린 일정이 그대로 다음 단계로 넘어간다. 같은 입력에도 매번 다른 답을 내놓는 부품을 시스템 한가운데 두면 이런 사고를 피할 길이 없다.
Information and Software Technology(IST) 저널의 특별호 「Software Architecture for AI-Driven Systems: Challenges and Emerging Solutions」는 이 문제를 아키텍처 관점에서 다룬다. 이제 AI는 시스템 바깥에 붙이는 부가 기능이 아니라 핵심 구조와 동작의 일부가 되었으니 학습하는 부품과 적응형 제어 루프, 데이터 파이프라인을 한데 품으려면 아키텍처도 달라져야 한다는 문제의식에서 출발한 호다.
이번 호에는 우주선 작업 일정과 철도 신호, 코드 리뷰, 수어 인식, 농작물 추천까지 폭넓은 주제의 논문 13편이 실렸다. 그중 본문이 공개된 3편을 끝까지 읽고 나머지 10편은 초록을 살폈는데 다루는 분야가 제각각인데도 여러 편이 닮은꼴 설계를 택했다. 사람의 말을 기계가 읽을 형태로 옮기는 일까지만 LLM에게 맡기고 최종 판단은 언제나 같은 답을 내는 결정론적 부품에 넘기는 구조다.
WS-Line, 자연어는 LLM이 옮기고 일정은 솔버가 짠다
WS-Line은 우주선 탑재 컴퓨터의 작업 일정을 짜는 도구다. 작업마다 걸리는 시간과 쓰는 자원이 다르고 어떤 작업은 선행 작업이 시작된 뒤 정해진 시간이 지나야만 돌아갈 수 있는데 이런 조건들이 사람이 읽는 기술 문서에 자연어로 흩어져 있다. 현장 전문가들이 이 문서를 읽고 작업 순서를 손으로 정의해 검증하려면 길게는 이틀이 걸린다.
WS-Line은 문서를 곧장 일정으로 바꾸지 않는다. 먼저 LLM이 RAG(문서에서 관련 대목을 찾아 프롬프트에 붙이는 방법)로 찾은 근거를 바탕으로 WorkSched-DSL이라는 YAML 형식의 명세를 채우고 이 명세가 스키마에 맞지 않으면 오류 메시지와 함께 LLM에게 되돌려 정해진 횟수 안에서 고치게 한다. 검증을 통과한 명세는 스크립트가 제약 최적화 문제(CSOP)로 변환한 뒤 솔버가 최종 일정을 계산한다. 실행 가능성 검사와 최적화는 반드시 정형 스케줄링 계산(“a formal scheduling computation”)에 맡긴다는 것이 이 논문의 설계 원칙이다.
문서 15개로 10번씩 만든 명세 150개는 모두 문법 검사를 통과했고 이 명세로 계산한 일정 150개도 정답 명세에서 나온 일정과 전부 일치했다. 반대로 같은 문서를 gpt-5.5에 주고 MiniZinc 스크립트를 바로 짜게 한 비교 실험에서는 10번 중 8번이 실행조차 되지 않았고 나머지 2번도 틀린 일정이 나왔다. 더 새로운 모델에 일을 통째로 맡긴 쪽이 역할을 나눈 파이프라인보다 오히려 참담한 결과를 낸 셈이다.
물론 솔버가 아무리 정확해도 건네받은 명세 자체가 문서와 어긋나면 형식만 맞고 내용은 틀린 일정이 나올 수밖에 없다. 문서에 애초부터 빠진 정보는 뒤 단계의 어떤 검사로도 되살릴 길이 없기 때문이다. 그래서 WS-Line은 추출을 시작하기 전에 필수 항목이 문서에 들어 있는지부터 확인하고 빈칸이 있으면 사람에게 먼저 묻는다.
LLM 옆에 결정론적 근거를 붙인 세 논문
철도 신호 논문은 유럽 철도 표준 ERTMS/ETCS의 운행 시작 절차를 다룬다. 설계 단계에서 그려 둔 절차 모델과 실제 코드가 따로 있을 때 실행 중인 코드가 모델과 다르게 흘러가면 이상 신호로 봐야 한다. 이를 잡으려면 코드 곳곳에 로그를 심어야 하는데 설계 모델의 각 단계가 실제 코드의 어느 줄에 해당하는지 짝짓기가 까다로워 이 연결 작업만 LLM에게 맡긴다. 전체 파이프라인에서 LLM이 개입하는 대목은 이 계측 단계 하나뿐이다.
실제 이상 여부를 판정하는 일은 실행 기록을 설계 모델에 겹쳐 보며 어긋난 지점을 찾는 적합성 검사(conformance checking)의 몫이다. 이 기법을 쓰면 어느 단계에서 절차가 틀어졌는지 정확히 짚어 낼 수 있다. 실험 결과 LLM이 심은 로그는 모델 흐름의 최대 82.849%를 덮었고 이상 탐지 성능은 F1 95.957%를 기록했다.
코드 리뷰 논문은 제조 실행 시스템(MES)처럼 애플리케이션 코드와 데이터베이스 동작이 복잡하게 얽힌 환경을 겨냥한다. 메서드와 데이터베이스 부작용을 잇는 의존성 그래프를 결정론적 분석으로 먼저 만들고 이를 AI 리뷰어에게 판단 근거로 건네는 방식이다. 3개월 동안 실제 PR 342건에 시범 적용한 결과 기존 파이프라인이 놓쳤던 고위험 취약점 20건을 잡아냈고 정밀도는 87.0%에 달했으며 평균 리뷰 반복 횟수도 2.4회에서 1.1회로 줄었다.
스스로 설정을 바꾸는 자가 적응 시스템을 다룬 Falcon 논문도 같은 구조를 따른다. 운영 중인 AI 모델의 예측 확신도가 떨어지면 비슷한 환경에서 학습한 다른 모델로 갈아 끼우는데 어떤 모델로 바꿀지 고르는 일은 환경 조건을 논리식으로 적어 두고 답을 찾는 SMT 솔버의 몫이다.
에이전트가 늘면 로그 형식부터 흔들린다
여러 에이전트가 함께 움직이는 시스템에서는 로그 형식부터 수시로 흔들린다. 어느 날은 agent_id가 actor_id로 이름을 바꾸고 없던 필드가 생겼다 사라지기도 해서 OpenTelemetry처럼 스키마를 미리 못 박아 두는 파이프라인은 규격에서 벗어난 이벤트를 버리거나 일부만 받아들인다. FOAP 논문은 이 문제를 7개 층으로 나눈 관측 아키텍처 패턴으로 풀어냈다.
해법의 핵심은 이중 보관이다. 들어온 이벤트를 원본 그대로 한 벌 저장하면서 표준 형식으로 바꾼 사본을 나란히 두는 방식인데 표준 형식 변환은 Gemini 2.5 Flash 기반의 정규화 에이전트가 맡는다. 이때 출력은 JSON만 내놓도록 묶어 두고 변환에 실패하면 억지로 값을 채우는 대신 parseError 표시를 남긴다.
에이전트 1개가 단순한 이벤트를 보낼 때는 정규화 성공률이 100%였지만 에이전트 2개의 이벤트가 섞이자 93.3%로, 에이전트 3개가 필드가 많은 이벤트를 보내자 90%로 떨어졌다. 그럴듯하지만 틀린 값을 지어내거나 모델 업데이트로 동작이 달라지고 같은 입력에도 다른 출력이 나오는 문제는 LLM 정규화가 피할 수 없는 위험이다. 원본 보관은 바로 그 순간에 기록 유실을 막아 주는 안전망 노릇을 한다.
다만 실험 규모는 자그마하다. 무료 요금제 한도 탓에 에이전트는 최대 3개, 시나리오당 이벤트는 110개까지만 실제 실험을 돌렸고 논문 표에 함께 실린 에이전트 100개 수치는 실측이 아닌 추정치다.
같은 말을 다르게 바꾸면 드러나는 것
DAP 논문은 사용자의 자연어 요청으로 알맞은 API를 찾는 문제를 다룬다. OpenAPI 명세에서 LLM으로 예상 사용자 발화를 뽑아내고 같은 뜻을 여러 표현으로 바꿔 쓴 뒤 그 문장들을 합쳐 API 메서드 벡터를 만든다. 명세 문서만으로 벡터를 만들었을 때보다 검색 성능이 NDCG@10 기준 최대 7.7% 올랐다.
편향 탐지 논문은 반대로 이 말바꾸기를 공격 도구로 썼다. 정해진 템플릿 문장만 넣는 대신 뜻은 같고 표현만 조금씩 다른 문장들로 텍스트 분류 모델 17개를 시험했더니 숨어 있던 편향 예측이 과제에 따라 6~65% 더 드러났다. 고정된 템플릿 앞에서는 편향이 없어 보이던 모델 여럿이 문장 표현을 바꾸자마자 편향을 드러낸 셈이다.
한쪽은 다양한 표현으로 검색기를 튼튼하게 만들고 다른 쪽은 모델의 약점을 들춰내지만 두 실험이 가리키는 사실은 같다. 언어 모델이 들어간 시스템을 고정된 문장 몇 개로만 시험하면 실제 현장에서 마주칠 동작을 가늠할 수 없다는 점이다. 생성형 AI 테스트 연구 37편을 종합한 문헌 리뷰 역시 프롬프트 표현 하나에 결과가 크게 흔들리고 독점 API에 기대고 있어 재현이 어렵다는 점을 공통 한계로 짚었다.
LLM에게 맡길 일과 맡기지 않을 일의 경계
이번 특별호에서 눈에 띄는 논문들은 LLM 자체를 더 똑똑하게 만들기보다 LLM에게 어디까지 맡길지 경계를 긋는 데 공을 들인다. WS-Line은 자연어를 DSL로 옮기는 일까지만 맡기고 철도 모니터는 코드에 로그를 심는 일까지만 맡기며 코드 리뷰는 결정론적 의존성 그래프로 판단 근거를 대 주고 FOAP는 변환 실패에 대비해 원본을 통째로 남겨 둔다. 그런 경계 없이 LLM에게 최적화 스크립트를 처음부터 끝까지 짜게 한 비교 실험이 10번 중 한 번도 정답을 내지 못한 이유가 여기에 있다.
물론 실린 논문들의 실험 규모가 아직 작거나 합성 데이터에 기댄다는 점은 감안하고 읽어야 한다. WS-Line이 시험한 문서 15개 가운데 12개는 다른 LLM이 만든 합성 문서였고 FOAP는 이벤트 110개, 철도 모니터도 프로토타입 하나로만 검증했다. 실제 현장에서 비교적 긴 시간 검증을 거친 연구는 3개월 동안 PR 342건을 다룬 코드 리뷰 논문 정도여서 회의 대화를 업무 기록으로 바꿔 주는 DevNous를 비롯한 나머지 연구들도 대규모 현장 검증은 숙제로 남아 있다.
결국 시스템 한가운데에 LLM을 넣으려 할 때 가장 먼저 던져야 할 질문은 단순하다. 이 모델의 출력이 틀렸을 때 그 오류를 누가 잡아내는가. 솔버든 의존성 그래프든 원본 기록이든 그 대답을 맡아 줄 결정론적 부품이 자리에 없다면 그 일을 LLM에게 맡기기는 아직 이르다.
출처: Software Architecture for AI-Driven Systems: Challenges and Emerging Solutions, Information and Software Technology 특별호. 본문을 읽은 논문은 WS-Line, 철도 소프트웨어 모니터, FOAP이고 나머지는 초록을 참고했다.