도메인 학습과 기술 실험을 분리하는 두 가지 트랙

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

개인 프로젝트는 두 질문 중 하나에 답할 수 있다. 도메인이나 제품 아이디어가 어떻게 동작하는지, 또는 낯선 기술이 어떻게 움직이는지다. 둘을 한꺼번에 풀면 큰 미지수가 두 개 생긴다. 그래서 익숙한 기술로 띄우는 서비스와 한 기술만 남긴 평범한 실험으로 나눈다.

첫 번째 트랙: 익숙한 기술로 도메인을 서비스에 올린다

도메인을 비슷하게 경험하거나 사업 아이디어를 검증하려면 이미 아는 기술로 작은 버전을 빨리 만든다. 저장소에서 멈추지 말고 배포한 뒤 실행 중인 서비스를 계속 발전시킨다. 스택을 배우느라 시간을 쓰기보다 제품과 도메인을 배우는 것이 목적이다.

서비스를 올린 뒤에도 구조는 실험할 수 있다. 레이어를 아예 쓰지 않거나, JPA 엔티티를 도메인 객체로 함께 쓰는 방식과 영속성을 숨기는 방식을 비교해 볼 수 있다. 집중된 성능 테스트를 하면 선택한 구조의 실제 한계를 보고 서비스에 부하를 주는 경험도 얻는다.

이 트랙에서 낯설어야 하는 것은 도메인 질문이다. 익숙한 구현 도구가 배워야 할 지점까지 가는 시간을 줄여 준다.

두 번째 트랙: 기술 실험은 단일 모듈까지 줄인다

Redis, 메시징 시스템, 검색 엔진, 리액티브 스택이 목적이라면 최소한의 단일 모듈 프로젝트로 시작한다. 복잡한 모듈화와 도메인 규칙을 내려놓는다. 명령을 직접 써 보고 부하를 주며 기술 자체의 동작을 본다. 제품 출시가 목적이 아니므로 작은 저장소로 남겨도 된다.

여기에도 성능 테스트가 들어간다. 기술이 어떻게 움직이고 나중에 어떻게 쓸 수 있을지를 보기 위해서다. 유닛 테스트도 할 수 있지만 완전한 도메인을 만드는 것보다 직접 사용하고 성능을 집중해서 살피는 데 무게를 둔다.

낯선 커머스 도메인과 낯선 메시징 플랫폼을 합치면 모르는 것에 모르는 것을 더한다. 내 경우 두 트랙을 섞었을 때 양쪽 모두 진도가 흐려지는 일이 많았다. 둘을 잘 합쳐 배우는 사람도 있으므로 보편 법칙이 아니라 개인적인 학습 패턴이다. 비슷한 성향이라면 질문을 먼저 이름 붙이는 것만으로 프로젝트가 끝나지 않은 두 실험이 되는 일을 피할 수 있다.