개발자가 된 핏짜

60.5 시간 짜리 아이폰 앱 만드는 강의인데 오늘부터 듣는다.

강사가 유데미에서는 꽤 유명한 편이라고 한다.

강의 들으면 25개의 ios 앱 개발 포트폴리오가 생겨서 이걸로 취준을 할 수 있다가 강의 취지인데, 나는 취미로 앱개발하고 싶어서 듣는다. 강의료는 17,000원이다. 영국 발음의 언니가 나와서 설명해주는데 런던에 사신다고 한다. 

완전 초보를 대상으로 하는 강의이기에 나한테는 제격인거 같다. 디자인이랑 앱 출시하는것 까지 강의 내용에 포함이 된다. 

하루에 3시간이라고 해도 20일걸린다.

한달 잡고 다 듣는게 목표.

xCode가 애플에서 제공하는 iOS 앱 만드는 앱인데 최신 OS에서 설치가 가능하다.

여기서부터 강의 수강 딜레이가 시작된다.

강의는 4년전꺼라 최신화 한다고는 하지만 Big Sur 11버전 이상이면 된다고 했다. 하지만 2024년은 그걸 허락하지 않았다.

그리고 스타벅스 와이파이는 느렸다.

집으로 돌아와서 내 인생 첫 앱을 완성했다.

단순히 display를 보여주는 앱인데 simulator를 사용해서도 열 수 있고 내 아이폰과 연결해서 직접 다운로드 받아서 열 수도 있다.

주요 주제

- 주문 시스템의 독특한 특징과 고민
- 시스템의 장애와 대응 방안
- 어플리케이션 샤딩과 데이터 분산 저장 방식의 효과적인 구현 방안
- 대용량 데이터 조회 성능 개선 방안 모색
- 주문 시스템의 도메인 라이프 사이클 분석 및 개선
- 어플리케이션 샤딩 적용을 위한 데이터 정리 및 단일화

요약

배달의 민족 주문 시스템
- 배달의 민족 주문 시스템을 만들면서 여러 시행착오를 겪었고 그 안에서 굉장히 많이 성장을 해왔음
- 그 경험했던 시행착오들을 여러분들에게 공유드리고 싶어서 이 자리에 서게 되었음
- 배달의 민족 주문 시스템이 어떤 고민을 하면서 만들고 있는지, 성장 통제를 어떻게 극복해 나가면서 시스템이 진화해 나가는지를 말씀드리는 것임

음식 주문 시스템의 특징
- 주문 시스템은 다른 커머스 도메인과 다르게 독특한 특징을 가지고 있음
- 커머스 도메인의 특성과 음식 주문이라는 독특한 도메인의 특성을 고민하면서 시스템을 개발해 나가고 있음
- 마이크로 서비스 아키텍처를 추구하면서 어떻게 하면 시스템들 간에 잘 정리가 되면서 통신을 할 수 있을지 그런 부분을 고민하면서 개발하고 있음
- 대규모 트랜잭션을 안정적으로 처리하기 위해 많은 고민을 하면서 개발하고 있음

대용량 데이터의 조회 성능 개선
- 시스템이 장애가 나게 되면 전체 시스템에 장애가 이어지면서 베딩 서비스 자체가 유통이 되는 크리티컬한 이슈를 가지고 있음
- 대용량 데이터에 대해서 조회 성능이 계속 나빠지는 부분을 어떻게 해소해 나가는지 말씀드릴 것임
- 대규모 트렌드 션 계속 주문 수가 증가하면서 쓰기 처리 장비가 공간 쓰기 처리나 하계치에 도달하는 이슈가 많아짐
- msa로 아키텍처를 전환해 나가다 보니 무분별한 이벤트 발행으로 유실되는 이벤트도 많아지고 서비스의 흐름을 파악하기 어려워지는 아키텍처가 자성을 높아지게 되는데 이런 부분을 어떻게 개선해 나갔는지까지 소개해 드리면서 발표를 마무리해보도록 하겠음

주문 도메인 라이프 사이클
- 주문 인터널 api 서버는 주문 내역이나 기타 주문 정보가 필요한 서비스들에 주문 정보를 조회할 수 있는 데이터를 제공해 주는 ai 서버임
- 주문 내역 상세를 보여주기 위해서는 많은 정보가 필요함
- 주문 내역 상세를 보여주기 위한 api 리스턴스가 우측에 보이는 제이슨 스탭인데 방대한 양의 데이터를 조회해서 보여줘야 함
- 정규화를 해서 해결하기로 함
- 주문 도메인의 생명줄은 주문 생성, 접수 완료, 취소라는 크게 주문 도메인 라이프 사이클을 가지고 있음
- 주문 도메인 라이프 사이클 안에서만 도메인의 변경이 발생함
- 도메인 이벤트가 발행되게 되면 주문 이벤트 처리기 애플리케이션에서 데이터를 동기화해서 데이터 동기화를 이루어낼 수 있음

샤딩 전략
- 분산 처리에서 유통을 분산시켜보자고 설계를 하게 됨
- 오로라 장비는 엔진이 샤딩을 지원하지 않는 엔진이어서 해결이 될 수 없었음
- 어플리케이션 사진을 구현하기 위해서는 데이터를 저장할 때 어떤 카드의 데이터를 저장할지 결정하는 차진 전략에 대한 고민이 필요했고 두 번째로는 저장된 데이터를 어떻게 조회해 와서 시간 순서대로 잘 나열해서 제공해 드릴 수 있을지 데이터를 다시 애그리게이터 하는데 어떻게 해야 될지 하는 크게 두 가지 기능이 필요했음
- 샤딩 전략을 어떤 걸 사용할까 고민을 해봤는데 리서칭한 전략은 크게 세 가지였음
- 키 베이스드 샤딩은 해시 펑션을 통해서 데이터를 고르게 균등하게 내보낼 수 있는 장점이 있음
- 레인지 베이스 샤딩은 특정 값의 렌즈를 통해서 샤드를 결정하면 되기 때문에 구현이 매우 간단하다는 장점을 가지고 있음

주문 시스템의 특징
- 주문 시스템의 특징은 배달의 민족 서비스 특성상 음식 주문이 제대로 일어나지 않으면 대 서비스 자체가 장애라고 예측하는 고객분들이 많은 특징을 가지고 있음
- 주문 시스템은 정책상 최대 30일까지만 주문 취소가 가능해서 데이터의 변경이 최대 30일까지만 가능하며, 음식 주문의 특성상 대부분의 주문은 하루 내에 배달 완료가 돼서 처리가 되기 때문에 데이터가 완결되는 시간은 대체로 하루 내에 스냅샵 형태로 데이터가 바뀜
- 저희는 단일 장애 포인트를 피해서 최대한 시스템에 장애가 가지 않게끔 하자라는 전략을 취함
- 동적 데이터는 길어야 30일 대부분은 하루 내에 완결이 되기 때문에 스타드의 추가는 많이 일어나지 않아도 될 것이며, 차드의 추가가 일어난다 해도 최대 30일이 지나면 대리권은 결국에는 균등하게 붕괴될 것이다라는 결론을 내리게 됨

어플리케이션 샤딩
- 샵의 디터 키는 샵의 키가 어느 샷으로 가라는 걸 매핑해 놓은 매핑 클래스임
- 서비스 레이에서 사드가 어떤 차드로 반환하기로 결정하였고 이를 스레드 로퍼에 저장하는 것까지 해서 에스펙트 j의 동작은 무리되게 됨
- 에스트래픽 라우팅 데이터 소스에서 디디터밍 커런트 로버피라는 메소드를 오버라이즈 해서 미리 저장해놨던 사드 보도기를 3d 오터에서 가져오게 되고 이를 통해서 데이터 소스를 결정하게끔 구현을 해놓게 되었음
- 어플리케이션 샤딩을 적용하면서 쓰기 오천이 증가하는 부분에 대해서 똑같은 ha 구성을 앰버에 가져가면서 스케일 아웃으로 데이터를 고르게 분산시켜서 저장을 하면서 요청을 분산시키며 대응이 가능한 구조를 갖추겠음

도메인 로직과 서비스 로직의 분리
- 어플리케이션 이벤트를 통해 도메인 로직과 서비스 로직을 분리하는 것이 어려움
- 이를 해결하기 위해 내부 데이터와 외부 데이터를 정리함

이벤트 발행 실패 시 서비스의 일관성
- 이벤트 처리의 주체를 단일화함으로써 서비스 로직을 한 곳에서 관리하고자 하는 니즈가 더 컸음
- 도메인 로직과 서비스 로직 모두 실패했을 때 서비스의 일관성을 가져갈 수 있음
- 도메인 로직이 수행돼도 핸드실 커니 때 이후에 이벤트 발행이 실패될 경우에는 도메인 로직은 성공했지만 서비스 로직은 실패하면서 서비스의 일관성을 합치는 경험을 줄 수 있음
- 이벤트 발행이 실패가 되더라도 트랜잭션 커밋이 되면서 아웃바우스 ntt의 데이터 페이보드가 저장이 돼 있었기 때문에 이벤트 유
발생했을 때 다시금 이 아홉마팬티를 통해서 재발행이 가능하게 설계가 가능하게 됨


---------

추천시스템

주요 주제
- 추천 시스템 팀의 구성과 업무 수행 방식
- 데이터 전달 방식과 의존성 관리
- 실시간 데이터 추천 서비스를 위한 필요 사항과 구현 방법


다음 할 일
- 데이터 수집 및 처리 방법 검토


요약
추천 시스템 팀의 성장
- 추천 시스템 팀이 대외적인 공간에서 기술적인 내용을 공유하고 소개하는 것은 처음임
- 추천 시스템 팀이 어떻게 성장했는지 공유하고 배운 교훈들을 공유할 것임

추천 시스템 팀의 고객
- 추천 시스템 팀은 추천이라는 단 하나의 목적을 위해 만들어진 목적 조직임
- 데이터 사이언티스트와 데이터 엔지니어 그리고 dpm 이렇게 세 직군으로 구성되어 있음
- 추천 시스템 팀의 데이터 엔지니어에게는 두 부류의 고객이 있음
- 첫 번째 고객은 데이터 사이언티스트임

추천 시스템의 개발 과정
- 추천 시스템 팀의 데이터 엔지니어는 머신러닝 코드도 보고, api 서버도 개발하고, 데이터 파이 파일도 만들고, 추천과 관련된 모든 업무를 수행하고 있음
- 추천 서비스가 실제로 어떤 과정을 통해 만들어지는지 함께 살펴봄
- 추천 머신러닝 하면 빠지지 않고 등장하는 그림임
- 데이터를 가져와서 저처리하고 모델을 학습하고 평가하고 배포한 다음에 피드백을 받아서 끊임없이 개선하는 과정임
- 머신러닝 서비스를 개발하기 위해서는 필요함
- 학습과 예측을 어떻게 구성하느냐에 따라서 전체적인 시스템의 모습이 달라짐

오프라인 추첨 방식
- 오프라인 추첨 방식은 미리 추첨 결과를 뽑아서 저장해 놓는 방식을 오프라인 추첨 오프라인 예측 방식이라고 부르고 있음
- 학습 후 온라인 예측 방식은 사용자가 장바구니에 어떤 상품을 담았을 때 그 상품과 함께 어울릴 만한 상품을 추천해 주는 서비스임
- 온라인 예측을 위해서는 모델뿐만 아니라 모델에 함께 전달할 피처 데이터도 필요함

데이터베이스의 의존성
- 데이터를 데이터베이스에 올려줌으로써 추천을 전달할 수 있음
- 데이터 전달 방식은 두 가지 의존성을 불러옴
- api를 통해 주고받자 그리고 꼭 필요한 정보만 주고받자는 정책도 의존성을 줄이는 데 매우 큰 영향을 미쳤음

에어플로우의 단점
- 에어플로우에서 모델 학습 테스크를 수행하면 gpu 서버에 베이 콘다 가상 환경에서 활성 파일이 실행되는 시기였음
- 에어플로우에 ssh 오퍼레이터를 사용해서 gpu 서버로 명령어를 날림
- 에어플로우의 단점은 학습 안정성이 떨어지고 의존성 관리가 어렵다는 것임
- 데이터센터의 쿠버네티스 환경을 구축해서 학습 환경을 컨테이너 기반으로 전환함

코네틱스 환경의 실시간 서비스
- 하이퍼 파라미터 튜닝, 벡터 서시, 대용량 데이터 분산 처리 등 새로운 서비스가 보이면 빠르게 셋업해서 테스트해보는 게 중요함
- 코네틱스 환경에서 사용하기 쉬운 형태로 제공이 됨
- 실시간이라는 단어를 잘 살펴볼 필요가 있는데 다 같은 실시간이 아니기 때문임

실시간 데이터 수집
- 장바구니에 담은 상품 등을 추천 서비스에 녹여내면 완전히 새로운 서비스를 만들어낼 수 있음
- 실시간성 데이터를 추천 서비스에 잘 녹여내기 위해서는 실시간 정보를 함께 전달받는 것이 가장 간단한 방법임
- 실시간 데이터를 얻기 위해서 추가로 뭔가를 개발할 필요가 없음
- 모델 혹은 서비스의 요구 사항이 바뀔 수 있음
- 실시간 데이터를 수집하고 전달한다는 것 자체가 앞쪽 서버에게 부담이 될 수 있음

데이터 플랫폼 팀의 ups
- 데이터 플랫폼 팀의 ups에 올라탈까 아니면 우리가 직접 셋업해서 사용할까 두 가지 선택지가 있는데 여러분들이라면 어떤 선택을 할 것 같으신지 물어봄
- 데이터 플랫폼 팀도 일이 바쁘신데 우리의 요구 사항을 다 맞춰주실 수 있을까 또는 새벽에 갑자기 문제가 생기면 데이터 플랫폼 팀에서 빠르게 대응을 해 주실 수 있을까 걱정이 됨

sql 자동 포맷팅
- 목표가 명확해야 함
- sql 자동 포맷팅 또는 api를 빠르게 구현하는 것이 목표임
- 목표를 해결하기 위해 돌진하는 것이 중요함

비전공자 부트캠프 수료 후 근황

오랜만에 개발 블로그에 근황을 남긴다. 취업 후 바쁜 업무와 인생의 빅 이벤트인 결혼이 있어서 한동안 블로그를 소홀히 했었다. 지난 2월 스파르타 코딩클럽 항해99를 수료하고 스프링 개발자가 되겠다는 부푼 꿈을 안고 취업시장에 뛰어들었다. 다시 대학교 4학년 때로 돌아간 느낌이었는데 의외로 그때 보단 스트레스가 덜했다. 어차피 나의 수준 (비전공자 부트캠프 3개월 공부)을 생각하니 그렇게 바라는 게 많지 않아서였다. 회사 입장에서 나를 개발자로 뽑을 이유가 딱히 없다고 생각해서 작은 회사, 신생 회사 위주로 넣었다. 이제는 큰 규모 회사가 싫기도 했기 때문이다. 업계 평균 초봉 범위에 들기만 한다면 땡큐였다. 

비전공자 부트캠프 출신 취업 하다

이력서를 넣은지 한달이 다 되어가니 여러 회사에서 면접 제의가 들어왔다. 규모가 작은 스타트업 위주로 넣었는데 시드 단계에서 부터 시리즈 C, 중견 기업에서 면접 제의가 들어왔다. 그러다가 면접 본 곳 중 가장 나를 필요로 할 거 같은 곳으로 선택했다. 나는 스프링을 겨우 3개월 정도 공부한 완전 초짜인데 node.js를 시키겠다는 곳이었다. 고심 끝에 취직을 결심하고 들어간 곳에서 처음 2주동안은 node.js를 공부하고 바로 개발에 투입되었다. 스프링에 비해서 node.js는 쉬운 편(?)이었다. MongoDB를 사용하는 데 SQL보다 휠씬 개발하기 쉽다. 사람들도 좋고 시니어 개발자와 붙어서 일하는 환경도 모르는 것을 친절하게 알려주시는 환경도 좋다. 입사 3개월 후에는 주 3일 재택도 가능해졌다. 취업 후 3군데 정도에서 더 면접 제의가 왔었고 규모도 훨씬 크고 업력도 훨씬 오래된 곳들이었지만 고사했다. 재택은 최고의 복지다. 

주니어 개발자 7개월 후기

개발자가 스트레스가 아예 없는 직업은 아니지만 (그런 직업은 없다. 백수도 스트레스가 있다.) 전에 내 전공일을 하며 사람 스트레스와 내 잘못이 아닌 타인의 잘못된 결정과 판단으로 밤을 새던 날과는 다르게 나의 미숙함과 잘못으로 밤을 새기 때문에 훨씬 낫다. 전직장에서 스트레스가 100이었다면 여기는 10 정도다. 내 업무량은 나의 숙련도와 관련해서 결정된다.  내가 못하면 밤새는 거고 빨리 잘하면 빨리 퇴근하는 거다. 이제 코딩의 ㅋ을 안지 겨우 1년 밖에 안된 비전공자 부트캠프 출신이 개발자로 취직을 했기 때문에 오래 걸리고 실수가 많고 아는 게 없는 게 당연해서 야근을 하는 것에 불만이 없다. 납기를 맞추는 것이 좀 스트레스긴 하지만 말이다. 그리고 체감 상 스프링보다 노드가 상대적으로 쉽다. SQL보다 NoSQL이 쉽다. 

스타트업 주니어 개발자

사실 스타트업이란 곳에서 일하는 것은 꽤나 모험적인 일이다. 작은 초기 인원으로 많은 것을 하려다 보니 개발 업무 이외에도 할 것들이 생긴다. 전공을 살려 IR 자료 리서치를 도와드린 적도 있다. 아마 이게 내가 빨리 취업된 이유일 것 같기도 하다. 매 주 각자 자유 주제를 가져와서 모든 구성원 앞에서 스터디 발표를 한다. 생각해보니 다음 주는 내가 발표를 하는 날이다. 큰일이네. 매 주 주제를 생각하는 것도 고역이다. 한 사람이 여러가지 업무를 같이 하다 보니 정신이 없을 때도 있지만 스타트업의 묘미가 아닌가 싶다. 회사가 성장하는 게 눈에 보여서 다들 바쁠수 밖에 없다고 생각했다. 나는 물론 개발 업무가 95%다. 다른 걸 같이 할 여력이 안되는 것도 있다. 그래도 나의 아이디어와 제안들이 받아질 때도 종종 있어서 탑 다운 방식이 99.9%였던 전 직업 보다는 훨씬 직업 만족도나 회사에 대한 만족도가 크다. 연봉은 전보다 3분의 1이 되었지만 돈보다 마음 편한 게 최고다. 아무래도 스타트업은 빨리 성장하는 게 목표인지라 고객의 니즈를 빨리 맞춰주려하고 그에 따라 개발 일정도 산정이 되기도 한다. 

node.js를 취업해서 2주 배워놓고 개발자로 일 한지 벌써 7개월이 흘렀다. 아직 아무것도 모르는 거 같고 비동기, 동기가 나를 괴롭히지만 향후 5년 간은 계속해서 개발을 할 것 같다. 개발일은 재미있고 늘 흥미롭기 때문이다. 5년이라는 짧은 텀을 잡은 이유는 인생 어디로 흘러갈지 모르기 때문. 나도 처음 취업했을 때 그 회사 10년 다닐 줄 알았다. 코로나 터질 줄 몰랐고 개발 배울지 몰랐고 올해 결혼할지도 몰랐다. 

현재 진행하는 사이드 프로젝트 'developSpace'에서는 탈퇴하면 '우주미아'라는 닉네임으로 변경해주기로 결정을 했었습니다. 탈퇴 기능 구현을 맡았는데 기존 게시물은 삭제 하지 않으면서 게시물에 나오는 닉네임은 '우주미아'로 변경하고, 프로필 사진도 기본 사진으로 변경하고, 회원 칼럼을 없애려고 합니다. 

그런데 모든 탈퇴 회원이 '우주미아'라는 닉네임을 가지면 중복이 되어 문제가 생기니 랜덤 숫자와 형용사를 붙여주기로 했습니다. 

랜덤 닉네임 만들기

필수적으로 들어가야 하는 것은 '우주미아'입니다. 겹치지 않기 위해서 형용사와 숫자를 포함시킨 랜덤 닉네임을 만드려고 합니다.

public static String randomNickname(){
    List<String> adjective = Arrays.asList("행복한", "슬픈", "게으른", "슬기로운", "수줍은",
            "그리운", "더러운", "섹시한", "배고픈", "배부른", "부자", "재벌", "웃고있는", "깨발랄한");
    String name = "우주미아";
    String number = (int)(Math.random() * 99)+1 +"";
    Collections.shuffle(adjective);
    String adj = adjective.get(0);
    return adj+name+number;
}

String 값을 반환하는 randomNickname 메서드를 만들었습니다.

형용사는 제가 맘대로 적어넣은 겁니다.

적다보니 19개를 적었네요. 나중에 20개로 늘려야겠습니다.

Collections.shuffle을 사용하면 List의 값들을 섞어줍니다. 

말그대로 셔플을합니다.

셔플 한 값중 가장 첫번째 값을 adj 에 저장합니다.

기본으로 들어가는 "우주미아"는 String name에 저장했습니다.

마지막으로, 랜덤 숫자(number)를 저장합니다.

99까지 숫자 중에서 랜덤으로 숫자가 나갑니다.

이 3가지 값들을 하나로 더하면 adj + name + number 로 랜덤 닉네임이 완성됩니다.

"부자+우주미아+57" 이 나왔네요!

어제 CI/CD와 MySQL 연동을 완료했고 이제는 회원 관련 API를 만들어야 합니다. 오늘 밤까지 기능 구현 다 하기로 했거든요. 제가 구현 해야하는 기능들은 아래와 같습니다.

• [ ] 카카오 로그인 - Spring Security
• [ ] 구글 로그인
• [x] 멤버 권한 ENUM - MEMBER, ADMIN
• [x] 관리자 로그인
• [ ] 닉네임 변경
• [ ] 탈퇴 → 우주미아

카카오 로그인은 이전에도 해봐서 괜찮고 구글 로그인은 뒤로 미뤄도 될 것 같습니다. 관리자 로그인이긴하지만 기본 로그인 이미 구현 완료했고 멤버 권한 칼럼도 따로 만들었습니다. 닉네임 변경과 탈퇴는 안해봤는데 이번 기회로 해보면 좋을 것 같습니다. 닉네임 변경은 별로 안어려울 것 같습니다. 이번 프로젝트에서는 탈퇴 시에 닉네임을 우주 미아로 변경하기로 했습니다. 로그인은 못하지만 게시글 내역은 지우지 않는 것으로 정했습니다. 

그리고 swagger를 적용해서 하는 것을 잊지말아야 겠어요. 자꾸 까먹네요.

대략적으로 오늘 할 일 순서는

1. 카카오 로그인 API (이메일, 닉네임, 프로필 사진)

2. 닉네임 변경 설정 API

3. 탈퇴 API

입니다.

저녁 먹기전에 다 끝내봅시다.

테스트 코드 짜는 연습하기 전에 CI/CD를 구축하려고 합니다. aws ec2와 codedeploy와 githubaction을 사용하여 무중단 배포를 구현하였습니다. 전에 최종프로젝트할 때 팀장님이 프로젝트 시작도 전에 다 해놓으신거를 사용했었는데 굉장히 효율적으로 잘 사용했었습니다.

Codedeploy 설치하기

이제 명령어 치는 것도 익숙해져서 터미널을 겁내지 않게 되었습니다.

원래는 까만건 종이요 하얀건 글씨였답니다.

위의 블로그 글을 참조했습니다.

가장 도움이 되고 깔끔하게 정리되어 있습니다.

물론 aws 공식 문서가 가장 정확합니다.

CI/CD 성공!!!

자그만 오류가 하루종일 절 붙들고 있었지만 결국 성공했습니다. 

만세.

하루종일 찾다가 이것 저것 다 시도해봐도 안되서 설마 이거인가 하고 해봤는데 이거였다.

springframework.book version 이 2.7.8 이었는데

version을 2.7.6으로 변경하자마자 잘되는 걸 확인했다.

3초만에 build 가 되었다.

아래는 전체 build.gradle 이다. 별걸 다 시도 해봤지만 아니어서 허탈하다. 하지만 해결해서 행복.

plugins {
    id 'java'
    id 'org.springframework.boot' version '2.7.6'
    id 'io.spring.dependency-management' version '1.1.0'
}

group = 'developSpace.com'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '17'

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-security'
    implementation 'org.springframework.boot:spring-boot-starter-web'

    implementation 'io.springfox:springfox-boot-starter:3.0.0'
    implementation 'org.mapstruct:mapstruct:1.5.3.Final'
    implementation 'mysql:mysql-connector-java'

    compileOnly 'org.projectlombok:lombok'
    compileOnly group: 'io.jsonwebtoken', name: 'jjwt-api', version: '0.11.2'
    runtimeOnly group: 'io.jsonwebtoken', name: 'jjwt-impl', version: '0.11.2'
    runtimeOnly group: 'io.jsonwebtoken', name: 'jjwt-jackson', version: '0.11.2'

//    runtimeOnly 'com.h2database:h2'
    runtimeOnly 'mysql:mysql-connector-java'

    annotationProcessor 'org.projectlombok:lombok'
    annotationProcessor 'org.mapstruct:mapstruct-processor:1.5.3.Final'

    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testImplementation 'org.springframework.security:spring-security-test'

}

tasks.named('test') {
    useJUnitPlatform()
}

jar {
    enabled = false
}

이력서 고치랴, 면접준비하랴, 프로젝트 하랴, 그동안 못만난 지인들 만나랴, 밀린 드라마 보랴, 아주 바쁜 생활이 지속되고 있습니다. 친구들이랑 노는 것은 새로운 게 없지만 개발은 늘 새롭네요. 회원가입 로그인을 구현을 작년 11월에 해보고 안하다가 이번에 새로 사이드 프로젝트를 하면서 구현을 담당하게 되었습니다.

회원가입이 생각보다 단순하지는 않습니다.

1. 이메일 중복체크

2. 닉네임 중복체크

3. 이메일 유효성 확인

4. 비밀번호 유효성 확인

5. 닉네임 유효성 확인

6. 프로필 이미지

쓰다 보니까 더 많아졌네요. 

우선 오늘은 swagger랑 기본 security 설정을 커밋했고 위에 나열한 것들을 다 하고 잘 예정입니다.

@Size(min = 8, max = 15, message = "비밀번호의 길이는 8자에서 15자 사이입니다")
@Pattern(regexp = "[a-zA-Z0-9`~!@#$%^&*()_=+|{};:,.<>/?]*$", message = "비밀번호 형식이 일치하지 않습니다")
private String password;

validator 클래스를 따로 만들어서 해야 겠습니다. 생각보다 유효성 검사할 것들이 있네요. 

swagger를 프론트와 소통하는 API 명세서로 계속 사용해왔는데 설정하는 법을 정리해보려고 합니다. Spring Boot 2.7.8, Gradle 환경에서 설정하는 방법입니다. swagger를 사용하면 따로 API 명세를 작성하지 않아도 되고 추후에 수정할 일이 생겨도 자동으로 수정이 되서 편합니다. 프론트랑 소통할 때도 문서로 하는 것보다 swagger로 바로바로 업데이트 되어서 생산성도 높아집니다.

1. Build.gradle 의존성 추가

implementation 'io.springfox:springfox-boot-starter:3.0.0'

build.gradle에 위의 dependency 코드를 추가합니다.

2. SwaggerConfig.java

@Configuration
public class SwaggerConfig {
    @Bean
    public Docket api() {
        return new Docket(DocumentationType.OAS_30)
                .ignoredParameterTypes(AuthenticationPrincipal.class)
                .ignoredParameterTypes(Pageable.class)
                .useDefaultResponseMessages(false)
                .apiInfo(apiInfo())
                .select()
                .apis(RequestHandlerSelectors.basePackage("developspace.com.developspace")) // api 스펙이 작성되어 있는 패키지 (controller)
                .paths(PathSelectors.any())
                .build();
    }

    public ApiInfo apiInfo() {
        return new ApiInfoBuilder()
                .title("DevelopSpace Rest API Documentation")
                .description("Develop Space API 명세")
                .version("0.1")
                .build();
    }
}

3. security 설정 풀어주기

security로 막아 놓은 것에 swagger url 설정 추가해줬습니다.

http.authorizeRequests().antMatchers("/api/member/signup","/api/member/login").permitAll()
        .antMatchers("/v3/api-docs/**", "/swagger-ui/**", "/swagger-resources/**").permitAll()
        .antMatchers(HttpMethod.GET,"/api/answer/**").permitAll()
        .antMatchers("api/question/**").permitAll()
        .anyRequest().authenticated();

4. Swagger 확인하기

localhost:8080/swagger-ui/index.html

위의 주소로 접속하면 swagger api 문서를 볼 수 있습니다.

알고리즘이랑 sql 문제들을 풀어야하는데 또 저는 환경에 밀어넣어져야 열심히 하는 나약한 인간이라서 내기를 하기로 했습니다.

다음주 목요일까지 프로그래머스 자바 lv1 문제 다풀기 10만원 빵

총 73문제인데 아직 하나도 안풀어봤습니다. 뇌풀기 몸풀기 용도로 빠르게 풀고 레벨 2로 넘어가야겠습니다. 

이제 인성면접은 그냥 하는데 CS는 휴가 다녀왔더니 기억이 안나서 다시 열심히 해야겠어요.

멘토님들은 어떻게 다 외우고 계시는 걸까요..?

근데 생각해보니 저도 회사다닐때 필요에 의해 다 외우고 살았던거 같습니다.

열심히 외우겠습니다...

잠시 휴식하느라 정신이 없어서 취업코칭을 위한 이력서 업로드를 수정을 다 해놓은 것 말고 바로 전 버전을 올리고 말았습니다. 근데 왠걸 합격점을 받았습니다. 이러면 좀 곤란한데요. 어느 게 더 나은 이력서인지 판단이 안되네요.

아래는 인텔리픽 취업코칭에서 받은 이력서 피드백입니다.

지난 주는 멘토링을 진행했습니다.

멘토님이 해주신 이력서 피드백은 아래와 같습니다. 

• skill 부분에 대한 부분 추가하기
• Introduce에 개발에 대한 가치 , 내가 개발할 때 중요하게 생각하는것들 개발원칙 추가
• *나는 이런 사람입니다가 필요함
• 잘정리해서 -> 자바, Spring boot 3.0 , nginix aws ec2 s3 cloudfront aws deploy githubaction swagger 스킬로 정리해서 쓰기
• 이미지가 들어가면 좋을 것 같음
  • 왼쪽 기술 스택 | 오른쪽 프로젝트 사진 및 상세내용(나의 역할)
• 영어에 대한 강점 어필…….
  • 나의 강점에 대해서 (쓰기)
  • 금융권 경험, 영어 잘하고, 개발도 할줄앎

취업 스터디 기간도 끝났고 수요일인 내일에는 또 다시 모의 면접날입니다. 5만원 돌려받을 수 있을지는 모르겠지만 모의면접은 참여합니다.

💡문제 상황

첫번째 게시글에서는 좋아요 클릭 시, 반영이 잘 되는데 두번째 게시글부터 게시글 좋아요가 반영이 안되는 현상이 발견됨. 게시글을 조회하고 있는 멤버의 좋아요 여부를 나타내는 isLiked 값이 여러번 연속해서 처리할 때 계속해서 true로만 반환 됨. 트랜잭션이 충돌을 일으킨 것으로 여겨짐.

해당 게시글에 조회하는 멤버가 좋아요를 눌렀을 시, 생성되는 postLike 데이터를 조회하는 과정에서 에러가 나는 것으로 확인됨. 해당 멤버와 해당 게시글 아이디로 데이터를 조회하여 postLike가 이미 있으면 false로 반환(좋아요 취소)하고 없으면 true로 반환(좋아요 성공)하는 로직임.

📒선택지

1. 낙관적 락(Optimistic Lock): version 관리를 통해 application 레벨에서 처리하는 방법으로, JPA가 제공하는 버전 관리 기능(@Version)을 사용함. 대부분의 트랜잭션이 충돌하지 않는 다고 가정하는 방법임. 충돌이 나는 것을 막지 않고, 충돌이 난 것을 감지하면 처리함

2. 비관적 락(Pessimistic Lock): 트랜잭션의 충돌이 발생한다고 가정함. 하나의 트랜잭션이 자원에 접근 시 락을 걸고, 다른 트랜잭션이 접근하지 못하게 함. 데이터 수정 즉시 트랜잭션 충돌 여부 확인이 가능함. DB 단에서 Lock을 함.

🤔 문제 해결

• 이미 충돌이 발생한 것을 확인 했기 때문에 비관적 락을 사용하기로 결정함. 복합키를 이용하여 좋아요 데이터를 찾아오는 메서드에 비관적 락을 걸어주었음.

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Transactional
@QueryHints({@QueryHint(name = "javax.persistence.lock.timeout", value ="3000")})
Optional<PostLike> findByPostLikedIdAndMemberId(Long postLikedId, Long memberId);

• 비관적 락에는 두가지 종류가 있음:
  • Exclusive Lock: 데이터를 변경하고자 할 때 사용되며, 트랜잭션이 완료될 때까지 유지되어 해당 Lock이 해제될 때까지 다른 트랜잭션은 해당 데이터에 읽기를 포함하여 접근을 할 수 없음
  • Shared Lock: 다른 사용자가 동시에 데이터를 읽을 수는 있지만 Write는 할 수 없음
• LockModeType으로 PESSIMISTIC_WIRTE 선택하였는데, PESSIMISTIC_WRITE은 Exclusive Lock을 걸고, 데이터를 읽거나, 업데이트 하거나, 삭제하는 것을 막음
• Lock이 길어지면 Latency가 길어지기 때문에,  @QueryHints 를 사용하여 Lock에 3초 타임 아웃을 적용함

→ 좋아요 여부 값(isLiked) 반환 정상적으로 실행 됨

기타 고려사항

• 단일 DB 환경이기 때문에 비관적 락을 사용해서 문제가 발생하지 않지만 추후에 분산 DB를 사용하는 환경일 경우에는 분산 락(Distributed Lock) 도입도 고려해 볼 수 있음. (위의 이미지는 현재 아키텍쳐; RBS 하나를 사용)

• 비관적 락은 모든 트랜잭션에 대해 Lock을 사용하기 때문에 트래픽이 많은 경우, O(N^2) 정도로 성능이 저하된다는 문제가 생길 수 있음.

웹 서버와 WAS의 차이는?

대표적인 웹서버는 Apache, Ngnix가 있습니다.웹서버란 HTTP 프로토콜을 기반으로 클러이언트가 웹 브라우저에 요청을하면 그 요청을 받아서 정적 컨텐츠를 제공하는 서버입니다. 정적 컨텐츠는 단순 HTML 문서, CSS, 이미지, 파일 등 즉시 응답 가능한 컨텐츠를 말합니다. 웹서버가 정적 컨텐츠가 아닌 동적 컨텐츠를 요청 받으면 WAS가 요청을 처리하게 되고 그 결과를 웹서버가 클라이언트가 전달하는 역할도 하게 됩니다. 

WAS(Web Application Server)는 서블릿 컨테이너, 웹 컨테이너라고 불리기도 하는데 웹 서버의 기능들을 구조적으로 분리하여 처리하는 목적으로 만들어졌습니다. 분산 트랜젝션, 보안, 쓰레드 처리 등을 처리하는 분산 환경에서 사용이 됩니다. WAS는 프로그램 환경과 DB 접속 기능을 제공하고 여러개의 트랜잭션을 관리할 수 있습니다. WAS의 종류로는 Tomcat, JBOSS, WebSphere 등이 있습니다.

Stack과 Queue 그리고 Array와 Linked List 자료구조에 대해 말씀해주시고 차이점에 대해 설명해주세요.

배열(Array)와 Linked List에 설명을 드리자면 먼저 배열은 구조가 간단하고 데이터를 읽는데 걸리는 access time이 짧은 편입니다. 단점으로는 크기를 변경할 수 없고, 크기 변경을 피하기 위해 충분히 큰 배열을 생겅하면 메모리가 낭비가 됩니다. 또 비순차적인 데이터의 추가, 삭제에 시간이 많이 걸린다는 단점이 있습니다. LinkedList는 이런 배열의 단점을 보완한 것이 특징입니다. 비연속적으로 존재하는 데이터를 연결하고 단 한번의 참조 변경으로 데이터 삭제가 가능합니다. 또 한번의 Node 객체 생성과 두번의 참조 변경만으로 데이터 추가가 가능합니다. 링크트리스트는 데이터 접근성이 나쁘다는 단점이 있는데 이중 연결 리스트는 이러한 문제를 보완하여 접근성을 향상시켰습니다. 배열은 빠른 접근이 요구되고, 데이터의 삽입과 삭제가 적을 때 사용하고 링크드리스트는 삽입과 삭제 연산이 잦고, 검색 빈도가 적을 때 사용합니다.

@SpringBootTest와 @WebMvcTest의 차이점을 설명해 주세요.

@SpringBootTest는 프로젝트 내부에 있는 스프링 빈을 모두 등록해서 사용해서 테스트가 느리다는 특징이 있습니다. 실제 운영 환경에서 사용되는 클래스들을 통합해서 테스트하기 때문에 실제 환경과 가장 유사하게 테스트가 가능합니다. Service 의 메서드가 변경이 되어도 Mocking 값을 수정하지 않아도 되서 변경이 자유롭습니다. 그러나 테스트 단위가 크기 때문에 디버깅이 어렵다는 단점이 있습니다.

@WebMvcTest는 컨트롤러의 역할만을 테스트합니다. Web Layer에 해당하는 빈만 생성해서 테스트하기 때문에 @SpringBootTest보다 빠르다는 장점이 있습니다. 그러나 Mock 객체를 사용해서 실제 동작과는 차이가 날 수 있습니다. 또한 메서드 변경이 일어날 때 Mocking값을 수정해줘야 한다는 번거로움이 있습니다. 

트랜잭션이 무엇인지 설명해 주세요.

트랜잭션이란 데이터베이스의 상태를 변화시키기 위해서 수행하는 작업의 단위를 뜻합니다. 원자성(Atomicity)은 트랜잭션의 가장 큰 특성으로 트랜잭션 안의 작업들이 분리되어 작업불가하고 모두 반영되던가 전혀 반영되지 않아야 합니다. 일관성은 트랜잭션이 진행되는 동안 데이터베이스가 변경되었더라도 기준은 트랜잭션을 진행하기 위해 참조한 데이터베이스 정보로 진행되어야 합니다. 고립성은 둘 이상의 트랜잭션이 동시에 실행되고 있을때 서로 트랜잭션 연산에 관여되지 않아야합니다. 지속성은 트랜잭션이 성공적으로 완료 되었다면 그 결과는 영구적으로 반영되어야 합니다.

TCP와 UDP의 공통점과 차이점을 설명해보세요.

TCP(Transmission Control Protocol)는 신뢰성 있는 데이터 전송을 지원하는 연결 지향형 프로토콜로 일반적으로 TCP와 IP가 함께 사용되는데, IP가 데이터의 전송을 처리한다면 TCP는 패킷 추적 및 관리를 하게 됩니다. 연결 지향형인 TCP는 3-way handshaking이라는 과정을 통해 연결 후 통신을 시작하는데, 흐름 제어와 혼잡 제어를 지원하며 데이터의 순서를 보장합니다. UDP(User Datagram Protocol)는 비연결형 프로토콜로써, 인터넷상에서 보내는 쪽에서 일방적으로 데이터를 전달하는 통신 프로토콜로 TCP와는 다르게 연결 설정이 없으며, 혼잡 제어를 하지 않기 때문에 TCP보다 전송 속도가 빨라 실시간 동영상 스트리밍 서비스 같은 서비스에 적합합니다. 그러나 데이터 전송에 대한 보장을 하지 않기 때문에 패킷 손실이 발생할 수 있습니다.

하루종일 코딩을 하다가 거북목이 악화되는 게 매우 느껴져서 잠시 넷플릭스 다큐멘터리를 봤습니다. spaceX가 어떻게 화성에 가려고 하는지, 일론 머스크는 어떻게 로켓맨이 되었는지에 대한 흥미로운 다큐멘터리였습니다. 

저는 화성 이주 같은 거창한 꿈은 꾸지 못하지만 나름 생각하고 꿈만 꿨던것을 하나하나 이루어 가고 있습니다. 훌륭한 개발자가 되는 것을 장기프로젝트라고 생각하고 지금 당장 좌절하고 실패하더라도 꾸준히 나아가겠습니다. 

취준생이긴하지만...! 부트캠프 때문에 주말에 친구들을 안만난지 꽤 됐는데 오랜만에 만나서 폭풍수다를 떨었습니다. 물론 만나기 직전까지 카페에서 공부하다가 갔답니다.

개발자는 즐겁습니다. 왜냐면 생각하면 다 만들 수 있기 때문이죠. 오늘만 미팅을 2개 했습니다. 하나는 항해99 최종 프로젝트 발전 시키기 위한 회의이고 하나는 제가 제안한 미니(not so mini) 프로젝트에 대해서 기능을 확정하기 위한 회의였습니다. 제가 예전에 꿈꾸던 삶을 살고 있어서 행복하긴 한데 물리적으로 시간이 부족함을 느낍니다. 저는 아이디어는 정말 많은데 바로 구현할 수 없는 점이 늘 아쉬웠거든요. 지금은 부트캠프에서 만난 인연들과 아이디어를 떠올리기만 하면 바로 팀이 만들어져서 (순식간에 무려 8명이 모였습니다;) 바로 실현 가능성이 보이거든요. 더 빨리 개발자를 하지 못한 것이 아쉬울 따름입니다. 

최종 프로젝트 발전 시키기

최종 프로젝트 관해서는 리팩토링(interface를 사용해서 서비스 구현하기 등), 페이지 추가, 서비스 보완, 부하 테스트, 성능 테스트 등 기능 구현하기에 급급해서 놓쳤던 부분들을 채워나가기로 했습니다. 장기 프로젝트로 전에 시간에 쫓기면서 하던 것과는 달리 취업 준비도 하면서 좀 여유를 가지고 진행하기로 했습니다. 밤새기 금지를 룰로 넣을까도 했습니다. 프론트에 열정맨이 계셔서 잠을 안주무시거든요. 트러블 슈팅을 하다보면 저도 새벽까지 하는 게 허다하긴 하지만 그분은 아예 잠을 안주무시더라구요. 그분께 미니프로젝트도 같이하자고 한 거였는데 8명이 되버렸습니다. 열정맨과 함께하니 좋습니다 🤦‍♀️

미니 프로젝트 - DEVELOP SPACE

백엔드 3명, 프론트 3명, 디자이너 2명이 함께하는 전혀 미니미 하지못한 이 프로젝트를 처음 기획하게 된 의도는 '우리끼리 재밌게 뭐 하나 하면 좋겠다~ 면접 공부할 때 폰에 단어장처럼 들고 다니면 어떨까?' 였는데 뭔가 본격적으로 시작이 되어버렸습니다. 안드로이드 앱 출시를 목표로 달리려고 합니다. 2주가 될 줄 알았던 프로젝트는 아마 디자인이 나오는데만 2주가 소요 될 것으로 예상이 됩니다. 다행히 api가 복잡하거나 많지는 않아서 (20개 안쪽) 부하 테스트라던지 좀더 백엔드 적인 것들을 시도해보려고 합니다. 테스트 코드도 꼭꼭 해보고 싶어서 제가 얼른 기능 구현 끝내버리고 하자고 이야기 하고 있습니다. 

저는 이번에 회원가입, 로그인 쪽을 맡게 되었습니다. CI/CD 구축과 Swagger 세팅도하고 Spring Security까지 제가 부트캠프 내내 안해봤던 것들을 해보고 싶어서 자진해서 나섰습니다. 다들 github action 쓰고 aws 능숙하게 다루고 linux도 마찬가지로 많이 안해봐서 이번 기회에 좀 파고들면 좋을 거라고 생각했습니다. 현재 CI/CD를 할려면 shell script라는 걸 써야 한다고 해서 열심히 찾아보고 있습니다. github action을 쓰는 이유는 저희가 협업 툴로 github을 쓰기 때문입니다. 버전 관리하는 것도 훨씬 익숙하기도 합니다. 우선 제 아이디로 ec2 인스턴스랑랑 rds를 생성 해놨습니다. 

취업은 언제?

이제 수료한지 겨우 일주일이 지난 시점이지만 조금은 조급합니다. 벌써부터 면접보러 가시는 분들도 있고요. 저는 이력서용 사진을 하나 찍었습니다. 사진을 넣고 싶지 않았는데 사진을 넣으라는 조언들이 많아서 넣었습니다. 라떼는 상상도 못할일이죠. 아는 분이 개발 팀장인데 그냥 제가 아는 이력서 형식으로 하라고 말씀해 주셔서 그렇게 하려다가 아무래도 붙캠 출신들의 화려한 이력서 사이에서 눈에 띄지는 못할 거 같아 사진을 박았습니다.  아직까지는 서류 합격률이 그렇게 좋지는 않습니다. 한방에 합격하면 좋겠지만 커리어 전환이 쉬울거라고 생각하지도 않았어서 일단은 최선을 다하겠습니다. 코딩하는 것도 재밌고 취업 공부하면서 cs를 배우는 것도 재밌으니까요!

Parameter와 Argument의 차이에 대해 설명해주세요.

parameter는 매개변수명을 말하고 argument는 함수와 메서드의 입력 값(value)를 뜻합니다. 함수를 정의할 때 사용되는 변수를 매개변수, 실제로 함수가 호출될 때 넘기는 변수값을 argument(인수)라고 설명할 수 있습니다. 

프로세스와 스레드의 차이에 대해 설명해 주세요

프로세스는 운영체제로부터 자원을 할당받는 작업의 단위이고, 스레드는 프로세스가 할당받은 자원을 이용하는 실행의 단위입니다. 프로세스는 실행될 때 운영체제로부터 프로세서, 필요한 주소공간, 메모리 등 자원을 할당받습니다. 스레드란 한 프로세스 내에서 동작되는 여러 실행의 흐름으로 프로세스 내의 주소공간이나 자원들을 같은 프로세스내에 스레드끼리 공유하면서 실행됩니다.

어제 밤에 미니 프로젝트 멤버들과 회의를 했는데 인원이 늘어난 만큼 제대로 하자는 의견이 많아서 프로젝트가 더이상 미니가 아니게 되었습니다. 2주정도 생각했던 프로젝트는 한달 정도 될 것 같습니다. 백엔드의 업무가 늘어나긴 했지만 2명이 감당하지 못할 정도는 아니어서 저는 이번달 안에 끝낼 계획입니다. 개발하면서 밤새는 건 괜찮습니다라고 생각했는데 백엔드 1명이 더 추가되었습니다아! 총 8명의 중형 프로젝트가 되었습니다.

저는 그냥 제가 안해본 CI/CD, Spring Security 쪽을 건들여보고 싶었는데요 인원이 늘면서 여유가 생겼습니다. 같이 interface로 service 구현하기 등등을 해보려고 합니다.

MSA(Microservice Architecture)란?

하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐를 말합니다. 예전에는 Monolithic Architecture라는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태로 개발을 하였습니다. 소규모프로젝트에는 합리적일지 모르나 일정 규모 이상의 서비스에서 Monolithic Architecture 는 비효율적입니다. Microservice Architecture에서는 하나의 어플리케이션을 작은 서비스 단위로 나누어서 작업을 하기 때문에 각각의 서비스의 독립적 배포가 가능하고 다른 서비스에 대한 의존성이 낮아집니다. 또한 확장성이 높으며 에러가 발생해도 그 에러가 발생한 단위의 서비스를 격리가 가능하기 때문에 유연한 대처가 가능합니다. 

MSA의 단점으로는 상대적으로 복잡하다는 점이 있고 서비스가 커질 수록 그 복잡도가 늘어날 수 있다는 점이 단점입니다. 서비스가 분리되어 있기 때문에 트랜잭션의 복잡도가 증가하고 많은 자원을 필요로 하게 됩니다. 또 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기가 어려울 수 있고, 데이터의 정합성도 관리하기 어렵습니다. 성능면에서는 서비스간 호출시 API를 사용하기 때문에 통신 비용이나, latency가 그만큼 늘어난다는 단점이 있습니다. 

제네릭에 대해서 설명하고, 컬렉션 클래스에서 왜 제네릭을 사용하는 지 설명해주세요.

데이터 타입을 일반화한다는 의미를 가지고 있으며 클래스나 메서드에서 사용할 내부 데이터 타입을 컴파일 시에 미리 지정하는 방법입니다. 클래스에서 사용할 타입을 클래스 외부에서 설정하는 것 입니다. 제네릭의 장점은 객체 타입의 안정성을 높일 수 있고 반환 값에 대한 타입 변환을 쉽게 할 수 있다는 점입니다. 타입 체크와 형변환을 생략할 수 있어서 코드가 간결해진다는 장점도 있습니다. 컬렉션은 이러한 장점 때문에 제네릭 기법으로 구현이 되어 있습니다. 컬렉션을 특정 타입만 다루지 않고 여러 종류의 타입으로 변환할 수 있도록 컬렉션을 일반화 시키기 위해 제네릭을 사용합니다. 

List, Set, Map, HashMap의 차이에 대해서 설명해주세요.

List는 데이터들이 순서대로 저장되고 중복을 허용합니다. 

Set은 데이터의 집합으로 순서가 없고 중복되는 데이터를 허용하지 않아서 중복되지 않는 데이터를 사용할 때 유용합니다. 

Map은 key와 value라는 페어로 이루어지는 데이터의 집합입니다. key는 중복되지 않고 순서를 보장하지 않습니다. 인덱스가 따로 존재하지 않기 때문에 iterator를 사용해야합니다. HashMap은 마찬가지로 key에 대한 중복이 없으며 순서를 보장하지 않습니다. 동기화가 보장이 되지 않고, key와 value값으로 null을 허용한다는 특징이 있습니다. 

정리하자면, list는 데이터들이 순서대로 저장되며 중복을 허용하고,  set은 순서가 보장되지 않고 중복을 허용하지 않고, Map은 순서가 보장되지 않고 key값의 중복은 허용하지만 value값은 중복될 수 없다는 특징이 있습니다.