💻 computer science

You Shall Not Pass! Where and Why Developers Draw The Line on AI Autonomy

448명의 마이크로소프트 개발자를 대상으로 한 혼합 연구 방법론을 통해, 본 논문은 소프트웨어 엔지니어링에서 AI 자율성에 대한 수용도가 작업 특성과 개인적 특성에 따라 유의미하게 달라지며, 개발자들이 정체성을 정의하고 인간 중심적이며 설계 지향적인 업무에는 가장 강한 저항을 보이는 반면 요구 사항이 높거나 책임성이 낮은 작업은 위임하는 데 더 기꺼이 동의한다는 것을 밝히고 있다.

원저자: Rudrajit Choudhuri, Christian Bird, Carmen Badea, Marco Gerosa, Anita Sarma

게시일 2026-07-02

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Rudrajit Choudhuri, Christian Bird, Carmen Badea, Marco Gerosa, Anita Sarma

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

소프트웨어 개발을 거대하고 북적이는 건설 현장이라고 상상해 보십시오. 수년간 노동자들(개발자들)은 기초부터 지붕까지 모든 것을 구축해 왔습니다. 이제, 새로운 종류의 조력자가 도착했습니다. 바로 벽돌을 쌓고, 시멘트를 섞으며, 심지어 설계도까지 그릴 수 있는 초고속의 매우 똑똑한 로봇(AI)입니다.

중요한 질문은 이제 로봇이 일을 할 수 있느냐가 아니라, **로봇이 스스로 얼마나 많은 일을 해야 하는가?**입니다.

"You Shall Not Pass!"(통과할 수 없다!)라는 제목의 이 논문은 거대 기술 기업(마이크로소프트)의 448명의 건설 노동자를 대상으로 한 조사와 같습니다. 그들은 정확히 어디에서 선을 긋는지 알아내고자 했습니다. 그들은 알고 싶었습니다. 우리는 언제 로봇이 혼자 일하게 내버려 두고, 언제 현장의 열쇠를 직접 쥐고 있을 것인가?

통제의 세 가지 관문

연구진은 개발자들이 단순히 AI에 대해 "예" 또는 "아니오"라고 답하는 것이 아님을 발견했습니다. 대신, 그들은 AI가 더 많은 자유를 얻기 위해 통과해야 하는 세 가지 관문(또는 자물쇠)을 상상합니다. 공항의 보안 검문소와 비슷하지만, 코드를 위한 검문소라고 생각하면 됩니다.

관문 1: "제안"의 관문

규칙: 로봇은 아이디어를 속삭일 수 있지만, 실제 작업은 인간이 수행해야 합니다.
느낌: "네 아이디어는 들어보겠지만, 망치를 쥐고 있는 건 나야."
언제 열리는가? 거의 항상입니다. 개발자들은 브레인스토밍이나 작은 버그를 수정하기 위해 AI의 제안을 받는 것을 좋아합니다.

관문 2: "실행"의 관문 (첫 번째 큰 경계선)

규칙: 로봇은 실제로 그것을 만들 수 있지만(코드를 작성), 인간은 그것이 사용되기 전에 반드시 검사하고 승인을 내려야 합니다.
느낌: "네가 벽을 쌓을 수는 있지만, 우리가 페인트를 칠하기 전에 내가 확인해야 해."
"금지 구역": 만약 인간이 결과에 대해 **개인적인 책임(Accountability)**을 느낀다면, 보통 여기서 로봇을 멈춰 세웁니다. 그들은 자신이 검사하지 않은 벽에 자신의 이름을 남기고 싶어 하지 않습니다.

관문 3: "결정"의 관문 (최종 경계선)

규칙: 로봇은 만드는 것뿐만 아니라 무엇을, 언제 만들지도 결정할 수 있으며, 인간은 상황이 끔찍하게 잘못되었을 때만 개입합니다.
느낌: "이제 네가 현장 소장이야. 난 그냥 발코니에서 지켜볼게."
"금지 구역": 이곳은 대부분의 사람들이 특히 다음과 같은 경우에 "통과할 수 없다!"라고 말하는 곳입니다:
- 정체성(Identity): 자신을 진정한 전문가로 느끼게 하는 작업들(복잡한 시스템 아키텍처 설계와 같은). 그들은 자신의 직업적 "기술(craft)"을 잃고 싶어 하지 않습니다.
- 인간적 연결(Human Connection): 멘토링, 고객과의 대화, 또는 가르치기. 로봇은 "인간적인 일"을 잘 수행할 수 없습니다.
- 높은 이해관계(High Stakes): 실수가 프로젝트 전체를 망칠 수 있는 경우, 인간은 최종 결정권을 유지하고 싶어 합니다.

왜 그들은 그곳에 선을 긋는가?

논문은 이 선이 모든 사람이나 모든 작업에 대해 동일한 위치에 그려지는 것이 아니라는 점을 발견했습니다. 이는 네 가지 주요 요소에 달려 있습니다:

"나"의 요소 (정체성): 어떤 작업이 개발자가 사랑하고 자신을 정의한다고 느끼는 것(창의적인 설계와 같은)이라면, 그들은 로봇을 엄격하게 통제합니다. 그들은 그것을 스스로 하는 즐거움을 잃고 싶어 하지 않습니다.
"책임"의 요소 (책무성): 만약 개발자가 무언가 고장 났을 때 책임을 져야 한다는 것을 안다면, 그들은 로봇이 자신의 직접적인 승인 없이 행동하는 것을 거부합니다. 그들은 직접 승인하는 사람이 되고 싶어 합니다.
"과도한 업무"의 요소 (수요): 만약 개발자가 지루하고 반복적인 업무(서버 설정이나 기본적인 문서 작성 등)에 허덕이고 있다면, 그들은 AI가 의사결정까지 맡도록 기꺼이 허용합니다. 그들은 지쳐 있고 그저 로봇이 힘든 일을 처리해주길 원합니다.
"로봇 조련사"의 요소 (경험): AI를 많이 사용해 보았고 위험을 감수하는 것을 두려워하지 않는 개발자들은 로봇이 주도권을 잡도록 허용하는 데 더 개방적입니다.

"계단식 잠금 장치" 비유

저자들은 이 과정을 (강의 물길을 따라 있는) **운하의 갑문(canal locks)**에 비유하여 설명합니다.

AI의 자율성은 강을 거슬러 올라가려는 배와 같습니다.
**책무성(Accountability)**은 첫 번째 갑문입니다. 인간이 책임을 느낀다면, 문은 닫힌 상태로 유지되며 배는 통과할 수 없습니다.
**정체성(Identity)**은 두 번째 갑문입니다. 작업이 인간의 정체성에 핵심적이라면, 이 문은 닫힌 상태로 유지됩니다.
**업무량(Workload)**은 수압입니다. 인간이 압도당하고 있다면, 물의 압력이 문을 밀어 열어 배가 더 빨리 위로 올라갈 수 있게 합니다.

경고 신호 (안티 패턴)

논문은 만약 기업들이 기본적으로 AI 도구가 규칙을 결정하도록 내버려 둔다면, 나쁜 일이 발생할 것이라고 경고합니다:

"거수기(Rubber Stamp)" 문제: 만약 인간이 너무 바빠서 로봇의 작업을 확인하는 것을 멈춘다면, 그들은 자신이 이해하지 못하는 일에 서명만 하는 "거수기"가 되어 버립니다.
"공허한 지휘자(Hollow Orchestrator)": 만약 로봇이 모든 어려운 생각을 다 한다면, 인간 개발자는 기술을 잃게 됩니다. 그들은 자신이 실제로 이해하지 못하는 로봇을 관리하는 매니저가 될 뿐입니다. 마치 악기를 연주할 줄 모르는 지휘자와 같습니다.
"끊어진 파이프라인(Severed Pipeline)": 만약 AI가 모든 초급 수준의 업무를 수행한다면, 신입 개발자들은 기초를 배우지 못할 것입니다. 그들은 기초를 연습할 기회가 없기 때문에 전문가로 성장할 수 없습니다.

결론

이 논문은 우리가 단순히 "AI가 할 수 있는 작업"과 "인간이 해야 하는 작업"의 목록을 만들 수 없다고 결론짓습니다. 그 목록은 AI가 똑똑해짐에 따라 매일 변합니다.

대신, 우리는 업무를 의미 있게 유지하는 방식으로 직업을 설계해야 합니다. 우리는 인간이 큰 결정에 책임을 지고, 직업의 "기술(craft)"을 유지하며, 지루한 일은 AI에게 맡겨서 그들이 전문가처럼 느껴지는 일에 집중할 수 있도록 만들어야 합니다. 그렇지 않으면, 우리는 인간이 단지 로봇이 일하는 것을 지켜볼 뿐, 정작 기계가 어떻게 작동하는지는 전혀 이해하지 못하는 미래를 만들게 될 위험이 있습니다.

기술 요약: "당신은 통과할 수 없다! 개발자들이 AI 자율성의 경계를 긋는 지점과 그 이유"

문제 정의

생성형 AI 도구(예: GitHub Copilot, Claude)가 코드를 작성하고, 버그를 수정하며, 테스트를 생성하는 능력을 확장함에 따라, 핵심적인 질문은 소프트웨어 엔지니어링 작업을 수행할 수 있는지의 여부에서 '얼마나 많은' 자율성을 개발자가 양도할 것인가로 옮겨갔다. 통제되지 않은 위임은 문제의 악순환을 초래할 위험이 있다. 즉, 개발자는 기술과 판단력을 쌓을 기회를 잃어, 자신이 더 이상 완전히 이해하지 못하는 작업을 승인하는 '고무도장(rubber-stamp)' 문화를 형성할 수 있다. 또한, 코드 생성이 저렴해짐에 따라 배포 압박이 가속화되어 리뷰, 테스트, 운영에 이르는 전체 파이프라인 전반으로 작업 오프로딩(offloading)이 가속화되며, 이는 책임 소재를 복잡하게 만들고 결함 수정 비용을 증가시킨다.

기존 연구는 AI 도입 동인(신뢰, 워크플로우 호환성)과 자동화에 적합한 태스크에 대해 광범위하게 다루어 왔다. 그러나 개발자들이 설정하는 구체적인 **경계(boundaries)**에 대한 이해에는 공백이 존재한다. 특히, 개발자들이 AI가 자신을 대신해 '행동(act)'하도록 허용하는 지점과, 명시적인 승인 없이 AI가 '결정(decide)'하도록 허용하는 지점이 어디인지에 대해서는 여전히 불분cl명하다. 이러한 경계를 정의하지 못한다면, 개발자에게 의미 있는 업무를 보존할 수 있는 도구와 역할을 설계하는 것은 불가능하다.

방법론

저자들은 다양한 제품, 역할, AI 도구 노출도를 가진 대규모 조직인 마이크로소프트(Microsoft)의 전문 소프트웨어 개발자 448명을 대상으로 혼합 방법론 연구를 수행했다.

연구 설계

설문 도구: 인지 평가 이론(cognitive appraisal theory)과 직무 설계 프레임워크를 기반으로, 설문은 5가지 소프트웨어 개발 생애주기(SDLC) 범주(개발, 설계 및 계획, 품질 및 리스크, 인프라 및 운영, 메타 워크)에 걸친 20가지 소프트웨어 엔지니어링 태스크를 평가하도록 구성되었다.
평가 차원: 참가자들은 네 가지 차원에서 태스크를 평가했다: 가치(목표에 대한 중요성), 정체성(개인적 연결/즐거움), 책임성(결과에 대한 책임), 요구도(인지적 노력).
자율성 도출: 고정된 등급 대신, 참가자들은 AI가 '가장 큰 역할'을 수행하기를 원하는 부분과 AI가 '처리하지 않기를' 원하는 측면에 대해 개방형 응답을 제공했다.
분류: 개방형 응답은 (Endsley와 Kiris를 변형한) 5단계 자율성 척도로 분류되었다:
- L1: 없음 (인간이 결정/행동).
- L2: 의사결정 지원 (AI가 제안; 인간이 결정/행동).
- L3: 합의적 (AI가 행동; 인간이 결정/승인).
- L4: 모니터링 (AI가 결정/행동; 인간에게 선택적 거부권 있음).
- L5: 완전 자동화 (AI가 단독으로 결정/행동).
분석:
- 정량적 분석: 누적 링크 혼합 모델(CLMM)과 일반화 선형 혼합 모델(GLMM)을 사용하여 태스크 평가 및 개발자 특성(경험, 리스크 허용도, 테크노필리아)을 바탕으로 수용된 자율성 수준과 그 전이(Action Boundary: L2→L3; Decision-Making Boundary: L3→L4)를 예측했다.
- 정성적 분석: 개방형 응답에 대한 성찰적 주제 분석(reflexive thematic analysis)을 통해 각 자율성 수준과 연관된 구체적인 업무 측면을 특징지었다.
- 검증: 세 개의 서로 다른 대규모 언어 모델(LLM)과 인간 코더로 구성된 'AI 위원회'가 분류 작업에서 높은 상호 검사자 신뢰도( $\alpha = 0.93$ )를 달달성했다.

주요 기여

자율성 경계의 경험적 매핑: 본 연구는 SDLC 전반에 걸쳐 개발자들이 AI 자율성에 대해 긋는 경계를 세밀하게 매핑하며, AI가 '행동(산출물 생성)'하는 것과 '결정(승인 없이 선택을 내리는 것)'하는 것을 구분한다.
인지 평가 프레임워크: 개발자의 위임 의사가 단순히 도구의 능력이나 신뢰도에 의해서만 결정되는 것이 아니라, 업무를 어떻게 인지적으로 평가하느냐(가치, 정체성, 책임성, 요구도)에 깊이 뿌리박고 있음을 입증한다.
"계단식 잠금(Cascading Locks)" 모델: 저자들은 자율성이 일련의 게이트를 통해 부여된다는 개념적 프레임워크를 제안한다. 첫 번째 게이트인 **행동 경계(Action Boundary)**는 책임성에 의해 제어되며, 두 번째 게이트인 **의사결정 경계(Decision-Making Boundary)**는 정체성과 요구도에 의해 제어된다.
안티 패턴 식별: 도구의 기본 설정이 의미 있는 업무 설계를 압도할 때 발생하는 특정 설계 안티 패턴(예: "지연된 답변 가능성", "처리량 쇄도", "축소되는 울타리")을 식별한다.

주요 결과

수용된 자율성 수준 (RQ1)

중앙값 수용도: 수용된 자율성의 중앙값은 **L3 (합의적)**이다. 대부분의 개발자(74%)는 명시적인 승인/서명이 보장된다면 AI가 작업 산출물을 생성하는 것을 수용한다.
태스크 변동성:
- 시스템 지향적 업무 (개발, 품질, 운영): 개발자들은 테스트 생성 및 보안 스캐닝과 같이 경계가 명확한 실행 및 검증(L3)은 위임할 용의가 있으나, 맥락에 민감한 판단에 대해서는 감독권을 유지한다.
- 설계 및 인간 지향적 업무: 개발자들은 설계, 계획, 멘토링에 대해서는 AI를 **L2 (의사결정 지원)**로 제한한다. 판단력, 공감, 책임성에 대한 우려 때문에 이 영역에서 AI가 행동하거나 결정하도록 하는 것을 꺼린다.
자율성 예측 요인:
- 태스크 정체성: 가장 강력한 부정적 예측 변수이다. 태스크와 자신을 동일시하는(예: 공예로서의 코딩) 개발자는 자율성을 덜 양도하는 경향이 있다.
- AI 경험 및 리스크 허용도: 긍정적 예측 변수이다. AI 경험이 많고 리스크 허용도가 높은 개발자일수록 더 높은 수준의 자율성을 수용한다.
- 태스크 책임성: 전체적인 자율성 수준을 예측하지는 않았으나, 특정 경계에서는 유의미했다(아래 참조).
- 태스크 요구도: 전체적인 수준을 예측하지는 않았으나, 의사결정 경계에 영향을 미쳤다.

경계 넘기 (RQ2)

행동 경계 (L2 → L3): "AI가 제안"에서 "AI가 행동"으로 넘어가는 것은 태스크 책임성과 부(-)의 상관관계가 있다. 결과에 대해 높은 책임을 느끼는 개발자일수록 AI가 산출물을 생성하도록 하는 것에 소극적이며, 설령 AI의 제안을 수용하더라도 직접 생성하는 것을 선호한다.
의사결정 경계 (L3 → L4): "인간이 결정"에서 "AI가 결정(거부권 포함)"으로 넘어가는 것은 다음과 같다:
- 태스크 정체성과 부(-)의 상관관계 (개발자들은 자신의 전문적 정체성과 직결된 태스크의 의사결정권을 보호한다).
- 태스크 요구도와 정(+)의 상관관계 (높은 업무량은 의사결정을 오프로딩하려는 의지를 높인다).
- AI 경험 및 리스크 허용도와 정(+)의 상관관계.

의의 및 주장

본 논문은 개발자가 긋는 AI 자율성의 "선"이 고정된 것이 아니라 업무에 대한 인지적 경험을 반영한다고 주장한다. 저자들의 주장은 다음과 같다:

의미 있는 업무 설계가 필수적이다: 개발자의 참여와 역량을 보존하기 위해, 조직은 책임성과 정체성의 "계단식 잠금"을 존중하는 역할과 워크플ло우를 설계해야 한다.
도구의 기본 설정은 위험하다: 조직이 도구의 기본 설정을 통해 경계를 결정하게 방치하면, 다음과 같은 안티 패턴을 초래할 위험이 있다:
- 지연된 답변 가능성 (Deferred Answerability): 책임이 사전 커밋 감독이 아닌 사후 실패 리뷰로 전가된다.
- 축소되는 울타리 (The Shrinking Fence): 전문적 정체성이 AI가 아직 할 수 없는 일(AI 역량이 성장함에 따라 계속 이동하며 좁아지는 목표)로만 정의된다.
- 공허한 오케스트레이터 (Hollow Orchestrator): 개발자는 직함은 유지하지만, 자신이 승인하는 작업을 이해하거나 검증할 능력을 상실한다.
전략적 설계의 선택: 논문은 조직에 선택권이 있다고 결론짓는다. 판단력과 정체성에 기반하여 의미 있는 업무를 유지하도록 역할을 의도적으로 설계할 것인가, 아니면 자동화가 개발자의 핵심 역량을 침식하도록 내버려 둘 것인가. 저자들은 인지적 평가를 도구와 역할이 진화함에 따라 경계가 왜, 그리고 어디에서 그려지는지를 지속적으로 평가하기 위한 살아있는 프레임워크로 사용할 것을 권고하며 전자를 옹호한다.