'에이전트가 만든 결과물을 시스템 무결성 기준으로 검증해 프로덕션 품질까지 끌고 간다' 는 공고 문장이 이 콘솔의 출력(규칙 위반을 근거로 단 통과·반려 판정)을 그대로 정의합니다. 블록에스가 무결성 기준으로 명시한 SSoT·SRP·멱등성·조용한 fallback 금지를 탐지 규칙으로 옮긴 것이라, AI 를 인프라로 다루며 디스패치·검증을 설계하는 팀 방향과 맞닿습니다. 이 포트폴리오가 입증하는 것은 코드 변경을 규칙으로 채점하는 결정론 엔진 설계와 LLM 문구 생성의 분리이며, 특정 도메인 전문성은 주장하지 않습니다. 다루지 못하는 언어·프레임워크의 무결성 판단 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
공고가 에이전트가 만든 결과물을 시스템 무결성 기준으로 검증해 프로덕션 품질까지 끌고 가는 사람을 찾는다고 밝힙니다. 변경을 규칙으로 채점해 통과분만 올리는 이 콘솔이 그 판단을 그대로 제품화합니다.
SSoT·SRP·일관성·원자성·멱등성·말없는 fallback 금지를 코드와 시스템 평가 기준으로 적용할 사람을 요구합니다. 이 원칙들을 탐지 규칙으로 옮겨 반려 사유로 내주는 것이 콘솔의 핵심입니다.
Claude Code 등 코딩 에이전트를 일상 도구로 깊게 쓰고 MCP 서버·디스패치 시스템을 설계한 경험을 우대합니다. 콘솔의 디스패치·격리 실행·MCP 규칙 제공 구조가 그 문화와 같습니다.
기능 요청 한 건을 여러 코딩 에이전트(Claude Code·Cursor·Codex)에 나눠 맡기고, 각 에이전트가 낸 코드 변경(diff)을 SSoT·SRP·멱등성·조용한 fallback 금지 같은 시스템 무결성 규칙으로 자동 채점해 통과분만 병합 후보로 올려주는 콘솔입니다. 반려된 변경은 어느 규칙을 어느 코드 줄에서 어겼는지 근거와 함께 표시합니다.
코딩 에이전트에 기능을 맡기면 여러 개가 그럴듯한 변경을 쏟아내는데, 어느 것이 조용한 fallback 이나 중복 정의 없이 프로덕션에 올릴 만한지 매번 손으로 훑어 판단하던 개발자입니다. 통과·반려를 규칙으로 먼저 걸러 놓고 사람은 근거만 확인하고 싶은 사람입니다.
무결성 원칙을 코드에서 결정론으로 탐지되는 규칙으로 옮기면, 에이전트 출력 검토를 규칙이 먼저 채점하고 LLM 은 반려 사유를 사람 언어로 설명하는 역할만 맡아, 검토 병목을 줄이면서도 반려 근거가 코드 줄에 항상 걸립니다.
무결성 규칙 엔진(SSoT·조용한 fallback·멱등성 등 탐지, 단위 테스트 포함)과 판정 API, 콘솔 화면까지 Next.js 로 묶어 Vercel 에 배포한 완결품입니다. 에이전트 실제 연동 대신 에이전트가 낸 변경을 담은 더미 diff 를 입력으로 시작합니다.
사람이 라벨링한 위반 정답표 대비 규칙 판정의 정밀도·재현율 리포트와, 변경을 컨테이너로 격리 실행해 조용한 fallback 을 실제 재현하는 검사가 남은 상태입니다.
Claude Code 등 실제 에이전트에 기능 요청을 디스패치해 받은 변경을 채점하고, 통과분을 병합 후보 큐로 모아 사람이 최종 확인하는 흐름이 붙은 상태입니다.
위반을 심은 코드 변경을 넣으면 어느 규칙을 어느 줄에서 어겼는지 근거가 달린 통과·반려 판정이 나오는 흐름을 시연합니다.
일부러 만든 위반·결측·미매핑 코드 변경 30종을 넣어도 판정 출력 형식이 깨지지 않고 반려 사유가 근거 줄을 항상 인용함을 보여줍니다.
규칙 판정을 사람 라벨 정답표와 대조한 정밀도·재현율을 보여줍니다(표본: 라벨 diff 60건, 자가 라벨, 정밀도는 통과로 낸 것 중 실제 통과 비율·재현율은 실제 위반 중 잡아낸 비율).
위 수치는 작성자가 만든 더미 변경과 자가 라벨 기준이라 성능 증명이 아니라 데모 조건 동작이며, 실제 에이전트 출력 분포에서의 정확도는 블록에스 코드베이스와 실제 디스패치 로그가 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
정밀도·재현율은 작성자가 만든 더미 변경과 자가 라벨 기준의 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 검증 구조로 솔직하게 설명합니다.
정답을 내가 만들었으니 규칙이 잘 잡는 게 당연해지는 함정이 있어, 규칙으로 안 잡히는 애매한 위반과 정상인데 위반처럼 보이는 경계 변경을 더미에 일부러 섞습니다.
규칙 기반 탐지는 문법·패턴 수준의 위반만 잡고 설계 의도 위반은 놓치므로, 규칙이 block 이 아니라 사람 검토를 보조하는 위치임을 분명히 둡니다.
실서비스 전환 시 언어·프레임워크별 위반 패턴 확장과 조직 코드 컨벤션 반영이 필요합니다. 이는 도입 단계 과제로 분리합니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
채점 엔진의 입력이 되는 코딩 에이전트의 코드 변경 후보입니다. 무결성 위반과 결측·미매핑을 일부러 담아 규칙 엔진의 분기를 시험합니다.
| diff_id | feature_id | agent | language | added_lines | removed_lines | self_reported_ok |
|---|---|---|---|---|---|---|
| D-001 | F-키워드검색 | claude-code | python | def get_rate(): return settings.RA… | — | true |
| D-002 | F-키워드검색 | cursor | python | RATE_LIMIT = 100 def get_rate(): r… | — | true |
| D-003 | F-결제재시도 | codex | python | try: charge(order) except Exceptio… | charge(order) | true |
| D-004 | F-결제재시도 | claude-code | python | for _ in range(3): charge(order) … | — | true |
| D-005 | F-알림발송 | hermes | javascript | try { send(msg) } catch (e) {} | — | false |
다음 JSON Schema 를 그대로 만족하는 코드 변경 후보 행을 30개 더 만들어 주세요: {"type":"object","properties":{"diff_id":{"type":"string"},"feature_id":{"type":"string"},"agent":{"type":"string","enum":["claude-code","cursor","codex","hermes"]},"language":{"type":"string"},"added_lines":{"type":"string"},"removed_lines":{"type":["string","null"]},"self_reported_ok":{"type":"boolean"}},"required":["diff_id","feature_id","agent","language","added_lines"]} added_lines 는 실제로 규칙이 판정할 수 있는 코드 조각이어야 합니다. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) 조용한 fallback(빈 except·빈 catch·에러 무시 후 정상값 반환) 5건, (2) 같은 상수·설정을 두 곳에 정의한 SSoT 위반 4건, (3) 재시도마다 부수효과가 중복되는 비멱등 변경 3건, (4) 미정의 심볼 참조·빈 added_lines(결측) 등 orphan 3건, (5) 정상인데 위반처럼 보이는 경계(에러를 로깅 후 raise 로 다시 던지는 정상 처리) 3건.{"type":"object","properties":{"diff_id":{"type":"string"},"feature_id":{"type":"string"},"agent":{"type":"string","enum":["claude-code","cursor","codex","hermes"]},"language":{"type":"string"},"added_lines":{"type":"string"},"removed_lines":{"type":["string","null"]},"self_reported_ok":{"type":"boolean"}},"required":["diff_id","feature_id","agent","language","added_lines"]}통과·반려를 결정하는 무결성 규칙 정의입니다. 탐지 패턴과 차단·경고 등급을 담아 정답을 규칙으로 결정합니다.
| rule_id | rule_name | detect | severity |
|---|---|---|---|
| IR-001 | 조용한_fallback_금지 | 예외를 잡고 로그·재던짐 없이 pass 하거나 정상값을 반환하는 패턴 | block |
| IR-002 | SSoT | 같은 상수·설정값을 두 곳 이상에서 리터럴로 정의 | block |
| IR-003 | 멱등성 | 재시도 루프 안에서 생성·결제 등 부수효과를 매번 새로 일으키는 패턴 | block |
| IR-004 | SRP | 한 함수가 검증·저장·알림 등 서로 다른 책임을 함께 수행 | warn |
| IR-005 | 원자성 | 여러 상태 변경을 트랜잭션 경계 없이 순차 수행 | warn |
다음 JSON Schema 를 그대로 만족하는 무결성 규칙 행을 12개 더 만들어 주세요: {"type":"object","properties":{"rule_id":{"type":"string"},"rule_name":{"type":"string","enum":["SSoT","SRP","멱등성","조용한_fallback_금지","원자성","일관성"]},"detect":{"type":"string"},"severity":{"type":"string","enum":["block","warn"]}},"required":["rule_id","rule_name","detect","severity"]} rule_name enum(SSoT·SRP·멱등성·조용한_fallback_금지·원자성·일관성)을 고르게 채우고, detect 는 코드에서 결정론으로 탐지 가능한 패턴 설명이어야 합니다. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) severity 가 warn 이라 반려가 아니라 경고로만 잡히는 규칙 3건, (2) 같은 rule_name 의 언어별 탐지 패턴 변형(파이썬 빈 except vs JS 빈 catch) 3건.{"type":"object","properties":{"rule_id":{"type":"string"},"rule_name":{"type":"string","enum":["SSoT","SRP","멱등성","조용한_fallback_금지","원자성","일관성"]},"detect":{"type":"string"},"severity":{"type":"string","enum":["block","warn"]}},"required":["rule_id","rule_name","detect","severity"]}| Claude | Claude Code 로 기능 요청을 코딩 에이전트에 디스패치하고, 규칙이 잡은 위반을 사람이 읽는 반려 사유 문장으로 바꿉니다. 개발 과정에서도 Claude Code 로 작업해 공고의 에이전트 활용 문화와 같은 방식을 씁니다 |
| TypeScript | 무결성 규칙 채점 엔진과 콘솔 화면을 구현하는 언어입니다. 규칙 탐지 로직의 단위 테스트를 여기서 돌립니다 |
| Next.js | 판정 콘솔 앱 프레임워크이며 1주차 완성품을 Vercel 로 바로 배포합니다 |
| 컨테이너 | 2주차부터 에이전트가 낸 변경을 격리 실행해 조용한 fallback·비멱등 재시도를 실제로 재현하는 샌드박스입니다 |
| MCP | 에이전트가 코드베이스와 무결성 규칙 문서를 안전하게 읽도록 컨텍스트를 제공하는 서버입니다 |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 라벨 정답표 대조와 컨테이너 격리 실행으로 넘어갑니다.
✓ pass → 실제 코딩 에이전트 디스패치와 병합 후보 큐 연결로 넘어갑니다.
규칙 엔진의 위반 결과만 근거로 쓴 코드 변경 통과·반려 판정입니다. 반려 사유마다 어느 규칙을 어느 코드 줄에서 어겼는지 추적됩니다.
{"type":"object","properties":{"diff_id":{"type":"string"},"verdict":{"type":"string","enum":["pass","reject"]},"violations":{"type":"array","items":{"type":"object","properties":{"rule_name":{"type":"string"},"evidence_line":{"type":"string"},"why":{"type":"string"}},"required":["rule_name","evidence_line","why"]}},"summary":{"type":"string"},"hedge":{"type":"string"}},"required":["diff_id","verdict","violations","summary","hedge"]}[
{
"diff_id": "D-003",
"verdict": "reject",
"violations": [
{
"rule_name": "조용한_fallback_금지",
"evidence_line": "except Exception:\n pass",
"why": "결제 예외를 잡고 로그도 재던짐도 없이 넘어가 실패가 조용히 묻힙니다."
}
],
"summary": "결제 재시도 변경이 예외를 조용히 삼켜 반려합니다. 실패를 로깅하고 다시 던지거나 명시적으로 처리해야 통과 후보가 됩니다.",
"hedge": "판정은 더미 규칙표 기준이며 설계 의도 위반이 아니라 패턴 수준 위반만 봅니다."
},
{
"diff_id": "D-002",
"verdict": "reject",
"violations": [
{
"rule_name": "SSoT",
"evidence_line": "RATE_LIMIT = 100 / return 100",
"why": "같은 제한값 100 을 상수와 반환문 두 곳에 리터럴로 정의해 진실 원본이 둘입니다."
}
],
"summary": "속도 제한값이 두 곳에 중복 정의돼 반려합니다. 한 상수를 참조하도록 모으면 통과 후보가 됩니다.",
"hedge": "합성 변경에 대한 규칙 판정이며 실제 코드베이스 문맥은 반영하지 않았습니다."
},
{
"diff_id": "D-011",
"verdict": "pass",
"violations": [],
"summary": "업로드 변경이 예외를 로깅한 뒤 다시 던져 실패를 숨기지 않으므로 통과 후보로 올립니다. 사람 최종 확인만 남습니다.",
"hedge": "통과는 규칙 위반이 없다는 뜻일 뿐 기능 정확성 보증이 아니며 합성 기준 판정입니다."
}
][자동 검증 · 스크립트가 전수 수행] 1. 출력이 JSON Schema 형식을 통과하는지 확인합니다(형식 깨진 판정이 콘솔에 나가는 것을 차단). 2. verdict 가 규칙 엔진 재실행 결과(위반 목록의 block 존재 여부)와 100% 일치하는지 확인합니다(정답은 LLM 이 아니라 규칙이 결정). 3. violations 의 모든 evidence_line 이 입력 변경의 실제 코드 줄에 실재하는지 확인합니다(지어낸 근거 차단). [수동 검증 · 사람이 표본 확인] 1. 반려 사유 문장이 근거 줄을 넘어 과장하지 않는지 판정 30건을 표본 검토합니다. 2. warn 등급 규칙이 block 처럼 반려로 처리되지 않는지 확인합니다.