설계 과정에서 인간이 검증해야 하는 지점

소프트웨어 설계의 각 단계에서 "어디를 검증해야 하는가"는 결국 **"어디서 실수하면 비용이 가장 큰가"**와 같은 질문이다.

핵심 원리: 수정 비용의 비대칭성

how-to-design-a-program-from-scratch|설계 프로세스를 다시 보면:

요구사항 → 도메인 모델링 → 아키텍처 → 컴포넌트 → 데이터 → 알고리즘 → 구현

왼쪽에서 내린 결정이 오른쪽 전체를 지배한다. 요구사항이 틀리면 아키텍처부터 다시, 아키텍처가 틀리면 컴포넌트 구조부터 다시 짜야 한다. 반면 알고리즘 하나가 틀린 건 그 함수만 고치면 된다.

Barry Boehm의 "결함 수정 비용 곡선"에 따르면, 요구사항 단계의 결함을 구현 후에 발견하면 수정 비용이 수십~수백 배 증가한다. 따라서 검증의 우선순위는 상위 결정일수록 높다.

인간이 검증해야 하는 4가지 지점

1. 요구사항 — "이게 정말 필요한 건가?"

가장 치명적인 지점이다. 요구사항 자체가 틀리면 그 위에 쌓인 모든 것이 무너진다.

시간표 앱 예시:

• "수업 추가/삭제"라고 했지만, 실제로 원하는 건 학교 API에서 자동으로 수업을 가져오는 것일 수 있다.
• "개인용"이라고 가정했지만, 핵심 니즈는 친구들과 빈 시간 비교일 수 있다.

이건 코드로 검증할 수 없다. 프로토타입을 보여주고 "이게 네가 원하는 거야?"라고 확인하는 것이 가장 확실한 검증이다.

2. 도메인 모델의 경계 — "이 분리가 현실을 반영하나?"

Course와 Lecture를 분리하는 판단이 틀리면 시스템 전체가 어색해진다.

예를 들어 **"보강 수업"**이 등장하면: 보강은 원래 Lecture를 대체하는 건가, 새로운 임시 Lecture를 추가하는 건가? 이것은 학교마다 규칙이 다를 수 있고, 도메인 전문가(= 실제 사용자)만 답할 수 있다.

모델 경계는 기술적 판단이 아니라 현실 세계의 규칙에 대한 판단이다.

3. 아키텍처 가정의 유효성 — "전제가 아직 맞는가?"

"개인용 소규모 → Layered 적합"은 현재의 가정 위에 세운 결론이다. 시간이 지나면 가정이 깨질 수 있다:

• "개인용" → 친구 공유 기능 요청 → 서버 필요 → 아키텍처 재설계
• "수업만 관리" → 과제/시험/알림 추가 → Event-Driven이 더 적합해짐

이것이 아키텍처 부채(architectural debt)다. 처음에 세운 가정이 아직 유효한지 주기적으로 재검토해야 한다. 코드가 돌아간다고 아키텍처가 맞다는 뜻은 아니다.

4. 모듈 간 인터페이스 계약 — "계약이 명확하고 충분한가?"

conflict_checker.check(newLecture, existingLectures)에서 검증할 것들:

• existingLectures에 같은 과목의 기존 Lecture도 포함되는가?
• 반환값이 bool이면 "어떤 수업과 충돌했는지" 알 수 없는데, UI에서 보여줘야 한다면?
• 시간이 정확히 맞닿는 경우 (10:00-11:00과 11:00-12:00) — 충돌인가?

이런 엣지 케이스는 인터페이스 설계 시점에 "사용자가 필요로 하는 게 뭔지" 인간이 사고해야 한다.

기계에 맡길 수 있는 부분

• 코드 정합성: 타입 체크, null 검사, 범위 검사 → 컴파일러/정적 분석
• 스타일 일관성: 포맷팅, 네이밍 → 린터
• 회귀 버그: 기존 기능 깨짐 여부 → 자동화 테스트
• 알고리즘 정확성: 구간 겹침 공식 검증 → 유닛 테스트

판별 기준

본질적으로 인간이 검증해야 하는 것은 "이게 맞나?"라는 질문이 기술이 아니라 맥락(context)에 의존하는 부분이다.

컴퓨터는 "주어진 규칙대로 동작하는지"는 잘 검증하지만, "이 규칙 자체가 맞는지"는 판단할 수 없다.

검증 우선순위 (높음 → 낮음)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
① 요구사항     → "진짜 필요한가?" (사용자 검증)
② 도메인 모델  → "현실을 반영하나?" (도메인 전문가 검증)
③ 아키텍처 가정 → "전제가 유효한가?" (주기적 재검토)
④ 인터페이스   → "계약이 충분한가?" (코드 리뷰)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⑤ 알고리즘/구현 → 자동화 테스트로 대체 가능