전체 글

이번에 동아리에서 기존 Nest로 작성된 Account-Server를 Spring+Kotlin으로 변경하는 프로젝트(같은 스터디)를 진행하게 됐습니다. 저는 현재 이 중에서도 특히 인증과 인가 담당한 파트를 전반적으로 담당하고 있습니다.  왜 스프링인가? 시작에 앞서 간략하게 나마 스프링으로 전환하려는 이유를 서술하겠습니다.  1. 유지보수 가능한 개발자가 많다.  저희 동아리의 메인 서버가 스프링+코틀린으로 작성된 만큼 스프링을 다룰 개발자가 많으며, 동시에 구인하기에도 용이합니다.  2. Nest를 쓸만큼 다중 요청이 많지 않다. 싱글 쓰레드인 Nest는 비동기 I/O 모델은 분명 I/O bound 작업에서 강한 만큼, I/O 작업이 주를 이루는 어카운트 서버 (WAS내 복잡한 연산 X)라는 점에서 ..

본격적으로 스프링 세큐리티 라이브러리를 이용하기 전에 러프하지만, 간단하게 인터셉트와 JWT 라이브러리, Redis를 이용해  OTP Code를 생성 -> 검증 -> 임시 Token을 발급하고, 이를 인증한 회원에게는 접근 권한을 발급하는 로직을 구현해보겠습니다. 스프링 부트 생성까지는 스킵하고 의존성 설정 부터 시작하겠습니다  implementation("io.jsonwebtoken:jjwt:0.9.1") implementation("javax.xml.bind:jaxb-api:2.3.1") implementation("org.glassfish.jaxb:jaxb-runtime:2.3.1") implementation("org.springframework.boot:spring-boot-starter-dat..

오랜만에 알고리즘을 풀었습니다.이런 류의 Union-Find 문제가 종종 보이길래 빠르게 포스팅합니다.  문제 접근이번 문제의 경우 처음부터 알고리즘을 보고 풀었습니다.. 클래스 5의 문제들 중 비트마스킹이 너무 많습니다.이분탐색, 분리집합 스타트였다는 점 참고해주세요. 우선 풀면서 '공항' 문제와 매우 유사함을 느꼈습니다. 이진탐색인데 뭔가 체킹을 필요로 하는?(기존에 이 문제 못풀었습니다) 시간 단축의 핵심은 Target K 숫자보다 큰 수 중 가장 작은 수를 이진 탐색으로 간단히 찾고그 수가 아직 사용하지 않은 수면 좋겠으나만약 사용된 경우에는 그 수보다 큰 수들 중 사용되지 않은 가장 작은 수를 빠르게 찾는 것에'분리 집합' (Union Find) 알고리즘을 사용하는 것이라고 생각했습니다. 한칸씩..

Docker를 사용한 배포를 직접 해보면서 뭔가 이미지 파일들과 도커 허브를 잘 이용하면 자동화된 배포가 가능할 것 같았습니다. 기존에는 프로젝트를 진행하면서, 배포에 많은 시간을 사용했습니다. Main Branch에 Merge를 하면 WAS가 올려진 서버에 직접 SSH 접속해 이를 다시 받아오고, DB 변경 사항이나 배포용 환경설정에서의 Conflict 등을 직접 다룬다는 게, 프로젝트의 핵심이 되는 비지니스 로직에만 집중하지 못하고, 자꾸 밖으로 힘이 샌다는 느낌이 강하게 들었습니다. 변경 사항을 직접 테스트하고 빌드하고 이를 EC2 서버에 Deploy하는 과정을 한번에 해준다... 정말 멋진 자동화 프로세스입니다. 개발자는 항상 효율을 따지는 사람들 인 것 같습니다.   결과적으로 전부터 쭉 궁금했..

1. 마구잡이식 개발에서 벗어나자 기능 요구사항 분석 -> ERD 설계 -> ERD에 맞춰 Entity 설계 -> Repository, Service 구현 -> 구현 사항 테스트 -> 프론트엔드 연결 2. 영속성 컨텍스트 내부 객체는 한 트랜잭션이 커밋될 때, 더티 체킹을 통해 알아서 DB에 수정사항이 반영된다.(장고 orm에서는 가져온 객체를 수정하더라도 post.save()와 같이 반영을 해줘야 했는 데, JPA에는 Dirty Checking 기능이 있어서 그렇다!, 꽤나 똑똑한듯) +) 자체적으로 merge 하는 방법보다 이 JPA의 변경감지 기능을 사용하는 설계가 옳다. 처음부터 준영속 객체를 생성하지 말고, 영속 객체를 DB에서 꺼내오는 식으로 3. 엔티티 클래스에서 자체적으로 비지니스 로직을 ..

이전 글에선 도커 이미지 빌드와 Compose에서 로컬 환경 실행에 그쳤다면,이번에는 실전으로 들어가 AWS EC2 실제 서버 배포 + AWS RDS 연동 두 가지를 동시에 시도했습니다. 우선 AWS RDS Free tier에 맞는 데이터 베이스 인스턴스 생성 RDS도 하나의 서버입니다.기존 EC2와 동일하게 서버 간의 연결에 신경쓰려면 딱 두가지를 신경쓰면 됩니다. 1) 접속할 IP와 PORT에 대한 인바운드 보안 규칙 설정 2) 서버의 EndPoint (+PORT 이 경우 5432) 그 외에서 신경 쓰일 일은 없었습니다.데이터 베이스에 접근할 유저와 비밀번호를 잘 기억해서 환경변수에 적어주는 것 정도? 이제 이 DB에 접근할 IP에 대해 인바운드 규칙을 설정 해주겠습니다.(가운데는 본인 IP니 무시해..

사실 안쉬움 뭔가 가상환경 속에서 커맨드만을 이용해 예측하는 기분이 들었습니다.  이전 도커 파일에선 하나의 이미지만을 빌드 후 실행했다면, 이번에는 두 이미지 (스프링 + PostgreSql)를 도커로 합쳐서 한 컨테이너에 띄우는 작업을 진행합니다.  우선 기존 도커파일은 그대로 유지합니다. FROM openjdk:18-ea-jdk-slimVOLUME /tmpCOPY build/libs/demo-0.0.1-SNAPSHOT.jar codingtest-service.jarENTRYPOINT ["java","-jar","codingtest-service.jar"] 이제 docker-compose.yml 파일을 dockerfile과 동일한 위치에 생성합니다. (사실 Docker 쪽만 다룬 폴더를 만들수 있으나..

폴더 최상위에 Dockerfile 생성  springboot를 의존성에 추가했을 경우, bootJar을 클릭하여 JAR 파일 생성이때 생성된 build/libs/~~.jar 파일 앞서 생성한 도커파일에 커맨드 작성FROM openjdk:18-ea-jdk-slimVOLUME /tmpCOPY build/libs/demo-0.0.1-SNAPSHOT.jar codingtest-service.jarENTRYPOINT ["java","-jar","codingtest-service.jar"] FROM은 오픈소스 자바 VOLUME은 스프링부트가 위치할 rootCOPY는 지정된 경로의 jar파일을 container에 복사ENTRYPOINT  복사한 jar파일 실행  그럼 이제 도커파일을 이미지화 한다. 명령창에서 "co..