💻 computer science

To Copilot and Beyond: 22 AI Systems Developers Want Built

이 논문은 860 명의 개발자를 대상으로 한 설문과 심층 분석을 통해, AI 가 코드 작성뿐만 아니라 개발 워크플로우 전반에 걸쳐 개발자의 전문성과 정체성을 해치지 않는 범위 내에서 품질 신호를 강화하고 권한을 명확히 제한하는 22 가지의 새로운 AI 시스템이 필요하다는 점을 밝혀냈습니다.

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

게시일 2026-04-10

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

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

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

이 논문은 **"개발자들이 AI 에게 정말 원하는 것은 무엇인가?"**에 대한 거대한 설문조사 결과를 담고 있습니다.

마치 **"요리사 (개발자) 가 조수 (AI) 에게 무엇을 시키고, 무엇을 직접 하려는지"**를 860 명의 요리사에게 물어본 연구라고 생각하면 쉽습니다.

핵심 내용을 쉽게 풀어서 설명해 드릴게요.

1. 문제: "요리하는 시간보다 설거지 시간이 더 길다?"

대부분의 사람들은 개발자가 하루 종일 코드 (요리법) 를 작성한다고 생각합니다. 그래서 AI 도 "코드 짜는 거 도와줘"에 집중했습니다.
하지만 현실은 다릅니다. 개발자의 하루 중 코딩을 하는 시간은 10% 정도에 불과합니다. 나머지는 다음과 같은 일들입니다:

버그 찾기 (설거지)
문서 정리 (식탁 정리)
팀원 교육 (신규 요리사 교육)
규정 준수 확인 (위생 검사)

현재의 AI 는 '요리'만 도와주고, '설거지'와 '정리'는 개발자가 직접 해야 합니다. 그래서 개발자들은 "요리는 빨라졌는데, 뒷정리가 더 바빠져서 지쳤다"고 호소합니다.

2. 발견: 개발자들이 원하는 '22 가지 AI 시스템'

연구팀은 개발자들에게 "AI 에게 무엇을 시키고 싶니?"라고 물었습니다. 그 결과 22 가지 구체적인 AI 시스템이 필요하다는 답변이 나왔습니다.

이들은 크게 5 가지 분야로 나뉩니다:

개발 (코딩): 기술 부채 (오래된 코드 정리) 를 정리해 주는 시스템.
설계 (기획): 아이디어를 구체화하고 계획을 세우는 것을 도와주는 시스템.
품질 관리 (검수): 코드를 작성하는 순간 바로 버그를 찾아주는 시스템.
인프라 (운영): 서버 경고나 시스템 문제를 분석해 주는 시스템.
메타 작업 (협업): 문서 작성, 신입 교육, 고객 응대 등을 도와주는 시스템.

3. 핵심 통찰: "유한한 위임 (Bounded Delegation)"

이 연구의 가장 중요한 결론은 **"개발자들은 AI 에게 '일'은 시키지만, '책임'은 안 맡긴다"**는 것입니다.

비유: 개발자는 AI 를 **"정교한 로봇 조수"**로 생각하지만, **"주인 요리사"**는 자신이 하고 싶어 합니다.
예시:
- AI 가 "이 재료를 다듬어 줘" (코드 작성) 는 시킬 수 있다.
- 하지만 "이 요리의 맛을 최종 결정해 줘" (최종 설계 결정) 는 시키지 않는다.
- AI 가 "이 식중독 원인을 찾아줘" (버그 분석) 는 시킬 수 있다.
- 하지만 "이 식당을 폐업시켜" (시스템 중단 결정) 는 시키지 않는다.

개발자들은 AI 가 지루하고 반복적인 '조립 작업'은 다 해주길 원하지만, 자신의 '직업적 정체성'과 '책임'이 걸린 부분은 절대 AI 에게 넘기지 않으려 합니다.

4. 개발자들이 AI 에게 요구하는 4 가지 규칙 (안전장치)

개발자들은 AI 가 일을 할 때 다음 4 가지 규칙을 반드시 지키길 원합니다. 이를 **'안전장치'**라고 부릅니다.

권한 범위 명확화: "너는 여기까지만 해. 그 너머는 내가 결정해." (예: AI 가 임의로 새로운 파일을 만들지 못하게 막기)
출처 증명: "이걸 왜 이렇게 했어? 근거를 보여줘." (예: AI 가 만든 코드가 어디서 왔는지 출처를 밝히기)
불확실성 신호: "모르겠으면 '모른다'고 해. 확신 없는 추측을 하지 마." (예: AI 가 헛소리를 하지 않게 경고하기)
최소 권한 원칙: "내 비밀 자료 (고객 정보 등) 에는 접근하지 마." (예: 민감한 데이터는 AI 가 건드리지 못하게 차단하기)

5. 결론: AI 의 가치는 '무엇을 하느냐'가 아니라 '어디서 멈추느냐'에 있다

이 논문은 우리에게 중요한 질문을 던집니다.

"AI 가 얼마나 많은 일을 해내는가가 중요한 게 아니라, AI 가 개발자의 영역에서 '어디서 정확하게 멈추는지'가 더 중요하다."

개발자들은 AI 가 일하는 속도를 높이는 것보다, 생각할 시간을 더 많이 갖게 해주는 것을 원합니다. AI 가 모든 것을 다 해주는 '마법사'가 아니라, 개발자가 더 잘할 수 있게 돕는 '신뢰할 수 있는 조수'가 되어야 한다는 뜻입니다.

한 줄 요약:

"AI 에게는 **'설거지'**를 시키되, **'요리사'**의 자리와 **'책임'**은 개발자가 직접 지키고 싶어 합니다."

논문 요약: "To Copilot and Beyond: 22 AI Systems Developers Want Built"

(코파일럿을 넘어: 개발자들이 구축되기를 원하는 22 가지 AI 시스템)

이 논문은 오레곤 주립대학교와 마이크로소프트 리서치가 공동으로 수행한 연구로, 소프트웨어 개발자들이 현재 AI 도구의 한계를 어떻게 인식하고 있으며, 향후 어떤 AI 시스템이 실제로 필요로 하는지를 심층적으로 분석한 결과입니다.

1. 연구 배경 및 문제 정의 (Problem)

코드 작성과 실제 업무의 불일치: 개발자들은 하루 업무 시간의 약 10% 만을 코드 작성에 할애하지만, 대부분의 AI 도구 (예: GitHub Copilot) 는 이 소수 부분인 '코드 생성'에 집중되어 있습니다.
나머지 90% 의 업무: 개발자의 실제 업무는 디버깅, 규정 준수 (Compliance), 온보딩, 문서화 유지, 변경 사항 검토, 비기술적 이해관계자와의 소통 등 코드 작성 외의 영역에 집중되어 있습니다.
AI 의 역설 (Right-Shift Burden): AI 가 코드 생성 속도를 가속화함에 따라, 생성된 코드의 품질 검증, 리뷰, 테스트, 사고 대응 등 인간이 수행해야 하는 '검증 (Verification)' 단계의 부담이 급격히 증가하고 있습니다. 이로 인해 'AI 생성 쓰레기 (Workslop)'가 늘어나고, 개발자의 피로와 번아웃, 기술 부채가 축적되는 문제가 발생하고 있습니다.
연구 질문: 개발자들은 구체적으로 어떤 AI 시스템을 원하며, 그 시스템이 작동하기 위해 어떤 조건 (제약) 을 부과하고 있는가?

2. 연구 방법론 (Methodology)

데이터 수집: 마이크로소프트의 860 명의 개발자를 대상으로 한 대규모 설문을 기반으로 합니다. (2025 년 7 월 실시, IRB 승인)
설문 구조: 개발자가 수행하는 5 가지 주요 작업 카테고리 (개발, 설계 및 계획, 품질 및 리스크 관리, 인프라 및 운영, 메타 작업) 에 대해 "어디서 AI 의 도움을 가장 원하나요?"와 "어디서 AI 가 개입하기를 원치 않나요?"라는 개방형 질문을 포함했습니다.
분석 기법 (Human-in-the-Loop Multi-Model Council):
- 단계 1 (독립적 주제 발견): GPT-5.2, Gemini 3.1 Pro, Claude Opus 4.6 등 3 개의 서로 다른 프런티어 모델을 사용하여 응답 데이터를 독립적으로 분석하고 잠재적 주제를 발견했습니다. (모델 간 편향을 줄이기 위함)
- 단계 2 (코드북 조정): GPT-5.2 를 사용하여 중복 주제를 병합하고, 데이터에 근거하지 않은 주제를 제거하여 통합된 코드북을 생성했습니다.
- 단계 3 (연구자 검토): 두 명의 연구자가 각 주제의 정확성, 근거, 명확성을 검토하고 최종 코드북을 승인했습니다.
- 단계 4 (체계적 코딩): 3 개의 모델이 승인된 코드북을 기준으로 모든 응답을 코딩하며, 코딩 전에 사고 과정 (Chain-of-Thought) 을 기록하도록 하여 투명성을 확보했습니다.
- 단계 5 (신뢰도 평가): Krippendorff's $\alpha$ 를 사용하여 모델 간 상호 평가자 신뢰도 (IRR) 를 측정 (평균 0.94) 하고, 다수결 원칙으로 최종 주제를 확정했습니다.

3. 주요 기여 및 결과 (Key Contributions & Results)

연구는 개발자들이 원하지만 현재 부재한 22 가지 구체적인 AI 시스템을 5 가지 카테고리별로 도출했습니다.

3.1 개발 (Development) - 4 가지 시스템

기술 부채 제거용 범위 제한 PR 빌더: 대규모 리팩토링을 수행하되, 인간의 검토가 가능한 작은 단위 (Atomic diffs) 로 나누고, 도메인 지식이 필요할 경우 중단하는 시스템.
코드 및 테스트 임베디드 품질 게이트: 커밋 전 실시간으로 결함을 탐지하고, 테스트 커버리지를 분석하여 PR 작성 시점에 품질 신호를 제공하는 시스템.
트레이스 - 투 - 디프 (Trace-to-diff) 루트 원인 워크벤치: 생산 사고 발생 시 로그, 스택 트레이스, 변경 이력을 자동으로 수집하여 '증거 파일'을 구성하고, 가설을 검증한 후 패치를 제안하는 시스템.
크로스 파일 변경을 위한 리포지토리 컨텍스트 그래프: 대규모 코드베이스의 구조와 역사적 맥락을 이해하여, 파일 간 변경 시 파급 효과를 정확히 분석하고 잘못된 중복 코드를 방지하는 시스템.

3.2 설계 및 계획 (Design & Planning) - 5 가지 시스템

설계 - 스프린트 워크벤치: 승인된 설계를 구체적인 작업 항목, 의존성 맵, 스프린트 시퀀스로 자동 변환하되, 최종 계획 수립은 인간이 하도록 지원하는 시스템.
요구사항 - 설계 아키텍처 스튜디오: 다양한 아키텍처 대안을 생성하고 트레이드오프를 비교하되, 최종 결정을 내리지 않는 '사고 파트너' 역할.
트레이드오프 및 리스크 분석기: 설계의 숨겨진 의존성과 NFR(비기능적 요구사항) 격차를 분석하고 시나리오를 시뮬레이션하는 시스템.
의사결정 맥락 및 출처 그래프: 과거 설계 결정의 맥락, 근거, 변경 이력을 추적하여 '왜 그렇게 했는지'를 설명할 수 있는 시스템.
풀루프 설계 문서 및 다이어그램 워크벤치: 메모나 초안을 구조화된 문서와 편집 가능한 다이어그램으로 변환하되, 출처를 명시하고 인간이 수정할 수 있도록 지원하는 시스템.

3.3 품질 및 리스크 관리 (Quality & Risk Management) - 5 가지 시스템

변경 인식 테스트 생성 및 품질 게이트: 코드 변경 (Diff) 에 기반하여 영향을 받는 영역을 매핑하고, 누락된 테스트를 생성하여 리포트를 제공하는 시스템.
맥락 인식 PR 리뷰 어시스턴트: 코드베이스의 맥락을 이해하여 PR 의 의도, 위험 영역, 결함을 분석하고 인간 리뷰어가 집중해야 할 부분을 제안하는 시스템.
머지 전 보안 어드바이저 (패치 제안): 보안 취약점을 발견하고, 해당 코드 경로에 맞는 구체적인 패치 제안서를 작성하되, 인간이 검증하도록 하는 시스템.
준수 증거 컴파일러 및 인터프리터: 규정 (Compliance) 문서를 해석하고, 필요한 증거를 수집하여 감사용 형식으로 변환하는 시스템.
사전 예방적 회귀 경고용 리스크 레이더: 배포 이력과 텔레메트리를 분석하여 잠재적 리스크를 조기에 경고하는 시스템.

3.4 인프라 및 운영 (Infrastructure & Operations) - 4 가지 시스템

알림 조정 및 사고 트라이얼을 위한 텔레메트리 상관관계 어시스턴트: 사고 발생 시 관련 로그와 변경 사항을 자동으로 연결하여 '증거 뭉치'를 구성하고, 알림의 정확도를 개선하는 시스템.
CI/CD 및 인프라-as-코드 청사진 빌더: 조직의 정책과 컨텍스트를 반영하여 파이프라인 설정을 생성하고 디버깅을 지원하는 시스템.
유지보수 백로그 우선순위 결정기: 다양한 경고 신호를 통합하여 무엇을 먼저 수정해야 하는지 우선순위를 제시하는 시스템.
고객 지원 트라이얼 어시스턴트: 고객 문의를 분류하고 관련 지식을 검색하여 인간이 검토할 초안 응답을 작성하는 시스템.

3.5 메타 작업 (Documentation, Knowledge, Collaboration) - 4 가지 시스템

DocSync (지속적 문서 동기화): 코드 변경에 따라 문서가 자동으로 업데이트되도록 하되, 사실 확인은 인간이 하도록 하는 시스템.
맥락화된 개발자 온보딩 코치: 신입 개발자의 목표와 수준에 맞춰 학습 경로, 코드베이스 맵, 실습 과제를 생성하는 시스템.
이해관계자 커뮤니케이션 초안 작성 워크벤치: 기술적 내용을 다양한 대상 (고객, 경영진 등) 에 맞게 어조와 깊이를 조절하여 초안을 작성하는 시스템.
기술 발견을 위한 인터랙티브 탐색 보드: 초기 아이디어 단계에서 다양한 대안을 탐색하고 평가 기준을 설정하여 의사결정을 돕는 시스템.

4. 핵심 발견 및 시사점 (Significance)

4.1 '제한된 위임 (Bounded Delegation)' 패턴

개발자들은 AI 가 작업의 조립 (Assembly) 부분을 처리하는 것은 원하지만, 직업적 정체성 (Craft) 과 판단 (Judgment) 이 필요한 부분은 인간이 직접 수행하기를 원합니다.

조작 (Assembly): 반복적 작업, 증거 수집, 초안 작성, 데이터 정리 등.
직업 (Craft): 최종 결정, 책임 소재, 설계의 핵심 판단, 인간적 소통 등.
이러한 경계는 AI 의 성능이 향상되더라도 쉽게 이동하지 않을 것으로 예상되며, 개발자의 전문성과 책임감을 보호하기 위한 의도적인 설계 요구사항입니다.

4.2 검증의 우회 (Right-Shift Problem) 해결

AI 가 생성하는 코드의 양이 증가함에 따라, 검증 (리뷰, 테스트, 보안) 의 부담이 뒤로 밀려나고 있습니다. 개발자들은 이 문제를 해결하기 위해 품질 신호를 작업의 초기 단계 (Authorship time) 에 삽입하는 시스템을 원합니다. 즉, 생성과 검증을 동시에 수행하거나, 검증이 생성보다 앞서도록 설계해야 합니다.

4.4 공통된 4 가지 가드레일 (Guardrails)

개발자가 수용하는 모든 AI 시스템은 다음 4 가지 제약 조건을 따릅니다:

명시적 권한 범위 (Explicit Authority Scoping): AI 는 선언된 범위 내에서만 작동하고, 판단이 필요하면 중단해야 함.
출처 추적 (Provenance): 모든 출력물은 원본 데이터나 근거에 연결되어야 함.
불확실성 신호 (Uncertainty Signaling): 증거가 부족하거나 확신이 없을 때 이를 명시적으로 표시해야 함 (과도한 자신감 금지).
최소 권한 접근 (Least-Privilege Access): 민감한 데이터 접근을 제한하고, 생산 환경에 대한 쓰기 권한은 인간이 통제해야 함.

5. 결론

이 논문은 AI 도구 개발이 단순히 '코드 생성'을 넘어, 개발자의 전체 업무 흐름 (Workflow) 을 이해하고 검증 부담을 줄이는 방향으로 나아가야 함을 강조합니다. 개발자가 원하는 AI 는 모든 것을 대신하는 것이 아니라, 인간이 더 가치 있는 작업 (직업적 판단과 책임) 에 집중할 수 있도록 주변의 조립 작업을 흡수하는 도구입니다. 따라서 AI 시스템의 가치는 "얼마나 많은 일을 할 수 있는가"가 아니라, **"어디에서, 그리고 얼마나 정확하게 멈추는가"**에 달려 있습니다.