- 증상: AI에게 «내가 결정해야 하는 게 뭐야?»라고 물으면 계획 문서에서 뽑아낸 «사용자 결정» 목록이 옵니다. 그날 새벽엔 방향 결정 5건, 그리고 별건으로 «아무도 안 부르는 캐시 함수 3개, 지울까요?»가 있었습니다
- 원인: 결정을 못 한 건 게을러서가 아니라 설명만 오고 확인할 화면이 없어서였습니다. 그리고 죽은 코드 앞에서는 늘 절충안이 유혹합니다 — «나중에 필요하면 쓰라고 남겨 두면 어때?»
- 해결: «냉정하게, 현실적으로, 네가 운용자라면?» 한 마디로 절충안을 접고 삭제. 대신 재도입 조건을 문서 한 줄로 남겼습니다. 진짜 이유는 PR 본문에 있었습니다 — 그 캐시는 배선되는 순간 학생 이름이 평문으로 앉는 지뢰였습니다
혹시 이런 상황인가요?
AI와 프로젝트를 하다 보면 «사용자가 정해야 할 것» 목록이 쌓입니다. 하나하나가 뭘 뜻하는지 바로 안 와닿아서 «이따 볼게» 하고 미룹니다. 그중엔 «이 함수들은 아무도 안 부릅니다. 지울까요?» 같은 것도 있죠. 지우자니 «언젠가 쓸 것 같고», 두자니 찜찜하고. 그렇게 세션이 갑니다.
저도 똑같이 당했습니다
저는 아이들 수학을 가르치고 있고, 학생 리포트를 AI로 만드는 플랫폼을 AI와 함께 개발하고 있습니다. 그날은 새벽 작업이었습니다. 세션을 «내가 결정해야 하는 게 뭐야?»로 열었더니 AI가 계획 문서에서 방향 결정 5건을 뽑아 줬고, 그러다 작업 중이던 파워셸 창이 강제 종료돼 «작업 재개 포인트 찾아»로 다시 시작했습니다. 재개하고 보니 5건은 그대로였습니다. 저는 이렇게 적었습니다.
다음 할일 진행하고, 사용자 몫은 한건 한건 설명이 필요해. 설명을 듣고 이해한다음 결정해야지.
그 5건과 별개로 «사용자 몫»이 하나 더 있었습니다. 학생 정보 보호 작업의 마지막 조각인 «report-cache의 죽은 함수 3개 삭제». 저는 바로 결정하지 않고 이렇게 물었습니다.
report-cache 죽은 함수 3개 삭제 전에 report-cache의 역할에 대해 예를 들어 설명해줘. 나머지는 화면 보고 결정할게
원인은 이거였습니다 — 죽은 코드가 아니라 «묻힌 지뢰»였다
무대를 한 문장으로 — AI와 코드를 만들다 보면 «언젠가 쓰려고» 만든 조각이 남고, 그걸 지우는 결정은 사람 몫으로 돌아옵니다. 오답노트에서 안 쓰는 공식을 지울 때 «혹시 나올지도»가 손을 잡는 것과 같아요.
죽은 코드(dead code) — 프로그램 어디에서도 호출하지 않는 코드. 캐시 — 한 번 조회한 결과를 잠시 보관해 두고 다음엔 DB 대신 그걸 돌려주는 저장소. 배선 — 어떤 함수를 실제 화면이 부르도록 연결하는 일. 죽은 코드는 «배선»되는 순간 살아납니다.
그 파일에는 리포트 조회 결과를 캐시하는 함수 3개가 있었습니다. 문제는 세 가지가 겹쳐 있었다는 겁니다.
- 어느 화면도 부르지 않았습니다. 검수 AI가 소스·테스트·스크립트를 전부 뒤져 참조 0건을 확인했고, 예전에 만든 접근 권한 감사 문서에도 이미 «호출자 없음(dead code)»으로, 배선하면 0행이나 장애로 이어진다고 적혀 있었습니다. 두 갈래가 독립적으로 같은 판정이었습니다.
- 셋 중 둘이 학생 정보를 함께 캐시하도록 짜여 있었습니다. 학생 테이블을 조인해 이름까지 캐시에 넣는 구조였고, 그중 하나는 최대 1시간 남습니다.
- 곧 학생 이름을 암호화하는 키가 들어갈 예정이었습니다. 그러면 이 캐시가 배선되는 순간 평문 이름이 캐시에 앉는 지뢰가 됩니다.
즉 «안 쓰는 코드»가 아니라 «지금은 안 터지는 지뢰»였습니다. 그런데도 저는 절충안을 먼저 꺼냈습니다.
삭제 안하고 남겨두는 대신, 캐시가 필요한 시점(예를들어 회원이 50명이 넘어가거나 교사 고객도 생겨서 DB 조회가 크게 늘어난 상태에서 캐시 함수 배선을 고려 해본다라고 제한해둔다면 어때?
«고려»에 굵게까지 쳤습니다. 지우기 싫은 마음이 그대로 보이죠.
이렇게 고쳤습니다 — «운용자라면?»으로 절충안을 접다
절충안을 내놓고 나서, 제가 다시 물은 건 이겁니다.
냉정하게, 현실적으로, 너가 시스템 운용자라면 삭제할거야 절충안으로 갈거야?
AI는 “저라면 삭제하겠습니다. 지금까지 아무도 캐시에 접근하지 않았습니다. 나중에 DB 조회가 크게 늘어서 실제 페이지 로딩 시간이 오래 걸린다면 그때 다시 캐시 정책을 복구하면 된다.”
삭제로 가. 문서 한 줄도 같이.
그런데, 지금 생각났는데 예전에 이 캐시를 설계 해놓은 이유가 리포트 조회가 빈번하고 화면 로딩도 길어서 캐시를 도입한것 같아. 단시간내에 사용자가 수직 상승하지 않는한 성능 문제는 없는거지?
«문서 한 줄»이 핵심이었습니다. 절충안이 하려던 일 — «나중에 필요해지면 다시 생각한다» — 을 코드가 아니라 문서가 맡게 한 겁니다. 코드에 남기면 지뢰가 남고, 문서에 남기면 조건만 남습니다. AI가 아키텍처 문서에 넣은 문장은 이랬습니다.
리포트 조회 캐시는 의도적으로 없다. 재원생 50명 초과·교사(다계정) 고객 발생 등으로 조회 부하가 실측되면 그때 설계한다 — 학생 이름 등 PII는 캐시에 싣지 않는 것이 전제 …
세 가지가 한 문장에 있습니다. 없는 게 의도라는 선언, 재도입 조건(재원생 50명 초과·교사 고객·부하 실측), 그리고 전제(이름은 캐시에 싣지 않는다). 나중에 누가 «캐시가 왜 없지?» 하고 다시 만들려 해도, 이 문장이 먼저 읽힙니다.
검수가 잡아낸 한 가지 더
삭제 PR에 검수 AI를 붙였더니 7점(10점 만점)에 통과하면서 한 가지를 더 짚었습니다. 상용화 계획 문서에 «앞으로 캐시는 이렇게 만들자»는 코드 샘플이 있었는데, 그 샘플이 학생 테이블을 조인하는 같은 모양이었습니다. 코드에서 지뢰를 걷어내도 문서가 그 지뢰를 다시 심을 수 있었던 거죠. AI에게 샘플을 고치고 경고 절을 달게 했습니다. 코드 변경분에 대한 전체 검증(테스트 1,040개 + 빌드)이 통과했고, 새벽 4시 2분에 머지됐습니다.
이 결정의 진짜 이유(«배선되면 평문 이름이 캐시에 앉는 지뢰», «호출자 0건 실측», «운영자 승인으로 삭제», «재도입 조건은 문서에»)는 채팅이 아니라 커밋과 PR 본문에 남았습니다. 이 글도 그 본문을 원천으로 썼습니다. 대화는 흘러가고, 커밋은 남습니다.
결정 5건은 어떻게 풀렸나
캐시 건이 머지된 뒤에도 방향 결정 5건은 그대로였습니다. 크래시 복구부터 세 시간쯤 지난 새벽 4시를 넘겨, 다른 AI 세션에서 «오늘 결정 5건이 어떻게 판정됐는지 한 줄씩» 묻는 메시지까지 왔고, 저는 이렇게 적었습니다.
다음 할일 진행하자. 다섯건중 한건도 마무리를 못했네.
풀린 계기는 질문의 방향을 바꾼 것이었습니다.
지금 5건 결정할게. 어떤 화면을 확인해야해? 그리고 재생성 플래그 질문 3개는 뭐야?
«설명해 줘»가 아니라 «어떤 화면을 보면 되는지 알려 줘». AI가 건마다 확인할 화면을 짚어 줬고, 화면을 보고 나니 이십 분 남짓이었습니다. ① 유지, ② 제안대로, ③ 제 사업 판단 하나(수업이 끝난 학생도 셀프 분석을 계속 쓸 수 있게 열어 두기), ④⑤ 권장대로 — 다섯 건을 그 자리에서 정했고, 결정과 별개로 저장 알림 화면은 «좀 있다 눈으로» 한 번 더 보기로 남겼습니다. 새벽 5시, 첫 결정이 PR로 머지됐습니다. 그러고 나서 AI에게 완료 기준과 산출물을 정의해 새벽 루프를 돌리라고 하고 잠자리에 들었습니다. 세 시간 동안 0건이던 다섯 건이, 화면 하나씩과 함께 오니 한 번에 풀린 겁니다.
같은 실수를 막는 체크리스트
- 죽은 코드를 지우기 전에 이게 살아나면 무슨 일이 생기나를 먼저 묻는다. 안 쓰는 코드와 지뢰는 다르다.
- 참조 0건은 두 갈래로 확인한다(코드 검색 + 별도 감사 문서/검수 AI). 한 갈래면 «지금은» 0건일 뿐이다.
- 절충안이 «나중에 고려»라면, 그 조건은 코드가 아니라 문서에 남긴다 — «의도적으로 없다 + 재도입 조건 + 전제» 한 문장.
- 판단이 막히면 AI에게 «네가 운용자라면?»을 묻는다. 제안자 위치에서 책임자 위치로 자리를 옮기게 하는 질문이다.
- 지운 뒤 문서의 코드 샘플도 같이 본다. 문서가 지뢰를 다시 심을 수 있다.
- «왜»는 채팅이 아니라 커밋·PR 본문에 적는다.
- 사용자 결정 목록을 받으면 «설명해 줘» 대신 어떤 화면을 확인하면 되나부터 묻는다.
FAQ
Q. 캐시를 지우면 느려지지 않나요?
저도 그게 걱정돼 물었습니다. 그 캐시는 어느 화면도 부르지 않았으니 지운다고 느려질 게 없었고, 부하를 실측한 적이 없어서 «실측되면 그때 설계한다»는 조건만 문서에 남겼습니다.
Q. 3개 다 지웠나요?
조회 캐시 3개는 지우기로 했고, 무효화 함수 하나는 남겼습니다. 유일하게 실제로 참조되는 함수였기 때문입니다(그 무효화 체인도 현재 미배선이라는 사실은 AI가 주석으로 박아 뒀습니다).
Q. AI가 «운용자라면 삭제»라고 답했나요?
답변 원문은 제 기록에 남지 않았습니다. 확실한 건 그 질문 직후 제가 «삭제로 가»라고 했고, PR 본문에 «운영자 승인으로 삭제»와 근거가 적혔다는 것입니다. 이 글은 그 기록만으로 썼습니다.
Q. 결정 목록이 매번 쌓이면 어떡하죠?
결정 요청에 «확인할 화면»을 붙이게 하세요. 제 경우 설명만 있을 때는 세 시간 동안 0건, 화면이 붙자 이십 분 남짓에 5건이었습니다.
한 줄 교훈
죽은 코드의 절충안은 «코드에 남기기»가 아니라 «조건을 문서에 남기기»입니다. 오답노트로 치면 안 쓰는 공식은 지우되, «언제 다시 볼지»만 노트 귀퉁이에 적어 두는 셈이죠. 그리고 지울까 말까 막히면, AI를 제안자가 아니라 운용자 자리에 앉혀 보세요.