2026 당근 프론트엔드 인턴 포트폴리오, 안 만든 기능까지 보여주는 법

“이전 지표라든가 히스토리를 찾는 게 시간이 꽤 많이 걸리네요 ㅠㅠ”

프로젝트 기록을 다시 모으던 한 프론트엔드 개발자분이 보내온 말입니다. 포트폴리오를 만들 때 가장 오래 걸리는 일은 화면을 꾸미는 작업보다 당시 왜 그런 결정을 내렸는지 증명할 자료를 되찾는 일입니다.

당근 프론트엔드 인턴 포트폴리오도 같은 지점에서 갈립니다. 완성한 기능과 기술 스택만 나열하기보다 어떤 사용자 문제를 풀었고, 무엇을 만들지 않기로 했으며, 여러 선택지 중 왜 그 방법을 골랐는지 보여줘야 합니다.

2026년 9월 12일 확인한 당근 커뮤니티실 프론트엔드 인턴 공식 공고는 9월 13일 오후 11시 59분 마감 예정입니다. 이 글에서는 공고가 직접 요청한 내용을 실제 개발자 프로젝트에 적용해, 포트폴리오 첫 두 장으로 정리하는 과정을 보여드리겠습니다.

당근 공고는 완성한 기능보다 선택의 근거를 묻습니다

공고는 이력서나 포트폴리오에 다음 내용이 있으면 좋다고 안내합니다.

• 가장 중요하게 본 사용자 문제
• 문제를 풀기 위해 시도한 방법과 확인한 결과
• 팀의 비효율을 발견하고 개선한 경험
• 만들지 않은 기능과 그렇게 결정한 이유
• 중요한 기술이나 아키텍처를 선택한 기준
• 프로젝트에서 본인이 맡고 기여한 범위

이 목록은 프로젝트를 많이 넣으라는 뜻이 아닙니다. 한 프로젝트 안에서 문제와 선택, 실행과 결과가 이어지는지 보겠다는 뜻에 가깝습니다.

예를 들어 React, TypeScript, Vite 사용이라고 적으면 도구만 보입니다. 반면 운영 중인 서비스를 멈추지 않기 위해 전면 재개발을 포기하고 점진적 전환 구조를 설계했다고 적으면 제약과 판단이 함께 보입니다. 같은 프로젝트라도 두 번째 설명에서 지원자가 실제로 해결한 문제가 더 선명합니다.

기술 스택 세 줄을 포트폴리오 두 장으로 바꿨습니다

아래 사례를 고른 이유는 당근 공고가 직접 요구한 만들지 않은 기능과 그 이유가 선명하기 때문입니다. 완성한 기능보다 전면 재개발을 택하지 않은 판단이 프로젝트의 중심에 있습니다.

완료된 경력기술서에 담긴 프로젝트 하나를 당근 공고에 맞는 포트폴리오로 옮겨보겠습니다. 이 개발자분은 오래된 Vue 2 환경과 느린 빌드 과정 때문에 개발 속도가 떨어진 서비스를 맡았습니다.

처음 기록만 압축하면 다음과 같이 쓸 수 있습니다.

Vue 2 레거시 코드를 Vue 2.7 Bridge로 전환하고 Webpack을 Vite로, npm을 pnpm으로 바꿨습니다. 서비스 운영을 유지하며 마이그레이션을 마쳤고 빌드 속도를 개선했습니다.

성과와 기술은 있지만 프로젝트의 난도는 보이지 않습니다. 왜 최신 버전으로 한 번에 다시 만들지 않았는지, 여러 선택지 중 Bridge를 고른 이유가 무엇인지 알 수 없기 때문입니다.

이 기록을 포트폴리오로 옮기려면 문장을 다듬기 전에 다음 질문부터 풀어야 합니다.

1. 느린 빌드가 사용자와 개발팀에 어떤 문제를 만들었는가?
2. 전면 재개발과 점진적 전환을 어떤 기준으로 비교했는가?
3. 기존 코드와 새 코드가 어떻게 함께 동작하도록 만들었는가?
4. 공존 구조와 전환 순서 중 본인이 직접 결정한 범위는 어디까지인가?
5. 빌드 시간의 변화를 어떤 기준과 시점으로 확인했는가?

답은 경력기술서 한 문장에 모두 들어 있지 않습니다. 코드 저장소와 회의 기록, 빌드 로그에 흩어진 사실을 모아야 프로젝트의 제약과 선택, 기여와 결과가 연결됩니다.

첫 장에서는 이 판단이 만든 결과부터 보여줍니다. 빌드 시간은 기존의 절반 이하, 서비스 운영 유지, 점진적 전환을 상단에 배치하고, 아래에는 기존 환경에서 새로운 개발 흐름으로 넘어간 구조와 본인의 기여를 연결했습니다.

첫 장에서 결과와 전체 구조를 보여주면 읽는 사람은 프로젝트의 난도와 기여 범위를 바로 파악할 수 있습니다.

두 번째 장에서는 왜 그렇게 했는가에 답합니다. 전면 재개발과 점진적 전환을 비교하고, 선택 기준과 실행 순서, 결과를 한 화면에 묶었습니다. 기술명만 보이던 기록이 제약 속에서 더 나은 방법을 고른 의사결정 사례로 바뀝니다.

실제 개발자 프로젝트를 바탕으로 만든 포트폴리오 구성 예시입니다.

첫 장은 결과, 두 번째 장은 판단을 보여주세요

프로젝트의 모든 내용을 한 화면에 넣으면 무엇을 봐야 하는지 알기 어렵습니다. 두 장의 역할을 나누면 시선의 흐름이 선명해집니다.

• 첫 장: 해결한 문제, 대표 성과, 전환 구조, 본인의 핵심 기여
• 두 번째 장: 검토한 대안, 채택하지 않은 이유, 단계별 실행, 결과의 근거

첫 장의 목적은 프로젝트 전체를 설명하는 것이 아니라 읽는 사람이 왜 이 결정을 더 알고 싶은지 판단하게 만드는 것입니다. 두 번째 장에서는 그 관심을 선택의 근거로 이어가세요. 빌드 기록이나 마이그레이션 계획표가 남아 있다면 결과 옆에 작은 증거로 붙이고, 세부 코드는 다음 장에서 보여주면 됩니다.

‘안 만든 기능’은 포기한 목록이 아니라 우선순위의 증거입니다

공고에서 눈에 띄는 대목은 무엇을 만들었는지만큼 무엇을 만들지 않았고 왜 그랬는지도 적어달라는 요청입니다. 지원자에게 불리한 질문처럼 보이지만, 실제로는 제품 판단을 보여주기 좋은 항목입니다.

다음 네 문장으로 정리해보세요.

검토한 선택은 전면 재개발이었습니다.
채택하지 않은 이유는 운영 중인 서비스의 변경 범위와 배포 위험이 너무 컸기 때문입니다.
대신 기존 코드와 새 코드가 함께 동작하는 점진적 전환을 택했습니다.
그 결과 운영을 유지하면서 빌드 시간을 절반 이하로 줄였습니다.

여기서 중요한 것은 ‘시간이 없어서 못 했다’는 변명이 아닙니다. 당시의 사용자 영향, 개발 비용, 운영 위험과 검증 결과를 비교해 우선순위를 정했다는 사실입니다.

개인 프로젝트라면 검색, 알림, 채팅처럼 넣고 싶었던 기능 중 하나를 떠올려보세요. 왜 제외했는지 근거가 없다면 단순 미완성에 가깝습니다. 반대로 사용자 인터뷰에서 우선순위가 낮았거나, 핵심 가설을 검증하는 데 필요하지 않았거나, 개인정보 위험이 더 컸다는 근거가 있다면 하나의 제품 결정이 됩니다.

커뮤니티실 포트폴리오는 사용자와 시스템을 함께 보여줘야 합니다

이번 포지션이 속한 커뮤니티실은 당근카페와 당근아파트 등 이웃이 관심사와 생활권을 중심으로 연결되는 서비스를 만들고 있습니다. 공고는 사용자 목소리를 바탕으로 빠르게 개선하는 일과 여러 기능의 기반이 되는 컴포넌트와 프레임워크, 시스템 문제를 함께 다룹니다.

그래서 프로젝트를 고를 때도 화려한 화면만 볼 필요는 없습니다. 다음 우선순위로 살펴보면 됩니다.

• 사용자의 반복되는 불편을 발견하고 제품을 처음부터 만든 경험
• 사용자 반응이나 지표를 보고 기능을 바꾼 경험
• 공통 컴포넌트나 개발 환경을 개선해 팀의 실험 속도를 높인 경험
• 운영 장애나 성능 문제를 찾아 안정성을 높인 경험

인프라 개선 프로젝트를 넣는다면 기술적 성과에서 멈추지 마세요. 빌드가 빨라져 수정 사항을 더 자주 확인할 수 있었는지, 공통 컴포넌트 덕분에 새 화면의 일관성을 지켰는지처럼 사용자에게 도달하는 과정이 무엇이 달라졌는지까지 이어야 합니다.

반대로 사용자 프로젝트를 넣더라도 예쁜 화면만 보여주면 부족합니다. 어떤 목소리를 들었고, 그중 무엇을 문제로 정의했으며, 기능을 낸 뒤 어떤 반응을 확인했는지 적어야 합니다. 당근이 공고에서 요구한 사용자 문제와 시스템 개선이 이 지점에서 연결됩니다.

React와 TypeScript는 사용한 장면으로 증명하세요

공고의 지원 자격에는 React 기반 SSR과 JavaScript 또는 TypeScript 개발 경험이 들어 있습니다. 우대 경험에는 제품을 처음부터 만든 경험, 웹뷰, 실험과 지표 분석 등이 포함됩니다. 해당 키워드가 있다면 기술 목록에 한 번 더 넣기보다 프로젝트 본문에서 사용한 장면을 보여주세요.

• React SSR: 왜 서버 렌더링이 필요했는지, 데이터 요청과 캐시를 어떻게 나눴는지, 초기 화면이나 검색 노출에서 무엇이 달라졌는지
• TypeScript: 어떤 잘못된 상태를 타입으로 막았는지, API 계약이나 공통 컴포넌트의 변경을 어떻게 안전하게 관리했는지
• 실험과 지표: 어떤 가설을 세웠고, 무엇을 측정했으며, 결과를 보고 어떤 기능을 유지하거나 버렸는지
• 웹뷰: 웹과 앱의 책임을 어떻게 나눴고, 뒤로 가기나 인증처럼 경계에서 생긴 문제를 어떻게 해결했는지

공고는 Claude Code나 Codex 같은 AI 도구를 활용하는 개발 방식도 언급합니다. AI를 사용했다면 생성한 코드의 양보다 어디까지 맡겼고 무엇을 직접 검증했는지를 적으세요. 예를 들어 반복 테스트 작성은 도구에 맡기되 상태 전이와 예외 조건은 직접 정의했다는 식입니다. 그래야 AI 사용이 도구 자랑이 아니라 개발 판단으로 읽힙니다.

500자 사전 질문은 포트폴리오의 판단을 압축해 쓰세요

당근은 공고의 사전 질문마다 500자 이내로 본인의 생각을 적도록 안내합니다. 포트폴리오와 사전 질문을 별개의 글처럼 만들면 같은 프로젝트도 중심이 달라질 수 있습니다. 먼저 핵심 프로젝트의 첫 두 장을 완성한 다음, 그 판단을 다섯 문장으로 줄이는 편이 자연스럽습니다.

1. 어떤 문제를 발견했는지 한 문장
2. 왜 그 문제가 중요했는지 한 문장
3. 비교한 선택지와 결정 이유를 두 문장
4. 직접 한 일과 결과를 한 문장

위 마이그레이션 사례라면 다음처럼 시작할 수 있습니다.

운영 중인 서비스의 오래된 Vue 2 환경이 신규 기능 개발과 빌드를 늦추고 있었습니다. 전면 재개발도 검토했지만 변경 범위가 커 배포 위험이 높다고 판단했습니다. 그래서 Vue 2.7 Bridge로 기존 코드와 새 코드가 공존하는 기간을 만들고 신규 기능부터 순차적으로 옮겼습니다. Webpack과 npm 환경도 Vite와 pnpm으로 바꿨습니다. 서비스 운영을 유지하며 전환을 마쳤고 빌드 시간은 기존의 절반 이하로 줄였습니다.

위 포트폴리오의 판단을 500자 안으로 옮긴 예시입니다. 자신의 역할과 표현에 맞게 다시 써야 합니다.

문장을 매끄럽게 다듬는 것보다 본인이 왜 그렇게 판단했는지 설명할 수 있는지가 먼저입니다. 공고에서도 다른 사람이나 AI가 정리한 말보다 본인의 생각을 직접 적어달라고 안내합니다.

가장 자신 있는 프로젝트 하나로 먼저 진단해보세요

포트폴리오를 열기 전에 아래 질문에 소리 내어 답해보세요.

1. 사용하거나 운영하던 사람이 겪은 문제를 한 문장으로 설명할 수 있는가?
2. 채택한 방법과 버린 방법을 비교하고, 선택 기준을 말할 수 있는가?
3. 팀의 성과와 본인이 직접 내린 결정 및 구현 범위를 구분할 수 있는가?
4. 결과 수치의 기준과 측정 시점, 근거 자료를 바로 찾을 수 있는가?
5. React, TypeScript, SSR과 AI 도구를 실제 사용한 장면으로 설명할 수 있는가?
6. 같은 판단이 포트폴리오와 500자 사전 질문에서 일관되게 보이는가?

여기서 막힌다면 화면 디자인보다 먼저 경험과 근거를 정리해야 합니다. 특히 다음과 같은 경우에는 프로젝트를 고르는 일부터 시간이 오래 걸립니다.

• 프로젝트가 여러 개라 무엇을 첫 장에 놓을지 결정하기 어렵다.
• 팀 성과는 있지만 본인의 기여를 어디까지 써야 할지 모호하다.
• 당시 지표와 선택 이유가 코드 저장소, 문서와 대화에 흩어져 있다.
• React SSR 프로젝트와 기술 판단이 강한 다른 프로젝트의 순서를 정하기 어렵다.
• 포트폴리오와 사전 질문을 각각 쓰다 보니 강조하는 역량이 달라졌다.

포트폴리오 기획과 컨설팅 과정에서는 지원 공고와 현재 자료를 먼저 대조합니다. 이어서 인터뷰로 당시의 판단과 역할을 확인하고, 팀의 결과와 본인의 기여를 나눈 뒤 첫 두 장의 순서와 500자 답변의 중심을 맞춥니다. 완성된 포트폴리오가 없어도 지원 공고와 프로젝트 목록부터 검토할 수 있습니다.

이력서의 프로젝트 설명도 함께 고쳐야 한다면 경력기술서 쓰는 법에서 배경과 접근, 성과를 정리하는 순서를 볼 수 있습니다. 당근의 제품과 일하는 방식을 지원서에 연결하는 방법은 당근 PM 인턴 지원서 작성법에서 이어집니다.

당근 프론트엔드 인턴 포트폴리오의 핵심은 기능을 많이 보여주는 데 있지 않습니다. 무엇을 만들었는지와 무엇을 만들지 않았는지, 두 결정에 같은 기준이 흐르게 만드는 것입니다. 그 기준이 보이면 기술 스택도 결과 수치도 지원자의 판단을 증명하는 근거가 됩니다.