먼저 밝혀둔다. 이 글에 쓰는 것은 나의 관점에서 본 소프트웨어 개발의 구조다. 여기에 기재된 내용이 객적으로 옳다고 주장하는 것이 아니다. 나에게는 이렇게 보였고——그 보이는 방식에 따라 L2A-SCP의 구조가 결정되었다. 따라서 본고는 "이것이 옳다"라는 주장이 아니라, "나에게는 이렇게 보여서 이렇게 만들었다"라는 설계 유래에 대한 설명으로 읽어주길 바란다. 진실은 따로 있겠지만, 내가 그 진실에 도달했다는 이야기는 아니다. 참고로 나는 L2A-SCP를,

AI 소프트웨어 파운드리(Software Foundry)를 위한 제조 라인으로 파악하고 있다. 본고는 그중 라인 내부의 공정 설계——왜 공정(단계)을 이렇게 나누는지——를 설명한다.

이전 글 「AI에게 '사양대로'의 산출물을 만들게 한다 ── L2A-SCP를 V-모델(V-model)로 읽기」에서는 L2A-SCP가

SPEC → UC → RBA·SEQA → RBD·SEQD → DD → TS → TC → SRC

라는 다단계 중간 산출물을 경유한다는 것을 구조로서 보여주었다. 하지만 거기서는 "왜 이 단계 수인가"를 주어진 것으로 취급했다. 본 기사는 그 한 점만을 상당히 추상도를 높여 파고든다. 결론부터 말하자면, 단계가 많은 것은 체크포인트를 늘리고 싶어서가 아니다. SPEC에서 SRC로 이어지는 긴 변환을, 한 단계당의 도약이 의미를 훼손하지 않을 만큼 짧게 나누고 있기 때문이다.

소프트웨어 개발이란, 의미를 유지한 문서의 연속 변환이다

먼저 발판을 하나 놓겠다. 소프트웨어 개발이란 무엇인가. 나는 이렇게 정의한다.

SPEC에서 SRC에 이르기까지, 어떠한 의미를 유지하면서 사람이 형태를 변화시켜 가는 작업.

입구(SPEC)와 출구(SRC)는 형태가 완전히 다르다. 한쪽은 자연어에 가까운 요구 기술(Requirement Description)이고, 다른 한쪽은 기계가 실행하는 결정론적(Deterministic)인 코드다. 형태는 다르지만, 전달해야 할 의미는 같아야 한다. 도중에 상류에서 정당화할 수 없는 의미가 늘어나서는 안 되며, 상류에 있던 의미가 이유 없이 줄어서도 안 된다 (타입, 경계 API, 에러 분류와 같은 구현상의 의미는 도중에 정당하게 늘어날 수 있다. 문제는 "늘어나는 것"이 아니라, 상류로부터 근거를 부여받지 못한 채 늘어나는 것이다). 개발이란, 이 "형태를 바꾸면서 의미를 유지하는" 변환의 연쇄라고 파악한다.

이 관점을 취하면, 품질 문제는 "좋은 코드를 어떻게 쓸 것인가"가 아니라, "변환 도중에 의미가 깨지지 않게 하려면 어떻게 해야 하는가"로 옮겨간다. L2A-SCP의 단계 구성은 이 질문에 대한 답으로서 설계되어 있다.

할루시네이션의 발생 원인을 확률적 사고가 아닌 '거리'로 보기

먼저 용어의 범위를 정해두겠다. 여기서 말하는 할루시네이션(Hallucination)은 이른바 사실 오인(Factual Hallucination)뿐만 아니라, 상류에 근거가 없는 설계 보완——AI가 멋대로 타입, 클래스, 예외 방침 등을 "그럴싸하게" 채워 넣는 것——도 포함하여 지칭한다.

LLM의 할루시네이션은 보통 **확률적인 사고(Probabilistic Accident)**로 취급된다. 모델이 분포가 좋지 않은 쪽을 뽑았다고 말이다. 그래서 대처도 대증요법이 된다——프롬프트를 궁리하거나, 온도를 낮추거나, 검색으로 보강하거나, 후단에서 팩트 체크를 하는 것 등이다. 이것들은 모두 "왜 일어났는가"라는 구조에는 파고들지 않는다.

L2A-SCP에서 나는 할루시네이션을 한 단계 더 아래에서 구조적인 현상으로 파악하고 있다.

의미적 거리가 긴 변환은 그 사이를 "그럴싸한 보완"으로 채우려 한다. 그 보완은 원래의 의도에서 괴리되기 쉽다. 그것이 할루시네이션으로 표출된다.

여기서 유효한 것은, 이것은 AI 고유의 현상이 아니다라는 관찰이다. 인간 설계자도 요구사항에서 구현으로 단번에 뛰어내릴 때, 그 사이를 암묵지(Tacit Knowledge)로 채운다. 경험이 풍부하면 보완이 대체로 맞기 때문에 문제가 표면화되지 않을 뿐, 경험이 얕으면 잘못된 보완을 한다. 인간의 경우 이는 "경험 부족" 혹은 "암묵지 결여"로서 개인의 능력 문제로 귀결되어 왔다. AI에서 동일한 현상이 일어나면 "할루시네이션"으로서 재발견된다. 하지만 일어나고 있는 현상은 같다——거리가 긴 변환에서는 보완이 필요하며, 보완은 틀리기 쉽다.

내가 20여 년 전에 "암묵지의 배제"로서 시작한 노력은, 현대의 언어로는 "할루시네이션 억제"라고 부르는 것과 동일한 현상을 가리키고 있었다. 그렇다면 처방전도 같다. 프롬프트 궁리도 검색 확장도 아닌, 변환의 각 단계를 의미적으로 근접하게 만드는 것. 거리가 길기 때문에 보완이 필요한 것이라면, 거리를 좁히면 된다.

'거리'란 무엇인가 ── 차원 변환의 양

그렇다면 "의미적 거리"란 구체적으로 무엇의 거리인가. 이 부분이 본 기사의 핵심이다.

UC(Use Case)는 본질적으로 1차원이다. "액터가 무엇을 하고, 시스템이 어떻게 응답하는가"라는 시계열적·문장적 흐름으로 선형적으로 나열되어 있다. 반면, 상세 설계(Detailed Design)는 다차원이다. 책임을 가진 요소들이 공간적으로 배치되어 서로를 참조하는 구조로 되어 있다.

이 두 사이에는 **차원 변환 (Dimension Transformation)**이 필요하다. 1차원의 의미 기술을 다차원의 책임 공간으로 사상(Mapping)해야 한다. ICONIX의 로버스트니스 다이어그램(Robustness Diagram)은 바로 이 변환기다. "주어 추출"과 "책임 분해"라는 두 가지 조작을 통해, 선형적 기술을 공간 배치로 끌어올린다. Boundary / Control / Entity의 삼분류는 추출한 주어를 공간에 배치하기 위한 좌표계에 해당한다.

그리고 결정적인 것은, 이 변환의 거리는 균일하지 않다는 점이다. 동일한 "SEQ $\rightarrow$ DD"라는 한 단계 안에서도 성질이 다른 조작이 혼재되어 있다.

거리란, 요컨대 그 단계에서 의미가 얼마나 변화하는가이다. 기계적인 변환(정보를 추가하지 않는 변환)은 거리가 짧고, 할루시네이션 (Hallucination)의 여지가 작다. 의미를 도입하는 변환은 거리가 길고, 여지가 크다. "자신을 가질 수 없는 단계"는 대개 이러한 긴 조작과 짧은 조작이 한 단계에 섞여 있어, 거리를 일괄적으로 평가할 수 없을 때 발생한다.

거리의 척도 ── 사원소 (주어 · 책임 · 경계 · 예외)

여기서 솔직하게 적어둔다. 나는 처음부터 "거리"를 재는 척도를 가지고 있었던 것이 아니다. 단계를 먼저 배치할 수 있었던 것이다. "이곳은 할루시네이션이 일어나지 않는 거리다"라는, 언어로 표현되기 전의 감각(위화감)으로 말이다. 배치할 수 있었다는 것과, 왜 배치할 수 있었는지를 설명할 수 있는 것은 별개의 문제다. 척도는 나중에, 배치해 버린 현상을 설명하기 위해 요청된 것이다.

그 척도가 바로 내가 소프트웨어 개발에서 항상 쫓고 있는 네 가지 요소였다.

이 사원소(Four Elements)로 다시 말하면, 두 가지 질문에 답이 나온다.

의미적 거리란 무엇인가 ── 사원소의 변화량이다.

할루시네이션이 일어나지 않는다는 것은 무엇인가 ── 사원소가 한 단계 내에서 다룰 수 있는 범위 안에 들어오는 것이다.

네 가지 중, 책임(Responsibility)이 핵심에 자리한다. 이유는 "책임이 가장 중요하기 때문"이 아니다. 더 구조적이다. 사원소 중 책임만이 출구에서 외부로 고정된다. 테스트가 통과된다, 즉 적어도 관측 가능한 책임은 SRC에 존재한다. 책임의 유지에는 테스트라는 고정 장치가 있다(테스트가 고정하는 것은 관측 가능한 책임이지, 책임의 전부가 아니라는 점에는 유보가 필요하다). 주어 · 경계 · 예외의 유지에는 그에 상응하는 외부의 고정 장치가 (적어도 지금은) 없다. 즉 책임은 사원소 중 가장 외부로부터 유지의 타당성을 검증하기 쉽다 $\Rightarrow$ 관측의 발판을 가진 원소인 것이다. "의미를 유지하며 변환한다"의 "유지"를 검증 가능한 형태로 측정할 수 있는 것은, 현재로서는 책임에 가장 강하게 편중되어 있다는 뜻이 된다.

여기에 본 방법론의 최대 한계도 있다. 이 척도는 객관적인 자(Ruler)가 아니다. 사원소는 사후에 세운 설명 가설이며, "한 단계 내에서 다룰 수 있는 범위인가"에 대한 최종 판단은 결국 나의 위화감이 담당하고 있다. 의미적 거리를 외부에서 기계적으로 측정하는 수단(임베딩 벡터(Embedding Vector), 책임 관계의 형식화 등)은 아직 연구 중인 미결 과제다. 본 기사는 "거리로 생각한다"라는 **프레임워크 (Framework)**를 제시하는 것이지, 거리를 자로 잴 수 있다고 주장하는 것이 아니다. 이 점을 과신하지 말기를 바란다.

그래서 다단계가 된다

이상을 종합하면, L2A-SCP의 단계 구성 이유가 나온다.

SPEC $\rightarrow$ SRC

를 단번에 변환하면 거리가 너무 길다. 사원소를 한 단계 내에서 다룰 수 없으므로 AI(또는 인간)가 그 사이를 보완하게 되고, 그 보완이 할루시네이션이 된다. 그래서 긴 변환을, 각 구간이 한 단계 내에서 다룰 수 있는 거리에 들어오도록 나눈다. 그것이 중간 산출물이다.

중간 산출물은 관료적인 체크포인트가 아니다. 긴 차원 변환에, 의미를 유지할 수 있는 간격으로 칸막이를 넣어둔 것이다. 칸막이의 위치는 "사원소가 이 구간이라면 다룰 수 있다"라는 거리 판단에 의해 결정된다.

구체적인 예를 하나 들겠다. "사용자가 설정 파일을 지정한다. 존재하지 않으면 에러로 처리한다"라는 작은 UC가 있다고 가정하자. 이를 갑자기 SRC로 떨어뜨리면, AI는 FileLoader

・ConfigRepository

・DefaultConfigProvider

・예외 유형·로그 방침…… 등으로 보완하기 시작한다. 모두 "설계로서 그럴듯해" 보이지만, 상류에 근거가 없다——장거리를 단번에 뛰어넘은 만큼을 그럴싸함으로 메운 결과다. L2A-SCP는 이 판단을 짧은 거리로 나눈다. 먼저 Boundary / Control / Entity로 나누어 주어를 세우고, 책임을 RBA에 두며, SEQA로 상호작용을 확인하고, RBD/SEQD로 구체적 책무로 옮긴 뒤, DD에 이르러서야 비로소 언어 구조와 경계 API로 떨어뜨린다. 단번에 뛰어넘는다면 장거리 보완이 되었을 판단이, 각 단계에서는 "사원소(four elements)를 다룰 수 있는 범위"의 작은 판단으로 분할된다. "거리"라는 추상적인 용어는, 요컨대 이 "한 단계에서 얼마나 멀리 뛰는가"를 의미한다.

단계를 늘리는 제어 장치 ── 무의미한 단계는 방법론을 부패시킨다

다만 "단계는 많을수록 좋다"는 아니다. 이것은 중요한 제어 장치다. 거리를 좁히기 위해 단계를 추가할 수 있다면 끝도 없이 추가하게 될 것이다. 하지만 의미 없는 단계를 늘리면 방법론은 부패한다.

새로운 단계를 추가해도 되는지는 다음 기준으로 판정한다.

ICONIX의 단계(SPEC, UC, RB, SEQ, DD, TS, TC, SRC)가 채택된 이유는, 각 단계가 서로 번역 불가능한 고유한 관점을 제공하기 때문이다. 어느 하나라도 결여되면 나머지 단계로는 보완할 수 없는 정보가 누락된다. 그렇기에 불가분한 것이지, 단계 수가 많아서 훌륭한 것이 아니다.

하강에도 형태가 있다. 추상에서 구체로 내려갈 때는, 가급적 직선으로 하강하며, 옆으로 흔들리지 않아야 한다. 방향을 바꿔도 되는 것은 합류점——새로운 상류의 의도가 경로에 주입되는 지점——에 한한다. 단일 경로의 도중에 방향이 바뀌는 것은 부정한 드리프트(drift)다. 의미의 흐름에는 관성이 있다. 급커브를 틀면 전 단계의 의미가 다음 단계로 완전히 통합되지 못하고 흘러넘치게 된다. 흘러넘친 부분이 보완으로 메워지며, 그것이 할루시네이션(hallucination)이 된다.

그리고 실무적으로는, 설명할 수 없는 단계는 유지보수 시 삭제 후보가 된다. "왜 이 단계가 존재하는가"를 구조적으로 답할 수 없는 방법론은 비판을 받으면 무너진다. 단계의 정당성은 앞서 언급한 네 가지 기준에 의해 항상 설명 가능해야 한다.

왜 지금 이것이 성립하는가 ── AI의 빠른 생성 속도가 과도한 비용을 흡수한다

거리를 좁히기 위해 단계를 두텁게 만드는 것은 비용이 높다. 중간 산출물이 늘어나면 그만큼 쓰는 수고도 늘어난다. 이것은 역사적으로 워터폴(Waterfall) 모델이 기피되었던 이유 그 자체다——각 단계를 정성스럽게 다지는 엄밀함은, 재작업과 작업량 측면에서 과도한 비용이 되어 수지가 맞지 않았다.

이 지점을 반전시키는 것이 AI다. AI의 생성 속도는 인간보다 차원이 다르게 빠르다. 따라서 단계를 세밀하게 나눔으로써 발생하는 과도한 비용을, AI의 빠른 생성 속도가 흡수한다. 각 단계를 얇게 나누더라도 작업 시간 측면에서는 허용 범위 안에 들어온다. 이전 글에서 "재실행 가능한 V자"라고 부른 것은 이와 같은 사정의 다른 측면이다——하류의 산출물을 한 단계 분량만큼 다시 만드는 수고가 AI를 통하면 거의 무시할 수 있을 정도로 작아진다. 그렇기에, 중간 산출물을 잘게 나누는 엄밀한 공정——본래라면 재작업 비용이 높게 들었을 다단계 프로세스——에서도 필요하다면 몇 번이고 반복하며 돌릴 수 있다.

다만 거듭 말하지만, 빨라졌다고 해서 무턱대고 단계를 추가해서는 안 된다. AI의 빠른 생성 속도는 과도한 비용을 흡수할 뿐, 단계를 늘리는 것 자체를 정당화하지는 않는다. 정당화는 어디까지나 앞서 언급한 네 가지 기준과 직선 하강의 규율이 담당한다.

프로세스가 먼저, 툴은 나중 ── legixy의 위치

마지막으로, 거리 이야기와 추적 가능성(traceability)의 관계를 짚어둔다.

순서가 중요하다. 프로세스가 먼저 존재하며, 툴은 나중에 그것을 유지하기 위해 만들어졌다. 단계를 나누어 거리를 좁히더라도 각 단계에서의 일탈을 제로로 만들 수는 없다. 좁혀진 거리 안에서 발생하는 **작은 드리프트(drift)**를 포착할 장치가 필요하다. legixy(추적 엔진)는 모든 산출물을 유향 그래프(directed graph)화하고, 그 잔차를 검출하기 위해 만들어졌다.

즉 두 바퀴로 움직인다. 거리를 좁힌다(프로세스) / 좁혀진 거리 내의 일탈을 검출한다(툴). 한쪽만으로는 효과가 없다. 거리를 좁히지 않으면 검출해야 할 일탈이 너무 커서 감당할 수 없고, 검출이 없다면 좁힌 거리의 효과를 끝까지 끌어낼 수 없다.

이 순서에는 운용상의 이점도 있다. legixy가 무언가를 검출하지 않았을 때, 그것이 "툴의 성능 부족"인지 아니면 "애초에 프로세스로 커버해야 할 범위를 벗어난 것"인지를 프로세스라는 독립된 기준에 비추어 판정할 수 있다. 툴이 먼저 존재하는 방법론에서는 이것이 불가능하다. 툴이 검출하는 범위가 어느샌가 프로세스의 정의가 되어버리기 때문이다.

현재 위치와 그 다음 ── 임베딩 거리에서 책무 거리로

「좁혀진 거리 내의 일탈을 검출하는 눈」이 지금 무엇을 보고 있으며, 다음에 무엇을 보고 싶어 하는가. 이 부분은 본고의 사정(射程)의 외연이므로, 현재 위치와 방향만을 솔직하게 적어둔다.

현재: ONNX 형식의 임베딩 모델로 의미적 거리를 감시하고 있다. 인접한 산출물 사이의 **의미적 거리 (Semantic Distance)**를 임베딩 모델(ONNX 형식의 문장 임베딩. 예: all-MiniLM-L6-v2)로 벡터화하여 측정하고, 그 일탈—세만틱 드리프트 (Semantic Drift)—를 감시하고 있다. "상류의 산출물과 하류의 산출물이 의미적으로 얼마나 멀어졌는가"를 수치로 지켜보는 메커니즘이다. 거리를 좁힌 뒤에도 남는 작은 어긋남을 포착하는 현실적인 방책이 되고 있다.

다만 임베딩이 측정하는 것은 표층적인 의미의 근접성일 뿐, 본고에서 핵심으로 둔 책무 (Responsibility) 그 자체는 아니다. 기억해 주길 바란다—관측 가능한 책무는 테스트를 통해 "출구 (SRC)"에서만 외부적으로 고정된다. 즉, 변환의 도중에는 책무가 아직 관측할 수 있는 발판을 갖지 못한다. 의미적 거리는 책무 일탈의 **대리 지표 (Proxy Indicator)**는 될 수 있지만, 책무 자체의 일탈을 직접 보고 있는 것은 아니다.

다음: CST를 통해 변환 도중의 책무 일탈을 감시하고 싶다. 그래서 다음에 목표로 하는 것이 변환 과정 중에 책무의 일탈을 직접 감시하는 것이다. 그 후보가 바로 CST—여기서는 프로그래밍 문맥에서 혼동하기 쉬운 구문 트리 (Concrete Syntax Tree)가 아니라, **개념 공간 이론 (Conceptual Spaces Theory)**이다.

CST (개념 공간 이론)란: Peter Gärdenfors가 제창한, 개념을 기하학적으로 다루는 프레임워크. 개념을 "질적 차원 (Quality Dimensions)"이 형성하는 공간 내의 볼록 영역 (Convex Region)으로 나타내며, 개념 간의 유사함/멀어짐을 해당 공간 내의 거리로 측정한다. 기호도 아니고 생(raw) 벡터도 아닌, "의미 있는 좌표계 안의 위치"로서 개념을 다룰 수 있다는 점이, 본고의 "차원 변환의 거리"라는 관점과 자연스럽게 맞닿는다.

목표는 책무를 CST 공간 내의 위치로 나타내어, 어떤 단계에서 다음 단계로 내려갈 때 책무가 얼마나 이동·변질·소실되었는지를 공간 내의 이동으로 파악하는 것이다. 그렇게 된다면 테스트를 기다리지 않고—출구에 도달하기 전에—책무의 일탈을 관측할 수 있다. 지금은 출구에만 존재하는 책무의 발판을, 변환 도중에 둘 수 있게 된다.

다만 한계도 솔직하게 적는다. CST가 순수하게 잘하는 것은 수평 방향의 유사성 (동일한 추상도를 가진 개념 간의 근접성)이며, 본고가 문제 삼고 있는 것은 수직 방향—추상에서 구체로 내려가는 차원 변환을 가로지르는 책무의 보존이다. 따라서 CST를 그대로 적용하면 책무 드리프트 (Responsibility Drift)를 측정할 수 있다는 이야기가 아니다. 수직적인 하강을 따라 책무 관계를 추적할 수 있도록 확장할 필요가 있다. 이는 이미 구현된 기능이 아니라, 가능하다면 하고자 하는 방향성이다. "교정될 수 있는 표준화된 자는 아직 손에 없다"라는 한계에 대한 구체적인 공략 지점이 바로 이것이다.

맺음말 ── 다단계는 번거로움이 아니라, 거리의 설계이다

L2A-SCP의 중간 산출물이 다단계인 이유는, 꼼꼼하게 체크하고 싶어서도, 공정을 늘리고 싶어서도 아니다. 소프트웨어 개발이 SPEC에서 SRC로의 차원 변환이며, 그 변환 도중에 의미를 파괴하지 않기 위해서는 어느 한 단계도 "의미를 유지할 수 있는 거리"를 초과해서는 안 된다—이 점에 귀결된다.

L2A-SCP에서 할루시네이션 (Hallucination)이란, 패치로 때워야 할 사고가 아니다. 문서 간의 거리가 멀 때, AI가 그 사이를 메우려다 발생하는 보완이다. 그렇기에 대처법은 모델에 대한 패치가 아니라, 변환의 간격 (거리)을 설계하는 것이 된다. 사원소 (Four Elements)는 내가 그 거리를 측정하기 위해 가져온 척도다 (다만 위화감에 의해 교정되는, 사후적인 척도). 중간 산출물은 그 거리로 긴 변환을 나눈 칸막이이다. legixy는 칸막이로 나눈 구간에 남은 일탈을 감시하는 눈이다. 그리고 전체적인 교정은 최종적으로 만드는 이의 위화감이 담당한다.

교정될 수 있는 표준화된 자는 아직 손에 없다. 하지만 "거리로 생각한다"는 프레임워크는 왜 단계가 필요한지, 어디에 단계를 두어야 하는지, 어디에서 단계를 추가해서는 안 되는지를 구조로서 설명할 수 있다. 다단계는 그 구조의 시각화이다.

마지막으로, 서두의 비유로 돌아가겠다. 나는 L2A-SCP를 AI 소프트웨어 파운드리(Software Foundry)의 일종으로 파악하고 있다(반도체 파운드리에 비유한 관점이다). 이 비유를 빌리자면, 본고에서 지금까지 다루어 온 "거리를 설계하고, 긴 변환을 의미를 유지할 수 있는 짧은 길이로 한 단계씩 나누는" 이야기는 제조 라인 자체의 품질을 높이기 위한 고안——라인 상의 각 공정(작업자)이 잘못된 보완을 하지 않도록 하는 내부적인 규율——에 해당한다.

하지만 파운드리는 라인 규율만으로 신뢰성을 확보하는 것이 아니다. 품질 관리(Quality Control)·품질 보증(Quality Assurance) 체계에 의한 외부 감시 구조를 별도로 갖추고, 그것과 결합되어야 비로소 출하 가능한 품질에 도달한다. L2A-SCP 도 마찬가지다. 거리 설계로 라인을 조인 데다, 게이트(Gate)·독립 리뷰어 층(Independent Reviewer Layer)·AT·PAI(독립 주체에 의한 블랙박스 검사)·추적성(Traceability)과 같은 라인 외부에서 품질을 감시하는 구조를 겹쳐 놓았다. 이전 글에서 다루었던 V자 형태의 우측 팔, 즉 각 레벨에 대응하는 검증이 바로 이 외부 감시에 해당한다. L2A-SCP가 신뢰성을 주장할 수 있는 것은, 이 내부(라인 규율)와 외부(감시 구조)가 모두 갖춰졌을 때뿐이다. 본고에서는 그중 내부적인 측면인 "왜 단계가 필요한가"를 거리로 설명했다. 외부의 감시 구조에 대해서는 다음 글에서 다루겠다.

Discussion