3.3.1 원칙 1: 원자성(Atomicity) - 단일 책임 원칙(SRP)의 무자비한 적용

정통 객체지향 소프트웨어 공학의 가장 위대하고 오래된 격언 중 하나인 **‘단일 책임 원칙(Single Responsibility Principle, SRP)’**은 단순히 자바(Java) 클래스 아키텍처나 MSA(Microservices Architecture) 설계에만 국한되는 것이 아니다. 이 원칙은 안갯속을 걷는 듯 예측 불가능한 AI 모델을 통제하기 위해 우리가 구축하는 ‘결정론적 정답지(Deterministic Oracle Ground Truth)’ 파이프라인 설계에 가장 첫 번째로, 그리고 가장 무자비하게 적용되어야 할 핵심 공학 패러다임이다.

엔터프라이즈 AI 테스트 데이터셋에서 정답지의 **원자성(Atomicity)**이 뜻하는 바는 명확하다. 정규표현식(Regex)이든 JSON 스키마든 간에, **“하나의 평가 기준 단위(Unit Test Case)는 오직 단 하나의 쪼갤 수 없는 논리적 명제(Single Logical Proposition) 팩트만을 참(True)과 거짓(False)으로 검증해야 한다”**는 기계적인 원칙이다.

오늘날의 거대 언어 모델(LLM)은 뛰어난 유창함으로 한 번의 긴 자연어 응답 안에서 여러 가지 사실을 동시에 기술하거나, A를 한 뒤 B를 하고 C로 요약하는 복합적인 태스크(Multi-step Task)를 수행하는 경우가 대부분이다. 이때 MLOps 아키텍트가 검증 오라클(Oracle) 파이썬 스크립트에 여러 개의 채점 조건을 하나의 거대한 정규식이나 프롬프트 덩어리로 뭉뚱그려 평가하게 설계하면, 테스트 파이프라인의 ’에러 측정 해상도(Error Resolution)’가 치명적으로 뭉개지는 재앙이 발생한다.

1. 얽히고설킨 스파게티 정답지의 문제점: 부분적 실패의 모호성(Ambiguity)

만약 프로덕션 사용자(User)가 사내 금융 챗봇에게 "어제 삼성전자의 아침 시가와 오후 종가를 표(Table)로 예쁘게 그려서 정리하고, 이를 바탕으로 내일 투자 의견 세 줄 요약해 줘"라고 복합적이고 다면적인 질의(Multi-intent Query)를 던졌다고 가정해 보자.

경험 없는 주니어 프롬프트 엔지니어 혹은 비전문가가 라벨링 툴에서 엑셀로 기입한 잘못 설계된 비원자적(Non-atomic) 스파게티 정답지는 대개 다음과 같은 한 줄 형태의 평가 기준을 띤다.

[Bad Ground Truth]:
{ "expected_answer": "결과물 텍스트 안에 어제 시가는 70,000원이고, 오후 종가는 75,000원이라는 팩트가 있어야 하며, 이 두 숫자는 반드시 마크다운 표 형식 범주 안에 출력되어야 하고, 마지막 하단의 투자 의견은 '강력 매수'라는 긍정적 뉘앙스를 포함해야 함." }

이런 끔찍하게 얽힌 다중 조건 정답지를 야간 빌드 CI 오라클 파이프라인에 통과시켰을 때, 결과가 FAIL(0점)로 붉게 떨어졌다고 치자.
비상 알림을 받고 새벽에 일어난 MLOps 엔지니어는 시스템 대시보드만 보고서는 모델이 1) 아침 시가 데이터를 DB에서 잘못 가져왔는지, 2) 데이터는 맞았는데 표(Table) 포맷팅 그리기를 실패했는지, 3) 아니면 전부 다 잘해놓고 마지막 투자 의견을 ’매도’로 오판했는지 즉각적으로 전혀 알 길이 없다.

정확한 장애 지점을 디버깅(Debugging)하기 위해서는 결국 피곤한 인간 개발자가 터미널을 열고 수만 줄의 날 것(Raw) 로그 텍스트를 눈으로 일일이 읽어보며 추론해야 한다. 이는 철저히 자동화되어야 할 CI/CD 품질 관리(Quality Assurance) 파이프라인의 공학적 의미가 완전히 붕괴하였음을 의미한다.

2. 원자적 정답지의 분해(Decomposition): 검증 파이프라인 해상도의 극대화

단일 책임 원칙(SRP)과 원자성 원칙을 차갑게 적용하면, 아키텍트는 저 뭉뚱그려진 단일 사용자 질의에 대해 데이터베이스 단에서부터 4개의 완벽히 독립된(Isolated and Independent) 마이크로 정답지(Micro Ground Truths) 객체 로우(Row)로 파편화하여 분리 설계해야 한다.

[Atomic Metric 1 - 시가 팩트 검증 (Fact Integrity)]:
“응답 JSON 파생 필드 혹은 텍스트 내에 시가: 70000이라는 수치 데이터가 구조적으로 정확히 존재하는가?” (True/False)
[Atomic Metric 2 - 종가 팩트 검증 (Fact Integrity)]:
“응답 JSON 파생 필드 혹은 텍스트 내에 종가: 75000이라는 수치 데이터가 구조적으로 정확히 존재하는가?” (True/False)
[Atomic Metric 3 - UI/UX 렌더링 무결성 검증 (Format Compliance)]:
“응답 텍스트 블록 전체 내에 Markdown Table 파싱을 위한 |---|---| 정규표현식 패턴이 시각적으로 존재하는가?” (True/False)
[Atomic Metric 4 - 의미론적 추론 검증 (Semantic Alignment)]:
“도출된 텍스트 결괏값을 다시 경량 분류 모델(Classifier Oracle)에 넣었을 때, 그 결과 클래스가 ‘Buy(매수)’ 범주에 속하는가?” (True/False)

평가 로직을 이렇게 원자(Atom) 단위로 쪼개어 CI 서버에 올리게 되면, 릴리즈 당일 오라클 시스템 대시보드는 멍청한 FAIL 하나를 띄우는 것이 아니라, **“Metric 1, 2, 4는 무결점으로 PASS 하였으나, Metric 3(표 렌더링)에서만 FAIL이 발생함”**이라는 의사가 긋는 메스처럼 정밀하고 핀셋 같은 에러 리포트 트래킹(Error Tracking)을 지라(Jira) 티켓으로 자동 발행할 수 있다.

이처럼 결정론적 정답지가 극한의 원자성을 획득할 때, 개발팀의 리더는 “오늘 최신 프롬프트 업데이트 이후 우리 금융 에이전트의 데이터 추출 인식률은 놀랍게도 99% 유지되었으나, 표를 그려주는 마크다운 포맷팅 프레젠테이션 능력이 15% 하락했다“라는 정확한 파이프라인 증상 분석 수치를 얻게 되며, 이는 회의할 필요도 없이 곧바로 파이썬 포맷터(Formatter) 쪽의 빠르고 정확한 핫픽스(Hotfix) 코드 배포로 직결된다.

오라클의 채점 기준 정답지는 서툰 문학도가 쓰는 길고 서술적인 소설이 되어서는 절대 안 된다. 그것은 오직 기계가 단 한 줄의 정규식이나 ASSERT 문으로 완벽하고 독립적으로 참(True)과 거짓(False)을 수학적으로 판별해 낼 수 있는, 가장 차갑고 단단한 단일 논리 원소(Atomic Elements)들의 모음집이어야만 한다.