Radian의 AI 코딩 자동화, 작업 승인과 실행 권한은 같은 뜻일까요?

핵심 요약 (TL;DR)

계획을 승인했다고 컴퓨터의 모든 파일에 접근하도록 허락한 것은 아닙니다. 한국 시간 10월 26일 공개된 Radian 소개는 코딩 에이전트와 작업 조율기 arc를 하나로 묶었다고 설명합니다.[1][2] 눈여겨볼 부분은 자동화라는 이름보다 권한의 층위입니다. 계획 승인, 파일 접근, 변경 병합은 각각 다른 질문이며, README는 기본 실행 권한이 넓다는 점도 숨기지 않습니다.[2]

제작자는 무엇을 한데 묶었나요?

제작자는 계획을 논의하고 여러 에이전트에게 작업을 나눈 뒤 검토·시험·통합으로 이어 가는 과정에 연결 작업이 많았다고 말합니다. Radian과 arc를 만들면서 자신은 제품 방향과 검수에 집중했다고도 밝혔습니다.[1] 이는 제작자의 자기보고이며 생산성이 얼마나 향상됐는지 독립적으로 측정한 결과는 아닙니다.

공개 문서는 Radian을 코드 작업을 수행하는 에이전트, arc를 계획과 개별 작업을 관리하는 프로그램으로 구분합니다. 작업마다 별도 브랜치와 작업 디렉터리, 세션 기록을 두는 구조입니다.[2] 이번 글에서는 문서를 대조했으며 설치하거나 자동 병합을 실행하지 않았습니다.

기본값이면 안전한 범위인가요?

README에 따르면 기본 권한 단계는 full입니다. 샌드박스 없이 내장 도구를 실행하며 별도 확인창도 띄우지 않습니다. 반면 workspace 프로필은 운영체제의 격리 기능을 켜고 쓰기를 작업 공간에 제한한다고 설명합니다.[2] 기본값과 제한된 선택지가 같지 않다는 점이 중요합니다.

문서도 낯선 저장소의 프롬프트 주입을 full 모드가 방어하지 않는다고 명시합니다.[2] 따라서 첫 실습부터 업무 원본과 여러 계정이 연결된 환경을 맡기기보다, 가짜 자료만 든 분리된 프로젝트에서 시작하시길 권합니다. ‘계획을 읽었다’와 ‘실행 범위를 제한했다’를 따로 기록해 보세요.

AI가 계획을 쓰면 바로 실행되나요?

arc의 설명은 계획을 작성하는 주도 세션이 직접 확정·시작·병합하지 못한다고 구분합니다. 사용자가 계획을 확인한 뒤 자동화 수준에 따라 작업 시작과 병합이 달라집니다. 병합 전에는 설정한 검사와 승인 절차를 거치며, 검사 뒤 브랜치가 바뀌면 승인을 무효화하고 다시 검증한다고 안내합니다.[2]

이 구조를 읽으며 자신의 MVP에도 작은 경계를 만들 수 있습니다. 예를 들어 문의 화면의 문구 수정과 자료 저장 방식을 바꾸는 일을 별도 작업으로 나누는 것입니다. 둘을 한 요청에 담으면 무엇이 시험됐고 무엇이 아직 남았는지 설명하기 어려울 수 있습니다.

첫 작업의 완료 조건은 어떻게 적을까요?

“문의 화면의 빈 입력 안내만 수정해 주세요. 저장 방식과 외부 전송은 바꾸지 마세요. 빈 입력·정상 입력의 결과를 각각 확인하고, 바뀐 파일과 실행하지 못한 검사를 알려 주세요.” 이는 원작의 명령어가 아닌 활용 예시입니다.

결과를 받은 뒤에는 테스트 통과 문장만 읽지 말고 해당 변경으로 화면을 다시 열어 보세요. 다른 수정이 들어갔다면 이전 검토가 어디까지 적용되는지 다시 확인합니다. 자동화의 속도보다 사람이 승인한 대상이 계속 같은지를 지키는 실습입니다.

FAQ: arc를 쓰면 모든 검사가 자동으로 정해지나요?

문서는 검사 명령을 프로젝트 설정에 넣도록 안내합니다.[2] 검사 장치가 있다는 사실만으로 여러분의 앱에 필요한 조건까지 갖춰지는 것은 아닙니다. 실제 입력과 기대 결과를 먼저 적어 두세요.

FAQ: 첫 앱부터 여러 에이전트가 필요한가요?

그럴 필요는 없습니다. 작은 작업을 혼자 확인하는 기준부터 정해 보세요. 이 사례의 가치는 복잡한 구성을 그대로 가져오는 데 있지 않습니다. 계획·권한·검수·공개를 서로 다른 결정으로 남기는 데 있습니다.

출처
[1] https://news.ycombinator.com/item?id=50233447
[2] https://github.com/hisea/radian
관찰: 2026-10-26 KST