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패키지 구조 변경에 있어 하루스터디 팀의 선택지는 크게 두 가지로 ..
4주차는 처음으로 기획에서 벗어나 개발과 발표 준비에만 몰두했던 시간이었는데요, 여느 때와 마찬가지로 한 주 동안 배웠던 것들, 느꼈던 점들을 작성해보고자 합니다 🥸 페어 프로그래밍 기능 개발을 본격적으로 시작하기에 앞서, 팀원들과 어떻게 개발을 할 지에 대해서 논의하는 시간을 가졌었습니다. 이 과정에서 처음에는 동기화 작업이 우선이니 몹 프로그래밍, 그리고 그 뒤부터는 페어 프로그래밍을 하자! 라고 결론이 났습니다. 그래서 엔티티 설계 등, 동기화 작업이 중요한 경우에는 몹 프로그래밍을 진행했고, 그 뒤 개별적인 기능은 페어 프로그래밍으로 구현했습니다. 분업 방식을 고려하지 않았던 것은 아니지만, 프로젝트의 경우에는 결과물만큼 동기화 과정도 중요하다고 판단했기 때문에 페어 & 몹 프로그래밍으로 진행했습..
벌써 하루스터디 협업을 시작한지 3주가 지났습니다. 시간이 참 빠르다고 느껴지는데 이번에도 어김없이 회고를 하면서 무엇을 했는지, 앞으로는 무엇을 해야하는지를 작성해보겠습니다. 🥸 서비스에서 도구로 사실 이번주에는 대대적인 변경 작업이 있었습니다. 결론부터 말씀드리면, 1차 데모데이때 설명드렸던 기능들을 거의 90% 이상 갈아엎었습니다. 서비스 정체성은 유지하면서 기능은 전부 대체했는데요, 왜 그렇게 되었는지를 아래에 작성하고자 합니다. 하루스터디의 모토는 '짧은 주제의 스터디를 짧고 빠르게, 부담없이' 입니다. 그렇기에 제가 초기에 기획했던 모델은 스터디 모집 서비스였습니다. 짧은 주제의 스터디(쿠키와 세션 스터디 등)는 기존 스터디 패러다임과는 전혀 다르니 용기있게 짧은 주제의 스터디를 개설할 '장'..
2차 스프린트 및 MVP 기획이 드디어 끝이 났고, 이에 따라 저희 팀은 데이터베이스 및 엔티티 설계를 시작하게 되었습니다. 이번 글을 통해 하루스터디의 데이터베이스 설계 과정을 기록하고자 합니다. 데이터베이스 설계는 처음이었지만, 유의미한 경험들을 많이 했다는 생각이 들었기 때문입니다! 😀 요구사항에서 데이터 추출사실 저는 이렇게 규모가 있는 프로젝트에서 데이터베이스 설계를 해본 적이 없습니다. 이전 레벨 1, 레벨 2 미션들에서는 테이블을 먼저 설계하지 않고 도메인 객체를 먼저 설계했는데, 큰 규모의 프로젝트에서는 이러한 시도를 하기보다는 전통적인 Layered Architecture를 따르는 편이 나을 것 같았습니다. 그래서 이런저런 레퍼런스를 찾아보게 되었고, 해당 과정에서 '요구사항에서 키워드를..
하루스터디의 2주 차가 종료되었습니다. 정말 눈 깜짝할 세 없이 하루가 지나가고 있는 것 같아요. 오늘이 무슨 요일인지 까먹을 때도 많고, 엄청 바쁠 때도 많아서 레벨 1, 레벨 2가 그리워질 때도 있습니다.. (그때는 한가했던 거였군요 🙄) 2주 차에도 역시 1주 차와 마찬가지로 기획 과정을 고도화했습니다. 그리고 드디어 개발 문서를 작성하기 시작했는데요, 컨벤션을 만들었고, 기술 스택을 결정했습니다. 이 과정을 하나하나 기록해보고자 합니다!! IA 만들어보기 1주차에 브레인스토밍을 거치면서 여러 기능들이 종합되었는데, 어떤 기능을 구현해야 할지 혹은 어떤 기능은 어떤 기능과 연관이 있는지를 알지는 못했습니다. 즉, 정말 나열만 했던 셈이라 각자가 생각하고 있는 서비스의 모습이 조금씩 다르기도 했고 이..
무엇이 문제였을까? 로그인 기능을 구현하기 위해서는 어떠한 방법으로든 클라이언트를 식별할 수 있어야 합니다. 하지만 HTTP의 기본 원리를 그대로 따르면서 이를 구현하면 어려운 점이 많습니다. 무상태성을 완전하게 고려하면서 로그인 기능을 구성하려면 클라이언트는 매번 ID, PASSWORD를 보내주어야 할 것입니다. 이런 서비스를 사용하는 클라이언트는 매번 로그인을 해야할 것이구요. 그렇다면 쿠키에 ID, PASSWORD를 넣어두고 요청을 보내는 방식은 어떨까요? 사용자는 확실히 매번 요청을 할 필요도 없어보이고, 로그인 기능을 쉽게 구현할 수 있을 것 같아보입니다. 쿠키는 기본적으로 매 요청마다 같이 전송되니까요. 하지만 이 방식도 문제가 있습니다. 대표적인 문제점은 다음과 같습니다. 보안 위협: 요청에..
HTML5를 기준으로 브라우저 저장소의 종류는 크게 두 종류로 나뉘는데요, 쿠키 웹 스토리지(로컬 스토리지, 세션 스토리지) 이 두 저장소에 대해 알아보는 시간을 갖겠습니다. 쿠키 쿠키가 등장한 이유 HTTP의 특징 중 하나는 무상태성입니다. 즉, 서버는 클라이언트에 대한 어떤 가정도 하지 않는다는 것을 의미합니다. 하지만 이런 무상태성이 단점으로 작용하는 때가 존재하는데요, 인증 기능이 포함된 서버와 통신을 한다고 가정해보겠습니다. 완전한 무상태성을 유지하기 위해선, 위와 같은 통신 절차를 따르게 됩니다. 즉, 클라이언트는 필요한 모든 정보를 보내야 하기 때문에 매번 동일한 인증 절차를 거쳐야합니다. 이런 방식은 번거롭다고 느껴지지 않나요? 따라서 이런 HTTP의 무상태성을 통해 발생하는 문제점을 보완..
긴 것 같으면서도 짧았던 레벨 3 첫주차가 종료되었습니다. 그래서 이번 주에 느꼈던 것들, 학습했던 것들 위주로 회고를 작성하고자 합니다. 사실 여태까지는 일일 회고나 주간 회고를 작성하지 않았는데, 협업을 진행하게 되면서 주간 회고도 되게 유의미할 것 같다는 생각이 들어 시작하게 되었습니다..! 우리 모두가 기획자 레벨2 회고에서 언급했던 것처럼, 저는 이번 레벨3 프로젝트의 기획자 역할을 맡게 되었습니다. 그래서 총 7명의 팀원(엽토, 노아, 룩소, 히이로, 마코, 모디, 나)들은 내가 제시한 주제로 프로젝트를 하게 되었는데, 처음에는 걱정이 많았습니다. 기획자라는 역할을 경험해보지 못했기 때문입니다. 사실 제대로 된 협업도 이번이 처음이라, 방학 때 이런저런 걱정이 있었던 것 같습니다. 그런데 레벨..
