내 주력 언어의 특징 - JAVA (Feat. KPT 회고)

 

 

이 글은 알파코에서 진행 중인 [신한투자증권] 프로디지털아카데미 6기 과정 중 백엔드 과목의 김송아 강사님의 강의를 기반으로 작성되었습니다

 

 

🖋️ 나는 왜 Java를 주력 언어로 쓰는가

내 주력 언어는 Java다.

Java의 여러 특징 중에서도 가장 중요하게 생각하는 것은 바로 객체 지향 패러다임을 깊이 있게 지원한다는 점이다.

 

강사님께서 '객체가 무엇일까요?' 라고 물으셨을 때 나는 다음과 같이 정의했다.

현실 세계의 사물이 속성과 행동이 가지고 상호작용하듯, 데이터와 그 데이터를 처리하는 행위를 하나로 묶은 것

 

 

강사님의 정의는 이랬다.

객체는 주어 자리에 넣고 동사로 문장을 만들 수 있는 모든 것이다.

 

더 간결한 정의를 내려주셨다.

 

두 정의를 곱씹으며, 결국 객체 지향의 본질은 '자신만의 역할과 책임을 가진 주체'를 명확하게 설계하는 것에 있다는 사실을 다시 한번 깨달았습니다.

 

 

 

 

⚙️ 좋은 설계의 핵심: 역할과 책임

나는 객체 지향에서 가장 중요한 것은 객체 설계라고 생각한다.

'잘 설계된 객체'란, 각 객체가 맡은 역할을 명확하게 수행하여 시스템이 유기적으로 돌아가게 하는 것이다.

 

 

 

 

📌 실제 적용 - 프디아 본프로젝트

프디아에서 진행했던 본프로젝트에서도 백엔드 개발은 Java + Spring Boot로 진행했다.

우리가 채택한 구조는 도메인 중심 설계(DDD) 스타일이었다.

모든 기능을 도메인(엔티티) 단위로 묶고, 그 안에서 해당 도메인에 필요한 Service, Controller, DTO, Repository 등을 관리하는 방식이다.

 

폴더 구조 설계

우리 프로젝트의 주요 패키지 구조는 이랬다.

- common
    - config
    - handler
    - response
    - util
- domain
    - disclosure
    - earning_call
    - investment_type
    - investment_type_news_comment
    - member
    - member_stock
    - news
    - notification
    - scrap_group
    - scrap_grouped
    - source
    - stock
    - summary
    - user_scrap
- presentation
    - member
    - notification

 

domain 안에는 interface, service, model이 있고, presentation에는 controller와 dto가 있었다.

 

 

구조 선택 이유

이 구조를 선택한 이유는 크게 세 가지다.

 

1. 도메인 별로 코드 모아두기

예를 들어 news 관련 기능을 수정해야 한다면 domain/news 폴더만 보면 되도록 설계했다. 관련 Service, Repository, DTO가 흩어져 있지 않으니 코드 탐색 속도가 빠르다.

 

2. 공통 기능의 재사용성 확보

common 폴더에 공통 설정(config), 예외 처리(handler), 응답 포맷(response), 유틸(util)을 모았다.

 

3. 계층 책임 명확화

presentation 계층은 요청(Request)과 응답(Response) 처리만 담당하도록 분리했다.

예를 들어 NotificationController는 오직 NotificationSevice로만 비즈니스 로직을 위임한다.

이렇게 하면 의존성 방향이 단방향으로 유지되어 유지보수성이 높아졌다.

 

 

 

 

실제로 얻은 장점

이 방식은 개발 과정에서 여러 긍정적은 효과를 줬다.

• 변경 범위 최소화
  notification 기능에 스케줄러(NotificationScheduler)를 추가할 때 다른 도메인에는 영향이 거의 없었다.
• 협업 효율 향상
  팀원별로 도메인을 나눠서 맡을 수 있어 충돌 가능성이 줄었다.
• 테스트 용이성
  도메인별로 독립적인 단위 테스트 작성이 가능했고, 버그 추적 속도도 빨랐다.

 

남은 궁금증과 나름의 정리

프로젝트가 끝났지만 아직도 헷갈리는 부분이 있다.

바로 두 개 이상의 엔티티(Model)을 함께 사용하는 서비스 코드는 어디에 둬야 할까? 하는 점이다.

 

예를 들어

• NotificationService가 알림을 만들기 위해 뉴스와 회원 데이터를 같이 써야 하는 경우
• SummaryService가 요약을 만들 때 투자성향 코멘트까지 함께 생성하는 경우

이런 상황에서는 '그럼 이 서비스는 summary 폴더에 둬야 할까, investment_type_news_comment 폴더에 둬야 할까? 하는 고민이 생긴다.

 

찾아보고 정리한 나름의 기준을 이렇다.

 

1. 결과물이 속하는 곳에 넣기
   - 최종적으로 만들어지고 저장되는 게 요약이라면 -> summary 폴더
2. 여러 엔티티를 그냥 연결만 하는 경우
   - 각각의 엔티티는 자기 역할만 하고, 서비스가 단순히 '이거 하고, 저거 한다' 순서만 정한다면 공용으로 쓰는 상위 폴더에 따로 두는 게 깔끔하다.
3. 둘이 꼭 같이 움직여야 하는 경우
   ex) 요약을 만들 때 항상 코멘트도 같이 만들어야 하는 경우
   -> 그 규칙을 더 책임지는 쪽 폴더에 두기
   만약 '요약 생성'이 프로젝트에서 더 중요한 핵심 흐름이라면 summary 폴더에 두는 게 맞다.

 

아직도 완벽하게 확신이 있는 건 아니지만, 이렇게 기준을 정리해 두니 다음 프로젝트에서는 조금 더 빠르게 판단할 수 있을 것 같다.

 

 

 

🪞 KPT 회고

Keep (유지할 점)

• 도메인 중심 구조로 코드 관리 -> 유지보수성과 확장성 향상
• common 폴더로 공통 기능을 중앙화 -> 재사용성, 일관성 확보
• 계층 간 역할을 명확히 분리 -> 의존성 구조가 깔끔해짐

Problem (아쉬운 점)

• 두 개 이상의 엔티티를 함께 사용하는 서비스의 위치 결정이 애매함

Try (개선할 점)

• 서비스 위치 결정 기준을 적용해 일관성 있는 구조 유지
• 복합 도메인 로직은 application 계층 등 별도 모듈로 분리 검토