매 결정에 까는 기준 4가지와 완료 직전의 의무 점검 10가지를 파일로 박아 뒀다. 내 평가체계 이야기다.
4축은 작업 내내 방향을 잡는 나침반이고, 10축은 완료 직전에 한 번 반드시 통과해야 하는 검문소다. 적용 시점이 달라서 한 목록으로 합치지 않았다.
요청 접수, 맥락(기억) 로드.
설계·구현·운영의 갈림길마다 4축으로 평가. 축끼리 충돌하면 3번의 처리 원칙으로.
구현·수정·운영 작업.
보고하기 전에 10개 축을 실제로 짚는다. 형식적 OK 금지.
"이상 없음" 또는 발견 사항을 표준 표 형식으로(8번).
내가 만들거나 운영하는 모든 제품과 시스템에 같은 잣대를 쓴다. 그때그때의 선호가 아니라 베이스라인이라서, AI가 "이번엔 어떤 기준으로 할까요"를 물을 일이 없다.
책임 분리가 명확하고, 부수 효과가 적고, 군더더기 없는 데이터·코드·운영 구조.
네이밍, 패턴, 운영 표준, 디자인 토큰, UX 어조가 한 프로젝트 안에서도 프로젝트 사이에서도 어긋나지 않을 것.
장애 내성, 사고 시 빠른 감지와 복구, 잠재 리스크의 인지와 관리. 리스크는 없애는 것만 관리가 아니다. 알고 안고 가는 것도 관리다(5번 참조).
쓰는 사람의 인지 부하와 실수 유발을 최소로, 흐름은 자연스럽게. 사용자가 누구인지부터 정의한다(4번 참조).
안정성을 높이는 절차가 사용자 친화성을 해치는 식의 충돌이 종종 생긴다. 이때 AI가 임의로 한쪽을 고르는 게 내가 가장 경계하는 동작이다.
사용자 친화성이라는 축은 사용자가 누구냐에 따라 답이 달라진다. 내가 만드는 시스템의 사용자층은 대략 다섯으로 나뉜다.
대외 서비스·안내 페이지. 가장 보수적인 기준 — 익명성과 쉬운 언어.
사내 업무 시스템·사내 알림. 교육 없이 쓸 수 있어야 한다.
접수·관리·조회 도구. 반복 업무라서 동선 한 칸이 누적 비용.
협업 도구. 권한 경계가 핵심.
개인 자동화·운영 도구. 친절함보다 정확한 로그와 빠른 진단.
· 프로젝트의 기억 파일에 우선 사용자가 명시돼 있으면 그것을 따른다.
· 없으면 작업 전에 "어느 사용자를 우선할까요"를 먼저 묻게 했다.
· 직원용 시스템에 운영자인 내가 같이 쓰는 화면이 있다거나 하면, 양쪽 모두에 대해 평가한다.
4축에 어긋나 보여도 내가 알고 받아들인 트레이드오프는 지적 대상이 아니다. 이 조항이 없으면 AI는 점검 때마다 같은 항목을 새로 "발견"한다. 잔소리가 반복되면 사람은 진짜 경고까지 무시하게 된다.
· 일부러 미루고 있는 문서화·이중화 작업
· 평가를 거쳐 안고 가기로 한 잠재 리스크
· 교체 비용 대비 위험을 따져 유지하기로 한 구성
· 앞으로 추가될 같은 성격의 결정들
· 그 예외가 실제 사고로 이어졌을 때
· 내가 재논의 의사를 비쳤을 때
→ 즉시 재평가 대상으로 복귀한다.
예외는 영구 면제가 아니라 "지금은 그대로 두기로 한 결정"이다.
예외 목록도 기준과 마찬가지로 기억 파일에 적혀 있다. "전에 봐주기로 했잖아"가 세션이 바뀌어도 통하려면, 봐주기로 한 사실 자체가 기록돼 있어야 한다.
모든 작업의 완료 보고 직전에 이 10개를 짚는다. 규칙은 하나다. "이상 없음"이라고 적기 전에 실제로 짚었는지 스스로 확인할 것. 형식적인 OK가 제일 위험하다.
구조·책임 분리·결정의 일관성.
인증, 권한 상승, 시크릿, 세션, 요청 위조류.
개인정보보호법 등 그 작업이 속한 도메인의 법령·규제.
메모리·리소스·시크릿·환경변수·로그로 새는 것.
데이터·상태·UI·문서·기억 파일 사이의 어긋남. 발행물도 여기 포함된다.
구현 디테일의 결함, 쓰이지 않는 잔재.
런타임·빌드·운영 비용, 그리고 사람의 수작업.
4번의 다층 사용자 정의를 따라 평가.
모니터링·로그·헬스체크·알람 — 고장 나면 알 수 있는가.
공유 자원·도메인·환경·네이밍, 운영 중인 다른 프로젝트까지(9번 참조).
한 줄 고치는 데 풀 점검을 강요하면 점검 자체가 무시되기 시작한다. 그래서 강도를 세 단계로 나눴다.
코드·설정·기억·운영 환경에 의미 있는 변경이 있었던 작업.
한 줄 수정, 기억 한 건 추가, 단순 조회, 오타 수정.
내가 "지금은 빨리 끝내자"라고 명시했을 때만. 대신 보류했다는 사실을 한 줄 남긴다. 침묵으로 건너뛰는 건 안 된다.
발견이 없으면 "이상 없음" 한 줄. 있으면 아래 4열 표. 형식을 고정해 두면 보고를 빠르게 훑을 수 있고, 권장 조치 없이 문제만 나열하는 보고도 사라진다.
| 발견 | 영향 | 권장 조치 | 내 결정 필요? |
|---|---|---|---|
| 예: A 변경이 B 모듈 호환성에 잠재 영향 | 특정 화면 일부가 깨질 수 있음 | B 모듈 회귀 테스트 추가 | Yes — 영향 범위 판단 필요 |
| (발견이 없으면 "이상 없음" 한 줄) | |||
이번 작업이 공유 자원을 건드렸다면, 그 자원을 쓰는 다른 프로젝트들이 자동으로 점검 범위에 들어온다. 여러 서비스를 혼자 운영하면서 겪은 사고는 대부분 고친 곳이 아니라 같이 쓰는 곳에서 났다.
공용 인증 토큰, API 키처럼 여러 곳이 함께 읽는 값.
서브도메인 추가·변경이 이웃 서비스에 미치는 영향.
여러 앱이 같이 쓰는 SSO·계정 체계.
DB·스토리지·알림 webhook·헬스체크 같은 공용 인프라.
메이저 버전 변경은 같은 의존성을 쓰는 모든 프로젝트의 일.
모든 세션·프로젝트에 걸리는 hook·cron·스케줄러.
축의 이름이나 개수보다는 운영 원리 쪽이 옮겨 심을 만하다.
AI에게 일관된 기준을 적용시키려면 기준이 로드 가능한 텍스트로 존재해야 한다. 말로 한 번 알려준 기준은 다음 세션에 없다.
점검의 적은 누락이 아니라 형식적인 OK다. 이상 없음이라 적기 전에 실제로 짚었는지 자체 확인하라는 의무 한 줄이 점검 품질을 좌우했다.
AI에게 시킬 일은 충돌을 드러내고 권장안을 다는 것까지다. 트레이드오프를 조용히 자체 결정하게 두면, 무엇을 포기했는지 사람이 모르는 채로 일이 굳는다.
예외 목록이 없으면 AI는 같은 지적을 영원히 반복하고, 사람은 경고 자체를 끄게 된다. 신호 대 잡음 비율도 설계할 대상이다.
모든 작업에 풀 점검을 요구하는 제도는 가장 먼저 형식만 남는다. 간이 점검과 기록을 남기는 보류라는 합법적 출구가 있어야 풀 점검이 진짜로 돈다.