완벽한 프롬프트 대신 화면으로 보여준다: Loom의 에이전트 업무 전달

문제는 한눈에 보입니다. 시안에서는 버튼이 입력 양식 아래에 있지만 실제 앱에서는 옆에 있고, 휴대전화에서는 오류 메시지가 나타나면 둘 다 화면 밖으로 밀려납니다. AI 코딩 에이전트가 이해하도록 설명하는 데는 사람에게 직접 보여주는 것보다 오랜 시간이 걸리기도 합니다.

2026년 10월 22일 Atlassian은 여러 Loom 업데이트와 함께 Record for agent를 소개했습니다. 화면을 보여주며 설명한 녹화를 AI 에이전트용 지시로 바꾸는 녹화 모드입니다. 동료에게 업무 화면을 보여주는 비동기 영상 도구인 Loom이 같은 소통 방식을 다음 작업을 수행하는 소프트웨어로 확장한 셈입니다. 지원 문서에 따르면 Business + AI 및 Enterprise 요금제 대상 오픈 베타이며, 녹화 시간은 5분으로 제한됩니다. 발표, 현재 이용 조건.

눈여겨볼 변화는 에이전트가 영상을 받을 수 있다는 사실 자체보다, 익숙한 녹화 과정에서 검토하고 수정한 뒤 전달할 수 있는 작업 지시서가 나온다는 점입니다. 핵심은 긴 프롬프트를 잘 쓰는 경쟁이 아니라 실제로 일을 잘 넘기는 방법이 됩니다.

제품을 식별하기 위한 공식 Loom 로고입니다. Record for agent의 화면 캡처가 아닌 브랜드 마크입니다. 로고: Loom / Atlassian. 상표 사용 정책.

녹화는 설명에서 빠지기 쉬운 맥락을 담는다

좋은 버그 보고에는 “양식이 고장 났다”는 말 이상이 필요합니다. 시작 상태, 문제를 일으킨 동작, 기대했던 결과, 실제 결과가 있어야 합니다. 이 정보가 여러 캡처와 복사한 URL, 채팅 메시지에 흩어져 있으면 수정을 시작하기 전에 누군가가 관계를 다시 맞춰야 합니다.

Loom의 문서상 흐름은 음성 지시와 화면 키프레임, 상호작용 이벤트, 방문 링크를 결합합니다. Chrome 확장 프로그램에서는 콘솔 메시지와 네트워크 요청·응답 메타데이터도 수집할 수 있습니다. 데스크톱 버전은 화면의 특정 부분을 가리킬 수 있는 선택 및 그리기 도구를 제공합니다. 이 정보는 지시서를 만드는 입력이며, 제안된 수정이 제대로 작동한다는 증거와는 구분해야 합니다. 캡처 항목.

저희가 주목하는 부분은 소통의 단위가 달라진다는 점입니다. 캡처는 상태를, 문장은 의도를 보여줍니다. 짧은 시연은 한 상태가 어떻게 다른 상태로 바뀌어야 하는지 설명할 수 있습니다. 생성된 지시서는 그 설명과 실행할 작업을 연결합니다.

녹화를 맥락을 담아 보내는 소포라고 생각하면 이해하기 쉽습니다. 요청한 변경에 필요한 것은 모두 넣되, 관련 없는 것은 최소화해야 합니다. 5분이라는 제한도 이런 정리에 도움이 될 수 있습니다. 문제 하나를 보여주고, 그 영향을 설명하고, 분명한 완료 기준을 제시하는 방식입니다.

작업 전달 과정을 설명한 자체 도식입니다. 지시서 검토와 에이전트의 실제 작업 수행은 별도 단계입니다.

원하는 동작이 보이면 디자인 피드백도 쉬워진다

결제 화면을 조정하는 팀을 생각해 보겠습니다. 예시 시연에서 디자이너는 승인된 시안과 현재 앱을 열고 세 가지 차이를 짚을 수 있습니다. 좁은 화면에서 배송 옵션이 아래로 사라지고, 총액 갱신이 늦으며, 확인 메시지의 강조가 잘못됐다는 식입니다. 중요한 정보는 두 화면의 모양뿐 아니라 그 관계에 있습니다.

생성된 프롬프트를 검토하는 사람은 각각의 관찰을 동작으로 바꿔야 합니다. 에이전트가 같은 장면을 보고 있지 않을 때 “이것을 옮겨주세요”는 모호합니다. “좁은 화면에서 배송 옵션을 변경한 뒤에도 주문 총액이 보이게 해주세요”라면 구현자가 검증할 결과가 명확합니다.

특히 디자인 파일과 실행 중인 페이지를 함께 다루는 변경에 유용합니다. Loom 지원 문서도 Figma와 웹사이트 사이를 오가며 UI 변경을 설명하는 예를 듭니다. 보이는 참조를 담는 데 도움을 받을 수 있지만, 어느 참조를 기준으로 삼을지는 팀이 결정해야 합니다. 잘 다듬어진 시안에도 로딩, 오류, 권한 상태가 빠져 있을 수 있습니다. 지원되는 작업 흐름.

따라서 반드시 유지해야 할 조건을 한 문장 덧붙이는 편이 좋습니다. 결제 예시라면 총액이 선택한 배송 방식과 일치해야 한다거나, 변경한 필드에 키보드 포커스가 남아 있어야 한다는 조건입니다. 이런 제약은 시각적 시안에 드러나지 않는 경우가 많고 테두리 위치보다 중요할 수 있습니다.

제품 문구도 같은 방식으로 다룰 수 있습니다. 실제 화면에 놓인 문장을 보여주고, 누가 읽는지와 어떤 결정을 도와야 하는지 설명해 보세요. 온보딩 전체를 녹화하면 문장만 따로 떼어 놓았을 때 보이지 않는 어색한 전환을 전달할 수 있습니다.

버그 보고에는 재현 가능한 시작과 확인 가능한 끝이 필요하다

두 번째 활용 예는 반복되는 고객 지원 문제입니다. 데스크톱에서는 문서를 업로드할 수 있지만 작은 화면에서는 진행 표시가 비어 있다고 가정해 보겠습니다. 짧은 녹화로 파일 유형, 선택한 동작, 화면 전환, 피드백이 사라지는 지점을 보여줄 수 있습니다.

생성된 작업에도 완료의 정의가 필요합니다. “업로드를 고쳐주세요”만으로는 파일이 거절된 문제인지, 네트워크 응답이 없는 것인지, 성공한 결과를 UI가 표시하지 못한 것인지 알 수 없습니다. 유용한 지시서는 관찰한 증상과 추정 원인을 분리합니다.

처음에는 범위를 좁히는 편을 권합니다. 피드백이 사라지는 현상을 재현하고, 어느 계층이 책임지는지 확인하고, 회귀 검증을 포함한 변경을 제안하도록 하는 것입니다. 이후 서버 오류가 발견되면 그 증거를 바탕으로 조사 범위를 넓히면 됩니다. 화면 배치 문제 제보가 설명 없이 업로드 시스템 전체 재작성으로 바뀌어서는 안 됩니다.

로그를 읽는 데 익숙하지 않은 사람에게도 장점이 있습니다. 원인을 먼저 진단하지 않고도 문제가 생기는 순서를 보여줄 수 있기 때문입니다. 엔지니어나 에이전트는 기록된 맥락을 조사에 활용하고, 수정 후에는 처음 관찰한 현상과 비교할 수 있습니다.

녹화와 테스트 사례는 서로 다른 역할을 합니다. 녹화는 누군가가 겪은 일을 보존하고, 테스트는 소프트웨어가 계속 만족해야 하는 동작을 설명합니다. 좋은 흐름은 앞의 기록을 적절한 형태의 뒤 검증으로 이어줍니다.

프롬프트 복사와 Jira 작업 생성은 진입 조건이 다르다

Loom 오픈 베타는 Chrome 확장 프로그램이나 버전 2.0 이상의 데스크톱 앱에서 이용할 수 있습니다. 문서는 기본 프롬프트 흐름과 Jira 작업 항목 생성도 구분합니다. Jira 생성에는 Atlassian 관리 계정과 활성 Jira 구독이 필요합니다. 프로젝트 관리 체계를 바꾸지 않고 작업 전달부터 시험하려는 작은 팀에는 중요한 차이입니다. 이용 조건과 설정.

가장 단순한 시험은 이미 잘 아는 프로젝트에서 영향이 작은 작업 하나를 다루는 것입니다.

1. 관련 디자인, 공개 테스트 페이지 또는 개발 환경을 열고 설명할 수 있는 시작 상태를 준비합니다.
2. 지원되는 Loom 녹화기에서 Record for agent를 선택하고 관련 동작을 보여주며 변경 하나를 설명합니다.
3. 5분 제한 전에 녹화를 마치고 생성된 실행 지시를 처음부터 끝까지 읽습니다.
4. 모호한 지칭을 고치고 관련 없는 자료를 지운 뒤 구체적인 합격 기준을 덧붙입니다.
5. 프롬프트를 Markdown으로 복사해 사용할 에이전트에 전달하거나, 계정에서 지원하는 전달 또는 Jira 흐름을 이용합니다.
6. 변경을 수락하기 전에 에이전트의 결과를 원래 상황과 대조합니다.

이 순서라면 첫 실험을 이해하기 쉽게 유지할 수 있습니다. 기능이 도움이 되는지도 명료한 지시를 준비하는 시간과 추가 확인 질문 수를 비교해 판단할 수 있습니다.

에이전트가 빨리 끝냈다는 사실만으로는 충분하지 않습니다. 동료가 무엇이 바뀌었고 왜 원래 관찰을 해결하는지 설명할 수 없다면 전달 방식에 손볼 부분이 남아 있습니다. 가장 유용한 이득은 검토를 줄이는 것보다 맥락을 다시 맞추는 수고를 줄이는 데 있습니다.

맥락이 풍부할수록 공유할 정보도 신중히 고른다

화면만으로는 무슨 일이 있었는지 알 수 없기 때문에 기술적 맥락이 가치 있습니다. 실패한 요청, 예상 밖 리디렉션, 콘솔 오류가 눈에 보이는 증상과 다른 원인을 가리킬 수 있습니다. 동시에 다른 도구로 보내고 싶지 않은 정보가 포함될 수도 있습니다.

녹화 전에는 관련 테스트 페이지를 사용하고 작업 범위를 분명히 해두세요. 녹화 후에는 생성된 지시서에 계정별 URL, 고객 식별자, 불필요한 로그 내용이 있는지 확인하는 편이 좋습니다. 문서에 나온 수집 항목을 보면 녹화를 일반 이미지 첨부처럼 취급하기보다 무엇을 확인할지 구체적으로 정할 수 있습니다.

핵심은 문제 해결에 필요한 정보를 보존하는 것입니다. 요청 식별자가 동료의 허가된 서버 추적 조회에 도움이 된다면 유용할 수 있습니다. 녹화 중 우연히 나타난 개인 알림이나 관련 없는 URL 목록은 UI 작업에 거의 도움이 되지 않습니다.

이 표는 제품의 추가 권한이나 모든 생성 작업에 모든 수집 정보가 들어간다는 보장이 아니라, 팀의 검토 질문입니다. 실제로 보내는 지시서에 무엇을 포함할지 결정하는 데 목적이 있습니다.

유용한 검토는 에이전트가 바꿔도 되는 것, 받는 정보, 결과를 판단하는 기준을 확인합니다.

첫 측정 대상은 설명이 얼마나 온전히 전달되는지다

업무를 줄일 가능성은 적어도 세 가지입니다. 디자이너는 시각적 차이를 길게 풀어 쓰지 않아도 됩니다. 지원 담당자는 문제가 기억에 생생할 때 순서를 보존할 수 있습니다. 개발자는 더 명확한 참조와 기대 결과를 포함해 에이전트에 일을 맡길 수 있습니다.

실패 양상도 각각 다릅니다. 디자인 피드백은 정상 경로 밖의 동작을 놓칠 수 있습니다. 지원 시연은 다른 사람이 재현할 수 없는 계정 상태에 의존할 수 있습니다. 개발자의 녹화는 정보가 너무 많아 실제 요청을 찾기 어려워질 수 있습니다.

첫 평가에서는 익숙한 작업 몇 개를 고르고 에이전트와 저장소는 동일하게 유지해 보세요. 생성된 지시서에 얼마나 많은 수정이 필요한지, 얼마나 자주 추가 설명을 요청하는지, 최종 변경이 명시한 조건을 만족하는지 기록하면 됩니다. 이런 측정이 커서가 움직이는 단발성 시연보다 소통의 품질을 잘 보여줍니다.

출력 품질과 작업 난이도도 나눠 보아야 합니다. 간단한 문구 수정은 어떤 지시서로도 성공할 수 있습니다. 로딩 상태, 좁은 화면 배치, 두 도구 사이 전환처럼 맥락이 중요한 작은 작업이 더 유익한 시험입니다. 그래도 담당자가 쉽게 되돌리고 검토할 수 있는 범위는 유지해야 합니다.

Loom은 사람들이 이미 다른 사람에게 설명하려고 녹화를 사용한다는 점에서 이 습관을 익숙하게 만들기 좋은 위치에 있습니다. 기회는 그 명료함을 에이전트 작업으로 옮기는 데 있습니다. 풍부한 입력만 있으면 달성할 목표를 설명할 필요가 없다고 생각하는 것이 위험 요소입니다.

다른 사람도 이해할 수 있어야 좋은 지시서다

Record for agent는 화면의 모든 픽셀을 말로 묘사하는 대신 보여주는 데서 시작하는 합리적인 선택을 합니다. 가장 좋은 결과는 에이전트와 동료 모두 이해하기 쉬우며, 최초 관찰과 승인된 변경 사이의 관계가 드러나는 작업일 것입니다.

다음 녹화를 보내기 전에 한 가지를 물어보세요. 녹화하는 모습을 지켜보지 않은 사람도 성공이 무엇인지 설명할 수 있을까요? 그렇다면 유용한 지시서입니다. 그렇지 않다면 코드를 바꾸기 전에 지시부터 다듬을 차례입니다.

출처

• Atlassian: AI 시대에 의도를 보여주는 방법, 2026년 10월 22일.
• Loom: AI 에이전트를 위한 녹화, 이용 조건·캡처·작업 흐름 문서, 2026년 10월 26일 확인.

원본과 검토한 노트를 함께 보관하세요

보관 권한이 있는 녹화라면 Telli.sh에서 원본 자료와 검토한 노트를 한곳에 모아둘 수 있습니다. 오디오 노트로 시작해 보세요.