docs: 과제 추가

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를 사용해 봅시다.

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를 사용해 봅시다.
+- 특히, 해당 과제는 실제 데이터를 적재하고 테스트할 필요가 있습니다.