AI는 현재 코드 구조의 벽에 막혀있다

들어가며

코드는 단순한 기능의 동작 논리 만을 담고 있지 않습니다. 저장소 history나 주석을 제외 하더라도, 선대 개발자의 구조 사상을 통하여 이후 개발 될 코드들의 방향성을 제안하며, 해당 솔루션, 서비스, 프로젝트의 지속 개발 안정성을 제어하는 역할을 하게 됩니다. 또한 이는 시간에 걸친 시행착오와 함께 발전하며 해당 환경 및 요구 사항에 적합한 형태로 진화합니다.

무서운 속도로 발전하는 AI들은 현재 이론 상 75,000 ~ 110,000라인의 코드를 다룰 수 있다고 알려져 있습니다 [1]. 반면적으로 AI를 통한 코드 작성 초기부터 알려진 문제들은 여전히 지속되고 있습니다. 이와 관련한 문제의 원인과, 이를 위한 개발자들의 발전 방향성을 제안합니다.

이 글의 취지

2025-08-16 현재 AI를 기준으로 한 글이며, 이는 AI를 통한 코딩 방법론을 헐뜯기 위한 목적을 가지지 않습니다. 이제 막 배우기 시작한, 혹은 실무에 투입 된 지 얼마 되지 않은 주니어 개발자들이 AI와 함께 개발을 해 나아가며 마주하게 될 문제들 중 일부에 대하여, 그 원인을 인지하고 더 나은 방향성을 제안하기 위한 목적으로 작성 되었습니다.

또한, 이미 수많은 벤치마크 경쟁이 존재하지만, 이 글은 성능 순위가 아니라 우리가 구조적 사고를 어떻게 바꿀 수 있는지에 초점을 맞추고자 합니다.

AI의 문맥 누락으로 인한 필요 코드 삭제 문제

인간의 기억력은 한계가 있고, 프로젝트 내 모든 코드를 외울 수 없습니다. 이에, 함수 및 class, 혹은 module(dll)이나 service와 같은 단위를 만들고 그 목적과 기능들을 추상화 하여 기억합니다. 작업 시, 목적에 밀접한 논리 및 코드 위주로 이해 및 기억하고, 그 외 부분들은 모두 추상 레벨 그 이상으로 활성 되지 않습니다. 이는 다시 정리 된 구조로 저장되며, 이 과정의 반복은 점진적 발전 방법론으로 적극 활용 됩니다.

반면, 현재 개발 목적 AI로 가장 높은 평가를 받는 Claude code는 무수한 시행착오를 반복하며 목표에 도달하는 방식을 사용합니다. 물론 MCP + RAG을 통한 문맥 레벨에서의 참조 구현들이 알려져 있어 평가를 Brute force와 비할 바는 아니지만, 그 효율 관련으로 무수히 많은 문제들이 보고되고 있습니다 [2] [3]. Cursor 또한 문맥 누락으로부터 자유롭지 못하며 [4], 기존의 대화형 AI는 더욱 그 평가가 떨어집니다 [5] [6]. 대체적으로 부분적인 코드 산출에는 매우 훌륭하지만, 프로젝트 단위의 제어에는 어려움을 보이고 있는 것이 사실입니다.

AI의 문맥 누락을 유발하는 코드 생산

"그거 프롬프트 잘못 넣은거 아니야?"

AI를 활용한 코드 작성을 하며 흔하게 접하는 문장 입니다. 선술 하였듯, 코드는 단순하게 동작을 위한 논리만을 담아내는 저장 구조가 아닙니다. 이미 코드로 문맥을 전달하는 시도들이 있고, 대표적으로 TDD를 활용한 AI 문맥 제어 방법론이 있습니다 [7]. 이는 적어도 현재 AI가 프롬프트만이 아닌, 입력 된 코드 또한 문맥의 일종으로서 이해를 한다는 강력한 증거 입니다.

다만 아쉽게도, 현 시점의 AI는 스스로 그 구조를 이해하기 쉬운 코드를 잘 만들어 내지 못합니다. 아래는 GPT-4o가 100% 작성한 코드이며, GPT-5 또한 구조적 문제점을 찾아내지 못하는 대표적 예시 입니다.

if (g.mode === 'TURN') { 
broadcastTurn(roomId);
startTurnTimer(roomId);
} else {
io.to(roomId).emit("timer:reset", { remaining: 0 });
}

코드 저장소는 이 Link를 참조하면 되며, 참조 할 tag는 before_refact, after_refact 입니다. before_refact는 단순한 목적 지향형 코드로 구성 되어 있고, after_refact는 room의 명시적 객체 독립 및 game의 mode 별 핸들러 파생 구조를 담고 있습니다. 이 두 tag를 각각 GPT-5에게 전달하고, Team Trun 모드를 추가해 달라는 요청 비교를 해 보았습니다.

before_refact 코드는 전반적인 위치에 TeamTurn 분기문들이 추가되며, 이후 추가되는 요구사항들로부터 각 mode들의 동작들이 쉽게 망가졌습니다. 반면, after_refact 코드는 기존 상속 구조를 존중하며, 파생 클래스를 추가하는 형태로 코드 변형을 시도하였고, 이후 추가되는 요구사항들에도 mode 별 동작들이 쉽게 망가지지 않는 결과를 보입니다.

위 예시는 Link를 참고하여 직접 테스트 해볼 수 있으며, 구조 유무에 따른 AI의 생산 코드 품질의 차이를 이해 할 수 있습니다.

*참조 코드는 구조의 차이를 설명하기 위한 코드로, after_refact 또한 AI를 통해 작성 되었고 이상적인 코드와는 거리가 있습니다. 구조 유무에 따른 결과물의 차이를 이해하는 목적으로서만 참고 되어야 함을 주의해야 합니다.

구조 및 문맥 제어

AI에게 동적 모듈 로딩 구조의 필요성을 질문하면 명쾌한 정답을 응답합니다. 다만 아이러니하게도, '명시적' 동적 모듈 로딩 구조 구현을 요구하지 않는다면, 원하는 결과를 받을 수 없습니다. 당연하게도 AI에게 코드 토시 하나 놓치지 않고 명령을 하지는 않으므로, 상당히 많은 구조들이 누락 될 수 있습니다.

가장 중요한 점은, 환경과 요구 사항에 따른 구조를 판단하는 개발자의 능력입니다. 좋은 구조의 코드는 이후 있을 AI의 연산들의 실수를 줄여주며, 어긋난 방향으로의 코드 출력을 예방합니다. AI에 발전에 의하여, 저수준의 코드는 설령 비 개발자라 하더라도 하루에 수만 라인의 코드를 만들어 낼 수 있게 되었습니다. 앞으로의 개발자의 수준 평가는, 작성 가능한 고수준의 코드 생산량이 될 것입니다.

생산량의 증가로 인해, 기존의 Function, Class 단위를 제어하던 개발자는 Module 단위의 제어를, Module 단위를 제어하던 개발자는 Service 단위를, Service 단위를 제어하던 개발자는 Architecture 레벨의 고민 할 수 있는 시간이 주어졌습니다. 더 넓고 깊은 제어를 하기 위한 지식을 많이 가진 개발자가 더 높은 평가를 받게 될 것입니다.

결론

현 시점에서 AI의 코딩은 파편적으로는 인간을 능가하지만, 구조와 사상 면에서는 이제 막 개발을 배운 신입 개발자와 크게 다르지 않습니다. AI는 단기 목적에 치중하며, 스스로 만든 코드를 스스로 무너뜨리거나, 의도를 망각한 채 의미 없는 구조를 덧붙이곤 합니다.

구조적 의도가 부재한 코드는 AI와 인간 모두에게 함정이 됩니다. 이 글은 그러한 실수를 방지하기 위한 생각의 씨앗을 뿌리는 시도였습니다. 결국 논리가 끊임없이 바뀌는 상황에서 방향을 잃지 않도록 이끄는 것은 개발자의 몫이라는 점을 잊지 말아야 합니다.