일정 기간 동안 월급을 받으며 업무를 수행하는 형태입니다. "6개월간 우리 개발팀에서 백엔드 개발을 맡아주세요"같은 의뢰죠. 대부분 클라이언트 사무실에 출근하기 때문에 '상주'라고도 부르지만, 요즘은 재택근무도 있습니다. 여기서는 "Java와 Spring Boot를 5년간 다뤄봤습니다"같은 기술 경험을 증명하는 경력기술서가 핵심입니다.

즉 내가 어떤 형태의 프리랜서 활동을 하고자 하는지에 따라 준비해야 할 것이 달라지는 것입니다. 도급 시장과 달리 기간제, 상주 프로젝트는 일반적인 채용 시장과 닮아 있습니다.

그럼 이제, 각각의 상황에서 클라이언트의 마음을 사로잡을 수 있는 구체적인 작성 전략을 포트폴리오, 경력기술서 순으로 알아보겠습니다.

포트폴리오에 대한 흔한 착각 2가지

먼저, 프리랜서 개발자의 포트폴리오에 관해 정말 많은 분들이 착각하시는 것 두 가지를 살펴보겠습니다.

“어려운 기술을 많이 쓰면 실력 있어 보이겠지?”

많은 분들께서 기술적 역량을 보여주기 위해 포트폴리오에 어려운 기술의 이름을 많이 나열해두고는 하시는데요. 하지만 기술의 난이도를 구분하지 못하는 클라이언트도 많습니다. 예를 들어, 라이브 커머스를 만들고 싶은데 개발 지식이 없어서 외주를 맡기는 고객에게 '로드 밸런싱 적용'이라는 문구는 아무런 감흥을 주지 못할 수도 있습니다. 중요한 것은 그 기술을 ‘왜’ 사용했는지 맥락을 설명하는 것입니다. 비전문가도 이해할 수 있는 쉬운 설명과, 전문가를 위한 기술적 설명을 함께 담는 것이 가장 좋습니다.

“유명 대기업 프로젝트를 보여주면 무조건 통하겠지?”

또 지원하고자 하는 프로젝트와 관련이 없는 내용이라 하더라도 유명 대기업 프로젝트를 포트폴리오에 전부 나열하는 분들도 많습니다. 하지만아무리 크고 대단한 고객사와의 프로젝트 경험이라도, 현재 의뢰한 프로젝트와 관련이 없다면 매력도는 떨어집니다. 클라이언트는 결국 ‘나의 문제’를 해결해 줄 수 있는 포트폴리오를 원하기 때문입니다. 여러 포트폴리오 중 현재 프로젝트와 가장 유사한 핵심 프로세스를 가진 포트폴리오를 선별하여 먼저 제시하는 것이 훨씬 효과적입니다.

그렇다면, 포트폴리오를 어떻게 작성해야 할까요? 네 가지 전략으로 정리해봤습니다.

매력적인 프리랜서 개발자 포트폴리오 만드는 4가지 방법

첫째, 기능 나열이 아닌 ‘문제 해결’ 과정을 보여라

많은 개발자가 포트폴리오를 작성할 때 가장 흔히 하는 실수가 있습니다. "청소 매칭 플랫폼을 개발했습니다. React와 Node.js를 사용했고, 결제 기능과 예약 시스템을 구현했습니다." 이런 식으로 기능만 나열하는 것이죠.

하지만 클라이언트가 정말 알고 싶은 건 다릅니다. "이 개발자가 우리와 비슷한 상황을 겪은 고객의 문제를 해결해본 적이 있는가?"입니다.

왜 이 프로젝트가 시작됐는지
당시 고객사는 어떤 문제를 겪고 있었는지
이를 해결하기 위해 어떤 접근과 방법론을 적용했는지

이런 부분이 클라이언트가 정말 궁금해하는 부분입니다. 즉, 즉, 단순한 기능 나열이 아니라 문제 → 목표 → 해결 과정 → 성과의 구조로 풀어내되 그 과정에서 어떤 기능을 어떻게 적용했는가가 포함되어야 매력적인 포트폴리오가 됩니다.

위시켓에서는 효과적인 포트폴리오 작성을 돕기 위해 ‘포트폴리오 플러스’ 기능을 만들기도 했습니다. 포트폴리오를 입력할 때 자동으로 문제 해결 과정을 입력할 수 있는 항목이 만들어집니다. 이에 맞춰 작성한 포트폴리오는 클라이언트가 원하는 정보를 담게 됩니다. <출처: 위시켓>

➡️'포트폴리오 플러스'로 작성된 포트폴리오 살펴보기

둘째, 기술을 말할 땐 ‘비즈니스적 맥락’을 강조하라

또 많은 분들이 포트폴리오에서 기술적 난이도를 강조하고는 합니다. 하지만 프로젝트를 발주하는 기업 입장에서 중요한 건 “내 문제를 해결해줄 수 있는 사람인가”입니다. 기술적 난이도를 강조하는 것보다, 프로젝트 배경과 비즈니스적 목적을 서술하는 편이 훨씬 설득력이 있습니다.

특히 기술적 배경이 없는 클라이언트에게는 전문 용어가 와닿지 않습니다. 예를 들어 “쿠버네티스 환경에 분산 처리 적용” 같은 전문 용어는 일부 클라이언트에겐 와닿지 않습니다. 중요한 것은 그 기술을 사용한 이유입니다. “트래픽 급증 상황에서도 안정적인 서비스를 유지하기 위해 분산 처리를 적용했다”처럼 맥락과 의미를 풀어주는 것이 효과적입니다

셋째, 프로젝트 성격에 따라 전략을 달리하라

포트폴리오는 모든 프로젝트를 동일한 방식으로 나열하는 것보다, 프로젝트의 성격에 따라 강조점을 달리할 때 훨씬 더 효과적입니다. 기획 단계부터 시작하는 프로젝트인지, 개발에만 집중하는 프로젝트인지에 따라 포트폴리오 전략을 달리 해야 합니다.

기획부터 참여한 프로젝트라면? → '왜', '무엇을' 만들었는지 스토리를 강조하라

기획 단계부터 프로젝트에 참여했다면, 단순히 어떤 기능을 만들었는지를 넘어 이 프로젝트가 왜 시작되었고, 무엇을 해결하고자 했는지에 대한 깊이 있는 이야기를 전달해야 합니다.

프로젝트의 배경과 목표를 명확히 하기: 포트폴리오에 프로젝트의 배경과 달성하고자 했던 목표를 구체적으로 서술하면, 클라이언트가 겪는 문제와 유사한 상황을 해결해 본 경험이 있음을 보여줄 수 있습니다. 기획부터 참여한 경우, 이 배경과 목표를 훨씬 더 설득력 있게 설명할 수 있습니다.
소통 과정을 어필하라: 클라이언트와 어떻게 소통하여 기획서를 만들고 과업 범위를 합의했는지 과정을 보여주는 것이 좋습니다. 이는 단순 개발 역량뿐만 아니라, 클라이언트의 비전을 구체화하는 문제 해결 능력을 갖추었음을 증명하는 강력한 무기가 됩니다.

개발만 진행한 프로젝트라면?→ '어떻게' 잘 만들었는지 기술적 역량을 증명하라

이미 기획이 완료된 프로젝트에 개발로만 참여했다면, 포트폴리오의 초점은 '어떻게' 잘 만들었는지에 맞춰져야 합니다.

적용된 개발 방법론을 구체적으로 서술하라: 주어진 기능이 원활하게 작동하도록 어떤 개발 방법론을 적용했는지 설명하는 것이 효과적입니다. 예를 들어, MSA 형태로 서버를 구성했거나, CI/CD를 적용한 경험, 또는 서비스 성능을 높이기 위해 분산 처리를 사용한 경험 등을 구체적으로 명시할 수 있습니다.
독자를 고려한 이중 설명 방식을 활용하라: 기술적인 내용을 설명할 때는 개발을 잘 모르는 사람도 이해할 수 있는 쉬운 설명과, 전문가가 봤을 때 의미 있는 기술적 설명을 함께 구성하는 것이 가장 좋습니다. 이를 통해 비전문가인 의사결정권자와 전문가인 실무 담당자 모두를 설득할 수 있습니다.

넷째, 이미지 구성도 전략이다

마지막으로, 이미지도 신경 써야 할 부분입니다. 포트폴리오에서 이미지는 단순한 장식이 아닙니다. 메인 화면 하나만 덩그러니 올려놓으면 클라이언트는 서비스의 전체 그림을 상상하기 어렵습니다. 아래와 같은 전략으로 이미지를 구성하는 것이 클라이언트에게 도움이 됩니다.

효과적인 이미지 구성 전략

서비스의 핵심 사용 흐름을 단계별로 보여주기
사용자별 화면 구성 (예: 고객용 앱 / 관리자 대시보드)
주요 기능이 작동하는 모습
Before & After (개선 프로젝트의 경우)

초보를 위한 Tip
포트폴리오의 핵심은 ‘자기 자랑’이 아닌 ‘고객 문제 해결 스토리’입니다. 내가 사용한 기술이나 화려한 기능 목록을 나열하는 대신, 클라이언트가 어떤 고민을 가지고 있었고, 그 문제를 해결하기 위해 당신이 어떤 과정을 거쳤는지에 집중하세요. 이 스토리텔링이 당신을 대체 불가능한 ‘문제 해결 전문가’로 만들어 줄 것입니다.

시장에서 통하는 경력기술서 작성법

지금까지 도급 프로젝트에서 중요한 포트폴리오 작성법을 알아봤는데요. 이제 기간제, 상주 프로젝트에 지원할 때 작성하는 경력기술서 작성법에 대해 이야기해보겠습니다.

포트폴리오에서도 각 클라이언트나 상황에 맞는 작성 전략을 소개했었죠. 경력기술서에서도 모든 프로젝트에 통하는 '만능 경력기술서'는 존재하지 않습니다.

자신이 주로 활동하고 싶은 시장이 어디인지에 따라 경력기술서의 전략은 완전히 달라져야 합니다. 또 자신의 경력 연차별로, 산업 도메인별로도 경력기술서의 전략에서 신경 써야 할 요소들이 달라집니다.

타깃 시장별 경력기술서 전략

먼저 타깃 시장별 경력기술서 전략을 살펴보겠습니다. 시장은 크게 두 가지로 나뉩니다. 안정성을 중시하는 대기업 SI(System Integration) 시장과, 성과와 잠재력을 중시하는 스타트업·중소기업 시장입니다.

1. 대기업 SI 시장: 정형화된 ‘팩트’ 중심의 기술서

금융, 공공, 통신, 제조 등 대기업 SI 프로젝트 시장은 경력기술서에 대한 ‘암묵적인 표준(Standard)’이 존재합니다. 이력서를 검토하는 담당자들이 수많은 지원자를 빠르게 평가하기 위해 정형화된 포맷을 선호하기 때문이죠.

핵심 요소: 프로젝트명, 참여 기간, 고객사, 역할, 수행 업무, 사용 기술
가장 중요한 것: 산업 분야 경험 (Domain Experience)

위와 같은 정형화된 형식이 SI 시장의 표준입니다. 여기서는 무엇을 했는지가 중요하지, 왜 했는지는 크게 중요하지 않습니다.

이 시장의 가장 큰 특징은 특정 산업 경험을 매우 중요하게 여긴다는 점입니다. 예를 들어, 은행권 프로젝트는 은행권 경험이 있는 개발자를 최우선으로 찾습니다. ‘최근 5년 내 은행 프로젝트 경험 3년 이상’과 같이 매우 구체적인 조건을 제시하기도 합니다.

따라서 대기업 SI 시장을 목표로 한다면, 자신이 전문성을 가진 산업 분야(금융, 제조, 의료, 공공 등)를 명확히 하고 관련 프로젝트 경험을 집중적으로 부각해야 합니다.

2. 스타트업/중소기업용 경력기술서

반면 스타트업/중소기업에 지원하기 위한 경력 기술서는 다릅니다. 이런 곳에서는 정형화된 양식보다 개발자의 문제 해결 능력과 프로젝트에 대한 기여도를 비중 있게 봅니다.

문제 인식: 이 프로젝트에서 어떤 문제를 해결하려 했는가?
나의 역할과 기여: 문제 해결을 위해 구체적으로 어떤 역할을 했고, 얼마나 기여했는가?
결과 및 성과: 나의 활동을 통해 어떤 긍정적인 결과가 있었는가? (예: 트래픽 처리 용량 증대, 응답 속도 개선 등)

위와 같은 요소를 경력 기술서에 담아야 합니다. 이때 쓰는 경력기술서는 채용 사이트에서 제공하는 일반적인 이력서와도 비슷합니다.

연차별 경력기술서 전략

그런데 타깃 시장과 관계 없이 경력이 쌓일수록 중요한 경험이 있습니다. 이것이 경력기술서에 드러나야 하죠. 바로 '설계 경험'입니다. 이전 글 <프리랜서 개발자, 어떤 기술을 배워야 돈이 될까?>에서도 살펴 봤듯이 경력이 쌓일수록 급여를 높이고 경쟁력을 갖추기 위해 가장 중요한 요소죠.

DB 설계, 인프라 설계 등 아키텍처 설계 경험은 개발자의 등급을 나누는 핵심적인 척도입니다. 중급(5~9년 차) 개발자부터는 설계 역량을 쌓고 이를 경력기술서에 반드시 포함시켜야 고급 개발자로 성장할 수 있습니다

산업 도메인별 경력기술서 전략

기간제/상주 프로젝트를 할 때는 산업 도메인이 중요한 요소가 됩니다. 특정 산업 도메인에서 활동하고자 한다면 관련한 프로젝트를 꾸준히 하면서 경력을 잘 관리해야 합니다. 이전 글에서도 살펴봤듯이, 위시켓 데이터에 따르면 산업 도메인별로도 개발자의 급여 차이가 명확한데요. 급여 뿐 아니라 그런 프로젝트들은 관련 경력을 꼼꼼하게 요구하는 경우가 있어 경력 기술서를 작성할 때 그런 부분에 유념해야 합니다.

전문성이 특히 요구되는 산업 분야

특히 아래와 같은 분야는 해당 산업의 도메인 지식이 없으면 프로젝트 진입 자체가 어려운 경우가 많습니다. 중급 이상으로 성장하며 높은 몸값을 받기 위해서는 이 중 자신의 전문 분야를 명확히 정하는 전략이 필요합니다.

진입 장벽이 매우 높은 분야:금융, 보험, 제조, 물류, 유통, 의료, 공공, 통신, 방산 등은 관련 프로젝트 경험을 필수적으로 요구하는 경우가 많습니다.
특정 기업 경험이 필요한 경우: 삼성, 하이닉스와 같은 특정 대기업의 제조 프로젝트는 해당 기업의 프로젝트 유경험자를 선호하는 경향이 뚜렷합니다.
세부 카테고리: 때로는 같은 금융권이라도 ‘은행’과 ‘카드사’ 경험을 구분해서 요구하는 등, 프로젝트에 따라 훨씬 더 디테일한 경험을 요구하기도 합니다.

세부 카테고리 예시
금융·보험: 은행, 카드, 보험사별로 프로젝트 경험을 세분화해 요구
의료: 개인정보·보안 이슈가 크고, 의료 시스템 특성 이해가 필수
제조·반도체: 삼성, 하이닉스 등 개별 기업 경험 여부를 따지는 경우 많음
통신·방산·공공: 산업 이해도가 없으면 아예 투입 자체가 어려움

이런 특수성이 요구되는 분야에서 경력기술서를 작성할 때는 단순히 “금융권 프로젝트 참여”라고 적는 게 아니라, “○○은행 차세대 시스템 프로젝트 참여 (3년) – 계정 관리 모듈 개발 및 보안 아키텍처 설계”처럼 산업별 특수성과 기여도를 구체적으로 서술해야 합니다.

SI와 SM: 명확히 구분하여 표기하기

마지막으로, 이 부분은 많은 개발자가 놓치는 부분입니다. SI(System Integration)와 SM(System Maintenance)은 시장에서 다르게 평가됩니다.

SI 경험: 새로운 시스템 구축, 평균 단가 50만원 높음
SM 경험: 안정적 운영 능력, 장기 프로젝트 선호 시 유리

둘 다 경험이 있다면 반드시 구분해서 표기해야 합니다.

마치며

포트폴리오와 경력기술서는 단순한 이력 나열이 아닙니다. 클라이언트에게 "이 사람이 우리 문제를 해결해줄 수 있다"는 확신을 주는 마케팅 도구입니다.

위시켓에서 가장 많은 계약을 성사시키는 파트너들의 공통점은 명확합니다. 그들은 자신이 해결한 문제와 그 과정을 스토리로 풀어내고, 클라이언트가 찾는 바로 그 경험을 보여줍니다.

기술력은 기본입니다. 하지만 그것을 어떻게 전달하는지가 프리랜서 시장에서의 성공을 좌우합니다.

위시켓에서는 10만 명 이상의 개발자가 활동하고 있습니다. 이 글에서는 그간의 많은 데이터를 기반으로 포트폴리오, 경력기술서 작성법을 알려드렸는데요. 참고하셔서 성공적인 커리어 이어나가시길 응원하겠습니다.

실전 체크리스트

포트폴리오 체크리스트

□ 프로젝트 배경과 문제 상황을 명확히 설명했는가?

□ 해결 과정과 나의 기여도가 구체적으로 드러나는가?

□ 이미지가 서비스의 핵심 흐름을 보여주는가?

□ 기술 용어와 일반 설명의 균형이 맞는가?

□ 타깃 클라이언트와 유사한 프로젝트를 선별했는가?

경력기술서 체크리스트

□ 타겟 시장(SI/스타트업)에 맞는 형식인가?

□ 설계 경험이 있다면 빠짐없이 포함했는가?

□ 산업 도메인이 명확하게 드러나는가?

□ SI/SM 구분이 되어 있는가?

□ 연차에 맞는 역량이 표현되었는가?

프리랜서 개발자가 처음이라면? 요즘IT에서 이 글을 읽어보세요