다층 LLM 리뷰를 '효과적인 시스템'으로 만들기 — SKILLS를 늘리기 전에 해야 할 3가지 투자

• SDLC의 각 단계에 **전문 SKILL(BA / Sec / Perf / Arch / DBA / QA / Ops / Compliance)**을 배치하여 다층 리뷰를 수행한다는 구상은 그림으로 그리면 아름답다. 하지만 SKILLS를 늘리는 것만으로는 결과물의 입도(granularity)가 올라가지 않는다. - 효과적으로 만들기 위해서는 SKILLS의 앞단에 Grounding × 결정론적 판정 × 실행 루프라는 3가지를 정비할 필요가 있다. - 본 기사는 전반부에서 그 3가지 원칙을 일반론으로서 설명하고, 후반부에는 필자가 직접 만든 OSS에 적용한 사례를 사례로 제시하는 구성으로 되어 있다. - 결론: SKILL을 늘리는 것은 마지막에 해도 된다. 그보다 앞서 해야 할 투자가 있다.

LLM을 SDLC(Software Development Life Cycle)의 각 단계에 통합하여, 요구사항 → 설계 → 구현 → 테스트 → 릴리스의 각 단계에서 복수의 전문 SKILL이 리뷰하게 한다는 구상이 최근 자주 논의되고 있다.

그림으로는 매력적이다. 각 관점의 전문 SKILL이 PR(Pull Request)에 코멘트를 남기고, "모든 관문을 통과한 것만이 릴리스된다"는 다층 가드(multi-layered guard)의 세계관.

하지만 이를 그대로 구축하면, LLM이 자신만만하게 승인한 PR이 실제로 배포했을 때 망가져 있는 사고가 흔히 발생한다. 원인은 대개 다음 중 하나다.

Grounding이 부족함: 고객 고유의 제약 사항, 사내 표준, 과거 사례를 전달하지 않기 때문에, SKILL이 "일반론적으로는 맞지만 현장과는 맞지 않는" 제안을 함

판정이 LLM의 주관에 의존: Pass/Fail을 LLM이 결정하게 하므로, LLM이 "적절하다고 판단합니다"라고 쓰면 그대로 통과됨

실행되지 않음: 정적 리뷰(Static Review)로만 판정하고 있어, 실제로 돌려보지 않으면 알 수 없는 문제를 놓침

SKILLS를 늘리는 것은 이 3가지를 정비한 후에도 늦지 않다. 정비하기 전에 SKILLS만 두텁게 만들면, 자신감 있는 오류를 대량 생산하는 장치가 만들어질 뿐이다.

이하, 3가지 투자를 각각 살펴보겠다.

SKILL이 현장에 맞지 않는 제안을 하는 것은 SKILL이 나빠서가 아니라,

현장의 정보를 전달하지 않았기 때문이다.

LLM은 주어진 컨텍스트(Context)의 범위 내에서만 생각할 수 있다. "기존 자산이 있는지", "사내 규칙은 어떠한지", "과거 유사한 안건에서 무엇을 결정했는지"를 전달하지 않으면, SKILL은 매번 제로 베이스에서 일반론만을 답변한다.

Grounding으로서 전달해야 할 정보는 크게 3가지 종류가 있다.

과거 안건에서 "어떤 논점으로", "어떻게 판단했는지", "왜 그렇게 판단했는지"를 구조화하여 축적하고, 유사 안건에서 참조할 수 있도록 한다.

# 축적되는 1개 안건의 예
case_id: 2025-q4-fintech-api
industry: financial
...

Embedding 하여 유사 검색이 가능하도록 해두면, SKILL 리뷰 시에 "업종 × 패턴에 따라 과거에 어떻게 결정했는지"를 전달할 수 있다. SKILL은 일반론이 아니라 "자사의 과거 판단과의 정합성"을 이야기할 수 있게 된다.

히어링(Hearing)이나 요구사항 정의 단계에서, 기존 자산 프로필을 구조화된 입력값으로 받는다.

항목	필요한 이유
기존 인프라	기존 환경과 일치하지 않는 제안을 방지
...

이것이 없는 상태에서 SKILL을 늘려봤자, SKILL이 늘어난 만큼 "일반론적으로는 맞지만 현장과는 맞지 않는 지적"만 늘어날 뿐이다.

사내 규칙을 YAML 등으로 구조화하여 보유하고, LLM 프롬프트의 서두에 Dump 한다.

naming:
  pattern: "{env}-{service}-{resource}-{seq}"
tagging:
  ...

이것을 서두에 두는 것만으로도, LLM이 "멋대로 베스트 프랙티스(Best Practice)를 발명하는" 현상이 대폭 감소한다. SKILL의 리뷰 지적도 "베스트 프랙티스 측면에서는 이렇다"가 아니라 "사내 표준에서는 이렇다"라는 구체성을 갖게 된다.

SKILL은 "지적 사항 생성", "위반의 의미를 자연어로 설명", "리팩터링(Refactoring) 제안"에만 사용한다. Pass/Fail을 결정하는 것은 LLM이 아니라 기계로 한다.

LLM SKILL에게 "보안상 문제없습니다"라고 쓰게 하여 Pass로 처리하는 운용은 구조적으로 무너진다. LLM은 설득력 있는 문장을 쓰는 데 능숙하기 때문에, 틀렸더라도 통과되어 버린다.

판정은 결정론적인(Deterministic) 도구에 맡긴다.

영역	NG: LLM 주관 판정	OK: 기계 판정
보안	「설정이 적절하다고 판단」	정적 분석 도구의 위반 0
...

그 위에, 각 결과물 패턴이 "통과해야 할 기계 체크 (Machine Check)"를 스스로 정의하는 형태로 만든다.

# 패턴별 통과 조건(예)
acceptance_criteria:
static_analysis:
...

LLM은 이를 만족하는 코드를 생성하고, CI가 이를 판정하는 분업 구조가 된다.

게이트(Gate)의 Pass/Fail은 CI로 이양한다:

.github/workflows/
├── gate-2-design.yml # 설계서 lint, schema 검증
├── gate-3-implementation.yml # 정적 분석, lint, 타입 체크
...

LLM SKILL은 PR 코멘트로 지적을 남기는 역할. 「통과/미통과」는 CI의 결정론적 (Deterministic) 결과이다. 이것만으로도 「LLM의 인상에 따라 품질이 변하는」 현상이 사라진다.

정적 리뷰로는 잡을 수 없는 것

실행 시의 문제를 본방 투입 전에 포착하는 메커니즘.

정적 분석이나 LLM 리뷰는 「코드를 읽어서 알 수 있는 것」만 포착할 수 있다. 반면, 실제 시스템에서 발생하는 문제의 상당수는 「돌려보지 않으면 알 수 없는」 것들이다: 실행 권한, 레이턴시 (Latency), 초기화 순서, 의존 서비스와의 결합, etc.

PR 단위로 일회성 검증 환경을 할당하여, 자동 배포 → 검증 → 폐기한다.

# CI 설정 개요
on: pull_request
jobs:
...

이를 통해 「실제 환경에서 처음 알게 되는 문제」가 PR 단계에서 표면화된다.

샌드박스(Sandbox) 실행에서 발생한 에러·경고를 새로운 판단 포인트로 기록하고, 원칙 1 (a)의 판단 로그에 축적한다.

# 자동 추가되는 예
runtime_findings:
- source: static_analysis
...

이를 통해 "실제 환경에서 실제로 무엇이 일어났는가"가 판단 로그에 축적되며, 다음 안건의 SKILL 리뷰로 전달된다 (원칙 1 (a)로 돌아감).

Grounding → 판정 → 실행 → Grounding의 루프가 닫힌다. 이것이 돌아가기 시작해야 비로소 시스템은 "안건을 처리할 때마다 똑똑해지는" 상태가 된다.

모든 게이트에 사람을 두지 마라. 두어야 할 곳에 두어라.

3가지 원칙을 정비한 후, 인간 리뷰의 배치를 결정한다.

게이트	주 판정	인간 리뷰
게이트 1: 요구사항	LLM (SKILL) + 고객 리뷰	필수 (전제 오류를 제거)
게이트 2: 설계	SKILL 다각화 + 과거 안건 RAG	권장 (불가역적 판단의 합의)
게이트 3: 구현	기계 판정	불필요 (차이점 리뷰만 수행)
게이트 4: 테스트	기계 판정	불필요
게이트 5: 릴리스	기계 판정 + 승인 권한	필수 (본방 투입은 불가역적)

설계의 핵심:

• 인간 리뷰의 밀도는 판단의 불가역성에 비례시킨다 - 게이트 3-4는 기계 판정만으로 통과할 수 있는 설계로 만들어, 인간이 개입하지 않도록 한다 (그렇지 않으면 인간이 병목(Bottleneck)이 된다).
• 단, 게이트 1과 5는 절대로 생략하지 않는다.

게이트 1을 생략하면 "상류의 오류를 하류에서 합리화하는" 사고가 발생한다. 요구사항 오인을 SKILL이 그대로引き継いだ(인계한) 채 설계·구현·테스트를 통과시키고, 릴리스 직전에 "애초에 요구사항이 틀렸었다"라고 깨닫는 패턴이다. 다층 SKILL 리뷰는 상류 오류를 발견하는 메커니즘이 아니다 (SKILL은 주어진 전제 안에서 최적화한다). 따라서 상류에 사람을 배치한다.

게이트 5를 생략하면, 기계 판정을 모두 통과한 코드가 그대로 본방에 나간다. 기계 판정은 「규칙을 위반하지 않았다」는 것만을 보증한다. 「지금 이 타이밍에 본방에 내보내도 되는가」를 판단하는 것은 여전히 인간의 업무다.

Phase A: Grounding 입력 확장
├ 기존 자산 스키마
├ 조직 지식 (Knowledge)
...

Phase D를 마지막에 배치한 것이 본 기사의 주장입니다. Grounding과 결정론적 판정, 그리고 실행 루프가 없는 상태에서 SKILL을 늘리는 것은, 자신감 있는 오류를 대량 생산하는 장치를 만드는 것과 같다.

SKILLS를 늘리기 전에 Grounding × 결정론적 판정 × 실행 루프를 정비하라.

Grounding (그라운딩): 과거의 판단, 기존 자산, 조직의 지식(Knowledge)을 SKILL에 전달한다 -
결정론적 판정 (Deterministic Judgment): Pass/Fail 여부는 LLM이 아닌 도구(Tool)가 결정하게 한다 -
실행 루프 (Execution Loop): 일회성 환경(Disposable Environment)에서 실행하고, 그 결과를 판단 로그(Judgment Log)로 되돌린다 -
SKILLS 정비: 이 단계에 이르러서야 비로소 다층 SKILL을 두텁게 쌓는 것이 의미를 갖는다

이것들이 갖춰져야 비로소, 그림의 세계관인 "LLM 다층 리뷰를 통해 품질·보안·신뢰성을 확보하고, 모든 관문을 통과한 프로젝트만 릴리스한다"가 기능하는 형태로 작동하게 된다는 것이 현시점의 결론입니다.

SKILL을 늘리고 싶어지는 마음은 충분히 이해합니다 (그림으로서도 이해하기 쉽고, 진척도 측면에서도 명확하기 때문입니다). 하지만 "그림으로서의 이해하기 쉬움"과 "시스템으로서 효과가 있는지 여부"는 별개의 문제라는 것이, 필자가 우회하며 얻은 교훈입니다.