당신의 React 앱에는 아키텍처가 있습니다. 하지만 팀원 중 누구도 그것을 선택하지 않았습니다. 바로 AI가 선택했습니다.

모든 React 프로젝트의 어느 시점에는 누군가가 이렇게 묻습니다: 왜 구조가 이런 식인가요?

그리고 아무도 제대로 된 답변을 하지 못합니다.

결정이 틀렸기 때문이 아닙니다. 결정 자체가 없었기 때문입니다. 구조는 성장했습니다. 한 번의 세션마다 조금씩 말이죠. 각각의 AI 생성물은 그 순간에는 말이 되는 무언가를 추가했지만, 의도적인 아키텍처 (Architecture) 선택의 일부였던 적은 없었습니다.

아키텍처는 존재합니다. 단지 설계되지 않았을 뿐입니다.

설계되지 않은 아키텍처가 구축되는 방식

첫 번째 세션에서 시작됩니다.

AI가 컴포넌트 (Component)를 생성합니다. 그것을 어딘가에 배치합니다. 특정 요청에 대해 말이 되는 파일 구조 (File structure)를 만듭니다. 아무도 이것이 장기적으로 무언가가 위치해야 할 곳인지 묻기 위해 멈춰 서지 않습니다. 기능은 작동합니다. 세션은 종료됩니다.

다음 세션은 그 위에 구축됩니다. 구조가 옳았기 때문이 아니라, 이미 거기에 있었기 때문입니다. AI는 존재하는 것을 보고 그것을 확장합니다. 새로운 기능에는 폴더가 생깁니다. 새로운 훅 (Hook)은 마지막 훅 옆에 배치됩니다. 새로운 서비스 (Service)는 공간이 있는 곳 어디든 추가됩니다.

충분한 세션이 지나면 코드베이스 (Codebase)에는 구조가 생깁니다. 폴더 계층 구조 (Folder hierarchy). 무언가가 위치하는 패턴. 모든 새로운 세션이 이미 존재하기 때문에 강화하게 되는 암묵적인 아키텍처 (Implicit architecture)가 형성됩니다.

아무도 그것을 설계하지 않았습니다. AI는 이전의 모든 세션에서 축적된 결정들을 모아 그것을 조립했을 뿐입니다.

이것이 대부분의 개발자가 깨닫는 것보다 더 중요한 이유

설계되지 않은 아키텍처가 반드시 망가진 것은 아닙니다. 한동안은 잘 작동할 수도 있습니다.

문제는 그것이 무엇을 위해서도 최적화되지 않았다는 점입니다. 확장성 (Scalability)을 위해서도, 팀의 탐색 (Navigation)을 위해서도, 그것이 나타내는 도메인 (Domain)을 위해서도 아닙니다. 그것은 각 개별 세션에서 생성하기 가장 쉬웠던 것에 최적화되었습니다.

이는 아키텍처가 반영하는 모든 결정이 팀의 의도적인 선택이 아니라, AI가 선택한 최소 저항 경로 (Path of least resistance)였음을 의미합니다. 그리고 최소 저항 경로를 따르는 아키텍처는 시간이 흐를수록 좋아지지 않습니다.

새로운 개발자들은 이를 탐색하는 데 어려움을 겪습니다. 왜냐하면 학습해야 할 논리는 없고, 오직 추적해야 할 역사만이 존재하기 때문입니다. 구조가 성장을 수용하도록 설계된 적이 없기 때문에 기능을 추가하는 것이 점점 더 어려워집니다. 아키텍처가 모든 곳에 존재하면서 동시에 어디에도 존재하지 않기 때문에 리팩터링 (Refactor) 비용이 비싸집니다.

AI가 발명한 아키텍처가 잘못된 이유는 그것이 나쁘기 때문이 아닙니다. 그것이 결코 당신의 것이 아니었기 때문입니다. 그리고 아무도 의도적으로 설계하지 않은 코드베이스는 아무도 완전히 이해하지 못하는 코드베이스입니다.

의도적인 아키텍처란 어떤 모습인가

의도적인 아키텍처는 AI가 무엇인가를 생성하기 전에, 요소들이 어디에 위치할지를 정의하는 규칙에서 시작됩니다.

완전한 아키텍처 문서가 아닙니다. 몇 주간의 계획도 아닙니다. 그저 AI가 스스로 답해버릴 질문들에 답할 수 있을 만큼의 규칙이면 충분합니다.

컴포넌트 (Components)는 어디에 위치하는가? 기능 (Features)은 어떻게 조직되는가? UI와 비즈니스 로직 (Business logic) 사이의 경계는 무엇인가? 앱의 서로 다른 부분들은 어떻게 통신하는가?

이러한 규칙들은 아키텍처 결정을 AI가 따르는 제약 조건 (Constraints)으로 바꿉니다:

AI의 결정을 대체하는 아키텍처 규칙:
1. 기능 (Features)은 내부에 컴포넌트 (Components), 훅 (Hooks), 서비스 (Services), 타입 (Types)을 포함하는 독립된 폴더이다.
2. 공유 코드 (Shared code)는 전용 shared 폴더에 위치한다. 기능 간에 직접적인 교차 임포트 (Cross-import)는 허용되지 않는다.
...

세 가지 규칙. 첫 세션이 시작되기 전에 적용하십시오. 그러면 AI는 아키텍처를 발명하는 것을 멈추고, 당신이 선택한 아키텍처 안에서 구축을 시작할 것입니다.

아키텍처 되찾기

대부분의 프로젝트는 설계되지 않은 아키텍처가 문제가 되는 지점에 도달합니다. 리팩터링 (Refactor)이 고려됩니다. 구조에 대한 대화가 마침내 이루어집니다.

그 대화는 가치가 있습니다. 하지만 아키텍처가 이미 모든 곳에 존재한 후에 이루어진다면 비용이 많이 듭니다.

첫 세션 전에 진행하는 동일한 대화는 20분밖에 걸리지 않으며 비용도 들지 않습니다. AI는 그 이후의 모든 세션에서 그 대화의 결과물을 따릅니다.

그것이 바로 당신이 선택한 아키텍처와, 아무도 요청하지 않았음에도 AI가 조립해버린 아키텍처 사이의 차이점입니다.

프롬프트(Prompt)는 중요하지 않습니다. 규칙(Rules)이 중요합니다.

당신의 React 프로젝트는 당신이 설계했든 아니든 이미 아키텍처를 가지고 있습니다.

문제는 그 아키텍처가 애플리케이션을 어떻게 구조화해야 하는지에 대한 의도적인 결정(deliberate decisions)을 반영하고 있는지, 아니면 무엇을 생성하는 것이 가장 쉬웠는지에 대한 AI의 누적된 결정(accumulated AI decisions)을 반영하고 있는지입니다.

먼저 설계하십시오. 그것을 규칙(Rules)으로 작성하십시오. AI가 무엇인가를 구축하기 전에 AI에게 전달하십시오. 그리고 아무도 선택하지 않은 아키텍처를 물려받는 일을 멈추십시오.

당신의 React 아키텍처가 당신에 의해 설계된 것이 아니라 AI에 의해 발명된 곳을 찾고 싶습니까?

저는 바로 그 지점을 정확히 찾아낼 수 있도록 도와주는 24가지 항목의 무료 체크리스트를 만들었습니다. AI가 당신을 대신하여 아키텍처 결정을 내리고 있는 구조적 간극(structural gaps)을 찾아보세요.

→ React AI 클린 코드 체크리스트 받기 — 무료

→ Avery Code React AI 엔지니어링 시스템