코드 검토
만든 사람 말고 다른 사람이 그 작업을 한 번 읽고 넘기는 절차예요. 여러 명이 손대기 시작하면 품질과 지식 공유를 같이 챙겨 줘요. 사고를 줄이는 값보다, 한 사람만 아는 자리를 없애는 값이 더 커요.
쉽게 말하면
전단지를 인쇄소에 넘기기 전에 다른 사람이 한 번 읽는 것이에요. 만든 사람은 스무 번을 봐도 자기 전단지의 전화번호 끝자리를 못 봐요. 머릿속에 맞는 번호가 있으니까 눈이 그걸 재생하거든요. 옆 사람은 3초 만에 찾아요. 인쇄 500장을 뽑은 뒤에 찾으면 500장이 종이값이 되고, 넘기기 전에 찾으면 1분이에요. 코드 검토는 그 1분을 제도로 만든 거예요.
검토는 반영 요청 위에서 일어나요. 요청서가 문턱이라면, 검토는 그 문턱에서 사람이 실제로 하는 일이에요.
검토를 사고 예방으로만 알면 절반만 아는 거예요. 더 큰 값은 지식 공유예요. 검토를 하면 그 코드를 아는 사람이 최소 두 명이 돼요. 한 명이 그만두는 날 서비스가 안 멈추는 이유가 이거예요.
속도가 빨라 보여요. 대신 그 한 명이 없어지는 날 비용이 한꺼번에 청구돼요.
건당 반나절이 더 걸려요. 대신 사람이 바뀌어도 서비스가 안 흔들려요.
AI에게 훑게 하는 것과는 다른 이야기예요
AI에게 먼저 한 번 훑게 하는 방법은 AI에게 검토시키기 쪽 이야기예요. 그건 빠뜨린 구멍을 기계가 찾아 주는 것이고, 여기서 말하는 검토는 사람이 사람 작업을 보는 것이에요. 둘은 겹치지 않아요. AI가 훑어 준 뒤에 사람이 보면 사람은 더 중요한 것만 보면 돼요.
검토가 실제로 잡아 주는 것
검토가 만능은 아니에요. 잡히는 것과 안 잡히는 것이 갈려요. 이걸 알아야 검토에 무엇을 기대할지 정할 수 있어요.
| 종류 | 검토가 잡나 | 설명 |
|---|---|---|
| 화면이 아예 안 열림 | 검토 전에 걸러야 해요 | 사람 눈보다 자동 점검이 훨씬 잘 잡아요. 자동 점검을 요청마다 돌리면 사람은 여기 시간을 안 써요 |
| 조건이 반대로 된 실수 | 잘 잡아요 | 할인 대상이 아닌 손님에게 할인이 나가는 식이에요. 만든 사람은 의도가 머리에 있어서 못 보고, 남은 그냥 읽어서 봐요 |
| 건드리면 안 되는 자리를 건드림 | 잘 잡아요 | 결제·로그인·손님 정보처럼 이번 작업과 상관없는 파일이 바뀌어 있으면 검토에서 바로 눈에 띄어요 |
| 키나 비밀번호가 코드에 박힘 | 잘 잡아요 | 가장 값진 순간이에요. 환경 변수로 빼야 할 것이 그대로 들어가 있는지 남의 눈이 봐요 |
| 느려지는 코드 | 반쯤 잡아요 | 명백한 것만 보여요. 실제 느려짐은 손님 수가 올라가야 드러나서 부하 시험 쪽 일이에요 |
| 기획이 틀림 | 못 잡아요 | 요구한 대로 만들었는데 요구가 틀린 경우예요. 이건 요구사항 정리에서 갈려요 |
사장님이 검토에서 하는 일
사장님이 코드 줄을 읽으라는 뜻이 아니에요. 검토에는 코드를 보는 자리와 서비스를 보는 자리가 따로 있어요. 뒤쪽은 사장님이 제일 잘해요.
- 1이 작업이 무엇을 바꾸는지 한국어 한 줄로 받아요. 한 줄로 안 나오면 한 요청에 여러 일이 섞인 거예요. 나눠 달라고 하세요.
- 2손님이 보는 문구를 확인해요. 코드는 못 읽어도 화면에 나갈 말은 사장님이 최종 결정권자예요. 안내 문구·버튼 이름·에러 메시지가 여기서 정해져요.
- 3이번 작업이 건드리면 안 되는 자리를 말로 짚어요. "이 작업이 결제 화면을 건드리나요" 한 줄이면 돼요. 답이 애매하면 그게 신호예요.
- 4자동 점검이 통과했는지만 봐요. 빨간 표시가 남아 있으면 사람 검토를 시작할 때가 아니에요.
- 5눌러 볼 주소가 있으면 눌러 봐요. 코드 검토보다 사장님에게는 이게 훨씬 정확해요. 실제로 써 보는 사람이 사장님이니까요.
- 6의견은 요청서 안에 글로 남겨요. 전화나 메시지로 하면 다음 사람이 못 봐요. 검토의 값 절반은 남는 글에서 나와요.
장면 · 외주 개발자가 검토 결과를 물었다
“코드는 제가 봤고 문제 없습니다. 사장님은 승인만 눌러 주시면 돼요.”
여기서 그냥 누르면 검토가 요식 행위가 돼요. 누르기 전에 두 가지만 물으세요. 이번에 바뀌는 화면이 어디인지, 그리고 되돌려야 할 때 얼마나 걸리는지예요. 두 번째 질문이 특히 중요해요. 되돌리기가 5분이면 과감히 넣어도 되고, 반나절이면 연습 무대에서 먼저 봐야 해요. 승인은 코드에 대한 보증이 아니라 내 가게에 지금 들어가도 좋다는 결정이에요.
검토를 규칙으로 만들기
검토는 사람의 성의에 맡기면 두 달 만에 죽어요. 바쁘면 안 하게 되고, 한 번 건너뛰면 그게 기본값이 돼요. 그래서 규칙 다섯 줄을 미리 정해 둬요.
| 정할 것 | 권하는 기준 | 왜 이 기준인가 |
|---|---|---|
| 누가 보나 | 한 명이면 충분해요 | 두세 명으로 늘리면 좋아지기보다 서로 미뤄요. 작은 팀은 한 명이 가장 잘 돌아가요 |
| 얼마나 큰 것까지 | 하루 안에 읽을 크기로 | 요청이 크면 아무도 제대로 못 봐요. 큰 요청의 승인률이 100퍼센트인 팀은 검토가 이미 죽은 거예요 |
| 언제까지 답하나 | 영업일 하루 안 | 답이 늦으면 그동안 본판이 앞서 나가서 충돌이 늘어요. 검토가 느리면 사람들이 검토를 피해요 |
| 건너뛰어도 되는 때 | 손님이 지금 못 쓰는 급한 수정만 | 예외를 안 정해 두면 급할 때마다 즉흥으로 건너뛰고, 그게 관행이 돼요. 급한 수정은 뒤에 검토를 채워요 |
| 무엇을 반드시 보나 | 손님 문구·비밀 값·건드리면 안 되는 자리 | 전부 보려 하면 아무것도 못 봐요. 목록을 짧게 정해 두면 검토가 5분 안에 끝나요 |
부탁이 아니라 설정으로 막으세요
코드 보관 서비스에는 승인이 한 건 이상 있어야 합치기 버튼이 열리게 하는 설정이 있어요. 사람에게 지키자고 부탁하는 것보다 훨씬 확실해요. 개발자에게 "본판은 승인 없이 못 들어가게 잠가 주세요" 한 줄만 요청하면 돼요. 규칙은 사고가 나기 전에 걸어 둘 때만 값이 있어요.
확인해 보세요
외주 개발자가 파일 40개, 1200줄이 바뀐 요청 하나를 올리고 검토를 부탁했어요. 사장님이 할 가장 좋은 대응은?
검토가 망가지는 세 가지 길
- 1도장 찍기. 열어 보지도 않고 승인만 눌러요. 통과율이 100퍼센트고 의견이 한 줄도 안 달렸으면 이 상태예요. 고치는 법은 무엇을 반드시 보는지 목록을 짧게 정하는 거예요.
- 2취향 싸움. 이름을 이렇게 지어라, 줄바꿈을 저렇게 해라로 며칠이 가요. 취향은 사람이 아니라 자동 정렬 도구가 정하게 넘기면 논쟁 자체가 사라져요.
- 3적체. 요청이 열흘씩 열려 있어요. 그러면 다들 검토를 피해서 몰래 넣기 시작해요. 답변 기한을 정하는 게 이걸 막는 유일한 방법이에요.
장면 · 개발자 두 명이 서로의 작업을 검토하기 시작했다
“서로 봐 주니까 오히려 개발이 느려지는 것 같은데요.”
초반 2주는 실제로 느려져요. 서로의 코드를 처음 읽으니까요. 그다음부터 뒤집혀요. 남의 코드를 읽어 둔 사람은 그 자리를 고칠 때 묻지 않고 바로 고치거든요. 느려지는 건 초기 비용이고, 빨라지는 건 이자예요. 다만 이 말은 검토를 규칙 없이 굴려도 된다는 뜻이 아니에요. 크기와 기한을 안 정하면 초기 비용만 계속 내게 돼요.
세 가지 모두 사람 탓이 아니에요. 기준이 없어서 생기는 일이에요. 기준 다섯 줄을 적어 두면 대부분 사라져요.
자주 묻는 것
- Q. 혼자 만드는데 검토가 필요한가요?
- 지금은 필요 없어요. 검토는 두 사람 이상일 때 값이 나와요. 혼자일 때는 되돌리기와 실제로 눌러 보는 확인이 그 자리를 대신해요. 다만 외주나 프리랜서가 코드를 고치기 시작하는 날부터는 바로 필요해요.
- Q. 저는 코드를 못 읽는데 검토자로 이름이 올라가도 되나요?
- 돼요. 다만 무엇을 보는 사람인지 서로 정해 두세요. 사장님은 손님 문구와 서비스 영향을 보고, 코드 자체는 다른 개발자가 봐요. 아무도 코드를 안 보는 상태로 승인만 도는 건 검토가 아니에요. 개발자가 한 명뿐이면 그 사실을 인정하고 자동 시험과 연습 무대를 대신 두껍게 하는 게 정직한 선택이에요.
- Q. AI에게 검토를 맡기면 사람 검토를 빼도 되나요?
- 빼면 안 돼요. AI는 읽어서 알 수 있는 실수를 잘 찾지만, "우리 가게에서 이게 맞는 결정인가"는 판단하지 못해요. 순서를 바꾸는 게 맞아요. AI가 먼저 훑고, 사람은 남은 판단만 봐요. 자세한 건 AI에게 검토시키기 쪽에 있어요.
- Q. 검토에서 반대 의견이 나왔는데 개발자와 저 중 누가 결정하나요?
- 기술적으로 어떻게 만들지는 개발자가, 서비스가 어떻게 보일지는 사장님이 정해요. 이 선을 미리 그어 두면 대부분의 다툼이 사라져요. 애매한 것은 되돌리기 비용으로 갈라요. 되돌리기가 싼 결정은 빨리 넣고 보고, 비싼 결정은 연습 무대에서 먼저 봐요.
- Q. 검토를 했는데도 사고가 났어요. 검토가 소용없는 건가요?
- 검토는 사고를 0으로 만드는 장치가 아니에요. 같은 사고가 두 번 안 나게 만드는 장치예요. 사고가 났으면 원인을 반드시 보는 목록에 한 줄 추가하세요. 사람을 탓하면 다음 검토가 더 형식적으로 변해요. 반복되는 사고는 고쳤더니 딴 게 깨짐 쪽 대책이 필요할 수도 있어요.
- Q. 외주 계약서에 검토를 넣을 수 있나요?
- 넣을 수 있고, 넣는 편이 좋아요. "본판 직접 반영 금지", "요청 하나에 한 가지 일", "자동 점검 통과 후 합치기" 세 줄이면 충분해요. 시작할 때 말하면 비용이 안 붙고, 중간에 요구하면 추가 작업으로 계산돼요. 외주 맡기기에 계약 이야기가 더 있어요.
직접 해보기
혼자일 때 검토를 흉내 내는 법
아직 혼자 만들고 있다면 검토자가 없어요. 대신 만들기 전에 물어보는 습관으로 절반은 흉내 낼 수 있어요. 스튜디오 채팅에 고쳐 달라고 하기 전에 "이번 수정이 어느 화면을 건드리는지 먼저 알려 주세요"라고 한 번 물어보세요. 바뀌는 범위를 글로 받고 시작하는 것, 그게 검토가 하는 일의 첫 절반이에요.
스튜디오 열기더 깊이 (안 읽어도 괜찮아요)
왜 만든 사람은 자기 실수를 못 보나 · 읽는 게 아니라 기억을 재생하기 때문이에요. 방금 자기가 쓴 글을 볼 때 사람의 눈은 글자를 하나씩 훑지 않고, 머릿속에 있는 의도를 화면에 겹쳐 놓아요. 그래서 전화번호 끝자리가 틀려도 맞는 번호가 보여요. 다른 사람은 겹칠 기억이 없어서 그냥 글자를 읽어요. 검토가 효과를 내는 이유는 그 사람이 더 뛰어나서가 아니라 기억이 없어서예요. 그래서 검토자는 초보여도 값을 해요.
검토를 짧게 유지하는 실무 요령 · 요청 설명에 "무엇을 바꿨나"만 적으면 검토자가 코드를 처음부터 해석해야 해요. 여기에 왜 이렇게 했는지와 무엇을 확인했는지 두 줄을 더 받으면 검토 시간이 크게 줄어요. 자동으로 잡히는 것은 사람이 안 보게 넘기는 것도 같은 효과예요. 줄바꿈·따옴표 같은 형식은 도구가 정리하고, 시험은 자동 점검이 돌리고, 사람은 판단만 봐요.
인수인계의 절반은 평소 검토에서 만들어져요 · 개발자가 떠날 때 문서를 몰아서 쓰게 하면 대부분 형식적인 글이 나와요. 평소에 검토를 돌리면 그 사람의 판단 이유가 요청서마다 글로 쌓여요. 나중에 "이건 왜 이렇게 돼 있죠"의 답이 그 안에 있어요. 그래서 검토 기록은 인수인계 자료의 일부예요. 사람을 붙잡을 수는 없지만 그 사람의 판단은 남길 수 있어요.
이것만 기억하세요
- ·코드 검토는 만든 사람 말고 다른 사람이 그 작업을 한 번 읽고 넘기는 절차예요
- ·사고 예방보다 지식 공유가 더 큰 값이에요. 그 코드를 아는 사람이 두 명이 돼요
- ·사장님이 볼 자리는 코드가 아니라 손님 문구·건드리면 안 되는 자리·되돌리기 비용이에요
- ·규칙 다섯 줄을 미리 정해요. 누가·얼마나 큰 것까지·언제까지·예외·반드시 볼 목록이에요
- ·성의에 맡기면 두 달 만에 죽어요. 승인 없이는 못 들어가게 설정으로 잠그세요