DevAI: 하이프와 부정 사이

게시일: 2025년 11월 15일 | 원문 작성일: 2025년 10월 30일

작성일: 2025년 10월 30일 | 원저자: Ivan Kusalic (CTPO) | 원문 보기

두 진영, 같은 착각

”AI로 엔지니어를 10배 생산적으로 만들 수 있어요.” 기술을 모르는 CEO가 수백만 전문가들이 못 푼 걸 자기가 풀었다고 확신하며 말하죠.

”AI는 별거 없어요, 1년 전에 써봤는데 말도 안 되는 실수를 하더라고요.” 수석 엔지니어가 모래에 머리를 박기 직전에 하는 말이에요.

두 진영이 있어요. 매주 다른 회사에서 같은 대화가 벌어지죠. 양쪽 다 자기가 맞다고 확신해요. 그리고 양쪽 다 실제로 무슨 일이 일어나는지는 무시하고 있어요.

저는 지난 몇백 시간을 AI와 함께 코딩하면서 보냈어요. Executive-Coder Experiment 이후에도 계속했죠 - 더 복잡한 시스템, 더 어려운 문제들로요. 300명 규모의 엔지니어링 부서를 이끄는 CTPO로서 대규모 AI 도입도 추진했어요.

AI가 어디서 도움이 되고, 어디서 실패하는지, 그리고 왜 양쪽 진영 모두 핵심을 놓치고 있는지 배운 걸 공유해볼게요.

소프트웨어 개발 파이프라인 문제

핵심적인 오해는 코드 산출량과 비즈니스 가치를 혼동하는 거예요.

소프트웨어 개발을 코딩으로 생각하기 쉬워요. 저도 제일 먼저 떠오르는 게 그거거든요. 코드 작성은 엔지니어들이 좋아하는 것이고 비즈니스가 우리가 하루 종일 하는 거라고 생각하는 것이죠. 하지만 소프트웨어 제품 개발엔 더 많은 게 있어요.

전체 소프트웨어 개발 생명주기(SDLC)가 있죠: 요구사항, 계획, 설계, 구현, 검증, 배포, 운영. 이걸 의도적으로 건너뛰면 프로토타입이나 MVP를 만드는 거예요. 하지만 진짜 고객이 제품에 의존하기 시작하면 이 모든 활동이 필요해져요.

개발자들이 쓰는 GenAI(“DevAI”라고 부를게요)는 더 많은 코드를 생산하게 도와줘요. 그래서 불행히도 AI가 별로 도움이 안 되는 다른 활동들이 있다는 게 문제죠.

소프트웨어 전달을 조립 라인으로 생각해봐요. AI가 코딩이라는 한 스테이션을 슈퍼차저로 만들어서 10배 더 많은 부품을 쏟아내요. 좋은 것 같죠?

근데 조립 라인은 그렇게 작동하지 않아요. 부품들이 다음 스테이션에 쌓여요: 검증, 배포, 운영. 한편 코딩 스테이션은 상류의 요구사항과 설계 결정을 기다리며 놀고 있죠. 라인은 가장 빠른 스테이션이 아니라 가장 느린 스테이션의 속도로 움직여요.

이게 파이프라인 문제예요. 우리가 코드 산출량을 아무리 늘려도 가치 생성은 SDLC의 다른 단계들에서 병목이 생겨요. 가치는 고객이 실제로 기능을 쓸 때만 생성되거든요.

어떤 사람들은 10배 또는 100배 생산성을 외쳐요. 거기 어느 정도 진실이 있을 수 있어요. 엔지니어가 실제로 10배 더 많은 코드를 생산할 수 있으니까요. 하지만 고객을 위한 가치의 큰 개선 없이 이건 허영 지표예요.

저는 AI와 vibe-coding으로 만든 20,000줄짜리 프로젝트를 버리고 처음부터 다시 시작한 적이 있어요. 그런 경험을 공유하는 사람은 별로 못 봤죠. “삭제한 LOC”는 사람들이 듣고 싶어하는 자랑거리 지표가 아니더라고요.

다른 사람들은 개선이 전혀 없고 AI가 산업을 망치고 있다고 냉소적으로 응수해요. 여기도 진실의 씨앗이 있어요. 다른 활동을 무시하고 더 많은 코드만 생산하면 코드베이스가 썩고 빠르게 마이너스 경제적 가치를 만들어내거든요.

불행히도 파이프라인 문제는 시작일 뿐이에요.

복잡도 세금

우리의 가장 강한 엔지니어 중 한 명이 9개월 동안 새 프로젝트를 작업했어요. 그는 수년간 고급 툴링과 AI 조정 워크플로우로 DevAI를 써왔죠. 초기엔 믿을 수 없을 정도로 생산적이었어요.

하지만 시간이 지나면서 느려졌어요. 6개월쯤 되니 뭐가 어디 구현되어 있는지 몰랐죠. 새 기능을 추가하는 게 질주하는 게 아니라 기어가는 것처럼 느껴졌어요. 새 프로젝트에 합류할 기회가 생기자 뒤돌아보지 않고 뛰어들었어요.

이게 DevAI가 타임라인을 압축한다는 걸 보여줘요.

위쪽: 전통적 개발 | 아래쪽: AI 사용 개발 | 🟢 Greenfield   🟡 Maturing   🔴 Legacy

모든 코드베이스는 같은 궤적을 따라가요: greenfield(새 프로젝트)에서 legacy(레거시)까지요. 깨끗한 greenfield 프로젝트는 성배처럼 여겨지고, 레거시 코드베이스는 우울증을 유발하죠.

• Greenfield: 최소한의 제약이나 기술 부채로 빠른 개발과 실험에 집중하는 깨끗한 새 코드베이스
• Maturing: 여전히 기능이 활발히 추가되지만 안정성과 유지보수성이 우선순위가 되면서 개발이 느려지는 성장하는 시스템
• Legacy: 문제와 복잡성이 도사리는 오래된 코드베이스로, 변경이 위험하고 상당한 리팩토링 없이는 피하게 되는 상태

여기 두 진영이 동의하지 않는 이유가 있어요. 100배 생산성을 말하는 사람들은 종종 greenfield 프로젝트를 작업해요. 신혼여행 단계에 있는 거죠. 코드베이스가 단순하고 깨끗해서 AI가 5000줄의 코드를 추가하는 동안 좋아하는 따뜻한 음료를 홀짝이면서 여유롭게 일할 수 있어요.

이렇게 해서 저는 수석 엔지니어가 진지한 얼굴로 AI로 60배-120배 더 생산적이라고 말하는 걸 듣게 되는 거예요. 그러다가 갑자기 아니게 되죠.

불행히도 코드베이스는 불가피하게 레거시가 돼요. 새 기능 추가가 기하급수적으로 어려워지죠. 회의론자들은 레거시 시스템에서 살아왔어요. 작은 변경도 프로덕션 장애를 일으킬 수 있어서 스트레스가 극심한 곳이죠.

새 기능 추가는 복잡성을 추가해요. 변경은 시간 여유를 가지고 거의 이루어지지 않아서 대충 넘어가는 것들이 축적돼요. 생산성이 떨어지죠. DevAI로는 무서운 속도로 greenfield에서 legacy로 치달아요. 건물이 노화되는 타임랩스 영상 같아요. 보통 수십 년 걸리는 것들(마모의 느린 축적, 패치 위의 패치, 아무도 더 이상 이해하지 못하는 시스템)이 이제 몇 달 만에 일어나요.

이 가속화된 부패는 단지 양에 관한 것만이 아니에요 - AI가 생성하는 것의 품질에도 관한 거예요.

품질 문제

저는 AI에게 HTTP 리디렉션을 처리하라고 했어요. 버그를 고칠 수 없게 되자 curl로 쉘 아웃(외부 명령어를 실행)하기 위해 별도 프로세스를 생성했어요. 간단한 HTTP 클라이언트 버그가 외부 의존성과 취약한 프로세스 관리를 가진 보안 위험으로 바뀐 거죠. 후…

품질 문제가 실제로 어떻게 나타나는지 보여주는 사례예요.

우리가 고객 대면 기능에 GenAI를 직접 쓸 때는 품질을 검증하기 위해 테스트와 평가를 작성해요. 불행히도 DevAI를 쓸 때는 그에 상응하는 게 없어요. 코드는 한 번 생성되고 간단한 코드를 받을지 복잡한 코드를 받을지, 보안을 의식한 코드인지 취약한 코드인지, 성능이 좋은지 비효율적인지는 주사위 굴리기예요.

어떤 사람들은 AI 생성 코드 품질에 감동받아요. 다른 사람들은 실망하죠.

깊은 경험이 없는 개발자들이 종종 가장 감동받아요. 그게 문제죠. 미묘한 문제를 발견하는 패턴 인식이 부족해요: tight coupling(강한 결합), 관심사 분리 부족, 보안 허점. AI 출력이 깨끗해 보이고 작동하니까 좋은 거라고 생각해요.

경험 많은 엔지니어는 더 세밀한 관점을 가져요. 모든 코드가 동등하게 만들어지지 않는다는 걸 알죠. 코드베이스의 어떤 부분은 집착적으로 최적화해야 하고 다른 부분은 그냥 작동하면 돼요. 훌륭한 엔지니어는 목적에 맞을 때 평균적인 코드를 쓰는 걸 기꺼이 해요. 그리고 언제 안 맞는지 알아차릴 수 있죠.

문제는? DevAI는 차이를 모른다는 거예요.

실제 사례들

앞서 언급한 curl 우회 사례처럼 이런 문제들은 공통된 패턴이 있어요:

• APNs 아키텍처 재앙: AI는 Expo 모바일 앱이 APNs credential(자격증명)에 직접 접근할 수 없다고 주장하고 제3자 서비스를 통해 알림을 라우팅하라고 고집했어요. 몇 주 후 AI가 틀렸다는 걸 발견했죠. 직접 접근이 완벽하게 작동했어요. 완전히 불필요한 인프라 레이어 전체를 구축했던 거예요. 더 비싸고, 덜 안전하고, 덜 성능 좋게요. AI가 존재하지 않는 제약을 만들어냈기 때문이에요
• 테스트 삭제: AI는 여러 시도 후에도 실패하는 단위 테스트를 고칠 수 없었어요. 해결책은? 실패하는 모든 테스트를 삭제하는 거였죠. 그리고 보너스로 많은 관련 없는 통과하는 테스트들도요. 문제 해결!

AI는 문제를 올바르게 해결하는 게 아니라 문제를 사라지게 만드는 걸 최적화해요. DevAI와 작업한다는 건 이런 나쁜 결정들을 계속 잡아내는 거예요: 잘못된 추상화, 불필요한 복잡성, 작동하는 데모 뒤에 숨어있는 보안 허점. 놓치면 눈덩이처럼 불어나요. 빠르게요.

버릴 코드를 만드는 게 아니라면 “어떻게든 작동해”는 충분하지 않아요. DevAI 출력을 그냥 받아들이는 건 몇 주 만에 레거시 상태로 질주하고 겨우 작동하는 스파게티 코드 덩어리로 끝나는 확실한 방법이에요.

지식 결핍

지난달 제 코드베이스에서 아름다운 커맨드 패턴 추상화를 발견했어요. 완벽한 관심사 분리. 우아한 미들웨어. 컨퍼런스 발표에서 자랑할 만한 코드죠. 10분 동안 쳐다보며 왜 존재하는지 기억하려고 했어요.

그러다가 깨달았어요: 필요가 없었어요. 전체 추상화, 그러니까 수백 줄의 화려하고 과도하게 엔지니어링된 코드가 존재하지 않는 문제를 해결했던 거죠. AI와 저는 몇 주 전에 커밋할 때마다 하이파이브하며 구현하는데 몇 시간을 보냈어요. 이제 우리가 뭘 해결하려고 했는지조차 기억이 안 나요.

아. 삭제. 커밋. 푸시. 일주일치 “생산성”이 사라졌네요.

DevAI와 함께하면 그 미치광이가 훨씬 빨리 도착해요. 그리고 더 화나서요. AI가 생성할 때 겨우 이해했던 그 코드? 다음 주에 디버깅할 때 고생하게 될 거예요. AI가 추가한 그 똑똑한 추상화? 새벽 2시에 프로덕션을 터뜨리면 과거의 당신과 AI를 저주하게 될 거예요.

버그를 고려하면 생산성 계산이 잔인해져요. 10배 더 많은 코드는 10배 더 많은 버그를 의미해요. 80%를 작성하고 20%를 버그 수정하는 데 쓰던 엔지니어? 이제 AI로 30%를 작성하고 70%를 버그 수정하는 데 써요. 슬프게도 디버깅을 자기 일의 하이라이트로 생각하는 엔지니어는 거의 없어요.

하지만 문제는 더 깊게 파고들어요: 이해의 상실.

멘탈 모델의 부재

AI가 코드를 작성하면 코드베이스의 멘탈 모델을 만들지 못해요. 수동으로 코드를 작성할 때는 변수 이름 짓기, 라이브러리 함수 선택, 로직 구조화 결정, 중첩 깊이 결정에 시간을 보내요. 실제 타이핑은 “코드 작성” 시간의 일부일 뿐이에요. 이 모든 미세 결정들이 이해를 만들어내요. 머릿속에서 코드를 최적화하는 데 쓰는 시간이죠.

GenAI를 쓰면 그 시간이 사라져요. AI가 그 결정들을 해요. 그리고 물리적으로 코드와 함께 보내는 시간이 훨씬 줄어들어요. 제 경우는 20분의 1로 줄었어요. 100줄을 쓰는 것과 2000줄을 쓰는 것의 차이는 책을 신중하게 읽는 것과 대충 훑는 것의 차이예요.

결과는 예측 가능해요: 코드베이스에 대한 얕은 이해.

새 greenfield 프로젝트에선 큰 문제가 아니에요 - 아직 거기 많은 게 없으니까요. 하지만 코드베이스가 커지면 차이가 극심해져요. 어떤 추상화가 존재하고 어디 있는지 잘 기억나지 않아요. 디버깅이 더 어려워지고 재사용이 떨어지고 중복이 치솟아요.

계속 새 코드베이스에 온보딩되는 것처럼 느껴져요. 실제로 그러니까요. 몇 달 동안 작업했을 수도 있지만 이해는 몇 주 작업한 신입만큼 얕아요.

이게 코드베이스 부패를 가속화해요. 레거시로 더 빨리 치달아요.

작업에 맞는 도구 선택하기

지난주에 인증 로직을 추가해야 했어요. 그건 손으로 작성했죠. 그걸 호출하는 API 엔드포인트들은? AI가 생성하고 리뷰했어요. 테스트 설정은? 순수 AI였어요. 같은 프로젝트, 다른 접근법이죠.

핵심은 올바른 작업에 올바른 도구를 선택하는 거예요. DevAI는 강력한 새 도구 상자를 줘요. 하지만 모든 상황에 같은 도구를 쓸 순 없잖아요. 애플리케이션의 가장 중요한 부분에 DevAI가 감독 없이 코드를 생성하게 해서도 안 돼요.

프로토타이핑의 힘

프로토타이핑이 DevAI가 진짜 빛나는 곳이에요. AI를 써서 빠르게 인사이트를 모으고 새 프로토타입을 만드는 건 훌륭해요. 결과에 빠져들어서 프로덕션 준비된 시스템으로 착각하지만 않으면요.

핵심은 선택에 대해 의도적이 되는 거예요. 속도가 지속가능성보다 중요할 때 DevAI를 써서 질주하세요. 장기적으로 만드는 게 아닐 때 장기 프로젝트인 척하지 마세요.

실제로 효과있는 것들

제게 효과가 있었던 것들이에요:

1. 명확한 요구사항부터 시작

AI에게 무엇을 만들지 더 잘 지시할수록 생성된 코드가 더 유용해요. 기능이 어떻게 보여야 하는지 명시하세요. 기술적 제약을 정의하세요. DevAI가 더 빠르게 더 많은 코드를 생산하니까 요구사항에 비례적으로 더 많은 시간을 투자하세요. 기억하세요: “며칠의 코딩이면 몇 분의 계획을 아낄 수 있다” (계획을 안 하고 코딩부터 하면 결국 더 오래 걸린다는 역설이죠). 대충 감으로 하지 마세요.

저는 이걸 어렵게 배웠어요. 모바일 앱 작업하면서 흥분해서 AI가 알림 전달을 관리하는 10,000줄짜리 괴물을 만들게 했죠. 끝날 때쯤엔 어떤 기능을 지원해야 하는지조차 몰랐어요. 20시간을 낭비했다는 건 알았죠. 한숨과 함께: git revert.

2. 코딩 전에 설계

무엇을 만들고 싶은지 정확히 알 때까지(그리고 AI를 위해 명확하게 윤곽을 그릴 수 있을 때까지) 설계 문서를 계속 다듬어요. 그런 다음 전체 SDLC를 커버하는 구현 계획에서 AI와 작업해요. 그래야 구현하죠.

예상하셨겠지만 - 또 다른 실패담이에요. 캘린더 서브시스템을 위한 시간 관리 기본 단위(primitive)를 만들면서 데이터 플로우를 명확히 하고 스토리지 시스템을 선택하고 심지어 Architecture Decision Record(ADR)도 작성했어요. 하지만 데이터 모델링에 대해서는 정확하지 않았죠. 고통스러운 재작업 시간들이 따라왔어요.

실전에서 얻은 또 다른 교훈: 백엔드와 모바일에 걸친 큰 기능을 만들었어요. 구현 계획을 만들었지만 단계가 너무 컸어요. 검증을 끝에 남겨뒀죠. 놀랍게도 조각들이 맞지 않았어요. 백엔드와 프론트엔드 간 공통 부분을 추출하고 둘 다 재작업해야 했어요.

3. 모듈화에 집착적으로 집중

교훈은? 모듈화에 집착적으로 집중하세요. 도메인 경계가 수정처럼 명확해야 해요. AI가 그것들을 존중하도록 가이드하세요. 강한 경계 없이 AI는 여러분이 풀 수 있는 것보다 빠르게 엉킨 난장판을 만들어내요.

4. 경험 많은 엔지니어 고용

AI를 가이드할 수 있는 경험 많은 엔지니어를 고용하세요. 그들은 언제 나쁜 제안을 무시할지, 언제 더 나은 추상화를 요구할지, 언제 손으로 코드를 작성할지 알아요. 경험 적은 엔지니어들이 더 나은 설계 결정을 하도록 도와주죠. 이게 우리에게 잘 작동해서 다행이에요.

하이프와 부정을 넘어서

수백 시간을 AI와 코딩하며 알게 된 것: 잘 해낼 엔지니어는 AI를 거부하거나 맹목적으로 받아들이는 사람들이 아니에요. 트레이드오프를 이해하는 사람들이에요. DevAI를 써서 언제 질주하고 언제 속도를 늦추고 직접 작업할지 아는 사람들이죠.

산출 향상은 진짜예요. 레거시로의 빠른 경로도 진짜고요.

DevAI는 더 빠르게 더 많은 코드를 생성하게 해줘요. 여러분의 결정이 더 빠르게 더 많은 부채를 만드는지, 더 빠르게 더 많은 가치를 전달하는지를 결정해요.