AI 툴은 깔았는데, 왜 개발팀은 그대로일까

AI 툴은 깔았는데, 왜 개발팀은 그대로일까

 

개발조직 AX 전환은 도구 설치가 아니라, 사람들이 새 방식으로 일해도 손해 보지 않는 구조를 만드는 일에 가깝습니다.

 

 

AI 활용 사례를 공유하자고 했는데, 정작 아무도 먼저 말하지 않는 순간. 관심이 없는 게 아니라 말하면 손해 볼 수 있는 구조일 수 있습니다.

 

 

요즘 개발조직에서 이런 말을 자주 듣습니다.

 

우리도 AX 조직으로 바뀌어야 합니다.

 

 

틀린 말은 아닙니다.

 

이제 AI 코딩 도구를 아예 안 쓰는 개발팀을 찾는 게 더 어렵습니다. 코드 초안, 테스트 생성, PR 설명, 장애 로그 요약, 라이브러리 사용법 확인까지 이미 업무 안으로 들어왔습니다.

 

그런데 이상한 장면이 생깁니다.

 

팀장이 채널에 글을 올립니다.

 

이번 주 AI 활용 사례 공유해 주세요.

 

 

좋아요는 몇 개 찍힙니다. 댓글은 별로 없습니다.

 

누가 안 쓰는 것도 아닙니다. 이미 쓰는 사람은 씁니다. 다만 공개적으로 말하기가 애매합니다.

 

잘 쓰는 사람은 이런 생각을 합니다.

 

괜히 공유했다가 앞으로 내 일만 더 빨리 끝내라고 하면?

 

 

아직 잘 못 쓰는 사람은 또 다르게 생각합니다.

 

지금 못한다고 말하면 뒤처진 사람처럼 보이는 거 아닌가?

 

 

리더는 이 침묵을 보고 “관심이 없네”라고 해석하기 쉽습니다.

 

나는 이 장면을 조금 다르게 봅니다.

 

관심이 없는 게 아니라,
말하면 손해 볼 것 같은 구조일 수 있습니다.

 

 

비슷한 도구를 쓰는데, 조직마다 결과는 완전히 달라집니다.

 

A팀은 몇 달 만에 일하는 방식이 바뀝니다. 기획 단계에서 AI로 엣지 케이스를 뽑고, 이슈를 더 작게 쪼갭니다. PR을 올리기 전에 AI로 빠진 테스트를 점검하고, 장애 회고에서는 로그와 트레이스를 먼저 요약해 원인 후보를 좁힙니다. 실패한 프롬프트와 이상한 코드 생성 사례도 팀 문서에 남깁니다.

B팀은 달라진 게 거의 없습니다. 몇몇 개발자는 개인적으로 잘 씁니다. 어떤 사람은 쓰면서도 티를 안 냅니다. 어떤 사람은 아예 불신합니다. 회의에서는 AI 이야기가 나오지만 PR 규칙, 테스트 기준, 장애 회고 방식은 그대로입니다.

 

 

같은 도구를 써도 어떤 팀은 사용 경험을 팀의 학습으로 바꾸고, 어떤 팀은 개인 사용에 머뭅니다.

 

 

겉으로는 둘 다 AI를 도입했습니다.

 

하지만 한쪽은 팀의 일하는 방식이 바뀌었고, 다른 한쪽은 개인 요령이 늘어난 정도에서 멈췄습니다.

 

이 차이는 어디서 생길까요?

 

툴 문제일까요. 기술스택 문제일까요. 개발자 역량 문제일까요.

 

일부는 맞습니다. 테스트가 없고, 문서가 없고, 레거시가 복잡하고, 보안 정책이 엄격한 조직은 AI 적용이 어렵습니다. 도메인 규칙이 코드와 사람 머릿속에만 있는 조직도 어렵습니다.

 

하지만 이것만으로는 설명이 부족합니다.

 

비슷한 제약에서도 어떤 팀은 작은 성공을 만들고, 어떤 팀은 멈춥니다. 어떤 팀은 실패 사례를 모아 다음 시도를 고치고, 어떤 팀은 첫 실패 뒤에 조용히 접습니다.

 

내가 보기엔 여기서 테크 리더의 실력이 갈립니다. AI를 설명하는 능력이 아니라, 사람들이 왜 새 방식을 조심하는지 읽는 능력입니다.

 

 

 

 

AI 사용과 AX 전환은 다릅니다

 

개인이 AI를 쓰는 것과 개발조직이 AX로 전환되는 것은 다릅니다.

 

개인 사용 단계에서는 개발자가 혼자 AI를 씁니다. 코드 초안, 검색, 리팩터링, 테스트 생성에 활용합니다. 어떤 사람은 생산성이 눈에 띄게 오릅니다. 그런데 팀의 공식 방식은 그대로입니다.

 

이 단계에서는 AI가 개인의 요령입니다.

 

팀 단위 사용으로 넘어가면 달라집니다. PR, 리뷰, 테스트, 이슈 쪼개기, 문서화에 AI 사용 기준이 생깁니다. 실패 사례와 좋은 사용법이 공유됩니다. AI가 팀 리듬 안에 들어옵니다.

 

이때부터 AI는 팀의 작업 방식이 됩니다.

 

조직 운영 방식까지 가면 더 달라집니다. 온보딩, 장애 회고, 기술부채 관리, 품질 기준, 제품 실험까지 AI 활용 방식이 연결됩니다. AI 사용은 개인의 재주가 아니라 조직의 기본 역량이 됩니다.

 

많은 조직은 첫 단계에서 멈춥니다.

 

대표나 리더는 말합니다.

 

우리도 AI 쓰고 있습니다.

 

 

그런데 실제로는 일부 개인이 자기 방식대로 쓰고 있을 뿐입니다.

 

AI 계정이 많아졌다고 AX 조직이 된 건 아닙니다. 교육을 한 번 했다고 전환이 끝난 것도 아닙니다.

 

AX 조직은 AI 사용 경험이
팀의 규칙과 학습으로 바뀌는 조직입니다.

 

 

 

 

기술스택은 중요합니다. 하지만 거기서 끝나지 않습니다

 

개발조직에서 AI 적용이 어려운 기술적 이유는 실제로 있습니다.

 

• 테스트가 없습니다.
• 문서가 없습니다.
• 도메인 규칙이 코드에 숨어 있습니다.
• 레거시가 복잡합니다.
• 사내 보안 정책상 외부 도구를 쓰기 어렵습니다.
• 코드베이스가 너무 특수해서 일반 모델이 맥락을 잘 못 잡습니다.

 

이 문제들은 실제입니다. 현장에서는 꽤 자주 막힙니다.

 

테스트도 없고, 배포도 불안하고, 로그도 부실한 조직에서 “AI로 개발 생산성 올리자”고만 말하면 현장은 바로 알아챕니다.

 

이건 또 위에서 내려온 말이구나.

 

 

그런데 여기서 기술 문제만 보면 반쪽만 본 겁니다.

 

같은 조건에서도 어떤 팀은 작은 실험을 시작합니다. 운영 리스크가 낮은 업무부터 고릅니다. 실패한 사례를 모읍니다. 사내 보안 기준 안에서 쓸 수 있는 방식을 찾습니다. 그리고 작게라도 “이건 된다”를 팀에 보여줍니다.

 

반대로 어떤 팀은 멈춥니다.

 

• 우리 코드는 특수해서 안 돼.
• 보안 때문에 안 돼.
• AI가 우리 도메인을 몰라.

 

이 말들이 완전히 틀렸다는 뜻은 아닙니다.

 

다만 질문이 하나 더 필요합니다.

 

정말 기술 때문에 멈춘 걸까요. 아니면 새 방식을 시도하다가 어설퍼지는 순간을 조직이 견디지 못해서 멈춘 걸까요.

 

 

DORA의 2025년 AI-assisted Software Development 리포트는 AI를 조직의 기존 강점과 약점을 확대하는 증폭기로 설명합니다. 도구 자체보다 그 도구가 놓이는 조직 시스템을 봐야 한다는 이야기입니다.

 

이 말은 개발조직 AX에 꽤 정확하게 들어맞습니다.

 

AI는 약한 조직을 갑자기 강한 조직으로 만들어주지 않습니다. 오히려 기존의 정보 흐름, 신뢰, 책임 구조, 학습 방식이 그대로 드러납니다.

 

• 나쁜 소식이 숨겨지는 팀에서는 AI 실패도 숨겨집니다.
• 리뷰 문화가 약한 팀에서는 AI가 만든 결과물도 대충 넘어갑니다.
• 리더가 일정 압박만 하는 팀에서는 AI가 학습 도구가 아니라 압박 도구가 됩니다.

 

그래서 기술스택은 봐야 합니다.

 

다만 거기서 멈추면 원인을 반만 찾고 끝납니다.

 

 

 

개발자의 저항은 무지가 아니라 자기보호일 수 있습니다

 

AI 도입에 저항하는 개발자를 두고 단순하게 말하기 쉽습니다.

 

• 보수적이다.
• 변화를 싫어한다.
• 공부를 안 한다.

 

그런데 현장은 그렇게 단순하지 않습니다.

 

개발자는 AI가 자기 일에 어떤 의미인지 꽤 빠르게 계산합니다.

 

• 내가 쌓아온 전문성이 낮게 평가되는 건 아닌가.
• AI를 쓰면 더 많은 일을 더 빨리 하라고 압박받는 건 아닌가.
• AI가 만든 코드에서 문제가 생기면 누가 책임지는가.
• 내가 AI를 잘 못 쓰면 뒤처진 사람처럼 보이는가.
• 내가 잘 쓰는 방법을 공유하면 나만 더 바빠지는가.
• 리더는 나를 돕고 싶은 건가, 감시하고 싶은 건가.

 

이 질문이 해결되지 않으면 사람들은 겉으로는 동의하고 속으로는 멈춥니다.

 

회의에서는 “좋네요”라고 말합니다.

 

자리로 돌아가서는 예전 방식으로 일합니다.

 

혹은 AI를 쓰지만 숨깁니다.

 

이건 비합리적 행동이 아닙니다.
조직이 그렇게 행동하게 만든 겁니다.

 

 

특히 개발조직에서는 체면이 생각보다 큽니다. 내가 모른다는 걸 들키기 싫습니다. AI 도움을 받았다는 사실이 내 실력 부족처럼 보이는 것도 싫습니다.

 

AI가 만든 코드가 틀렸다고 말하면 괜히 내 검증 능력까지 의심받을까 봐 조용히 넘어가고 싶어질 수도 있습니다.

 

리더가 이걸 읽지 못하면 계속 같은 말을 반복합니다.

 

좋은 도구인데 왜 안 쓰지?

 

 

하지만 개발자 입장에서는 질문이 조금 다릅니다.

 

이걸 쓰면 내가 안전한가?

 

 

이 질문에 답하지 못하면 도입은 멈춥니다. 공식적으로는 진행 중이어도, 실제 업무는 그대로 갑니다.

 

 

 

빠르게 전환하는 팀은 먼저 안전장치를 만듭니다

 

빠르게 AX로 전환하는 조직은 AI를 무작정 강제하지 않습니다.

 

먼저 안전한 실험 공간을 만듭니다.

 

• 운영 리스크가 낮은 업무부터 시작합니다.
• AI 실패 사례를 공개적으로 공유합니다.
• 사용률보다 학습 내용을 봅니다.
• AI가 만든 결과물의 승인 기준을 명확히 합니다.
• 잘 쓴 사람에게 일을 몰아주지 않습니다.
• 못 쓰는 사람을 뒤처진 사람으로 만들지 않습니다.
• 리더가 자기 시행착오를 먼저 보여줍니다.

 

이런 장치가 있으면 사람은 움직입니다. 새 방식을 시도하다가 잠시 어설퍼져도 괜찮다고 느끼기 때문입니다.

 

Google의 Project Aristotle은 팀 효과성에서 “누가 팀에 있느냐”보다 “팀이 어떻게 함께 일하느냐”가 중요하다고 봅니다. 심리적 안전감, 신뢰성, 구조와 명확성, 의미, 영향이 주요 축으로 정리됩니다.

 

이걸 AX에 가져오면 질문이 선명해집니다.

 

• AI가 만든 결과가 틀렸다고 말할 수 있는가.
• AI 사용 책임과 승인 기준이 명확한가.
• 이 변화가 내 일을 더 낫게 만든다는 의미가 있는가.
• 작은 성공이 실제로 보이는가.

 

여기서 말하는 심리적 안전감은 좋은 분위기가 아닙니다. 회의실이 화목하다는 뜻도 아닙니다.

 

질문, 실패, 반대 의견, 도움 요청이 가능한 상태입니다.

 

AX에서 심리적 안전감은 이런 말로 나타납니다.

 

• 이 프롬프트는 실패했습니다.
• 이 방식은 보안상 위험합니다.
• AI가 만든 테스트가 틀렸습니다.
• 이 업무는 자동화하면 안 됩니다.
• 저는 아직 이 도구가 어렵습니다.

 

이 말들이 나와야 조직이 배웁니다.

 

빠르게 배우는 팀은 실패를 숨기지 않습니다. 실패한 AI 결과를 누가 잘못했는지 따지는 대신, 다음 작업 기준을 고치는 재료로 씁니다.

 

 

사람들이 말하지 못하는 조직에서는
AX도 자라지 않습니다.

 

 

 

 

변화는 공식 교육보다 누가 말하느냐에서 갈립니다

 

여기서 함께 자라기의 Git 도입 이야기가 떠오릅니다.

 

같은 Git 설명을 해도 어떤 조직은 성공하고, 어떤 조직은 실패합니다. 설명 문장이 맞았는지만으로는 부족합니다. 그 말을 하는 사람을 조직이 어떻게 느끼느냐가 같이 들어갑니다.

 

내가 이 사례에서 붙잡고 싶은 질문은 이것입니다.

 

조직이 그 사람에게 배우고 싶어 하는가?

 

 

이 질문은 AX에도 그대로 들어옵니다.

 

테크 리더가 아무리 맞는 말을 해도, 팀이 그 리더를 일정을 더 당기려는 사람으로 느끼면 저항합니다.

 

반대로 팀이 그 리더를 실패했을 때 같이 막아줄 사람으로 느끼면 실험합니다.

 

그래서 AX 리더에게 인문학이 필요합니다.

 

여기서 말하는 인문학은 고전 지식이 아닙니다.

 

• 사람이 왜 방어적으로 변하는지 아는 것.
• 체면과 책임이 행동을 어떻게 막는지 보는 것.
• 정답을 말하는 것보다 신뢰를 만드는 것이 먼저일 때를 아는 것.
• 조직 안에서 말이 누구를 통해 움직이는지 읽는 것.

 

이것이 기술 설득보다 먼저 필요한 사람 이해입니다.

 

오해하면 안 됩니다.

 

이건 개발자 기분을 맞춰주자는 이야기가 아닙니다.

 

변화가 실제로 일어나려면 사람들이 움직여야 하고, 사람은 논리만으로 움직이지 않는다는 이야기입니다.

 

특히 개발조직은 자존심, 책임감, 전문성, 평가가 강하게 얽혀 있습니다. 그래서 리더의 말 한마디가 지원으로 들릴 수도 있고, 압박으로 들릴 수도 있습니다.

 

개발조직 AX는 기술 전파이면서 동시에 신뢰 전파입니다.

 

 

 

 

빠른 조직은 전파 구조가 다릅니다

 

AI 도입은 전사 공지 한 번으로 퍼지지 않습니다.

 

사람을 통해 퍼집니다.

 

빠르게 전환하는 조직에는 보통 이런 구조가 있습니다.

 

• 먼저 실험하는 사람이 있습니다.
• 그 사람이 혼자 영웅이 되지 않고 사용법을 공개합니다.
• 팀 안에서 신뢰받는 사람이 변화의 중간 다리가 됩니다.
• 작은 성공이 반복적으로 공유됩니다.
• 실패 사례도 숨기지 않습니다.
• 리더는 그 공유를 평가나 감시로 바꾸지 않습니다.

 

반대로 실패하는 조직은 다르게 움직입니다.

 

• 대표나 CTO가 위에서 “AI 써라”라고 말합니다.
• 교육은 한 번 합니다.
• 사용률을 묻습니다.
• 몇몇 개인만 씁니다.
• 실패 사례는 숨겨집니다.
• 잘 쓰는 사람에게 일이 몰립니다.
• 못 쓰는 사람은 조용히 방어합니다.

 

그래서 조직 방식은 바뀌지 않습니다.

 

Everett Rogers의 혁신 확산 이론을 빌리면, 새로운 기술은 모두에게 동시에 퍼지지 않습니다. 초기 수용자, 의견 리더, 관찰 가능한 작은 성공, 시험 가능성이 중요합니다.

 

개발조직 AX도 마찬가지입니다.

 

전사 공지가 아니라, 신뢰받는 사람과 작은 성공을 통해 퍼집니다.

 

 

 

처음 30일은 이렇게 가는 편이 낫습니다

 

AX 전환을 시작한다고 해서 처음부터 전사 공지, 대형 교육, 사용률 대시보드로 들어가면 부담이 커집니다.

 

개발조직에서는 차라리 작게 시작하는 편이 낫습니다. 단, 작다는 말이 대충 해도 된다는 뜻은 아닙니다. 범위를 작게 잡고, 기준은 선명하게 잡아야 합니다.

 

 

1주차: 쓰지 말아야 할 곳부터 정합니다

 

AI를 어디에 쓸지보다 먼저 어디에 쓰면 안 되는지 정합니다.

 

• 고객 개인정보가 들어간 로그를 그대로 넣지 않는다.
• 운영 DB 덤프나 민감한 설정 파일을 외부 도구에 넣지 않는다.
• 라이선스가 불명확한 코드를 그대로 붙여 넣지 않는다.
• 보안 관련 변경은 사람이 반드시 승인한다.

 

이 기준이 없으면 개발자는 계속 눈치를 봅니다. 눈치를 보는 도입은 오래 못 갑니다.

 

 

2주차: 낮은 리스크 업무 하나를 고릅니다

 

처음부터 핵심 결제 로직이나 장애 대응 자동화를 건드릴 필요는 없습니다.

 

이슈 분해, 테스트 케이스 후보 만들기, PR 설명 초안, 릴리즈 노트 정리, 온보딩 문서 보강처럼 실패해도 바로 고객 장애로 이어지지 않는 업무가 좋습니다.

 

여기서 목표는 “AI가 얼마나 대단한가”를 증명하는 게 아닙니다.

 

팀이 새 방식으로 같이 일할 수 있는지를 보는 겁니다.

 

 

3주차: 성공 사례보다 실패 사례를 먼저 모읍니다

 

성공담만 모으면 발표자료는 예뻐집니다. 대신 조직은 잘 안 배웁니다.

 

실제로 도움이 되는 것은 이런 기록입니다.

 

• AI가 놓친 엣지 케이스
• 그럴듯했지만 틀린 테스트
• 리뷰에서 걸러진 위험한 코드 제안
• 프롬프트를 바꾸니 결과가 좋아진 사례
• 이 업무에는 AI를 쓰지 않는 게 낫다는 판단

 

이런 기록이 쌓이면 팀은 AI를 신비한 도구가 아니라 다룰 수 있는 업무 도구로 보기 시작합니다.

 

 

4주차: 팀의 작업 약속으로 바꿉니다

 

마지막에는 사용 후기를 모으는 데서 끝내면 안 됩니다.

 

팀 규칙으로 바꿔야 합니다.

 

• PR 올리기 전 AI로 누락 테스트 후보를 한 번 점검한다.
• AI가 만든 코드는 작성자가 책임지고 검증한다.
• AI 실패 사례는 회고 문서에 남긴다.
• 보안상 입력 금지 데이터는 예시와 함께 문서화한다.
• 잘 된 프롬프트는 개인 메모가 아니라 팀 문서에 남긴다.

 

이 정도가 되어야 개인 요령이 팀의 일하는 방식으로 넘어갑니다.

 

 

 

테크 리더의 일은 도구 선정이 아니라 수용 조건 설계입니다

 

테크 리더는 기술스택 문제와 사람 문제를 분리해서 봐야 합니다.

 

• 저항하는 사람을 무식하다고 보면 안 됩니다.
• AI 사용을 일정 압박 언어로만 말하면 안 됩니다.
• 낮은 리스크의 파일럿을 먼저 골라야 합니다.
• 실험 결과를 개인 평가와 분리해야 합니다.
• 실패 사례를 공개해도 안전한 장치를 만들어야 합니다.
• 신뢰받는 내부 전파자를 세워야 합니다.
• AI 사용 기준을 감시 규정이 아니라 작업 약속으로 만들어야 합니다.
• 경영진의 기대를 현실적인 변화 단계로 번역해야 합니다.

 

AX 테크 리더의 일은 AI를 믿으라고 설득하는 것이 아닙니다.

 

사람들이 새 방식을 시도해도 손해 보지 않는 조건을 만드는 것입니다.

 

 

AX 리더는 도구 설명자가 아니라 번역자에 가깝습니다. 경영진의 기대와 개발팀의 현실 사이에서 실험 범위, 실패 공유, 승인 기준을 작업 약속으로 바꿔야 합니다.

 

 

조금 더 세게 말하면, AX 전환에서 가장 위험한 리더는 AI를 모르는 리더만이 아닙니다.

 

사람을 모르는 리더입니다.

 

기술은 배울 수 있습니다. 도구는 바뀝니다. 모델 이름도 계속 바뀝니다.

 

그런데 사람들이 왜 숨는지, 왜 방어하는지, 왜 겉으로 동의하고 속으로 멈추는지 읽지 못하면 매번 같은 실패를 반복합니다.

 

 

 

우리 조직은 어디쯤인가

 

아래 질문에 답해보면 현재 위치가 보입니다.

 

• 우리 조직의 AI 사용은 개인 사용인가, 팀 프로세스인가.
• AI를 잘 쓰는 사람의 노하우가 팀 자산으로 바뀌고 있는가.
• 실패한 프롬프트와 잘못된 생성 결과를 공유해도 안전한가.
• AI 사용이 일정 단축 압박으로만 번역되고 있지 않은가.
• 팀에서 신뢰받는 사람이 변화 전파자 역할을 하고 있는가.
• 못 쓰는 사람을 부끄럽게 만들지 않고 끌어올리는 장치가 있는가.
• AI가 만든 결과물의 승인 기준이 있는가.
• 실험과 성과평가가 분리되어 있는가.
• 리더가 자기 시행착오를 먼저 공유했는가.
• 우리 조직은 기술스택 문제와 신뢰 문제를 구분해서 보고 있는가.

 

여기서 “아니오”가 많다면, 새 도구를 하나 더 사는 것보다 먼저 해야 할 일이 있습니다.

 

팀이 안전하게 시도하고, 실패하고, 공유하고, 고칠 수 있는 구조를 만드는 것입니다.

 

 

 

마무리

 

AI 도구는 앞으로도 빠르게 좋아질 겁니다.

 

하지만 도구가 좋아진다고 조직이 자동으로 AX가 되지는 않습니다.

 

같은 도구를 써도 어떤 팀은 조직의 일하는 방식을 바꾸고, 어떤 팀은 개인 사용에 머뭅니다.

 

그 차이는 기술스택만으로 설명되지 않습니다.

 

AX 조직은 AI를 많이 쓰는 조직이 아닙니다. 사람들이 AI로 일하는 방식을 함께 바꿔도 안전하다고 믿는 조직입니다.

 

 

 

 

참고한 자료

 

• DORA - State of AI-assisted Software Development 2025
• DORA - Generative organizational culture
• Google re:Work - Understand team effectiveness
• Amy Edmondson - Psychological Safety and Learning Behavior in Work Teams
• Prosci - ADKAR Model
• Diffusion of Innovations
• 김창준, 함께 자라기