From 236a226a95bd29e2e7a3350b3247b58a9e57c67e Mon Sep 17 00:00:00 2001 From: VSFe Date: Thu, 19 Sep 2024 00:34:40 +0900 Subject: [PATCH] =?UTF-8?q?docs:=20=EA=B3=BC=EC=A0=9C=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- assignments/algorithm-market.md | 110 ++++++++++++++++++++++++++ assignments/popping-community.md | 114 +++++++++++++++++++++++++++ assignments/very-simple-sns.md | 128 +++++++++++++++++++++++++++++++ readme.md | 15 ++-- 4 files changed, 361 insertions(+), 6 deletions(-) create mode 100644 assignments/algorithm-market.md create mode 100644 assignments/popping-community.md create mode 100644 assignments/very-simple-sns.md diff --git a/assignments/algorithm-market.md b/assignments/algorithm-market.md new file mode 100644 index 000000000..9d240c908 --- /dev/null +++ b/assignments/algorithm-market.md @@ -0,0 +1,110 @@ +# Assignment - Algorithm Market + +- 해당 과제는 총 5개의 Step으로 구성되어 있습니다. +- 모든 과제는 C4-Cometrue 깃허브 레포에서 관리되어야 하며, 반드시 각 Step이 종료될 때 마다 PR 요청을 날려야 합니다. + - 물론, 다른 사람들의 PR에 대한 리뷰도 가능합니다. +- 서버는 필요할 때 편하게 말씀해 주세요. +- 상당히 고민이 많이 필요한 주제입니다. 일부 Step에 대해서 제공하는 키워드가 힌트가 될 수 있으니, 키워드와 관련한 학습을 진행하는 것을 권장합니다. +- 궁금증이 있으면 주저하지 말고 서로 커뮤니케이션하고, 그럼에도 해결되지 않는다면 질문을 남겨주세요. +- 각 PR 마다 설계 의도를 작성해주세요. 좀 더 효율적인 리뷰가 가능할 겁니다. + +## 프로젝트 설명 + +`온라인 저지 개발` + +- 알고리즘 연습 사이트 (ex. 릿코드, 백준, 프로그래머스) 를 개발해 봅시다. +- 최소 1개 이상의 언어를 지원해야 하며, 정/오답 여부, 메모리 및 시간 제한 여부 등을 체크할 수 있어야 합니다. +- 문제 제작자는 문제 데이터 (ex. 테스트케이스, 시간 및 메모리 제한) 를 쉽게 수정할 수 있어야 합니다. + +### Step 1. 기본 환경 구축 + +#### 구현사항 + +- 기본적인 환경을 구축합니다. 문제를 조회할 수 있는 기능을 개발해 주세요. +- 특정 문제는 다음과 같은 정보를 갖고 있습니다. + - 문제 제목 + - 시간/메모리 제한 + - 제출 횟수/정답자 + - 문제 설명 + - 예제 입출력 데이터 + - 채점용 데이터 (각 문제당 최소 10개 - 입력 파일/출력 파일 별도로 구성) + +#### 프로그래밍 요구사항 + +- 채점용 데이터는 수백mb 가 넘는 경우도 허다합니다. 이 파일들을 어떻게 관리하는게 좋을까요? +- 문제에는 이미지가 반드시 포함되어야 합니다. 이미지를 관리하는 방법도 생각해 보세요. + +### Step 2. 채점 환경 구축 + +#### 구현사항 + +- 사용자가 특정 문제에 대한 코드를 제출한 경우, 해당 문제를 채점하여 결과를 반환하도록 만들어 주세요. +- 해당 Step 에서는 정답/오답 여부만 체크합니다. +- 제출할 수 있는 언어는 본인의 편의에 의해 설정하면 되나, **최소 2개 이상의 언어**를 사용하도록 만들어 주세요. +- Step 1에서 저장된 모든 채점용 데이터를 활용하여 채점하며, 하나라도 답이 다르다면 오답, 전부 맞는 경우에만 정답으로 인식되도록 개발해 주세요. + +#### 프로그래밍 요구사항 + +- 언어의 컴파일 및 빌드부터 진행해야 합니다. 해당 프로세스에서 실패할 시, "컴파일 에러" 메시지가 떠야겠네요. +- 데이터를 보내는 사용자가 악의적인 코드 (ex. 시스템 강제 종료) 를 호출할 수도 있습니다. 이를 어떻게 막을 수 있을까요? + +### Step 3. 채점 환경 구축 (2) + +> 주의: 해당 Step을 100% 완벽하게 수행하기 위해선, +> +> - Docker 등의 가상화 기술을 활용하거나, +> - 채점용 Worker Server Pool을 별도로 구성해야 합니다. +> +> 서버가 1대인 경우엔, **채점 때 마다 달라지는 런타임 차이** 를 어느정도 감수하고 개발해야 합니다. 해당 사항만 인지하신다면 Step 구현이 불가한 건 아니니 참고해 주세요. + +#### 구현사항 + +- 채점 환경을 더 고도화 합니다. +- 이제, 여러 문제에 대한 여러 요청이 동시에 들어올 수 있습니다. +- 또한, 제한시간 및 메모리제한을 체크합니다. + - 참고로, 백준과 프로그래머스의 시간제한/메모리제한 정책이 다릅니다. (백준은 상대적으로 런타임 속도가 느린 일부 언어의 경우에 한 해 보너스 시간 제공, 프로그래머스는 정확성 테스트는 10초/효율성 테스트는 정답 코드의 일정 배수) +- (선택 - 도전) 채점 현황을 조회할 수 있는 API를 개발해 주세요. (채점 중인 경우엔 진행 퍼센트 포함) + +#### 프로그래밍 요구사항 + +- 오래 걸려도 괜찮습니다. 다만, **절대 사용자 요청이 유실되지 않도록** 해야 합니다. +- 서버 1대로 진행해도, **최소 3개의 채점 프로세스**가 돌아야 합니다. +- 사용자가 여러 번 제출 버튼을 누르면, 어떻게 처리해야 할까요? +- (선택 - 도전) 중간에 서버를 꺼버리고, 재부팅 해 주세요. 이 경우에도 사용자 요청이 유실되지 않을 방법이 있을까요? +- (선택 - 도전) Cache의 존재로 인해, 런타임의 오차가 커질 수 있습니다. 이를 보정할 방법을 생각해 보세요. + +### Step 4. 문제 추가 기능 개발 + +#### 구현사항 + +- 유저가 문제를 쉽게 추가할 수 있도록 기능을 개발합니다. +- Step 1에서 언급한 모든 데이터를 필요로 합니다. +- 문제 임시 저장 및 불러오기가 가능해야 합니다. +- 문제 출제자가 지원하는 언어 중 **2개 이상**의 언어로 해당 문제를 해결해야만 공개할 수 있습니다. +- (선택 - 도전) 검수진을 추가합니다. 검수진 3인 이상이 해당 문제를 해결해야만 공개할 수 있습니다. + +#### 프로그래밍 요구사항 + +- 제작중인 문제는 어떻게 관리해야 할까요? 특히 DB에서 어떤 방식으로 관리해야 할지 생각해 보세요. + +### Step 5. 데이터 수정 기능 개발 + +#### 구현사항 + +- 문제에 오류가 있거나, 반례를 추가하기 위한 기능을 개발합니다. +- 문제 지문 수정 및 데이터 추가, 시간제한/메모리제한을 수정할 수 있습니다. +- 만약 데이터를 추가하거나, 시간 및 메모리 제한이 추가된 경우, **관련된 모든 제출은 전부 재채점되어야 합니다.** +- 단, 특정 언어의 시간제한, 메모리제한만 수정된 경우엔 해당 언어에 대해서만 재채점을 진행합니다. + +#### 프로그래밍 요구사항 + +- 재채점이 진행되는 중에도 다른 문제 채점은 여전히 진행되어야 합니다. 어떻게 해야 서비스 영향도를 최소화할 수 있을까요? +- (선택 - 도전) 10,000 개 이상의 제출이 존재하는 문제를 만들고, 수정을 해 보세요. 문제 없이 동작하나요? + +### Step 6. 성능 테스트 + +#### 구현사항 + +- 실제로 개발한 서버의 성능이 어떨까요? +- 사용자의 사용 시나리오를 설계하고, 이를 활용해 스트레스 테스트 툴을 사용한 성능 테스트를 진행해봅시다. + - 여기서는 nGrinder를 사용해 봅시다. diff --git a/assignments/popping-community.md b/assignments/popping-community.md new file mode 100644 index 000000000..e730524c4 --- /dev/null +++ b/assignments/popping-community.md @@ -0,0 +1,114 @@ +# Assignment - Popping Community + +- 해당 과제는 총 7개의 Step으로 구성되어 있습니다. +- 모든 과제는 C4-Cometrue 깃허브 레포에서 관리되어야 하며, 반드시 각 Step이 종료될 때 마다 PR 요청을 날려야 합니다. + - 물론, 다른 사람들의 PR에 대한 리뷰도 가능합니다. +- 서버는 필요할 때 편하게 말씀해 주세요. +- 상당히 고민이 많이 필요한 주제입니다. 일부 Step에 대해서 제공하는 키워드가 힌트가 될 수 있으니, 키워드와 관련한 학습을 진행하는 것을 권장합니다. +- 궁금증이 있으면 주저하지 말고 서로 커뮤니케이션하고, 그럼에도 해결되지 않는다면 질문을 남겨주세요. +- 각 PR 마다 설계 의도를 작성해주세요. 좀 더 효율적인 리뷰가 가능할 겁니다. + +## 프로젝트 설명 + +`사용자가 많은 커뮤니티 만들기` + +- 일반적인 게시판 기능 및 커뮤니티에서 지원하는 다양한 기능을 제공하는 커뮤니티를 개발해 봅시다. +- 단, 데이터의 양이 상당히 많고, 트래픽 또한 많다는 점을 상기해 주세요. + - 테스트 데이터가 필요할 시, **게시물 최소 100만개**, **댓글 최소 500만개** 정도를 생각해 두시면 좋습니다. + - 부분적으로, **그 이상의 데이터**를 요구하는 경우도 있습니다. 이 경우엔 직접 구현 보단 아이디어를 구상해보시면 좋을 것 같습니다. + + +### Step 1. 유저, 게시판, 게시글 + +#### 구현사항 + +- 기본적인 틀을 구상해 봅시다. 일반적인 커뮤니티에서의 유저, 게시판, 게시글 기능을 개발해 주세요. +- 유저의 닉네임은 중복이 불가능합니다. +- 특별한 추가 구현사항은 없으나, 이후 Step 을 위한 초석이라고 생각해 주시면 좋습니다. + +### Step 2. 게시글 작성 + +#### 구현사항 + +- 게시글을 작성합니다. +- 게시글은 모두가 작성할 수 있으며, 특히 Step 1에서 등록한 유저가 아니더라도 **본인이 닉네임을 지정하여 게시글을 작성할 수 있습니다.** (이 경우, 닉네임 중복 체크를 하지 않습니다.) +- 게시글에 이미지 첨부가 가능하며, 이미지는 게시글 어디에나 삽입할 수 있습니다. (즉, **맨 앞/맨 뒤가 아닌 게시글 한 가운데에도 작성이 가능해야 합니다.**) +- 게시글은 본인만 수정, 삭제할 수 있습니다. (유저는 유저 본인이 쓴 글을 수정 및 제거할 수 있으며, 본인이 닉네임을 지정하여 비회원으로 게시글을 작성한 경우 게시글 작성시 사용한 비밀번호를 올바르게 입력한 경우에만 가능합니다.) +- (선택 - 도전) 악성 스크립트를 게시물에 포함하는 것을 방지하기 위해, 게시글 작성 프로세스에서 스크립트 감지를 추가해 주세요. +- (선택 - 도전) 특정 사용자의 도배를 막기 위해, 일정 시간 동안 게시글을 n회 이상 작성할 수 없도록 만들어 주세요. (n은 본인이 정해주세요.) 참고로, 비회원도 포함입니다. + +#### 프로그래밍 요구사항 + +- 스키마 설계가 매우 중요합니다! 특히 엄청난 양의 게시글이 저장되어야 하는 만큼 이후 사용될 쿼리를 고민해 보시는걸 추천 드려요. +- 일반적으로 게시글은 markdown 이나 html 형식을 띄고 있습니다. 본인이 원하는 스타일을 골라서 사용하세요. +- 게시글 내용 기반 검색은 이후 Step 에서도 다루지 않을 것이니, 너무 걱정하지 마세요. + +### Step 3. 댓글 기능 구현 + +#### 구현사항 + +- 댓글 및 답글 기능을 구현합니다. +- 댓글은 모든 게시물에 작성 가능하며, 답글은 **특정 댓글에 대한 답글과 댓글**에만 작성할 수 있습니다. (즉, 4depth 이상의 댓글/답글 구조는 존재해선 안 됩니다.) +- 댓글의 길이 제한은 임의로 설정해 주세요. (무제한이 되어선 안 됩니다.) +- 게시글 조회 시, 댓글/답글을 합쳐 최대 100개만 화면에 노출합니다. +- 만약 답글이 많아 노출 대상에서 잘리면, 그 다음페이지의 시작에는 답글이 이어서 나와야 합니다. + +#### 프로그래밍 요구사항 + +- 댓글과 답글이 같은 스키마를 쓰는게 좋을까요? 별도의 테이블을 사용하는게 좋을까요? +- 상술했듯이, 우리는 댓글 **500만개**가 저장되어 있음을 상정해야 합니다. 효율적인 조회 전략을 찾아주세요. + +### Step 4. 게시판 기능 수정 + +#### 구현사항 + +- 게시판의 기능을 강화합니다. +- 이제, **유저가 게시판을 만들 수 있습니다.** +- 생성된 게시판을 만든 유저는 게시판의 메타데이터 수정, 게시글 강제 삭제 등의 기능을 갖습니다. +- 게시판에는 공지사항이 추가되며, 해당 공지사항은 게시판의 최상단에 출력될 수 있도록 해야 합니다. (단, 각 게시판 마다 최대 3개까지만 허용되며, 공지사항은 게시판을 만든 유저가 설정할 수 있습니다.) +- (선택 - 도전) 특정 조건에 맞는 게시물들을 다른 게시판으로 마이그레이션 하는 기능을 개발해 주세요. + +#### 프로그래밍 요구사항 + +- 이 변화로 인해 게시물 스키마에 변화가 있을까요? 이미 많은 데이터를 삽입했다면, 테이블의 구조를 변경할 시 얼마나 많은 시간이 걸리는지 확인해 보는 것도 좋겠네요. + +### Step 5. 좋아요/싫어요 기능 개발 + +#### 구현사항 + +- 좋아요/싫어요 기능을 개발합니다. +- 게시글 및 댓글/답글에 달 수 있으며, 최대 1회만 가능합니다. +- 비회원도 좋아요/싫어요를 달 수 있으나, 이 또한 최대 1회만 가능합니다. +- 당연하지만, 좋아요/싫어요 취소도 가능합니다. +- 이제, 게시글 조회 시 특정기간 (ex. 일주일) 간 좋아요를 많이 받은 게시글 순으로 볼 수 있도록 조회 기준을 추가합니다. +- (선택 - 도전) 가만히 있으면 좋아요/싫어요 수가 실시간으로 반영되도록 해 주세요. + +#### 프로그래밍 요구사항 + +- 일반적인 게시물, 댓글 작성에 비해 좋아요/싫어요 API 호출의 빈도는 훨씬 높을 것 입니다. 어떻게 해야 효율적인 로직을 구성할 수 있을까요? +- 조회 기준은 유저가 정하는 것이 아닌, 사이트에서 특정 옵션을 제공해주는 느낌으로 만드셔도 괜찮습니다. + +### Step 6. 어드민용 API 개발 + +#### 구현사항 + +- 사이트 관리 및 더 나은 사이트를 만들기 위해, 관리자측에서 요구한 API를 개발해 봅시다. +- 특정 유저가 작성한 게시글, 댓글을 조회할 수 있어야 합니다. + - 단, **탈퇴한 유저의 게시글, 댓글도 조회할 수 있습니다.** + - 또한, **유저가 삭제한 게시글, 댓글도 조회가 가능하며, 삭제 이유 (ex. 본인 삭제, 게시판 운영진에 의한 강제 삭제) 를 확인할 수 있어야 합니다.** +- 특정 기간동안 발생한 게시글 작성, 댓글 작성, 좋아요/싫어요 수를 카운트하여 통계처럼 제공하는 기능이 있어야 합니다. +- 압수수색 요청을 대비하여, 특정 유저가 작성한 모든 게시물, 댓글, 업로드한 이미지를 압축파일로 변환하는 기능이 필요합니다. + +#### 프로그래밍 요구사항 + +- 통계성 API 작성 시, 게시글과 댓글과 달리 좋아요/싫어요는 일반적인 카운트로는 불가능할 것 입니다. 어떻게 해야할까요? +- **이미지의 양이 너무 많아, 서버의 가용 메모리보다 더 큰 용량을 차지할 수 있습니다.** 해당 사항을 잘 숙지해 주세요. + +### Step 7. 성능 테스트 + +#### 구현사항 + +- 실제로 개발한 서버의 성능이 어떨까요? +- 사용자의 사용 시나리오를 설계하고, 이를 활용해 스트레스 테스트 툴을 사용한 성능 테스트를 진행해봅시다. + - 여기서는 nGrinder를 사용해 봅시다. +- 특히, 해당 과제는 실제 데이터를 적재하고 테스트할 필요가 있습니다. diff --git a/assignments/very-simple-sns.md b/assignments/very-simple-sns.md new file mode 100644 index 000000000..200fe57b2 --- /dev/null +++ b/assignments/very-simple-sns.md @@ -0,0 +1,128 @@ +# Assignment - Very Simple SNS + +- 해당 과제는 총 7개의 Step으로 구성되어 있습니다. +- 모든 과제는 C4-Cometrue 깃허브 레포에서 관리되어야 하며, 반드시 각 Step이 종료될 때 마다 PR 요청을 날려야 합니다. + - 물론, 다른 사람들의 PR에 대한 리뷰도 가능합니다. +- 서버는 필요할 때 편하게 말씀해 주세요. +- 상당히 고민이 많이 필요한 주제입니다. 일부 Step에 대해서 제공하는 키워드가 힌트가 될 수 있으니, 키워드와 관련한 학습을 진행하는 것을 권장합니다. +- 궁금증이 있으면 주저하지 말고 서로 커뮤니케이션하고, 그럼에도 해결되지 않는다면 질문을 남겨주세요. +- 각 PR 마다 설계 의도를 작성해주세요. 좀 더 효율적인 리뷰가 가능할 겁니다. + +## 프로젝트 설명 + +`기본적인 SNS 만들기` + +- 간단한 기능을 제공하는 SNS를 개발해 봅시다. +- 본격적인 프로젝트 경험이 부족하거나, 단순 기능 개발만 중점적으로 진행하셨던 분들에게 추천 드립니다. (**더 나은 프로젝트를 만들기 위해 무엇이 필요한가?** 에 대한 쉬운 예제라고 생각하시면 좋습니다.) + +### Step 1. 유저 기능 개발 + +#### 구현사항 + +- 유저 기능을 개발해 주세요. +- 기본적인 SNS에서 필요한 기능을 잘 생각해서, 회원가입 시 입력할 수 있도록 해 주세요. + +#### 프로그래밍 요구사항 + +- 금칙어가 있나요? 사용자에게 혼란을 줄 수 있는 키워드는 들어올 수 없도록 원천 차단이 필요합니다. +- 회원가입에 OAuth를 사용해도 되고, 그렇지 않아도 됩니다. 해당 프로젝트의 주 목적은 로그인/인증이 아니니, 편한 방법으로 구현해 주세요. + +### Step 2. 피드 관련 기능 개발 + +#### 구현사항 + +- 피드를 작성하는 기능을 개발해 주세요. +- 일단은 본인의 피드만 보이도록 해야 합니다. +- 피드는 255자 제한이 걸려있고, 이미지를 첨부할 수 있습니다. + - 이미지는 이미지 업로드 후, 생성된 이미지의 URL을 첨부하는 방식으로 구현해 주세요. +- 피드 조회시에는 페이징을 사용해야 합니다. 페이징 기법을 조회 한 후, 일반적인 SNS에서 활용할 수 있는 적당한 방법을 찾아서 사용해 주세요. +- 특정 사용자가 작성, 조회 API를 과도하게 호출하지 못하도록 방어합시다. + - 분당 5회 이상 호출하지 못하게 하도록 방어해 주세요. + - 엄밀한 구현을 위해선 다소 복잡할 수 있으므로, 저희는 **자료구조를 통해 API 횟수를 기록하도록** 설정해 주면 됩니다. + +#### 프로그래밍 요구사항 + +- 데이터가 가장 많이 쌓이게 될 테이블은 바로 피드 테이블입니다. 인덱스를 모른다면 인덱스에 대해 학습하시고, 피드와 관련된 모든 쿼리가 최대한 인덱스를 타도록 개발해 주세요. +- 분 단위 task는 `cron`을 통해 처리하도록 해 주세요. +- 팁이라면, 일반적인 SNS에서 조회를 여러 번 광클해도 실제로는 요청이 서버로 전달이 안 되는 경우가 많습니다. 그렇기에, 정상적인 사용 케이스에서 API 요청 한도를 넘는 경우는 많이 없습니다. + +### Step 3. 팔로우 기능 개발 + +#### 구현사항 + +- 사용자는 다른 사용자를 팔로우할 수 있습니다. +- 특정 사용자를 팔로우한 경우, 타임라인에 해당 사용자의 피드를 조회할 수 있어야 합니다. +- 상대방이 나를 팔로우한 경우, "팔로워" 로 취급되며 별도로 카운트 됩니다. +- 사용자는 팔로우/팔로워 목록을 갖고 있으며, 단순 카운트 외에도 목록을 조회할 수 있습니다. + - 해당 목록 조회 시, 서로 팔로우 상태인 경우 별도 표시가 필요합니다. +- 내가 아닌 다른 사용자의 피드는, "좋아요" 를 남길 수 있습니다. + +#### 프로그래밍 요구사항 + +- 데이터의 양이 본격적으로 많아집니다. +- 일반적으로 팔로우 한 사용자의 피드를 조회할 때는 "IN" 쿼리를 사용하겠죠? + - 서브쿼리로 쿼리가 나가지 않도록 유의하면 좋을 것 같습니다. + - 팔로우한 사용자가 너무 많으면 쿼리가 기형적으로 변할 수 있긴 하지만, 이번에는 해당 사항은 고려하지 않습니다. +- Step 2에서 페이징을 사용하여 쿼리를 구현한 만큼, Step 3에서도 큰 구조는 변경되어선 안 됩니다. +- 관계를 표현하는 별도의 테이블이 필요합니다. + - 힌트를 드리자면, 팔로우 유저/팔로워 유저를 표현하는 각각의 칼럼에 대해 인덱스를 거시는게 좋습니다. + - 가능하면, 인덱스를 안 걸고 쿼리를 수행했을 때의 시간/인덱스를 걸고 쿼리를 수행했을 때의 시간을 기록하시면 많은 도움이 될 거에요. +- 화면에 피드가 보여 "좋아요"를 눌렀는데, 그 시간동안 다른 사용자가 해당 피드를 삭제할 수 있습니다. 이 경우, 어떻게 처리해야 할까요? + +### Step 4. 검색 기능 개발 + +#### 구현사항 + +- 검색 기능을 개발합니다. +- 모든 피드에 대해 검색/팔로우한 사용자의 피드만 검색 옵션이 존재합니다. +- 해당 검색 결과 또한 페이징을 사용하도록 해 주세요. +- 혹시 로그를 사용하고 계신가요? **다른 로그의 로그 수준을 조정하고, 검색 API가 호출될 때 마다 특정 레벨의 로그가 출력되도록 해 주세요.** (다른 로그보다 로그 수준이 높아야 합니다.) + +#### 프로그래밍 요구사항 + +- 일반적으로, 검색은 DB 인덱스로 해결하기 어렵습니다. + - MySQL은 Full Text Index, MongoDB는 MongoDB Atlas에서 제공하는 Text Search 등을 활용할 수 있으나, 데이터의 양이 많을 경우 해당 방식 보다는 별도의 검색 서버를 구축하는 것이 권장됩니다. + - 상술한 인덱스를 적용해 보셔도 좋고, 그렇지 않다면 해당 기능에 한 해 인덱스를 붙이지 않고 만들어 보셔도 좋습니다. +- Spring 을 사용하는 경우, Log Level는 TRACE - DEBUG - INFO - WARN - ERROR 로 구성되어 있습니다. + - 다른 로그의 레벨을 DEBUG 이하로 낮춰주시고, 검색 API 호출만 INFO로 맞춰주세요. + - 왜 그러냐고요? 이후에 알게 됩니다! + +### Step 5. 인기 해시태그 기능 개발 + +#### 구현사항 + +- 이번에는, 실시간으로 호출되지 않는 기능을 개발할 겁니다. + - 간단하게 말해서, 사용자가 직접 호출하지 않고, 내부적으로 동작하는 기능이라고 생각하면 됩니다. +- 10분에 한 번, 인기 해시태그 목록을 갱신합니다. + - 최근 1시간 동안 작성된 피드에 대해, 피드에 포함된 해시태그 (ex. `#안녕`) 을 가져와, 가장 많이 등장한 해시태그 상위 5개를 저장합니다. +- 사용자가 인기 해시태그 조회를 요청한 경우, 기록한 상위 5개의 해시태그 목록을 반환하도록 해 주세요. + +#### 프로그래밍 요구사항 + +- 인기검색어는 우리가 생각하는 것 처럼 실시간이 아닙니다. 위와 유사한 방식으로 주기적으로 갱신한다고 보시면 좋아요. + - 왜냐고요? 실시간인 경우, 소수의 어뷰저에 의해 검색어가 실시간으로 바뀔 수 있거든요! + - 사용되는 자원도 상당히 부담되고요... + +### Step 6. 통계성 어드민 기능 개발 + +#### 구현사항 + +- 일반적으로, 사용자의 정보, 전체적인 서비스와 활성화도를 파악하기 위해 통계성 집계를 주기적으로 진행합니다. +- 일일 피드 작성 양, 누적 피드 작성 양을 매일 계산해서 별도의 테이블에 저장하도록 해 주세요. + - 어드민 API 호출 시, 최근 일주일간의 데이터를 조회해서 반환합니다. +- 일일 주요 검색어 키워드를 상위 10개 추출해 주세요. + - 어드민 API 호출 시, 최근 일주일간의 데이터를 조회해서 반환합니다. + +#### 프로그래밍 요구사항 + +- 피드 통계는 크게 문제가 없을 것 같은데, 검색어는 어떻게 구할 수 있을까요? + - 힌트는, Step 4에서 우리가 로그를 조정한 것과 연관이 있습니다. + - 로그의 활용도를 알 수 있는 use-case 라고 보시면 좋을 것 같아요. + +### Step 7. 성능 테스트 + +#### 구현사항 + +- 실제로 개발한 서버의 성능이 어떨까요? +- 사용자의 사용 시나리오를 설계하고, 이를 활용해 스트레스 테스트 툴을 사용한 성능 테스트를 진행해봅시다. + - 여기서는 nGrinder를 사용해 봅시다. diff --git a/readme.md b/readme.md index 0741cc05e..09e4a5d23 100644 --- a/readme.md +++ b/readme.md @@ -3,12 +3,15 @@ - 취뽀컴트루 & 취준마라톤 과제 레포 - 각 프로젝트 설명은 assignment 폴더를 참고 바랍니다. -| 과제 이름 | 한 줄 설명 | 링크 | -| -- | -- | -- | -| My-Storage | 간단한 형태의 클라우드 스토리지를 만들어 봅시다. | [링크](assignments/my-storage.md) | -| Mini-Pay | 기본 송금과 정산 기능이 있는 페이 서비스를 만들어 봅시다. | [링크](assignments/mini-pay.md) | -| Accelerated To-Do | iCal 형식에 맞춘 일정을 제공하는 To-Do 서버를 개발해 봅시다. | [링크](assignments/accelerated-to-do.md) | -| Opener-Market | 구매자와 판매자 기능이 있는 오픈마켓 서비스를 개발해 봅시다. | [링크](assignments/opener-market.md) | +| 과제 이름 | 한 줄 설명 | 예상 난이도 (1 - 5) | 링크 | +| -- | -- | -- | -- | +| My-Storage | 간단한 형태의 클라우드 스토리지를 만들어 봅시다. | 4 ~ 5 | [링크](assignments/my-storage.md) | +| Mini-Pay | 기본 송금과 정산 기능이 있는 페이 서비스를 만들어 봅시다. | 4 | [링크](assignments/mini-pay.md) | +| Accelerated To-Do | iCal 형식에 맞춘 일정을 제공하는 To-Do 서버를 개발해 봅시다. | 4 ~ 5 | [링크](assignments/accelerated-to-do.md) | +| Opener-Market | 구매자와 판매자 기능이 있는 오픈마켓 서비스를 개발해 봅시다. | 3 ~ 4 | [링크](assignments/opener-market.md) | +| Popping-Community | 일반적인 커뮤니티를 개발해 봅시다. 단, 사용자가 엄청나게 많을 겁니다. | 3 ~ 4 | [링크](assignments/popping-community.md) | +| Algorithm-Market | 알고리즘 연습 사이트 (ex. 릿코드, 백준, 프로그래머스) 를 개발해 봅시다. | 4 | [링크](assignments/algorithm-market.md) | +| Very-Simple-SNS | 간단한 형태의 SNS를 개발해 봅시다.
어느정도 규모 있는 서버 개발을 해 본적이 없는 분들에게 추천드립니다. | 2 | [링크](assignments/very-simple-sns.md) | ## Branch Guide