돌아가는지부터 보지 마세요. 무엇이 사라졌는지를 먼저 봅니다.
AI가 만들어 준 코드를 검토할 때 대부분 실행부터 해 봅니다. 그런데 실제로 문제가 되는 것은 실행이 안 되는 코드가 아니라 잘 돌아가는데 뭔가 빠진 코드입니다. 실행이 안 되면 바로 알지만, 조용히 사라진 기능은 몇 주 뒤에야 발견됩니다. 그래서 검토 순서를 바꿨습니다. 먼저 변경 범위가 요청한 범위 안인지 보고, 그다음 기존 것 중 사라진 게 없는지 보고, 새로 들어온 외부 의존과 비밀값 처리를 봅니다. 실행은 그 뒤입니다. 이 순서로 보면 검토 시간이 오히려 줄어듭니다. 앞의 세 가지에서 걸리는 것이 많아 실행까지 갈 일이 줄기 때문입니다.
요청한 범위를 넘었는지 먼저 본다
가장 흔한 문제는 부탁하지 않은 것까지 바뀌어 있는 경우입니다.
정리, 개선, 최신화 같은 이름으로 손댄 부분이 섞여 들어옵니다. 하나하나는 그럴듯하지만 합치면 검토 범위가 몇 배가 됩니다.
그래서 작업을 시킬 때부터 이번에 바꿀 것과 바꾸지 않을 것을 나눠 말해 두는 편이 낫습니다. 화면 하나, 기능 하나, 오류 하나처럼 작은 단위로 끊습니다.
받은 뒤에는 바뀐 파일 목록부터 봅니다. 예상하지 않은 파일이 목록에 있으면 내용을 보기 전에 왜 바뀌었는지 먼저 물어봅니다.
사라진 것이 없는지 본다
단순화를 이유로 기존 기능이 지워지는 일이 생각보다 자주 있습니다. 새 코드만 읽으면 알아챌 수 없습니다.
그래서 새로 생긴 줄이 아니라 없어진 줄을 먼저 훑습니다. 지워진 조건문 하나가 예외 처리 전체를 없애는 경우가 있습니다.
문구와 이름도 확인 대상입니다. 승인받은 제목이나 안내 문구가 슬쩍 다듬어져 있으면 되돌립니다.
덮어쓰기 전에 되돌아갈 지점을 만들어 두는 습관이 여기서 값을 합니다. 지점이 있으면 판단이 빨라지고, 없으면 일단 두고 보게 됩니다.
| 볼 것 | 구체적으로 | 발견하면 |
|---|---|---|
| 없어진 줄 | 조건문, 예외 처리, 검증 | 왜 뺐는지 묻는다 |
| 바뀐 문구 | 제목, 안내 문장, 이름 | 원래대로 되돌린다 |
| 바뀐 기본값 | 설정값, 상한, 시간 제한 | 근거를 확인한다 |
| 줄어든 상태 처리 | 빈 화면, 로딩, 오류, 권한 거절 | 빠진 상태를 되살린다 |
새로 들어온 외부 의존을 본다
코드가 짧아지는 대신 새 라이브러리나 외부 서비스가 하나 늘어난 경우가 있습니다. 당장은 이득처럼 보입니다.
그런데 외부 의존은 나중에 비용이 됩니다. 버전이 바뀌거나 서비스가 중단되면 그때 대응할 사람은 나입니다.
그래서 새 의존이 보이면 네 가지를 먼저 확인합니다. 왜 필요한지, 비용이 있는지, 없어지면 어떻게 되는지, 나중에 걷어내려면 무엇을 고쳐야 하는지입니다.
네 가지에 답이 안 나오면 의존을 늘리지 않고 직접 쓰는 쪽을 택합니다.
이미 있는 것과 겹치는지도 봅니다. 같은 일을 하는 도구가 둘이 되면 어느 쪽이 실제로 쓰이는지 아무도 모르게 되고, 고칠 때마다 두 군데를 봐야 합니다.
버전을 정확히 고정해 두는 것도 이때 확인합니다. 범위로 열어 두면 어제 되던 것이 오늘 안 되는 상황을 설명할 수 없습니다.
비밀값이 어디에 있는지 본다
이 항목은 다른 것과 성격이 다릅니다. 한 번 새면 되돌릴 수 없기 때문에 발견 즉시 멈춥니다.
키나 토큰이 코드 안에 그대로 적혀 있는지, 설정 파일에 들어갔는지, 기록에 찍히는지 봅니다.
"일단 되게 하고 나중에 옮기자"는 임시 처리가 가장 위험합니다. 나중이 오지 않는 경우가 많습니다.
운영체제가 제공하는 보안 저장소를 쓰고, 값이 없을 때 평문으로 대신 읽는 예비 경로를 만들지 않습니다. 예비 경로가 있으면 결국 그 경로가 기본이 됩니다.
| 확인 대상 | 있으면 안 되는 것 | 대신할 것 |
|---|---|---|
| 소스 코드 | 키, 토큰, 비밀번호 | 보안 저장소에서 읽기 |
| 설정 파일 | 평문 인증 정보 | 이름만 두고 값은 밖에 |
| 실행 기록 | 인증 정보 출력 | 가려서 남기기 |
| 공유 파일 | 쿠키, 세션 값 | 아예 담지 않기 |
그다음에 실행한다
앞의 네 가지를 통과했다면 이제 돌려 봅니다. 여기서도 정상 경로만 보면 부족합니다.
실제로 문제가 나오는 곳은 드문 경우입니다. 값이 없을 때, 느릴 때, 권한이 없을 때, 중간에 껐다 켰을 때를 각각 봅니다.
| 상황 | 확인할 것 | 자주 빠지는 처리 |
|---|---|---|
| 값이 하나도 없을 때 | 빈 화면 안내 | 빈 목록이 오류처럼 보임 |
| 기다리는 중 | 진행 표시 | 멈춘 것처럼 보임 |
| 실패했을 때 | 무엇이 왜 실패했는지 | 메시지 없이 조용히 끝남 |
| 권한이 없을 때 | 거절 안내 | 빈 화면으로 처리 |
| 다시 켰을 때 | 저장된 상태 복원 | 설정이 초기화됨 |
검토를 끝내는 기준
"돌아가니까 됐다"로 끝내면 다음에 같은 자리에서 다시 봅니다. 끝냈다고 말할 조건을 정해 둡니다.
저는 세 줄로 정리합니다. 기대한 개수와 실제 개수가 같은지, 완료를 알리는 문구를 실제로 봤는지, 확인하지 못한 것이 무엇인지입니다.
세 번째 줄이 가장 중요합니다. 확인 못 한 것을 그대로 적어 두면 다음 사람이 거기서부터 시작합니다.
반대로 확인 못 한 것을 비워 두면, 그것은 확인했다는 뜻으로 읽힙니다. 이 오해가 뒤에서 가장 비싼 실수로 이어집니다.
실패한 과정도 남깁니다. 무엇을 시도했다가 왜 되돌렸는지가 없으면, 다음에 같은 방법을 다시 시도하게 됩니다. 성공한 결과만 적힌 기록은 다음 사람에게 아무 정보도 주지 못합니다.
자주 묻는 질문
Q. 코드를 읽을 줄 몰라도 검토가 되나요?
A. 바뀐 파일 목록과 없어진 줄을 보는 것만으로도 상당 부분 걸러집니다. 요청하지 않은 파일이 바뀌었는지는 코드를 몰라도 판단할 수 있습니다.
Q. 실행이 잘 되면 넘어가도 되나요?
A. 정상 경로만 통과한 것입니다. 값이 없을 때, 권한이 없을 때, 다시 켰을 때를 각각 봐야 실제로 쓸 수 있습니다.
Q. 새 라이브러리를 쓰자고 하면 거절해야 하나요?
A. 거절이 아니라 근거를 요구합니다. 왜 필요한지, 비용이 있는지, 나중에 걷어내려면 무엇을 고쳐야 하는지에 답이 나오면 씁니다.
Q. 키를 코드에 잠깐 넣는 것도 안 되나요?
A. 임시로 넣은 값이 그대로 남는 경우가 대부분입니다. 처음부터 보안 저장소를 쓰는 편이 결과적으로 더 빠릅니다.
확인 자료
- 자체 개발 운영 문서 · 개발루틴 템플릿 v1.3 중 기존 자산 보존과 작은 단위 개발 규칙
- 같은 문서의 테스트 확인 항목과 버전·백업 규칙
- 자료 폴더 운영 기준 문서 · 보안 기준과 개발·검증 순서
- 현장 부록 v1.3 · 완료 보고에 추가할 세 항목
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.