1.1.4 로직의 블랙박스화: 개발자가 제어할 수 없는 내부 연산 과정

1.1.4 로직의 블랙박스화: 개발자가 제어할 수 없는 내부 연산 과정

1. 서론: 명시적 제어의 종말과 새로운 연산 패러다임의 도래

1.1 결정론적 세계의 붕괴

컴퓨터 과학의 태동기부터 소프트웨어 공학은 인간의 지성을 기계가 이해할 수 있는 논리적 구조로 환원하는 작업이었습니다. 앨런 튜링(Alan Turing)과 존 폰 노이만(John von Neumann)이 정립한 컴퓨팅의 기초 위에서, 프로그래머는 전지전능한 설계자였습니다. 우리가 작성하는 소스 코드의 모든 라인, 모든 조건문(if-then-else), 모든 루프(for, while)는 명확한 의도를 가지고 작성되었으며, 컴퓨터는 이를 한 치의 오차도 없이 수행하는 충실한 대리인이었습니다. 이 시기의 소프트웨어, 즉 안드레이 카패시(Andrej Karpathy)가 명명한 Software 1.0의 세계는 투명하고, 결정론적(Deterministic)이며, 인과관계가 명확한 ’화이트박스(White Box)’였습니다.

그러나 2010년대 중반, 딥러닝(Deep Learning)의 실용화와 함께 소프트웨어의 본질적인 패러다임이 이동하기 시작했습니다. 우리는 더 이상 문제를 해결하는 알고리즘을 직접 작성하지 않습니다. 대신, 문제의 해답(데이터)과 그 해답을 찾을 수 있는 구조(아키텍처)를 제공하고, 컴퓨터가 스스로 알고리즘을 찾아내도록 유도합니다. 이것이 바로 Software 2.0입니다. Software 2.0은 인간이 이해하기 힘든 수백만, 수천억 개의 부동 소수점(Floating-point) 매개변수(Parameters)로 구성되며, 이 매개변수들의 집합인 신경망(Neural Network)이 프로그램의 실체가 됩니다.

제미나이(Gemini)와 같은 거대 언어 모델(LLM)은 이러한 Software 2.0의 정점에 서 있습니다. 이들은 전례 없는 성능과 유연성을 보여주지만, 그 대가로 우리는 소프트웨어에 대한 ’명시적 제어권’을 상실했습니다. 개발자는 모델이 ‘왜’ 그런 답변을 생성했는지, ‘어떻게’ 특정 결론에 도달했는지에 대한 논리적 추적 경로를 잃어버렸습니다. 본 보고서는 이러한 ‘로직의 블랙박스화(Black Box Logic)’ 현상을 심층적으로 분석합니다. 단순히 내부를 볼 수 없다는 불투명성을 넘어, 이것이 소프트웨어의 신뢰성, 유지보수성, 그리고 개발자의 역할에 미치는 광범위한 영향을 기술적, 공학적 관점에서 철저히 규명할 것입니다.

1.2 패러다임의 전환: 작성자에서 큐레이터로

Software 1.0에서 개발자는 로직의 **작성자(Writer)**였습니다. C++이나 Python으로 작성된 코드는 개발자의 사고 과정을 그대로 반영한 결과물입니다. 반면, Software 2.0에서 개발자는 데이터의 **큐레이터(Curator)**이자 모델의 **교사(Teacher)**로 변모합니다. 개발자의 주된 업무는 복잡한 알고리즘을 설계하는 것이 아니라, 고품질의 데이터셋을 수집, 정제, 라벨링하고, 이를 통해 최적화 알고리즘(Optimizer)이 올바른 방향으로 학습하도록 유도하는 것입니다.

이 과정에서 ’소스 코드’의 정의가 바뀝니다. Software 2.0의 소스 코드는 사람이 읽을 수 있는 텍스트 파일이 아니라, (1) 학습 데이터셋, (2) 신경망 아키텍처 정의, (3) 학습 하이퍼파라미터의 조합입니다. 컴파일 과정은 ’학습(Training)’으로 대체되었으며, 그 결과물인 바이너리는 거대한 가중치 행렬(Weight Matrices)입니다. 이 새로운 바이너리는 인간의 인지 능력을 벗어난 고차원 공간에서 작동하며, 우리는 이를 ’블랙박스’라고 부를 수밖에 없게 되었습니다.

2. 블랙박스의 기술적 해부: 왜 우리는 내부를 볼 수 없는가?

Software 2.0의 블랙박스화는 개발자가 코드를 의도적으로 숨기거나 난독화(Obfuscation)해서 발생하는 보안상의 문제가 아닙니다. 이는 딥러닝 모델의 수학적 구조와 정보 처리 방식에 내재된 본질적(Intrinsic) 특성입니다. 신경망이 정보를 처리하는 미시적 메커니즘을 이해해야만 왜 우리가 내부 연산을 직관적으로 파악하거나 제어할 수 없는지 알 수 있습니다.

2.1 분산된 표현(Distributed Representation)과 의미의 해체

전통적인 소프트웨어 공학(Software 1.0)에서는 ’모듈성(Modularity)’과 ’캡슐화(Encapsulation)’가 핵심 원칙이었습니다. 특정 기능은 특정 함수나 클래스에 할당되며, 변수명(예: customerAge, taxRate)은 해당 메모리 공간이 담고 있는 정보의 의미를 명확히 지시합니다. 따라서 버그가 발생하면 해당 변수나 함수를 추적하여 논리적 오류를 수정할 수 있습니다.

그러나 신경망(Software 2.0)에서는 이러한 국소적(Local) 의미가 해체됩니다. 정보는 특정 뉴런이나 파라미터 하나에 저장되는 것이 아니라, 네트워크 전체 혹은 레이어 전체에 걸친 **분산된 표현(Distributed Representation)**으로 존재합니다.

  • 다대다(Many-to-Many) 대응: 하나의 개념(예: ‘고양이’)은 수천 개의 뉴런 활성화 패턴으로 표현되며, 역으로 하나의 뉴런은 ‘고양이’, ‘자동차’, ‘구름’ 등 수백 가지 서로 다른 객체를 인식하는 데 동시에 관여합니다. 이를 ’Polysemantic Neuron’이라고도 합니다.
  • 환원 불가능성: 따라서 개별 뉴런 하나를 떼어내어 “이것은 고양이의 귀를 담당하는 뉴런이다“라고 정의하는 것은 수학적으로 부정확하며 공학적으로 무의미합니다. 의미는 개별 요소가 아닌 요소들 간의 관계와 패턴 속에 존재하기 때문입니다.

이러한 특성은 개발자가 시스템의 특정 지식을 ’수정’하거나 ’삭제’하는 것을 극도로 어렵게 만듭니다. “모델에서 ’폭력적인 언어’에 대한 지식만 삭제하라“는 요구는 Software 1.0에서는 금지어 리스트를 업데이트하는 것으로 해결되지만, Software 2.0에서는 수천억 개의 파라미터 속에 흩어져 녹아있는 관련 가중치들을 찾아내야 하는 불가능에 가까운 작업이 됩니다.

2.2 고차원성(High Dimensionality)과 비선형성(Non-linearity)

블랙박스화의 또 다른 핵심 원인은 고차원성과 비선형성의 결합입니다. 인간의 인지 능력은 3차원 공간에 갇혀 있으며, 우리는 변수 간의 관계를 선형적(Linear)인 인과관계로 파악하려는 강한 편향을 가지고 있습니다. “입력 X가 2배 늘어나면 출력 Y도 비례해서 증가한다“는 식의 사고방식입니다.

그러나 최신 딥러닝 모델은 수천억 차원의 파라미터 공간(Parameter Space)을 다룹니다. 이 공간에서 데이터 포인트들을 구분 짓는 결정 경계(Decision Boundary)는 단순한 평면이 아니라, 인간이 상상할 수 없는 복잡한 위상(Topology)을 가진 초곡면(Hyper-surface)을 형성합니다.

  • 비선형 활성화 함수: ReLU, Sigmoid, Tanh, Gelu와 같은 비선형 함수들이 층층이 쌓이면서(Deep Layering), 입력 데이터는 수십, 수백 번의 비선형 변환을 겪습니다. 이 과정에서 입력 공간은 비틀리고(Warping), 접히고(Folding), 찢어지며(Shearing) 새로운 잠재 공간(Latent Space)으로 매핑됩니다.
  • 해석의 단절: 이 복잡한 변환 과정을 거친 최종 출력값에 대해, “왜 이 입력이 이 출력을 만들어냈는가?“라고 물었을 때, 수학적으로는 “중간 레이어의 3,421번째 벡터와 가중치 행렬 W의 내적 후 ReLU를 통과한 값이…“라고 설명할 수 있습니다. 하지만 이는 인간에게 아무런 **설명력(Explanatory Power)**을 가지지 못합니다. 이것이 바로 해석 가능성(Interpretability)의 상실입니다.

2.3 최적화가 작성한 코드의 불투명성

Software 2.0에서 실질적인 프로그래밍, 즉 가중치를 설정하는 작업은 사람이 아니라 **최적화 알고리즘(Stochastic Gradient Descent, SGD 등)**이 수행합니다. 개발자는 목적 함수(Loss Function)를 통해 “무엇(What)“을 달성해야 하는지만 정의할 뿐, “어떻게(How)” 달성할지는 전적으로 최적화 과정에 위임합니다.

문제는 최적화 알고리즘이 찾아낸 해결책이 인간의 논리와는 전혀 다른 방식으로 작동할 수 있다는 점입니다. 이를 **‘외계지성(Alien Intelligence)’**에 비유하기도 합니다. 예를 들어, 이미지 분류 모델이 ’늑대’를 인식할 때, 인간처럼 늑대의 생김새를 보는 것이 아니라, 훈련 데이터에 늑대 사진이 주로 눈(Snow) 배경에서 찍혔다는 점을 이용해 ’하얀 배경’을 ’늑대’로 인식하는 논리를 스스로 구축할 수 있습니다. 이는 모델이 99%의 정확도를 가진다 하더라도, 그 내부 로직은 인간의 상식과 전혀 다를 수 있음을 시사합니다. 개발자는 모델이 ’정답’을 맞혔다는 사실은 알 수 있지만, 그것이 ’올바른 이유’로 맞혔는지는 확신할 수 없게 됩니다.

3. 인과성(Causality)의 상실과 상관관계(Correlation)의 함정

Software 1.0은 본질적으로 인과적(Causal)입니다. “사용자가 버튼을 눌렀기 때문에(Cause) 결제 창이 뜬다(Effect)“는 논리가 코드에 명시되어 있습니다. 반면, Software 2.0은 데이터 간의 통계적 **상관관계(Correlation)**를 학습하는 기계입니다. 이 차이는 블랙박스 로직의 신뢰성에 치명적인 약점을 만듭니다.

3.1 허위 상관관계(Spurious Correlations)와 지름길 학습

딥러닝 모델은 데이터셋 내에 존재하는 가장 ‘쉬운’ 패턴을 찾아내어 손실 함수를 최소화하려는 경향이 있습니다. 이를 **지름길 학습(Shortcut Learning)**이라고 합니다. 만약 학습 데이터에서 ’의사 가운을 입은 사람’이 대부분 ’남성’이라면, 모델은 ’의사’라는 직업적 특징(청진기, 병원 배경 등)을 학습하는 대신, 단순히 ’남성 = 의사’라는 쉬운 상관관계를 학습해버릴 수 있습니다.

이러한 **허위 상관관계(Spurious Correlation)**는 블랙박스 내부 깊숙이 각인되며, 개발자가 이를 사전에 감지하기는 매우 어렵습니다. 테스트 단계에서 우연히 남성 의사 사진만 테스트한다면 모델은 완벽하게 동작하는 것처럼 보일 것입니다. 그러나 실제 환경에서 여성 의사 사진이 입력되면 모델은 오작동을 일으킵니다. 이는 모델이 실제 세계의 인과율(Causality)을 이해한 것이 아니라, 데이터셋에 편향된 통계적 우연을 ’진리’로 받아들였기 때문입니다.

3.2 인과 추론의 부재와 일반화의 한계

제미나이와 같은 생성형 모델 역시 이 문제에서 자유롭지 않습니다. LLM은 다음에 올 단어의 확률을 예측할 뿐, 문장이 담고 있는 사실 관계의 인과성을 이해하고 추론하는 것이 아닙니다.

  • 인과적 추론(Causal Inference)의 결여: “비가 와서 바닥이 젖었다“는 문장과 “바닥이 젖어서 비가 왔다“는 문장 사이의 논리적 타당성 차이를 모델은 오직 학습 데이터에 등장한 빈도로만 판단합니다. 만약 데이터에 후자의 문장이 더 많이 포함되어 있다면, 모델은 그것을 더 그럴듯한 문장으로 생성할 것입니다.
  • 환각(Hallucination)의 원인: 이러한 인과성 부재는 ‘환각’ 현상의 근본 원인 중 하나입니다. 모델은 사실 여부와 관계없이 통계적으로 그럴듯한 단어들을 조합하여 거짓 정보를 마치 진실인 것처럼 생성합니다. 블랙박스 내부는 ’진실(Truth)’을 검증하는 메커니즘이 없으며, 오직 ’유사성(Likelihood)’만을 계산하기 때문입니다.

4. 제어권의 상실(Loss of Control): 개발자에서 관찰자로

로직의 블랙박스화는 단순한 이해의 부재를 넘어, 시스템에 대한 **통제권(Agency)**의 근본적인 상실을 의미합니다. Software 1.0 시대의 개발자가 시스템의 모든 비트와 바이트를 통제하는 ’엔지니어’였다면, Software 2.0 시대의 개발자는 시스템의 행동을 관찰하고 간접적으로 유도하는 ’관찰자’에 가깝습니다.

4.1 명시적 수정(Explicit Fix)의 불가능성

가장 즉각적인 제어권 상실은 ‘버그 수정(Fix)’ 과정에서 나타납니다. 전통적인 개발에서는 버그가 발견되면 해당 로직을 담고 있는 코드 라인을 찾아 수정하면 되었습니다. 이는 외과 수술처럼 정확하고 국소적인(Local) 개입입니다.

하지만 Software 2.0에서는 이러한 국소적 수정이 불가능합니다. “이 모델이 특정 사투리를 인식하지 못한다“는 문제가 발생했을 때, 개발자는 “사투리 처리 가중치를 0.5 높여라“와 같은 직접적인 명령을 내릴 수 없습니다. 그 사투리를 처리하는 로직이 네트워크 전체에 분산되어 있기 때문입니다. 개발자가 할 수 있는 유일한 조치는 **데이터셋에 해당 사투리 샘플을 추가하고 전체 모델을 재학습(Retraining)**시키는 전역적(Global) 개입뿐입니다.

4.2 CACE 원칙: 하나를 바꾸면 모든 것이 바뀐다

재학습을 통한 수정은 CACE(Changing Anything Changes Everything) 원칙에 지배받습니다. 딥러닝 모델의 모든 파라미터는 서로 얽혀 있기 때문에, 특정 문제를 해결하기 위해 데이터를 추가하고 재학습하면, 전혀 상관없는 다른 기능이 망가질 위험이 있습니다.

  • 파국적 망각(Catastrophic Forgetting): 새로운 데이터를 학습하는 과정에서 모델이 이전에 학습했던 지식을 잊어버리는 현상입니다. 사투리 인식을 개선했더니 표준어 인식률이 떨어지거나, 특정 보안 취약점을 패치했더니 일반적인 대화 능력이 저하되는 식입니다.
  • 회귀 테스트의 무한 반복: 따라서 Software 2.0의 유지보수는 ’수정 -> 전체 테스트 -> 또 다른 문제 발생 -> 재수정’의 무한 루프에 빠지기 쉽습니다. Software 1.0에서는 모듈별로 격리된 수정이 가능했지만, Software 2.0은 거대한 단일 덩어리(Monolithic)로 동작하기 때문에 유지보수의 비용과 불확실성이 기하급수적으로 증가합니다.

4.3 적대적 취약성(Adversarial Vulnerability)

제어권 상실의 가장 극단적인 형태는 **적대적 공격(Adversarial Attack)**에 대한 취약성입니다. 블랙박스 내부의 로직은 인간의 시각적/인지적 로직과 다르기 때문에, 입력 데이터에 인간의 눈에는 보이지 않는 미세한 노이즈를 추가하는 것만으로도 모델을 완전히 속일 수 있습니다.

예를 들어, 판다 사진에 특수한 노이즈를 섞으면 사람은 여전히 판다로 보지만, AI는 99%의 확신을 가지고 ’긴팔원숭이’로 분류할 수 있습니다. 이는 개발자가 모델의 ’보는 방식’을 통제하지 못했음을 증명합니다. Software 1.0에서는 입력값 검증(Input Validation)을 통해 예외 처리가 가능하지만, 고차원 벡터 공간에서 일어나는 이러한 공격은 전통적인 방어 로직으로 막을 수 없습니다.

5. 오라클 문제(The Oracle Problem)와 검증의 위기

로직이 블랙박스화되면서 개발자가 직면하는 또 다른 난관은 **‘테스트 오라클(Test Oracle)’**의 부재입니다. 오라클이란 테스트 수행 결과가 참인지 거짓인지를 판단하는 기준이나 메커니즘을 말합니다. Software 1.0에서는 명세(Specification)가 명확하므로 “2+2=4“와 같은 결정론적 오라클이 존재합니다.

5.1 확률적 결과와 정답의 모호성

하지만 제미나이와 같은 생성형 AI가 다루는 문제는 ‘정답이 모호하거나 유일하지 않은’ 영역입니다. “이 문서를 요약하라“거나 “친절하게 응대하라“는 요청에 대해 단 하나의 정답은 존재하지 않습니다. 또한 모델은 매번 다른 결과를 내놓는 비결정론적(Non-deterministic) 특성을 가집니다.

  • 비결정론적 출력: 같은 입력에 대해 어제는 A라고 답하고 오늘은 B라고 답할 수 있습니다. 이때 A와 B 중 무엇이 정답인지, 혹은 둘 다 정답인지 판단하는 것은 매우 어렵습니다.
  • 평가의 주관성: “요약이 잘 되었는가?“를 판단하기 위해서는 결국 인간의 주관적 개입(Human Evaluation)이 필요하며, 이는 자동화된 테스트 파이프라인(CI/CD) 구축을 어렵게 만듭니다.

5.2 메타모픽 테스팅(Metamorphic Testing)과 차분 테스팅

이러한 오라클 문제를 해결하기 위해 학계와 산업계에서는 **메타모픽 테스팅(Metamorphic Testing)**과 같은 새로운 검증 전략을 도입하고 있습니다. 이는 절대적인 정답(Ground Truth) 대신, 입력과 출력 사이의 **관계(Relation)**를 검증하는 방식입니다.

  • 메타모픽 관계(Metamorphic Relation, MR): 예를 들어, “감성 분석 AI에 ’정말’이라는 강조 부사를 추가해도 긍정/부정의 결과는 바뀌지 않거나 강화되어야 한다“는 관계를 정의합니다. 만약 ’정말’을 넣었더니 긍정이 부정으로 바뀐다면, 정답을 모르더라도 모델에 버그가 있음을 알 수 있습니다.
  • 차분 테스팅(Differential Testing): 신규 모델의 출력을 기존의 검증된 모델(또는 더 큰 모델)의 출력과 비교하여 그 차이를 분석하는 방식입니다.

하지만 이 역시 간접적인 검증일 뿐, 블랙박스 내부의 로직이 정확한지 직접 들여다보는 것은 아닙니다. 개발자는 이제 코드의 논리적 결함을 찾는 것이 아니라, 시스템의 **행동적 일관성(Behavioral Consistency)**과 **통계적 분포(Statistical Distribution)**를 모니터링하는 것으로 품질 보증(QA)의 역할을 전환해야 합니다.

6. 새로운 실패의 유형: 조용한 실패(Silent Failure)와 기술 부채

Software 1.0의 버그는 대개 요란합니다. 프로그램이 멈추거나(Crash), 예외(Exception)를 발생시킵니다. 이는 개발자에게 즉각적인 피드백을 줍니다. 반면, Software 2.0의 블랙박스 로직이 야기하는 실패는 훨씬 은밀하고 위험합니다. 이를 **‘조용한 실패(Silent Failure)’**라고 부릅니다.

6.1 문법적으로 완벽한 오류

Software 2.0 모델은 절대 “에러“를 출력하지 않습니다. 대신 ‘틀린 답을 매우 높은 확신(Confidence)을 가지고’ 출력합니다.

  • 현상: 번역 모델이 오역을 하거나, 제미나이가 존재하지 않는 판례를 날조(Hallucination)할 때, 시스템 내부에서는 아무런 경고등도 켜지지 않습니다. 행렬 곱셈과 활성화 함수 연산 자체는 수학적으로 완벽하게 수행되었기 때문입니다.
  • 탐지의 어려움: 이러한 실패는 시스템이 배포되고 한참이 지나서야, 실제 사용자에게 피해가 발생한 후에야 발견되는 경우가 많습니다. 특히 시간이 지남에 따라 입력 데이터의 분포가 변하면서(Data Drift) 모델의 성능이 서서히 저하되는 현상은 기존의 모니터링 도구로는 감지하기 어렵습니다. 시스템은 ’작동’하고 있지만, 논리는 내부에서부터 썩어가고(Rotting) 있는 것입니다.

6.2 Software 2.0의 기술 부채

블랙박스 로직은 새로운 형태의 **기술 부채(Technical Debt)**를 양산합니다.

  • 숨겨진 피드백 루프(Hidden Feedback Loops): 모델 A의 출력이 모델 B의 입력으로 사용되고, 다시 모델 B가 모델 A의 학습 데이터에 영향을 주는 복잡한 의존성이 생길 수 있습니다. 이는 시스템을 분석 불가능한 상태로 만듭니다.
  • 접착제 코드(Glue Code)의 증가: 블랙박스 모델을 기존 시스템에 통합하기 위해 수많은 전처리, 후처리 코드가 덕지덕지 붙게 되며, 이는 전체 시스템의 복잡도를 높입니다.
  • 데이터 의존성 부채: 사용된 학습 데이터의 버전 관리, 데이터 정제 파이프라인의 일관성 유지는 코드 관리보다 훨씬 어렵고 비용이 많이 듭니다.

7. Software 3.0와 하이브리드 아키텍처: 블랙박스 가두기

제미나이와 같은 LLM의 등장은 Software 2.0을 넘어 Software 3.0으로의 진화를 예고하고 있습니다. Software 3.0은 자연어 프롬프트를 통해 거대 모델을 제어하는 방식을 말합니다. 이 단계에서 엔지니어링의 핵심은 ’블랙박스 내부를 이해하는 것’에서 ’블랙박스를 안전하게 가두고 제어하는 것’으로 이동합니다.

7.1 샌드위치 아키텍처(Sandwich Architecture)

블랙박스의 불확실성을 통제하기 위해, 결정론적인 Software 1.0 코드 사이에 Software 2.0 모델을 끼워 넣는 하이브리드 아키텍처가 표준으로 자리 잡고 있습니다.

  1. 입력 가드레일(Input Guardrails): 사용자의 입력을 모델에 전달하기 전에, Software 1.0 기반의 규칙(Rule)이나 작은 모델을 통해 개인정보, 유해성, 프롬프트 주입 공격 등을 필터링합니다.
  2. 블랙박스 코어(Black Box Core): 제미나이와 같은 LLM이 핵심 추론과 생성을 담당합니다.
  3. 출력 검증기(Output Validators): 모델이 생성한 결과를 사용자에게 보여주기 전에 다시 한번 검증합니다. 예를 들어, 생성된 코드가 문법적으로 올바른지 컴파일러로 확인하거나, 생성된 사실이 지식 베이스(RAG)와 일치하는지 대조합니다.

이러한 구조는 확률적인 블랙박스 모델을 결정론적인 안전장치로 감싸서(Wrap), 전체 시스템의 신뢰성을 확보하려는 시도입니다.

7.2 설명 가능한 AI(XAI)의 역할과 한계

비록 완전한 해석은 불가능할지라도, 설명 가능한 AI(XAI) 기술은 블랙박스 내부를 엿볼 수 있는 창을 제공합니다.

  • SHAP/LIME: 입력 데이터의 어떤 특징(Feature)이 결과에 가장 큰 영향을 미쳤는지 기여도(Attribution)를 계산합니다.

  • Attention Map: 트랜스포머 모델이 문장을 생성할 때 어떤 단어에 집중(Attend)했는지 시각화합니다.

그러나 이러한 설명은 대개 **사후적(Post-hoc)**이며 근사치(Approximation)일 뿐입니다. 이는 모델의 실제 내부 메커니즘을 완벽하게 설명하는 것이 아니라, 인간이 이해할 수 있는 수준으로 단순화한 ’해석’에 불과하다는 한계를 인지해야 합니다.

8. 결론: 확률적 소프트웨어 공학의 시대로

제미나이를 위시한 Software 2.0 시스템의 도입은 소프트웨어 공학자들에게 **‘로직에 대한 미시적 통제권의 포기’**를 요구합니다. 우리는 더 이상 연산의 모든 단계를 명시적으로 제어할 수 없으며, 블랙박스 내부의 불투명성과 확률적 동작을 시스템의 상수로 받아들여야 합니다.

그러나 이것이 개발자 역할의 축소를 의미하는 것은 아닙니다. 오히려 역할의 확장과 고도화가 필요합니다.

  1. 데이터 엔지니어링이 곧 프로그래밍: 로직을 직접 작성하는 대신, 로직을 형성하는 원재료인 데이터의 품질과 분포를 설계하는 것이 개발자의 핵심 역량이 됩니다.
  2. 확률적 사고(Probabilistic Thinking): 100%의 무결성을 보장하는 결정론적 사고에서 벗어나, 99.9%의 신뢰도를 관리하고 리스크를 분산시키는 확률적 사고방식을 갖춰야 합니다.
  3. 시스템 설계자로서의 귀환: 개별 알고리즘 작성에서 벗어나, 블랙박스 모듈들을 안전하게 조립하고 검증하는 거시적인 시스템 아키텍처 설계가 더욱 중요해집니다.

결국 ’로직의 블랙박스화’는 기술의 퇴보가 아니라 진보의 대가입니다. 우리는 계산 가능한 것의 영역을 기하급수적으로 확장하는 대신, 계산 과정의 투명성을 일부 지불했습니다. 이 거래를 성공적인 엔지니어링으로 완성하는 것은 이제 블랙박스 자체가 아니라, 그 블랙박스를 다루는 우리의 새로운 공학적 태도에 달려 있습니다.

8.1 표 1: Software 1.0과 Software 2.0/3.0의 기술적 특성 비교

구분Software 1.0 (Classical)Software 2.0 (Deep Learning)Software 3.0 (LLM/Agentic)
로직 작성 주체인간 프로그래머 (명시적)최적화 알고리즘 (데이터 기반)거대 모델 + 프롬프트 (맥락 기반)
핵심 구성 요소소스 코드 (Logic)가중치 (Weights), 데이터프롬프트, 컨텍스트, RAG
가시성 (Visibility)화이트박스 (White Box)블랙박스 (Black Box)블랙박스 + 자연어 설명
제어 방식명령어 (Instruction)목적 함수 (Objective)지시문 (Natural Language)
실패 모드크래시, 버그 (Explicit)편향, 환각 (Silent Failure)지시 불이행, 조작 (Jailbreak)
테스트 오라클결정론적 (Equal/Not Equal)통계적 (Distribution Match)평가자 모델 (LLM-as-a-Judge)
유지보수 대상코드 라인데이터셋, 라벨링프롬프트, 지식 베이스

9. 참고 자료

  1. Karpathy: AI is not electricity. It’s a new operating system - AI Magazine, https://haimagazine.com/en/science-and-development/karpathy-ai-is-not-electricity-its-a-new-operating-system/
  2. Andrej Karpathy’s Software is Changing (Again) summarized - Medium, https://medium.com/data-science-in-your-pocket/software-is-changing-again-96b05c4af061
  3. Software 2.0 - Andrej Karpathy – Medium, https://karpathy.medium.com/software-2-0-a64152b37c35
  4. Highlights of a 40 - Minute Speech by AI Guru Karpathy - 36氪, https://eu.36kr.com/en/p/3345724973996929
  5. Why we will never open deep learning’s black box | Towards Data …, https://towardsdatascience.com/why-we-will-never-open-deep-learnings-black-box-4c27cd335118/
  6. Understanding AI’s Black Box Phenomenon | by Myk Eff | AI Music, https://medium.com/ai-music/the-enigmatic-machine-decoding-ais-black-box-phenomenon-44ad38c3c6a3
  7. Why Machine Learning Models are Black Boxes - TrendSpider, https://trendspider.com/learning-center/why-machine-learning-models-are-black-boxes/
  8. Interpreting Black-box Machine Learning Models for high … - arXiv, https://arxiv.org/html/2407.21056v1
  9. Building the Software 2.0 Stack by Andrej Karpathy [video], https://news.ycombinator.com/item?id=17280454
  10. Causality-Driven Neural Network Repair: Challenges and …, https://arxiv.org/html/2504.17946
  11. Correlation vs. Causation: What’s the Difference? - Coursera, https://www.coursera.org/articles/correlation-vs-causation
  12. How do AI models determine cause and effect? - Milvus, https://milvus.io/ai-quick-reference/how-do-ai-models-determine-cause-and-effect
  13. Correlation vs. Causation: How Causal AI is Helping Determine Key, https://globalforum.diaglobal.org/issue/october-2024/correlation-vs-causation-how-causal-ai-is-helping-determine-key-connections-in-healthcare-and-clinical-trials/
  14. From Correlation to Causation: How Causal AI Is Reshaping Policy, https://www.francescatabor.com/articles/2025/7/30/from-correlation-to-causation-how-causal-ai-is-reshaping-policy-making
  15. Connecting the Dots: The Crucial Difference Between Correlation, https://predikt.ai/insights/connecting-the-dots-the-crucial-difference-between-correlation-and-causation-for-ai-predictions-in-finance
  16. Everything you need to know about Software 2.0 - Matellio, https://www.matellio.com/blog/everything-you-need-to-know-about-software-2-0/
  17. Catching Silent Errors in Deep Learning Training with Automated, https://www.usenix.org/system/files/osdi25-jiang.pdf
  18. Security of Software 1.0 vs 2.0 - Xander Dunn, https://xander.ai/security-of-software-1-0-vs-2-0
  19. The Oracle Problem - YLD, https://www.yld.io/blog/the-oracle-problem
  20. How effectively does metamorphic testing alleviate the oracle, https://vuir.vu.edu.au/33046/1/TSEmt.pdf
  21. The Oracle Problem in Software Testing: A Survey - EECS 481, https://eecs481.org/readings/testoracles.pdf
  22. What Is Deterministic AI? Benefits, Limits & Use Cases - Kubiya, https://www.kubiya.ai/blog/what-is-deterministic-ai
  23. Oracle Forms Modernization: Why Deterministic Conversion Matters, https://renaps.com/en/blog/oracle-forms-modernization-Deterministic-vs-AI
  24. Testing convolutional neural network based deep learning systems, https://pmc.ncbi.nlm.nih.gov/articles/PMC11888866/
  25. Metamorphic Testing of Relation Extraction Models - MDPI, https://www.mdpi.com/1999-4893/16/2/102
  26. Use of Metamorphic Relations as Knowledge Carriers to Train Deep, https://arxiv.org/pdf/2104.04718
  27. Testing Modern AI Systems: From Rule-Based Systems to Deep, https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/testing-modern-ai-systems-from-rule-based-systems-to-deep-learning-and-large-lan/4429518
  28. Software Dependencies 2.0: An Empirical Study of Reuse and, https://arxiv.org/html/2509.06085v1
  29. Investigating and Detecting Silent Bugs in PyTorch Programs, http://www.shinhwei.com/Saner2024.pdf
  30. Debugging in the Age of AI Isn’t About Fixing Broken Code - ShiftMag, https://shiftmag.dev/debugging-ai-era-6681/
  31. Data-driven techniques for identifying and automatically repaying, https://dr.lib.iastate.edu/bitstreams/4a21cbdf-c824-429c-8283-b0f5df2e772b/download
  32. Measuring Technical Debt in AI-Based Competition Platforms - arXiv, https://arxiv.org/pdf/2405.11825
  33. (PDF) Understanding Software-2.0: A Study of Machine Learning, https://www.researchgate.net/publication/348296914_Understanding_Software-20_A_Study_of_Machine_Learning_Library_Usage_and_Evolution
  34. Software 1.0 vs Software 2.0 vs Software 3.0: A 3-Minute Breakdown, https://medium.com/@agile.cadre.testing/software-1-0-vs-software-2-0-vs-software-3-0-a-3-minute-breakdown-2fb17a16340f
  35. Navigating the Three Eras of Software Development - Robbie Allen, https://robbieallen.medium.com/navigating-the-three-eras-of-software-development-a-strategic-guide-for-executives-fee108db9007
  36. [D] What are the top Explainable AI papers ? : r/MachineLearning, https://www.reddit.com/r/MachineLearning/comments/1pdthu0/d_what_are_the_top_explainable_ai_papers/
  37. samzabdiel/XAI: Papers and code of Explainable AI esp … - GitHub, https://github.com/samzabdiel/XAI
  38. Black Box Issues in Artificial Intelligence: Risks, Real Examples, and, https://medium.com/@esilvalabh/black-box-issues-in-artificial-intelligence-risks-real-examples-and-how-to-mitigate-them-with-f69adebe82e2