📬 Weekly AI Sadari 26호
안녕하세요, AI 전도사 문단열입니다.
요즘 "저 앱 만들었어요"라는 말을 정말 많이 듣습니다. 바이브코딩 덕분에 코딩 몰라도 뚝딱 만드는 시대가 됐으니까요. 그런데 저는 거기서 꼭 하나를 여쭤봅니다.
"지금도 쓰고 계세요?"
이번 주는 만드는 것보다 10배 중요한 것, 피드백루프에 대해 이야기합니다.
📚 오늘의 모든 학습자료(슬라이드, 팟캐스트, 퀴즈 등)는 레터 하단에 링크로 준비해두었습니다.
🔥 "만들었다"와 "쓴다"는 전혀 다른 말이다
저희 팀 이야기를 먼저 꺼내야 할 것 같습니다.
지난 몇 달 동안 저는 Claude Code로 사내 툴을 수십 개 만들었습니다. 사다리필름 포털, 프로젝트 관리 툴, 문서 아카이빙 툴, 캐릭터 생성기, 자동 스토리보드 생성기… 만들 때마다 신났습니다. "이거 쓰면 업무가 달라질 것 같다"는 확신도 있었고요. 그런데 어느 날 돌아봤습니다.
팀원들이 안 쓰고 있었습니다.
처음엔 당황했습니다. 분명히 잘 만들었는데. 기능도 다 있는데. 왜 아무도 안 쓰는 걸까.
가까이 가서 물어보니 이유가 나왔습니다.
"편하긴 한데, 실무랑 딱 맞진 않아요."
아, 그거였습니다. 제가 생각한 실무와, 팀원들이 매일 부딪히는 실무 사이에 미묘한 거리가 있었던 겁니다. 기능이 없는 게 아니라, 내가 만든 방식이 그들이 일하는 방식과 어긋났던 것. 저는 기획자 입장으로 만들었고, 팀원들은 실무자 입장에서 쓰려 했던 것.
만드는 사람 따로, 쓰는 사람 따로. 이 구도가 굳어지는 순간 툴은 방치됩니다. 아무리 잘 만든 툴도요.
첫 번째 배움: 요구사항 정의는 질문의 기술이다
그래서 저는 방향을 바꿨습니다. 개발에 착수하기 전에, 쓸 사람의 이야기를 먼저 듣기로 했습니다. 그런데 여기서 함정이 있습니다.
"어떤 기능이 있으면 좋겠어요?" 이 질문, 하면 안 됩니다.
이 질문을 받은 팀원은 기능을 상상해야 합니다. 자기가 써본 적 없는 것을 머릿속에서 그려야 해요. 그 대답은 대부분 "음… 뭔가 자동화 되면 좋겠어요" 같은 뭉뚱그린 말로 돌아옵니다. 쓸 수가 없어요.
대신 이렇게 물어야 합니다.
"지금 업무에서 뭐가 제일 번거로워요?" "오늘 하루 중에 가장 시간 낭비라고 느낀 순간이 언제예요?" "지금 어떤 방식으로 하고 있어요? 한번 보여줄 수 있어요?"
기능을 묻는 게 아니라, 불편을 캐내는 것. 현재 방식을 눈으로 보는 것. 이게 진짜 요구사항 정의입니다.
이렇게 하면 "파일 이름 바꾸는 게 매번 헷갈려요", "이 승인 단계가 너무 많아요", "복붙을 하루에 50번은 하는 것 같아요" 같은 말이 나옵니다. 이게 진짜 재료입니다. 여기서 만들어야 할 것이 보입니다.
두 번째 배움: 그래도 피드백루프는 반드시 필요하다
그런데 여기서 끝이 아닙니다.
아무리 요구사항을 잘 받아도, 실제로 써보기 전까지 모르는 것들이 있습니다.
사람은 자기가 느끼는 불편감을 100% 말로 꺼낼 수 없습니다. 말로 꺼내려면 그 불편이 의식 위로 올라와야 하는데, 많은 불편은 무의식 수준에 잠겨 있어요. 오래 써온 방식일수록 더 그렇습니다. "이게 불편한지 몰랐는데 써보니까 영 이상하네요"라는 말은, 요구사항 인터뷰 자리에서는 절대 나오지 않습니다. 직접 써봐야만 나오는 말이에요.
그래서 피드백루프가 필요합니다.
피드백루프란 간단히 말하면 이겁니다.
빠르게 만든다 → 실제로 써본다 → 불편을 발견한다 → 고친다 → 다시 써본다
이 사이클을 한 바퀴 도는 것. 그리고 또 돌리는 것.
한 번에 완벽하게 만들려는 시도는 시간만 잡아먹습니다. 요구사항을 완벽히 받아도, 설계를 아무리 잘 해도, 첫 번째 버전은 항상 어딘가 어긋납니다. 이건 실력의 문제가 아니에요. 쓰기 전에는 알 수 없는 것들이 존재하기 때문입니다.
바이브코딩의 진짜 강점은 빠르게 만드는 것입니다. 그 강점을 살리는 방법은, 그 빠름을 피드백루프에 연결하는 것입니다.
빠르게 만들고, 빠르게 써보고, 빠르게 고치고, 또 써보고.
이 사이클이 수십 번 돌아야 팀 전체가 실제로 쓰는 툴이 됩니다. 전사 자동화, 업무 시스템화. 거기까지 가는 길은 단번에 완성된 툴이 아니라, 수십 번의 피드백루프가 쌓인 결과물입니다.
처음 만든 것과 반년 뒤의 것이 다른 툴처럼 느껴져야 정상입니다. 그게 잘 되고 있다는 신호입니다.
📋 이번 주 액션 아이템
☑️ 지금 쓰지 않는 바이브코딩 결과물 1개 꺼내기 → "왜 안 쓰고 있는지" 이유 한 줄만 적기
☑️ 그 툴을 쓸 사람 한 명에게 직접 물어보기 → "지금 업무에서 뭐가 제일 번거로워요?" (기능 묻지 말 것)
☑️ 그 대화를 바탕으로 AI에게 개선 방향 3가지 뽑아달라고 하기 → 그 중 하나만 바로 고쳐보기
🧪 피드백을 받는 툴도, 바이브코딩으로 만들면 됩니다
그럼 피드백루프를 실제로 어떻게 '돌릴' 것인가.
여기서 현실적인 문제가 생깁니다. 팀원들이 툴을 쓰다가 불편한 점이나 오류를 발견하면 당연히 저한테 알려줍니다. 그런데 그 경로가 제각각이었어요.
카카오톡으로 왔습니다. 슬랙으로도 왔습니다. 복도에서 구두로도 왔어요. 어떤 팀원은 메모 앱에 써뒀다가 나중에 몰아서 보내기도 했습니다.
피드백은 분명히 오고 있었는데, 흩어졌습니다. 어떤 앱에서 어떤 문제가 얼마나 자주 터지는지 파악이 안 됐어요. 뭘 먼저 고쳐야 하는지도 모르겠고, 고친 게 있는지 없는지도 뒤섞였습니다.
피드백이 모이지 않으면, 피드백루프는 돌아가지 않습니다.
Claude Code에게 부탁한 것
그래서 저는 또 Claude Code를 켰습니다.
이번엔 이렇게 말했어요.
"우리 팀이 만든 사내 웹앱들에 대해 팀원들이 피드백을 남길 수 있는 트래커가 필요해. 어떤 앱에서 온 이슈인지 구분되고, 긴급도랑 유형도 태그로 나눌 수 있고, 담당자가 댓글로 소통하면서 처리 상태를 관리할 수 있게 해줘."
복잡한 기획서가 아니었습니다. 한 문단짜리 요청이었어요.
Claude Code는 질문을 몇 가지 되물었습니다. 어떤 기술 스택을 쓸지, 사용자 구분이 필요한지, 첨부파일 기능이 있어야 하는지. 그 대화를 주고받으면서 방향이 구체화됐고, 첫 번째 동작하는 버전이 나오는 데 한 시간이 채 안 걸렸습니다.
실제로 이렇게 생겼습니다
📸 트래커 메인 화면
화면 왼쪽엔 미확인 이슈가 쌓입니다. 긴급도 태그(긴급/보통), 이슈 유형(수정/개선), 어느 앱에서 온 건지(FPM, SID Explorer 등), 누가 올렸는지, 언제 올렸는지가 한눈에 보입니다.
오른쪽엔 개발자가 확인한 이슈가 넘어갑니다. 담당자가 댓글로 소통하고, "개발 완료" 체크를 누르면 완료 이슈로 이동합니다. 지금 완료된 이슈만 14건, 처리 중인 것이 43건입니다.
📸 새 피드백 등록 폼
등록 폼은 이렇게 생겼습니다. 제안자 이름, 제안 종류(개선/수정), 긴급도(긴급/보통), 이슈 제목, 해당 앱/페이지, 상세 내용, 첨부파일. 팀원 입장에서 30초면 올릴 수 있습니다.
처음 버전에는 첨부파일 기능이 없었습니다. 쓰다 보니 "스크린샷도 같이 올리고 싶다"는 말이 나왔고, 그걸 피드백으로 받아서 추가했습니다. 트래커 자체도 피드백루프로 개선된 거예요.
달라진 것들
도입하고 나서 세 가지가 달라졌습니다.
하나, 피드백이 한 곳에 모입니다. 카카오톡이나 복도 대화로 오던 것들이 전부 트래커로 들어옵니다.
둘, 우선순위가 보입니다. 어떤 앱에 이슈가 몰리는지, 긴급 태그가 많이 붙는 게 어떤 건지 눈으로 확인됩니다. 뭘 먼저 고칠지 판단이 생깁니다.
셋, 기록이 쌓입니다. 완료된 이슈 14건. 이게 숫자로 보이니까 팀원들도 "이게 진짜 개선되고 있구나"를 느낍니다. 피드백을 남기는 게 허공에 외치는 게 아니라는 걸 알게 되는 것, 이게 참여를 지속시킵니다.
여러분은 어디서 시작할까요
거창하게 생각할 필요 없습니다. 규모에 따라 이 세 가지 중 하나면 충분합니다.
① 나 혼자 쓰는 툴이라면 — 노션 페이지 하나로 됩니다. "쓰다가 불편했던 점" 칸 하나만 만들어두고 생각날 때마다 적는 것. 이게 피드백루프의 최소 단위입니다.
② 소수 팀이 함께 쓴다면 — 구글 시트로 충분합니다. 앱 이름, 불편한 점, 긴급도, 처리 여부. 열 네 개짜리 시트 하나가 카톡 피드백 100개보다 낫습니다.
③ 팀 전체가 쓰는 사내 툴이라면 — 저희처럼 트래커를 바이브코딩으로 직접 만드세요. 한 문단짜리 요청으로 시작하면 됩니다. 완벽하지 않아도 괜찮아요. 쓰면서 고치면 됩니다. 그게 피드백루프니까요.
만드는 것보다 고치는 것이 오래 걸립니다. 그리고 고치는 것이 쌓여야 진짜 쓰는 툴이 됩니다.
피드백루프는 선택이 아닙니다. 바이브코딩의 두 번째 단계입니다.
뉴스레터에서 궁금하거나 문의하고 싶은 점이 있다면 언제든 의견 남겨주세요.
📧 오늘의 학습 자료
아래 링크에 오늘의 학습자료들을 담아뒀어요!
출퇴근시간에 10분만 투자해서 복습해보세요. 매주 쌓이면 당신의 자산이 됩니다.
💌 구독하세요
매주 월요일 아침 8시, 당신의 뇌가 가장 편한 방식으로 최신 AI 인사이트를 전해드립니다.
의견을 남겨주세요