고민되는 문제
약 4개월 정도 실무를 경험해보면서 주니어 백엔드 개발자로서 궁금한 점이 한두가지가 아니다. 그래서 이러한 의문사항을 직장동료들과 토론해보고 계속 자료를 찾아보았다. 하지만 명쾌한 답을 얻지는 못 한것들이 많다.
테스트 커버리지 수준
이 부분은 동료 백엔드 개발자 분들과 토론을 한 적이 있다. 이응준 님의 테스트 커버리지 100%는 커녕 50%도 쉽지 않았다. 테스트 커버리지를 얼마나 잡는가? 1 + 1 = 2 라는 당연한 부분도 테스트 코드를 꼭 작성해야 하는가? 어떤 메서드를 우선적으로 테스트 할 필요가 있는가? 이 부분은 여러가지 프로젝트를 그 필요성이 많이 느껴지는 부분이 있다. 우선은 70%라도 목표로 잡고 진행해 보아야겠다.
MSA
MSA와 외부 API를 연동하는 것의 차이가 무엇인가? MSA의 정확한 개념을 알아야 그 차이를 알 수 있을 것이다. 그렇다면 MSA로 구성할 경우 성능을 어떻게 개선할 수 있는가? 그리고 외부 API 연동할 때의 성능은 어떻게 개선할 수 있는가?
웹 캐싱
개발바닥 영상 하나를 보면서 줌 인터넷 뿐만 아니라 다음 검색 웹 서비스를 개발하면서 주로 API 붙이고, 캐싱을 하는 것을 계속 반복한다고 들었다. 그 캐싱을 하기위한 관리 시스템으로서 Redis나 Memcached 등이 있다. 그렇다면 Redis나 Memcached 또는 EHCache를 어떻게 사용하여 컨텐츠를 서빙하는 성능을 높일 수 있는가? 이는 Redis를 활용한 스프링 프로젝트를 테스트 해봄으로써 원리를 익히고 실무에 적용하면 될 것 같다.
DB 쿼리 튜닝과 인덱싱
인덱싱을 어떻게 걸고, 쿼리를 어떻게 튜닝해야 성능을 높일까? 먼저 인덱싱에 있어서 특정 테이블에 인덱스를 추가하는 것은 단순히 추가한다고 해결되는 것이 아니다. 특정 컬럼에 대한 인덱스를 걸었을 때 이에 연관된 다른 쿼리들이 느려질수도 있다. 쿼리 튜닝은 애초에 기본 원칙을 준수하면서 쿼리를 작성하면 최소한의 성능은 보장된다. 쿼리 튜닝의 기법들을 적용하면서 일종의 쿼리 리팩토링을 진행하고, 테이블 구조 자체가 이상적인 구조가 맞는지 추가적으로 검토할 필요가 있다.
JPA에 대한 이해
JPA 영속성 컨텍스트의 동작원리, 흐름을 정확히 알고 그림으로 그려보기 -> 김영한님의 JPA 강의를 듣고 책을 읽으면서 JPA라는 ORM의 원리를 이해
테스트 코드와 Mockito
테스트코드 작성을 위해 모키토를 사용하는 방법
테스트코드 작성을 위해 모키토 대신에 인터페이스를 상속하는 간이 클래스를 사용하는 방법
REST API의 구조
API를 한방에 다 보내는 것이 좋은지? 아니면 페이지별로 요청을 오도록 하는게 나은지? API 설계는 항상 고민이다. 프론트엔드 개발자분과 같이 개발을 진행하면서 프론트와 백엔드 중 어디에서 해당 로직을 담당할지
웹 서비스에서의 성능의 계층적 구조
성능의 우선순위? 클라이언트 > API 서버 통신 > DB접근(I/O)
새로운 엔티티 여러 개 동시에 생성 시
새로운 엔티티를 생성할때 프론트에서 구분이 안가서 경고가 뜨면 0.1234 처럼 소수로 보내고 Long으로 받아서 0L로 자르는 테크닉? 바람직한지
DB 문서화 및 형상관리
레거시 코드와 레거시 DB?를 볼때 항상 해당 테이블과 해당 컬럼이 무슨 역할을 하는지 일일이 코드를 통해 일종의 리버싱을 해야해서 너무 곤란한 적이 많았다. DB를 문서화 하기 좋은 방법은 무엇이 있을까? 그냥 워크벤치에서 description 필드에 설명만 적어두어도 훨씬 알아보기 쉬웠을텐데 아쉽다. 그리고 DB의 계속적인 변화에 대해 코드를 형상관리하듯이 형상관리 하면 좋을것 같다는 생각이 들었다. 물론 스키마에 대한 sql 스크립트를 코드로 저장하면서 형상관리 할수도 있지만, 현재의 DB 스키마 자체를 직접 관리하고 싶은 경우 Flyway나 관련 툴이 몇개는 있는것 같다. DB형상관리
에러가 발생할 때의 원인 찾기
항상 에러가 발생하면 원인을 찾기위해서 이것저것 바꿔보면서 테스트 한다. 로컬에서는 되는지, 서버에 배포했을 때만 안되는지, 서버에서 안된다면 해당 요청에 대해 서버에 접속해 curl로 직접 요청이 되는지 등 여러가지 조건을 바꿔가면서 테스트하면 분명히 어느 대조군에서 에러가 발생하는지는 알 수 있다. 가령, 다음과 같은 경우가 있었다.
배포를 했는데 갑자기 프론트에서 라이브러리를 하나도 못 끌어온다. -> 로드밸런서가 제대로 동작하지 않아 갈아끼우기 전의 인스턴스에 해당하는 주소를 참조하여 발생
로컬에서는 된다 -> 배포 후 서버에서 안된다 -> CORS나 주소 설정 등은 다 맞추어져 있다 -> 서버에 직접 접속해서 curl을 날려본다 -> 서버의 IP가 해외라서 외부업체 API로부터 차단당함
벨리데이션이 필요한 경우
조영호님의 우아한 객체지향 발표를 보면 장바구니 구현을 예로 들면서 검증의 중요성을 강조한다. 커머스 분야에서는 이러한 검증이 당연히 필요할 것이고, 이외에도 어떠한 부분에서 검증이 들어가야 정확할지 매순간 판별하기가 쉽지 않은것 같다. 아직 나의 수준에서는 문제가 발생하면 비로소 원인을 파악 후, 해당 문제에 대한 검증 코드를 추가하는 것이 최선이다. 이러한 경험이 쌓이면 사전에 검증을 충분히 하는 코드를 작성할 수 있을 것 같다.
