AI 코딩의 마지막 10%: 피드백을 문맥으로 남기는 방법

핵심 요약 (TL;DR)

AI로 첫 화면을 만드는 속도는 빨라졌지만, 마지막 10%를 다듬는 일은 여전히 느립니다. ‘여기 느낌이 이상해요’, ‘버튼을 조금 더 자연스럽게’ 같은 피드백은 사람에게도 모호하고 에이전트에게는 더 모호합니다. 최근 공개된 오픈소스 도구 Remarc는 화면 요소, 선택한 텍스트, 스크린샷, 음성 의견을 문맥과 함께 남기고 MCP를 통해 에이전트가 읽게 하는 접근을 제안합니다. 이 도구를 꼭 써야 한다는 뜻은 아닙니다. 중요한 신호는 AI 협업의 병목이 생성이 아니라, 정확한 피드백 전달로 이동하고 있다는 점입니다.

긴 프롬프트가 왜 자꾸 어긋날까요?

채팅 한 줄에는 ‘어느 화면의 어느 버튼인지’, ‘현재 상태가 무엇인지’, ‘무엇은 유지해야 하는지’가 빠지기 쉽습니다. AI는 빈자리를 그럴듯하게 채우고, 우리는 다시 캡처를 보내며 수정합니다. 이런 왕복은 모델 능력보다 입력의 구조 문제일 때가 많습니다. Remarc의 소개처럼 특정 요소를 가리키고 의견을 남기는 방식은, 대화가 아닌 주석에 가깝습니다. 대상과 요청을 묶어 두면 에이전트가 바꿔야 할 곳과 건드리지 말아야 할 곳을 구분하기 쉬워집니다.

피드백을 어떻게 구조화하면 좋을까요?

수정 요청 하나를 ‘대상·문제·원하는 변화·확인 기준’ 네 줄로 작성해 보세요. 예를 들어 ‘모바일 결제 버튼 / 하단 메뉴와 겹침 / 메뉴 위로 고정 / 작은 화면에서 끝까지 보임’처럼 적습니다. 화면 캡처가 있다면 표시를 하나만 하고, 기존 디자인을 유지할 영역도 함께 적으세요. 한 요청에 여러 문제를 넣지 않는 원칙도 중요합니다. 에이전트는 속도가 빠르므로, 작은 단위의 명확한 요청이 더 짧은 시간에 좋은 결과로 돌아옵니다.

수정 완료는 무엇으로 판단할까요?

‘완료했습니다’라는 에이전트의 문장으로 끝내지 마세요. 변경된 파일, 바뀐 화면, 직접 확인한 조건을 함께 받으세요. 상태를 열린 항목·검토 중·완료로 나누면, 수정이 누락됐는지도 보입니다. 특히 디자인 수정은 데스크톱 화면 하나만 보고 끝내기 쉽습니다. 모바일 폭, 빈 데이터, 긴 문구, 오류 메시지를 최소한 한 번씩 확인해야 합니다. 피드백 기록은 AI를 감시하는 장치가 아니라, 다음 변경에서 같은 설명을 반복하지 않게 하는 프로젝트의 기억입니다. 요청을 닫을 때는 해결된 이유와 남은 의문도 한 줄로 남기세요. 다음 에이전트나 미래의 내가 화면을 다시 만질 때, 그 기록이 가장 짧은 인수인계가 됩니다.

FAQ: MCP를 바로 연결해야 하나요?

아닙니다. 먼저 문서나 이슈에 네 줄 피드백을 남기는 것만으로도 효과가 있습니다. MCP는 그 문맥을 에이전트 작업 흐름에 더 자연스럽게 연결하고 싶을 때 검토하면 됩니다.

FAQ: 피드백이 많으면 한 번에 맡겨도 되나요?

서로 독립적인 항목이라면 목록으로 전달할 수 있습니다. 다만 결제·권한처럼 위험한 변경은 한 항목씩 확인하고 다음 단계로 가는 편이 안전합니다.

출처: https://github.com/metedata/Remarc | https://news.ycombinator.com/item?id=49323749
관찰 시점: 2026-08-18 KST