서비스를 운영하다 보면 이런 불안이 있어요. "분명 만들긴 했는데, 진짜 끝까지 잘 돌아가는 게 맞나?"
저는 rona.so에 챌린지를 하나 열어둔 상태였어요. 모집 페이지는 멀쩡히 떠 있고요. 그런데 마음 한구석이 계속 찜찜했습니다.
이유가 있었어요. 사실 이 챌린지의 인증 방식을 중간에 한 번 바꿨거든요.
예전 방식: 사용자가 정해진 실습을 따라 하면 → 그게 자동으로 인증됐어요. 잘 돌아갔고요.
바뀐 방식: 사용자가 자기 업무에 맞는 맞춤형 스킬을 직접 만들어서 → 그걸 완료하면 인증되는 방식으로 바꿨어요.
한국인
인증의 '출발점' 자체가 달라진 거죠. 그러니 마음에 이런 의심이 들었어요. "원래는 잘 됐는데, 서비스 기획을 바꾸면서 그 연결이 끊긴 거 아닐까?"
결론부터 말하면 인증은 단 한 번도 카운팅되지 않는 상태였습니다. 그리고 그걸 찾아내고 고치기까지, 제가 직접 코드를 들여다본 게 아니라 AI에게 'QA 루프'를 통째로 돌리게 해서 해결했어요. 그 과정을 공유해볼게요.
제가 쓴 'QA 루프' 방법론부터 소개할게요
발단은 로나에서 발견한 글이었어요. 원래 코덱스(Codex) 라는 AI 도구로 돌리는 방식으로 소개된, "Full Product Evaluation Loop(제품 전체 평가 루프)" 라는 방법론이었어요.
말은 거창한데, 핵심 아이디어는 단순해요.
AI 에이전트에게 우리 제품을 '진짜 사용자처럼' 써보게 해서 → 로직·UX 결함을 찾고 → 계획을 세워 직접 고치고 → 고친 게 진짜 사라졌는지 다시 검증한다.
보통의 코드 점검은 "코드를 위에서 아래로 한 번 읽어보는" 식인데, 이 방법론은 다르게 접근해요. 점검할 영역을 사용자가 실제로 거치는 '경로(플로우)' 여러 개로 쪼개고, 경로마다 가상 사용자(AI 에이전트)를 한 명씩 붙여서 동시에 써보게 해요. 그리고 결함이 발견되면, 그 결함을 "반박해봐"라고 시키는 또 다른 검사관 AI가 한 건씩 교차검증해서 '그럴듯하지만 사실은 틀린 가짜 결함'을 걸러내고요.
한국어로 웹사이트를 만드는 과정을 보여주는 다이어그램
쉽게 비유하면 — 가게 오픈 전에 알바생 한 명에게 "쭉 둘러봐" 하는 게 아니라, 손님 5명을 풀어서 각자 다른 동선으로 써보게 하고, 그들이 "여기 이상해요" 한 걸 점장이 한 번 더 직접 가서 확인하는 거예요. 그래서 큰 서 비스도 빠짐없이, 헛다리 없이 점검이 돼요.
코덱스 전용? 아니요 — 제 클로드코드엔 'ralph·OMC'가 있었어요
마음에 들어서 바로 써보고 싶었는데, 한 가지 걸리는 게 있었어요. 제가 코덱스는 저렴한 요금제를 쓰고 있어서, 이렇게 여러 AI를 동시에 풀어 끝까지 돌리는 긴 루프는 토큰(사용량)이 중간에 동날 것 같았거든요.
그래서 평소 쓰던 클로드코드(Claude Code)에게 그냥 물어봤어요. "이 방법론, 너도 돌릴 수 있어?"
답이 구체적이었어요. 제 클로드코드에는 이미 OMC(여러 AI 에이전트를 동시에 부려서 일을 나눠 시키는 오케스트레이션 도구) 와 ralph(목표가 달성될 때까지 스스로 같은 루프를 반복하는 자동 반복 장치) 가 깔려 있었거든요.
이 방법론이 요구하는 건 딱 두 가지였어요 — ① 여러 가상 사용자를 동시에 돌리는 것, ② 결함이 사라질 때까지 발견→수정→재검증을 자동으로 반복하는 것. 그런데 OMC가 ①을, ralph가 ②를 정확히 담당하니까, "코덱스 전용 방법론"이 아니라 클로드코드에서도 그대로 돌아갈 수 있었던 거예요. 실제로 이 방법론은 클로드코드 안에 하나의 도구(스킬)로도 들어와 있었고요.
💡 여기서 첫 번째 팁. 특정 도구 전용처럼 보이는 방법론도, "그 방법론이 진짜 요구하는 게 뭔지" 로 분해해서 물어보세요. "여러 AI 동시 실행 + 자동 반복"처럼 능력 단위로 따져보면, 내가 쓰는 도구로도 되는 경우가 많아요.
AI가 '막연한 QA'를 '체크리스트'로 바꿔줬어요
여기서 이 방법론의 진짜 매력이 나왔어요. 제가 "QA 해줘"라고 막연하게 던졌는데, AI가 그걸 사용자 입장의 통과 기준(유저 스토리) 으로 쪼개주더라고요.
쉽게 말하면, "잘 되는지 봐줘" 같은 막연한 말을 → "이건 이래야 통과" 같은 구체적인 합격 조건 목록으로 바꿔준 거예요.
점검 항목
통과 기준 (이래야 정상)
1
사용자가 맞춤 스킬을 완료하면 → 챌린지 인증이 +1 된다
2
같은 날 두 번 완료해도 → 인증은 하루 한 번만 (중복 방지)
3
로그인 안 한 익명 사용자는 → 카운트되지 않는다
4
예전 방식(실습 인증)은 → 여전히 멀쩡히 돌아간다
5
이 인증이 → 모집 페이지/참여 현황 숫자에 반영된다
이렇게 기준이 눈앞에 펼쳐지니까, 막연했던 불안이 "그래서 1번이 되냐 안 되냐" 같은 명확한 질문으로 바뀌었어요. 점검이 갑자기 쉬워진 느낌이었죠.
💡 두 번째 팁. AI에게 점검을 맡길 때, "사용자 입장에서 하나씩 통과 기준을 만들어줘" 라고 해보세요. 막연한 불안이 체크리스트로 바뀌는 순간, 일이 절반은 끝나요.
핵심 반전 — '데이터가 두 갈래로 나뉘어 다리가 없었다'
AI가 코드를 파고들더니 원인을 찾아냈어요. 비유로 풀면 이래요.
저희 서비스 안에는 데이터가 흐르는 길이 두 갈래로 나 있었어요.
A 길: 예전 '실습' 방식이 다니던 길. 여기엔 "완료했으니 인증 1회 올려!" 라고 외치는 신호등이 달려 있었어요.
B 길: 새로 만든 '맞춤 스킬' 방식이 다니는 길. 그런데 이 길엔 그 신호등이 없었어요.
사용자가 맞춤 스킬을 아무리 열심히 만들고 완료해도, B 길에는 "인증 올려!"라고 외쳐줄 신호등이 없으니 인증 카운터는 0에서 꿈쩍도 안 했던 거예요. 두 길 사이에 건너갈 다리가 아예 없었던 거죠.
찾았으면 고쳐야죠 — 두 길 사이에 '다리'를 놨어요
저는 점검 리포트만 받고 끝내고 싶지 않았어요.
깨진 지점을 제대로 수정해서 실제로 돌아가게 만드는 것까지,
이 루프를 돌려서 최종 완성으로 하고 싶어.
그래서 AI에게 수정까지 이어서 맡겼어요. AI가 한 일은 결국 B 길에 신호등을 새로 다는 것 이었어요. "맞춤 스킬 완료" 신호가 들어오면, 그걸 받아서 챌린지 인증 카운터로 연결해주는 다리를 놓은 거죠. 덤으로 "같은 날 여러 번 완료해도 인증은 하루 한 번만" 되도록 중복 방지 장치도 같이 넣었고요.
그래도 미심쩍어서 — "진짜 되는 거 맞아?"
수정이 끝났다고 AI가 말했지만, 저는 한 번 더 확인하고 싶었어요. 테스트가 통과했다는 말만으론 안심이 안 됐거든요.
진짜 제대로 된 거 맞아? 누군가 스킬을 만들고 → 동작시키고 → 완료한 것까지
데이터로 들어와서, 챌린지 참여자 현황을 팔로업할 수 있게 된 건지 확신이 안 서.
그래서 더 깐깐한 검증 모드를 한 번 더 돌렸어요. 이번엔 '누가 만들고 누가 실행했는가' 라는 신원 문제까지 파고들었는데, 여기서 중요한 경계를 하나 발견했어요.
각자 본인 스킬을 만들어 본인이 완료 → 정상 작동 ✅
한 사람이 만든 걸 여러 명이 돌려쓰면 → 인증이 만든 사람에게만 몰림 ⚠️
다행히 이번 챌린지는 참여자가 각자 본인 스킬을 만들어 쓰는 방식이라 정상 케이스에 딱 해당했어요. AI가 "이 경우엔 문제없지만, 이런 경우엔 주의해야 한다"까지 짚어준 덕에 안심하고 넘어갈 수 있었죠.
마지막엔 이런 질문도 했어요.
실제로 잘 되는지 사람이 직접 테스트할 필요는 없어?
AI의 답은 솔직했어요. "자동 테스트로 서버 로직은 증명했지만, 배포한 뒤에 사람이 화면에서 숫자가 실제로 오르는지 딱 한 번은 눈으로 봐야 한다"고요. 그래서 배포 후 직접 확인할 체크리스트까지 받아뒀습니다.
💡 세 번째 팁. AI가 "다 됐어요"라고 해도, "진짜 끝까지 되는 거 맞아? 사람이 확인할 건 없어?" 라고 한 번 더 되물어보세요. 자동 테스트가 못 덮는 마지막 한 칸을 AI가 솔직하게 알려줘요.
AI 활용 팁!
이 방식은 "내가 만든 게 진짜 끝까지 잘 돌아가나?" 싶은 모든 상황에 써먹을 수 있어요.
새 기능을 붙였는데 기존 기능이 안 깨졌는지 불안할 때
결제·신청·인증처럼 중간에 한 군데만 끊겨도 치명적인 흐름을 점검할 때
"분명 바꿨는데 어디서 연결이 끊긴 것 같다" 싶은 막연한 의심이 들 때
한 가지 전제는 있어요. AI에게 "수정까지 해줘"라고 명확히 말하고, 끝나면 "사람이 확인할 게 없냐"고 되묻는 것. 이 두 마디가 점검의 완성도를 크게 바꿔요.
솔직한 마무리 — 이번엔 로나의 직접적인 도움은 못 받았어요
사실 이 작업은 처음에 로나(제가 만드는 서비스)로 시작했어요. 로나에 "이 방법론으로 챌린지를 QA하고 싶다"고 요청하니, 로나가 이 작업에 맞춘 스킬을 하나 만들어주더라고요.
그런데 솔직히 말하면, 이번엔 로나에게서 직접적인 도움을 받았다고 말하기는 어려웠어요. 끝나고 기록을 되짚어보니 이런 점들이 아쉬웠거든요.
방법론은 결국 제가 가져온 거였어요. 로나가 더 좋은 방법론을 찾아다 준 게 아니라, 제가 링크로 준 그 방법론(QA 루프)을 그대로 옮겨 담은 정도였어요.
로나가 새로 더해준 부분(QA 도구 추천)이 하필 제 프로젝트와 안 맞았어요. Playwright·Sentry 같은 일반적인 도구를 제안했는데, 제 실제 환경과 달라서 결국 통째로 버리고 다른 방식으로 갈아탔어요.
그래서 진짜 문제를 진단하고 고친 건 결국 클로드코드였고, 로나는 출발 버튼에 가까웠어요.
조금 민망하지만 제 서비스를 제가 써보고 정직하게 남겨요. "AI가 맞춤 스킬을 만들어준다"는 게 방향과 틀은 잡아줄 수 있어도, 그 사람의 실제 환경에 딱 맞는 도움까지 되려면 아직 갈 길이 있다는 걸 이번에 제 손으로 확인했어요. (이건 다음 개선 과제로 가져갑니다.)
