오늘은 오전을 쉼 없이 달렸었다. 어제 멘토링 노트 준비하느라 CS기술 노트 작성을 안 했던 만큼 오늘 4개 질문을 10시까지 작성 후, 10시부터 12시 반까지 쉽없이 회의만 했다. 거의 6개 안건을 의논하고, 튜터님 찾아뵙고, 결론을 내리느라 진이 빠져서 30분 일찍 점심시간을 가졌다. 우선 계획으로, 오늘까지 기능을 다 완료하고 내일부터는 다음 볼륨을 위해 계획을 짜고, 부하테스트를 해볼 것 같다. 나는 이제 슬슬 프론트를 해야겠고,, 요즘 너무 쳐지는 것 같은데 다시 힘내봐야겠따. 일단 오늘은 일찍 자고. 오늘 안건은 우선, 서비스에서 다른 도메인의 데이터를 가져오려면 서비스를 통하기로 결정을 했었는데, 두 서비스가 서로 참조하면 상호 참조가 발생하는 문제가 예상이 되어서, 파사드 패턴을 사용해보..
Til
오늘은 오전에 튜터님과 멘토링 시간이 잡혀서 미리 질문한 것들을 정리해서 갔었는데, 튜터님의 인터넷 상태가 고르지 못해,, 일단 적어둔 것을 글로 피드백 해주시고 저녁에 방문해서 질문을 받았다. 정말.. 도움이 많이 되었다. 우선 우린 백엔드로 취업을 할 거여서, 쌩 EC2에다가 이것저것 구현하는 것보다 이미 잘 나와 있는 AWS의 서비스들을 잘 이용하고, 우리는 프로덕션 코드에 집중하는 것이 더 좋다고 하셨다. 또 기획서는 꼭 버전 관리를 잘 해야 한다고 조언 받았다. 아 그리고 나는 레디스를 담당하다 보니까 캐싱에 대해 궁금한 것들을 여러 개 질문했었는데, 그 중에 실제 상황에 가깝게 부하테스트를 해보고, 이를 토대로 어느 요소들을 캐싱해둘지, 또 캐싱 해둔다면 그 기준을 어떻게 잡아야 할지가 궁금했..
public class StringTest01 { static String STR = "bearer bbbcccccdddddddeeeeffff"; @Test void test01() { long start = System.currentTimeMillis(); for (int i = 0; i < 1_000_000; i++) { String s1 = STR.split(" ")[1]; } long end = System.currentTimeMillis(); System.out.println("(end - start) = " + (end - start)); } @Test void test02() { long start = System.currentTimeMillis(); for (int i = 0; i < 1_..
오늘은 아침에 기술면접 준비를 해두고, 담당 튜터님과 피드백 일정을 잡고, 오전에는.. ERD를 또 갈아엎었다. 그래도 이번에는 조금 더 깔끔하게 다듬었고, 결제 부분을 포인트로 대체해서 구현하기로 했다. 그리고 로직들도 다듬어서 각 케이스별 처리 방법도 정리를 해두었다. 또한 AWS의 EC2 및 RDS, S3 인스턴스를 만들어서 팀원들과 공유를 해두었고, 코드 컨벤션으로 JpaRepository를 상속받을 것인가와 @RepositoryDefinition 으로 할 것인가를 고민해봤고, JpaRepository를 상속받은 것으로 결론이 났다. 사실 나는 납득이 안 됐었다. 필요하지 않은 메서드들까지 전부 구현을 해주기 때문에 캡슐화 되지 않는다고 생각했고, 기본 제공 메서드를 테스트 코드를 작성할 수 있는..
오늘부터 최종 프로젝트가 시작됐다. 팀장은 내심 내가 하고 싶었지만 그래도 하고 싶은 분들이 있을까봐 아무도 안 하면 제가 할거니 부담없이 말해달라고 했고, 내가 팀장이 되었다. 이제 부팀장을 정해야 했는데, 팀장/부팀장의 역할 중 하나로 튜터님, 매니저님과 팀원 사이를 이어주는 부분도 있다고 했고, ㅈㅎ님이 평소에 튜터님을 열심히 괴롭?히는 모습을 종종 보았기 때문에 ㅋㅋ 내가 직접 선정을 했다. 많은 아이디어들이 나왔지만, 결국 챌린지반의 존재 이유였던 대용량 트래픽 처리에 집중하고자 비즈니스 부분은 과감히 덜어냈다. 우리 팀은 크림의 기프티콘 버전을 만들어 보기로 했다. 처음부터 크림을 염두에 둔 것은 아니고 아이디어를 내고 피봇팅 하는 과정의 결과물이 크림이었다 ㅋ ㅋ 원래 중고 물품을 다수의 구..
협업툴 프로젝트 KPT Keep 컨벤션을 미리 잡고 프로젝트를 시작한 점. 그리고 이를 sample 디렉토리로 프로젝트 시작때 만들어 둔 것. 단순히 문서화 이상으로 어떻게 코드를 작성해야하는지 바로 확인하며 작성할 수 있어서 아주 좋았음 스타일 가이드를 미리 적용해놓고 시작한 점. Google style guide 로도 줄바꿈에는 팀원마다 달랐지만, spotless를 통해 이마저도 강제하여 충돌난 경우가 확연히 줄어들게 됨. 리뷰 및 소통, 참여에 적극적 PR 하나에 최대 41건의 리뷰가 달릴 정도로 리뷰에 적극적이며, 문제가 발생해도 서로 해결하려고 함. 커밋 수가 700개가 넘을 정도로 다들 열심히 함 Problem 문제가 없어서 문제를 찾을 수 없어서 문제였다. 프로젝트 시작 전에 도입을 고려했던..
JWT (JSON Web Token) JWT란, 인증에 필요한 정보들을 암호화 시킨 JSON 토큰을 의미한다. JWT는 JSON 데이터를 Base64 URL-safe Encode 를 통해 인코딩하여 직렬화한 것이며, 토큰 내부에는 위변조 방지를 위해 개인키를 통한 전자서명도 들어있다. 따라서 클라이언트가 JWT를 서버로 전송하면 서버는 서명을 검증하는 과정을 거치게 되며, 검증이 완료되면 응답한다. Base64 URL-safe Encode 란, 일반적인 Base64 Encode에서 URL에서 오류없이 사용하도록 +, / 를 각각 -, _로 표현한 것이다. JWT 구조 JWT는 .을 구분자로 해서 3가지 문자열의 조합으로 나타내며, header.payload.signature 로 구성되어 있다. 이거는 ..
Cookie / Session / Token 인증 방식 종류 일반적으로 서버가 클라이언트 인증을 확인하는 방식은 크게 쿠키, 세션, 토큰 3가지 방식이 있다. Cookie 인증 쿠키는 Key-Value 형식의 문자열이다. 클라이언트가 어떤 웹사이트에 방문하면, 그 사이트의 서버를 통해 브라우저에 설치되는 정보 기록용 파일이다. 그래서 각 사용자마다 고유 정보 식별이 가능해진다. Cookie 인증 방식 브라우저가 서버에 요청을 보낸다. 서버는 요청에 대한 응답에 브라우저에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다. 이후 브라우저는 요청을 보낼 때마다 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다. 서버는 쿠키에 담긴 정보를 바탕으로 요청의 주체를 식별한다. Cookie 방식의 ..
Refresh token이 필요한 이유 Access token 만을 통한 인증 방식의 문제는, 제 3자에게 탈취당할 경우 보안에 취약하다는 점이다. 발급된 이후에는 서버에 저장되지 않아 토큰 자체로 검증을 하며 사용자 권한을 인증하기 때문에 Access token이 탈취되면 토큰이 만료되기 전까지 토큰을 가지고 있는 사람은 누구나 접근 권한을 가진다. JWT는 발급 후 삭제가 불가능해서 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대응을 하고 있다. 보통은 유효기간을 짧게 하여 탈취당했을 때의 악용 시간 자체를 줄이는 해결책이 있긴 하지만, 그만큼 사용자는 자주 로그인을 하여 토큰을 발급받아야 하는 불편함이 있었다. 이러한 이유로 Refresh token이 나오게 되었다. 이름이 Refresh toke..
