기존 접근 vs AI 시대 접근
기존 접근
- 간단하게 시작
- 기능 추가하며 복잡도 증가
- 복잡도가 임계점 넘으면 아키텍처 도입
AI 시대 접근 (제안)
[사용자] “AI 도구로 인해 작업 속도 자체가 극적으로 빨라지는 시대에는, 오히려 처음에 아키텍처를 구상하고 설계한 뒤 그 위에서 하나하나 코드를 올리는 방식이 더 낫지 않을까 싶어.”
- 처음부터 아키텍처/패턴 구상
- 보일러플레이트 많아도 구조 위에서 시작
- AI가 패턴 따라 코드 추가
근거
[사용자] “간단하게 시작해서 기능을 마구마구 추가하다 보면, 아키텍처를 도입해야 하는 시기가 생각보다 엄청 빨리 올 것 같아. 거기다 AI 덕분에 코딩 속도가 빨라진 상황에서는 보일러플레이트 코드가 크게 문제가 되지 않을 수도 있겠더라고.”
비용 구조의 변화
| 과거 | AI 시대 |
|---|---|
| 코드 작성 = 비쌈 | 코드 작성 = 저렴 |
| 보일러플레이트 = 고통 | 보일러플레이트 = 별로 안 아픔 |
| “나중에 정리” = 괜찮음 | “나중에 정리” = 위험 |
| 리팩토링 = 해볼만함 | 리팩토링 = 상대적으로 더 비쌈 |
왜 리팩토링이 더 비싸졌나
[Claude] “저는 ‘이 구조에 맞춰서 새 기능 추가해’보다 ‘이 뒤섞인 코드를 저 구조로 바꿔’가 훨씬 어렵습니다. 기존 동작 보존하면서 구조 바꾸는 건 컨텍스트도 많이 먹고, 실수 가능성도 높고, 검증도 어렵습니다.”
이너 아키텍처 vs 패턴/컨벤션
[사용자] “내가 이야기하는 아키텍처라는 게 패턴이나 컨벤션 같은 파일 구조, 상태 관리, 에러 처리 이런 종류인 것 같기도 해. 이너 아키텍처가 패턴과 컨벤션에 좀 더 가까운 느낌도 들긴 하네.”
패턴/컨벤션: “어떻게” 작성하나
- 파일명:
*.service.ts,*.store.ts - 에러 처리 스타일
- 함수형 vs 클래스형
- 네이밍 규칙
이너 아키텍처: “무엇이 어디서 무엇과 소통하나”
- 레이어 분리 (presentation → domain → data)
- 의존성 방향 (domain은 infrastructure를 모른다)
- 모듈 경계
- 데이터 흐름 방향
실제 차이
[Claude] “컨벤션은 파일 단위로 바꿀 수 있습니다. 이너 아키텍처는 바꾸면 연쇄적으로 영향이 갑니다.”
예: “상태 변경은 반드시 store를 통해서”
- 컨벤션처럼 보이지만 데이터 흐름에 대한 아키텍처 결정
- 바꾸면 여기저기 다 바뀌어야 함
Clean Architecture / Hexagonal 도입 시점
[사용자] “클린 아키텍처, 그 중에서 포트앤 어댑터를 그냥 애초에 처음부터 도입하면 도메인과 상관없이 거의 다 먹히지 않아?”
Hexagonal이 맞는 경우
- 비즈니스 규칙이 복잡하고 중요한 경우
- 외부 시스템(DB, API 등)이 바뀔 가능성이 있는 경우
- 도메인 로직을 독립적으로 테스트하고 싶은 경우
Hexagonal이 오버킬인 경우
- 실질적으로 CRUD가 대부분인 경우
- 도메인 로직보다 UI나 통합 로직이 더 많은 경우
- 작은 규모에서 빠르게 검증해야 하는 경우
현실
[Claude] “Port, Adapter, UseCase, Entity, DTO, Mapper… 이게 다 의미 있으려면 분리할 만한 도메인 로직이 있어야 합니다. 없으면 그냥 ceremony입니다.”
실용적 결론
[Claude] “AI 협업 관점에서 더 중요한 건, 레이어/폴더 구조가 일관적인가, 의존성 방향이 명확한가, 각 파일이 어디에 뭘 해야 하는지 예측 가능한가입니다.”
제안: “가벼운 레이어드” + “명시적 규칙"으로 시작, 도메인 복잡도 올라가면 Hexagonal로 진화