진정으로 논할 가치가 있는 것은 다른 몇 가지 질문들입니다.
무엇에 사용하고 있는지? 어느 정도 깊이 사용하고 있는지? 얼마나 신뢰하는지? 화제의 Agent는 실제로 얼마나 많이 사용되는지?
Stack Overflow의 2026년 개발자 설문조사에서는 흥미로운 실태가 드러납니다. 응답자의 약 83%가 업무에서 최소한 한 종류의 AI 도구를 사용하고 있습니다. 반면, 중요한 업무 판단과 관련된 작업까지 포함하여 많은 작업을 AI를 신뢰한다고 답한 사람은 겨우 6.6%에 불과합니다.
이는 'AI는 쓸모없다'는 증거가 아닙니다. 오히려 AI가 개발 일상에 녹아들고 있음을 보여줍니다. 다만, 많은 사람들이 점차 이해하게 되는 것은 사용할 수 있는 것과 안심하고 맡길 수 있는 것은 별개라는 것입니다.
본 기사에서는 원본 AI 데이터 페이지에 있던 4가지 영역—활용 현황, 신뢰도와 워크플로우, Agent 에코시스템, 직장 도입—을 처음부터 끝까지 읽기 쉬운 한국어로 소개합니다. 한국어 도표 22점도 첨부했습니다. 공식 문서를 그대로 번역하는 것이 아니라, 데이터와 질문의 의미를 유지하면서 자연스러운 한국어로 정리했습니다.
| 숫자 | 무엇을 나타내는가 |
|---|
| 82.8% | 업무에서 최소한 한 종류의 AI 도구를 사용 (약 83%) |
| ... | 코딩 어시스턴트/Agent를 사용하는 사람 중, 매일 사용 |
| 55.0% | 일상적인 AI 이용 시간에 관한 질문에 응답한 사람 중, 매일 최소 2시간 이상 업무에 활용 |
| 62.0% | 업무에서의 AI 활용에 긍정적 |
| 48.0% | 출력을 쉽게 검증할 수 있는 경우에 한해, AI를 신뢰함 |
| ... | |
| 먼저, 집계 대상에 대해 중요한 주의사항이 있습니다. 질문마다 응답자 수가 다릅니다. AI를 사용하는 사람만을 대상으로 한 질문이나 특정 Agent 도구를 사용해 본 사람에게만 물어본 질문도 있습니다. 또한, 복수 답변이 가능한 질문의 경우 비율을 단순히 합산해도 100%가 되지 않습니다. 아래 도표에는 각 질문의 샘플 수를 기재했습니다. | |
이 질문에 응답한 17,464명 중, 65.9%가 AI 코딩 어시스턴트 또는 코딩 Agent를 이용했고, 62.5%가 범용 AI 채팅 도구를 이용하고 있습니다. 다시 말해, AI는 더 이상 브라우저에서 질문하는 채팅창에 머무르지 않고, 에디터, 터미널, 코드 리포지토리, 개발 프로세스 속으로 깊숙이 들어와 있습니다.
다만, 'Agent의 시대'라고 과장하기에는 아직 이릅니다. AI Agent나 자동화 워크플로우를 이용하고 있다고 응답한 사람은 **26.2%**로, 채팅 어시스턴트만큼 보급되지는 않았습니다. 또한, 업무에서 AI를 전혀 사용하지 않는다고 답한 사람도 17.2%가 있었습니다.
여기에는 특히 오해하기 쉬운 부분이 있습니다. 73%는 개발자 전체의 73%가 매일 코딩 어시스턴트를 사용한다는 의미가 아닙니다. 이 종류의 도구를 사용하는 사람들 중 73%가 매일 사용한다는 뜻입니다. 범용 채팅 도구의 일상 이용률은 65.6%, Agent/자동화 워크플로우는 63.1%입니다.
사내 AI 도구의 이용 빈도는 다소 낮은 편으로, 매일 이용하는 사람은 47.7%였습니다. 이는 반드시 자체 개발 도구의 품질이 낮다는 의미는 아닙니다. 이용 범위나 접근 방법, 태스크의 빈도가 범용 도구와 다를 가능성도 있습니다. 적어도 기능 목록의 길이가 아니라, 업무 흐름에 자연스럽게 통합될 수 있는지가 중요하다는 것을 알 수 있습니다.
일상적인 AI 이용 시간에 관한 질문에 응답한 10,926명 중, 30.9%가 매일 4시간 이상, AI를 업무에 활용하고, 24.1%가 매일 2~4시간 이용합니다. 합치면 정확히 **55%**입니다.
이는 '하루 근무 시간 중 얼마나 많은 시간을 AI의 도움을 받고 있는가'를 물어본 것이며, AI와 연속적으로 대화하는 시간이거나, AI가 업무의 55%를 단독으로 처리했다는 의미도 아닙니다. 그럼에도 불구하고, 일부 개발자에게 있어 AI가 가끔 시도해보는 플러그인에서 상시 사용하는 도구로 변하고 있다는 것은 충분히 유추할 수 있습니다.
매우 긍정적인 응답자가 31.6%, 다소 긍정적인 응답자가 30.4%로, 합치면 62%가 긍정적이었습니다. 다소 부정적인 응답자와 매우 부정적인 응답자를 합쳐 21.5%, 중립은 15.3%였습니다.
따라서 '개발자들은 모두 AI를 싫어한다'도, '개발자들은 이미 100% AI를 수용했다'도 둘 다 실태를 반영하고 있지 않습니다. 보다 현실에 가까운 것은, 대부분은 사용에 적극적이지만, 지켜보거나 신중하게 평가하는 사람들이 있거나, 명확히 좋아하지 않는 사람들도 상당히 많다는 시각입니다.
개발자와 AI의 관계를 이해하기 위해 그림을 한 장만 고른다면, 저는 이것을 선택하겠습니다.
응답자의 **48%**는 결과를 쉽게 검증할 수 있는 경우에만 AI를 신뢰한다고 답했습니다. 16.3%는 많은 작업에서 AI를 신뢰할 수 있지만, 중요한 업무 판단에 영향을 주어서는 안 된다고 생각합니다. 또한 16.3%는 낮은 위험도의 작업에만 맡기고 싶다고 답변했습니다. 중요한 판단이 관련된 작업을 포함하여, 많은 작업에서 AI를 진정으로 신뢰한다고 답한 사람은 겨우 6.6%입니다.
이는 '검증 가능한 신뢰(Verifiable Trust)'라고 부를 수 있습니다. AI는 초안, 코드, 아이디어를 제시할 수 있지만, 최종적인 책임과 판단은 인간에게 남아있습니다.
이 히트맵은 정보량이 많지만, 천천히 볼 가치가 있습니다. 현재 AI가 가장 많이 사용되는 분야는 **익숙한 분야의 코드 생성(69.3%)**와 디버깅/문제 해결/리팩토링(63.8%), 간단한 기술적 질문에 대한 답변(59.4%), 그리고 테스트 작성 및 개선(58.1%)입니다.
반면, 프로덕션 환경(Production Environment)으로의 배포, 운영, 장애 대응 등에 AI를 사용하고 있는 사람은 **19.9%**에 그칩니다. 현재 AI를 사용하지 않고 앞으로도 사용할 계획이 없는 사람은 **36%**입니다. 이메일이나 일상적인 커뮤니케이션 문서 작성 역시 많이 활용되지 않았습니다. **45.9%**는 현재 사용하지 않으며, 앞으로도 사용할 계획이 없다고 답했습니다.
이는 평소의 감각과도 잘 일치합니다. AI에게 검증 가능한 코드를 작성하게 하는 것은 심리적 부담이 적은 반면, AI가 프로덕션 환경에 직접 접근하도록 하는 것은 이야기가 다릅니다.
그림 해석: '현재 사용 중', '앞으로 더 사용하고 싶은', '앞으로 사용량을 줄이고 싶은' 등은 각각 개별적으로 집계된 답변이며, 중복될 수 있습니다. 같은 행을 합계가 100%가 되는 누적 형식으로 해석하지 마십시오.
이는 리포트 전체에서도 특히 안심할 만한 수치입니다. **76.5%**는 출력을 로컬 환경(Local Environment)에서 실행하고, **63.9%**는 기존 코드베이스와 대조하며, **53%**는 테스트나 보안에 미치는 영향을 확인했습니다. 또한 38%는 공식 문서를 참조합니다.
반면, **'그대로 사용'하는 사람은 겨우 9.6%**입니다. 즉, AI로 인해 개발자의 코딩 방식이 변화하더라도, 실행(Execution), 테스트(Test), 리뷰(Review)와 같은 엔지니어링상의 규율이 자동으로 사라진 것은 아닙니다.
AI가 복잡한 작업을 매우 잘 처리할 수 있다고 생각하는 사람은 겨우 **16%**입니다. 가장 많았던 응답은 38.8%로, '그럭저럭이지만 특별히 뛰어나지는 않다'는 평가였습니다. 또한 24%는 성능이 낮거나 매우 낮다고 답했습니다.
일반 개발자에게 현실적인 방법은 복잡한 요구사항 전체를 AI에 넘겨 결과를 기다리는 것이 아니라, 검증 가능한 작은 단위로 작업을 분할하고, AI의 제안을 조금씩 확인해 나가는 방식일 수 있습니다.
매주 AI 제품을 2개 사용하는 사람은 34.4%이고, 3~5개를 사용하는 사람은 40.5%입니다. 합치면, 약 4분의 3에 달하는 사람이 매주 2~5종류의 AI 도구를 사용하고 있다는 의미입니다. 다만, 주당 6가지 이상을 사용하는 사람은 4.8%에 그쳤습니다.
'모델의 수(Model Count)'와 '도구의 수(Tool Count)'를 혼동하지 않도록 주의해야 합니다. 이 설문 항목이 집계하는 것은 AI 기능을 의식적으로 활용하는 제품이나 도구의 수이며, 하나의 제품 내에서 전환하여 사용하는 모델의 수는 아닙니다.
최근 매일 새로운 Agent 프레임워크가 등장하는 것을 느끼고 있다면, 이 장은 공감할 것입니다. 여기에 나오는 데이터에 대해서는 특히 주의가 필요합니다. 각 그림이 나타내는 것은 해당 개별 설문에 답변한 사람들의 데이터이며, 개발자 전체의 시장 점유율(Market Share)이 아닙니다.
이 설문에 응답한 1,392명 중, Mem0이 20%로 선두였습니다. 그 뒤를 LangMem(15.2%), Memary(12.6%), Graphiti와 Supermemory(각각 11.6%)가 따랐습니다.
선두임에도 불구하고 2할에 불과하다는 점에서, Agent용 메모리 기반은 여전히 분산되어 있음을 알 수 있습니다. 앞으로 어떤 제품이 사실상의 표준이 될지 빠른 단계에서 결론을 내리기는 어려울 것입니다.
**LangChain(30.2%)**이 1위였고, 그 뒤를 **OpenAI Agents SDK(23.8%)**가 이었습니다. 흥미롭게도, **터미널을 직접 사용하는 방법(18.9%)**은 LangGraph(18.8%)와 거의 동률이었습니다.
이 결과는 모든 에이전트(Agent)에 다층적인 추상화가 갖춰진 대규모 프레임워크가 반드시 필요한 것은 아님을 시사합니다. 많은 작업의 경우, 단순하고 투명하며 디버깅하기 쉬운 터미널 워크플로우도 매력적입니다.
이러한 종류의 도구에서는 **Sentry(26%)**가 1위를 차지했으며, LangSmith가 17.3%, MLflow와 Langfuse가 각각 15.2%를 기록했습니다.
에이전트를 도입하는 것은 단순히 '작동하게 만드는' 것 이상입니다. 팀 차원에서 본격적으로 사용하려면 일련의 엔지니어링적 질문에 답해야 합니다. 오류는 어디서 발생했는지, 왜 그러한 답변을 했는지, 프롬프트를 변경한 후 품질이 올라갔는지 내려갔는지, 장애가 발생했을 때 어떻게 추적할 것인지 등입니다. 관측 가능성(Observability)과 평가의 중요성은 점점 높아지고 있습니다.
이 도구 분야 설문에 응답한 12,255명 중 지난 1년 동안 **Claude Code를 사용해 본 사람은 65.5%, GitHub Copilot은 58.7%**였습니다. 그 다음으로는 OpenAI Codex(29.5%), Cursor(25.5%)가 이어졌습니다.
여기서 제시하는 수치는 '지난 1년 동안 사용해 본 경험'의 비율입니다. 이는 유료 구독자 비율이 아니며, 매일 활성 사용자 수나 도구의 품질 평가를 나타내는 것도 아닙니다. 여러 도구를 사용한 사람도 있기 때문에, 이 비율들을 상호 중복되지 않는 시장 점유율로 해석할 수는 없습니다.
**Lovable(38.3%)**이 1위를 차지했으며, Replit(28.3%)과 v0(27.5%)가 뒤를 이었고, Bolt.new는 17.2%였습니다.
이러한 도구들은 아이디어를 프로토타입으로 만드는 진입 장벽을 낮춘다는 가치가 있습니다. 하지만 프로토타입을 만든 후에도 데이터 권한, 유지보수, 배포(Deploy), 보안에는 충분한 주의가 필요합니다. 이 수치들이 보여주는 것은 이용 현황일 뿐이며, '개발 지식이 없어도 안심하고 운영 시스템을 공개할 수 있다'는 의미는 아닙니다.
이 설문에서는 Make(38.9%), n8n(32.7%), **Zapier(18.5%)**가 상위 3개였습니다. 그 이후의 도구들은 분포가 더 분산되어 있습니다.
이 수치로부터 에이전트 세계에서는 '모델을 실제 업무 액션에 연결하는 것'에 대한 큰 수요가 있음을 알 수 있습니다. 클라우드 서비스, 로우코드(Low-code) 인터페이스, 또는 개발자용 오케스트레이션 방식 중 무엇을 선택할지는 팀이 배포 및 유지보수 비용을 고려하여 판단하고 있습니다.
'유용하다'와 '매우 유용하다'를 합산했을 때, 코드 구현은 74.6%, 디버깅/리팩토링(Refactoring)은 72.6%, 문서 작성은 65.7%, 코드 리뷰는 64.5%였습니다.
반면 커뮤니케이션에 대해서는 '유용하다' 또는 '매우 유용하다'고 답한 비율이 35%에 그쳤으며, 22.6%는 그다지 실용적이지 않다고 느꼈습니다. AI는 코드처럼 구조화된 기술적 내용의 작성, 설명, 수정에서는 높은 평가를 받는 반면, 인간관계나 맥락과 관련된 커뮤니케이션 영역에서는 평가가 늘어나지 않고 있습니다.
AI 덕분에 **66.1%**의 응답자는 디버깅/리팩토링 작업에 대한 만족도가 높아졌다고 답했고, **60.6%**는 문서 작성 작업에서, **60.1%**는 코드 구현 작업에서 만족도가 높아졌다고 답했습니다.
다만 주목할 만한 대조점도 있습니다. 코드 구현에서는 **19.9%**가 만족도의 저하를 느꼈습니다. AI 덕분에 작업이 쉬워지는 사람도 있는 반면, 생성된 결과물을 검토하고 수정하며 이해하는 데 더 많은 시간을 할애하는 사람일 수도 있습니다. '빨라진다'는 것과 '쾌적해진다'는 것은 반드시 같지 않습니다.
도구를 교체한 경험이 없는 사람은 단 33.7%에 불과하며, 약 2/3는 적어도 한 번은 교체했습니다. 가장 흔했던 주된 이유는 **출력 품질이 더 높기 때문(25.1%)**이었고, 그 다음으로 회사 지정/권장(10.6%), 개발 환경과의 통합성이 더 좋음(7.4%), 비용이 낮음(6.4%) 순이었습니다.
주의할 점은 25.1%는 이 설문에 응답한 전체 인원을 대상으로 한 비율이며, 도구를 교체한 사람만을 대상으로 계산된 비율이 아니라는 점입니다. 제품을 선택할 때 개발자가 가장 중요하게 생각하는 것은 결과물의 품질이며, 그 다음으로 가격이나 기타 요소가 이어지는 것으로 보입니다.
AI가 코드의 선호도, 프로젝트 배경, 업무 습관을 기억한다면, 누가 그 정보를 열람하고, 편집하고, 삭제할 수 있을까요?
**53.6%**는 '자신 스스로'라고 답했습니다. 회사 차원에서 일원 관리되기를 원하는 응답자는 14.7%, 팀 단위로 관리되기를 원하는 응답자는 11.1%였습니다. 또한, 14.2%는 애초에 AI가 장기적인 기억을 가지는 것을 원하지 않는다고 답했습니다.
이는 기업용 AI 제품을 개발하는 사람들에게 중요한 시사점을 던져줍니다. 기억 기능은 많을수록 좋은 것은 아닙니다. '무엇이든 자동으로 기억한다'는 것보다, 투명하고 관리 가능하며 삭제할 수 있는 것이 사용자에게 더 큰 안도감을 줄 수 있습니다.
가장 많은 응답률을 보인 답변은 **29.7%**로, 'AI는 기본적으로 임의적이며, 직원이 각자 사용 방법을 결정하고 있다'였습니다. 승인된 도구와 명확한 이용 가이드라인이 있는 회사는 24%를 차지했습니다. 또한, 15.9%는 일부 팀만이 적극적으로 도입하고 있어 운영 방식이 통일되어 있지 않다고 답했습니다.
이 데이터만으로는 특정 관리 단계에 있는 기업이 전 세계 얼마나 되는지 직접 추정할 수는 없습니다. 집계 대상 자체가 응답자가 자신의 조직에 대해 언급한 내용이기 때문입니다. 하지만, 도구의 보급 속도는 빠르지만 규칙이나 협업 체계가 이를 따라가지 못하고 있다는 점은 명확히 드러납니다.
AI 사용을 의식적으로 피한다고 답한 사람은 41.3%였습니다. 반면, 약 **58.7%**는 어떤 종류의 우려 때문에 AI 활용을 의도적으로 자제하고 있다고 답했습니다.
주요 이유는 기술 습득 능력 저하 또는 일자리 대체에 대한 우려(17.1%), 윤리적 문제(15.2%), 개인정보 보호 및 보안(13%), 환경 영향(8.2%)이었습니다. 이러한 우려가 AI를 전면적으로 사용하지 않는 유일한 이유라고 단정할 수는 없지만, 활용 범위나 수용 방식에는 분명히 영향을 미치고 있습니다.
반대 의견을 모두 '새로운 도구를 배우기 싫어서'라는 단순한 설명으로 치부하는 것은 명백하게 지나칩니다.
**32.8%**의 응답자는 회사가 승인한 소수의 도구만을 채택하고 있다고 답했습니다. **18.6%**는 주로 하나의 도구만 사용하고 있다고 답변했습니다. 이 둘을 합치면 **51.4%**에 달하여, 많은 팀들이 도구를 좁히고 선택하는 단계에 들어섰음을 알 수 있습니다.
한편, 17.3%의 회사는 각 팀이 자체적으로 도구를 선택하며, 12.5%는 여전히 폭넓게 시도해보는 단계입니다. 조직이 독자적인 내부 도구나 모델을 개발하고 있다고 답한 사람은 단지 **4.3%**에 불과했습니다.
이는 많은 AI 프로젝트가 다음에 직면할 과제일 수 있습니다. 부족한 것은 모델 자체가 아니라, 보안(Security), 비용(Cost), 효과성(Effectiveness), 사용 용이성(Usability) 사이의 균형을 맞추면서 안정적인 업무 방식을 어떻게 구축하느냐 하는 문제입니다.
이 22장의 자료를 보며 느낀 점은 'AI가 개발을 대신한다'는 것도 아니고, 'AI가 기대만큼 뛰어나지 않다'는 것도 아니었습니다. 오히려 세 가지 변화가 동시에 일어나고 있는 듯합니다.
첫째, AI는 단독적인 질의응답(Q&A) 도구에서 소프트웨어 개발 프로세스의 기반으로 변화하고 있습니다. 코딩, 디버깅(Debugging), 테스트, 문서 작성 등 깊이 활용하는 사람들이 이미 존재합니다. 그러나 실제 운영 환경(Production Environment), 권한, 보안, 중요한 판단에 가까워질수록 사람들은 더욱 신중해집니다.
둘째, 검증할 수 있는 능력의 가치가 오히려 높아지고 있습니다. AI는 빠르게 답을 내놓지만, 실행 방법, 경계 조건(Boundary Condition) 확인 방법, 코드베이스 현황과의 모순점을 구별하는 방법을 알아야 합니다. 시스템, 업무, 테스트를 이해하고 있는 사람의 중요성이 그로 인해 사라지는 것은 아닙니다.
셋째, Agent 시장은 빠르게 성장하고 있지만 아직 형태가 정립되지 않았습니다. 코딩 어시스턴트(Coding Assistant)에는 명확한 상위 제품이 존재하는 반면, 메모리(Memory), 오케스트레이션(Orchestration), 가시성(Observability), 자동화(Automation) 등의 분야에서는 여전히 다양한 제품들이 존재합니다. 기업에서 본격적으로 도입할 때 요구되는 것은 어떤 모델이 벤치마크(Benchmark)에서 약간 높은 점수를 얻느냐가 아니라, 완벽하고, 제어 가능하며, 유지보수가 용이한 워크플로우를 구축할 수 있는지 여부입니다.
2026년의 질문은 더 이상 '개발자는 AI를 사용해야 하는가'가 아닙니다. '사용법을 익히고, 안심하고 활용하며, 책임지는 것 사이의 균형을 어떻게 맞출 것인가'입니다.
