InterviewForge

# 개발자 맞춤형 AI 모의면접 서비스 아이디어 제안서 > **한 줄 정의** > 사용자의 **GitHub 프로젝트 경험**과 **실제 지원 채용공고**를 연결해, 지원서 준비부터 실제와 유사한 기술면접 시뮬레이션까지 이어주는 개발자 취업 준비 서비스. --- ## 1. 아이디어 배경 개발자 취업 준비 과정에서는 크게 세 가지 문제가 반복된다. 1. 프로젝트를 여러 개 수행했지만, **내 경험 중 어떤 내용을 지원 회사에 강조해야 하는지 판단하기 어렵다.** 2. 채용공고마다 요구 기술과 역할이 다른데, 매번 **이력서와 자기소개서를 새롭게 맞추는 데 많은 시간이 든다.** 3. 기술 지식을 공부하더라도 실제 면접에서는 단순 CS 문제보다 **“왜 이 기술을 선택했나요?”, “본인이 직접 구현한 부분은 어디인가요?”, “다시 만든다면 무엇을 바꾸겠나요?”**처럼 지원자의 프로젝트를 파고드는 질문이 등장한다. 따라서 본 서비스는 단순한 `AI 면접 질문 생성기`가 아니라, > **채용공고 → GitHub 프로젝트 분석 → 지원서 최적화 → 맞춤 면접 → 피드백** 이 하나의 흐름으로 연결되는 **개발자 취업 리허설 플랫폼**을 목표로 한다. --- ## 2. 타깃 페르소나와 문제 정의 ### 핵심 페르소나 **김개발 / 24세 / 신입 개발자 취업 준비생** - 학교·부트캠프·동아리에서 여러 프로젝트를 수행했다. - GitHub에 프로젝트와 코드가 남아 있다. - Spring, React, AI 등 여러 기술을 사용해봤지만 본인의 강점을 한 문장으로 설명하기 어렵다. - 여러 개발자 채용공고를 보고 있지만 공고마다 지원서를 수정하는 과정이 번거롭다. - CS 질문은 공부해서 답할 수 있지만 자신의 프로젝트를 깊게 질문받으면 답변이 흔들린다. - 실제 면접 경험이 적어 긴장감 있는 면접 환경에 익숙하지 않다. ### 문제 한 문장 > 개발자 취업 준비생은 실제 지원 회사의 요구사항과 자신의 프로젝트 경험을 연결하기 어려워, 지원서 작성과 프로젝트 기반 기술면접 준비를 각각 반복해야 한다. --- ## 3. 서비스 포지셔닝 > **지원하고 싶은 개발자 채용공고와 내 GitHub를 연결하면, AI가 회사가 원하는 역량과 내가 실제로 해본 경험을 매칭하고 그 내용을 기반으로 지원서부터 실제 면접까지 준비해주는 서비스.** 슬로건 후보: - **내 GitHub를 읽은 면접관을 만나보세요.** - **내가 지원할 회사의 면접을 먼저 경험하다.** - **지원 공고부터 내 코드까지 알고 있는 AI 면접관.** --- ## 4. 꼬꼬면과의 차별화 방향 단순히 “더 현실적인 화면”을 만드는 것만으로는 차별화가 약하다. 핵심 차별점은 **질문의 근거(Context)** 로 잡는다. | 구분 | 일반적인 AI 기술면접 서비스 | 제안 서비스 | |---|---|---| | 질문 기준 | CS 분야 / 기술 스택 | **실제 채용공고 + GitHub 프로젝트** | | 개인화 | 사용자가 고른 분야 | **사용자의 실제 코드와 개발 기록** | | 프로젝트 질문 | 사용자가 입력한 프로젝트 설명 | **README, 코드, 기술 스택, 커밋 등 실제 자료 기반** | | 지원 회사 반영 | 제한적 | **JD(Job Description) 분석** | | 준비 범위 | 면접 중심 | **공고 → 지원서 → 면접 → 피드백 연결** | | 답변 검증 | 일반 지식 기준 | **사용자의 프로젝트 근거와 비교** | | 현실감 | 질문·꼬리질문 | **시간 제한, 이전 답변 기억, 압박 강도, 음성, 끼어들기 등** | ### 핵심 차별화 문장 > 꼬꼬면이 **“기술면접을 연습하는 서비스”**라면, 본 서비스는 **“내가 실제로 지원할 회사의 면접을 미리 경험하는 서비스”**를 목표로 한다. --- ## 5. 서비스가 사용하는 핵심 데이터 서비스는 세 가지 정보를 하나의 Context로 결합한다. ```text [지원자] GitHub / 기존 이력서 / 자기소개서 ↓ Candidate Context + [회사] 채용공고 / 요구 기술 / 주요 업무 ↓ Job Context + [면접] 직무별 질문 전략 / 기술 질문 / 프로젝트 질문 ↓ Interview Context ``` LLM에는 단순히 > “Java 백엔드 면접 질문을 해줘.” 가 아니라, > “이 지원자는 GitHub에서 Spring Boot와 Redis를 활용한 프로젝트를 수행했고, 현재 지원한 회사는 대규모 트래픽 처리와 Redis 경험을 우대한다. 지원자의 코드와 프로젝트 설명을 근거로 실제 면접관처럼 검증 질문을 생성하라.” 와 같은 Context가 전달된다. --- # 6. 핵심 기능 ① GitHub 프로젝트 자동 분석 ## 목표 사용자가 프로젝트 경험을 처음부터 다시 작성하지 않아도 GitHub를 연결하면 프로젝트 정보를 자동으로 정리한다. GitHub가 제공하는 **공식 GitHub MCP Server**를 활용하는 방향을 우선 검토한다. ### 가져올 정보 후보 - Repository 목록 - Repository별 README - 사용 언어 - 주요 디렉터리 구조 - `package.json`, `requirements.txt`, `pyproject.toml`, `build.gradle` 등 의존성 파일 - 주요 소스코드 - Commit 내역 - Pull Request - Issue - 프로젝트 기여 기록 ### 분석 결과 예시 ```yaml project: name: vibeGuard role: Backend / AI Integration technologies: - Spring Boot - PostgreSQL - OpenAI API - Docker inferred_experience: - REST API 설계 경험 - LLM API 연동 - PostgreSQL 데이터 모델링 - Docker 기반 실행 환경 구성 interview_points: - LLM 응답 지연을 어떻게 처리했는가? - PostgreSQL을 선택한 이유는? - API 에러 처리를 어떤 구조로 설계했는가? - Docker를 실제 배포에 사용했는가, 개발환경에만 사용했는가? evidence: - README.md - src/... - docker-compose.yml ``` ## 중요한 원칙: Evidence 기반 AI가 사용자의 프로젝트 경험을 **만들어내면 안 된다.** 가능한 모든 경험에는 근거를 연결한다. ```text “Redis를 활용해 캐싱 경험이 있습니다.” 근거 └── Repository A ├── build.gradle └── RedisConfig.java ``` 사용자는 AI가 잘못 추론한 경험을 수정하거나 제외할 수 있어야 한다. ### 사용자에게 주는 경험 일반적인 이력서 AI: > “프로젝트 내용을 입력해주세요.” 본 서비스: > **“GitHub를 연결해주세요. 실제 기록에서 프로젝트 경험을 찾아드릴게요.”** --- # 7. 핵심 기능 ② 채용공고 분석 사용자가 실제 지원하려는 공고에서 지원서와 면접 준비에 필요한 정보를 추출한다. ### 추출 예시 ```yaml company: Example position: Backend Engineer required: - Java / Kotlin - Spring Boot - RDBMS - REST API preferred: - Redis - AWS - 대규모 트래픽 처리 경험 - CI/CD 경험 responsibilities: - API 서버 개발 - 서비스 성능 개선 - 데이터 구조 설계 ``` 이후 사용자의 GitHub 경험과 비교한다. ### Job ↔ Candidate Matching | 채용 요구사항 | GitHub 근거 | 매칭 | |---|---|---| | Spring Boot | project-A | 높음 | | Redis | project-B | 높음 | | AWS | 없음 | 낮음 | | CI/CD | GitHub Actions | 중간 | | 대규모 트래픽 | 근거 없음 | 낮음 | 이 매칭 결과가 이력서 추천, 자기소개서 소재 추천, 면접 질문 생성의 공통 기반이 된다. --- # 8. 채용공고는 어디에서 가져올 것인가? 이 부분은 구현 전에 반드시 결정해야 한다. ## MVP 추천: 공고 URL 입력 + 텍스트 fallback ### 1순위 — 사용자가 실제 지원 공고 URL 입력 ```text 채용공고 URL 붙여넣기 ↓ 페이지에서 공고 내용 추출 ↓ JD 구조화 ``` 장점: - 사용자가 실제 지원하는 공고를 정확하게 사용한다. - 모든 채용공고를 자체 DB로 구축할 필요가 없다. - MVP 구현 범위가 작아진다. 단, 해당 사이트의 이용약관·robots 정책·접근 허용 범위는 확인해야 한다. ### 2순위 — 공고 텍스트 직접 붙여넣기 URL 파싱이 실패하는 경우 fallback으로 사용한다. ```text [채용공고 내용 붙여넣기] → LLM 구조화 → 기술스택 / 주요업무 / 자격요건 추출 ``` ### 3순위 — 허용된 Open API / 공개 데이터 향후 서비스 내부에 채용공고 검색 기능을 넣고 싶다면 고용 관련 공공데이터나 정식 API를 추가한다. ### 초기 MVP에서는 추천하지 않는 방식 원티드 / 점핏 / 사람인 / 잡코리아의 공고 전체를 주기적으로 크롤링해 자체 채용 DB를 만드는 방식. 이 방식은 - 사이트 구조 변경 - 크롤링 유지보수 - 이용약관 - 데이터 이용 권한 - 요청량 관리 등 서비스 핵심과 무관한 복잡도가 커진다. **카카오테크 캠퍼스 팀 프로젝트에서는 `사용자가 공고 URL 입력 → 분석` 구조를 우선 추천한다.** --- # 9. 핵심 기능 ③ 공고 맞춤 이력서 개선 단순히 이력서를 새로 생성하는 것보다 **채용공고에 맞춰 어떤 실제 경험을 강조할지 추천**하는 기능을 중심으로 둔다. 예: ```text 지원 공고 “Redis 경험 우대” ↓ GitHub 분석 Project B에서 Redis 사용 확인 ↓ 추천 Project B의 캐싱 적용 경험을 이력서 주요 프로젝트에 배치 ``` ## Evidence 기반 작성 ```text 채용 요구 역량 ↓ GitHub Evidence 검색 ↓ 사용자 경험 확인 ↓ 이력서 문장 생성 ``` AI는 GitHub나 사용자 입력에서 확인되지 않은 수치·성과를 임의로 만들지 않는다. --- # 10. 핵심 기능 ④ 공고 맞춤 자기소개서 자기소개서는 다음 세 가지를 사용한다. ```text 채용공고 + GitHub 프로젝트 + 사용자가 입력한 실제 경험 / 상황 / 가치관 ``` 바로 완성본을 만드는 것보다 다음 UX가 더 적합하다. ```text 이 공고는 문제 해결 경험을 중요하게 보고 있습니다. GitHub를 분석해보니 다음 프로젝트를 활용할 수 있습니다. 1. Project A - API 장애 해결 2. Project B - 모델 성능 개선 어느 경험을 사용하시겠습니까? ``` 사용자가 경험을 선택하고 사실관계를 보완한 뒤 AI가 문장화한다. --- # 11. 핵심 기능 ⑤ 실제 같은 AI 면접 시뮬레이션 서비스의 핵심 Experience다. ## 면접 시작 전 ```text 회사: Example 포지션: Backend Developer GitHub: 연결 완료 이력서: 등록 완료 채용공고: 분석 완료 ``` AI가 면접 구조를 만든다. ```text 1. 자기소개 3분 2. 지원동기 5분 3. 프로젝트 검증 15분 4. 기술 질문 15분 5. 문제 해결 / 상황 질문 10분 6. 지원자 질문 5분 ``` --- # 12. “진짜 면접 같다”를 만드는 핵심 장치 단순히 음성 대화를 제공한다고 실제 면접처럼 느껴지는 것은 아니다. ## 12.1 면접관 Persona ```text Backend Senior Engineer 경력 8년 성향: 차분하지만 기술적 근거를 끝까지 확인 관심 영역: DB / API / 시스템 설계 ``` 향후에는 HR Interviewer, Tech Lead, Senior Engineer 등 여러 면접관을 둘 수 있다. ## 12.2 실제 프로젝트를 파고드는 질문 예: > 프로젝트에서 Redis를 사용하셨다고 했는데, 캐시 무효화는 어떻게 처리했나요? 지원자: > TTL 방식으로 처리했습니다. AI: > TTL은 어떤 기준으로 정했나요? 지원자: > 정확히 기억나지 않습니다. AI: > 그렇다면 당시 서비스 특성을 기준으로 다시 설계한다면 어떤 기준으로 TTL을 결정하시겠어요? 즉, ```text 답변 → 꼬리질문 → 검증 질문 → 대안 질문 ``` 으로 이어진다. ## 12.3 이전 답변 기억 면접관은 앞선 답변을 기억한다. ```text 15분 전: “Redis를 캐싱에 사용했습니다.” 현재: “Redis를 직접 사용한 경험은 많지 않습니다.” ``` AI: > 조금 전 프로젝트에서는 Redis를 사용했다고 말씀하셨는데, 직접 구현한 범위가 어느 정도였나요? ## 12.4 답변이 너무 길면 끼어들기 > “죄송하지만 시간이 많지 않아서 핵심만 말씀해주시겠어요?” ## 12.5 압박 강도 ```text Friendly Standard Pressure ``` ## 12.6 면접 중 평가 숨기기 실제 면접처럼 면접 도중에는 점수·힌트·정답을 보여주지 않는다. --- # 13. 대표 기능: “면접관이 내 코드를 보고 있다” 면접 화면에서 실제 GitHub Code View를 함께 활용한다. AI 면접관: > `UserService`의 이 부분에서는 Repository를 직접 호출하고 있는데, Service Layer를 이렇게 구성한 이유가 있나요? 사용자는 > **“AI가 그냥 개발자 질문을 생성하는 것이 아니라 진짜 내 코드를 보고 있다.”** 는 느낌을 받는다. 이 기능은 서비스의 대표적인 **Signature Experience**가 될 가능성이 높다. --- # 14. 핵심 기능 ⑥ 면접 종료 후 분석 면접 종료 뒤 Interview Report를 제공한다. ```text Technical Knowledge 72 Project Understanding 91 Communication 68 Problem Solving 84 Job Fit 79 ``` ### 질문별 분석 예시 ```text Q. 왜 PostgreSQL을 선택했나요? 문제 → MySQL 등 다른 DB와 비교한 선택 근거가 부족함 GitHub Evidence → 프로젝트에서는 PostgreSQL을 사용했지만 특정 PostgreSQL 기능을 사용한 근거는 약함 다음 면접에서 준비할 내용 → 데이터 구조 / 팀 환경 / 개발 편의성 등 실제 선택 배경을 정리 ``` --- # 15. 중요한 차별화: “내가 실제로 한 경험인가?” GitHub의 기록을 이용해 사용자의 답변을 검증하는 기능을 고려할 수 있다. 예: 지원자: > 제가 프로젝트의 CI/CD 파이프라인을 직접 구축했습니다. GitHub에서 해당 workflow가 다른 팀원의 commit에 주로 나타나는 경우: AI: > 해당 설정의 주요 변경 기록은 다른 기여자에게서 더 많이 확인됩니다. 본인이 담당한 범위를 구체적으로 설명해주시겠어요? 단, **commit author = 실제 담당자**라고 단정해서는 안 된다. Pair Programming, 계정 공유, squash merge 등의 경우가 있기 때문이다. 따라서 GitHub 기록은 **사실 판정 도구가 아니라 추가 질문을 만들기 위한 Evidence**로 사용한다. --- # 16. 전체 사용자 흐름 ```text 회원가입 ↓ GitHub 연결 ↓ 프로젝트 자동 분석 ↓ Developer Profile 생성 ↓ 지원할 채용공고 URL 입력 ↓ JD 분석 ↓ GitHub ↔ JD 역량 매칭 ↓ 지원 전략 제안 ↓ 이력서 / 자기소개서 개선 ↓ AI 모의면접 ↓ 면접 피드백 ↓ 부족한 역량 분석 ↓ 지원서 수정 / 재면접 ``` 핵심은 한 번 쓰고 끝나는 것이 아니라 다음 Loop를 만드는 것이다. ```text 지원서 ↓ 면접 ↓ 약점 발견 ↓ 지원서 / 답변 수정 ↓ 재면접 ``` --- # 17. 핵심 자산: Developer Profile GitHub repository 전체를 매번 LLM에 보내면 속도와 비용 문제가 생긴다. 따라서 최초 분석 시 사용자의 개발 경험을 구조화한 Profile을 생성한다. ```json { "projects": [ { "name": "vibeGuard", "role": "backend", "technologies": [ "Spring Boot", "PostgreSQL", "Docker" ], "evidence": [ "README.md", "docker-compose.yml", "src/..." ] } ] } ``` 이 Profile을 공통으로 사용한다. - 이력서 - 자기소개서 - 채용공고 매칭 - 면접 질문 - 면접 평가 --- # 18. 기술 구조 초안 ```text ┌─────────────────────┐ │ Frontend │ │ React / Next │ └─────────┬───────────┘ │ ▼ ┌─────────────────────┐ │ Backend │ │ Spring / FastAPI 등 │ └──────┬────────┬─────┘ │ │ ▼ ▼ GitHub MCP JD Parser │ │ ▼ ▼ Repo Data Job Data │ │ └───┬────┘ ▼ Context Builder │ ▼ LLM API │ ┌──────┼────────┐ ▼ ▼ ▼ Resume Interview Feedback ``` --- # 19. GitHub MCP 활용 구조 GitHub 공식 MCP Server는 repository와 code 등의 GitHub context를 AI 도구가 사용할 수 있게 연결하는 용도로 활용할 수 있다. MCP 자체를 서비스 전체 구조로 보는 것이 아니라 **GitHub 데이터 접근 Adapter**로 보는 편이 좋다. ```text User ↓ GitHub OAuth / 권한 부여 ↓ GitHub MCP ↓ Repo / README / Code / PR / Issue ↓ Our Backend ↓ Developer Profile ↓ LLM ``` ### 검토할 보안·개인정보 항목 - Private Repository 접근 여부 - 최소 권한 원칙 - Access Token 보관 방식 - Repository 원본 데이터 저장 여부 - 사용자가 GitHub 연결을 해제했을 때 저장 데이터 삭제 정책 - 전체 repository를 매번 LLM으로 보내지 않는 구조 --- # 20. MVP 범위 제안 카카오테크 캠퍼스 팀 프로젝트에서는 기능을 지나치게 많이 넣지 않는 것이 중요하다. ## MUST ### 1. GitHub 연동 - Repository 가져오기 - README / 주요 코드 분석 - 기술 스택 추출 - 프로젝트 요약 ### 2. 채용공고 입력 - URL 또는 Text 입력 - JD 구조화 - 요구 역량 추출 ### 3. GitHub ↔ JD 매칭 - 보유 역량 - 관련 프로젝트 - 부족한 역량 ### 4. 맞춤 모의면접 - 프로젝트 질문 - JD 질문 - 동적 꼬리질문 - 이전 답변 기억 - 음성 면접 ### 5. 면접 Report - 잘한 점 - 부족한 점 - 질문별 피드백 - 프로젝트 설명 개선 포인트 ## SHOULD - 이력서 프로젝트 문장 추천 - 자기소개서 소재 추천 - 면접관 Persona - 면접 난이도 - 답변 모순 탐지 ## COULD - 회사별 면접 후기 데이터 - 여러 면접관 Panel Interview - System Design Whiteboard - 코딩테스트 - 표정 / 시선 분석 - 취업공고 자동 추천 초기 MVP에서는 과감하게 제외한다. --- # 21. 가장 추천하는 MVP 데모 시나리오 ```text ① GitHub 로그인 ② “지원할 공고를 넣어주세요.” → Backend Engineer 공고 입력 ③ AI “이 공고에서는 Redis와 Spring 경험을 중요하게 보고 있습니다.” ④ AI “GitHub를 확인해보니 Project A에서 Spring과 Redis를 사용한 경험이 있습니다.” ⑤ AI “이 프로젝트를 중심으로 면접을 진행하겠습니다.” ⑥ 실제 면접 시작 면접관: “Project A에서 Redis를 사용하셨는데 왜 데이터베이스 조회 대신 캐싱을 적용하셨나요?” 지원자 답변 면접관: “그렇다면 Cache Invalidation은 어떤 방식으로 처리하셨나요?” ⑦ 면접 종료 ⑧ Report “Redis 사용 경험은 확인되었지만 캐시 정책에 대한 설명이 부족했습니다.” ``` 이 하나의 장면만 완성도 있게 구현해도 서비스의 차별점을 설명하기 쉽다. --- # 22. 핵심 Value Proposition 핵심은 **“AI가 면접을 해준다”**가 아니다. 진짜 차별점은: > **AI가 ‘내가 실제로 무엇을 만들었는지’ 알고 면접한다.** 그리고 두 번째 Context가 붙는다. > **AI가 ‘내가 어디에 지원하는지’ 알고 면접한다.** 따라서 서비스 공식은 다음과 같다. ```text My GitHub + Job Description + Interview Simulation = Personalized Developer Interview ``` --- # 23. 팀 프로젝트에서 검증해야 할 핵심 가설 ### 가설 1 > 개발자는 일반적인 CS 질문보다 자신의 실제 프로젝트를 기반으로 한 질문을 더 가치 있게 느낀다. ### 가설 2 > 실제 지원공고가 반영되면 사용자는 일반 모의면접보다 더 현실적이라고 느낀다. ### 가설 3 > GitHub 자동 분석은 사용자가 프로젝트 경험을 직접 입력해야 하는 부담을 줄인다. ### 가설 4 > 면접 결과가 다시 이력서와 자기소개서 개선으로 연결되면 서비스 재사용 이유가 생긴다. --- # 24. 사용자 인터뷰 질문 서비스 구현 전에 개발자 취업 준비생을 대상으로 확인하면 좋다. 1. 모의면접을 준비할 때 가장 어려운 것은 무엇인가? 2. CS 질문과 프로젝트 질문 중 어느 쪽이 더 어렵다고 느끼는가? 3. 자신의 프로젝트를 면접용으로 별도 정리해 놓았는가? 4. GitHub를 AI가 분석해서 질문을 만드는 것에 거부감이 있는가? 5. Private Repository 접근을 허용할 의향이 있는가? 6. 지원할 때마다 이력서를 수정하는가? 7. 자기소개서는 공고별로 얼마나 수정하는가? 8. 지원 공고를 입력하면 예상 면접 질문을 생성해주는 기능을 사용할 것인가? 9. 음성 면접과 텍스트 면접 중 어느 것을 선호하는가? 10. 실제 면접처럼 답변 중 끼어들거나 압박 질문을 하는 기능을 원하는가? 11. 면접 결과 중 가장 받고 싶은 피드백은 무엇인가? 12. 비용을 지불한다면 어떤 기능 때문에 지불할 것인가? --- # 25. 지금 팀에서 답해야 할 질문 ## 제품 방향 1. 서비스의 1순위 가치는 **“실제 같은 모의면접”**인가, **“지원서부터 면접까지 전체 취업 준비”**인가? 2. 주요 사용자는 **신입 개발자 / 인턴 지원자 / 경력 개발자** 중 누구인가? 3. 첫 MVP에서는 백엔드·프론트엔드 등 특정 개발 직군 하나에 집중할 것인가? ## GitHub 4. Public Repository만 분석할 것인가, Private Repository까지 연결할 것인가? 5. README 수준이 아니라 실제 코드까지 읽어 질문하는 것을 핵심 기능으로 만들 것인가? 6. Commit/PR 기록으로 “본인이 담당한 부분”을 추론할 것인가? ## 채용공고 7. 사용자가 지원 공고 URL을 직접 넣게 할 것인가? 8. 서비스 내부에서 현재 채용공고를 검색하게 할 것인가? 9. URL 분석이 실패하면 공고 내용을 붙여넣게 할 것인가? ## 면접 시뮬레이션 10. MVP부터 **음성 면접**을 필수로 구현할 것인가? 11. 실제 면접관 영상/Avatar가 필요한가, 음성과 UI만으로 충분한가? 12. 면접관이 사용자의 답변 도중 끼어드는 기능까지 구현할 것인가? 13. 면접 난이도를 Friendly / Standard / Pressure처럼 나눌 것인가? ## 지원서 14. AI가 이력서 전체를 새로 작성하는가, 기존 이력서를 분석하고 수정하는가? 15. 자기소개서를 자동 완성할 것인가, GitHub에서 적절한 경험을 추천하고 사용자가 선택하게 할 것인가? --- # 26. 현재 단계에서의 추천 결정안 카카오테크 캠퍼스 팀 프로젝트 범위를 고려하면 다음 구성을 추천한다. ```text TARGET 신입 개발자 / 인턴 지원자 CORE GitHub 기반 실제 프로젝트 면접 INPUT GitHub + 채용공고 URL MVP 1. GitHub 분석 2. JD 분석 3. Job ↔ Project Matching 4. 음성 모의면접 5. 동적 꼬리질문 6. 면접 Report SUB 이력서 프로젝트 문장 추천 자기소개서 소재 추천 NOT MVP 전체 채용공고 크롤링 코딩테스트 표정 분석 시선 분석 복잡한 3D Avatar ``` --- # 27. 다음 단계 위 질문들에 대한 팀의 결정을 바탕으로 다음 문서를 순서대로 구체화한다. 1. 최종 문제 정의 / 포지셔닝 2. 핵심 사용자 시나리오 3. 기능 요구사항 명세 4. 화면 흐름 및 와이어프레임 5. 시스템 아키텍처 6. GitHub MCP / JD Parser 상세 설계 7. LLM Prompt 및 Context 구조 8. MVP 개발 일정 및 역할 분담 9. 경쟁 서비스 비교 10. 사용자 검증 계획 --- # 참고한 현재 기술·데이터 방향 - GitHub는 공식 GitHub MCP Server를 제공하며 Repository와 코드 등 GitHub Context를 AI 도구에 연결할 수 있다. - GitHub 연동 시 실제 서비스에서는 OAuth·접근 권한·Token 관리·Private Repository 데이터 처리 정책을 함께 설계해야 한다. - 채용공고는 MVP에서 전체 사이트를 수집하기보다 사용자가 실제 지원 공고의 URL 또는 텍스트를 제공하는 방식이 구현·운영 측면에서 현실적이다. - 향후 자체 채용공고 검색 기능이 필요할 경우 공공데이터포털 등에서 제공되는 고용 관련 공개 데이터/API도 별도 검토할 수 있다. --- # v2 결정사항 및 Agent AI 설계 ## 1. 서비스 방향 확정 서비스 범위는 단순 모의면접에서 다음 흐름으로 확장한다. ```text 채용공고 입력 → GitHub 프로젝트 분석 → 공고-경험 매칭 → 이력서/자기소개서 개선 → 실제 같은 면접 시뮬레이션 → 면접 피드백 → 지원서/답변 재개선 ``` 단, 서비스의 대표 경험은 여전히 **실제 같은 개발자 면접 시뮬레이션**으로 둔다. 핵심 문장: > **지원 공고와 내가 실제로 만든 프로젝트를 알고 있는 AI 면접관.** --- ## 2. GitHub 소스코드 분석 범위 ### 추천 결론 **소스코드는 읽되, 한 줄씩 시험 문제처럼 묻지 않는다.** GitHub 코드는 질문의 주제가 아니라 **지원자의 실제 경험을 검증하기 위한 Evidence**로 활용한다. 실제 개발자 면접에서는 지원서에 작성한 개발 경험과 기술을 바탕으로 프로젝트의 역할, 기술 선택, 문제 해결 과정, 기술적 이해도를 묻는 경우가 많다. 별도의 코딩 테스트나 라이브 코딩에서는 새 문제를 해결하는 능력을 검증하는 경우가 일반적이다. 따라서 다음 방식이 적절하다. ```text Repository 분석 → 사용 기술/구조/경험 추출 → 상위 수준 프로젝트 질문 → 지원자 답변 → 필요할 때만 코드 Evidence 확인 → 심층 꼬리질문 ``` ### 예시 GitHub에서 Redis 사용이 확인됨. 면접관: > 이 프로젝트에서 Redis를 사용하셨는데 어떤 문제를 해결하기 위해 도입하셨나요? 지원자: > 반복 조회가 많아서 캐시로 활용했습니다. 면접관: > 그렇다면 데이터 정합성 문제는 어떻게 처리했나요? 지원자 답변이 모호할 경우에만 Repository Evidence를 사용한다. > Repository에서는 TTL 기반 설정이 확인되는데, 당시 TTL 값을 결정한 기준이 있었나요? 즉 서비스는 **Repository-Aware Interview**를 지향한다. --- ## 3. 질문 깊이 단계 ### Level 1 — 프로젝트 이해도 > 프로젝트에서 본인이 맡은 역할은 무엇이었나요? ### Level 2 — 기술 선택 > Spring Boot를 선택한 이유는 무엇인가요? ### Level 3 — 설계 > Redis를 도입하기 전과 후의 구조는 어떻게 달라졌나요? ### Level 4 — Trade-off > 정합성이 더 중요한 서비스였다면 동일한 캐싱 전략을 사용했을까요? ### Level 5 — Code Evidence > 실제 Repository에서는 TTL 600초 설정이 확인되는데, 이 값을 정한 기준이 있었나요? Level 5는 모든 질문에 사용하는 것이 아니라 필요한 순간에만 사용한다. --- ## 4. GitHub Repository 정책 MVP에서는 **Public Repository만 지원**한다. 권장 UI 문구: > **현재 MVP에서는 Public GitHub Repository만 분석할 수 있습니다. 민감한 정보나 외부에 공개할 수 없는 프로젝트는 연결하지 마세요.** 단순히 “사용하려면 Public으로 전환하세요”라고 안내하는 것은 추천하지 않는다. Private Repository에는 API Key, 내부 프로젝트 자료, 팀원의 정보, 라이선스상 공개하면 안 되는 코드 등이 포함될 수 있기 때문이다. 향후 OAuth와 권한 관리가 안정화되면 Private Repository 연결을 추가한다. --- ## 5. 이력서·자기소개서 기능 방향 AI가 지원서를 대신 작성하는 것이 아니라 다음 역할을 한다. ```text 채용공고 분석 → 요구 역량 추출 → GitHub에서 관련 경험 검색 → 강조할 프로젝트/경험 추천 → 사용자가 작성 → AI가 개선 ``` 예: 공고: ```text Redis 사용 경험 우대 ``` GitHub: ```text Project A에서 Redis 사용 확인 ``` AI: > 이번 공고에서는 Project A의 Redis 캐싱 경험을 주요 프로젝트로 강조하는 것을 추천합니다. 사용자의 기존 문장: > Spring Boot와 Redis를 사용했습니다. 개선: > Spring Boot 기반 API에서 반복 조회가 발생하는 데이터를 Redis에 캐싱하는 구조를 적용했습니다. 확인되지 않은 성능 수치나 역할은 생성하지 않는다. --- ## 6. 면접 시뮬레이션 방향 화면에 **3명의 AI 면접관**을 배치한다. ### 면접관 A — Tech Lead 관심 영역: - Architecture - 기술 선택 - Trade-off - System Design ### 면접관 B — Senior Developer 관심 영역: - 구현 - 디버깅 - 테스트 - 프로젝트 기여도 - GitHub Evidence ### 면접관 C — Manager / Recruiter 관심 영역: - 협업 - 갈등 - 지원동기 - 커뮤니케이션 - 조직 적합성 각 면접관은 서로 다른 관점으로 질문한다. --- ## 7. 3:3 면접에 대한 추천 최종적으로는 다음과 같은 3:3 형태를 만들 수 있다. ```text 면접관 3명 VS 사용자 + AI 지원자 2명 ``` 다만 MVP에서는 **1명의 사용자 : 3명의 AI 면접관** 구조를 우선 추천한다. 이유: - GitHub 기반 개인 질문에 집중할 수 있음 - 음성 Turn Taking 구현이 단순함 - 사용자의 답변 시간이 충분함 - Multi-Agent 역할 분리가 잘 보임 - 데모 시 차별성이 명확함 ### 확장 버전 ROUND 1 ```text 3 : 3 Group Interview - 자기소개 - 지원동기 - 협업 경험 ``` ROUND 2 ```text 1 : 3 Technical Panel - GitHub 프로젝트 - 기술 선택 - JD 요구역량 - 동적 꼬리질문 ``` ROUND 3 ```text 1 : 1 Deep Dive - 대표 프로젝트 - 문제 해결 - 부족한 기술 검증 ``` MVP에서는 ROUND 2만 잘 구현해도 충분히 강한 데모가 된다. --- # 8. Agent AI를 넣을 위치 Agent는 단순히 LLM을 여러 번 호출하는 데 사용하는 것이 아니라, > **다음에 무엇을 해야 하는지 스스로 판단하고 Tool을 선택해야 하는 지점** 에 배치한다. 추천 구조: ```text Career Orchestrator │ ┌───────────────────┼────────────────────┐ ▼ ▼ ▼ Job Analysis Agent GitHub Evidence Agent Application Coach │ ▼ GitHub MCP ↓ Interview Director │ ┌───────────────────┼───────────────────┐ ▼ ▼ ▼ Tech Lead Agent Senior Dev Agent Manager Agent │ ▼ User │ ▼ Evaluation Agent ``` --- ## 9. Career Orchestrator Agent 전체 취업 준비 흐름을 관리하는 Supervisor Agent. 사용자의 현재 상태를 확인해 다음 단계를 결정한다. 예: ```text GitHub 연결 O JD 입력 X → JD 입력 요청 GitHub 분석 O JD 분석 O → Job-Candidate Matching 실행 지원서 개선 완료 → Interview Director 실행 ``` --- ## 10. Job Analysis Agent 채용공고를 분석한다. Input: ```text 채용공고 URL 또는 Text ``` Output: ```yaml position: required_skills: preferred_skills: responsibilities: experience_requirements: culture_keywords: expected_interview_topics: ``` --- ## 11. GitHub Evidence Agent 서비스의 핵심 Agent 중 하나. ### Tool **GitHub MCP** ### 역할 필요한 순간에 Repository를 검색하여 경험의 Evidence를 찾는다. 예: Interview Director: > 이 사용자가 Redis를 실제 프로젝트에서 사용했는지 확인해줘. GitHub Evidence Agent: ```text Project A - build.gradle: Redis dependency - RedisConfig.java - CacheService.java Confidence: HIGH ``` 중요한 점은 Repository 전체를 매번 LLM에게 넣지 않는 것이다. ```text 질문 → GitHub Evidence Agent → MCP Tool 호출 → 관련 코드 검색 → 필요한 Evidence만 반환 ``` --- ## 12. Application Coach Agent JD와 GitHub 경험을 매칭해 다음을 추천한다. - 강조할 프로젝트 - 강조할 기술 - 이력서 프로젝트 순서 - 자기소개서 소재 - 부족한 경험 예: ```text JD: Redis 경험 우대 GitHub: Project A Redis 확인 → Project A를 대표 프로젝트로 추천 ``` --- ## 13. Interview Director Agent 면접 전체를 지휘하는 핵심 Agent. 매 답변마다 다음을 판단한다. ```text 어느 면접관이 질문할 것인가? → 무엇을 질문할 것인가? → 꼬리질문이 필요한가? → GitHub 확인이 필요한가? → 난이도를 올릴 것인가? → 다음 주제로 넘어갈 것인가? ``` --- ## 14. Interviewer Agents ### Tech Lead Agent 질문 영역: ```text Architecture System Design Technology Choice Trade-off ``` ### Senior Developer Agent 질문 영역: ```text Implementation Debugging Testing Project Contribution Code Evidence ``` ### Manager / HR Agent 질문 영역: ```text Communication Collaboration Conflict Motivation ``` --- ## 15. Agent가 실제로 동작하는 예 사용자: > Redis를 이용해서 캐싱을 했습니다. Senior Developer Agent: > 캐시 무효화는 어떻게 처리했나요? 사용자: > TTL을 사용했습니다. Interview Director: ```text 기술 선택 근거가 부족함 → GitHub Evidence 확인 필요 ``` GitHub Evidence Agent: ```text CacheConfig.java TTL = 600 seconds ``` Tech Lead Agent: > 당시 TTL을 10분으로 설정하셨는데, 이 값을 결정한 기준은 무엇이었나요? 사용자: > 사실 해당 설정은 팀원이 담당해서 정확히 모릅니다. Senior Developer Agent: > 그렇다면 이 기능에서 본인이 직접 담당한 범위는 어디까지였나요? 이 과정이 Agent AI의 가장 강한 데모 포인트가 된다. --- ## 16. Evaluation Agent 면접 중 질문에는 참여하지 않고 관찰한다. 평가: ```text Technical Knowledge Project Understanding Problem Solving Communication Job Fit Evidence Consistency ``` 면접 종료 후 Report를 만든다. 예: ```text Project Understanding 87 Technical Knowledge 72 Communication 81 Job Fit 86 ``` 피드백: > Redis 사용 목적은 잘 설명했지만 캐시 무효화 전략의 Trade-off 설명이 부족했습니다. --- # 17. 면접의 즉각 반응 사용자의 답변을 바탕으로 Agent가 행동을 선택한다. ```text 답변 충분 → 다음 질문 답변 모호 → 구체적 사례 요구 기술적 오류 → 개념 확인 답변이 너무 김 → 면접관 개입 GitHub Evidence와 모순 → 실제 담당 범위 질문 좋은 답변 → 난이도 상승 ``` 예: > 죄송하지만 시간이 제한되어 있어서 핵심만 정리해주시겠어요? 또는: > 일반적인 Redis 설명보다는 본인 프로젝트에서 어떤 문제를 해결했는지 말씀해주세요. --- # 18. Agent Framework 후보 구조적으로는 **Supervisor + Specialized Agents** 패턴이 적합하다. ## LangGraph 적합한 이유: - State 관리 - 조건 분기 - Agent Routing - Tool 호출 - Human-in-the-loop - 면접 Session 유지 예시 State: ```python InterviewState = { "jd": ..., "candidate_profile": ..., "current_topic": ..., "asked_questions": ..., "answers": ..., "current_interviewer": ..., "evaluation": ... } ``` ## OpenAI Agents SDK 적합한 이유: - Agent - Tool - Handoff - Guardrail - Multi-Agent orchestration 구조를 비교적 명확하게 표현할 수 있다. 팀이 이미 LangChain을 사용한 경험이 있다면 LangGraph를 우선 검토할 만하다. --- # 19. MCP와 Agent의 관계 중요: ```text MCP ≠ Agent ``` MCP는 외부 시스템에 접근하기 위한 Tool Interface에 가깝다. 따라서: ```text GitHub Evidence Agent ↓ GitHub MCP ↓ GitHub ``` Agent가 > “이 지원자의 Redis 구현 근거를 확인해야겠다.” 고 판단하고 GitHub MCP Tool을 호출하는 구조다. --- # 20. Agent를 사용하지 않을 부분 다음은 일반 Backend Logic으로 구현한다. - 로그인 - 회원가입 - Repository URL 저장 - JD DB 저장 - 파일 업로드 - 사용자 설정 - 결과 저장 - UI 상태 관리 Agent는 판단과 Tool 선택이 필요한 곳에만 사용한다. --- # 21. 최종 MVP 추천 ## MUST 1. Public GitHub Repository 입력 2. GitHub MCP 기반 Repository 분석 3. 채용공고 URL/Text 입력 4. JD 요구역량 추출 5. JD ↔ GitHub 경험 매칭 6. 이력서/자기소개서 강조 경험 추천 7. 1 : 3 AI 면접관 음성 면접 8. 실시간 동적 꼬리질문 9. 필요한 순간 GitHub Evidence 조회 10. 면접 Report ## SHOULD - 면접관 Persona - 답변 중 끼어들기 - 난이도 동적 조절 - 답변 모순 탐지 - 지원서 개선 Loop ## LATER - Private Repository - AI 지원자 2명 - 완전한 3:3 면접 - 표정/시선 분석 - 코딩 테스트 - 채용공고 대규모 크롤링 - 복잡한 3D Avatar --- # 22. 최종 Demo Scenario ```text ① 사용자가 Public GitHub Repository 등록 ② GitHub Evidence Agent 분석 Spring Boot / Redis / Docker 발견 ③ 실제 지원공고 입력 “Spring Boot, Redis 경험 우대” ④ Application Coach “Project A의 Redis 경험을 강조하세요.” ⑤ 3명의 AI 면접관 앞에서 음성 면접 시작 ⑥ Senior Developer “Redis를 어떤 문제를 해결하기 위해 사용했나요?” ⑦ 사용자 답변 ⑧ Interview Director “더 깊은 기술 검증 필요” ⑨ GitHub Evidence Agent → MCP 호출 ⑩ Tech Lead “Repository에서는 TTL 방식이 확인되는데 이 값을 정한 기준은 무엇이었나요?” ⑪ 면접 종료 ⑫ Evaluation Agent Report 생성 ⑬ 부족한 답변을 바탕으로 이력서/면접 답변 재개선 ``` --- # 23. 최종 서비스 차별화 문장 > **꼬꼬면이 기술면접을 연습하게 해주는 서비스라면, 우리는 실제 지원 공고와 실제 GitHub 프로젝트를 연결해 ‘그 회사에 지원한 나’를 시뮬레이션한다.** 또는: > **내 GitHub를 읽고, 내가 지원할 공고를 이해한 AI 면접관.** --- # 참고 자료 - Kakao Tech — 개발 경험 및 지원서 기술 기반 인터뷰 - https://tech.kakao.com/posts/400 - https://tech.kakao.com/posts/451 - https://tech.kakao.com/posts/512 - Microsoft Careers — Technical Interviewing / Interview Tips - https://careers.microsoft.com/v2/global/en/hiring-tips/technical-interviewing - https://careers.microsoft.com/v2/global/en/hiring-tips/interview-tips.html - Amazon Jobs — Software Development Interview Preparation - https://amazon.jobs/content/en/how-we-hire/interview-prep/software-development-topics - GitHub MCP Server - https://github.blog/changelog/2025-04-04-github-mcp-server-public-preview/ - https://github.blog/ai-and-ml/generative-ai/a-practical-guide-on-how-to-use-the-github-mcp-server/ - LangGraph - https://docs.langchain.com/oss/python/langgraph/workflows-agents - https://docs.langchain.com/oss/python/langchain/multi-agent - OpenAI Agents SDK - https://developers.openai.com/api/docs/guides/agents - https://developers.openai.com/api/docs/guides/agents/orchestration