기록들 https://github.com/ndgndg91

사이드 프로젝트 여정 두 번째 이야기이다. 첫 번째 이야기는 SSO 를 다루어 보았다. 이번에는 Front 를 구현하고, CI/CD Pipeline 및 Infra 구성에 대해서 간략하게 정리해보려고 한다. 우선, 간단하게 프로젝트 Front 는 angular11 로  my.new 루트 도메인을 가진 repository 한 개, shortcut.my.new 서브 도메인을 가진 repository 한 개로 두 개의 repository 이다. 처음 infra 구성은 S3 Static web hosting 과 CloudFront 구성을 취하려고 했었다. 하지만, 해당 구성을 취하는 과정에서 관리비용이 꽤나 큰 것을 느꼈다. 각가의 CI/CD pipeline 을 손수 구성해줘야 되었다. 예를 들어, Github Action 을 사용할 경우, 특정 브랜치 master 에 Pull Request 혹은 Push 가 발생할 경우, angular project 를 build 하고 artifact 를 aws cli 통해서 S3 에 put object 를 통해서 업로드 하고, CloudFront Invalidation 을 직접 구성해주어야 하며, Domain 연동도 Route 53 Record 및 SSL 인증서를 ACM 에 직접 발급받고, 도메인을 구입한 DNS Provider 에서 Record 설정을 꼼꼼하게 신경써야한다. 혼자서 사이드 프로젝트를 진행하면서 Front 뿐만 아니라, Back-end 도 개발 및 인프라 관리를 하기 때문에 관리 비용이 꽤나 크게 다가왔다. 그러던 도중에 AWS Amplify 라는 서비스를 이용해보았고, 굉장히 큰 도움이 되었다. AWS Amplify 에 대한 내용을 정리하기 전에 우선 간단하게 S3 Static website hosting 설정을 정리하겠다. 아래는 CloudFront 를 이용하여 S3 웹사이트 호스팅 방법에 관련한 안내서이다. 4가지 방법을 알려주고 있는데, 웹사이트 엔드 포인트를 오리진으로 사용하는 방법만 일단 간략하게 ...

작년 2020년 11월 초부터 현재 재직 중인 회사 CPO 님과 2명이서 사이드 프로젝트를 하나 시작했다.   서비스 소개 영상이다. 제품의 아이디어 및 디자인 그리고 정체성 및 사용성에 대한 기획은 CPO 님이 그리고 나머지 기술 부문은 내가 맡아서 진행했다. 개발 스킬 향상을 위해서 혼자서 또는 개발자들끼리의 사이드 프로젝트를 진행한 경험은 많았지만, 사용자를 위한 제품을 만들기 위해서 진행한 사이드 프로젝트는 이번 경험이 처음이라고 할 수 있다. Slack 과 Notion 을 이용하여 프로젝트에 필요한 커뮤니케이션을 진행했고, 퇴근 후 각자 주당 평균 10시간 정도 투자해서 100일 안에 완성을 목표로 시작했다. 100일을 목표로 잡은 이유는 100일이 넘어가면 늘어지고 지쳐서 서로가 힘들어지기 때문에 다소 타이트할 수도 있고 넉넉할 수 도 있는 시간으로 적절하게 잡았다. 또한 .new 라는 도메인을 사용했는데, 구글에서 만든 도메인으로 도메인 구입 후 100일 이내에 도메인을 적용한 서비스를 출시해야 되며, 구글에서 만든 정책을 준수하는 서비스를 만들어야한다. 이러한 과정속에서 제품을 만드는 과정에서 개발이외에 부분에서도 많은 것을 느끼고 성장한 부분도 있지만, 나는 엔지니어로서 기술적인 부분에서 고생을 하고 배운 것들에 대해서 정리를 해보려고 한다. 그 첫 번째 주제가 바로 SSO 이다. 간단하게 SSO 의 개념에 대해 먼저 짚어보겠다. SSO 란 Single-Sign-On 의 약자이다. 우리나라말로 풀이하자면, 통합 인증 혹은 단일 인증 단일 계정 로그인 정도로 정리할 수 있다. 예시를 들자면, 우리 실생활에서 많이 사용하는 구글 서비스를 들 수 있다. 구글의 경우 한 번의 로그인을 통해서 Gmail, Youtube, Drive, Docs, Spreadsheet 등 여러 서비스를 사용할 수 있다. 구글의 여러 서비스의 경우, gmail 과 같이 mail.google.com 서브도메인으로 구성된 서비스도 있고, youtube 와 같이 youtu...

이번글에서는 @Transactional propagation 에 대해서 정리해보겠다. 그 전에 트랜잭션 관리 방법에 대해서 간단하게 정리하겠다. Application 을 개발할 때, Transaction 관리를 두 가지중 선택할 수 있다. 1. Programmatic Transaction Management 2. Declarative Transaction Management Programmatic Transaction Management 는 말 그대로 Transaction 관리를 코드로 직접 구현한다. Declarative Transaction Management 는 해석하면 선언적 트랜잭션 관리이다. 흔히 Spring framework 를 사용할 때 설정을 해주며 트랜잭션이 필요한 비즈니스 로직을 구현할 때 @Transactional 어노테이션을 사용한다. 위에서 rollback 과 commit 을 코드로 관리하는 반면,  AOP 를 통해서 관리된다. 따라서 보다 비즈니스 로직에 집중할 수 있다. Programmatic transaction management Vs Declarative transaction management Programmatic transaction management 는 보통 transaction 의 수가 적을 때 적합한 방식이다. 예를 들어, 자원에 대한 update operation 단지 몇 가지일 경우이다. transaction proxies 설정을 원하지 않을 때 적합하다. 이러한 경우에, TransactionTemplate 을 사용하는 것이 좋다. 반대로, application 이 수많은 transaction operation 이 필요할 경우, Declarative transaction management 가 더 적합하다. 이는 business logic 과 transaction management 을 분리시켜 주며, 설정 또한 그리 어렵지 않다. Spring framework 를 사용할 때, transaction ma...

Spring과 Spring Boot 의 가장 큰 차이점은 @SpringBootApplication Annotation 의 초기 설정 부트스트래핑이지 않을까 생각한다.  Spring initializer(https://start.spring.io/) 를 통해서 프로젝트를 생성하면, 아래와 같이 main 메서드를 가진 class 와 @SpringBootApplication Annotation 을 확인할 수 있다. 그렇다면, 정확히 @SprinBootApplication 이 하는일은 무엇일까? @SpringBootConfiguration, @EnableAutoConfiguration, @ComponentScan 3가지 어노테이션들을 확인할 수 있다. 그렇다면 각 3가지 Annotation 역할은 무엇일까? @EnableAutoConfiguration : Spring Boot 의 auto-configuration 메카니즘을 가능하게 한다. @ComponentScan : application 이 위치한 package 에 대하여 @Component scan 을 가능하게 한다. @SpringBootConfiguration : context 에 추가적인 spring beans (@Bean 어노테이션을 통해서 정의된 메서드를 가진 클래스) 등록을 가능하게 하며, 추가적인 configuration class 들을 import 할 수 있다.  그렇다면 auto-configuration 메카니즘은 무엇일까? Spring Boot 는 maven 혹은 gradle 에 추가된 jar dependencies 를 바탕으로 자동으로 설정을 시도한다. 예를 들어, HSQLDB 가  classpath 에 있다면, 수동으로 database connection beans 들을 설정할 필요가 없다. Spring Boot 는 자동으로 in-memory database 설정을 해준다. 단지, @EnableAutoConfiguration 이 포함된 @SpringBootAp...

 객체 지향의 5대 원칙으로 불리는 SOLID 원칙에 대해서 예제를 만들어서 정리해보려고 한다. SOLID 를 처음 알게 된 것은 첫 회사 면접에서 질문을 통해서 알게 되었다.  "객체 지향의 5대 원칙에 대해서 아나요?" 라는 질문이다. 벌써 3년 전 일이다. 당시에는 "응? 그런게 있구나??" 속으로 생각했었다. 면접이 끝나고 찾아봤는데, 그 당시에는 이게 개발하는데 중요한 것일까? 라는 생각을 했었는데 1년 씩 연차가 쌓이고 경험을 하면서 음 그래서 중요하구나.. 로 바뀌게 되었다. 코드를 한 번 작성하면 끝나는 것이 아니라, 결국 유지 보수를 해야된다. Software 는 계속해서 변화하는 요구사항들을 만족시키기 위해서 진화해야 된다. 그래서 중요한 것은 재사용하기 쉽고, 확장하기 쉽고, 진화하기 쉽고, 테스트하기 쉬워야 한다.  따라서 좋은 코드를 작성하기 위해서 스스로 정리 한다. 1. Single Responsibility Principle - 단일 책임 원칙 A class should have a single responsibility. 클래스는 책임을 하나만 가져야 한다. 다시 말해, 클래스 변경의 이유는 오직 하나여야만 한다. 왜? 1. Testing - 책임이 적을수록 테스트 케이스도 적어진다. 2. Lower Coupling - 책임이 적으면, 클래스의 기능도 적어지고, 의존성도 낮아진다. 그렇다면 예제를 통해 확인해보자. God 클래스를 만들었다. 이름에서 알 수 있듯이 많은 일을 하는 클래스이다. God 은 design 하고 develop 도 하고 plan 도 하고 customer service 도 한다. 흔히들 말하는 common 의 저주이다. God 은 모든일을 할 수 있다. 그럼 SRP 에 맞게 Class 를 나눠보자. God 클래스를 총 4개의 class 로 나누었다. Developer, Designer, Planner, CustomerServiceRepresentative.  준비한 예제가 ...