조금 쓸 내용을 정리하다 보니 읽을거리가 엄청나게 길어져서, 여러 번에 나누어 게시하겠습니다.

일단 각 기사에는 전체 링크도 준비해 둘 테니, 순서대로 읽어주시면 감사하겠습니다.

이 기사는 여러 AI와 채팅한 결과를 정리한 것입니다.

안녕하세요, AI 퍼스트(AI-first)적인 사고를 가진 에스케(え～すけ)입니다.

AI에게 구현을 완전히 맡기며 프로젝트를 진행하다 보니,

• 인간이 읽기 쉬운 깔끔한 폴더 구성이나 코드를 작성할 필요가 있을까?
• 인간이 이해하기 쉬운 폴더 구성이나 코드는 AI에게 어떤 의미일까?

라는 의문이 생겨서, AI에게 아키텍처는 어떤지 물어보았습니다.

우선은 직설적으로 물어보았습니다.

🤔 에스케

"AI만으로 대규모 시스템을 개발·유지보수한다면, 지금의 아키텍처가 최적인가요?"

그러자 AI로부터 돌아온 대답은 의외였습니다.

🤖 AI

"인간을 위한 베스트 프랙티스 (Best Practice)를 그대로 AI에게 적용하는 것은 최적이 아닐 수도 있습니다."

어라...?

"인간용"과 "AI용" 사이에 차이가 있는 걸까?

그렇게 생각되어 이유를 물어보았습니다.

🤔 에스케

"그게 무슨 뜻이야?"

🤖 AI

"인간은 코드를 작성하는 비용이 높지만, AI는 코드를 작성하는 비용이 거의 제로입니다."

🤖 AI

"그 대신, AI에게 가장 비용이 많이 드는 것은 코드를 이해하기 위해 대량의 파일을 읽는 것입니다."

듣고 보니 확실히 그렇습니다.

인간은 같은 코드를 여러 번 쓰는 것이 번거롭기 때문에,

• 공통화한다
• Util에 모은다
• DRY (Don't Repeat Yourself)를 의식한다

라는 사고방식을 갖게 됩니다.

하지만 AI는 다릅니다.

코드를 작성하는 것 자체는 몇 초면 끝납니다.

반면에,

• 공통 Util은 어디 있지?
• 어떤 클래스를 사용하면 되지?
• 다른 곳에도 비슷한 구현이 있나?
• 수정하면 다른 곳에 영향이 가지 않을까?

와 같은 확인을 위해 많은 파일을 읽어야 합니다.

즉, AI에게는 "쓰는 비용"보다 "읽는 비용"이 압도적으로 높다는 뜻이 됩니다.

여기서 다시 의문이 생겼습니다.

🤔 에스케

"그럼 지금까지 옳다고 여겨져 온 DRY는 AI 시대에도 정말 정의인가?"

그러자 AI는 잠시 생각한 뒤, 이런 대답을 돌려주었습니다.

🤖 AI

"인간만 개발한다면 DRY는 지금도 매우 유효합니다."

🤖 AI

"하지만 AI만으로 개발·유지보수하는 것을 전제로 한다면, 평가 축이 바뀔 가능성이 있습니다."

평가 축이 바뀐다...?

여기서부터 "AI가 읽기 쉬운 설계란 무엇인가?"라는, 지금까지 생각해 본 적도 없는 이야기로 이어졌습니다.

DRY 이야기를 듣고 다음에 궁금해진 것은 폴더 구성입니다.

최근에는 Feature First가 인기를 끌고 있는데, AI가 보기에도 좋은 구성일까요?

그래서 물어보았습니다.

🤔 에스케

"그럼 폴더 구성은 어때? AI가 개발한다면 무엇이 좋다고 생각해?"

그러자 AI는 망설임 없이 이렇게 대답했습니다.

🤖 AI

"AI만으로 개발한다면, Feature First는 궁합이 매우 좋다고 생각합니다."

"호오, 역시 그런가."

이유를 물어보기로 했습니다.

🤔 에스케

"왜 Feature First가 좋아?"

🤖 AI

"AI는 한 번에 대량의 코드를 이해하는 것을 어려워하기 때문입니다."

예를 들어, 전통적인 레이어 구성 (Layered Architecture)이라면 이런 느낌이 됩니다.

controllers/
services/
repositories/
...

주문 기능을 수정하고 싶을 뿐인데,

• Controller
• Service
• Repository
• Entity

와 같이 여기저기 폴더를 찾아가야 합니다.

반대로 Feature First라면,

features/
order/
user/
...

주문 기능을 수정하고 싶다면,

features/order

만 보면 될 가능성이 높아집니다.

확실히 이것은 AI뿐만 아니라 인간에게도 이해하기 쉬워 보입니다.

게다가 AI는 이런 말도 했습니다.

🤖 AI

"AI는 큰 일을 한 번에 해내는 것보다, 작은 일을 수없이 처리하는 것을 더 잘합니다."

예를 들어,

"주문 기능을 전부 만들어줘"

라는 의뢰보다,

• 주문 목록 API를 만든다
• 주문 등록 API를 만든다
• 주문 취소 API를 만든다

이와 같이 세분화하는 것이 AI가 안정적인 코드를 생성하는 데 도움이 됩니다.

이것은 사람도 마찬가지입니다.

"시스템 전체를 만들어줘"라고 듣는 것보다, "이 기능만 부탁해"라고 듣는 편이 작업하기 쉽습니다.

여기서 약간 심술궂은 질문을 던져보았습니다.

🤔 에스케(え～すけ) 씨

"그럼, 전부 Feature(기능) 단위로 가두어 버리면 최강이라는 뜻이야?"

그러자 AI는 잠시 생각한 뒤, 다음과 같은 답변을 돌려주었습니다.

🤖 AI

"아니요. 공유해야 할 것까지 Feature에 가두는 것은 위험합니다."

어라?

Feature First를 지지하고 있는데, 벌써 부정적인 의견이 나왔습니다.

도대체 무슨 뜻일까요?

예를 들어, 다음과 같은 테이블이 있다고 가정해 봅시다.

users
id
name
...

이를 Feature별로 관리하면,

features/
order/
UserEntity
...

와 같이 됩니다.

여기서,

users
+ icon_url

라는 컬럼 추가가 있었다고 가정해 봅시다.

자, 수정이 필요한 곳은 어디일까요?

• order?
• login?
• profile?
• 전부?

AI는 검색을 통해 찾아낼 수 있을지도 모릅니다.

하지만 "어디까지 영향이 미치는지"에 대한 판단은 사람에게도 AI에게도 어려워집니다.

그래서 AI가 제안한 것이 조금 흥미로운 사고방식이었습니다.

🤖 AI

"책임(Responsibility)뿐만 아니라, 『변경 이유(Reason for Change)』에 따라서도 모듈을 나누는 것이 좋을지도 모릅니다."

처음에는 무슨 말을 하는지 알 수 없었습니다.

자세히 물어보았습니다.

🤔 에스케(え～すけ) 씨

"변경 이유?"

🤖 AI

"같은 이유로 변경되는 것들은 가까이 두고, 다른 이유로 변경되는 것들은 분리한다는 생각입니다."

예를 들어,

• 주문 화면
• 주문 API
• 주문 비즈니스 로직 (Business Logic)

이것들은 "주문 사양이 변경된다"라는 동일한 이유로 함께 수정되는 경우가 많습니다.

반대로,

users

테이블은,

• 주문
• 로그인
• 회원 관리

등 여러 기능에서 이용됩니다.

즉,

"DB 스키마 변경"이라는 별개의 이유로 수정되는 경우가 많은 것입니다.

그렇게 생각하면,

shared/
database/
features/
...

라는 구성이 더 자연스러울지도 모릅니다.

솔직히 이 답변을 듣고 처음에는

"아니 아니, 그렇게 편하게 나눌 수 있다고?"

라고 생각했습니다.

하지만 생각해 보면, 실제 유지보수에서도

"이 수정, 어디까지 영향을 줄까..."

라며 고민하는 일은 자주 있습니다.

만약 AI가 주체가 되어 개발·유지보수를 하는 시대가 온다면,

"책임"뿐만 아니라 "변경 이유"도 설계의 기준이 된다.

그런 시대가 올지도 모릅니다.

여기서 또 다른 의문이 생겨났습니다.

🤔 에스케(え～すけ) 씨

"그럼, 공통 Util(유틸리티)은 어떻게 되는 거야?"

지금까지 당연하다는 듯이 만들어 왔던 DateUtil이나 StringUtil.

AI는 이것들을 어떻게 생각하고 있을까요.

다음은 그 이야기를 들어보기로 했습니다.