최근 들어 이런 이야기가 들려옵니다. AI를 도입했는데도 생각만큼 생산성이 오르지 않는다고.

AI에 해박한 엔지니어도 있고, 경험 많은 SE(시스템 엔지니어)도 있습니다. 설계도 완벽하고, 꼼꼼하게 리뷰까지 해서 구멍이 없다고 합니다.

하지만 큰 문제가 발생합니다.

이번 글에서는,

AI 시대의 개발은 기존의 설계 및 개발 방식으로는 실패한다

는 내용을 설명하겠습니다.

그럼 결론부터 말씀드리겠습니다.

1. 기존의 설계 스타일을 버려라
2. 신입사원 같은 설계가 좋다

(오해 없으시도록 미리 말씀드립니다. 이것은 '지금 당장 모든 시스템을 다시 작성하라'는 이야기가 아닙니다. 기존 자산을 어느 정도까지, 어떻게 다룰지는 글 후반부에서 정리하겠습니다. 우선 원칙에 대한 이야기입니다.)

기존의 OOP(객체 지향 프로그래밍)와 결정적으로 다른 점들을 순서대로 풀어보겠습니다.

'기존 OOP적인 무겁고 장황한 방식을 버리고, AI가 읽기 쉬운 '신입 수준의 단순함'으로 재구축하는 것'이야말로 AI 시대 설계의 본질입니다.

신입사원의 코드(메인 메서드에 모든 것을 작성하는 스타일)는 AI에게 '컨텍스트의 보고'입니다.

• 암묵적인 전제가 없다: 어느 클래스의 멤버 변수가 어떻게 되어 있는지, 어느 곳의 상속 관계가 어떻게 되어 있는지 등 '사람이 기억해야만 하는 정보'를 추적할 필요가 없습니다. -
  흐름이 직관적이다: 위에서 아래로 흐르는 '이야기'처럼 읽을 수 있어, AI는 '다음으로 무엇이 일어날지'를 정확하게 예측할 수 있습니다. -
  수정이 국소적이다: 모든 것이 눈앞에 보이기 때문에, 수정으로 인한 '예상치 못한 영향(부작용)'이 발생할 위험이 적습니다.

숙련된 엔지니어의 설계는 이 '쉬운 이해도'를 희생시키면서 '재사용성'이라는 먼 미래의 이익을 쫓고 있습니다. 하지만, AI라는 '무한한 속도로 코드를 작성할 수 있는 파트너'가 존재하는 현대에 와서, 그 이익은 비용 대비 가치가 떨어지고 있습니다.

'기존 설계 스타일을 버린다'는 것은 구체적으로 다음 세 가지를 포기한다는 의미입니다.

• '재사용성'을 최우선으로 생각하는 것:

재사용을 위해 강하게 결합된 설계를 하는 것보다는, AI에게 같은 처리를 여러 번 시키는 것이 (지금의 AI라면) 더 안전하고 빠릅니다. 오해가 없도록 여기서 설명드리자면, 이는 AI로 시스템 개발의 대부분을 담당하도록 전제했을 경우이며, 기존 방식처럼 **'여전히 인간이 코드 개발의 주역'**이면서 AI에게 코드 생성 일부를 맡기고, 인간이 코드의 종류 선택을 하고 복사-붙여넣기한 AI 코드를 참고하여 제작하는 스타일과는 맞지 않습니다. 즉, 어디까지 AI의 코드 생성을 도입하느냐에 따라 설계 방식도 조직, 체제, 제조 공정까지 변화합니다. -
'은폐(캡슐화)'에 집착하는 것:

AI가 코드를 생성할 때, 관련 파일을 '컨텍스트 (Context, 문맥)'로서 읽어 들입니다. 의존 관계가 복잡한 코드(상태가 클래스 전체에 분산되어 있는 것)를 읽어 들이면, AI는 '어떤 변수가 어디서 변경되는가'를 추론하는 데 계산 리소스를 낭비하게 되며, 논리적인 실수(Hallucination, 환각)를 일으키기 쉬워집니다.

다만 일부 IDE에서는 코딩 에이전트가 grep이나 코드 검색 도구를 사용하여 필요한 부분만 스스로 찾아갈 수 있기 때문에, 이러한 제약은 해마다 완화되고 있습니다. 그렇다 하더라도 '찾아가는 수고와 오독의 리스크를 애초에 줄일 수 있다'는 의미에서, 응집도(Cohesion)를 높여두는 가치는 변하지 않습니다.

추론 능력의 국소화 (인지 부하의 경감)

AI가 메서드를 작성할 때, 해당 메서드의 입력과 출력만을 생각하면 되는 상태라면 정확도는 비약적으로 향상됩니다. 외부 상태에 의존하지 않는 '순수 함수 (Pure Function)'는 테스트 코드 생성, 에지 케이스 (Edge Case)의 망라, 그리고 문서 생성에 있어서도 AI가 가장 풀기 쉬운 '논리 퍼즐'이 됩니다. -
모듈성의 최대화

AI는 코드를 '패치워크 (Patchwork)'로서 조립하는 데 능숙합니다. 메서드가 독립되어 있다면, AI는 '이 기능이 필요하다'는 요청을 받았을 때 기존 코드베이스를 파괴할 리스크를 최소한으로 억제하면서 새로운 함수를 삽입하거나 교체할 수 있습니다.

기존의 OOP (객체 지향 프로그래밍) 설계 사상과 AI를 전제로 한 설계를 비교하면 다음과 같습니다.

당신이 도출한 결론을 실천하기 위한 'AI 아키텍트'로서의 지침은 다음과 같습니다.

'부작용 (Side Effects)'을 배제할 것:

메서드 내부에서 클래스의 멤버 변수를 수정하는 설계를 극력 줄이고, 계산 결과를 반환값으로 돌려주는 설계 (Immutable, 불변 설계)에 가깝게 가져간다. -
데이터 구조를 '문서'로서 정의할 것:

AI는 코드보다 먼저 '데이터 구조 (타입 정의, Interface, JSON Schema)'를 이해합니다. 메서드의 로직을 쓰게 하기 전에, 먼저 타입 정의 (DTO/Model)를 완벽하게 설계하는 것이 AI에 대한 가장 효율적인 지시가 됩니다. -
'테스트 가능한 단위'를 단위로 삼을 것:

'이 함수 단독으로 유닛 테스트 (Unit Test)를 작성할 수 있는가?'를 기준으로 삼습니다. AI에게 단체 테스트를 생성하게 할 때, 의존 관계가 적은 함수라면 AI는 거의 100%에 가까운 정확도로 고품질의 테스트 케이스를 자동 생성할 수 있습니다.

기존 OOP의 '상속'이나 '복잡한 디자인 패턴'은 AI에게는 노이즈가 되는 경우가 많다는 것이 실정입니다. 앞으로는 'OOP의 형식을 빌린, 함수형 언어적인 데이터 흐름 설계'가 AI와 공생하는 시스템 개발의 표준 (Best Practice)이 될 것입니다.

기존처럼 AI를 사용하지 않고 클래스 설계와 메서드의 동작, 거동만으로 AI에게 코드 생성을 시키면, 코드 파괴, 컨텍스트 오염, 환각 (Hallucination) 연쇄가 가속화되는 것입니다.

시스템 개발 공정에 AI를 도입한다는 것은 기존의 개발 및 설계 방식을 바꿀 필요가 있다는 뜻입니다. 현재 소프트웨어 개발 현장에서 많은 엔지니어가 직면하고 있는 'AI가 기대한 대로 코드를 쓰지 못하거나 품질이 붕괴되는' 가장 큰 원인은, 기존의 개발 방식, 즉 클래스 설계 그대로 AI에게 코드 생성을 지시함으로써 발생하는 결함의 증대 그 자체입니다.

그 구조적인 차이를 정리합니다.

기존의 Java 등의 설계에서는 '캡슐화'라는 이름의 '정보 은폐'를 미덕으로 삼아왔습니다.

동작의 거동: 내부 상태 (private 변수)를 메서드를 통해 서서히 바꾸어 나감 (상태 전이). -
인간의 인지: 인간은 시간을 들여 코드 전체를 읽고, IDE (에디터)에서 정의부로 점프하며, 디버거로 변수 값을 확인하면서 '문맥 (Context)'을 뇌 내에 구축합니다. -
장점: 복잡한 비즈니스 로직을 시간축 안에서 은폐하여 정리할 수 있다.

이 '상태를 은폐하고 상태 전이로 처리를 수행하는' 기존의 방식을 그대로 AI에 적용하면, 다음과 같은 치명적인 현상이 일어납니다.

• 컨텍스트 오염 (コンテキスト汚染):

AI는 인간처럼 '코드 전체를 직관적으로 파악'하는 것이 아니라, 주어진 프롬프트(컨텍스트)의 범위 내에서만 추론합니다. 클래스 내에 상태(멤버 변수)가 여기저기 흩어져 있으면, AI는 '이 메서드가 실행될 때 다른 메서드에 의해 변수는 어떻게 변화하고 있는가?'라는 시간적 맥락을 유지하지 못하고 모순된 코드를 생성합니다.

• 환각 연쇄 (ハルシネーション連鎖):

AI가 '여기에 이런 변수가 있을 것이다(실제로는 없다)', '이 메서드를 호출하면 상태가 업데이트될 것이다(의존 관계가 불분명)'와 같은 가정을 멋대로 만들어냅니다. 그 잘못된 전제에 기반하여 다음 코드를 작성하기 때문에, 수정할수록 코드가 붕괴합니다.

• 코드 파괴 (コード破壊):

독립성이 낮은 코드에 AI가 변경을 가하면, 예상치 못한 곳(부작용)에서 버그가 발생합니다. 이는 AI가 '수정된 코드의 부작용으로 인한 영향 범위'를 전체 코드베이스로부터 완벽하게 계산하기 어렵기 때문입니다.

'인간'과 'AI'는 코드를 읽을 때 메모리 사용 방식이 다르기 때문입니다.

• 인간: 관련 문서나 과거의 설계 배경, 암묵적인 규칙을 기억하여, 코드라는 '빙산의 일각'으로부터 전체를 추측할 수 있습니다. - AI: 프롬프트에 기술된 정보(명시된 의존 관계)가 전부입니다. 거기에 쓰여있지 않은 '암묵적 의존 관계(상태 전이)'는 존재하지 않는 것으로 취급됩니다.

AI를 시스템 개발에 활용한다는 전제 하에서는, '설계 단계에서 AI가 헤매지 않도록 '상태'를 제거하고 로직을 단편화(모듈화)하여 제시하는', 즉 'AI 구동 설계(AI駆動設計)'로의 전환이 필수적입니다.

'응집도 (Cohesion) 레벨을 한 단계 높여라'

기존 인간 개발에서는 IDE의 강력한 자동 완성 기능이나, 뇌 속의 컨텍스트 보완('이 클래스는 이런 의도로 여기에 배치되어 있다'는 암묵지) 덕분에 어느 정도 '절차적(手順的)' 또는 '논리적(論理的)' 응집도만으로도 개발을 진행할 수 있었습니다.

하지만 AI를 전제로 할 경우, 그 '암묵지'가 통하지 않습니다. 결과적으로 AI는 'AI가 이해하기 어려울 정도로 광범위한 컨텍스트'에 끌려 들어가 환각을 일으킵니다.

• 1. 기능적 (Functional Cohesion): 가장 강력합니다. 하나의 함수가 '오직 한 가지 일만 완벽하게 수행'하는 상태입니다. AI에게는 실수가 일어나기 가장 적고, 테스트도 용이합니다. - 2. 순차적 (Sequential Cohesion): 입력과 출력이 명확하게 연결된 상태(파이프라인)입니다. AI가 '전처리 → 계산 → 변환'이라는 플로우를 생성하는 데 최적입니다. - 3. 통신적 (Communicational Cohesion): 같은 데이터를 다루는 함수군입니다. 데이터 모델(구조체)이 확실하게 정의되어 있다면, AI는 타입을 힌트로 삼아 높은 정확도로 처리를 작성할 수 있습니다.

• 4. 절차적 ~ 7. 우발적: 이들은 '코드의 실행 순서'나 '우연히 관련성이 있어 보이는 기능'이 클래스에 혼재되어 있는 상태입니다. 이렇게 만들어 버리면, AI는 '이 변수, 지금 단계에서 정말 이 값으로 맞는가?'라는 상태 추론의 미궁에 빠지게 됩니다.

이 경계선은 'AI가 그 코드를 생성할 때 다른 곳을 전혀 볼 필요가 없는가?'라는 기준으로 나뉩니다.

• 기능적 · 순차적 · 통신적이라면, AI는 프롬프트로 주어진 '인수(引数)'와 '반환 값의 타입(스키마)'만 보고 코드를 생성할 수 있습니다. - 절차적 · 논리적이 되면, AI는 '인스턴스 내 다른 멤버 변수의 현재 값'을 고려해야 합니다. 이 시점에서 프롬프트 컨텍스트가 오염되고, 환각 연쇄가 시작됩니다.

솔직히 말해서, '3. 통신적'과 '4. 절차적', '6. 논리적'의 경계선은 실제 코드에서 흑백으로 명확하게 나뉘는 것이 아니라 그라데이션입니다. '이것이 3에 가까운가 아니면 4에 가까운가'를 엄격히 판정하기보다는, '지금 작성하는 코드가 어느 방향에 가까워지고 있는가'를 의식할 정도의 감각으로 충분히 실용적입니다.

개발 엔지니어가 해야 할 일은, AI에게 '복잡한 로직을 클래스에 채워서 전달하는 것'이 아니라, '통신적(데이터를 공유하는)' 레벨까지 정리된 작은 파츠(기능적 · 순차적)를 AI가 조립하도록 하는 것입니다.

지금까지의 OOP 설계자들이 '어떻게 클래스를 계층화할지(상속이나 복잡한 관련성)'에 목숨을 걸었다면, 앞으로의 AI 시대 아키텍트는 '어떻게 메서드를 순수하게 만들고 의존성을 데이터 플로우로 변환할 것인가'에 목숨을 걸어야 합니다.

모듈의 응집도 (Cohesion)를 7단계로 정리하여, AI 시대의 설계에서 "어디를 경계선으로 삼아야 하는가"를 시각화합니다.

인간은 이것들을 뇌 내에서 보완하며 개발해 왔지만, AI에게 코드를 작성하게 할 때는 "저응집도 (4 이하)"의 코드를 전달하면, AI는 추론의 미로에 빠져들며 할루시네이션 (Hallucination)이 발생합니다.

1. 기능적 (Functional)

특징: 하나의 기능이 하나의 데이터만을 처리한다. AI에게 가장 단순하며 실수가 일어나지 않는다.

2. 순차적 (Sequential)

특징: 기능 A의 결과를 기능 B가 이어받는다. 데이터 플로우 (Data Flow)가 일직선이라 AI가 "다음에 무엇을 할지" 추론하기 쉽다.

3. 통신적 (Communicational)

특징: 동일한 데이터를 여러 기능이 공유한다. 타입 정의 (Schema)만 있다면 AI는 각 기능의 로직을 독립적으로 작성할 수 있다.

4. 절차적 (Procedural)

특징: 실행 순서에 강하게 의존한다. AI는 "A→B→C로 진행되는 도중에 Data1의 상태가 어떻게 되었는가"를 항상 유지해야 하므로, 컨텍스트 오염 (Context Pollution)이 발생하기 쉽다.

5. 일시적 (Temporal)

특징: "초기화", "종료 처리" 등 타이밍만으로 묶여 있다. 관련성이 낮은 데이터에 동시에 접근하기 때문에 AI는 할루시네이션을 일으키기 쉽다.

6. 논리적 (Logical)

특징: "DB 조작", "로그 출력" 등 역할로 분류된다. 비슷한 기능이지만 내부 처리가 제각각이기 때문에, AI는 "어떤 IF 문이 어떤 조건에서 동작하는가"를 예측하는 과정에서 혼란을 겪는다.

7. 우연적 (Coincidental)

특징: 관련이 없는 것들이 같은 모듈에 들어 있다. AI에게는 "쓰레기통"과 같아서, 컨텍스트로 읽히게 할 경우 성능이 가장 크게 저하된다.

이미지를 다시 확인하면, "기능"과 "데이터"의 선(의존 관계)이 복잡해질수록 모듈이라는 "상자" 안에 갇힌 논리가 미궁화되고 있음을 알 수 있습니다.

1~3: 데이터의 흐름이 정리되어 있어 AI는 "입력"과 "출력"만 생각하면 되므로, 코드 생성 결과가 안정적입니다.
4~7: 외부 상태(멤버 변수나 다른 기능의 실행 상황)에 대한 의존이 강하기 때문에, AI는 "전체의 정합성"을 추론하기 위해 거대한 뇌 부하를 강요받으며, 결과적으로 파괴적인 코드를 생성합니다.

이 도표를 머릿속에 넣어두면, AI에게 코드를 작성하게 할 때 "지금 모듈의 응집도가 낮은 설계 상태로 지시를 내리고 있지는 않은가?"라며 스스로 지시의 질을 셀프 체크할 수 있게 됩니다.

AI가 코드를 생성할 때, "함수의 인자와 반환값의 타입 정의 (인터페이스)"만 보고 로직을 짤 수 있는 상태가 이상적입니다.

기능적·순차적·통신적 (1~3)을 지향해야 하는 이유:

이것들은 "입력→변환→출력"이라는 수학적 함수에 가까운 동작을 합니다. AI는 외부의 복잡한 상태(클래스의 멤버 변수 등)를 추적할 필요가 없기 때문에, 할루시네이션 확률이 극도로 낮아집니다.

절차적 (4) ~ 우연적 (7)이 AI를 망가뜨리는 이유:

이것들은 "인스턴스의 상태"나 "특정 순서로 실행되는 부작용 (Side Effect)"에 의존합니다. 프롬프트에 다 적을 수 없는 "암묵적인 문맥"이 필요하기 때문에, AI는 "이 변수는 이 단계에서 어떻게 되어 있어야 하는가?"를 추측할 수밖에 없으며, 결과적으로 정합성이 없는 코드를 생성하게 됩니다.

기존의 개발 도구나 「IDE라는 도구의 설계 사상」과 「현대 AI 개발 사이의 격차」가 생산성과 품질의 병목 현상이 되고 있는 것이 현실입니다.

「기존의 IDE(Visual Studio, Eclipse, IntelliJ 등)는 인간이 『47(절차적우발적)』의 복잡한 상태를 뇌 내에서 관리하는 것을 전제로 설계되어 있기」 때문에, AI에게 코드를 작성하게 하려고 하면 오히려 그 IDE의 기능이 「AI의 발목을 잡는 노이즈」가 되는 경우조차 있습니다.

왜 「기존의 IDE」가 AI 개발에서 폐해를 낳는지, 구조적인 이유를 해설합니다.

기존의 IDE는 인간이 코드를 이해하기 위해 다음과 같은 기능을 제공해 왔습니다.

클래스 계층의 시각화: 상속 관계를 추적하는 트리. -
멤버 변수·메서드 참조처 검색: 「어디에서 이 변수가 사용되고 있는가」를 특정하는 기능. -
코드 보완 (Code Completion): 인스턴스의 상태에 기반한 메서드 제안.

이것들은 「응집도 4~7」과 같은 밀결합 (Tight Coupling) 설계에서 인간이 길을 잃지 않기 위한 대책입니다. 하지만 AI에게 이것들을 전달하면 어떻게 될까요? 「본래 무시해야 할 노이즈(다른 메서드의 상태 변화)」를 모두 컨텍스트 (Context)로 읽어 들여, 오히려 「어떤 변수가 중요한가」를 놓치는 (컨텍스트 오염) 부작용이 발생합니다.

기존의 IDE는 「파일」이나 「클래스」를 관리 단위로 삼고 있지만, AI에게 정말로 필요한 것은 「함수의 입출력 정의 (스키마)」입니다.

기존의 IDE: 「A.java」라는 파일 안에 10개의 메서드가 혼재되어 있어도, 인간은 에디터를 스크롤하며 볼 수 있으므로 문제가 없다. -
AI: 「A.java」 전체를 전달받으면, 무관한 메서드의 로직까지 추론에 섞어 넣어 할루시네이션 (Hallucination) 확률이 급증한다.

IDE는 인간을 위해 「관련된 정보를 한곳에 모으는 것」을 권장하지만, AI 개발에서는 「무관한 로직을 강제적으로 분리 (물리적으로 파일을 나누거나, 혹은 순수 함수 (Pure Function)로 추출)」하는 것이 요구되기 때문에, IDE의 「모으게 만드는」 기능이 설계의 방해가 되는 것입니다.

IDE의 디버거 (Debugger)는 인스턴스의 상태 변화 (45의 절차적·일시적 응집)를 추적하기 위해 존재합니다. 하지만 AI가 작성해야 할 코드는 「상태를 추적할 필요가 없는 (13의 기능적 응집)」 것이어야 합니다.

폐해: AI에게 「상태 전이 버그」를 수정하게 하려고 하면, IDE의 디버거가 제시하는 「복잡한 상태 스택」을 AI가 해석하게 됩니다. 이는 AI에게 「극도로 난이도가 높은 퍼즐」이며, 결과적으로 「임시방편적인 수정 코드 (추가적인 기술 부채)」를 생성하기 쉽게 만듭니다.

기존의 IDE를 「AI의 문맥을 관리하는 도구」로 사용하는 것을 그만두고, 다음과 같이 구분하여 사용해야 합니다.

AI를 「순수 함수 메이커」로 만들기:

IDE의 기능을 「코드 해석」이 아니라 「리팩터링 (Refactoring, 메서드 추출)」에 사용합니다. AI에게 지시하여 절차적 응집의 덩어리로부터 기능적 응집의 작은 함수들을 차례차례 뽑아내게 합니다. -
타입 정의 (Interface/DTO)를 IDE로 엄격하게 관리하기:

AI는 타입 정의에 매우 충실합니다. 로직을 IDE에서 쓰는 것이 아니라, 「타입 (계약)」을 IDE에서 엄격하게 작성하고, 로직은 AI가 그 타입에 따르게 하는 역할 분담을 합니다. -
IDE의 표시 단위를 작게 만들기:

AI가 답변할 때는 IDE의 창을 분할하여 「순수 함수」만을 표시함으로써 AI의 컨텍스트를 좁혀줍니다.

앞으로의 IDE는 단순한 「코드를 색상별로 표시하는 에디터」에서 「AI 에이전트 (AI Agent)를 지휘·감독하기 위한 사령실 (Operation Center)」로 진화해 나갈 것입니다.

지금까지의 IDE는 파일을 열고, 손으로 코드를 수정하고, 저장하는 「인간 중심의 조작」을 전제로 했습니다. 차세대 IDE는 다음과 같이 변합니다.

컨텍스트 자동 동기화: AI가 프로젝트 전체의 구조 (의존 관계나 타입 정의)를 실시간으로 파악하여, 인간이 굳이 지시하지 않아도 「지금 어디를 수정해야 하는지」를 앞서서 이해합니다. -
자율형 에이전트 통합: IDE 안에 「테스터」, 「디버거」, 「문서 작성자」와 같은 전문적인 AI 에이전트가 상주하며, 인간이 「〇〇해줘」라고 한마디 던지기만 하면 배후에서 에이전트들이 협력하여 작업을 완료합니다. -
UI의 추상화: 코드를 직접 편집하는 기회는 줄어들고, 설계도나 플로우 차트(Flowchart), 혹은 채팅 기반의 지시가 메인이 됩니다. IDE는 「생성된 결과」를 시각화하고 확인하기 위한 대시보드 (Dashboard)로서 기능하게 됩니다.

주목받고 있는 「바이브 코딩 (Vibe Coding)」과 같은 스타일을 뒷받침하기 위해, IDE는 다음과 같은 기능들을 표준 장착해 나갈 것입니다.

「실패의 샌드박스화 (Sandbox)」 자동화: 실행→수정→재실행의 루프가 매우 빨라지도록, IDE 자체가 즉시 프리뷰 환경을 구축하고 AI가 스스로 수정을 가할 수 있는 피드백 루프(샌드박스)를 구성합니다. -
「직관」을 코드로 변환하는 번역기: 모호한 표현이나 추상적인 요구사항으로부터, AI가 최적의 기술 선정과 구현 패턴(앞서 언급한 「고응집 (High Cohesion)」 구조)을 자동으로 선택 및 생성하는 기능이 강화됩니다.

결론부터 말하자면, 기존의 IDE는 「인간이 코드의 정합성을 유지하기 위한 비용」을 대신 부담해 주는 도구였습니다. 하지만, AI 네이티브 IDE는, 「코드의 정합성(의존 관계의 건전성)을 AI가 자동으로 유지한다」는 것을 전제로 합니다.

기존의 IDE: 「어디에 무엇이 있는지」를 인간이 찾기 위한 툴. -
AI 네이티브 IDE: 「무엇을 만들고 싶은지」를 AI에게 전달하고, 완성된 결과물을 리뷰하는 장소.

이처럼 IDE의 「역할」이 근본적으로 변해가기 때문에, 기존의 IDE를 AI로 확장하는 것만으로는 머지않아 한계가 올 것이라는 것이 저의 견해입니다. 다만, 이것이 「내일부터 구시대의 IDE가 사라진다」는 뜻은 아닙니다. 당분간은 「인간이 리뷰하고, AI가 생성하는」 하이브리드 운용이 주류로 남을 것입니다. IDE가 완전히 대체될지는 아직 확정된 미래가 아니라, 하나의 시나리오로 받아들여 주십시오.

향후의 IDE는, 「얼마나 빨리 타이핑할 수 있는가」가 아니라, 「얼마나 정확하게 AI에게 의도(Vibe)를 전달하고, 생성된 시스템을 아키텍트로서 평가할 수 있는가」를 지원하는 도구로 나아갈 것입니다.

숙련된 엔지니어는 「재사용성」, 「확장성」, 「유지보수성」을 추구하며 클래스를 설계합니다. 그 결과로 탄생하는 것이 「밀접한 의존 관계」나 「추상화된 상속 관계」입니다.

숙련된 엔지니어의 의도: 「나중에 기능을 추가하기 편하도록, 인터페이스로 느슨한 결합 (Loose Coupling)을 만들고 상태를 캡슐화하자」 -
AI의 관점: 「이 메서드를 호출하려면, 먼저 이 추상 클래스를 상속받고 이 복잡한 상태 전이를 초기화해야 한다고? ……우와, 의존 관계가 너무 깊어서 어떤 변수가 어디서 쓰이는지 확신이 안 서네. 좋아, 대충 비슷해 보이는 코드로 보완하자…… (결과: 버그)"

즉, 인간에게 「세련된 설계」는 AI에게 「해독 불가능한 미궁」에 불과합니다. AI는 「과거의 방대한 코드」로부터 학습하지만, 그 학습 데이터에는 「설계가 파탄 난 코드」나 「의도 불명인 설계」도 대량으로 포함되어 있기 때문입니다.

「신입 같은 방식으로 작성하라 (Main 메서드에 모든 것을 작성하라)」는 쪽이 AI에게는 더 정확합니다.

컨텍스트가 닫혀 있고 「명시적」임:

모든 것이 Main 메서드 안에 작성되어 있으면, AI는 「다른 파일을 찾아갈」 필요가 없습니다. 변수 선언부터 처리의 완결까지 하나의 화면(컨텍스트) 안에 들어와 있기 때문에, AI가 「전제 조건」을 잘못 읽을 리스크가 극히 낮아집니다. -
데이터 흐름(Data Flow)이 선형적임:

「A를 하고, 다음에 B를 하고, 마지막으로 C를 출력한다」는 절차가 눈에 보이기 때문에, AI의 추론에 모순이 생기기 어렵습니다.

AI에게 가장 친절한 코드란, 「해독할 필요가 없는 코드 (= 그 자리에 모든 것이 적혀 있는 코드)」입니다.

그렇다면 「신입의 코드가 최고」냐고 묻는다면, 물론 장기적으로는 유지보수가 불가능해집니다. 여기서 중요한 점은, 「AI 시대의 새로운 설계」란 「신입의 코드 (Main 메서드)」와 「숙련된 설계 (클래스 구조)」의 중간에 있는 것이라는 점입니다.

AI 시대의 아키텍트가 해야 할 일:

Main 메서드에 모든 것을 쏟아붓는 것이 아니라, 「기능적 응집도가 높은, 극소의 순수 함수 (Pure Function)」를 대량으로 나열하는 것입니다. -

• 「Main 메서드 안에 모든 것을 작성한다」는 단순함을 유지한다.
• 하지만 Main 메서드를 직접 작성하는 것이 아니라, 「AI가 언제든 꺼내 쓸 수 있는 작은 함수 부품의 카탈로그」로서 코드베이스를 정리해 둔다.

「유지보수 개발」이야말로 AI 시대의 최대 난관입니다.

기존의 「인간이 뇌 내에서 문맥을 보완하던 저응집도 (4~7)의 스파게티 코드」에 AI가 기능을 추가하게 만들면, 틀림없이 버그의 온상이 됩니다. 이 「기존 코드를 어떻게 요리할 것인가」라는 문제에 대한 AI 시대의 유지보수 개발 전략은 다음과 같습니다.

갑자기 기존 코드에 수정 코드를 직접 쓰게 해서는 안 됩니다. 우선, 그 코드의 「현재 설계 사상과 상태」를 AI가 출력하게 만듭니다.

절차: 기존 코드를 AI에게 읽히고, "이 코드가 어떤 데이터 흐름 (Data Flow, 응집도)으로 작동하는지 도해하라"고 명령합니다. -
효과: 인간이 "어렴풋이" 이해하고 있던 복잡한 구조를 AI가 시각화함으로써, AI 스스로가 "수정의 영향 범위"를 정확하게 인식할 수 있게 됩니다.

기존 코드에 대한 수정 요청이 오면, "수정 코드를 작성하기 전"에, "코드를 AI 친화적인 구조 (1~3)로 변환하는" 태스크를 먼저 완료시킵니다.

전략: "이 기능을 추가하기 전에, 먼저 이 절차적 로직을 인자(Argument)와 반환값(Return Value)을 가진 순수 함수 (Pure Function)로 분리해줘"라고 AI에게 의뢰합니다. 장점:

• 함수가 분리되면, 해당 함수 단위로 유닛 테스트 (Unit Test)를 생성할 수 있습니다.
• 기존의 스파게티 코드 (Spaghetti Code)를 AI가 다루기 쉬운 "느슨한 결합 (Loosely Coupled)의 부품"으로 해체한 뒤 수정을 진행하므로, 결함을 극적으로 줄일 수 있습니다.

인간이 "冗長化 (중복 및 비대화)"를 두려워하는 것은 당연합니다. 이를 방지하기 위해서는 AI에 대한 "설계 규칙 (Guardrail)" 강제가 필수적입니다.

「책임의 분리 (Separation of Concerns)」 강제: "추가 기능은 기존 클래스를 다시 쓰지 말고, 새로운 작은 클래스 (또는 순수 함수)를 만든 뒤, 그것을 기존 코드에서 호출하도록 해라"라는 지시를 내립니다. -
코드 품질 자동 체크: "이 수정으로 인해 기존 클래스의 의존 관계 (Dependency)가 복잡해지지는 않았는가? 응집도 (Cohesion)가 낮아지지는 않았는가?"를 체크하는 AI 프롬프트 (Prompt)를組み込み (組み込み, 포함)합니다.