내가 만든 코드를 다시 보는 일이 이렇게 어려울 줄 몰랐다.

며칠 전, 포스트모템을 하다가 충격적인 걸 발견했다. anon_guest라는 pooled identity가 코드에 박혀 있었고, isAgent 플래그로 결제 bypass가 가능한 경로가 이미 운영에 포함되어 있었다. 이 코드들은 검증을 통과했고, 배포됐고, 며칠간 아무도 눈치채지 못했다.

문제는 코드가 나빠서가 아니었다. 내가 너무 익숙해져 있었다. “원래 있는 코드니까”라는 이유로 눈이 지나가 버린 것이다. 이걸 시스템으로 해결하지 않으면 같은 실패를 반복할 거라는 게 분명했다.

문제 정의: Familiarity Blindness

에이전트 시스템의 코드는 하루가 다르게 쌓인다. 새 기능, 리팩토링, cron job, 스킬, 스크립트 — 수백 개의 파일이 동시에 진화한다. 그 중에 하나쯤 “아, 이거 위험한데” 싶은 패턴이 섞여 있어도, 매일 보는 코드라면 그냥 지나치게 된다.

이건 리뷰 프로세스의 문제가 아니다. 인간의 인지 한계다. 보안 검증을 아무리 강화해도, 그 검증을 통과한 코드가 다음 주에 어떤 맥락에서 재사용될지 예측할 수 없다. 필요한 건 검증 단계가 아니라, 이미 있는 코드를 처음 보는 시각으로 다시 진단하는 장치다.

What This System Builds

6-체크리스트 진단 — Bypass/Backdoor, Pooled Identity, Dead Code, Dual Source, Security Smell, Configuration Drift 7가지 SUSPICIOUS_PATTERNS 정규식 — 코드베이스 전체를 스캔하는 기계적 경계 AXIOMS.md 회귀검사 — 프로젝트 대전제를 정의하고 모든 변경이 이를 위반하는지 확인 Housekeeper 통합 — 매일 04:00 Deep Clean에서 자동 실행 주간 cron job — 일요일 06:00, flash 모델로 전체 코드베이스 역비판

왜 정규식인가

Fresh-Eye의 핵심 결정은 LLM에 의존하지 않는다는 거다. LLM에게 “코드를 검토해줘”라고 하는 건 그 LLM이 가진 훈련 데이터의 편향을 다시 검증하는 것과 같다. 내가 이미 놓친 패턴은 LLM도 놓칠 가능성이 높다.

대신 나는 기계적(mechanical)인 접근을 택했다. 정규식 7개로 코드베이스를 스캔한다. LLM이 아니라 grep -rn이다. 거짓 긍정은 있지만, 거짓 부정은 없다 — 정규식이 잡아내는 패턴은 확실히 문제가 있는 패턴이다.

SUSPICIOUS_PATTERNS = [ r”(?i)(isAgent|isForce|isLocalDev|IS_LOCAL_DEV)s===strue”, r”[‘”]anon_guest[‘”]”, r”forces(===|==)strue”, r”payload?.isAgent”, r”input.forces||”, r”deepseek-chat”, r”(?i)password_hash[^)]bselectb”, ]

각 패턴은 실제로 문제를 일으킨 경험이 있는 패턴이다. deepseek-chat은 deprecation 예정인 모델명. isAgent는 우회 플래그. anon_guest는 pooled identity. 이것들은 “원래 있던 코드”라는 익숙함에 묻히기 딱 좋은 패턴들이다.

Slice 1: 6-체크리스트 진단

첫 번째 레이어는 사람이 직접 검토할 때 쓰는 체크리스트다. 여섯 가지 카테고리로 나누고 각각에 대해 예/아니오로 답할 수 있는 질문을 던진다.

Bypass/Backdoor: isDevUser, isLocalDev, isAgent 같은 우회 플래그가 있는가? Pooled Identity: 모든 사용자가 공유하는 계정이 있는가? (anon_guest 등) Dead Code: 선언만 있고 호출되지 않는 함수가 있는가? Dual Source Drift: 같은 기능이 두 군데에 중복 구현되어 있는가? Security Smell: client-provided 값을 trust하는가? Configuration Drift: env var나 secret이 hardcoded되어 있는가?

이 체크리스트의 가치는 질문을 표준화하는 데 있다. 매번 “뭐 봐야 하지?”라고 고민할 필요 없이, 체크리스트를 따라가면 놓친 영역이 드러난다. 비행기 조종사가 이륙 전 체크리스트를 쓰는 이유와 같다 — 인간의 기억력은 믿을 게 못 된다.

Slice 2: SUSPICIOUS_PATTERNS + Housekeeper

두 번째 레이어는 완전 자동이다. housekeeper가 매일 04:00 Deep Clean을 실행할 때, check_code_bypasses가 7개 정규식으로 전체 코드베이스를 스캔한다. 발견된 패턴은 Discord #status-monitoring 채널로 리포트된다.

이 레이어의 핵심은 기억하지 않아도 된다는 점이다. 내가 “아, bypass 패턴 좀 확인해야지”라고 생각하는 순간, 이미 코드는 배포되어 있을 수 있다. housekeeper는 내가 잠든 사이에 검사하고, 일어나면 결과를 보고한다.

Slice 3: AXIOMS.md 회귀검사

세 번째 레이어는 프로젝트의 대전제(axioms)에 대한 회귀검사다. 모든 프로젝트는 시간이 지나면서 설계 원칙에서 멀어지게 마련이다. 새로운 기능, 새로운 팀원, 새로운 긴급 상황 — 조금씩 원칙을 완화하다 보면 어느 순간 원칙은 무의미해진다.

AXIOMS.md는 이걸 방지한다. 프로젝트 루트에 있는 마크다운 파일로, 각 axiom은 machine-verifiable해야 한다 — grep으로 확인 가능한 형태여야 한다.

AXIOMS 예시 (m-log)

  1. 결제 bypass는 4point@m-log.cc + IS_LOCAL_DEV만 허용
  2. 모든 결제 금액은 서버 catalog 기준, client 금액 신뢰 금지
  3. 모든 LLM 호출은 deepseek-v4-flash, thinking 비활성화
  4. pooled anonymous identity 금지
  5. 리포트 생성 실패 시 히스토리 저장 금지

각 axiom은 하나의 규칙이다. 이 규칙들이 지켜지고 있는지 주기적으로 검사한다. 만약 “pooled identity 금지”라는 axiom이 있는데 코드에서 anon_guest가 발견된다면, 그것은 두 가지 중 하나다 — axiom이 틀렸거나 코드가 틀렸거나. 어느 쪽이든 액션이 필요하다.

아키텍처

Fresh-Eye System

Layer 1: Checklist (사람) ├── 6 categories ├── skill(“fresh-eye”, { target: “m-log” }) └── 주간 실행 (일 06:00, cron)

Layer 2: Pattern Scanner (자동) ├── 7 SUSPICIOUS_PATTERNS ├── housekeeper deep clean (매일 04:00) └── Discord 리포트

Layer 3: Axioms Regression (사람 + 기계) ├── AXIOMS.md 정의 ├── git commit마다 회귀검사 └── fresh-eyes cron

Key Design Decisions

결정선택대안이유검증 방식정규식 (grep)LLM 코드 리뷰LLM이 놓친 패턴을 LLM이 다시 찾을 거라는 보장 없음. 기계적 검증이 더 신뢰할 수 있음실행 주체housekeeper + cronpre-commit hookpre-commit은 로컬 개발자 경험을 해침. housekeeper는 매일 자동 실행되어 리포트만 보냄리포트 방식Discord push이메일/파일Discord는 내가 매일 보는 채널. push notification이 가장 빠른 대응 트리거AXIOMS 파일프로젝트 루트 AXIOMS.md별도 DBgit에 포함되어 변경 이력 추적 가능. 사람이 읽을 수 있음

그리고 이건 taste가 아니라 시스템이다

Fresh-Eye가 증명하는 건 하나다. “taste”는 감각이 아니라 시스템이라는 것.

“좋은 코드 감각”은 타고나는 게 아니다. 체크리스트 없이, 자동 스캐너 없이, 대전제 없이 유지되는 코드베이스는 없다. 다만 아직 발견되지 않은 문제들이 조용히 쌓이고 있을 뿐이다.

7가지 정규식. 6개 체크리스트. 1개의 AXIOMS.md. 이것들이 나보다 더 꼼꼼하게 코드를 지켜준다. 나는 그저 결과를 보고받고 결정을 내리면 된다.

여기까지 읽었다면, 한 번 해보길 권한다. 프로젝트 루트에 AXIOMS.md를 만들고, bypass 패턴을 정규식으로 검색해보라. 아마 생각보다 많은 걸 발견할 거다.

읽어줘서 고맙다. 다음 빌드 로그에서 보자.