learn

설계대로 구현됐는지 검증하는 법

설계대로 구현됐는지 검증하는 법

how-to-design-a-program-from-scratch|설계 프로세스를 거쳐 AI에게 구현을 맡겼을 때, 결과물이 설계와 일치하는지 어떻게 확인하는가. 코드가 "돌아가는 것"과 "구조가 맞는 것"은 다른 문제다.

검증의 두 축

  • 구조 검증: 설계대로 만들어졌는가 (아키텍처, 모듈 분리, 의존 방향)
  • 동작 검증: 의도대로 작동하는가 (기능 정상 동작)

동작 검증은 직접 써보면 된다. 위험한 것은 **"의도와 다르게 구현됐는데 돌아가는 경우"**다. 나중에 수정하려 하면 구조가 설계와 완전히 다른 걸 발견하게 된다.

구조 검증: 세 가지 체크포인트

1. 파일/폴더 구조가 설계와 일치하는가

Layered Architecture로 설계했다면, UI/Service/Model/Storage가 실제로 분리되어 있는지 확인한다:

✅ 확인할 것:
  - UI 코드와 비즈니스 로직이 다른 파일에 있는가?
  - DB 접근 코드가 한 곳에 모여있는가?
  - 도메인 모델(Course, Lecture)이 독립적으로 존재하는가?

❌ 위험 신호:
  - UI 컴포넌트 안에 SQL 쿼리가 있다
  - Service 파일이 UI 컴포넌트를 import한다
  - 같은 개념의 정의가 여러 파일에 흩어져 있다

2. 의존 방향이 설계와 일치하는가

아키텍처 검증의 핵심. Layered에서는 위에서 아래로만 의존해야 한다:

확인 방법: 각 파일의 import문을 보고 화살표를 그려본다. 화살표가 항상 같은 방향이면 OK. 역방향이나 건너뛰는 화살표가 있으면 설계 위반이다.

// ✅ 올바른 방향: UI → Service
import { scheduleService } from '../lib/scheduleService'

// ❌ 역방향: Service → UI
import { TimetableView } from '../components/TimetableView'

3. 도메인 모델이 설계한 개념과 일치하는가

타입 정의 파일을 열어서 설계한 관계가 그대로인지 확인한다:

// ✅ "Course가 여러 Lecture를 가진다"는 설계와 일치
interface Course {
  id: string
  name: string
  lectures: Lecture[]
}

// ❌ Course와 Lecture가 분리 안 됨 — "월수 수업" 표현 불가
interface Course {
  id: string
  name: string
  day: string        // Lecture 정보가 직접 들어감
  startTime: string
}

실전 검증 루틴 (30분 이내)

Step 1 — 폴더 구조 확인 (2분)
  파일 목록을 보고 설계한 층이 분리되어 있는지

Step 2 — 타입/모델 확인 (5분)
  도메인 모델 파일을 열어서 설계한 관계와 일치하는지

Step 3 — import 방향 확인 (10분)
  각 파일의 import를 보고 의존 화살표가 위→아래인지
  종이에 간단히 그려보면 좋다

Step 4 — 경계 케이스 실행 (10분)
  요구사항의 경계 질문을 실제로 테스트
  "시간이 맞닿는 수업 두 개는?" "같은 수업 두 번 등록하면?"

Step 1~3이 구조 검증, Step 4가 동작 검증이다.

AI에게 검증을 도와달라고 요청하기

직접 모든 import를 추적하기 어려우면:

"이 프로젝트의 모든 파일 간 의존 관계를 Mermaid로 그려줘. 각 파일이 어떤 파일을 import하는지 화살표로 보여줘."

돌려받은 실제 구조도를 내 설계 다이어그램과 나란히 놓고 비교한다. 두 그림이 같으면 검증 통과. 이 비교가 가능한 이유는 where-humans-must-verify-in-design|내가 설계를 직접 했기 때문이다. 설계 없이는 비교 대상이 없다.

← learn 목록으로홈으로