이번 장바구니 협업 미션을 진행하면서 배포를 해보게 되었고 https라는 개념도 처음 다루게 되었습니다. 이번 아티클을 통해 https의 개념은 대략적으로 무엇인지, 어떻게 ec2 기반 서버에 적용할 수 있는지 알아보고자 합니다. HTTP, HTTPS? HTTPS(Hyper Text Transfer Protocol Secure)이란, HTTP에서 SSL 혹은 TLS라고 불리는 암호화 방식이 추가된 것입니다. HTTP는 바디, 헤더등을 암호화할 수 없어서 민감한 정보까지도 순전히 드러나게 된다는 문제가 있었는데, HTTPS가 이를 해결한 것으로 보입니다. 즉, HTTPS는 HTTP + TLS, SSL이고 HTTP의 확장된 버전으로 생각할 수 있습니다. 그리고 HTTP와 다르게 HTTP는 443번 포트를 사..
.http 파일 사용하기 리뷰어님의 추천으로 인텔리제이에서 Postman과 비슷한 기능을 수행 할 수 있다는 것을 알게 되었습니다. 바로 .http 파일을 사용하는 것인데요, 인텔리제이에서 디렉토리에 .http 파일을 만들면 다음과 같은 ui가 자동으로 구성됩니다. 그리고 application을 구동한 다음 위 초록색 실행버튼을 누르면 Postman처럼 요청이 갑니다. Response에 대해서도 아래 화면에서 확인이 가능합니다. 헤더나 바디까지도 지정해줄 수 있다는 점에서 좋은 것 같습니다. 또한 이 자체로 API 문서가 되는 셈이고, 버전 관리도 가능해서 유용하게 사용할 수 있을 것 같다는 생각이 드네요. 그리고 요청을 아래처럼 여러개 정의하는 것도 가능합니다. 그렇다면.. E2E 테스트를 굳이 코드레..
의존성 역전, 도메인 우선 개발 저는 아키텍쳐에 관심도 많고, 도메인 자체에도 관심이 많은 터라 이번 미션에서는 DIP를 적용해보고 싶다는 욕심이 들었습니다. 따라서 페어와 합의해 영속성 - 도메인 의존성을 역전시킨채로 미션을 진행했습니다. Repository의 인터페이스를 business layer에 먼저 만들어두고 domain, service를 구현 완료한 다음 Repository의 구현체 및 DB 테이블을 만들었습니다. 이 과정에서 무의식적으로라도 DB 테이블이나 쿼리문에 대해 신경쓰지 않게 되었습니다.(애초에 Repository 구현체를 만들지 않았으므로) 해당 접근방식을 통해 Layered architecture의 전통적인 문제점인 데이터 중심 설계로부터 벗어날 수 있었고, 순수 비즈니스 로직/..
레벨 2 첫 미션인 자동차 경주 미션이 끝났습니다. 스프링을 처음 접한 미션이었는데요, 이 과정을 통해 얻은 것들을 정리해보고자 합니다. 페어와 룰 정하기 + 아이스 브레이킹의 중요성 이번 미션의 페어는 체인저였는데요, 체인저의 제안으로 미션을 시작하기에 앞서 페어 프로그래밍 룰을 정했습니다. 스위치 시간이나 컨벤션, 그리고 구현 계획을 미리 정했는데요. 이 과정에서 체인저와 더 친해질 수 있었고 편한 마음으로 미션을 시작할 수 있었습니다. 게다가 이런 페어 프로그래밍 룰을 미리 정해 두었기에, 비교적 개발 피로도도 적었던 것 같아 좋았습니다. 스프링으로 하는 첫 미션이라 조급하고 막막한 마음이 있었는데, 확실히 규칙을 정하고 하니 안정적이라는 느낌을 받았습니다. 정말 좋은 방식인 것 같아, 앞으로 페어..
문제 정의 장바구니 미션을 진행하면서 인증을 위해 Interceptor를 구성했는데요, Interceptor를 만들고 기존에 작성했던 컨트롤러 테스트들을 돌려보자, 제대로 동작하지 않는 것을 확인했습니다. 왜 이런 일이 발생하는 걸까 고민이 많이 되었습니다. 예외가 발생하는 지점은 ProductControllerTest였는데, 코드 상에서 예외가 발생할만한 부분은 존재하지 않았기 때문입니다. 코드는 아래와 같은데요, @WebMvcTest(ProductController.class) class ProductControllerTest { @Autowired private MockMvc mockMvc; @Autowired private ObjectMapper objectMapper; @MockBean priv..
우테코 레벨 2 미션 중 '장바구니 미션'을 진행하고 있는데요, 최근 저의 가장 큰 고민 중 하나는 '도메인을 어떻게 순수하게 유지할 수 있을까?' 였습니다. 이런 고민을 해결하기 위해 몇 가지 방법을 시도해보게 되었고, 그 과정을 간단하게 기록해보려고 합니다! 1. DIP 적용 우선 저는 순수하게 도메인을 유지시키기 위한 방법으로 DIP를 먼저 떠올렸습니다. 계층형 아키텍쳐를 사용하는 경우, 이를 달성하기 위한 가장 보편적인 방법은 DIP입니다. 비즈니스 레이어에서 Repository나 Dao를 구현하는 영속성 레이어로 향하는 의존성을 DIP를 통해 역전시키면 됩니다. 이렇게 인터페이스를 도메인 패키지 내에 두면, 구현체에 관계없이 비즈니스 패키지는 독립적으로 작동할 수 있게 됩니다. 여기서 주의할 점..
우아한테크코스에 온 지 두 달이 지났고, 현재 방학을 맞이해 회고를 작성하고 있다. 정말 많은 일들이 있었고, 순식간에 지나간 레벨 1이었지만 그래도 보람찼다고 생각한다. 그래서 생활과 학습, 두 가지 측면으로 나눠 회고를 한번 작성해보려고 한다. 😀 생활 처음 우아한테크코스에 들어갔을 때가 생각난다. 연극 조 조원들과 함께 중국집에 갔는데 레오 음식만 너무 안 나와서 한 40분은 기다렸던 것 같다. 그렇게 연극 조원들과 어찌어찌 친해지고 연극을 준비했다. 연극 주제는 '협업할 때 빌런들' 이었다. 나는 뭐든지 검색해보지도 않고 알려달라도 떼쓰는 '핑프' 역할을 맡았었다. 처음에는 굉장한 부담이었는데, 생각해 보니 이것도 좋은 추억이겠다 싶어서 열심히 했던 기억이 난다. 그때 연극하면서 조금 무리수를 두..
이상(추상화 계층 분리) vs. 현실(기능) 체스 게임에서는 폰은 특별한 이동규칙을 가진다. 첫 이동에 2칸을 이동할 수 있고, 공격을 하는 경우는 대각선으로도 이동이 가능하다. 하지만 다른 기물들은 이렇게 특별한 이동규칙을 가지지 않는다. (나이트, 퀸, 비숍 등) 나는 모든 기물들을 하나로 추상화 해 다루고 싶었으나 폰을 추상화하는 과정에서 어려움을 겪었다. 아무리 생각해도 폰과 다른 기물들을 하나로 추상화 할 수 있는 수단을 찾지 못했었다. 따라서 폰의 이동규칙만 특별하게 상위 개념인 Board 객체에서 다뤘다. 이 부분에 대해서는 당연히 지적이 들어올 것이라 생각했고, 나도 개선해야 할 점이라 생각했다. 그리고 이것이 가지는 단점이 무엇인지 생각도 해보았는데, 아래와 같은 결론을 도출할 수 있었다..
방어 로직 세팅하기 체스 미션은 4단계까지 존재했다. 1단계에서는 체스 보드 생성, 2단계에서는 체스 말 이동 구현, 3단계에서는 점수 기능 구현 등, 각각의 단계마다 요구하는 게 달랐다. 나는 2단계까지 구현을 마친 시점에서 적팀 말을 잡는 기능은 현재 단계의 요구사항에서 벗어난다 생각해서 구현하지 않았다. 하지만 리뷰어분이 '구현되지 않았다면 적절한 방어 로직이 세팅되었는지'를 여쭤봐 주셨다. 생각해보니 내가 만든 어플리케이션은 불완전했다. 말을 잡는 기능을 구현하지도 않았는데, 이동 위치에 적팀 말이 있는 경우 덮어씌우는게 가능했다. 실제 서비스는 이렇지 않을 것이다. 분명 시간적 제약 등으로 중요한 기능만 먼저 딜리버리해야 하는 시점이 존재할 것이고, 딜리버리되지 않은 기능들은 사용자에게 오동작으..
mermaid 나는 설계를 할 때 시각화를 하는 것을 좋아한다. 그래서 이전까지는 draw.io 를 통해 다음과 같은 방식으로 다이어그램을 그린 후 구현을 시작했다. 하지만 시스템의 구조는 항상 동일한 것은 아니다. 변할 수 있다. 그렇기에 매번 다이어그램을 갱신하는 것은 귀찮았고(?) 문서가 코드를 따라가지 못하는 상황이 왔었다. 리뷰어분은 Mermaid 사용이 어떠냐고 제안해주셨고 다음과 같이 개선할 수 있었다. 정적인 문서를 조금이라도 더 동적으로 바꾸고, 간편하게 다이어그램을 그릴 수 있다는 점에서 좋다고 생각한다! 무상태 컨트롤러 나는 보통 컨트롤러에서 가장 추상적인 도메인 객체를 상태로 갖고 있게 코드를 짠다. 즉, 다음과 같은 식이다. public class BlackJackControlle..
