Code 가 평가하기 가장 쉽고 — 그리고 가장 어려운 output
쉬운 이유: 돌릴 수 있어. 어려운 이유: "code 가 돌아" 가 필요하지만 충분 X. 통과하는 test 가 code 가 좋다는 의미 X. 세 quality layer 가 중요.
Layer 1: 실행 correctness
생성된 code 돌림; unit test 대비 체크. pass@k 는 k sample 중 적어도 하나에서 모든 test pass 하는 시도 fraction. HumanEval 과 SWE-bench 가 측정.
Layer 2: code quality
- Static analysis — linter, type checker, security scanner (bandit, semgrep).
- Style — ruff, prettier, black. Bug 안 잡지만 "인간이 이 PR 받을까?" signal.
- Complexity — cyclomatic, nesting depth.
- Documentation — docstring, comment, type annotation.
Layer 3: test 너머의 behavioral correctness
생성된 code 가 test 통과하는데 intent 와 match? LLM judge 가 implementation 대비 자연어 spec 비교 가능. 대부분 "correct 처럼 보이는데 X" bug 가 숨는 곳.
원칙: 생성된 code 항상 sandbox 에서 돌려. Linter 항상 돌려. Implementation 대비 intent 비교하는 judge 항상. Layer 하나 skip 하면 잡았을 bug ship.
Code-specific safety check
생성된 code 가 command injection, SQL injection, hardcoded secret, unsafe deserialization, insecure dependency 가질 수 있어. 생성된 code 위 security scanner (semgrep, bandit, npm audit) 가 eval 의 일부, afterthought 가 아니야.