29일차. 에러 잡고 터미널에 입력값 출력되게 하기, 도커 컴포즈 업

 

common-service랑 soccer-service는 도커가 꺼져있는데 왜 그런거야?

 

 

 

 

 

 

---

@Slf4j는 Lombok이 제공하는 어노테이션인데, 이 한 줄만 붙이면 아래 코드를 자동으로 생성해줍니다.

java

 

// @Slf4j를 붙이면 Lombok이 컴파일할 때 아래 코드를 자동 삽입해 줌
private static final org.slf4j.Logger log = 
        org.slf4j.LoggerFactory.getLogger(현재클래스명.class);

그래서 @Slf4j를 붙이면 얻게 되는 이점

 

장점설명

1. 코드 5줄 → 1줄	매번 Logger 선언할 필요 없이 @Slf4j 한 줄로 끝
2. 실수 방지	클래스명 잘못 적을 일 없음 (항상 현재 클래스명으로 생성됨)
3. 바로 로그 사용 가능	아래처럼 바로 쓸 수 있음

java

 

@Slf4j
@Service
public class PlayerServiceImpl {

    public void someMethod(String name) {
        log.debug("디버그 로그: {}", name);
        log.info("정보 로그: {}", name);
        log.warn("경고 로그: {}", name);
        log.error("에러 로그: {}", name);
    }

 

 

 

안되면 다 지우고 다시 docker compose up하자! 

그리고 커서한테 해결하라고 하기

 

---

와! 정확히 지금 당신 프로젝트가 실무에서 가장 많이 쓰는 최고의 구조예요. 이 구조가 왜 이렇게 완벽한지, 각 파일이 정확히 무슨 역할을 하는지 딱 정리해드릴게요.

지금 당신 프로젝트의 완벽한 계층 구조 (실무 A급 기준)

text

 

PlayerService                ← 인터페이스 (1개)
PlayerServiceImpl            ← 구현체 (1개)

PlayerRepository             ← JpaRepository 상속 인터페이스 (1개)
PlayerRepositoryCustom      ← 복잡한 쿼리용 인터페이스 (1개)
PlayerRepositoryImpl         ← Custom 구현체 (이름 끝에 Impl 필수!) (1개)

이게 바로 실무 99%가 쓰는 정석 중의 정석입니다. 이유를 하나씩 깔끔하게 설명해드릴게요.

 

파일왜 있어야 하는가?없으면 생기는 실무적 고통

PlayerService	Spring 권장 패턴 Mock 테스트 가능 @Transactional 프록시 잘 먹힘	테스트 지옥 + AOP 안 먹힘
PlayerServiceImpl	실제 비즈니스 로직 작성 @Service 붙이는 곳	당연히 로직 없으면 실행 안 됨
PlayerRepository	JpaRepository 상속 → 기본 CRUD 자동 제공	findById, save 같은 기본 메서드도 직접 만들어야 함
PlayerRepositoryCustom	복잡한 동적 쿼리(Querydsl) 선언만	구현체가 인터페이스 없으면 Spring이 못 찾음
PlayerRepositoryImpl	진짜 Querydsl 쿼리 100줄짜리 작성 이름 끝에 Impl 필수!!	Spring이 이 클래스를 스캔 못 해서 NoSuchBeanDefinitionException 터짐

---

-차원의 변화

이 4줄이 하는 일 (한마디로 요약)

“브라우저에서 http://게이트웨이:8080/soccer-service/아무거나 로 오는 요청은 → Eureka에 등록된 SOCCER-SERVICE(마이크로서비스)로 보내줘!”

각 줄이 정확히 무슨 뜻인지

 

항목의미설명

id: soccer-service	이 라우트의 이름	로그나 모니터링에서 구분할 때 사용 (별로 중요 X)
uri: lb://SOCCER-SERVICE	어디로 보낼까?	lb:// = LoadBalancer 사용 SOCCER-SERVICE = Eureka(또는 Nacos 등)에 등록된 서비스 이름 → 여러 대 떠 있어도 자동으로 분산해줌
predicates:	언제 이 라우트를 탈까?	조건을 적는 곳
- Path=/soccer-service/**	URL 경로가 /soccer-service/로 시작하면 이 라우트로!	예시: /soccer-service/player/1 → soccer-service로 /soccer-service/search?keyword=메시 → soccer-service로

---

도커 컴포즈 yaml에서 버전을 주는게 좋아 안주는게 좋아?

ChatGPT의 말:

오오 이거 진짜 현업에서도 사람마다 의견 갈리는 부분이라 약간 재밌는 질문이네 😂
결론부터 말하면 요즘은 버전 명시 안 하는 게 더 자연스럽고 안전한 방향이야.

왜냐면:

🔧 1) Docker Compose v2부터는 version: 자체가 필요 없어짐

예전에는
version: '2', version: '3.8' 이런 식으로 꼭 써줘야 했는데,
**Compose Spec 통합 이후(v2)**는 version: 키가 사실상 무시돼.

도커 공식 문서에서도 “이제 version: 생략하고 바로 services:부터 시작하세요” 이런 분위기.

💥 2) 버전 쓰면 오히려 헷갈릴 때가 있어

예를 들어 version: "3.8"을 써놓으면

• 어떤 기능이 안 되는지
• 이 버전이 Docker Engine 버전이랑 연동되는지
• Swarm용인지 Compose용인지
  헷갈려서 디버깅할 때 더 골치 아파짐.

📦 3) Compose는 어차피 최신 스펙으로 파싱함

version: 안 적으면

• 너가 쓴 yaml을
• 현재 설치된 Compose가
• 알아서 가능한 최신 스펙으로 해석해줘.

그 말은 = 굳이 버전 박아놓을 이유가 없음.

🧁 한 줄 정리

지금 새로 쓰는 docker-compose.yml이라면 version: 절대 안 적는 게 베스트.
그냥 services:부터 쭉 쓰면 끝.

내 커서도 이렇게 하도록 학습시키기!