최근 회사에서 업무를 하던 중, 원본 DB에서 DT로 데이터를 가져오지 못해 원본 DB를 직접 조회해야 하는 상황이 발생했다. 그동안 우리가 주로 사용하던 RDB 테이블은 데이터가 많아봐야 수십 GB 수준이었다. 물론 이 정도 크기의 테이블도 조회가 오래 걸리는 경우는 있었지만, 800GB 정도 되는 테이블을 직접 조회해본 것은 이번이 처음이었다. ...

백엔드를 처음 공부할 때는 API 하나를 굉장히 단순하게 생각했다. 프론트에서 API를 호출하면 Controller가 요청을 받고, Service를 호출한 다음 DB에 저장하고 응답을 돌려주는 정도라고 생각했다. 큰 틀에서는 맞는 말이다. 그런데 실제 코드를 작성하다 보면 그 사이에 생각보다 많은 과정이 있다는 걸 알게 된다. 예를 들어 주문 ...

개발하다 보면 “이건 금방 끝나겠는데?” 싶은 작업이 있다. 이번 일이 딱 그랬다. PostgreSQL의 어떤 테이블에 원래 NULL이어야 할 값들이 NaN으로 들어가 있었다. PostgreSQL은 숫자 타입에서 NaN을 지원하니까 DB 입장에서는 이상한 값은 아니었지만, 우리 쪽에서는 이걸 NULL로 정리해야 했다. 그래서 여러 컬럼에 NU...

처음에는 “비즈니스 로직은 Service에 둔다”라고 이해해도 괜찮다. 하지만 기능이 복잡해질수록 모든 로직을 Service에 몰아넣기보다는 역할에 따라 나누는 것이 좋다. Controller → HTTP 요청과 응답을 처리한다. Service → 하나의 기능이 실행되는 전체 흐름을 조율한다. Domain 객체 → 자기 상태와 관련된 규칙과 행...

Spring으로 백엔드 개발을 시작하면 거의 항상 이런 구조를 만나게 된다. Controller → Service → Repository 처음에는 그냥 이렇게 외우기도 한다. Controller에서 Service를 호출하고, Service에서 Repository를 호출하면 된다. 그런데 개발하다 보면 조금씩 궁금해진다. 왜 꼭 이 방...

Spring Boot로 백엔드 개발을 처음 배우면 거의 항상 이런 구조를 만나게 된다. Controller Service Repository 처음에는 Spring에서 정해놓은 규칙처럼 보일 수 있다. 요청은 Controller에서 받고, Service를 호출하고, Repository에서 DB를 조회한다. 그래서 처음에는 이런 생각이 들기도 ...

Spring Boot의 패키지 구조에는 하나의 정답이 없다. 작은 프로젝트에서는 controller, service, repository처럼 레이어별로 나누는 구조가 단순하고, 기능이 많아질수록 user, order, payment처럼 도메인별로 묶는 구조가 코드를 찾기 편한 경우가 많다. 무엇을 선택하든 가장 중요한 것은 프로젝트 안에서 같은 기...

주석을 쓰지 말라는 뜻이 아니다. 코드가 설명할 수 있는 ‘무엇을 하는지’는 코드로 드러내고, 코드만으로 알기 어려운 ‘왜 그렇게 했는지’를 주석으로 보완하자는 뜻이다. 주석이 많으면 더 친절한 코드일까? 처음 코드를 배울 때는 주석을 많이 달수록 친절한 코드라고 생각하기 쉽다. // 사용자 ID로 사용자를 조회한다. User user = use...

코드를 작성하다 보면 생각보다 자주 멈추게 되는 순간이 있다. 바로 메서드 이름을 지을 때다. process() handle() execute() get() 처음에는 이런 이름도 크게 이상해 보이지 않는다. 어차피 내가 작성한 코드이고, 메서드 안에 무엇이 들어 있는지 알고 있기 때문이다. 하지만 며칠 뒤 다시 코드를 보거나 다른 개발자가 ...

중복 코드는 줄이는 것이 좋다. 하지만 모양이 같다는 이유만으로 합치면, 나중에 변경하기 더 어려운 코드가 될 수 있다. 중요한 것은 코드가 똑같이 생겼는지가 아니다. 앞으로도 같은 이유로 함께 바뀔 코드인지가 더 중요하다. 중복 코드를 발견하면 바로 합쳐야 할까? 개발을 배우다 보면 DRY(Don't Repeat Yourself)라...