🚀 토스, 포항공대 출신 | 현업 백엔드 개발자(+9년) 🎥2만 유튜버 | 개발 콘텐츠 제작 📚 인프런 강사 | 누적 수강생 18,000+ 👥 개발자 취업 커뮤니티 운영 중 (8,000+) 🧩 오픈소스 (Gradle, Spring AI 등) 다수 Contributor 📝38개 서류 합격 및 크몽 이력서 첨삭 100+회 이상 경험 (평점 5.0점)
이 챌린지는 강의·교재를 제공하지 않습니다. 이미 알고 있거나 스스로 학습한 내용을 실전 문제와 GitHub PR로 증명하는 실행 트랙입니다. 시작 전 준비 · Java 기본 문법과 Git 브랜치·커밋의 기초가 필요합니다.
이미 익힌 개념을 코드·실험·설명으로 증명하는 4주 실행 트랙입니다.
WHAT YOU SHIP
완주하면 남는 것
운영 가능한 User–Todo API와 통합 테스트
빈·프록시·트랜잭션 동작을 보여주는 검증 코드와 로그
실제 코드 증거가 연결된 Spring 면접 답변 18개
BEFORE
애노테이션을 붙이고 응답이 오면 구현을 끝냅니다.
AFTER
요청 흐름과 프록시, 빈, 트랜잭션 경계를 테스트와 로그로 재현하고 선택 근거를 설명합니다.
ACTUAL WORKFLOW
신청부터 리뷰까지, 실제 화면 순서대로
GitHub 주소를 복사해 제출하지 않습니다. 딩코 홈페이지가 개인 저장소 준비, 미션 브랜치와 PR 생성, 상세 리뷰 확인까지 이어줍니다.
1GitHub 먼저, Discord는 마지막카카오 로그인과 사전 진단을 마치면 개인 private 저장소를 준비하고, Discord 역할과 기수 채널은 마지막에 연결합니다.2내 private 저장소에서 미션 수행홈페이지가 ‘요청 흐름이 보이는 Todo API와 근거형 답변’ 브랜치와 PR 생성을 이어줍니다. PR 주소를 복사해 붙여넣지 않습니다.392점과 구체적인 근거 확인자동 검사와 AI 리뷰의 잘한 점·개선 포인트를 딩코 상세 리뷰와 GitHub PR 댓글에서 확인하고 같은 PR을 수정합니다.4Spring 챌린지 1기 운영 채널개인별 상세 리뷰는 Discord에 올리지 않고, 주간 요약과 운영 공지만 공유합니다.
위 화면은 실제 운영 UI와 저장소·채널 규칙을 바탕으로 만든 예시입니다. 저장소명, 기수 번호와 리뷰 점수는 참가자와 기수에 따라 달라집니다.
4-WEEK ROUTE
이미 아는 내용을 실제 결과물로 바꾸는 주차별 미션
매주 구현·실험, 테스트·로그, 선택 근거와 질문 답변을 하나의 PR에 제출합니다. 질문은 외운 답을 따로 내는 숙제가 아니라 방금 만든 코드와 증거로 답합니다.
W1
웹 요청에서 첫 API까지
HTTP와 JSON을 관찰하고 직접 실행되는 Spring Boot API로 연결합니다.
주간 통합 PR요청 흐름이 보이는 Todo API와 근거형 답변
[필수] POST /todos는 정상 입력에 201과 생성된 id·title·completed를, 잘못된 입력에 400 공통 오류를 반환하도록 계약을 정의하고 구현합니다.
[필수] GET /todos/{id}는 존재하는 Todo에 200을, 존재하지 않는 id에 404 공통 오류를 반환하게 하고 세 경계를 실제 애플리케이션 컨텍스트의 통합 테스트로 고정합니다.
[필수] 요청이 컨트롤러 인자가 되고 JSON 응답이 되기까지 DispatcherServlet, 검증, HttpMessageConverter의 역할을 본인 코드와 테스트에 연결해 설명합니다.
[선택 확장] 메모리 저장소를 H2·JdbcTemplate 저장소로 교체하고 같은 API 계약 테스트가 유지되는지 확인합니다.
제출 증거 · 201·400·404 계약을 구현한 실행 가능한 API 코드 · 실제 애플리케이션 컨텍스트에서 실행한 성공·검증 실패·404 통합 테스트 결과 · 본인 파일과 테스트를 인용한 요청 흐름 설명 · 이번 주 근거형 질문 1~5 답변 · 리뷰 지적이 있으면 반영한 커밋·검증 결과, 없으면 지적 없음 기록
함께 답할 근거형 질문 5개
HTTP 요청은 어떤 과정을 거쳐 컨트롤러 메서드의 인자가 되나요?
자바 객체는 누가 JSON 응답으로 변환하며, 그 사실을 어떻게 확인했나요?
입력 검증 실패를 컨트롤러 코드에서 직접 분기하지 않은 이유는 무엇인가요?
단위 테스트가 아니라 통합 테스트로 반드시 확인해야 한 경계는 무엇이었나요?
현재 API 계약에서 가장 먼저 깨질 가능성이 높은 부분과 그 검증 방법은 무엇인가요?
W2
프록시·빈·DI로 보는 스프링 컨테이너
스프링의 자동화를 프록시, 빈 생명주기와 의존성 주입 코드로 검증합니다.
주간 통합 PR스프링 컨테이너 자동화 해부와 근거형 답변
[필수] Todo 유스케이스에서 같은 인터페이스의 두 구현체를 만들고 @Qualifier 또는 @Primary로 선택 기준을 명시하며, 선택 전 모호성 실패와 선택 후 주입 성공을 격리된 컨텍스트 테스트로 비교합니다.
[필수] 생성자 주입으로 연결한 빈과 직접 new한 객체 사이에서 의존성, 생명주기 또는 부가기능 중 하나가 실제로 달라지는 장면을 테스트로 보여줍니다.
[필수] Todo 서비스에 AOP 부가기능을 적용하고 AopUtils로 프록시 여부·대상 클래스를 확인하며, 프록시를 통한 호출에서만 advice와 대상 호출이 기대한 순서와 횟수로 기록되는지 검증합니다.
[선택 확장] 빈 생명주기 콜백이나 스코프 프록시를 추가해 컨테이너가 관리하는 경계를 한 가지 더 비교합니다.
제출 증거 · 모호성 실패와 명시적 빈 선택을 함께 보여주는 격리 컨텍스트 테스트 · 프록시 종류·대상 클래스와 advice·대상 호출 순서 및 횟수를 단언한 테스트 결과 · 직접 new한 객체와 컨테이너 빈의 관찰 가능한 차이를 연결한 문서 · 이번 주 근거형 질문 1~5 답변 · 리뷰 지적이 있으면 반영한 커밋·검증 결과, 없으면 지적 없음 기록
함께 답할 근거형 질문 5개
스프링이 주입할 구현체를 결정할 수 없을 때 어떤 일이 발생하며 어떻게 해결했나요?
생성자 주입이 필드 주입보다 테스트와 불변성에 유리한 이유는 무엇인가요?
컨테이너가 관리하는 객체와 직접 생성한 객체의 가장 중요한 차이는 무엇인가요?
프록시 객체인지 원본 객체인지 코드로 어떻게 확인할 수 있나요?
이번 실험의 호출 순서 로그가 없었다면 어떤 설명을 검증할 수 없었나요?
W3
계층 분리와 트랜잭션
서비스 계층의 책임과 트랜잭션 경계를 실패 시나리오로 검증합니다.
주간 통합 PR실패해도 일관성이 보존되는 서비스와 근거형 답변
[필수] H2·JdbcTemplate로 User와 Todo를 저장하는 리포지토리와 두 변경을 조율하는 서비스 유스케이스를 구현합니다.
[필수] 트랜잭션이 없는 서비스가 User 저장 직후 예외를 던지게 호출하고, 테스트 메서드에 @Transactional을 붙이지 않은 상태에서 예외 뒤 User 1건·Todo 0건이 남는 부분 저장을 확인합니다.
[필수] 외부에서 Spring 프록시를 거쳐 호출한 @Transactional 서비스가 같은 지점에서 실패하게 하고, 예외 처리 뒤 별도 조회로 User 0건·Todo 0건을 확인해 두 변경의 롤백을 증명합니다.
[선택 확장] 체크 예외의 기본 동작과 rollbackFor 적용 전후 또는 같은 클래스 내부 호출의 프록시 우회를 별도 테스트로 비교합니다.
제출 증거 · User·Todo JDBC 리포지토리와 서비스 계층 코드 · 테스트 트랜잭션 밖에서 확인한 비트랜잭션 User 1·Todo 0 대 트랜잭션 User 0·Todo 0 결과 · 외부 프록시 호출과 데이터베이스 상태 조회를 연결한 트랜잭션 경계 설명 · 이번 주 근거형 질문 1~4 답변 · 리뷰 지적이 있으면 반영한 커밋·검증 결과, 없으면 지적 없음 기록
함께 답할 근거형 질문 4개
트랜잭션 경계를 컨트롤러나 리포지토리가 아니라 서비스에 둔 이유는 무엇인가요?
체크 예외와 언체크 예외에서 기본 롤백 동작은 어떻게 다르며 어떻게 검증했나요?
같은 클래스 내부 호출이 트랜잭션 프록시를 우회할 수 있는 이유는 무엇인가요?
롤백 테스트가 데이터베이스 상태까지 확인해야 하는 이유는 무엇인가요?
W4
운영 가능한 API 완성
예외, 검증, 로깅과 페이징을 적용해 포트폴리오로 제시할 API를 완성합니다.
주간 통합 PR운영 가능한 User–Todo API와 최종 근거 패키지
[필수] POST /users, POST /users/{userId}/todos, GET /todos/{id}, GET /users/{userId}/todos를 하나의 User–Todo 계약으로 완성하고 1주차 POST /todos 계약을 유지하거나 변경한 이유를 기록합니다.
[필수] 모든 400·404 응답을 code·message·requestId 필드가 있는 공통 형식으로 만들고, 목록 조회는 page=0·size=20 기본값, 최대 size, id 오름차순, totalElements·hasNext 메타데이터를 포함하도록 구현합니다.
[필수] 빈 목록, 여러 페이지, 안정된 정렬, 잘못된 page·size, 검증 실패와 404를 통합 테스트로 고정합니다.
[필수] 외부 X-Request-Id를 검증해 재사용하거나 새 값을 만들고 응답 헤더·오류 응답·구조화 로그에 같은 값을 연결하되 요청 본문·인증 정보는 로그에서 제외합니다.
[선택 확장] 커서 페이징 비교 실험이나 요청 수·오류율·지연 시간 중 첫 관측 지표를 추가합니다.
제출 증거 · 명시된 네 User–Todo 엔드포인트와 이전 계약의 호환성 결정 · code·message·requestId 공통 오류와 안정된 id 오름차순 페이징 명세 · 경계값을 포함한 API·페이징 통합 테스트와 실행 결과 · 응답·오류·로그에서 같은 requestId를 확인한 관측 증거 · 이번 주 근거형 질문 1~4 답변 · 리뷰 지적이 있으면 반영한 커밋·검증 결과, 없으면 지적 없음 기록
함께 답할 근거형 질문 4개
오류 응답 형식을 공통화하면 클라이언트와 운영자에게 어떤 이점이 있나요?
페이지 번호 기반과 커서 기반 페이징 중 현재 API에 맞는 방식을 왜 선택했나요?
로그에 반드시 남겨야 할 정보와 남기면 안 되는 정보는 무엇인가요?
이 API를 실제 운영하기 전에 추가할 첫 번째 관측 지표와 장애 검증은 무엇인가요?
WEEKLY LOOP
한 주의 실전을 한 PR 안에서 끝냅니다
주차별 실전 문제 확인
개인 브랜치에서 미션 수행
코드·테스트·설명을 PR 제출
자동 검사와 AI 리뷰 확인
같은 PR을 수정하고 자동 병합
통과 PR과 공식 해설 확인
누적 동료 리뷰와 크루 학습 기록 반영
제출은 GitHub PR만 사용합니다. 브랜치 생성부터 리뷰, 정확한 head SHA 병합까지 챌린지 화면과 GitHub가 연결됩니다. 필요한 증거가 PR 안에 있는지 자동으로 확인합니다.
CREW ENGAGEMENT
미션 한마디로 20분만 이야기합니다
2주차부터 PR에 한마디를 남기고, 크루는 막힌 점과 다른 접근만 나눕니다.
2주차부터 미션 한마디 PR 제출 때 막힌 점을 10~300자로 남깁니다.
팀이 정한 시간에 20분 화요일 21:15을 기본으로 막힌 점과 다른 접근만 나눕니다.
리더가 1~30자로 마무리 2주차부터 완료 크루 +5, 개인 완주와는 별도입니다.
팀 보너스 활동 참여자는 미션 한마디 외에 별도 글을 쓰지 않습니다. 크루 +5는 개인 완주와 별도입니다.
LIVE SESSION
라이브로 한 번, 진행 방식을 함께 맞춥니다
챌린지 기간 중 라이브 세션을 한 번 진행합니다. 완주 기준을 함께 맞추고, 제출이 화면에서 어떻게 흘러가는지 그 자리에서 확인합니다.
KICKOFF LIVE8/10(월) 20:00
60분 · 온라인
Spring 챌린지 킥오프 라이브
4주 진행 방식과 완주 기준 안내
월요일 킥오프에서 첫 미션 브랜치 준비와 수요일 시작 뒤 GitHub PR 제출 데모
실시간 Q&A
참여 링크는 시작 전 Discord 공지에 올립니다. 라이브에 참여하지 못해도 완주 기준과 제출 방법은 딩코 홈페이지와 Discord 공지에서 그대로 확인할 수 있습니다.
CHALLENGE CONTRACT
개념 학습은 각자, 실전과 피드백은 함께
이 챌린지는 강의·교재·Notion·보너스 자료를 제공하지 않습니다. 이미 알고 있거나 스스로 학습한 내용을 실제 문제에 적용하고 GitHub PR로 증명합니다.
챌린지가 제공합니다
주차별 실전 문제 · 개인 private 실습 저장소 · 명확한 통과 기준 · 자동 검사와 AI 리뷰 · 동료 비교와 완주 기록
참가자가 준비합니다
해당 분야의 기본 개념 · Git과 GitHub PR 경험 · 매주 실행할 시간 · 부족한 개념을 스스로 보완하는 태도
선택형 사전학습 · 별도 구매 · 9시간 58분
[Lv1] 면접에서 "설명할 수 있는" Spring Boot
이 강의와 교재는 챌린지에 포함되지 않으며 수강도 필수가 아닙니다. 사전 진단에서 부족한 영역이 있거나 개념 보완이 필요할 때만 선택하세요.
인프런 신청 여부와 별개로, 위의 ‘모집·참여 확인’ 버튼에서 현재 기수의 모집 상태를 확인합니다. 딩코에서 카카오 로그인하면 자리가 확보되고, 모든 연결을 마치면 참여 준비가 완료됩니다.
딩코 모집·참여 확인 페이지에서 현재 기수를 선택하고, 카카오 로그인하면 챌린지 멤버십이 즉시 생성되어 자리가 확보됩니다.
기수별 사전 진단을 통과하면 GitHub 연결 단계가 열립니다.
GitHub를 먼저 연결하면 조직 권한 확인과 개인 private 저장소 준비가 자동으로 예약됩니다.
Discord를 연결하면 Spring 챌린지 1기 카테고리와 공지·읽을거리·질문·자유 채널 권한이 설정됩니다.
홈페이지에서 submit/<미션> 브랜치를 만들고 코드를 push한 뒤 버튼 한 번으로 PR을 제출합니다.
자동 검사와 AI 리뷰에서 통과한 최신 커밋은 Dingco가 자동 병합하고 자유 채널에서 함께 축하합니다. 크루 Discord에서는 질문과 진행 상황을 함께 나누고, 공식 리뷰는 같은 크루 통과 PR을 우선으로 열되 없으면 같은 기수 다른 크루 PR로 이어집니다. 점수판은 주간에는 잠정 반영되고 마지막 누적 리뷰 마감 뒤 최종 확정됩니다.
같은 기수의 읽기 권한 개인 저장소는 private으로 유지되며 같은 기수 참가자는 주차 결과 공개 뒤 읽기 전용으로만 참고할 수 있습니다. 쓰기 권한은 본인 저장소에만 부여됩니다. 크루는 보통 5~6명으로 운영하고 명단은 공개 전까지 숨깁니다. 세부 점수표는 공개하지 않으며, 최종 점수 확정 뒤 동의한 우승 크루만 Hall of Fame·GitHub 배지·공개 이름으로 소개합니다. 참가 등록은 시작 주 수요일 19:00에 마감합니다. 사전 진단이 있는 트랙은 같은 시각까지 통과해야 하며, 크루 명단과 전용 Discord 채널은 20:00에 공개됩니다. 공식 시작과 1주차 미션 공개는 같은 날 21:00이며, 그 뒤로는 매주 수요일 21:00에 새 미션이 열리고 다음 화요일 21:00에 제출이 마감됩니다. 공식 리뷰는 매주 즉시 하지 않아도 되지만, 서로 다른 주차 기준으로 필요한 리뷰 수를 마지막 주차 뒤 일요일 21:00 전까지 채워야 합니다. 1주차 문제·개인 저장소·미션 브랜치는 미리 준비할 수 있고, PR 제출 버튼은 내 크루 채널 준비가 끝난 뒤 자동으로 활성화됩니다. GitHub·Discord 연결이 덜 끝난 참가자는 배정된 크루를 유지합니다.
FIT CHECK
이런 분께 맞고, 이런 분께는 맞지 않습니다
추천합니다
Spring Boot API는 만들어봤지만 내부 동작을 설명하기 어려운 분
면접 답변을 외우는 대신 자기 코드와 테스트를 근거로 말하고 싶은 분
매주 작은 PR과 자동 리뷰가 있어야 실행을 끝까지 밀어붙일 수 있는 분
추천하지 않습니다
Java 문법과 HTTP 요청·응답을 아직 한 번도 다뤄보지 않은 분
코드와 테스트를 제출하지 않고 콘텐츠만 둘러보고 싶은 분
COMPLETION
완주 기준을 시작 전에 공개합니다
4주 동안 주차별 통합 미션 PR 4개를 모두 제출합니다.
서로 다른 3개 주차의 통과 PR에 공식 리뷰를 제출합니다.
시작 전 준비
Java 기본 문법과 Git 브랜치·커밋의 기초가 필요합니다.
매주 약 4~6시간 동안 구현, 설명 수정과 필요한 리뷰 반영에 참여해야 합니다.
FAQ
참여 전에 가장 많이 묻는 것
기존 10주 부트캠프와 같은 과정인가요?
아닙니다. 이 챌린지는 4주 동안 한 과목을 완주하는 별도 트랙입니다. 더 긴 프로젝트·취업 집중 과정이 필요한 경우에만 10주 부트캠프로 이어집니다.
강의나 교재도 함께 제공되나요?
아닙니다. 챌린지는 주차별 문제, private 실습 저장소, 제출 기준과 리뷰 루프를 제공합니다. 연결 강의는 별도 구매 가능한 선택형 사전학습이며 수강은 필수가 아닙니다.
홈페이지 제출이나 링크 붙여넣기도 가능한가요?
제출 결과는 GitHub PR로만 받습니다. 다만 저장소·브랜치·PR 준비와 리뷰 확인은 딩코 홈페이지 버튼으로 쉽게 이어집니다.
Discord에는 무엇이 공개되나요?
Discord에는 개인별 상세 리뷰를 올리지 않고, 주간 요약과 운영 공지만 공유합니다. Spring 챌린지 1기 공용 채널은 읽을거리, 질문, 자유 대화와 운영 안내를 위한 공간입니다.