Chapter 1. AI 기반 소프트웨어 개발의 패러다임 변화와 비결정성(Nondeterminism)의 한계

• 1 AI 기반 소프트웨어 개발의 패러다임 변화와 비결정성Nondeterminism의 한계
• 1.1 소프트웨어 엔지니어링 1.0에서 2.0으로의 전환
• 1.1.1 전통적인 소프트웨어 개발(Software 1.0)의 정의: 명시적 로직과 결정론적 제어
• 1.1.2 AI 기반 소프트웨어 개발(Software 2.0)의 부상: 데이터와 확률적 모델링
• 1.1.3 ’코딩(Coding)’에서 ‘프롬프팅(Prompting)’ 및 ’오케스트레이션(Orchestration)’으로의 역할 이동
• 1.1.4 로직의 블랙박스화: 개발자가 제어할 수 없는 내부 연산 과정
• 1.1.5 소프트웨어 생명주기(SDLC) 전반에 걸친 AI의 침투와 파급 효과
• 1.2 비결정성(Nondeterminism)의 기술적 근원과 이해
• 1.2.1 대규모 언어 모델(LLM)의 작동 원리: 다음 토큰 예측(Next Token Prediction)의 확률론
• 1.2.1.1 자기회귀(Autoregressive) 생성의 특징과 누적 오차(Accumulated Error)
• 1.2.1.2 언어 모델의 확률 분포(Probability Distribution)와 소프트맥스(Softmax) 계층
• 1.2.2 샘플링 전략의 영향: Temperature, Top-p, Top-k 파라미터에 따른 다양성과 일관성의 트레이드오프
• 1.2.3 시드(Seed) 값과 난수 생성기의 한계: 동일 시드에서도 발생하는 미세한 차이
• 1.2.4 하드웨어 및 병렬 연산에 의한 비결정성: GPU 부동소수점 연산의 비순차적 처리 특성
• 1.2.5 모델 업데이트와 버전 드리프트(Model Drift): API 제공자의 잠수함 패치(Silent Patch)가 미치는 영향
• 1.3 결정론적(Deterministic) 시스템 vs 확률적(Probabilistic) 시스템의 충돌
• 1.3.1 비즈니스 로직의 요구사항: 100% 정확도와 재현성(Reproducibility)의 필요성
• 1.3.2 확률적 AI 출력의 본질적 결함: 환각(Hallucination)과 창의성 사이의 모호한 경계
• 1.3.3 ‘거의 맞는(Mostly Correct)’ 코드의 위험성: 99%의 정확도가 엔터프라이즈 환경에서 실패하는 이유
• 1.3.4 상태 관리의 어려움: 문맥(Context) 길이에 따른 기억 소실과 출력 변화
• 1.3.5 멱등성(Idempotency) 위배 사례: 동일 입력에 대한 상이한 출력으로 인한 데이터 무결성 훼손
• 1.4 AI 도입으로 인한 기존 품질 보증(QA) 체계의 붕괴
• 1.4.1 전통적 단위 테스트(Unit Test)의 한계: assert(output == expected) 구문의 무력화
• 1.4.1.1 동적이고 예측 불가능한 문자열 결과에 대한 단언(Assertion)의 어려움
• 1.4.1.2 모킹(Mocking) 및 스터빙(Stubbing) 패러다임의 붕괴
• 1.4.2 테스트 케이스 설계의 난이도 증가: 무한에 가까운 입력 공간과 예측 불가능한 출력 공간
• 1.4.3 회귀 테스트(Regression Testing)의 복잡성: 모델 성능 변화 감지와 로직 오류의 구분 불가능
• 1.4.4 디버깅(Debugging)의 실종: 스택 트레이스(Stack Trace)가 없는 오류 추적의 어려움
• 1.4.5 Flaky Test(성공과 실패가 오락가락하는 테스트)의 급증과 CI/CD 신뢰도 하락
• 1.5 비결정성이 비즈니스와 보안에 미치는 구체적 위협
• 1.5.1 금융 및 법률 분야에서의 규제 준수(Compliance) 위반 리스크
• 1.5.2 사용자 경험(UX)의 일관성 저해: 같은 질문에 대해 매번 다른 어조와 포맷으로 응답
• 1.5.3 프롬프트 주입(Prompt Injection) 및 탈옥(Jailbreaking) 공격에 대한 방어의 불확실성
• 1.5.4 비용 예측의 어려움: 재시도(Retry) 로직 증가에 따른 토큰 비용 및 레이턴시 폭증
• 1.5.5 책임 소재(Accountability)의 블랙홀: AI 오판단에 대한 개발자 vs 프롬프트 vs 모델 제공자의 법적 공방
• 1.6 실전 개발에서의 ’느낌적 코딩(Vibe Coding)’의 한계와 엔지니어링적 접근의 필요성
• 1.6.1 프롬프트 엔지니어링만으로는 해결할 수 없는 구조적 한계
• 1.6.2 인간 검토(Human-in-the-loop) 프로세스의 병목 현상과 확장성 문제
• 1.6.3 데모(Demo) 시연 성공과 프로덕션(Production) 배포 사이의 거대한 간극(The Chasm)
• 1.6.4 확신도(Confidence Score)와 로그 확률(Logprobs) 데이터의 활용 및 한계
• 1.6.5 경험적 튜닝을 넘어선 체계적 검증 파이프라인의 부재
• 1.7. 오라클(Oracle) 문제: AI 출력을 검증할 기준의 부재
• 1.7.1. 오라클 문제(The Oracle Problem)의 정의: 정답을 모르는 상태에서 AI의 답을 어떻게 평가할 것인가?
• 1.7.2. 소프트웨어 테스팅에서의 테스트 오라클 유형(참조, 부분, 휴리스틱 오라클) 재조명
• 1.7.3. AI 시대에 새로운 오라클이 필요한 이유: 비결정적 출력을 결정론적 잣대로 평가하기
• 1.7.4. 정답지(Ground Truth) 확보의 비용과 현실적 제약
• 1.7.5. 본 서적의 목표: 비결정성 속에서 결정론적 신뢰를 구축하는 오라클 설계 전략 소개
• 1.8. AI 비결정성(Nondeterminism)이 초래한 실제 비즈니스 실패 사례 분석
• 1.8.1. 사례 1: 항공사 챗봇의 약관 무시 및 환불 판례 (Air Canada 사례)
• 1.8.2. 사례 2: 코딩 어시스턴트의 치명적 리소스 유출 로직 생성(보안 사고)
• 1.8.3. 사례 3: 의료 AI의 환각으로 인한 처방 지침 위반 리스크
• 1.8.4. 각 사례에서 오라클 부재가 미친 영향과 교훈