공부

카테고리 기능을 구현하기로 했다.처음에는 카테고리의 구조가 확정이 안 되어 있고, 객체로 변환 처리를 어떻게 할까 고민하다가 그냥 도메인 객체를 NoSQL에 저장해 버리면 어떨까 생각했다. 하지만 나중에 생각해 보니 카테고리를 수정하거나 삭제할 때, 문제가 발생할 여지가 있었고, 카테고리의 계층 간 엄격한 관리가 필요하다는 것을 반영하여 RDBMS를 사용하기로 했다. 카테고리는 추가나 수정이 빈번하게 이루어지지 않기 때문에 조회에서 발생하는 성능의 차이는 나중에 캐시를 사용해서 극복할 수도 있었다. 그래서 SQL로 카테고리를 조회하는 기능을 구현해 보았다.  준비하기 RDBMS는 MariaDB를 사용하였다. 사실 계층형 쿼리를 사용하기 쉬운 DBMS는 오라클이다. 그냥 START WITH를 사용하면 되기..

테스트 관련 강의를 들으면서 지금까지 테스트에 대해 너무 소홀히 했던 것이 아닌가 돌아보게 되었다. 그동안은 단순히 기능 개발에만 몰두해서 테스트는 나중에 직접 실행해보는 식으로 했었는데 언젠가 고쳐야지 생각만 하다가 이제서야 신경쓰게 되었다. 그런데 강의를 듣다보니까 좋은 테스트를 위한 코드가 좋은 설계를 위한 코드와 일맥상통한다는 점이 신기했다. 그러니까 테스트를 위한 코드를 작성하면 좋은 구조로 설계할 확률이 올라간다는 것이다. 그동안 공부했던 DDD와 추가로 알게된 헥사고날 아키텍처도 다른게 아니라 서로 연관이 있는 부분이 컸다.  도메인 위주로 리팩토링하기  위의 구조가 현재 프로젝트 구조이다.어느 정도 계층을 나눠서 구현하려 했지만 도메인별로 파악하기가 쉽지 않고, 실제로 코드로 들어가보면 도..

지난번에는 kubeadm으로 직접 구성하는 방식을 진행해보았다면 이번에는 Kubespray를 사용하여 진행해보기로 했다. 기본적으로 클러스터 구성은 최소 3개이지만, 단순 실습만을 위해 다음과 같이 구성했다. control-plane 1개worker-node 2개 실습 환경은 Ubuntu 24.04를 이용하였다.18.04나 20.04와 같은 LTS 버전도 있지만 18.04는 너무 오래되어서 현재 python3만을 사용할 수 있는 것과 달리 2를 사용할 수 있기 때문에 최근 버전에서 구성하는 방법이 다를 것 같아서 넘어갔다. 20.04나 22.04를 사용해도 되지만 기왕 처음부터 하는 거 나중 되면 결국 24.04를 사용할 때가 올 것이기 때문에 미리 최신버전에서 사용법을 익히고자 이걸로 선택했다. 단순 ..

API 앱과 Admin 앱을 하나의 인스턴스에 띄울 일이 생겼다. 따로 분리하면 좋겠지만 OCI의 무료 인스턴스를 사용하고 있기 때문에 무료 인스턴스의 개수에 제한이 있어 하나에 구성하기로 했다.  TLS 인증서 발급받기sudo apt updatesudo apt-get install letsencrypt -y 먼저 letsencrypt를 통해 인증서를 발급하기 위해서 위와 같이 패키지를 다운로드한다.  certbot certonly --standalone -d 도메인명 그다음으로 인증서를 발급받아야 하는데 도메인명이 필요하다.도메인은 가비아에서 store나 site와 같이 일반적으로 사용하는 public suffix가 아닌 것들은 1천 ~ 3천 원 정도의 가격으로 1년을 사용할 수 있으니 크게 부담은 없..

도메인 모델을 구현하는 방법 중 자주 사용되는 것이 DB 엔티티 객체를 만들어 사용하는 방식이다. ORM을 통해 엔티티를 사용하면 UML 등으로 객체지향적으로 설계한 내용을 실제 구현체에 반영하기 쉽다. 하지만 객체를 이용하는 것에도 단점이 있다. 그것은 바로 수정하기 쉽다는 것이다. 무심코 Setter를 만들어버리면 메서드 하나만 호출하면 값을 쉽게 바꿀 수 있기 때문에 원치 않는 결과를 초래할 수 있다. 나도 전부터 여러 프로젝트를 진행하면서 무심코 Setter를 만들어 엔티티의 값을 수정하곤 했는데 이번에는 필요한 부분만 메서드로 따로 만들어 리팩토링 하기로 했다.  Badge 엔티티@Setter@Getter@NoArgsConstructor(access = AccessLevel.PROTECTED)@..

이전에 문자열로 된 클래스를 사용자로부터 받아서 내부의 메서드를 실행시키는 로직을 구현한 적이 있다. 그때는 파라미터도 없고, 단순 메서드 내부의 로직만 실행하도록 하는 것이 전부였는데, 이번 프로젝트에서는 코딩 테스트 풀이를 위한 메서드 실행이 목적이기 때문에 파라미터를 받는 것이 필수이다. 그런데 여기서 발생하는 문제는 파라미터 개수가 불분명하고, 문자열로 된 타입을 어떻게 실제 타입으로 변경할 것인가였다. 며칠간 고민하며 개발해 본 결과 다음 방법으로 원하던 목적을 이룰 수 있었다.  흐름 알아보기 먼저, 클라이언트에서 위와 같이 문제 번호와 작성한 코드 내용을 서버로 요청하면 컨트롤러에서 이를 처리하게 된다. 해당 컨트롤러에서는 다음 서비스를 호출하여 유저의 풀이 코드를 실행한다. @Slf4j@R..