AI 에이전트를 위한 피드백 보드: 프롬프트는 사용자가 쓰게 하세요

밤 11시에 사용자에게서 연락이 옵니다. "Safari에서 내보내기 버튼이 아무 반응이 없어요."

다음에 무슨 일이 벌어질지는 이미 압니다. 백 번은 겪은 일이니까요. 읽습니다. 이해합니다. 그리고 트래커를 열어 같은 내용을 당신의 말로 다시 씁니다. 파일 경로와 재현 절차, 사용자가 알 수 없었던 맥락까지 붙여서요. 그리고 나중에 터미널을 열어 세 번째로 또 씁니다. 이번에는 프롬프트로.

같은 요청을 세 번 쓴 셈입니다. 첫 번째는 공짜였고, 실제로 그 버그를 만난 사람이 써 줬습니다. 나머지 둘은 당신이 썼습니다.

에이전트가 등장하면서 우스워진 부분이 바로 그 두 번째와 세 번째 쓰기입니다.

아직도 손으로 치고 있는 마지막 한 가지

코딩 에이전트는 타이핑을 많이 없앴습니다. 그런데 브리핑은 없애지 못했습니다. 누군가는 여전히 에이전트에게 무엇을 만들지, 추측하지 않아도 될 만큼 자세히 알려 줘야 합니다. 그리고 그 누군가는 여전히 키보드 앞에 앉아 남의 말을 지시문으로 옮기고 있는 사람입니다.

그런데 그 옮기는 작업은 대개 의미가 없습니다. 잘 쓴 버그 리포트에는 에이전트에게 필요한 것이 이미 다 들어 있습니다. 무엇을 기대했는지, 실제로 무슨 일이 일어났는지, 어느 페이지에서, 어느 브라우저에서. 잘 쓴 기능 요청에는 의도와 이유가 이미 들어 있습니다. 그 글을 쓴 사람은 당신보다 문제에 가까이 있었습니다.

그런데도 우리는 그 글을 다시 가공해야 할 원재료처럼 다룹니다. 그 글을 모은 도구와 실제로 일을 굴리는 도구가 한 번도 같은 도구였던 적이 없기 때문입니다. 피드백은 이 제품에, 티켓은 저 제품에 있고, 에이전트는 둘 다 모르는 터미널에서 돕니다.

그 틈을 없애면, 다시 쓰는 단계는 일어날 자리가 사라집니다.

실행할 줄 아는 보드가 되면 피드백 보드는 달라집니다

공개 백로그는 사용자가 직접 들어올 수 있는 페이지입니다. 버그를 알리고, 기능을 요청하고, 남이 올린 요청에 추천을 누르고, 스레드를 따라가고, 상태가 바뀌는 것을 지켜봅니다. 여기까지는 피드백 보드이고, 잘 만든 제품도 여럿 있습니다.

다른 점은 티켓이 어디에 떨어지느냐입니다. 내보내기를 기다리는 피드백 전용 제품에 떨어지지 않습니다. 에이전트가 이미 작업을 꺼내 가고 있는 작업 보드에, 당신이 직접 쓴 티켓 옆에, 똑같은 자격의 티켓으로 떨어집니다.

거기서 티켓을 In Progress로 옮기면 그 티켓을 브리핑 삼은 에이전트가 뜹니다. 제목, 제보자가 쓴 그대로의 설명, 그 사람이 있던 페이지, 쓰던 브라우저, 그리고 그 뒤로 주고받은 대화까지. 아무도 다시 쓰지 않았습니다. 프롬프트가 곧 제보 글입니다.

여기서 흥미로운 결과는 속도가 아닙니다. 문제를 설명한 사람이 곧 작업을 명세한 사람이 된다는 점입니다. 사용자 피드백에서 다들 원한다고 말하면서 거의 아무도 그렇게 구조를 짜지 않는 것이 바로 이것입니다. 이 뒤집힘에는 이름이 있습니다. 클라이언트 주도 백로그입니다. 큐는 무엇이 중요할지에 대한 당신의 추측이기를 그만두고, 실제로 요청받은 것들의 기록이 됩니다.

입구가 셋인 이유, 사람은 자기가 있는 자리에서 말합니다

피드백 보드는 다른 데 가서 불평하는 것보다 여기에 제보하는 게 더 싸게 먹힐 때만 굴러갑니다. 그러려면 문제가 벌어진 그 자리에서 사람을 만나야 합니다.

공개 페이지는 가장 뻔한 입구입니다. 공유할 URL 하나, 목록이나 로드맵 화면, 추천, 그리고 등록 폼. 북마크해 둘 사용자가 있는 제품에 맞고, 동시에 작업이 굴러가고 있다는 눈에 보이는 증거 역할도 합니다. 아무도 읽지 않는 진행 상황 메일보다 값어치가 훨씬 큽니다.

두 번째는 심어 넣는 위젯입니다. 당신 사이트에 작은 스크립트를 넣으면 그 자리에서 폼이 열립니다. 제보하는 사람은 버그가 있는 페이지를 떠나지 않습니다. 사람이 문제를 설명해 줄 마음이 가장 큰 순간이 정확히 그때입니다.

세 번째는 Chrome 확장 프로그램이고, 행동을 가장 크게 바꾸는 것도 이쪽입니다. 사용자가 아무 페이지에서나 깨진 부분의 텍스트를 선택하고 확장 프로그램을 누르면, URL과 선택 영역이 이미 붙은 채로 티켓이 등록됩니다. 당신에게 도착하는 것은 "안 돼요"가 아니라 좌표가 찍힌 제보입니다.

에이전시라면 세 번째 입구를 쓰는 사람은 대개 클라이언트 본인이고, 클라이언트 포털 모드는 초대 전용입니다. 클라이언트마다 보드 하나, 다른 사람은 볼 수 없고, 스택에 SaaS 구독을 하나 더 얹을 일도 없습니다.

라우팅, "맞는 에이전트"는 한 명이 아니니까

들어온 티켓에는 수신인이 없습니다. 어떤 수신함이든 실무에서 걸리는 문제가 이것입니다. 누가 맡을지 누군가는 정해야 합니다.

밖에서 들어온 티켓은 전문 분야가 맞는 에이전트에게 자동으로 배정됩니다. 깨진 레이아웃은 프런트엔드 담당에게, 새는 쿼리는 백엔드 담당에게 갑니다. 매일 아침 큐를 손으로 분류할 일이 없습니다. 아무것도 설정하지 않았을 때의 기본 동작은 일부러 단순하고 예측 가능하게 만들어 뒀습니다. 프로젝트의 첫 번째 개발 에이전트에게 가고, 어쩌다 목록 맨 위에 있는 마케팅이나 PM 역할에게는 절대 가지 않습니다.

티켓을 에이전트 한 명이 아니라 에이전트 팀 전체에 걸 수도 있습니다. 그러면 클라이언트 요청이 당신에게 오기 전에 개발 단계와 QA 단계를 차례로 거칩니다.

다들 잊는 부분: 제보한 사람에게 무엇이 돌아가는가

피드백을 모으는 일은 쉽습니다. 제품이 사람을 잃는 자리는 그 고리를 닫는 지점입니다.

티켓이 개발에 들어가면 작성자에게 알려 줍니다. 우선순위가 올라가면 알려 줍니다. 하지 않기로 정하면 그것도 당신이 쓴 이유와 함께 알려 줍니다. 침묵보다 훨씬 낫습니다. 그리고 수정이 실제로 배포되면 그 사실을 알리는 메시지가 갑니다. 티켓 다섯 개에 메일 다섯 통이 아니라, 릴리스마다 알림 하나로 묶어서요.

보이는 것보다 중요한 작은 디테일이 하나 있습니다. 사용자 티켓을 닫는 커밋에는 제보자의 이름이 남고, 그 크레딧은 공개 변경 이력까지 그대로 따라갑니다. 배포된 변경에 자기 이름이 붙은 걸 본 사람은 다음 버그도 알려 줍니다. 리텐션 장치는 그게 전부이고, 돈은 한 푼도 들지 않습니다. 이 고리를 몇 달 굴리면 피드백 주도 개발이 구호가 아니라 눈으로 확인되는 사실이 됩니다. 추천이 순서를 정하고, 순서가 릴리스를 정합니다.

요청이 모호하게 들어오면 제보와 작업 사이에 티켓 범위 잡기가 들어갑니다. Product Manager 에이전트가 흐릿한 요청을, 그 변경이 반영된 당신 제품의 실제 목업으로 바꿔 줍니다. 코드 한 줄 쓰기 전에 같은 티켓 안에서 아이디어를 검증할 수 있습니다.

기존 도구들이 멈추는 지점

기존 강자들을 깎아내리려는 얘기가 아닙니다. Canny, Featurebase, Fider, UserVoice는 수집과 중복 정리와 순위 매기기를 잘하고, 제품 팀에게 중요한 부분들은 수년에 걸쳐 다듬어져 있습니다. 이들이 전부 같은 자리에서 멈추는 이유도 하나입니다. 구조가 그렇습니다. 엔지니어링이 다른 부서에 있고 내보내기를 거쳐야만 닿을 수 있는 조직을 위해 만들어진 도구들이니까요.

결정적인 것은 마지막 줄입니다. 큰 조직에서는 요청을 명세로 다시 쓰는 일 자체가 진짜 직무이고 진짜 가치가 있으며, 내보내기는 병목이 아닙니다. 코딩 에이전트로 제품을 내보내는 1인에서 5인짜리 팀에서는 그 다시 쓰기가 병목이고, 순수한 손실입니다.

이걸로 해결되지 않는 것

에이전트에 연결된 피드백 보드는 자동 조종 장치가 아닙니다. 그렇게 다루면 예상 그대로의 결과가 나옵니다.

나쁜 티켓은 여전히 나쁜 결과를 만듭니다. 재현 경로 없는 한 줄짜리 제보는 에이전트에게 붙잡을 것을 아무것도 주지 못하고, 에이전트는 자신만만하게 엉뚱한 일을 합니다. 보드는 쓰여 있는 것만 전달할 수 있습니다.

저절로 병합되는 것은 없습니다. 에이전트가 내놓는 것은 브랜치와 diff이고, 에이전트 결과물을 검토할 때 원래 지키던 규칙은 전부 그대로 유효합니다. 인증, 결제, 데이터를 건드리는 것이라면 더욱 그렇습니다. 낯선 사람이 올린 티켓이라는 사실은 그 기준을 낮출 이유가 아닙니다. 오히려 높일 이유입니다.

그리고 물량은 실제로 문제가 됩니다. 잘 굴러가는 공개 보드는 시끄러워집니다. 좋은 문제이지만 치러야 할 비용은 진짜입니다. 중복은 등록 시점에 표시되고, 추천 수는 한 사람이 원한 것과 마흔 명이 원한 것을 갈라 주고, 이유를 적어 티켓을 닫는 편이 그냥 썩게 두는 것보다 빠릅니다. 그래도 수신함을 읽는 사람은 여전히 필요합니다.

설정하는 법

프로젝트의 백로그를 열고, Public backlog를 누르고, URL과 공개 범위를 고릅니다. 설정은 그게 전부이고, 그 시점부터 페이지가 살아 있습니다.

설정보다 중요한 것은 그다음입니다. 링크를 사용자가 이미 있는 자리에 두세요. 앱 안, 고객 응대 답장, 릴리스 노트 맨 아래. 아무도 모르는 피드백 보드는 아무것도 모으지 못합니다. 이 기능이 실패하는 방식은 기술적인 것이 아니라, 링크가 끝내 공유되지 않는 것입니다.

AgentsRoom은 이 모든 게 돌아가는 지휘 본부입니다. 카드 하나가 돌아가는 에이전트가 되는 작업 보드, 거기에 연결된 공개 또는 비공개 피드백 페이지, 심어 넣는 위젯, Chrome 확장 프로그램, 그리고 작업이 실제로 배포될 때 나가는 클라이언트 알림. Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code와 함께 동작합니다.

AgentsRoom을 다운로드하고 첫 보드를 공개해 보세요.

자주 묻는 질문

AI 에이전트를 위한 피드백 보드란 무엇인가요?

사용자가 버그를 알리고 기능을 요청하는 공개 페이지인데, 코딩 에이전트가 작업을 꺼내 가는 바로 그 작업 보드에 연결되어 있습니다. 기존 피드백 도구와 갈라지는 지점은 마지막 단계입니다. 요청을 트래커로 내보내 프롬프트로 다시 쓰는 대신, 티켓 자체가 제보자가 쓴 문장 그대로 에이전트의 브리핑이 됩니다.

사용자가 올린 티켓이 정말 알아서 AI 에이전트를 시작시키나요?

시작은 여전히 의도적인 행동입니다. 누군가 티켓을 In Progress로 옮기면 그 티켓을 프롬프트 삼아 에이전트가 뜹니다. 자동으로 굴러가는 것은 라우팅입니다. 들어온 티켓을 전문 분야가 맞는 에이전트에게 보내 줍니다. 낯선 사람이 쓴 글이라면 무엇이든 그대로 실행하는 완전 자동은 기능이 아니라 보안 구멍입니다.

Canny, Featurebase, Fider, UserVoice와 무엇이 다른가요?

그 도구들은 수요를 모으고 중복을 정리하고 순위를 매기는 일을 아주 잘합니다. 그리고 전부 같은 자리에서 멈춥니다. 우선순위가 매겨진 목록을 건네주면, 그 한 줄 한 줄을 실제 작업으로 바꾸는 일은 여전히 사람 몫입니다. 실행 계층이 없는 이유는 애초에 엔지니어가 다른 부서에 있는 제품 팀을 위해 만들어졌기 때문입니다. 여기서 거는 쪽은 정반대입니다. 수집하는 면과 실행하는 면이 같은 물건입니다.

쓰려면 로드맵을 반드시 공개해야 하나요?

아닙니다. 공개, 비공개 링크, 초대 전용은 서로 다른 세 가지 모드입니다. 클라이언트마다 보드를 하나씩 두는 에이전시는 초대 전용을 쓰고, 검색 엔진은 그 보드를 영영 보지 못합니다. 사용자에게 요청과 추천을 받고 싶은 1인 개발자는 공개를 씁니다. 실행 부분은 세 모드 모두 똑같이 동작합니다.

공개 보드가 잡음으로 가득 차는 것은 무엇이 막아 주나요?

잡음이 들어오는 것 자체를 막아 주는 건 없고, 막아 준다고 말하면 거짓말입니다. 보드가 바꾸는 것은 잡음을 처리하는 비용입니다. 중복에 가까운 글은 등록 시점에 표시되고, 추천 수는 실제로 원하는 것이 무엇인지 알려 주고, 하지 않기로 한 티켓은 작성자에게 가 닿는 이유와 함께 닫힙니다. 남겨 두기로 한 티켓은 낯선 사람이 이미 대신 써 준 맥락을 달고 도착합니다.