AI · 소프트웨어 · 조직
인공지능(Artificial Intelligence, AI) 코딩 도구는 더 이상 '자동완성'에 머무르지 않는다. 2025년을 지나며 그것은 일하는 방식을 넘어 조직도와 채용, 평가 기준, 심지어 사업 모델까지 흔드는 변수가 되었다.
불과 1년 전만 해도 AI 코딩은 보조 도구의 인상이 강했다. 개발자가 코드를 어느 정도 짜 두면 나머지를 채워 주거나, 반복되는 구문을 대신 입력해 주는 정도였다. 2025년 말을 지나면서 분위기가 달라졌다. 단순 작업을 넘어, 사람이 시간을 들여 풀던 제법 복잡한 문제까지 도구가 대신 해결하기 시작한 것이다. 그 결과 변한 것은 개인의 생산성만이 아니다. 일을 나누는 방식, 사람을 뽑는 기준, 성과를 재는 잣대, 그리고 조직의 위계 구조 자체가 함께 흔들리고 있다.
이 글은 실리콘밸리에서 엔지니어링 조직을 이끄는 현장 리더들의 증언과, 같은 시기에 공개된 측정 데이터·기업 사례를 묶어 그 변화의 윤곽을 그린다. 다만 한 가지는 미리 적어 둔다. 이 분야의 진단에는 모두 '석 달 뒤면 다른 이야기가 될 수 있다'는 단서가 붙는다. 그래서 이 글이 붙잡으려는 것은 단정이 아니라 방향성이다.
현장에서 관리자들이 가장 먼저 체감하는 변화는 사람 사이의 격차다. 어느 시대에나 잘하는 엔지니어와 그렇지 못한 엔지니어는 있었다. 다만 그 차이가 과거에는 기껏해야 두세 배 수준이었다고 한다. 아무리 뛰어난 사람도 잠을 자고 밥을 먹어야 했고, 결국 물리적 시간이 산출의 상한을 눌렀기 때문이다. AI가 그 상한의 일부를 풀어 주면서, 상위권과 하위권의 차이가 열 배, 스무 배로 벌어지는 장면이 보고된다.
이 현상을 이해하는 데 오래된 경영 개념 하나가 유용하다. 넷플릭스의 리드 헤이스팅스가 정리한 인재 밀도(talent density)다. 핵심은 조직의 힘이 머릿수의 총량이 아니라 고성과자의 '밀도'에서 나온다는 것이다. 헤이스팅스는 닷컴 거품이 꺼진 뒤 인력의 3분의 1을 줄였는데, 예상과 달리 남은 팀이 더 적은 인원으로 더 많은 일을 해냈다는 경험에서 이 원칙을 길어 올렸다. 사람이 줄자 '실수 방지용' 절차가 줄었고, 모두가 빠르게 움직였다는 것이다.
열 명짜리 팀이 각자 10만큼 일하면 총량은 100이다. 다섯 명짜리 팀이 각자 20만큼 일해도 총량은 똑같이 100이다. 그런데 실제로 굴려 보면 두 번째 팀이 더 많은 결과를 낸다. 사람이 적을수록 서로 조율하고, 설명하고, 기다리는 데 드는 비용이 줄기 때문이다.
AI는 개인이 낼 수 있는 '20'의 천장을 끌어올린다. 그래서 같은 총량이라도 소수 정예에 더 유리해진다. 인재 밀도라는 오래된 화두가 AI 시대에 다시 날카로워지는 이유다.
그러나 '열 배, 스무 배'를 평균값으로 오해하면 곤란하다. 가장 엄밀한 측정은 오히려 정반대 신호를 보낸다. 비영리 연구기관 METR이 2025년 7월 발표한 무작위 대조 시험(Randomized Controlled Trial, RCT)이 그것이다. 평균 5년 이상 기여한 숙련 오픈소스 개발자 16명에게 자신의 실제 작업 목록 246건을 주고, 과제마다 AI 도구 사용 허용 여부를 무작위로 배정했다. 결과는 충격적이었다. 개발자들은 AI를 쓰면 24% 빨라질 것이라 예상했지만, 실제로는 작업 시간이 19% 늘었다. 더 흥미로운 것은 인식의 괴리다. 객관적으로는 느려졌는데도, 끝난 뒤 본인들은 평균 20% 빨라졌다고 믿었다. 경제·기계학습 전문가들의 사전 예측은 38~39% 단축이었으니, 기대와 현실의 간극은 더 컸다.
왜 느려졌을까. 코드를 직접 짜는 시간은 줄었지만, AI가 내놓은 결과를 읽고 검증하고 고치는 시간이 그만큼, 아니 그 이상으로 늘었기 때문이다. 작업의 무게중심이 '쓰기'에서 '검토하기'로 옮겨 간 것이다. METR은 2026년 2월 후속 실험 결과도 내놓았는데, 이번에는 깨끗한 결론을 얻지 못했다고 밝혔다. 상당수 개발자가 'AI 없이는 일하지 않겠다'며 대조군 참여를 거부해 표본이 한쪽으로 쏠린 탓이다. 도구가 이미 일상이 되었다는 방증인 동시에, 그 효과를 객관적으로 재기가 점점 더 어려워진다는 신호이기도 하다.
두 사실을 함께 놓으면 그림이 분명해진다. AI는 모두의 평균을 일률적으로 끌어올리는 장치가 아니다. 잘 쓰는 소수의 천장은 크게 높이고, 잘 다루지 못하는 다수는 검증 부담에 발이 묶이게 한다. 즉 평균이 오르는 것이 아니라 분산이 커진다. '열 배 격차'는 분포의 오른쪽 끝에서 벌어지는 일이지, 가운데가 통째로 이동하는 일이 아니다.
분산이 커지는 이유의 절반은 '누가 경계를 넘느냐'에 있다. 과거의 소프트웨어 조직은 분업으로 굴러갔다. 백엔드 개발자가 있고, 모바일(iOS) 개발자가 있고, 기계학습 개발자가 있었다. 새 기능 하나를 내놓으려면 백엔드가 자기 몫을 끝낸 뒤 모바일 담당에게 넘기고, 그가 다시 받아서 짜는 식의 협업이 필요했다. 그 사이에는 기다림과 인수인계가 끼어 있었다.
이제는 백엔드 개발자가 자기 몫을 끝낸 뒤, 바쁜 모바일 담당을 기다리는 대신 AI를 써서 모바일 부분까지 직접 짜 본다. 기획자가 아이디어를 내고 분석가가 검증하고 디자이너가 그린 다음에야 엔지니어에게 구현이 떨어지던 흐름도, 이제는 엔지니어가 문제를 발견하고 아이디어를 내는 단계부터 끌고 갈 수 있다. 결과적으로 도메인의 벽을 넘어 문제를 끝까지 책임지는 사람이 더 빨리 출시하고 더 큰 영향을 남긴다.
이런 작업 방식의 극단에는 2025년 2월 안드레이 카파시가 이름 붙인 바이브 코딩(vibe coding)이 있다. 코드의 존재를 잊은 채 자연어로 의도만 전달하고 나머지를 대규모 언어모델(Large Language Model, LLM)에 맡기는 방식이다. 병목이 '문법을 아는가'에서 '무엇을 만들어야 하는가'로 옮겨 갔다는 선언이기도 하다. 다만 이 용어는 1년 사이 양면적으로 변했다. 시제품이나 사내 도구를 빠르게 만드는 데는 강력하지만, 코드를 읽지 않고 그대로 운영 환경에 밀어 넣는 행위를 가리킬 때는 부정적 뉘앙스를 띠게 되었다.
경계가 흐려지는 데는 비용 곡선의 변화도 한몫한다. 가령 추천 시스템처럼 값비싼 기계학습 인력을 한 팀씩 굴려야 하던 기능을, 이제는 더 작은 제품도 시도해 볼 수 있다. 예전에는 자동화하지 않고 사람 손으로 처리하던 일에도 더 복잡한 솔루션을 끼워 넣을 여지가 생긴다. 만드는 비용이 내려가면 적용 범위가 넓어진다. 산업 전체의 투자수익률(Return on Investment, ROI) 셈법이 달라지는 것이다. 그래서 'AI가 엔지니어를 없앤다'기보다, '엔지니어가 다룰 수 있는 문제의 범위가 넓어진다'고 읽는 편이 현실에 가깝다. 단, 그 넓어진 범위는 경계를 넘을 수 있는 사람에게만 열린다. 1절에서 본 분산 확대와 정확히 맞물리는 지점이다.
경계를 넘는 인재가 귀해지자, 기업은 'AI를 얼마나 쓰는지'를 들여다보기 시작했다. 한동안 현장에는 "토큰을 많이 안 쓰면 일을 안 하는 것"이라는 분위기마저 돌았다. 여기서 토큰이란 언어모델이 글자를 처리하는 최소 단위로, 사용량을 재는 계량기에 해당한다. 사용량 자체를 생산성으로 간주하기 시작한 것이다.
2026년 들어 이 흐름은 구체적인 사례로 드러났다. 한 대형 기술기업은 개발자의 80% 이상이 매주 AI 도구를 쓰도록 목표를 세우고, 토큰 소비량을 사내 순위표로 추적했다. 또 다른 기업에서는 직원들이 만든 'Claudeonomics'라는 대시보드가 화제가 됐는데, 'Token Legend' 같은 칭호를 두고 경쟁이 붙으면서 30일 토큰 소비가 약 60조에서 74조 가까이로 치솟은 뒤에야 순위표가 폐지됐다. 한 회사는 2026년 AI 예산을 단 넉 달 만에 소진했고, 최고운영책임자는 그 토큰 증가가 실제로 출시된 기능과 어떻게 연결되는지 설명하지 못했다고 한다. 어느 반도체 기업 경영자는 "50만 달러를 받는 엔지니어가 25만 달러어치 토큰도 쓰지 않는다면 깊이 우려스럽다"고까지 말했다.
마케팅 팀을 '누가 돈을 가장 많이 썼나'로 줄 세운다고 상상해 보자. 지출이 곧 성과라면 예산을 가장 빨리 태운 사람이 일등이다. 그러나 돈을 많이 쓴 것과 매출을 많이 올린 것은 다른 이야기다. 토큰 순위표도 마찬가지다. 높은 소진율을 높은 성공률로 착각하는 순간, 사람들은 결과가 아니라 계량기를 채우기 위해 움직인다.
실제로 입력을 늘린다고 산출의 품질이 따라오지는 않았다. 코드 분석 업체 GitClear가 2억 1,100만 줄의 코드 변경을 들여다본 결과, 2024년 들어 다섯 줄 이상 중복되는 코드 블록이 여덟 배로 늘었고, 사상 처음으로 '복사·붙여넣기'가 '코드 이동'을 앞질렀다. 코드 이동은 흩어진 코드를 재사용 가능한 모듈로 정리하는 리팩토링의 신호인데, 그 비중은 크게 줄었다. 작성 후 2주 안에 다시 고쳐지는 '단기 처닝(churn)'도 꾸준히 늘었다. 일부 고(高)AI 활용 환경의 데이터에서는 처리량이 늘어나는 동시에 1인당 버그와 코드 리뷰 대기 시간이 함께 치솟는 양상이 관찰됐다. 빨리 만들수록 빨리 쌓이는 부채가 있는 셈이다.
그래서 측정의 축이 되돌아오고 있다. 순위표는 도입 초기의 '강제 장치'로는 쓸모가 있었다. 어떤 변화든 조직에 안착시키려면 처음에는 공격적으로 밀어붙여야 하고, 일단 많이 써 봐야 '이럴 땐 잘 되고, 저럴 땐 쓰면 안 된다'는 감각이 조직 차원에서 학습된다. 그러나 그 과도기를 지나 사용이 습관이 되면, 순위표는 의미를 잃는다. 평가의 초점은 다시 산출, 곧 그 사람이 AI를 써서 비즈니스 가치가 있고 품질이 좋은 결과를 냈는가로 돌아온다. 토큰은 입력일 뿐 결과가 아니다.
측정의 축이 산출로 돌아오면, 누가 그 산출을 책임지느냐를 따지는 조직의 모양도 달라진다. 과거의 구도는 단순했다. 임원과 기획자는 '일을 만들어서 주는 사람'이었고, 엔지니어는 '받아서 하는 사람'이었다. 야구로 치면 코치와 선수가 분리돼 있었다.
지금은 개발 일선을 떠난 지 오래된 임원이 직접 코드를 짜고, 부하 직원에게 자기 코드의 리뷰를 요청하는 장면이 드물지 않다. 그러면 받은 쪽도 리뷰만 하고 있을 수는 없으니 함께 코드를 짠다. 모두가 선수 겸 감독으로 뛰는 형국이다. 일을 만드는 사람과 푸는 사람, 코치와 선수 사이의 경계가 흐려진다.
이 평탄화를 상징하는 것이 직함의 변화다. 최근 여러 빅테크와 사스(SaaS) 기업의 고위 기술 임원들이 자리를 옮기며 기술직원(Member of Technical Staff, MTS)이라는, 위계가 드러나지 않는 직함을 택하고 있다. 한 인사관리 소프트웨어 기업의 최고기술책임자(Chief Technology Officer, CTO)는 부임 1년도 안 돼 선도 AI 연구소의 MTS로 옮겨 강화학습 엔지니어링을 맡았고, 유명 사진 공유 서비스의 공동창업자 출신 경영자도 제품 총괄을 거쳐 직접 코딩 도구를 만드는 실험 조직의 기술직원으로 자리를 바꿨다. 한 선도 AI 연구소의 사장은 "사람을 연구자와 엔지니어로 나누고 싶지 않다"고 그 이유를 설명했다. 결국 직급이 아니라 '어떤 문제를 풀 수 있고 어떤 문제에 책임질 수 있는가'가 사람을 가르는 기준으로 옮겨 가는 흐름이다.
그런데 임원이 다시 코딩을 하는 진짜 이유는 향수 때문이 아니다. 그것은 다음 장에서 다룰 두 가지 질문, 곧 병목과 가드레일을 직접 몸으로 알기 위해서다.
현장 리더들이 제시하는 관리의 틀은 의외로 단순하다. 임원이라면 다음 두 질문에 자신 있게 답할 수 있어야 한다는 것이다.
첫째, 오늘 아주 똑똑한 사람이 입사해 AI로 시스템을 통째로 뜯어고치려 한다면, 그의 속도를 막는 병목은 무엇인가? 둘째, 아주 부주의한 사람이 입사해 AI로 위험한 변경을 마구 밀어붙이려 한다면, 그를 막아 줄 가드레일은 무엇인가?
이 두 질문이 신선한 까닭은, AI 시대의 조직 설계를 '사람을 늘릴까 줄일까'가 아니라 '병목을 없애고 가드레일을 세우는 일'로 다시 정의하기 때문이다. 병목을 걷어내야 유능한 사람이 마음껏 속도를 낼 수 있고, 가드레일을 세워야 부주의한 손이 큰 사고를 내지 않는다. 두 가지가 갖춰져야 비로소 사람들이 안심하고 뛰어놀 판이 만들어진다.
가드레일이 왜 절실한지는 앞서 본 코드 품질 데이터가 말해 준다. 중복이 늘고, 리팩토링이 줄고, 단기 처닝이 치솟는다. AI가 코드를 빨리 쏟아낼수록 '검토'가 새로운 병목으로 떠오르고, 검토를 게을리하면 그 부채가 운영 환경에서 터진다. 코드를 읽지 않고 그대로 밀어 넣는 바이브 코딩이 시제품에서는 매력적이지만 운영 시스템에서는 위험한 이유가 여기에 있다.
차가 빨라질수록 가드레일과 신호 체계는 더 중요해진다. 가드레일은 속도를 줄이려고 세우는 것이 아니다. 운전자가 사고를 두려워하지 않고 더 빨리 달릴 수 있게 하려고 세우는 것이다.
소프트웨어에서 그 가드레일은 자동화된 테스트, 지속적 통합(Continuous Integration, CI), 권한 분리, 코드 리뷰다. 이것이 갖춰져 있어야 AI를 든 엔지니어가 망설임 없이 속도를 낼 수 있다.
임원이 직접 코딩을 해 보는 의미도 여기서 분명해진다. 결정권자가 손수 해 봐야 "코드는 금방 짰는데 테스트가 느리다"는 병목을 발견하고, "이렇게 쓰면 위험하겠다"는 지점을 체감한다. 그래야 무엇을 걷어내고 무엇을 막아야 하는지 조직 차원에서 올바르게 설계할 수 있다.
일하는 방식이 바뀌면 사람을 뽑는 방식도 따라온다. 과거의 개발자 면접은 흔히 한 시간 동안 한 문제를 주고 알고리즘 코드를 짜게 하는 방식이었다. 이제는 여기에 더해, 지원자에게 AI 도구를 쥐여 주고 더 복잡한 문제를 더 긴 시간 동안 풀게 한다. 관심사는 '문법을 외웠는가'가 아니라 'AI를 동원해 실제 문제를 풀어내는가'로 옮겨 간다.
팀장급 채용의 질문은 한 단계 더 나아간다. 'AI를 이용해 팀 전체의 생산성을 가로막던 문제를 개선해 본 경험이 있는가.' 팀원들이 시간을 허비하던 절차를 자동화했는지, 또는 리더이면서도 직접 손을 대 문제를 풀어 봤는지를 본다. 평가의 축이 '아는 사람'에서 '활용해 결과를 내는 사람'으로 이동한 것이다. 이는 1절의 분산 확대, 2절의 경계 넘기, 3절의 산출 중심, 5절의 가드레일이라는 흐름을 그대로 채용의 첫 단계로 끌어온 셈이다.
지금까지의 변화를 조직의 언어로 정리하면 몇 가지 실천이 남는다. 이 대목은 현장 증언과 데이터에 필자의 해석을 더한 부분이다.
첫째, 측정의 축을 입력에서 산출로 옮겨야 한다. 토큰 사용량이나 작성한 코드의 양은 도입 초기의 적응 지표로는 쓸모가 있지만, 그것을 성과로 굳히는 순간 사람들은 계량기를 채우러 움직인다. 재야 할 것은 '얼마나 썼는가'가 아니라 '무엇이 살아남아 가치를 냈는가'다.
둘째, 경계를 넘는 사람을 알아보고 키워야 한다. 한 분야에 깊은 'T자형' 인재를 넘어, 여러 영역을 가로지르며 문제를 끝까지 책임지는 '빗(comb)자형'에 가까운 사람이 분포의 오른쪽 끝을 만든다. 이들이 막히지 않도록 도메인 사이의 칸막이와 인수인계 비용을 줄이는 일이 곧 조직의 경쟁력이 된다.
셋째, 가드레일에 먼저 투자해야 한다. 자동화된 테스트와 지속적 통합, 권한 분리, 리뷰 체계는 속도를 늦추는 비용이 아니라 속도를 내기 위한 전제다. AI가 빨라질수록 검토가 병목이 되므로, 가드레일을 갖추지 못한 조직일수록 빠른 생산이 빠른 부채로 되돌아온다.
넷째, 직급보다 책임과 문제를 중심에 두어야 한다. 조직의 평탄화는 그 자체가 목적이 아니라, 결정권자가 문제에 직접 닿을 때 자연스럽게 따라오는 결과다. 임원이 코딩을 한다는 사실보다, 임원이 병목과 위험을 몸으로 알고 그것을 조직 설계로 옮긴다는 점이 본질이다.
끝으로 겸손이 필요하다. 이 글의 모든 진단에는 '석 달 뒤면 다른 이야기가 될 수 있다'는 단서가 붙는다. 모델의 능력과 비용, 도구의 형태는 빠르게 변한다. 변하지 않는 것은 질문의 구조다. 무엇을 측정할 것인가, 누구의 길을 터 줄 것인가, 무엇으로 사고를 막을 것인가. 통제할 수 없는 변화의 속도를 좇기보다, 측정과 인재와 가드레일이라는 통제 가능한 레버에 집중하는 편이 현실적이다. 경계가 흐려지는 시대에 조직이 붙잡을 수 있는 것은 결국 그 세 가지다.