이번 아티클에서는 HTTP 요청과 응답이 어떤 구조를 가지는지 알아보도록 하겠습니다. HTTP 메세지 구조 HTTP 요청(Http Request), HTTP 응답(Http Response) 모두 HTTP 메세지입니다. 표준에서 정의하는 HTTP 메세지의 구조는 다음과 같습니다. 보시다시피 HTTP 메세지는 크게 네 가지 부분으로 구성됩니다. start line, message headers, CRLF, message body입니다. start line start line의 경우 HTTP 메세지에서 가장 처음에 위치하는 부분입니다. 그리고 start line은 HTTP 요청이냐, 응답이냐에 따라 두 가지 종류로 나뉘게 됩니다. HTTP 요청인 경우에는 request line이라는 이름으로 불리며, HTTP..
Tomcat 구현 미션을 진행하면서 IO Stream이라는 개념을 다루게 되었습니다. 이번 아티클에서는 Stream이란 무엇인지, 그리고 IO Stream은 무엇이며 어떻게 사용될 수 있는지까지 알아보겠습니다. Stream이란? 우선 Stream이란 무엇인지부터 알아보겠습니다. Stream이란, '흐르는 시냇물' 이라는 사전적 의미를 가집니다. 그리고 이는 컴퓨터 공학 분야에서 자주 사용되는데, 주로 데이터, 패킷, 비트 등의 일련의 연속성을 갖는 흐름을 의미한다고 합니다. 보다 쉽게 이해하기 위해 실생활의 예시를 한번 들어보겠습니다. Streaming(스트리밍)이라는 키워드는 많이 들어보셨을 것 같습니다. 우리가 영상을 보거나 음악을 들을 때 자주 접하던 개념입니다. 영상을 보거나 음악을 들을 때 데이..
들어가면서 웹 어플리케이션을 개발하다 보면 수많은 예외 상황에 마주하게 됩니다. 그리고 좋은 어플리케이션을 구축하기 위해서는 이런 예외 상황들에 대해 적절한 응답을 내려주어야만 합니다. 일반적으로 예외 핸들링을 위해 관리해야 하는 정보는 다음과 같습니다: 상태코드 에러코드 예외 메세지 에러 코드의 경우에는 서비스마다 관리 여부가 다를 수 있겠으나, 제가 현재 개발하고 있는 '하루스터디' 서비스에서는 위 세 가지 요소를 전부 다 관리하고 있습니다. 그렇다면 위 요소들은 어떻게 관리가 되어야 할까요? 가장 먼저 떠올릴 수 있는 방안은 '예외 객체 자체에서 관리하는 것' 입니다. public class StudyNotFoundException extends RuntimeException { private st..
매번 협업 프로젝트를 진행할 때마다 마주치는 빈번한 문제 중 하나는 CORS입니다. 이번 협업 프로젝트를 진행하면서도 CORS 문제를 다룰 일이 생겼고, 한 번은 제대로 짚고 넘어가면 좋을 것 같아 이번 아티클을 통해 정리해 보도록 하겠습니다. OriginSOP(Same Origin Policy)와 CORS(Cross Origin Resource Sharing)에 대해 알아보기에 앞서, 두 개념에서 공통적으로 사용되는 개념인 Origin에 대해 알아보도록 하겠습니다. Web content's origin is defined by the scheme (protocol), hostname (domain), and port of the URL used to access it. Two objects have t..
이번 아티클에서는 Oauth의 개념을 알아보고 어떻게 인증 플로우를 구성할 수 있는지 알아보겠습니다. Oauth의 등장 배경 Oauth에 대해 알아보기에 앞서, 왜 등장했는지부터 이해해봅시다. Oauth가 등장하기 이전에는 인증방식에 대한 표준이 존재하지 않았습니다. 따라서 각 서비스마다 자체적으로 아이디 비밀번호를 관리하는 형태였습니다. 이런 상황에서 서비스 간에 정보를 공유해야 하는 상황이 생겼다고 가정해봅시다. 예를 들어 사용자의 일정 관리를 도와주는 A라는 서비스가 있는데, A 서비스에서는 보다 수월한 일정 관리를 위해서 사용자의 '구글 캘린더' 정보를 필요로 합니다. 이 때, 어떻게 사용자의 구글 캘린더 정보를 받아올 수 있을까요? A라는 서비스에서는 해당 유저에 대한 구글 계정 정보를 모르는데..
버그 리포팅 🐞 월요일은 버그 리포팅을 진행했습니다. 다른 팀들의 서비스를 사용해보고 어떤 버그가 있는지를 확인하는 방식이었습니다. 저희 팀도 다른 팀들로부터 버그 리포팅을 받았는데, 생각보다 버그가 많아서 놀랐습니다...ㅋㅋ 버그 리포팅이 1시간정도 진행되었던 걸로 기억하는데, 짧은 기간에 짧은 인원이 진행했음에도 불구하고 버그 관련 이슈가 10개 정도 생겼던 것 같습니다. 실제 사용자가 사용하면 더욱 버그가 많을텐데, 테스트 서버 및 QA의 중요성을 느끼는 계기가 되었습니다. 인증 플로우 구현(feat. Oauth2, JWT) 이번주는 기능 개발에만 집중했었습니다. 원래 하루스터디 백엔드 팀원들은 몹 프로그래밍을 자주 했었는데, 이번에는 시간이 부족할 것 같아서 페어 프로그래밍을 진행하게 되었습니다...
프로젝트에 JWT를 도입하면서 암호화에 대한 개념도 접하게 되었지만, 용어 정리가 명확하게 되지 않아 헷갈리는 일이 많았습니다. 따라서 이번 아티클에서는 공개키와 개인키, 그리고 대칭키와 비대칭키에 대해 정리해보고자 합니다. 대칭키 대칭키란 어떤 정보를 암호화, 혹은 복호화할 때 사용하는 키가 동일한 경우입니다. 대칭키 암호화 방식을 사용하는 경우, 어떤 정보가 A라는 키로 암호화 되었다면 수신하는 쪽에서도 동일하게 A라는 키로 복호화해야 합니다. 대칭키 방식은 암호화 / 복호화 과정에 있어 속도가 빠르다는 장점이 있으나, 키를 안전하게 교환해야 하는 문제점을 가지고 있습니다. 키를 가진 누구나 암호화 / 복호화가 가능하기 때문에 탈취되었을 때의 위험도가 크기 때문입니다. 따라서 많은 암호화 통신에서 뒤..
6주차는 리팩토링에 집중했던 한 주였습니다 🥲 마찬가지로 회고해보고자 합니다! 슈퍼타입 - 서브타입 제거 한 주가 시작되자마자 가장 먼저 했던 일은 테이블 상속구조를 제거하는 일이었습니다. ERD 설계를 할 때, 확장성을 고려해 슈퍼타입 - 서브타입 관계를 자주 사용했으나, 이에 따른 문제가 많이 발생했기 때문입니다. 우선 테이블 구조를 한 눈에 파악하기가 어려웠습니다. 어떤 정보가 어디에 들어가는지 알기 위해서는 자주 ERD를 확인해야 했던 것 같습니다. 또한, 코드 레벨에서도 상속 구조를 사용하니 캡슐화, 다형성 등 이것저것 신경쓸게 많았습니다. 확장에 유연하게 대응하기 위해서 추상화를 했지만, 추상화를 관리하는 비용이 생각보다 컸던 것 같습니다. 따라서 테이블 상속구조, 코드 상속구조를 모두 제거하..
JWT(Json Web Token)이란? JWT는 RFC 7519 에 등록된 표준으로서, JSON 포맷의 정보를 간결하게 전송할 수 있는 하나의 기술입니다. 사실 JWT라는 것은 추상적인 인터페이스의 역할이고 구현체는 두 가지로 분류되는데요. JWS(JSON Web Signature) - 서명 방식 JWE(JSON Web Encryption) - 암호화 방식 대부분의 경우 JWT를 JWS와 동일한 의미로 사용하므로 이번 아티클에서도 서명 방식(JWS)를 기준으로 설명하겠습니다. JWT는 서명(sign)이라는 개념을 사용해 데이터를 전송합니다. JWT를 처음 학습하시는 분들이라면 당연히 이 '서명'이라는 키워드가 낯설텐데, 쉽게 말해 데이터에 일련번호를 붙인다라고 생각하시면 될 것 같습니다. 이렇게 일련번..
5주차는 리팩토링 + 버그 수정에만 전념한 한 주였는데요, 마찬가지로 무엇을 느꼈는지 무엇을 경험했는지 회고하고자 합니다. 패키지 구조 변경이번주 들어 가장 큰 변화가 있다면 패키지 구조를 변경했다는 것입니다. 사실 이전까지는 패키지 구조에 대해 신경쓰지 않고 개발을 진행했던 터라, 한번 즈음은 패키지 구조에 대한 고민을 진행해야만 했습니다.// 이전 구조 └── backend ├── config ├── controller │ └── exception ├── dto │ ├── request │ └── response ├── entity ├── exception ├── repository │ └── dto └── service └── dto패키지 구조 변경에 있어 하루스터디 팀의 선택지는 크게 두 가지로 ..
