검토하는 법

1. 검토가 왜 기술인가

Code 탭에 맡기면 Claude가 스스로 실행해 보고 에러를 고칩니다. 그런데 에러가 없다는 것과 여러분이 원한 것이 나왔다는 것은 다릅니다. 버튼이 엉뚱한 곳으로 가고, 폰에서 글자가 잘리고, 가격이 지어낸 숫자이고, 시킨 것 중 하나가 빠지는 일은 에러 없이 일어납니다. 이것을 찾는 사람이 여러분입니다.

검토는 결과물을 '보는' 일이 아니라 '써 보는' 일입니다. 예쁘다, 괜찮다로 끝나면 검토가 아닙니다. 실제 사용자가 할 일을 여러분이 먼저 해보는 것입니다. 3장의 첫 실습에서 네 가지를 했습니다. 눌러 보기, 좁혀 보기, 읽어 보기, 빠진 것 찾기. 이 절에서 그것을 하나의 체크리스트로 만듭니다.

2. 검토 체크리스트

2.1 눌러 보기

모든 버튼과 링크를 눌러 봅니다. 어디로 가는지, 열리는지, 아무 일도 안 일어나는 버튼은 없는지 봅니다. 폼이 있다면 실제로 채워서 보내 봅니다. 보내고 나서 무슨 일이 일어나는지도 봅니다. "접수되었습니다"라는 문구만 뜨고 실제로는 아무 데도 저장되지 않는 경우가 흔합니다.

2.2 좁혀 보기

브라우저 창의 폭을 휴대폰만큼 좁게 줄여 봅니다. 8장에서 배운 개발자 도구(F12)의 기기 모드를 쓰면 정확한 폰 크기로 볼 수 있습니다. 글자가 잘리는지, 버튼이 화면 밖으로 나가는지, 표가 옆으로 밀리는지 봅니다. 가능하면 실제 폰에서도 열어 봅니다. 5장에서 배포한 주소를 폰으로 열면 됩니다.

2.3 읽어 보기

문구를 처음부터 끝까지 읽습니다. 찾는 것은 두 가지입니다.

지어낸 것: 여러분이 알려주지 않은 이름, 날짜, 가격, 주소, 전화번호, 후기. 앞 절의 브리프에서 [확인 필요]로 표시하라고 했다면 그 표시를 찾습니다.
어색한 것: 번역투, 과장, 우리 말투가 아닌 것. "혁신적인 경험을 만나보세요" 같은 문구는 Claude가 채운 여백입니다.

2.4 빠진 것 찾기

브리프의 '무엇이 보여야 하나' 목록을 옆에 두고 하나씩 대조합니다. Claude는 시킨 것 중 하나를 조용히 빼먹을 때가 있습니다. 특히 목록이 길수록 그렇습니다. 반대로 시키지 않은 것이 들어가 있을 수도 있습니다. 회원가입 버튼, 소셜 로그인, 뉴스레터 구독처럼 "보통 있으니까" 넣은 것들입니다. 브리프에 '없이'라고 적은 것이 들어가 있으면 그것도 빠진 것과 같은 문제입니다.

2.5 망가뜨려 보기

이름 칸에 아무것도 안 적고 보내 봅니다. 수량에 -1이나 9999를 넣어 봅니다. 연락처에 글자를 넣어 봅니다. 아주 긴 글을 넣어 봅니다. 사용자는 여러분이 생각하지 못한 방식으로 씁니다. 망가지면 그 상황을 그대로 Claude에게 말하면 됩니다. "수량에 -1을 넣어도 접수가 돼. 1 이상만 받게 해줘."

2.6 숫자 맞춰 보기

합계, 개수, 날짜처럼 계산된 것이 있으면 손으로 한 번 맞춰 봅니다. 가격표를 재료로 줬다면 페이지의 가격이 파일과 같은지 봅니다. 데이터를 분석한 결과라면 엑셀에서 합계를 내서 비교합니다. AI가 만든 숫자를 그대로 믿지 않는 습관은 결과물이 커질수록 중요해집니다.

3. 검토 메모 쓰기

검토하면서 찾은 것을 메모합니다. 머릿속에 두면 Claude에게 말할 때 절반이 빠집니다. 형식은 간단합니다.

검토 메모 (1차)

고칠 것:
1. 주문하기 버튼을 눌러도 아무 일도 안 일어남
2. 폰 폭에서 가격표가 옆으로 잘림
3. 농장 전화번호가 010-1234-5678로 지어져 있음 → 실제 번호로
4. '프리미엄 감귤 체험' 문구가 들어가 있는데 시킨 적 없음 → 삭제

괜찮은 것:
- 사진 배치, 색

'괜찮은 것'도 적는 이유가 있습니다. 다음 절에서 수정을 요청할 때 "이건 그대로 두고"라고 말할 수 있어야 Claude가 멀쩡한 부분을 건드리지 않습니다.

4. Claude에게 검토 시키기

여러분이 검토하는 동시에 Claude에게도 검토를 시킵니다. 둘이 찾는 것이 다릅니다. 여러분은 '내가 원한 것인가'를 보고, Claude는 '기술적으로 문제가 없는가'를 봅니다.

4.1 검토 Skill 쓰기

3장 9절에서 만든 page-review Skill이 이 자리에 있습니다. 결과물이 나오면 새 대화를 열지 않고 이어서 요청합니다.

이 폴더의 페이지를 검토해줘.

Claude가 링크, 폰 화면, 지어낸 문구, 빠진 것을 확인해 검토결과.md를 만듭니다. 여러분의 검토 메모와 나란히 놓고 보세요. Claude가 찾은 것 중 여러분이 놓친 것이 있을 것이고, 그 반대도 있을 것입니다.

4.2 다른 눈으로 검토 시키기

같은 대화에서 검토를 시키면 Claude는 자기가 만든 것을 너그럽게 봅니다. 사람도 그렇습니다. 그래서 새 대화를 열어 검토만 시키는 방법이 있습니다. /clear로 대화를 비우고 같은 폴더에서 이렇게 요청합니다.

이 폴더의 index.html은 다른 사람이 만든 거야. 제주 감귤 농장 주인이 지인 주문을 받으려고 만든 페이지인데, 개발을 모르는 사람이 유지보수해야 해. 사용자 입장에서 써 보고 불편한 점, 기술적으로 위험한 점, 폰에서 깨지는 점을 찾아서 심각한 순서로 정리해줘. 고치지는 말고.

'다른 사람이 만든 거야'라는 한 마디가 검토의 날을 세웁니다. '고치지는 말고'를 붙이는 이유는 검토와 수정을 분리하기 위해서입니다. 무엇을 고칠지는 여러분이 정합니다.

4.3 크롬 익스텐션으로 눌러 보게 하기

부록에서 다루는 Claude 크롬 익스텐션을 설치했다면, 브라우저에서 페이지를 열고 익스텐션에 "이 페이지의 모든 버튼을 눌러 보고 동작하지 않는 것을 알려줘"라고 시킬 수 있습니다. 눌러 보기를 Claude가 대신하는 것입니다. 폼을 채워서 보내 보게 할 수도 있습니다. 다만 익스텐션과 Code 탭은 연결되어 있지 않으니, 익스텐션이 찾은 것을 정리해서 Code 탭에 다시 전달해야 합니다.

5. 보안, 이것만은 봅니다

개발 전문가가 아닌 분이 보안을 전부 챙길 수는 없습니다. 하지만 세 가지는 검토 때마다 봅니다.

비밀번호나 키가 파일에 들어 있지 않은가: 구글 시트 연결, 외부 서비스 연결을 하면 '키'라는 긴 문자열이 생깁니다. 이것이 index.html 안에 그대로 적혀 있으면 배포하는 순간 누구나 볼 수 있습니다. Claude에게 물어보세요. "이 폴더에 외부에 공개되면 안 되는 키나 비밀번호가 들어 있는 파일이 있어?"
개인정보를 받고 있지 않은가: 이름, 연락처, 주소를 받는 페이지는 개인정보를 다루는 것입니다. 지인 몇 명에게 쓰는 것과 불특정 다수에게 공개하는 것은 법적으로 다릅니다. 2장 4절에서 말한 개인정보보호법의 영역입니다. 공개 서비스로 키우려면 그때는 전문가와 상의하세요.
누구나 데이터를 볼 수 있지 않은가: 주문 현황 표를 페이지에 그대로 보여주면 다른 사람의 이름과 주소가 보입니다. 브리프에서 '관리자 기능은 이번에는 없이'라고 잘랐다면, 현황 표도 공개 페이지에는 두지 않는 것이 맞습니다.

이 세 가지도 Claude에게 시킬 수 있습니다. "이 페이지를 공개했을 때 보안이나 개인정보 면에서 위험한 것이 있으면 알려줘. 개발을 모르는 사람이 이해할 수 있게 설명해줘." 위니북스에는 이 주제만 다루는 책이 따로 있습니다.

링크: https://www.books.weniv.co.kr/just-security

6. 검토를 언제 멈추는가

검토는 끝이 없습니다. 볼수록 고칠 것이 보입니다. 그래서 멈추는 기준이 필요합니다. 이 책의 기준은 하나입니다. 브리프의 '누가, 왜'가 이루어지는가. 감귤 농장 주인이 지인에게 링크를 보내 주문을 받을 수 있으면 1차 검토는 끝입니다. 색이 조금 아쉽고 문구가 조금 딱딱해도, 주문이 접수되면 쓸 수 있습니다. 나머지는 써 보면서 고칩니다. 앞선 책에서 MVP(최소 기능 제품)라고 부르던 것이 이것입니다. 다만 그때는 명세서로 정했고, 지금은 검토로 정합니다.