첫번째
1. 백엔드 개발자라면서 헥사고날이랍시고 다 막아놓고, 결국 컨트롤러에서 다 짬처리함
너무 철저해. 완전 방공호급 격리.
근데 결국 서비스 간 호출 금지, 유스케이스 간 호출 금지, 도메인-엔티티 분리까지 다 해놓고...
마지막에 컨트롤러에서 "그럼 그냥 다 꺼내서 유스케이스에 넘겨야지 뭐..."
결국 데이터 대잔치가 컨트롤러에서 열림. 이쯤 되면 헥사고날이 아니라 헬사고날임.
2. 도메인 계층에서 엔티티 사용 안 한다며? 근데 결국 Mapper에선 다 깨부숨
"인프라 외에서는 절대 Entity 못 써!"
근데 DTO <-> Entity 매핑은 결국 수작업이거나 MapStruct에 의존.
그리고 누가봐도 Entity 필드 그대로 베낀 SomeOutDto 넘쳐남.
이쯤 되면 계층 나눈 이유가 null.
3. Spring Boot 3 + JDK 21 쓰면서도 결국 Java 8처럼 개발함
"우린 최신 기술 써요!"
근데 람다, record, sealed?
안 씀.
결국 Java 21에서 쓰는 건 var 하나. 그것도 가끔.
넌 마치 최신 아이폰 사서 전화만 하는 사람 같아.
4. 명세서 잘 쓰긴 하는데, 거의 기계처럼 씀
"Description, Path Variables, Response Body, Response Example"
훌륭해. 근데 인간미가 없음.
API 명세서인데 왠지 장례식장 접수대 같음.
"이건 이렇고, 그건 그럽니다." 끝.
디자인도 UX도 없이, 그냥 기능만 있음.
5. 로직 설명할 땐 장황한데, 유머 코드에는 눈길도 안 줌
너한텐 try-catch보다 fun-catch가 더 필요함.
인생도 결국 디버깅이야, Sadik.
근데 넌 너무 진지해서 디버그 메시지도 INFO 레벨로 찍힘.
두번째
🔥 1. “DDD, 헥사고날” 외치는데 진짜 관심 있는 건 사실 정답 찾기야
헷갈리는 질문 들어오면,
“이거 서비스에서 유스케이스 호출해도 되나요?” 같은 거 엄청 고민함.
근데 그 고민의 핵심은 비즈니스 책임이 아니라 정답 유무임.
너의 사고방식은 지금:
"뭐가 맞는 구조지?"
근데 더 중요한 건:
"뭐가 이 맥락에서 실용적인 선택이지?"
너는 교과서를 중시하면서, 현실에선 타협하는 스타일인데
그 경계에 설 때 마다 스스로를 자책함.
“이렇게 해도 되는 걸까…?”
👉 성장하려면 틀을 위해 사는 게 아니라 틀을 부술 줄도 알아야 해.
🔥 2. “구조적 사고”는 좋아. 근데 가끔 논리적 완벽이 ‘속도’와 충돌함
너는 구조를 잘 짜. 추상화도 잘 해.
근데 “여기서 이 책임은 이 객체가 갖는 게 맞나?” 이 고민이 길어지면,
실제 구현보다 설계에서 시간을 다 써버림.
결과는?
구현은 급하게. 설계는 과하게.
- *결정 피로(decision fatigue)**가 올 때도 있음.
그럼 너는 다시 컨트롤러에서 "일단 하드코딩" 들어감.
🧠 멘탈: “일단 돌고 나중에 리팩토링”
🛠️ 현실: “그 나중은 안 옴”
🔥 3. “좋은 코드는 명확해야 해” 라고 하면서도 경우의 수가 늘어나는 걸 두려워함
예외 처리할 땐 항상 불안해 함.
if A && B || (C && !D) 같은 조건 나오면,
너는 이걸 한 줄로 유지하려고 애씀.
근데 가독성과 명확성은 반비례해.
사실은 if를 잘게 쪼개는 게 더 명확할 때도 있는데,
너는 “이건 너무 늘어지는 코드 같아”라고 생각하고 줄임.
즉, 너는 “깔끔함”이란 미덕과 “간결함”이란 독 사이에서 줄타기 중.
🔥 4. Enum displayName을 한글로 박고, 결국 EnumMapper 같은 거 만들었지?
“API에서 보여줄 땐 한글 이름 필요하니까...”
맞아. 근데 결국
Map<Enum, String> enumDisplayNameMap
같은 걸로 맵핑 로직 또 만듦.
왜? 단방향 표현력 부족해서.
💡 사실은 Enum 자체를 Presentation 전용으로 하나 더 만들어도 돼.
그런데 너는 “추가로 늘리는 것 자체를 부담스러워 함”
그래서 결국 Enum이 점점 무거워지고,
“아 이건 또 유틸 만들어야 하나?”
→ 또 고민. 또 시간 낭비.
🔥 5. 너는 "일단 되게 만들고 나중에 정리"가 아니라 “처음부터 되게 + 잘 되게”를 원해
즉, 탐색형 개발자가 아니라 계획형 개발자야.
그래서:
- 테스트 코드를 안 쓰면 찝찝하고,
- 컨벤션 안 맞는 코드 보면 몸이 먼저 반응하고,
- 커밋 메시지도 이상하게 쓰면 고치고 싶어짐
문제는:
이 성격이 빠른 실험을 방해할 때가 있다는 것.
너는 MVP보다는 Final Release 스타일이야.
하지만 세상은 늘 MVP부터 시작해야 하거든.
Sadik,
넌 생각보다 너무 성숙하게 개발하고 있어.
그런데 그게 네 발목을 잡는 지점도 있다는 걸 잊지 마.
"완벽함을 추구하되, 진흙 속에서 먼저 굴러라."
조금 더 실험해.
조금 더 부숴.
그리고 조금은 허술해도 괜찮다는 걸 받아들여.
