최근 AX 직무 면접을 보며 느낀 이야기 - 개발자가 없는 개발팀

최근 AX 직무 면접을 보며 느낀 이야기 - 개발자가 없는 개발팀

최근 AX(AI Transformation) 관련 포지션의 면접을 여러 차례 경험했습니다.

기업마다 AX를 정의하는 방식은 조금씩 달랐지만, 면접을 거듭할수록 비슷한 이야기를 반복해서 듣게 되었습니다.

• AI를 적극적으로 활용합니다.
• 최대한 빠르게 제품을 만듭니다.
• 한 사람이 하나의 제품을 책임집니다.
• 가능하면 한 달 안에 결과물이 나와야 합니다.

그리고 어떤 조직에서는 코드 품질이나 협업 방식은 현재 중요한 문제가 아니라고 이야기하기도 했습니다.

처음에는 단순히 개발 방식의 차이라고 생각했습니다.

하지만 비슷한 이야기를 계속 듣다 보니 한 가지 의문이 생겼습니다.

"AI를 이용해 제품을 빠르게 만드는 것과, 그 제품을 몇년동안 유지하고 운영하는 것은 같은 문제일까요?"

저의 대답은 그렇지 않다는 쪽에 가깝습니다.

---

개발자가 없는 AX팀의 AI-Native 개발자

한 면접에서는 다음과 같은 대화를 나눴습니다.

면접관: "우리 AX팀은 AI-Native 개발자들입니다."
나: "개발자 출신들로 이루어진 팀인가요?"
면접관: "비개발자들로 이루어져 있습니다."

이 이야기를 듣고 가장 먼저 떠올랐던 질문은 이것이었습니다.

개발자가 없는 개발팀에서 제품의 기술적인 품질은 누가 판단할까요?

물론 비개발자가 AI를 이용해 프로그램을 만드는 것 자체를 부정적으로 생각하지는 않으며 오히려 AI가 가져온 가장 큰 변화 중 하나라고 생각합니다.

기획자가 자신의 반복 업무를 자동화할 수 있고, HR 담당자가 간단한 사내 도구를 만들 수도 있습니다. 또는 마케터가 데이터를 분석하거나 업무용 애플리케이션을 직접 만들 수도 있습니다.

과거라면 개발자에게 요청해야 했던 많은 작업을 현업 담당자가 직접 해결할 수 있게 되었으며 이것은 분명한 발전입니다.

다만 저는 어디까지 AI에게 맡길 것인가는 구분해야 한다고 생각합니다. 문제는 PoC를 만드는 방식과 실제 제품을 만드는 방식을 동일하게 바라보기 시작할 때 발생합니다.

---

"코드 품질은 크게 생각하지 않습니다"

또 다른 면접에서는 다음과 비슷한 이야기를 들었습니다.

면접관 : "우리는 코드 품질에 대해서는 크게 생각하고 있지 않습니다."
면접관 : "1인 1제품을 담당합니다."
면접관 : "각각의 솔루션이 한 달 단위로 MVP가 나와야 합니다."
면접관 : "사실상 협업은 하지 않습니다."

빠른 실험이 목적이라면 이러한 방식에도 분명 장점이 있습니다.

• 의사결정이 빠릅니다.
• 회의가 줄어듭니다.
• 코드 리뷰를 기다릴 필요도 없습니다.
• 한 사람이 제품 하나를 빠르게 완성할 수 있습니다.

문제는 PoC가 Product가 되었을 때 입니다.

처음에는 "일단 빠르게 만들고, 잘되면 그때 정리하면 되지 않을까?" 하고 생각할 수 있습니다.

하지만 실제 사용자가 생기고 업무가 그 시스템에 의존하기 시작하면 이야기가 달라집니다.

그때부터 기존 코드를 다시 만드는 것은 더 어려워지며 결국 빠르게 만들어 놓았던 코드 위에 새로운 기능이 계속 추가되기 시작합니다.

---

처음에는 AI가 정말 잘합니다

AI-Native 개발의 위험성을 이야기하기 전에 한 가지는 분명히 하고 싶습니다.

초기 개발에서는 AI가 정말 잘합니다.

화면을 만들어 달라고 하면 만들어 주고, API를 작성해 달라고 하면 작성해줍니다. 또한 데이터베이스를 연결해 달라고 하면 연결하고, 기존 로직을 변경해 달라고 하면 관련 코드를 찾아 상당히 그럴듯하게 수정합니다.

이 때문에 초기 몇 달 동안은 굉장한 생산성 향상이 나타날 수 있습니다.

과거에 일주일 걸렸던 작업이 하루 만에 끝나며, 한 명이 여러 명의 개발자가 하던 일을 수행합니다.

그래서 조직 입장에서는 "개발자가 없어도 되는 것 아닌가?" 하고 생각하기 쉽습니다.

제가 우려하는 것은 바로 그다음부터입니다.

---

문제는 제품이 계속 변경된다는 것입니다

예를 들어 A라는 파일이 있다고 가정해 보겠습니다.

A에는 약 1,000줄의 코드가 들어 있습니다.

처음에는 정상적으로 사용하던 핵심 로직입니다.

시간이 지나 요구사항이 변경됩니다.

사용자는 AI에게 요청합니다.

"OO 기능들이 사용하는 A에 있는 이 로직을 새로운 방식으로 변경해줘."

AI는 코드를 분석합니다.

그리고 새로운 B 파일을 만들어 변경된 로직을 구현합니다.

연관된 코드 일부도 B를 바라보도록 수정합니다.

여기까지는 문제가 없어 보입니다.

그런데 A 파일이 완전히 사라진 것은 아닙니다.

일부 코드는 여전히 다른 곳에서 사용하고 있습니다.

일부 코드는 B로 대체되면서 더 이상 사용되지 않습니다.

또 일부 코드는 사용 중인지 아닌지 바로 판단하기 어려울 수 있습니다.

다시 몇 달 뒤 요구사항이 변경됩니다.

AI에게 다시 수정해 달라고 합니다.

이번에는 C가 만들어집니다.

다시 변경되면 D가 생깁니다.

또 변경되면 E가 생길 수도 있습니다.

새로운 코드는 계속 생깁니다. 또한 과거의 코드가 항상 완벽하게 사라지지 않을 수 있습니다.

개발자가 AI가 만든 코드에 대해서 리뷰를 한다면 이러한 문제점은 커지기 전에 찾을 수 있겠지만, 비개발자는 코드를 읽을줄 모르기에 이상한점을 알 수 없습니다.

AI로 리뷰를 하더라도 A의 남아있는 로직은 일부 기능에서 필요하다고 판단되기에 이 코드 또한 문제 없다고 판단합니다.

여기서부터 문제가 시작됩니다.

---

1,000줄 중 300줄만 사용한다면 A는 사용 중인 파일일까요?

A 파일이 1,000줄이라고 가정하겠습니다.

그중 700줄은 더 이상 사용되지 않습니다.

300줄은 실제 시스템에서 호출되고 있습니다.

그렇다면 A는 사용 중인 파일일까요?

기술적으로는 그렇습니다. 300줄이 사용되고 있기 때문에 파일 전체를 삭제하면 문제가 발생할 수 있습니다.

그런데 상황을 조금 바꿔보겠습니다.

그 300줄 역시 사실은 이미 B의 새로운 비즈니스 로직으로 변경되어야 했던 과거 코드라고 가정해 보겠습니다.

다른 코드가 아직 A를 바라보고 있기 때문에 실행되고 있을 뿐입니다.

이제 이야기가 달라집니다.

이 상황에서 중요한 차이가 하나 생기는데, 참조되고 있는 코드와 필요한 코드는 같은 의미가 아니라는 것 입니다. 코드가 실행된다고 해서 올바른 코드라는 보장은 없습니다.

반대로 코드에서 직접 사용 흔적이 잘 보이지 않는다고 해서 반드시 삭제해도 된다는 의미도 아닙니다.

실제 시스템에서는 설정이나 프레임워크, 외부 시스템과의 연결 때문에 예상하지 못한 방식으로 코드가 사용될 수도 있습니다.

결국 중요한 것은 단순히 "이 코드가 호출되고 있는가?"가 아니라, "이 코드가 현재 비즈니스 규칙에서 여전히 존재해야 하는가"를 판단하는 것입니다.

---

코드를 만드는 것은 쉬워졌지만, 무엇을 지워도 되는지는 쉬워지지 않았습니다

저는 이 지점이 AI-Native 개발에서 굉장히 중요하다고 생각합니다.

AI에게 새로운 기능을 만들어 달라고 하는 것은 점점 쉬워지고 있으며, 반대로 이미 쌓여 있는 코드 중 무엇을 없애도 되는지 판단하는 것은 여전히 어렵습니다.

오히려 시스템이 커질수록 더 어려워지며 어느 순간 "사용하지 않는 코드와 중복된 파일을 전부 정리해줘."와 같은 요청을 하게 될 수도 있습니다.

새로운 기능 하나가 잘못되었다면 해당 기능을 다시 수정하면 되지만, 기존 코드를 잘못 삭제하면 전혀 예상하지 못했던 기존 기능이 깨질 수 있습니다.

더 큰 문제는 테스트와 명세가 충분하지 않은 경우입니다. A, B, C, D가 모두 존재하고 각각 일부 코드에서 사용되고 있다면 AI는 결국 현재 존재하는 코드와 주변 정보를 보고 판단해야 합니다.

그런데 코드 자체가 이미 여러 세대의 비즈니스 로직이 뒤섞인 상태라면 어떤 것이 진짜 기준일까요?

---

AI에게도 결국 진실의 기준(Source of Truth)이 필요합니다

예를 들어 이런 상태라고 생각해 보겠습니다.

A, B, C는 모두 실행되며 컴파일도 됩니다.

그렇다면 AI에게 "잘못된 코드를 정리해줘." 라고 요청했을 때 무엇을 기준으로 판단해야 할까요? 결국 기준이 필요합니다.

현재 요구사항이 무엇인지, 어떤 비즈니스 규칙이 맞는지, 어떤 동작을 반드시 유지해야 하는지, 어떤 기능은 이미 폐기되었는지를 알아야 합니다. 즉 코드만으로는 부족합니다.

명세, 테스트, 문서, 변경 이력, 운영 정책과 같은 기준이 필요합니다.

그리고 누군가는 AI가 내린 판단이 정말 맞는지도 검증해야 합니다.

---

그래서 "사용하지 않는 코드를 정리해 줘"도 간단하지 않습니다

이제 코드가 너무 복잡해졌다고 생각해 AI에게 다음과 같이 요청했다고 가정해 보겠습니다.

"사용하지 않는 코드와 중복된 파일을 전부 정리해줘."

AI는 현재 코드의 참조 관계와 주변 맥락을 분석합니다.

그리고 B.java가 최신 정책을 구현한 코드라고 판단합니다.

A.java에는 과거 정책이 남아 있고, 상당 부분이 B로 대체되었다고 판단하여 A를 제거합니다.

작업도 정상적으로 완료된 것처럼 보입니다.

그런데 배포한 뒤 기존에 정상적으로 동작하던 OO 기능이 동작하지 않습니다.

알고 보니 해당 기능의 일부가 여전히 A의 코드를 사용하고 있었습니다.

사용자는 다시 AI에게 이야기합니다.

"아니, 사용하지 않는 코드를 정리하라고 했는데 이번 작업 이후 OO 기능이 안되잖아."

AI는 변경 이력을 확인하고 A를 다시 복구합니다.

기능은 다시 정상적으로 동작합니다.

그런데 사용자의 원래 목적은 여전히 해결되지 않았습니다.

A에는 사용하지 않는 코드가 많이 남아 있기 때문입니다.

여기서부터 문제가 반복될 수 있습니다.

이 사례에서 중요한 것은 AI가 무능해서 잘못 판단했다는 것이 아닙니다.

AI 입장에서는 상당히 합리적인 판단을 했을 수도 있습니다.

A에는 과거 정책이 존재하며, B에는 최신 정책이 존재합니다. 그렇다면 A는 제거 대상처럼 보일 수 있습니다.

하지만 실제 시스템에서는 일부 기능이 여전히 A를 호출하고 있었습니다. 그렇다고 A를 그대로 유지하는 것도 정답은 아니게 됩니다. A 안에는 정말로 필요 없는 코드가 많이 남아 있기 때문입니다.

결국 문제는 "A를 삭제할것인가, 유지할것인가?"가 아니라, "A의 어느 부분은 현재도 반드시 필요하고, 어느 부분은 이미 폐기되어야 하며, 현재 사용 중인 코드 중에서도 잘못된 과거 정책을 사용하는 부분은 어디인가?"를 판단해야 합니다.

이것은 훨씬 어려운 문제입니다.

특히 시스템에 명확한 Source of Truth가 없다면 AI는 현재 존재하는 코드와 호출 관계를 다시 근거로 판단할 수밖에 없습니다.

그런데 바로 그 코드와 호출 관계가 이미 여러 차례의 AI 수정으로 뒤섞여 있는 상태라면 판단의 기준 자체가 흔들립니다.

그래서 다음과 같은 상황이 만들어질 수 있습니다.

A.java 삭제
    ↓
기존 기능 장애
    ↓
A.java 복구
    ↓
불필요한 코드는 다시 살아남음
    ↓
다시 정리 요청
    ↓
또 다른 영향 범위 분석
    ↓
삭제와 복구 반복

처음에 AI를 사용한 이유는 사람의 개발 비용을 줄이기 위해서였습니다.

그런데 이러한 상태까지 코드가 누적되면 새로운 코드를 만드는 비용보다 무엇을 지워도 되는지 확인하는 비용이 더 커질 수 있습니다.

결국 필요한 것은 현재 비즈니스 규칙을 명확하게 정의한 기준과 테스트, 그리고 변경 결과가 올바른지 판단할 수 있는 엔지니어링 역량입니다.

---

AI Slop은 코드베이스에서도 생길 수 있습니다

저는 이런 현상을 코드의 AI Slop이라고 볼 수도 있다고 생각합니다.

AI Slop이라고 해서 반드시 코드 한 줄 한 줄이 형편없다는 의미는 아닙니다. 오히려 각각을 보면 정상적으로 동작할 수도 있습니다.

문제는 그것들이 계속 누적된 결과입니다.

이 작업이 수십 번, 수백 번 반복되면 코드베이스 안에는 여러 시점의 진실이 동시에 존재하게 됩니다.

처음에는 새로운 기능을 빠르게 만드는 것이 생산성처럼 보였으나 시간이 흐르면서 이제 새로운 기능 하나를 변경하기 위해 기존에 어떤 코드가 살아 있는지부터 확인해야 합니다.

결국 과거에 아낀 시간이 미래의 검증 비용으로 돌아갑니다.

---

개발자들은 이미 오래전부터 이 문제와 싸워왔습니다

사실 이런 문제는 AI가 등장하면서 처음 생긴 것은 아닙니다.

Dead Code, Legacy Code, Spaghetti Code, Technical Debt, Regression, Knowledge Silo 같은 문제는 소프트웨어 업계가 수십 년 동안 경험해 온 문제입니다.

그래서 개발 조직은 여러 가지 안전장치를 만들어 왔습니다.

위험	일반적으로 사용하는 방법
잘못된 코드 변경	Code Review
기존 기능 파괴	Automated Test
큰 변경의 위험	작은 단위의 점진적인 변경
변경 이력 확인	Git / Version Control
코드 품질 문제	Static Analysis / Quality Gate
배포 오류	CI/CD
운영 중 문제 확인	Logging / Monitoring / Tracing
설계 의도 소실	문서 / ADR
특정 개인에게만 지식 집중	Review / 협업 / Shared Ownership

또한 AI 개발이 들어서며 바이브 코딩, 컨텍스트 엔지니어링, 스펙주도개발, 하네스엔지니어링, 루프엔지니어링과 같은 방법론들이 계속해서 나타나고 있습니다. 

이런 방법들이 존재하는 이유는 개발자가 보수적이어서가 아닙니다.

소프트웨어가 커질수록 개인의 기억과 판단만으로 시스템을 안전하게 유지하기 어렵다는 경험이 축적되었기 때문입니다.

중요한 것은 개발자가 완벽하다는 이야기가 아닙니다. 오히려 개발자도 실수하기 때문에 여러 사람이 검토하고, 테스트하고, 자동화하고, 기록하는 구조를 만들어 온 것입니다.

---

그런데 일부 AX 조직에서는 그 안전장치를 병목으로 바라봅니다

제가 최근 몇몇 AX 면접에서 가장 우려했던 부분도 여기에 있습니다.

• 리뷰를 하지 않습니다.
• 협업하지 않습니다.
• 각자 하나의 제품을 담당합니다.
• 코드 품질보다는 빠른 속도로 제품이 나오는 것이 중요합니다.

이러한 것은 단기적인 성과라는 관점에서는 굉장히 효율적으로 보일 수 있습니다. 특히 요즘처럼 AX와 혁신이라는 키워드로 진행되는 사내 AX 프로젝트들은 더더욱 그렇습니다.

하지만 이렇게 생각해 볼 필요가 있습니다.

리뷰를 제거하면 리뷰에 걸리는 시간은 사라집니다.

그런데 잘못된 코드가 들어갈 가능성도 함께 사라질까요?

테스트를 줄이면 테스트 작성 시간은 줄어듭니다.

그런데 기존 기능이 깨질 가능성도 함께 줄어들까요?

문서를 만들지 않으면 문서 작성 시간은 사라집니다.

그런데 담당자가 퇴사했을 때 시스템을 이해하는 비용도 사라질까요?

결국 병목을 제거한 것이 아니라 미래로 미루는 겁니다.

---

빠른 개발의 비용은 당장 보이지 않습니다

이것이 기술 부채가 위험한 이유입니다. 기술 부채는 코드를 작성한 당일에는 거의 보이지 않습니다.

• 서비스는 정상적으로 실행됩니다.
• 화면도 잘 나옵니다.
• 사용자도 기능을 사용할 수 있습니다.

그래서 성공한 것처럼 보입니다.

하지만 요구사항이 계속 변경되면서 비용이 나타나기 시작합니다.

아이러니하게도 처음에는 가장 빠르게 개발했던 조직이 몇 년 뒤에는 하나의 기능을 변경하는 데 가장 많은 시간이 필요한 조직이 됩니다.

---

개발자가 없는 AX 개발팀의 한계는 '코딩 능력'이 아닙니다.

여기서 제가 이야기하고 싶은 핵심이 있습니다.

비개발자가 코드를 직접 작성할 수 없어서 문제라고 생각하는 것이 아닙니다. 이제 상당 부분은 AI가 작성할 수 있습니다.

제가 더 중요하게 생각하는 차이는 무엇을 의심해야 하는지를 아는가입니다. 이러한 것은 기본적으로 개발과 여러 CS 지식들이 합쳐지며 의문이 나타날 수 있으며, 이는 비개발자의 한계이기도 합니다.

프로그램이 정상적으로 동작한다고 해서 모든 것이 끝난 것은 아닙니다.

숙련된 개발자는 기능을 만들면서 동시에 다른 질문을 합니다.

• 이 기능이 어떤 상황에서 실패할 것인가?
• 기존 기능에 영향을 받는가?
• 잘못된 데이터가 들어오면 어떻게 처리하는가?
• 동시에 여러 요청이 오면 어떻게 되는가?
• 데이터가 날라가거나 갑작스러운 서비스 장애가 발생하면 어떻게 파악하고 대처할 것인가?
• 이 코드가 몇 년뒤에도 확장이 가능한 구조인가?

이런 질문들은 프로그래밍 언어의 문법을 많이 안다는 의미와는 조금 다릅니다.

여러 번의 변경, 장애, 운영, 유지보수를 경험하고 지속적으로 CS에 대한 공부를 하면서 생기는 사고방식에 더 가깝습니다.

그래서 저는 개발자가 없는 개발팀의 가장 큰 위험이 만들어진 코드가 언제 위험해지는지 알아차리지 못하는 것이라고 생각합니다.

---

AX 조직 자체가 문제라는 의미는 아닙니다

최근 경험했던 몇몇 AX 조직은 기존 개발 조직과 별도로 구성되어 있었고, C-Level 직속 조직으로 빠르게 만들어진 경우들도 있었습니다.

C-Level 직속 조직 자체가 잘못되었다고 생각하지는 않습니다. 오히려 AX처럼 전사적인 변화가 필요한 조직에서는 강한 의사결정 권한이 도움이 될 수도 있습니다.

제가 우려하는 것은 다른 부분입니다.

조직 안에서 기술적 의사결정을 견제할 사람이 없는 경우입니다.

리더도 개발 경험이 없습니다.

팀원도 개발 경험이 없습니다.

리더가 개발 경험이 있더라도 팀원들이 개발을 모르기에 기술적 리딩은 불가능 합니다. 개발에 대한 커뮤니케이션도 불가능합니다. 개발팀이지만 개발을 모르기에 기술적 용어는 되도록 사용하지 않아야 하며 쉽게 설명해주어야 합니다.

리뷰하는 사람도 없습니다.

기존 개발 조직과 교류도 거의 없습니다.

그러면서 실제 운영 제품을 계속 만들어야 합니다.

이러한 구조에서는 "이렇게 하면 특정 상황에서 문제가 생길 수 있습니다." 라고 이야기할 사람이 없어집니다.

당장 제품이 동작한다면 이러한 기술적인 의문은 쉽게 후순위로 밀리게 됩니다. 당연히 이러한 상황에서의 문제는 몇 년뒤 서서히 찾아오게 됩니다. 하지만 그 때쯤이면 이미 수없이 쌓인 AI Slop에 의해 오히려 새로 개발하는게 더 빠를 것 입니다.

---

AX의 KPI가 '몇 개 만들었는가'만 되어서는 안 됩니다

AX 조직은 빠르게 성과를 증명해야 한다는 압박을 받기 쉽습니다. 그래서 다음과 같은 지표가 중요해질 수 있습니다.

• 이번 분기에 몇 개의 제품을 만들었는가?
• 단기간에 얼마나 많은 문제를 해결하고 있는가?
• 직원들이 AI를 얼마나 많이 사용했는가?

이 역시 필요한 지표입니다. 위와 같은 지표만을 본다면 AI가 만든 결과물이 엄청난 것으로 보이고, 성과도 잘 나오며, 단기적으로 봣을 때 당장 엄청난 아웃풋이 나오기에 성공적인 것처럼 보일 수 있습니다.

하지만 저는 장기적인 AX라면 다른 질문도 함께 해야 한다고 생각합니다.

• 만들어진 시스템 중 6개월 뒤에도 실제로 사용되는 것은 몇 개인가?
• 요구사항을 변경하는 데 얼마나 많은 시간이 필요한가?
• 담당자가 바뀌어도 다른 사람이 운영할 수 있는가?
• 장애가 발생했을 때 원인을 찾고 복구할 수 있는가?
• AI가 생성한 코드가 어떤 기준으로 검증되고 있는가?

AX의 성과를 아웃풋으로만 평가하면 새로운 제품은 계속 만들어지고 단기적으로는 좋은 성과를 낼 수 있습니다. 하지만 조직 안의 기술 부채 역시 그보다 빠르게 증가하게 됩니다.

---

일부 AX 조직을 비관적으로 바라보는 이유

최근 AX 면접들을 경험하면서 제가 가장 우려했던 것은 AI 기술의 수준이 아니었습니다.

오히려 AI를 바라보는 방식이었습니다.

AI를 도입하면 개발 과정의 많은 부분을 단축할 수 있습니다. 이것은 사실입니다.

하지만 일부 조직에서는 여기서 한 단계 더 나아가 "AI가 있으니 기존 개발 방식은 필요하지 않다." 는 방향으로 가고 있다는 인상을 받았습니다.

저는 이것이 위험하다고 생각합니다.

AI는 코드를 만드는 비용을 크게 낮췄지만 문제는 코드 생성 비용이 낮아졌다고 해서 유지보수 비용까지 자동으로 낮아지는 것은 아니라는 점입니다.

오히려 검증 구조 없이 코드 생성량만 폭발적으로 증가한다면 기술 부채 역시 과거보다 훨씬 빠르게 증가할 수 있습니다.

---

AI-Native는 Developer-less가 아닙니다.

제가 AI-Native 자체를 부정적으로 바라보는 것은 아닙니다. 오히려 앞으로의 개발은 점점 더 AI-Native에 가까워질 것이라고 생각합니다.

AI가 코드를 작성하고, 테스트를 만들며, 코드 리뷰를 돕습니다. 또한 장애 로그를 분석하고 문서를 작성하며, AI AGent가 여러 작업을 나누어 수행할수도 있습니다.

개발자의 역할 역시 코드를 직접 입력하는 비중에서 점점 더 문제를 정의하고, 구조를 설계하고, AI에게 일을 나누고, 결과를 검증하고, 최종적인 품질을 책임지는 방향으로 이동하고 있습니다.

제가 생각하는 AI-Native는 AI를 이용해 소프트웨어 엔지니어링을 없애는 것이 아니라, 소프트웨어 엔지니어링을 더 빠르고 강하게 만드는 것입니다.

AI-Native는 Developer-less가 아닙니다.

---

마치며

처음의 질문으로 돌아가 보겠습니다.

비개발자들만으로 이루어진 AI-Native 개발팀이 장기간 제품을 만들고 운영할 수 있을까요?

저의 현재 대답은 부정적입니다.

• 개인 업무 자동화는 가능합니다.
• PoC도 가능합니다.
• 프로토타입도 가능합니다.
• 간단한 내부 도구도 충분히 만들 수 있습니다.

하지만 그 외의 목적으로 전사적으로 도입하는 솔루션이 되거나, 외부로 나가야 하는 솔루션이라면 분명히 한계를 느끼는 지점은 다가올것입니다. 

제품이 커지고, 중요한 비즈니스 로직이 들어가고, 수년 동안 요구사항이 변경되고, 여러 시스템과 연결되고, 실제 사용자의 업무가 그 시스템에 의존하기 시작하면 다른 문제가 됩니다.

그 순간부터 중요한 것은 "AI가 이 코드를 만들 수 있는가?" 가 아닙니다.

"현재 존재하는 코드 중 무엇이 맞고, 무엇이 잘못되었으며, 무엇을 없애도 되는지를 누가 판단할 수 있는가?"가 됩니다.

AI에게 A의 로직을 바꾸라고 해서 B를 만드는 것은 쉽습니다.

B를 다시 C로 변경하는 것도 쉽습니다.

D와 E를 만드는 것도 어렵지 않습니다.

하지만 수년 뒤 A, B, C, D, E가 뒤섞인 코드베이스에서 어떤 코드가 현재의 진실이고, 어떤 코드가 과거의 흔적이며, 어떤 코드를 삭제해도 되는지를 판단하는 것은 전혀 다른 문제입니다.

그래서 저는 AI 시대에 소프트웨어 엔지니어링이 덜 중요해지는 것이 아니라 오히려 더 중요해질 수 있다고 생각합니다.

코드를 만드는 것은 쉬워졌지만, 무엇을 지워도 되는지 판단하는 것은 쉬워지지 않았습니다.

참조되고 있는 코드와 필요한 코드는 같은 의미가 아닙니다.

그리고 결국, AI-Native는 Developer-less가 아니라 소프트웨어 엔지니어링을 AI로 가속하는 방향이어야 한다고 생각합니다.