AI에게 검증 가능한 목표 제시하기: SQuaRE 국제표준 기반 품질 목표와 아키텍처 드라이버

AI에게 검증 가능한 목표 제시하기: SQuaRE 국제표준 기반 품질 목표와 아키텍처 드라이버

출처 및 참고: 유튜브 채널 [코딩하는기술사]의 "AI에게 검증가능한 목표 제시하기 — 국제표준 기반 품질목표 세우기" 강연을 바탕으로, 프로덕션 소프트웨어 아키텍처와 자율 코딩 에이전트(Claude Code, Cursor, Codex 등) 하네스 설계 실무 관점을 결합해 정리한 글입니다.

---

1. "빠르게 만들어 주세요"라는 비극과 완료 판단(DoD)의 실종

소프트웨어 개발 프로젝트에서 기획자나 고객, 혹은 동료 엔지니어로부터 가장 흔하게 듣는 요구사항 중 하나는 다음과 같은 문장들입니다.

• "시스템이 버벅이지 않고 빠르게 동작해야 합니다."
• "장애가 최대한 안 나게 튼튼하게 만들어 주세요."
• "개인정보가 유출되지 않도록 보안을 철저히 강화해 주세요."

언뜻 보면 지극히 당연하고 상식적인 요구 같지만, 엔지니어링 관점에서 이는 최악의 안티패턴입니다. 바로 검증 가능한 기준(Criteria)이 결여된 주관적 '형용사 요구사항'이기 때문입니다.

[형용사 요구사항이 초래하는 소모적 분쟁]

고객 / 기획자: "화면이 너무 느려요. 아직 배포 못 합니다."
엔지니어:      "1.5초 만에 뜨는데 이 정도면 충분히 빠르죠. 뭐가 느리다는 건가요?"
고객 / 기획자: "우리는 0.3초 만에 팍팍 뜨는 걸 생각했는데요?"
엔지니어:      "그럼 처음부터 그렇게 말씀하셨어야죠!"

이 대화에서 틀린 사람은 아무도 없습니다. 사전에 상호 합의된 객관적 측정 기준 자체가 없었기 때문입니다.

기준이 없으면 프로젝트에서 가장 중요한 완료 판단(Definition of Done, DoD)이 원천적으로 불가능해집니다. 도대체 언제 코드가 완성된 것인지, 어떤 상태여야 프로덕션에 내보낼 수 있는지를 판정할 수 없습니다.

[형용사 기반 지시]
"빠르게 만들어주세요" ──▶ 임의의 조기 최적화/캐시 적용 ──▶ "느린데요 vs 빠른데요" 분쟁 ──▶ 완료 판단 불가

[검증 가능한 품질 목표]
"500 TPS 부하 하에서 P95 500ms 이하" ──▶ 아키텍처 텍틱 도출 ──▶ 부하 테스트 자동 실행 ──▶ 객관적 합격/불합격

더 큰 문제는 이 비극이 최근 급격히 확산된 AI 코딩 에이전트(Vibe Coding, Cursor, Claude Code 등) 환경에서 훨씬 더 파괴적인 형태로 재현된다는 점입니다.

---

2. 품질을 객관화하는 국제 표준: SQuaRE (ISO/IEC 25000) 시리즈

전문 소프트웨어 엔지니어와 시스템 아키텍트는 막연한 직관이나 '뇌피셜' 대신, 공인된 국제 표준 체계를 기준으로 품질을 정의하고 소통해야 합니다.

소프트웨어 제품 품질 요구사항 정의 및 평가를 위한 국제 표준 프레임워크가 바로 SQuaRE (System and software Quality Requirements and Evaluation, ISO/IEC 25000 계열)입니다.

표준 번호	표준 명칭	핵심 질문과 아키텍처적 역할
ISO/IEC 25010	제품 품질 모델 (Quality Model)	"무엇을 품질로 정의할 것인가?" 소프트웨어 제품 품질을 9대 주특성과 세부 부특성으로 체계적으로 분류·정의
ISO/IEC 25023	제품 품질 측정 (Quality Measurement)	"무엇으로 어떻게 측정할 것인가?" 품질 특성별 정량적 계측을 위한 측정 항목(Items)과 수학적 측정 함수(Functions) 제공
ISO/IEC 25030	품질 요구사항 (Quality Requirements)	"요구사항을 어떻게 수립하고 관리할 것인가?" 품질 요구사항의 전제 조건, 목표 수치, 평가 프로세스 명세 가이드

특히 ISO/IEC 25010은 소프트웨어의 가치를 결정하는 9대 핵심 품질 특성을 제시합니다.

1. 기능 적합성 (Functional Suitability): 완전성, 정확성, 적절성
2. 성능 효율성 (Performance Efficiency): 시간 효율성(응답/처리 시간), 자원 활용성, 용량성
3. 호환성 (Compatibility): 공존성, 상호운용성
4. 사용성 (Usability): 적절성 인식성, 학습성, 운영성, 사용자 오류 방지성, 인터페이스 심미성, 접근성
5. 신뢰성 (Reliability): 성숙도, 가용성, 무결함성, 복구 가능성
6. 보안성 (Security): 기밀성, 무결성, 부인 방지성, 책임 추적성(Audit Trail), 진정성
7. 유지보수성 (Maintainability): 모듈성, 재사용성, 분석성, 수정성, 테스트 용이성
8. 이식성 (Portability): 적응성, 설치성, 대체성
9. 안전성 (Safety): 시스템 운영 중 인명이나 환경에 위해를 끼치지 않는 안전성

---

3. 표준의 핵심 철학: "측정 함수는 주어지지만, 목표값(Target)은 아키텍트의 몫이다"

많은 엔지니어들이 국제 표준을 오해합니다. "표준을 보면 권장 응답 속도나 허용 장애 시간이 나와 있겠지?"라고 생각하는 것입니다. 하지만 표준 문서를 아무리 뒤져봐도 "응답 속도는 1초 이하여야 한다" 같은 숫자는 결코 나오지 않습니다.

ISO/IEC 25023이 제공하는 것은 정량적 측정 함수입니다.

응답 시간 적정성(Time Behaviour Adequacy) 측정 함수

$$X = \frac{A}{B}$$

• $A$: 실제 시스템에서 계측된 평균 응답 시간 (Actual Mean Response Time)
• $B$: 비즈니스 요구사항에 명시된 목표 응답 시간 (Target Response Time)
• 합격 판정 기준: $X \le 1.0$ (목표 만족), $X > 1.0$ (목표 미달)

표준은 왜 $B$의 구체적인 수치를 못 박아두지 않았을까요? 도메인과 비즈니스 환경에 따라 시스템에 요구되는 합격선이 완전히 다르기 때문입니다.

[도메인에 따른 목표값 B의 극단적 차이]

1. 증권 초단타 매매 시스템 (HFT / Order Execution)
   - 목표 응답 시간 B = 10ms ~ 50ms
   - 100ms 지연은 수억 원의 금융 손실 직결 ──▶ 메모리 인메모리 아키텍처, 커널 바이패스 필수

2. 사내 총무팀 비품 신청 게시판 (Internal Backoffice)
   - 목표 응답 시간 B = 2,000ms (2초)
   - 사용자가 2초를 기다려도 비즈니스 영향 전혀 없음 ──▶ 고비용 인메모리 캐시 도입 불필요

동일한 $X = A / B$ 측정 공식을 사용하더라도, 비즈니스 목적에 부합하는 적정 목표치 $B$를 결정하고 타협점을 찾아내는 것은 시스템 아키텍트의 고유한 권한이자 책임입니다.

---

4. 품질 목표가 설계를 강제한다: 아키텍처 드라이버와 텍틱(Tactics)

품질 요구사항이 수치와 조건으로 구체화되어 시스템 구조에 결정적인 영향을 미치게 될 때, 이를 아키텍처 드라이버(Architectural Driver)라고 부릅니다.

목표값($B$)이 명확해야만, 그 목표를 달성하기 위한 구체적인 설계 전략인 아키텍처 텍틱(Tactics)이 비로소 도출됩니다.

[품질 목표에서 프로덕션 배포까지의 엔지니어링 루프]

+-------------------------------------------------------------+
| 1. 모호한 비기능 요구 식별 ("빠르고 장애 없는 시스템")      |
+-------------------------------------------------------------+
                              │
                              ▼
+-------------------------------------------------------------+
| 2. SQuaRE 표준 매핑 (ISO 25010 성능/신뢰성, ISO 25023 함수) |
+-------------------------------------------------------------+
                              │
                              ▼
+-------------------------------------------------------------+
| 3. 구체적 조건 & 수치 목표 설정 (ISO 25030)                 |
|    - 부하 조건: 500 TPS 동시 요청                           |
|    - 성능 지표: P95 ≤ 500ms, Error Rate ≤ 0.1%              |
+-------------------------------------------------------------+
                              │
                              ▼
+-------------------------------------------------------------+
| 4. 아키텍처 드라이버 확정 & 설계 텍틱(Tactics) 도출        |
|    - Redis 캐시 도입, Read Replica 분리, 커넥션 풀 튜닝    |
+-------------------------------------------------------------+
                              │
                              ▼
+-------------------------------------------------------------+
| 5. 구현 & 자동화 하네스 검증 (k6, Chaos Engineering)        |
+-------------------------------------------------------------+
                              │
               ┌──────────────┴──────────────┐
               ▼                             ▼
       [목표 미달 (X > 1)]           [목표 달성 (X ≤ 1)]
               │                             │
               ▼                             ▼
     설계 텍틱 재검토 & 튜닝       검증 완료(DoD 달성) & 배포

실무에서 자주 쓰이는 3대 비기능 품질 특성을 모호한 요구에서 검증 가능한 아키텍처 드라이버로 변환한 사례를 살펴보겠습니다.

실무 3대 품질 특성의 구체화 변환표

분류	모호한 일상어	ISO 25010 품질 특성	검증 가능한 품질 목표 (Verifiable Goal)	도출되는 아키텍처 텍틱 (Tactics)	자동화 검증 방법
성능	"빠르게 만들어 주세요."	성능 효율성 $\to$ 시간 효율성	"정상 부하 500 TPS 환경에서, 주문 생성 API의 P95 지연 시간은 500ms 이하여야 하며 오류율은 0.1% 미만이어야 한다."	• Redis 인메모리 캐싱 • DB 슬레이브 분기 & 복합 인덱스 • WAS 인스턴스 수평 스케일아웃	k6, nGrinder 부하 테스트 스크립트 실행 후 메트릭 리포트 자동 생성
가용성	"장애가 절대 안 나게 해 주세요."	신뢰성 $\to$ 가용성, 복구 가능성	"월간 가용성을 99.95% 이상으로 유지하고, 단일 인스턴스 장애 시 평균 복구 시간(MTTR)은 10분 이내여야 한다." (월 누적 다운타임 22분 이내)	• 멀티 AZ(Multi-AZ) 액티브-스탠바이 이중화 • 헬스체크 기반 오토 페일오버 • 서킷 브레이커(Resilience4j)	카오스 엔지니어링 모의 장애 주입(Chaos Mesh) 및 페일오버 시간 계측
보안성	"보안을 최대한 강화해 주세요."	보안성 $\to$ 책임 추적성 (Accountability)	"관리자의 고객 개인정보 마스킹 해제 및 조회 행위에 대한 감사 로그 기록률을 100%로 보장해야 한다."	• AOP 기반 분산 감사 로그 미들웨어 • WORM(Write-Once) 불변 저장소 연동 • 변조 방지 SHA-256 해시 체인	1,000건 시뮬레이션 요청 후 중앙 감사 로그 DB와 1:1 대조 자동 검증

---

5. AI 코딩 에이전트 시대의 하네스 설계: Verifiable Definition of Done

최근 엔지니어링 현장에서 가장 뜨거운 화두는 AI 코딩 에이전트(Claude Code, Codex, Cursor 등)에게 작업을 위임하는 방식입니다. 여기서도 동일한 원리가 적용됩니다.

"성능 좋게 해줘"가 부르는 AI 재앙

에이전트에게 "주문 API 성능 좀 빠르게 개선해줘"라고 지시하면 어떤 일이 벌어질까요?

1. 자의적 과잉 엔지니어링 (Over-engineering): 아직 병목이 확인되지도 않았는데 복잡한 비동기 큐와 분산 락, 다단계 캐시를 무차별 도입해 코드 복잡도만 폭증시킵니다.
2. 환각 및 엉성한 코드 양산: 실제로 성능이 개선되었는지 확인하지 않고, 그럴듯해 보이는 최적화 라이브러리만 임포트하고 작업을 마쳤다고 선언합니다.
3. 완료 판단(DoD)의 불가능: 에이전트 스스로도 코드가 목표를 충족했는지 알 수 없고, 지시한 인간 엔지니어도 PR을 일일이 뜯어보며 의심해야 합니다.

소프트웨어 명저 Choose Boring Technology의 저자 댄 맥킨리(Dan McKinley)는 이를 두고 "측정(Eval) 없는 프롬프트 전달은 환상에 불과하다"고 갈파했습니다.

"The textual nature of prompts leads us to take the intentional stance towards systems which aren’t conscious, and thus miss the essential nature of their non-meaning."
(프롬프트가 텍스트 형태라는 이유로 우리는 의식 없는 시스템에 '의도'가 통할 것이라 착각하며, 그 텍스트가 본질적으로 기계적 확률 벡터에 불과하다는 사실을 망각한다.)
— Dan McKinley

확률론적 LLM에게 주관적 형용사를 전달하면 모델은 통계적 잠재 공간에서 표류합니다. 반면, 결정론적인 수치 기준과 테스트 하네스(Harness)를 주입하면 에이전트는 기계적으로 목표에 수렴(Convergence)합니다.

프롬프트 비교: 모호한 프롬프트 vs 검증 가능한 하네스 프롬프트

[Bad Prompt: 모호한 자연어 지시]
"주문 생성 API(POST /api/v1/orders)가 좀 느린 것 같아. 성능 좋게 최적화해줘."

[Good Prompt: SQuaRE 기반 Verifiable DoD와 하네스 주입]
당신은 백엔드 성능 최적화 에이전트입니다. 아래 조건과 검증 하네스에 따라 작업을 완수하십시오.

1. 실행 환경: 로컬 도커 테스트 환경 (CPU 2코어, 4GB RAM)
2. 대상 컴포넌트: POST /api/v1/orders (주문 생성 트랜잭션)
3. 품질 목표 (ISO/IEC 25023 시간 효율성):
   - 정상 부하 500 TPS 주입 시 P95 응답 시간 ≤ 500ms
   - HTTP 5xx 에러율 ≤ 0.1%
4. 작업 절차:
   Step 1. 제공된 부하 테스트 스크립트(`npm run test:load:order`)를 실행해 현재 기준선(Baseline) 계측
   Step 2. 쿼리 실행 계획(EXPLAIN ANALYZE) 점검, 인덱스 보완, 필요 시 Redis 캐시 계층 설계 적용
   Step 3. 동일한 부하 테스트 스크립트를 재실행하여 메트릭 확인
   Step 4. P95 ≤ 500ms 및 에러율 ≤ 0.1%를 만족할 때까지 튜닝 루프 반복
   Step 5. 목표 달성 전후의 지표 비교표(Latency P50/P95/P99, RPS, Error%)를 작성하고 작업 완료 선언

이렇게 지시하면 에이전트는 환각에 빠지지 않습니다. 부하 테스트를 실행하고, 목표치 $X = A / B \le 1.0$에 도달할 때까지 스스로 코드를 수정하고 계측하는 자기 교정 루프(Self-Correction Loop)를 돌게 됩니다.

---

6. 결론: 코드 작성자에서 '품질 목표와 하네스 아키텍트'로

경영학의 구루 피터 드러커(Peter Drucker)와 소프트웨어 공학의 선구자 톰 드마르코(Tom DeMarco)는 시대를 관통하는 명언을 남겼습니다.

"측정할 수 없으면 관리할 수 없고, 관리할 수 없으면 개선할 수 없다."
(If you can't measure it, you can't manage it, and you can't improve it.)

AI가 몇 초 만에 수백 줄의 코드를 쏟아내는 시대입니다. 단순히 키보드로 코드를 빠르게 타이핑하는 능력은 더 이상 엔지니어의 핵심 경쟁력이 아닙니다.

1. 형용사를 숫자로 바꾸는 능력: 모호한 비즈니스 요구사항을 ISO/IEC 25000 SQuaRE 체계를 활용해 객관적이고 측정 가능한 품질 목표로 전환하는 역량
2. 목표에 맞는 텍틱을 설계하는 능력: 도메인 비용과 리스크를 계산하여 합리적인 목표값($B$)을 정의하고, 이를 달성하기 위한 아키텍처 드라이버를 도출하는 역량
3. AI를 통제하는 하네스를 구축하는 능력: 확률론적 LLM 코딩 에이전트가 주관적 방황을 멈추고 객관적 지표에 수렴할 수 있도록 검증 스크립트와 DoD를 엄격하게 설계하는 역량

앞으로의 소프트웨어 엔지니어링은 "코드를 짜는 일"에서 "검증 가능한 품질 목표를 세우고, 이를 기계적으로 평가할 수 있는 하네스 아키텍처를 설계하는 일"로 무게중심이 이동하고 있습니다.