취업 준비를 시작한 대학생 개발자라면 한 번쯤 이런 고민을 한다. “포트폴리오를 만들고 싶은데, 혼자 만든 토이 프로젝트로 충분할까?” 인턴 경험이 없고, 실무 레퍼런스도 부족한 시점에 가장 현실적인 돌파구가 바로 공모전이다. 공모전은 단순히 수상 실적을 채우는 이벤트가 아니다. 팀을 꾸리고, 기획부터 구현까지 일정 안에 완성하고, 심사라는 외부 검증을 통과하는 전 과정이 실무와 구조적으로 닮아 있다. 신입 개발자에게 남은 가장 강력한 무대라고 불리는 이유가 여기에 있다.
왜 공모전이 포트폴리오에서 특별한가
면접관이 포트폴리오를 볼 때 가장 먼저 확인하는 것은 “이 사람이 실제 문제를 풀어본 경험이 있는가”다. 혼자 만든 클론 코딩이나 튜토리얼 프로젝트는 기술 스택을 익혔다는 신호는 줄 수 있지만, 협업·기획·일정 관리 능력까지는 보여주기 어렵다. 반면 공모전 수료·입상 프로젝트는 외부 기준을 통과한 결과물이라는 점에서 신뢰도가 다르다.
특히 정부·공공기관·대기업이 주최하는 공모전은 출제자가 실제 산업 현장의 문제를 과제로 제시하는 경우가 많다. 데이터 분석, 앱 개발, AI 모델 구현 등 주제는 다양하지만 공통적으로 “현실 데이터를 다루거나 실사용자를 가정한 요구사항”을 담는다. 이런 경험은 면접에서 “실무와 가장 가까운 프로젝트”로 설명하기에 충분한 근거가 된다.
수상 여부만 중요한 것도 아니다. 본선 진출, 멘토링 참여, 제출 자체가 이력서에 서술할 수 있는 경험이다. “○○ 공모전 본선 진출, ○○ 기능 구현 담당”처럼 구체적으로 쓸 수 있는 단위 경험이 쌓이는 것이다.
어떤 공모전을 골라야 하는가
공모전은 많지만 취업 포트폴리오에 실질적으로 도움이 되는 것과 그렇지 않은 것이 구분된다. 고르는 기준을 몇 가지로 정리하면 다음과 같다.
- 주최 기관의 공신력: 정부부처, 공공기관, 대기업, 주요 IT 기업이 주최하는 공모전은 이력서에 올렸을 때 면접관이 맥락을 파악하기 쉽다. 출처가 불분명한 소규모 공모전은 설명 비용이 높아진다.
- 과제의 구체성: “AI로 무엇이든 만들어라”처럼 범위가 너무 넓은 과제보다 “○○ 공공 데이터를 활용해 ○○ 문제를 해결하는 서비스를 개발하라”처럼 요구사항이 명확한 대회가 포트폴리오 서술에 유리하다.
- 팀 구성 가능 여부: 개발자 단독 참가보다 기획·디자인·개발이 섞인 팀 구성을 권장하는 대회가 많다. 협업 경험을 증명하고 싶다면 이쪽이 유리하다.
- 결과물의 공개 가능 여부: 제출 후 GitHub에 올리거나 데모 링크를 공유할 수 있는 대회라면 포트폴리오 활용도가 높다. 보안상 공개가 제한된 대회라면 면접에서 설명 준비를 별도로 해야 한다.
대표적으로 많이 언급되는 대회로는 공공 빅데이터를 활용한 데이터 분석 공모전, 각 지자체나 중앙부처의 앱·서비스 개발 공모전, 대기업 계열사의 해커톤, 대학 연합 해커톤 등이 있다. 직접 검색하거나 학교 커리어센터, 개발 커뮤니티 공지를 주기적으로 확인하는 것이 현실적인 방법이다.
참가 전에 준비해야 할 것들
공모전에 “그냥 신청해서 해보자”는 접근은 결과물의 완성도와 경험의 밀도 모두를 낮춘다. 참가 전에 아래 항목을 점검하면 훨씬 효율적으로 움직일 수 있다.
- 역할 분담 확인: 팀원 각자가 무엇을 담당하는지 첫 미팅에서 명시적으로 정한다. “개발은 내가 다 한다”는 구조로 시작하면 후반부에 반드시 병목이 생긴다.
- 기술 스택 합의: 팀원이 모두 익숙한 스택으로 시작하는 것이 원칙이다. 공모전은 새 기술을 배우는 자리가 아니라 팀이 이미 가진 역량을 빠르게 조합하는 자리다.
- 일정 역산 계획: 제출 마감일부터 역산해서 기획, 설계, 구현, 테스트, 발표 준비 각각의 기한을 정한다. 최소 제출 2~3일 전에 기능 구현을 완료해야 한다. 마지막 날 밤샘으로 완성하는 구조는 결과물의 완성도를 크게 낮춘다.
- 심사 기준 분석: 대부분의 공모전은 심사 항목과 배점을 공고에 공개한다. 기술 완성도에 30%, 사회적 가치나 창의성에 30%, 발표력에 40%를 두는 대회라면 발표 준비가 기술만큼 중요하다는 뜻이다.
GitHub 레포지토리는 참가 시작일부터 열어두는 것을 권한다. 커밋 히스토리 자체가 작업 과정을 보여주는 증거가 된다. 제출 직전에 한꺼번에 올린 레포는 면접에서 신뢰도가 낮다.
수상보다 중요한 것: 경험을 기록하는 방법
공모전에서 수상하면 물론 좋다. 하지만 탈락하거나 본선 진출에 그쳤다고 해서 포트폴리오 활용 가치가 사라지는 것은 아니다. 오히려 수상하지 못한 경험을 어떻게 기록하고 설명하느냐가 성숙도를 보여주는 지점이 된다.
공모전이 끝난 직후 아래 세 가지를 문서로 정리하는 것을 권한다. 시간이 지나면 기억이 흐려지고, 구체적인 숫자와 상황이 사라진다.
- 내가 실제로 구현한 기능 목록: “백엔드 개발”이 아니라 “사용자 인증 API 구현, JWT 기반 세션 관리, 쿼리 최적화로 응답 속도 개선” 수준으로 구체화한다.
- 기술적 의사결정 기록: 왜 이 기술을 선택했는가, 어떤 문제를 만났고 어떻게 해결했는가를 짧게라도 기록한다. 면접에서 “이 기술을 선택한 이유가 무엇인가”라는 질문에 곧바로 답할 수 있는 원천이 된다.
- 팀 내 역할과 협업 방식: Git 브랜치 전략, 코드 리뷰 진행 여부, 일정 관리 도구 사용 여부 등을 기록한다. 협업 경험을 묻는 질문에 구체적인 사례로 답할 수 있다.
이 기록들은 이력서의 프로젝트 항목을 채우는 데 직접 활용할 수 있다. 나중에 “뭘 했더라”를 검색하며 시간을 쓰는 대신, 이미 정리된 문서에서 필요한 표현을 꺼내 쓰는 구조가 훨씬 효율적이다.
공모전 경험을 면접에서 설명하는 방법
공모전 프로젝트를 면접에서 설명할 때 자주 나오는 실수가 있다. 프로젝트의 배경과 전체 구조를 설명하는 데 시간을 너무 쓰고, 정작 “내가 무엇을 했는가”는 짧게 끝내는 경우다. 면접관이 궁금한 것은 프로젝트의 완성도보다 지원자 본인의 기여와 사고방식이다.
효과적인 설명 구조는 다음 흐름을 따른다. 첫째, 과제의 핵심 문제를 한 문장으로 정의한다. 둘째, 팀 내 내 역할과 담당 범위를 명확히 말한다. 셋째, 기술적으로 가장 도전적이었던 부분과 해결 방법을 구체적으로 설명한다. 넷째, 결과 또는 배운 점으로 마무리한다. 이 흐름을 2~3분 안에 전달할 수 있도록 미리 연습하는 것이 좋다.
수상을 못 했을 때는 오히려 “아쉬웠던 점과 개선 방향”을 솔직하게 말하는 것이 좋은 인상을 남긴다. “○○ 기능을 구현하려 했는데 시간이 부족해 제출하지 못했다. 이후 개인 레포에서 추가 구현했다”는 식의 설명은 주도성과 성장 의지를 동시에 보여준다.
지금 당장 시작하는 첫 단계
공모전을 처음 시도한다면 규모가 크고 경쟁이 치열한 대회보다, 출전 장벽이 낮고 결과물을 완성하기에 현실적인 일정을 가진 대회부터 시작하는 것이 낫다. 첫 참가의 목표는 수상이 아니라 “제출 완료”다. 제출 경험 자체가 다음 참가의 기준점이 된다.
팀을 꾸리기 어렵다면 학교 내 개발 동아리, 학과 단체 카톡방, 개발자 오픈 커뮤니티의 팀 모집 게시판을 활용한다. 공모전 공고에는 대개 권장 팀 구성 인원과 필요 역할이 명시돼 있어 필요한 포지션을 찾기도 수월하다.
공모전이 끝난 후에는 결과에 관계없이 GitHub에 정리된 레포를 남기고, 간단한 README로 프로젝트 개요와 본인 담당 파트를 기록해둔다. 이 레포 하나가 나중에 포트폴리오 사이트나 이력서에 링크로 들어가는 실질 자산이 된다.
대학생 개발자에게 공모전은 실무 경험의 공백을 채우는 가장 정직한 방법 중 하나다. 수상 실적보다는 경험의 밀도와 기록의 구체성이 결국 면접에서 빛을 발한다. 어느 대회에 도전할지, 팀은 어떻게 구성할지, 또는 이미 참가한 공모전 경험을 어떻게 이력서에 풀어낼지 막막하다면 누스쿨 커뮤니티에서 같은 고민을 가진 사람들과 이야기를 나눠보자. 실제 채용 경험이 있는 멘토에게 직접 피드백을 받는 것이 혼자 고민하는 시간을 줄이는 가장 빠른 방법이다.
💬 댓글 0