“백엔드 핵심 개념을 왜 배워야 하죠? AI가 다 만들어 주는데.”

틀린 말이 아닙니다.
요구사항을 설명하면 코드가 나옵니다.
설계가 엉망이어도, 도메인 로직이 뒤엉켜도, 일단 돌아가는 무언가가 나옵니다.

그런데 AI는 코드를 만들어 줄 뿐, 판단하지 않습니다.

REST API가 올바른 리소스를 중심으로 설계됐나요?
도메인 로직이 도메인 객체 안에 올바르게 응집되어 있나요,
아니면 여러 곳으로 흩어져 있나요?
테스트가 올바른 동작을 검증하나요, 아니면 구현 세부사항에 얽매여 있나요?

AI는 이 질문에 답하지 않습니다. 코드만 만들어 줄 뿐입니다.

백엔드 핵심 개념은 코드를 작성하기 위해 배우는 게 아닙니다.
AI에게 올바르게 지시하고, AI가 만든 코드를 판단하기 위해 배웁니다.

개념을 알아야 판단할 수 있습니다

AI는 URL을 금방 만들어 줍니다.
하지만 URL보다 먼저 정해야 할 것이 있습니다.
리소스가 무엇인가입니다.
리소스를 제대로 식별하면 URL은 자연스럽게 따라오고,
Controller가 어떻게 조직돼야 하는지도 보입니다.

AI는 DI 코드도 잘 만듭니다.
하지만 의존 방향이 올바른지는 보장하지 않습니다.
비즈니스 로직이 기술적 세부사항에 의존하게 되면
Layered Architecture는 이름뿐이 됩니다.

AI에게 기능을 맡기면 도메인 로직이 객체 밖으로 새나오기 쉽습니다.
처음에는 괜찮아 보입니다.
문제는 규칙이 늘어날 때 생깁니다.
응집성이 떨어진 코드는 AI도 버그 없이 고치기 어렵습니다.

AI가 만든 테스트는 그럴듯합니다.
하지만 테스트가 올바른 동작을 검증하는지,
아니면 구현 세부사항에 얽매여 있는지는 별개의 문제입니다.

AI는 DB 테이블도 만들고 JPA Entity도 만들고 매핑도 해줍니다.
하지만 객체의 세계와 관계형 데이터베이스의 세계는 근본적으로 다릅니다.
그 차이를 이해하지 못하면 AI가 만든 매핑이 왜 그렇게 됐는지,
어디서 문제가 생길지 보이지 않습니다.

개념을 알아야 이 판단을 내릴 수 있습니다.
그리고 개념을 알아야 AI에게 제대로 지시할 수도 있습니다.

아키텍처는 트레이드오프입니다

모듈러 모놀리스로 갈까요, 마이크로서비스로 나눌까요?
같은 트랜잭션 안에서 처리할까요, 메시지 큐로 비동기 처리할까요?

이 질문들은 무엇이 더 유행하는지를 고르는 게 아닙니다.
운영 복잡도, 장애 전파, 배포 독립성, 데이터 일관성을
어떻게 가져갈지 결정하는 일입니다.

좋은 아키텍처를 고르는 질문은 “무엇이 더 멋있는가”가 아닙니다.
“지금 우리에게 무엇이 더 중요한가”입니다.

이 판단은 AI가 대신해 주지 않습니다.

AI가 더 많이 만들수록, 더 많이 필요합니다

AI는 코드를 빠르게 만들어 줍니다.
하지만 빠르다고 올바른 건 아닙니다.

리소스 식별, 의존 방향, 도메인 응집, 테스트 전략, 아키텍처 선택.
이 글에서 다루지 못한 것들도 많습니다.
이 판단들은 AI가 대신해 주지 않습니다.

AI가 더 많은 코드를 만들수록,
올바르게 지시하고 결과를 판단할 수 있는 개발자가 더 필요해집니다.

와일드 백엔드 강의에서 이 개념들을 함께 다룹니다.