🚀 토스, 포항공대 출신 | 현업 백엔드 개발자(+9년) 🎥2만 유튜버 | 개발 콘텐츠 제작 📚 인프런 강사 | 누적 수강생 18,000+ 👥 개발자 취업 커뮤니티 운영 중 (8,000+) 🧩 오픈소스 (Gradle, Spring AI 등) 다수 Contributor 📝38개 서류 합격 및 크몽 이력서 첨삭 100+회 이상 경험 (평점 5.0점)
이 챌린지는 강의·교재를 제공하지 않습니다. 이미 알고 있거나 스스로 학습한 내용을 실전 문제와 GitHub PR로 증명하는 실행 트랙입니다. 시작 전 준비 · 제출은 딩코가 만들어주는 개인 private 저장소에서 진행합니다. 강의와 같은 Java 17·Spring Boot·JPA·MySQL 기준 프로젝트가 들어 있고, 강의가 정답으로 제시하는 개선 산출물은 비워둔 상태로 제공합니다.
이미 익힌 개념을 코드·실험·설명으로 증명하는 6주 실행 트랙입니다.
WHAT YOU SHIP
완주하면 남는 것
저장소 안 근거와 한계가 연결된 방어 가능한 bullet 3~5개
강의 주차별 숙제 답안과 실행 계획·부하·동시성·캐시 측정 기록
확인 불가 주장과 꼬리질문까지 연결된 면접 답변 패키지
BEFORE
“성능을 개선했습니다”처럼 검증하기 어려운 문장을 먼저 만듭니다.
AFTER
강의 숙제를 그대로 수행해 실행 계획, 전후 수치, 회귀 테스트를 남긴 뒤 이력서 bullet로 압축합니다.
RESUME PROOF CHAIN
좋은 문장을 쓰는 대신, 증거 사슬을 먼저 만듭니다
경험을 그럴듯하게 포장하는 첨삭이 아닙니다. 실제 프로젝트의 문제를 다시 재현하고, 선택과 결과를 검증한 뒤 이력서와 면접 언어로 압축합니다.
01문제 정의무엇이 왜 문제였는가
02재현 실험같은 조건에서 다시 실행
03전후 수치로그·쿼리·부하 결과
04선택 근거대안과 트레이드오프
05이력서 한 줄행동과 임팩트로 압축
06면접 답변꼬리질문까지 연결
이력서 원문은 공개하지 않습니다. 크루 공개 전에는 본인과 운영자만 접근하고, 공개 뒤에는 같은 크루에만 읽기 권한을 엽니다. Discord에는 개인 리뷰 없이 비식별 주간 요약과 운영 공지만 공유합니다.
ACTUAL WORKFLOW
신청부터 리뷰까지, 실제 화면 순서대로
GitHub 주소를 복사해 제출하지 않습니다. 딩코 홈페이지가 개인 저장소 준비, 미션 브랜치와 PR 생성, 상세 리뷰 확인까지 이어줍니다.
1GitHub 먼저, Discord는 마지막카카오 로그인과 사전 진단을 마치면 개인 private 저장소를 준비하고, Discord 역할과 기수 채널은 마지막에 연결합니다.2내 private 저장소에서 미션 수행홈페이지가 ‘기준 프로젝트에서 문제 상황을 만들고 수치화 패턴으로 쓰기’ 브랜치와 PR 생성을 이어줍니다. PR 주소를 복사해 붙여넣지 않습니다.388점과 구체적인 근거 확인자동 검사와 AI 리뷰의 잘한 점·개선 포인트를 딩코 상세 리뷰와 GitHub PR 댓글에서 확인하고 같은 PR을 수정합니다.4백엔드 이력서 챌린지 1기 운영 채널개인별 상세 리뷰는 Discord에 올리지 않고, 주간 요약과 운영 공지만 공유합니다.
위 화면은 실제 운영 UI와 저장소·채널 규칙을 바탕으로 만든 예시입니다. 저장소명, 기수 번호와 리뷰 점수는 참가자와 기수에 따라 달라집니다.
6-WEEK ROUTE
이미 아는 내용을 실제 결과물로 바꾸는 주차별 미션
매주 구현·실험, 테스트·로그, 선택 근거와 질문 답변을 하나의 PR에 제출합니다. 질문은 외운 답을 따로 내는 숙제가 아니라 방금 만든 코드와 증거로 답합니다.
W1
기능을 문제 해결 경험으로 바꾸기
강의 1주차를 따라 기준 프로젝트에서 문제 상황을 만들고 수치화 패턴으로 문장을 씁니다.
주간 통합 PR기준 프로젝트에서 문제 상황을 만들고 수치화 패턴으로 쓰기
[필수] 기준 프로젝트를 docker compose로 띄우고 GET /api/studies 목록 조회처럼 자주 불리는 기능 1개를 골라 정상 동작을 확인합니다. 강의 1주차의 "문제를 만들어야 합니다"를 따라 그 기능에서 사용자가 늘면 무엇이 먼저 깨질지 예측합니다.
[필수] 고른 기능의 현재 응답 시간을 같은 입력으로 3회 이상 측정해 resume/resume.md의 근거 범위에 기록합니다. 강의 1주차 "성능이란 & 성능측정"의 정의를 그대로 씁니다.
[필수] 강의 1주차 "수치화 패턴"에 맞춰 이력서 문장 1개를 작성하고, 그 문장의 각 수치가 어디서 나왔는지 저장소 안 경로로 연결합니다. 아직 측정하지 못한 값은 확인 불가로 표시합니다.
[필수] src/test/ 아래에 그 기능의 회귀 테스트 1개를 추가해 이후 주차의 개선이 기능을 깨지 않는지 확인할 수 있게 만듭니다.
[선택 확장] 문제 상황 후보를 3개까지 늘려 우선순위와 근거를 함께 적습니다.
제출 증거 · 고른 API 경로와 docker compose 실행·응답 확인 기록 · 같은 입력 3회 이상 측정한 응답 시간과 측정 조건 · resume/resume.md의 수치화 패턴 문장 1개와 각 수치의 저장소 안 근거 · src/test/ 회귀 테스트 1개와 통과 출력 · 질문 1~4 답변
함께 답할 근거형 질문 4개
이 기능에서 사용자가 늘면 가장 먼저 무엇이 병목이 될 것 같고, 그 근거는 무엇인가요?
측정한 응답 시간이 실제 사용 패턴을 얼마나 대표하며 어떤 한계가 있나요?
작성한 이력서 문장에서 팀의 성과와 본인의 기여를 어떤 증거로 구분할 수 있나요?
현재 문장에서 아직 검증할 수 없는 주장과 이를 보완할 계획은 무엇인가요?
W2
관측 가능한 성능 개선
강의 2주차를 따라 Prometheus·Grafana와 k6로 병목을 재현하고 전후 수치를 남깁니다.
주간 통합 PR모니터링 붙이고 k6로 TPS 측정하기
[필수] 기준 프로젝트의 docker compose로 Prometheus와 Grafana를 함께 띄우고, 강의 2주차 "각 컨테이너의 역할"대로 CPU·메모리 지표가 수집되는 것을 확인합니다.
[필수] k6-scripts/ 아래 부하 스크립트로 1주차에 고른 API의 기준선 TPS와 응답 시간 분포를 측정합니다. 강의 2주차 "TPS 가 뭘까?"의 정의를 그대로 씁니다.
[필수] 부하 중 어느 자원이 먼저 한계에 닿는지 지표로 확인하고, 병목이라고 판단한 근거를 resume/resume.md에 기록합니다.
[필수] 강의 2주차 "그렇다면 어떻게 성능 개선하는건데"의 인프라·애플리케이션 개선 방법 중 하나를 적용해 같은 스크립트로 재측정합니다. src/main/과 src/test/를 함께 변경합니다.
[선택 확장] JMH로 애플리케이션 코드 구간을 벤치마킹해 수치를 보강합니다.
제출 증거 · Prometheus·Grafana에서 수집된 CPU·메모리 지표 · k6 실행 명령과 기준선 TPS·응답 시간 분포 · 개선 적용 후 같은 스크립트 재측정 결과와 전후 비교 · resume/resume.md의 병목 판단 근거와 이력서 문장 · 질문 1~3 답변
함께 답할 근거형 질문 3개
현재 프로젝트에 사용자가 400명 이상으로 증가하면 어떤 문제가 발생할까요?
현재 제공하던 기능에서 추가로 제공될만한 기능이 있다면 뭐가 있을까요? 해당 기능을 제공하려면 어떤 변화가 필요할까요?
현재 프로젝트에 예상보다 많은 사용자가 유입된다면 저희는 어떤걸 공부해야 할까요?
W3
인덱스와 쿼리 플랜
강의 3주차를 따라 신청 검색 API의 실행 계획을 근거로 인덱스를 설계하고 비용을 설명합니다.
주간 통합 PR신청 검색 API를 실행 계획으로 개선하기
[필수] 앱을 처음 띄우면 app.seed.* 설정대로 신청 데이터가 채워집니다. GET /api/enrollments/search?from=&to=&status=&minFee= 를 호출해 느린 상태를 재현하고, 시드 규모와 본인 환경 수치를 함께 적습니다.
[필수] EXPLAIN으로 실행 계획을 뜨고 강의 3주차 "쿼리플랜 타입별 분석"에 따라 어디서 비용이 나는지 지목합니다.
[필수] 복합 인덱스를 직접 설계해 src/main/resources/ 아래 DDL로 추가하고, 같은 쿼리의 실행 계획과 실행 시간을 전후 비교합니다. 강의가 정답으로 제시한 인덱스를 그대로 베끼지 말고 본인 쿼리 패턴에서 컬럼 순서를 결정한 근거를 남깁니다.
[필수] GET /api/enrollments/stats의 회원별 집계도 같은 방식으로 측정하고, 인덱스만으로 한계가 있다면 집계 테이블이나 반정규화 중 하나를 선택해 적용합니다.
[필수] src/test/ 아래에 개선한 조회의 회귀 테스트를 추가해 결과가 이전과 같은지 확인합니다.
[선택 확장] 인덱스 추가 후 INSERT·UPDATE 성능을 별도로 측정해 트레이드오프를 수치로 남깁니다.
제출 증거 · 시드 규모(app.seed.enrollments)와 개선 전 search·stats 실행 시간 · 개선 전후 EXPLAIN 실행 계획 출력 · 추가한 인덱스 DDL과 컬럼 순서 결정 근거 · src/test/ 회귀 테스트와 통과 출력 · resume/resume.md에 반영한 이력서 문장 · 질문 1~4 답변
함께 답할 근거형 질문 4개
현재 쿼리에서 병목(성능 저하) 가능성이 있을 만한 부분은 어디라고 생각하나요?
인덱스(또는 복합 인덱스)를 새로 추가한다면, 어떤 컬럼(들)에 추가하고 싶나요?
인덱스를 적용하거나 쿼리를 튜닝한 뒤, 성능을 어떻게 측정·검증할 계획인가요?
만약 인덱스 적용 후 데이터 삽입·수정 시 성능 저하가 생긴다면, 어떻게 대처할 수 있을까요?
W4
트랜잭션과 동시성
강의 4주차를 따라 스터디 신청에서 정원 경합을 재현하고 락 전략을 선택합니다.
주간 통합 PR스터디 신청에서 정원 경합을 재현하고 락으로 막기
[필수] POST /api/enrollments/studies/{studyId} 에 멀티스레드 테스트를 붙여 정원이 초과되는 상태를 실제로 재현합니다. 강의 4주차 "멀티스레드 테스트로 확인"처럼 단일 스레드에서는 통과하고 동시 요청에서는 깨지는 것을 둘 다 보여줍니다.
[필수] 격리 수준만으로는 막히지 않는다는 것을 확인하고, 강의 4주차 "락을 거는 방식"에서 낙관적 락과 비관적 락 중 하나를 선택해 src/main/에 구현합니다. 선택 근거를 정합성·성공 수·재시도 수로 설명합니다.
[필수] 같은 멀티스레드 테스트로 개선 후 불변식이 지켜지는 것을 확인하고 전후 결과를 함께 남깁니다.
[필수] 트랜잭션 안에서 제거할 수 있는 작업(예: 외부 호출)이 있는지 점검하고, 강의 4주차 "개선 : 트랜잭션 범위 줄이기"를 참고해 범위를 조정합니다.
[선택 확장] 두 번째 전략(네임드 락 등)을 같은 조건에서 비교하거나 데드락을 의도적으로 재현해 해결합니다.
제출 증거 · 단일 스레드 통과·동시 요청 실패를 모두 보여주는 테스트 출력 · 선택한 락 전략의 구현 코드와 선택 근거 · 개선 후 같은 테스트에서 불변식이 지켜진 출력 · 트랜잭션 범위 조정 내용과 근거 · resume/resume.md에 반영한 이력서 문장 · 질문 1~4 답변
함께 답할 근거형 질문 4개
현재 프로젝트에서 동시성 문제가 발생할 가능성이 있는 시나리오는 무엇인가요?
동시성 제어(트랜잭션 Isolation, Lock, Optimistic Lock 등)를 적용한다면, 어떤 방법을 고려해볼 수 있을까요?
트랜잭션 범위를 어떻게 설정하고, 트랜잭션 내에서 불필요한 작업(예: 외부 API 호출)을 제거할 수 있을까요?
동시성 이슈를 테스트하거나, 개선 전후를 어떻게 측정·검증할 계획인가요?
W5
JPA·컬렉션·비동기 성능
강의 5주차를 따라 실행 쿼리 수를 세고 N+1·벌크·비동기 중 실제 병목을 개선합니다.
주간 통합 PR댓글 목록의 쿼리 수를 세고 N+1·벌크·비동기 중 하나를 개선하기
[필수] 강의 5주차 "API 별 실행 쿼리 모니터링 구현"을 따라 실행 쿼리 수를 세는 장치를 붙이고, GET /api/studies/{id}/comments 의 현재 쿼리 수를 기록합니다.
[필수] N+1, 벌크 연산, Stream 필터 오버헤드, 비동기 처리 중 **하나**를 골라 그 지점이 실제 병목이라는 근거를 쿼리 수 또는 응답 시간으로 먼저 남깁니다. 댓글 목록은 작성자를 지연 로딩하므로 N+1을 고르면 여기서 시작합니다.
[필수] 고른 항목을 src/main/에서 개선합니다. N+1이라면 BatchSize·fetch join·EntityGraph 중 선택한 이유를, 비동기라면 스레드 풀 설정 근거를 함께 적습니다.
[필수] 개선 후 쿼리 수와 응답 시간을 같은 조건으로 재측정하고, src/test/ 회귀 테스트로 결과가 동일한지 확인합니다.
[선택 확장] 두 번째 항목까지 개선하거나 Grafana 대시보드로 지표를 시각화합니다.
제출 증거 · 쿼리 수 모니터링 장치와 개선 전 쿼리 수·응답 시간 · 고른 항목이 병목이라는 근거 · 개선 코드와 선택한 기법의 근거 · 개선 후 같은 조건 재측정 결과와 src/test/ 회귀 테스트 통과 출력 · resume/resume.md에 반영한 이력서 문장 · 질문 1~4 답변
함께 답할 근거형 질문 4개
N+1 / 벌크 연산 / 스트림 FilterOverhead / 비동기 처리 중, 어떤 항목을 적용했고 왜 그 부분을 선택했나요?
구체적으로 어떤 방식으로 개선(또는 적용)했나요?
모니터링(또는 로그) 결과, 개선 전후 무엇이 얼마나 좋아졌나요?
개선 과정에서 겪은 문제나 고려해야 할 사항은 무엇이었나요?
W6
캐싱과 최종 이력서 스토리
강의 6주차를 따라 Redis 캐싱과 실패 모드를 검증하고 6주 증거를 이력서로 압축합니다.
주간 통합 PRRedis 캐싱을 적용하고 6주 증거를 이력서로 압축하기
[필수] docker compose의 Redis에 연결하고, 강의 6주차 "어떤 데이터를 캐싱해야할까?"를 기준으로 캐싱 대상을 하나 선정해 RedisTemplate 또는 @Cacheable로 적용합니다. GET /api/studies/popular 는 호출마다 다시 계산하므로 후보입니다.
[필수] 캐시 적용 전후의 응답 시간과 DB 조회 수를 같은 조건에서 비교하고, 캐시 히트·미스가 실제로 관측되는 것을 확인합니다.
[필수] TTL과 무효화 전략을 정한 근거를 적고, 캐시된 데이터가 변경될 때 정합성을 어떻게 보장하는지 코드로 남깁니다.
[필수] 강의 6주차 "대표 문제 사례" 중 cache penetration, avalanche, Hot Key 하나를 골라 방지 장치를 적용하고 동작을 확인합니다.
[필수] 6주간 남긴 측정 근거에서 방어 가능한 이력서 bullet 3~5개만 resume/resume.md에 남기고, 제외한 주장과 그 이유를 함께 적습니다.
제출 증거 · 캐싱 대상 선정 근거와 적용 코드 · 캐시 전후 응답 시간·DB 조회 수 비교와 히트·미스 관측 기록 · TTL·무효화 전략과 정합성 보장 코드 · 선택한 캐시 문제 사례의 방지 장치와 동작 확인 · 증거가 연결된 이력서 bullet 3~5개와 제외한 주장 · 질문 1~5 답변
함께 답할 근거형 질문 5개
캐싱 대상 데이터를 어떻게 선정했나요?
TTL(만료 시간) / 무효화 전략은 어떻게 설정했나요?
캐싱 적용 전후의 성능(응답 시간, DB 부하 등)은 어떻게 달라졌나요?
Cache avalanche나 Hot Key 문제를 어떻게 방지할 수 있을까요?
캐시에 저장된 데이터가 변경되어도 문제가 없는지(정합성)는 어떻게 보장할까요?
WEEKLY LOOP
한 주의 실전을 한 PR 안에서 끝냅니다
주차별 실전 문제 확인
개인 브랜치에서 미션 수행
코드·테스트·설명을 PR 제출
자동 검사와 AI 리뷰 확인
같은 PR을 수정하고 자동 병합
통과 PR과 공식 해설 확인
누적 동료 리뷰와 크루 학습 기록 반영
제출은 GitHub PR만 사용합니다. 제출 diff와 evidence는 GitHub 조직 운영자와 자동 리뷰 처리자(현재 Anthropic API)가 검토합니다. 개인정보와 회사 기밀은 제출 전에 제거해야 합니다. 필요한 증거가 PR 안에 있는지 자동으로 확인합니다.
CREW ENGAGEMENT
미션 한마디로 20분만 이야기합니다
2주차부터 PR에 한마디를 남기고, 크루는 막힌 점과 다른 접근만 나눕니다.
2주차부터 미션 한마디 PR 제출 때 막힌 점을 10~300자로 남깁니다.
팀이 정한 시간에 20분 화요일 21:15을 기본으로 막힌 점과 다른 접근만 나눕니다.
리더가 1~30자로 마무리 2주차부터 완료 크루 +5, 개인 완주와는 별도입니다.
팀 보너스 활동 참여자는 미션 한마디 외에 별도 글을 쓰지 않습니다. 크루 +5는 개인 완주와 별도입니다.
LIVE SESSION
라이브로 한 번, 진행 방식을 함께 맞춥니다
챌린지 기간 중 라이브 세션을 한 번 진행합니다. 완주 기준을 함께 맞추고, 제출이 화면에서 어떻게 흘러가는지 그 자리에서 확인합니다.
KICKOFF LIVE8/24(월) 20:00
60분 · 온라인
백엔드 이력서 챌린지 킥오프 라이브
6주 진행 방식과 완주 기준 안내
월요일 킥오프에서 첫 미션 브랜치 준비와 수요일 시작 뒤 GitHub PR 제출 데모
실시간 Q&A
참여 링크는 시작 전 Discord 공지에 올립니다. 라이브에 참여하지 못해도 완주 기준과 제출 방법은 딩코 홈페이지와 Discord 공지에서 그대로 확인할 수 있습니다.
CHALLENGE CONTRACT
개념 학습은 각자, 실전과 피드백은 함께
이 챌린지는 강의·교재·Notion·보너스 자료를 제공하지 않습니다. 이미 알고 있거나 스스로 학습한 내용을 실제 문제에 적용하고 GitHub PR로 증명합니다.
챌린지가 제공합니다
주차별 실전 문제 · 개인 private 실습 저장소 · 명확한 통과 기준 · 자동 검사와 AI 리뷰 · 동료 비교와 완주 기록
참가자가 준비합니다
해당 분야의 기본 개념 · Git과 GitHub PR 경험 · 매주 실행할 시간 · 부족한 개념을 스스로 보완하는 태도
선택형 사전학습 · 별도 구매 · 22시간 28분
6주 완성! 백엔드 이력서 차별화 전략 4가지
이 강의와 교재는 챌린지에 포함되지 않으며 수강도 필수가 아닙니다. 사전 진단에서 부족한 영역이 있거나 개념 보완이 필요할 때만 선택하세요.
인프런 신청 여부와 별개로, 위의 ‘모집·참여 확인’ 버튼에서 현재 기수의 모집 상태를 확인합니다. 딩코에서 카카오 로그인하면 자리가 확보되고, 모든 연결을 마치면 참여 준비가 완료됩니다.
딩코 모집·참여 확인 페이지에서 현재 기수를 선택하고, 카카오 로그인하면 챌린지 멤버십이 즉시 생성되어 자리가 확보됩니다.
기수별 사전 진단을 통과하면 GitHub 연결 단계가 열립니다.
GitHub를 먼저 연결하면 공개 전에는 본인·운영자만 접근하고, 크루 공개 뒤에는 같은 크루만 읽는 이력서 전용 private 저장소 준비가 예약됩니다.
Discord를 연결하면 백엔드 이력서 챌린지 1기 카테고리와 공지·읽을거리·질문·자유 채널 권한이 설정됩니다.
홈페이지에서 submit/<미션> 브랜치를 만들고 실험 증거·이력서 초안을 push한 뒤 버튼 한 번으로 PR을 제출합니다.
상세 자동 리뷰는 딩코와 private GitHub에 남고, Discord에는 개인 리뷰 대신 비식별 주간 요약과 운영 공지만 안내합니다. 크루 Discord에서는 질문과 진행 상황을 함께 나누고, 공식 리뷰는 같은 크루 통과 PR을 우선으로 열되 없으면 같은 기수 다른 크루 PR로 이어집니다. 점수판은 주간에는 잠정 반영되고 마지막 누적 리뷰 마감 뒤 최종 확정됩니다.
공개 후 같은 크루만 읽기 이력서 저장소는 private으로 유지되며 결과가 공개된 뒤 같은 크루만 읽기 전용으로 확인할 수 있습니다. 제출 전 연락처·회사명·고객명 같은 민감 정보는 가리고, 원문 이력서와 private 리뷰는 Discord에 올리지 않습니다. 세부 점수표는 공개하지 않으며, 최종 점수 확정 뒤 동의한 우승 크루만 Hall of Fame·GitHub 배지·공개 이름으로 소개합니다. 참가 등록은 시작 주 수요일 19:00에 마감합니다. 사전 진단이 있는 트랙은 같은 시각까지 통과해야 하며, 크루 명단과 전용 Discord 채널은 20:00에 공개됩니다. 공식 시작과 1주차 미션 공개는 같은 날 21:00이며, 그 뒤로는 매주 수요일 21:00에 새 미션이 열리고 다음 화요일 21:00에 제출이 마감됩니다. 공식 리뷰는 매주 즉시 하지 않아도 되지만, 서로 다른 주차 기준으로 필요한 리뷰 수를 마지막 주차 뒤 일요일 21:00 전까지 채워야 합니다. 1주차 문제·개인 저장소·미션 브랜치는 미리 준비할 수 있고, PR 제출 버튼은 내 크루 채널 준비가 끝난 뒤 자동으로 활성화됩니다. GitHub·Discord 연결이 덜 끝난 참가자는 배정된 크루를 유지합니다.
FIT CHECK
이런 분께 맞고, 이런 분께는 맞지 않습니다
추천합니다
강의를 들었지만 직접 측정해본 적은 없어 이력서에 쓸 근거가 없는 분
프로젝트는 있지만 이력서에 CRUD 기능 나열만 남는 분
성능 개선을 했다고 쓰고도 재현 조건과 수치를 설명하기 어려운 분
추천하지 않습니다
운영 서버나 제3자 서비스에 부하·장애 실험을 실행하려는 분
회사 코드, 실제 사용자 데이터나 개인정보를 저장소에 올리려는 분
자동 생성 문장을 그대로 제출하고 싶은 분
COMPLETION
완주 기준을 시작 전에 공개합니다
6주 동안 주차별 통합 미션 PR 6개를 모두 제출합니다.
서로 다른 5개 주차의 통과 PR에 공식 리뷰를 제출합니다.
시작 전 준비
제출은 딩코가 만들어주는 개인 private 저장소에서 진행합니다. 강의와 같은 Java 17·Spring Boot·JPA·MySQL 기준 프로젝트가 들어 있고, 강의가 정답으로 제시하는 개선 산출물은 비워둔 상태로 제공합니다.
언어와 프레임워크는 강의 기준으로 고정입니다. 다른 스택으로 제출할 수 없습니다.
매주 약 6~10시간 동안 강의 해당 주차를 따라 측정하고 문장을 다듬어야 합니다.
FAQ
참여 전에 가장 많이 묻는 것
기존 10주 부트캠프와 같은 과정인가요?
아닙니다. 이 챌린지는 6주 동안 한 과목을 완주하는 별도 트랙입니다. 더 긴 프로젝트·취업 집중 과정이 필요한 경우에만 10주 부트캠프로 이어집니다.
강의나 교재도 함께 제공되나요?
아닙니다. 챌린지는 주차별 문제, private 실습 저장소, 제출 기준과 리뷰 루프를 제공합니다. 연결 강의는 별도 구매 가능한 선택형 사전학습이며 수강은 필수가 아닙니다.
홈페이지 제출이나 링크 붙여넣기도 가능한가요?
제출 결과는 GitHub PR로만 받습니다. 다만 저장소·브랜치·PR 준비와 리뷰 확인은 딩코 홈페이지 버튼으로 쉽게 이어집니다.
Discord에는 무엇이 공개되나요?
Discord에는 개인별 상세 리뷰를 올리지 않고, 주간 요약과 운영 공지만 공유합니다. 백엔드 이력서 챌린지 1기 공용 채널은 읽을거리, 질문, 자유 대화와 운영 안내를 위한 공간입니다.