제품 안에서 움직이는 AI는 답변을 내놓는 데서 끝나지 않고 실제 업무 상태를 바꾼다. 사용자가 기대하는 편의와 조직이 감당할 수 있는 위험 사이의 경계는 모델의 지능만으로 정해지지 않는다.
프롬프트는 방향, 통제는 실행 단계
Linear Agent의 시스템 프롬프트는 짧다. 말투와 제품 용어, 거절할 주제, 기능별 기본값 정도만 담았다. 행동의 방향은 프롬프트로 정하되 실제 권한은 툴의 매개변수와 호출 구조로 통제한다. 금지할 행동은 말로 경고하는 데 그치지 않고 실행할 수 없게 만든다.
실제로 2025년 Replit Agent는 코드 프리즈(코드 변경 금지 기간)를 어기고 프로덕션(실서비스 환경) 데이터베이스를 삭제한 뒤 허위 보고까지 만들었다. 정지 명령만으로는 쓰기 권한을 막을 수 없다는 사례다.
그런데 이슈, 고객 피드백, PR 설명은 업무 자료인 동시에 외부 입력이다. 모델은 명령과 자료를 같은 토큰 흐름에서 처리하므로 둘을 완전히 구분하기 어렵다. 프롬프트 인젝션은 자료 속에 심어진 문구를 모델이 명령으로 받아들여 원래 지시와 다르게 행동하게 만드는 공격이다. OWASP도 프롬프트 인젝션을 여러 에이전트 보안 위험과 연결한다. 그렇다면 마지막 안전선은 어디인가. 프롬프트가 아니라 실행 단계에 있다.
범용 도구보다 좁고 정확한 툴
코딩 에이전트는 읽기, 쓰기, 실행 같은 범용 도구를 조합한다. Linear Agent는 대신 이슈 생성, 문서 수정, 댓글 게시처럼 용도가 좁은 툴을 쓴다. 자유도는 줄지만 에이전트가 제품에서 허용한 행동만 선택하게 할 수 있다.
그런데 툴이 많아지면 선택이 쉬워질까. 370개 툴을 대상으로 한 연구에서는 작업마다 평균 7개만 골라 보여줘도 정답 툴을 포함하는 비율이 90.8%로 50개를 고정 노출했을 때의 90.3%와 비슷했고 선택 정확도는 5개를 고정 노출했을 때보다 더 높았다. 필요한 순간에 알맞은 툴만 보여주는 방식이 툴 수 자체보다 선택 정확도에 영향을 준다.
실제로 Linear는 관련 툴과 사용 원칙을 ‘스킬’로 묶어 필요할 때 불러온다. 외부 MCP 서버도 이슈와 프로젝트, 코멘트를 다루는 인터페이스를 제공한다. 다만 사용자가 지켜보는 외부 클라이언트와 혼자 비동기(사용자의 응답을 기다리지 않고 작업하는 방식)로 움직이는 자체 에이전트에는 같은 권한을 줄 수 없다. 툴은 단순한 API 포장이 아니라 제품이 허용할 행동의 범위를 정하는 장치다.
왜 Linear는 API를 감췄나
Anthropic은 수많은 MCP 툴을 코드 API로 제공하고 에이전트가 필요한 기능을 찾아 스크립트로 조합하는 방식을 제안했다. 모든 툴 정의를 처음부터 넣을 필요가 없어 Google Drive와 Salesforce를 연결한 사례에서는 토큰 사용량이 15만에서 2천으로 줄었다.
반면 Linear는 자체 제품 에이전트에 SDK, CLI, GraphQL API를 직접 주지 않았다. 샌드박스(외부와 격리된 실행 환경)의 잘못된 코드는 실패로 끝나는 경우가 많지만 프로덕션의 잘못된 요청은 정상 처리돼 실제 팀 데이터를 바꿀 수 있기 때문이다.
그렇다고 모든 작업에 같은 제한을 걸 필요는 없다. 코드 작업에는 더 넓은 자유를 줘도 된다. 코드를 조사하고 수정해 PR을 여는 과정에는 diff(코드 변경 내역), 리뷰, 머지(코드를 합치는 작업) 승인이 있다. 반면 이슈 상태나 문서 수정은 저장 즉시 동료에게 노출된다. 같은 에이전트라도 검토 장치와 실패 비용에 따라 권한이 다르다.
되돌리기 어렵다면 승인을 넣어라
‘삭제’나 ‘게시’ 같은 동작 이름만으로는 승인 여부를 정할 수 없다.
- Linear Agent는 이번 대화에서 자신이 만든 항목은 바로 지울 수 있지만 기존 이슈를 삭제할 때는 승인을 받는다.
- 내부 스레드에는 곧바로 댓글을 달 수 있어도 공개 저장소에 함께 올라가는 글은 먼저 묻는다.
되돌리기 어렵고 결과를 보는 사람이 많을수록 사람의 판단을 더한다. Meta의 Agents Rule of Two 역시 사적 데이터, 신뢰할 수 없는 콘텐츠, 외부 통신이 모두 겹치면 사람의 개입을 요구한다.
결국 안전장치는 여러 층으로 나뉜다. 프롬프트가 흔들리면 툴이 막고 툴 조합이 예상 밖으로 벗어나면 권한과 승인 절차가 다시 막는 구조다. 그래야 한 번의 오판이 곧바로 프로덕션 변경으로 이어지지 않는다.
그래서 B2B 제품에서는 삭제, 상태 변경, 외부 동기화처럼 다른 사람에게 영향을 주는 행동을 코드로 제한해야 한다. 반면 작업 순서나 문장 표현처럼 대화 안에서 고칠 수 있는 판단은 모델에 맡길 수 있다. 좋은 제품 에이전트는 무엇을 많이 하느냐만큼, 무엇을 끝내 하지 못하게 설계했느냐로 결정된다.
특히 에이전트의 성능이 높아질수록 사용자는 더 많은 일을 맡기면서도 개입할 시점을 놓치기 쉽다. 사용자가 제품을 신뢰하는 기준은 무엇인가. 에이전트가 성공한 순간보다 잘못 판단했을 때 얼마나 빨리 알아차리고 개입할 수 있는지다.