자기소개서와 포트폴리오 쓰는 법

자기소개서는 무엇을 보여 주나

자기소개서는 「나는 어떤 사람이다」를 선언하는 문서가 아니다. 「이런 상황에서 이렇게 행동했고, 그래서 이렇게 됐다」를 보여 주고, 읽는 사람이 「이 사람과 일하면 이렇겠구나」를 스스로 결론 내리게 하는 문서다.

대신	이렇게
내면을 정의: 「저는 친화력이 좋습니다」, 「공감을 잘합니다」	행동을 묘사: 「이야기를 끝까지 듣고 요약해서 되묻습니다」
정보 나열: 성격, 경험, 기술을 두서없이	한 가지 특성을 붙잡고 깊게 판다
자기중심: 「좋은 개발자가 되고 싶어 지원했다」	상대 중심: 「회사가 이런 사람을 찾는데, 내가 마침 그렇다」
「저는 커뮤니케이션의 달인입니다」	「개발에서 가장 중요한 것은 커뮤니케이션이라고 생각합니다」 + 그렇게 행동한 사례

어떤 사람으로 보이고 싶으면, 그런 사람이 할 법한 말과 행동을 쓴다. 정의는 읽는 사람의 몫이다.

뼈대 두 가지

문제 해결 서사

면접과 자기소개서를 통틀어 가장 큰 가산점은 문제 해결을 서술하는 데서 나온다. 감점 요인을 막는 것만으로는 점수를 따지 못한다. 자기소개서의 거의 모든 이야기는 이 3단으로 바꿀 수 있고, 바꾸면 힘이 생긴다.

서론  남들이 문제 아니라고 할 때, 이게 문제라고 봤다      (문제의식, 한두 줄)
본론  해결하려고 누구와 무엇을 했다                       (해결 과정)
결론  결과는 이렇게 됐고, 이것을 배웠다                    (결과·배움)

서사는 두 방향으로 쓸 수 있다.

방향	문제의식	해결 과정	결과·배움
장점을 증명	따라가기 벅찬 전공 수업	복습을 거듭해 내 것으로 만듦	좋은 성적과 자신감
단점을 극복	남의 눈치를 많이 보는 성격	팀원을 조금씩 설득해 과반의 동의를 얻음	졸업 프로젝트 완수와 팀의 신뢰

「배우고 느낀 점을 쓰라」는 질문에도 해결한 문제와 배운 점으로 답한다. 아무 활동이나 고를 수 없고 문제를 푼 활동을 골라야 하므로 이야깃거리가 많아진다. 사람은 원인과 결과로 엮인 이야기를 잘 기억한다.

계획 없이 뛰어들었다가 뜻밖의 것을 얻은 경험(「물에 빠졌다 나와 보니 주머니에 진주가 있었다」)도 이 구조로 짧게 쓰면 된다. 경력기술서가 없는 신입일수록 이 서사가 자기소개서의 중심이다. 경력이 생기면 문제 해결 이야기는 경력기술서로 옮겨 가고, 그때부터는 경력기술서가 자기소개서보다 중요하다.

PREP 구성

결론 한 줄 → 이유 → 가장 강한 사례 하나 → 결론 한 줄. 공식 자체는 글쓰기 원칙의 「PREP 공식」에 있다. 면접 답변에도 똑같이 쓴다.

문제 해결 서사와 PREP를 합치면 「1줄 → 본론 → 1줄」 구조가 된다. 한 문항을 문단 넷으로 나누고, 첫 문단과 마지막 문단에는 포인트만 한 줄씩 둔다. 줄바꿈 위치 자체가 구조를 보여 주므로 훑어 읽는 면접관이 핵심을 바로 찾는다.

[1줄]  포인트: 무엇을 해결했나 / 어떤 사람인가
[본론] 이유와 문제의식
[본론] 해결 과정 (사례 하나)
[1줄]  결론: 결과와 배운 점

뭘 쓸지 막막하면 가설과 결론부터 정한다. 「A는 B다」, 「C에서 가장 중요한 것은 D다」, 「E에서 F는 생각보다 중요하지 않다」 같은 문장으로 서론·결론을 먼저 박아 두면 본론은 쉽게 채워진다. 모두가 한 번쯤 고민해 본 주제에 자기 가설을 자신 있게 던지면 끝까지 읽힌다. 모두가 동의하지는 않더라도 납득은 할 수 있는 결론이어야 한다. 예: 「게임에서 재미는 생각보다 중요하지 않다 → 개발에서 중요한 것은 커뮤니케이션이다」처럼 통념을 건드리는 가설은 동의하는 사람도 반발하는 사람도 끝까지 읽게 만든다.

무엇을 쓸까: 주제별 우선순위

순위	주제	쓰는 법
1	지원 동기	회사가 가장 듣고 싶은 이야기다. 아래 「지원 동기는 채용 동기다」
2	문제 해결 경험	위의 3단 서사. 갈등 조정 경험은 소통 능력까지 함께 보여 준다
3	단점	좋은 말만 있으면 믿기 어렵다. 20% 정도 쓴맛이 들어가야 균형이 맞는다
4	장점	PREP로 건조하게. 해석 대신 본 것을 묘사하면 객관적으로 읽힌다
5	가치관	「일에서 가장 중요한 것은 ~다」 꼴로. 아래 「가치관을 끌어내는 질문」
6	기술·역할	짧게 언급만. 자세한 것은 경력기술서·포트폴리오에서
피함	성장 배경	나에 대해 아무것도 설명하지 못한다. 지원 동기로 이어지거나, 환경을 이겨 낸 문제 해결 서사일 때만 쓴다
가장 피함	인성 자랑	정의로 시작해 나열로 끝난다. 인성은 내가 주장해서가 아니라 상대가 인정해 줄 때 설득력이 생긴다

지원 동기는 채용 동기다

지원 동기를 뒤집으면 회사가 나를 뽑을 동기가 된다. 내가 지원한 이유가 아니라 회사가 나를 뽑아야 할 이유를 쓴다. 직무 기술서(JD)에 원하는 사람이 다 적혀 있다.

회사가 이런 사람을 찾고 있다는 것을 안다.
마침 내가 그 요건에 맞는다.
평소 이런 생각을 해 왔고, 이런 프로젝트에서 확인했다.
그러니 나를 뽑아 달라.

쓰면 안 되는 것: 「좋은 개발자가 되고 싶어서」(자기중심), 「업계 최고의 회사라서」(찬양).
그 회사 제품을 실제로 즐겨 쓴다는 이야기는 좋은 가점이다. 찬양으로 흐르지만 않으면 된다.
지원 동기는 특정 회사를 겨냥할 때만 맞춰 쓴다. 여러 곳에 올리는 범용 자기소개서에서는 빼거나 무난하게 쓴다.
학교 지원서는 다르다. 회사는 일할 사람을 뽑고 학교는 키울 사람을 뽑으므로, 학교에는 내가 지원한 동기를 써도 된다.

장단점 전개법

패턴	흐름
장점	장점 한 줄 → 근거 → 구체적 사례 → 그래서 내게 맞는 장점이다
장점이자 단점	이 장점은 동시에 단점이다 → 근거 → 사례 → 고치려고 이렇게 노력 중이다
단점을 문제로	단점 한 줄 → 문제로 인식하고 해결 시도 → 시도한 것들 → 결과와 배움
단점을 받아들임	단점 한 줄 → 근거 → 사례 → 배운 점 → 이 단점은 내게 저주이자 축복이다

단점을 쓰기 어려운 이유는 둘이다. 스스로를 객관적으로 보기 어렵고, 밉보일까 두렵다. 나이에 비해 짧은 경력, 긴 공백기처럼 바꿀 수 없는 핸디캡은 숨기지 말고 「이 핸디캡과 함께 사는 법을 배웠다」, 「나를 완성시킨 촉매였다」 같은 서사로 담담하게 쓰면 진솔하고 긍정적으로 읽힌다.

경력란

신입이면 인턴·아르바이트·봉사·공공 근로를 쓴다. 돈을 받고 일한 경험이 가장 좋다. 작은 사회 생활이기 때문이다. 이때 핵심은 「내가 선임의 시간을 어떻게 아껴 줬나」, 즉 업무에 어떻게 보탬이 됐나다.

동아리·학생회는 「프로 의식 없는 놀이터」라는 선입견을 받기 쉽다. 쓴다면 그 활동을 얼마나 진지하게 했는지를 강하게 보여 줘야 한다.

평범한 업무를 쓰는 틀: 페인 포인트 → 자신 있는 분야 → 특기사항

맡은 일이 평범해서 쓸 말이 없어 보여도, 어떤 업무든 그 일이 막아 주는 페인 포인트(pain point) 가 있다. 그 업무에서 무엇이 가장 중요한지부터 짚으면 평범한 경력도 논리가 선다.

순서	쓸 내용	예: 음식점 홀 담당
1. 페인 포인트	이 업무에서 가장 중요한 것과 그 이유	고객 응대에서 가장 중요한 것은 ○○다. 응접에서 ○○를 하면 ○○하기 때문이다
2. 자신 있는 분야	그 중요한 것 가운데 내가 잘한 부분과 근거(숫자)	꼼꼼한 계산과 정산. 주문 실수는 한 번도 없었고 정산 오류는 한 번뿐이었다
3. 특기사항	일하며 새로 배우거나 스스로 키운 것	업무에서 엑셀이 중요하다는 것을 알고 틈날 때마다 독학했다

「n년 n개월 동안 ○○에서 ○○를 맡았다」로 시작해 세 칸을 차례로 채우면 한 문단이 된다. 페인 포인트를 먼저 짚으면 읽는 사람이 그 일을 이해하는 사람으로 본다. 다만 근거는 실제 경험과 숫자여야 한다. 틀은 평범한 경험에서 의미를 끌어내는 도구이지 없는 성과를 만드는 도구가 아니다.

가치관을 끌어내는 질문

막막하면 이런 질문에 답해 본다. 무엇에 답해도 자기소개가 된다.

나는 내향적인가, 외향적인가
갈등이 생기면 어떻게 접근하고 행동하는가
내 소통 방식은 어떤가
함께 일한 상사·멘토 중 가장 좋았던 사람은 누구이고, 왜인가
일과 삶의 균형은 내게 어떤 의미인가
가장 일하기 좋은 환경은 어떤 곳인가

흔한 실수

실수	고치는 법
질문과 다른 답을 한다	질문의 핵심 단어에 답하고 있는지 문단마다 확인한다
근거를 네다섯 개 늘어놓는다	가장 강한 근거 하나만 남긴다. 설득력 약한 주장을 근거 개수로 메우면 분량만 는다
결론이 없다	마지막 문단에 반드시 결론 한 줄
처음부터 끝까지 건조하거나, 끝까지 감정 과잉이다	사실은 건조하게, 동기·배움에서만 감정을 조금 싣는다
나를 정의하고 나열한다	상황과 행동을 묘사한다

자기소개서도 면접처럼 낯선 상대에게 함께해도 괜찮은 사람임을 보여 주는 자리다(면접 잘 보는 법). 가장 좋은 모습을 자연스럽게 보여 주되 가짜 캐릭터를 연기하지 않는다.

포트폴리오

이력서가 본문, 포트폴리오는 부록

채용 담당자는 서류 전형에서 이력서를 먼저 보고 포트폴리오를 본다. 개발 직군에서는 경력직에게 포트폴리오를 요구하지 않거나 코딩 테스트·과제로 대신하는 경우가 많아, 포트폴리오는 필수 자료라기보다 참고 자료다. 그래서 승부는 이력서에서 본다. 이력서는 부실한데 포트폴리오에만 힘을 주는 것은 신입이 흔히 하는 큰 실수다.

문서	역할
이력서	내가 어떤 사람인지 읽는 사람의 머릿속에 모델링한다. 주제이자 주인공은 나 자신이다
포트폴리오	이력서로 모델링한 업무 능력을 실제 작업물을 증거로 설득한다

이력서에서 관심을 끌지 못하면 포트폴리오는 주의 깊게 읽히지 않는다. 포트폴리오는 「이력서에서 못다 한 이야기를 하는 곳」이 아니라 「이력서를 읽고 더 알고 싶어진 내용을 작업물로 보여 주는 곳」이다. 예를 들어 이력서에 「맞춤 경량 작업 대기열을 만들었다」고 썼다면, 읽는 사람이 「자세히 볼 수 없을까」 하고 궁금해할 때 포트폴리오가 답한다.

게임의 아트북처럼 생각하면 쉽다. 아트북도 그 자체로 콘텐츠가 있지만, 본편을 보고 난 뒤에 봐야 몰입된다. 부록과 참고 문헌을 아무리 많이 읽어도 본문을 안 읽었다면 그 책을 읽은 것이 아니다. 본문인 이력서가 중심을 잡고 포트폴리오를 이끈다.

네 가지 구성 요소

요소	담을 것	보여 주는 능력
자기소개서	문제의식 하나, 왜 그렇게 봤는지, 해결하려고 한 일	사고방식
경력기술서	다닌 회사와 맡은 일, 부딪힌 문제와 해결, 배운 것	실무 경험
개인 작업물	혼자 만든 것: 설계 문서, 코드, 데이터 표	주도해서 만드는 능력
협업 작업물	함께 만든 것: 회의용 문서, 회의록, 명세서, 리뷰	소통 능력

채용 담당자가 포트폴리오를 읽는 방식

포트폴리오는 나를 소개하는 자료가 아니라, 회사의 문제를 내가 풀 수 있다는 증거다. 학력·자격증·취미보다 「이 사람이 우리 문제에 도움이 되나」에 답해야 한다. 디자인 직군에서 나온 원칙이지만 개발자 포트폴리오에도 그대로 통한다.

원칙	하는 일	이유
첫인상에 공을 들인다	첫 화면을 보기 편하고 기억에 남게 짠다	계속 볼지가 첫 화면에서 거의 정해진다
읽기 쉽게 만든다	무엇을 봐야 하는지 바로 보이는 구조. 개성 있는 레이아웃이 가독성을 해치면 안 된다	헤매게 만드는 포트폴리오는 닫힌다
작업물은 골라서 넣는다	만든 것 전부가 아니라 가장 좋은 것, 그중에서도 지원한 회사의 문제와 이어지는 것	담당자는 짧은 시간에 핵심만 확인하고 싶어 한다
예쁜 결과보다 목표·기술·문제 해결	「결제 이탈을 줄여 줄 사람인가」, 「모션 경험이 있나」, 「모바일 앱에 맞는 기술이 있나」 같은 질문에 답하는 작업을 고른다	회사는 채용 공고에 풀고 싶은 문제를 적어 둔다
케이스 스터디를 하나 이상 넣는다	문제 → 사고 과정 → 시행착오와 배운 점 → 초안에서 최종안까지의 변화 → 사용자에게 준 영향	결과물만으로는 과정이 보이지 않는다. 작업할 때마다 일지를 남겨 두면 나중에 그대로 재료가 된다
요약을 맨 앞에 둔다	케이스 스터디 첫머리에 핵심 요약. 이력서도 중요도·최신순으로 위에서 아래로	담당자는 요약을 보고 읽을지 정한다. 요약이 없으면 대부분 읽지 않는다
실제가 아닌 프로젝트도 괜찮다	기존 서비스를 다시 설계할 때는 더 예쁘게가 아니라 발견한 문제를 고친다	신입이나 NDA로 실무 작업을 못 보여 주는 사람에게 특히 유효하다
개성은 균형 있게	사명·좌우명·관심사로 기억에 남되, 경험을 가리지 않게	회사는 기술을 갖추고 함께 일하고 싶은 사람을 찾는다

경력이 없어 포트폴리오를 못 만들고, 포트폴리오가 없어 일을 못 구하는 악순환은 일단 지금 만드는 것으로 끊는다. 경험이 적다면 앞으로 어떤 분야의 전문가로 크고 싶은지 방향을 함께 적는다. 회사는 성장할 사람에게 투자하고 싶어 한다. 포트폴리오는 한 번 만들고 끝나는 문서가 아니라 계속 고쳐 가는 문서다.

개발자 포트폴리오: 과정을 보여 주고, 밖으로 내보내지 않는다

개발자 포트폴리오를 고치는 순서는 문제를 정의하고(주제는 나 자신, 역할은 이력서 보조), 그에 맞는 구체적인 문제를 찾고, 주제를 지침 삼아 답을 찾는 것이다. 이력서를 옆에 두고 함께 보며 점검한다.

원칙	하는 일
결과물이 아니라 과정을 담는다	신입의 프로젝트는 대부분 본인만 아는 프로젝트이고, 부트캠프·클론 코딩 프로젝트는 서로 비슷하다. 결과가 같아도 만드는 과정은 사람마다 다르다. 일지처럼 쓰지 말고 이력서의 문제 정의 → 해결 → 결과를 작업물로 뒷받침한다
문제 정의도 증거로 보여 준다	「답답한 사용자 경험」이 문제였다면 API 응답 시간이나 브라우저에서 잰 성능 값을, 프론트엔드가 병목이었다면 개발 흐름을 시각화한 그림을 넣는다. 해결 과정에는 그때 쓴 코드와 설계도를 붙인다
코드는 맥락과 함께	자랑할 만한 코드만 떼어 놓으면 관심이 품질로 간다. 「이렇게 정의한 문제를 이렇게 풀었고, 그때 쓴 코드가 이것이다」로 이야기를 끌고 간다
이력서와 어긋나지 않게	이력서에 문서화를 중시한다고 썼는데 저장소 README에 보일러플레이트만 있으면 거짓말이 된다
주제를 강하게 받치는 순서로	설득력이 센 것부터, 이력서의 전개 순서에 맞춰 배치한다. 분량을 줄일 때는 이력서 주제와 먼 것부터 뺀다. 이력서의 모든 경험과 1:1로 맞출 필요는 없고 2~3개면 충분하다

읽는 사람을 밖으로 내보내지 않는다

외부 URL은 독자를 이탈시킨다. 링크를 누른 사람은 탭 수십 개 사이에서 왜 열었는지 잊거나, 모바일에서 불편해 닫거나, 그 페이지가 어느 지원자 것인지 찾지 못한다. 최대한 포트폴리오 안에서 해결한다.

데모는 영상으로. 신입의 프로젝트에 직접 들어가 꼼꼼히 써 보는 채용 담당자는 드물다. 영상을 넣고, 직접 써 보고 싶은 사람을 위한 URL은 작게 둔다.
영상은 핵심부터. 주소 입력 → 로그인 → A → B → 핵심 순서로 사용 과정을 그대로 녹화하지 않는다. 보여 주려는 것이 로그인이 아니면 잘라 내고 바로 핵심을 보여 준다.
체험을 열어 둔다면 가입·로그인 없이. 하드코딩을 해서라도 핵심 경험에 바로 닿게 한다. 회원 가입부터 하라고 하면 조용히 탭을 닫는다.
저장소 대신 커밋 링크. 짧은 코드는 포트폴리오에 바로 넣는다. 코드가 여러 커밋에 걸쳐 있으면 저장소 첫 화면이 아니라 해당 커밋 URL을 주고, 길면 짧은 URL로 바꾼다. 팀 저장소의 커밋 목록을 헤매다 보면 누구의 커밋인지도 알 수 없다.
저장소로 보내야 한다면 README를 관문으로. README에 누구의 저장소인지, 어떤 문제를 어떻게 정의했는지, 어떻게 풀었는지, 결과가 얼마나 나아졌는지, 관련 커밋 링크를 담는다. 팀 프로젝트라 팀 저장소 README를 고치기 어렵다면, 내 저장소에 설명용 README를 만들어 관문으로 쓰고 실제 구현은 팀 저장소의 커밋으로 연결한다. 채용 담당자는 그 페이지가 개인 저장소인지 팀 저장소인지보다, 알고 싶은 내용이 거기 있는지에 관심이 있다.

포트폴리오는 아트북이자 가상의 미술관이다. 관람객이 알아서 찾아와 분석해 주길 기대하지 말고, 도슨트가 되어 길을 안내하며 이력서의 주제를 남긴다. 적어도 오픈소스 저장소의 README보다는 친절해야 한다.

인트로와 결론이 점수의 대부분이다

많은 포트폴리오가 해 온 일을 남김없이 보여 주는 것에 집중한다. 열정은 보이지만 좋은 방식이 아니다. 좋은 논문처럼 가설을 세우고 결론으로 곧장 가야 한다.

슬라이드 포트폴리오라면 경험칙으로 체감 배점은 인트로 50, 결론 30, 나머지 전부 합쳐 20 정도다. 인트로와 결론 페이지를 가장 먼저 만들고, 그 사이를 논리로 채운다.

차별화

신입끼리 품질이나 비용으로는 차이가 크지 않다. 남는 무기는 차별화다.

경쟁자들의 전형(stereotype)을 먼저 파악한다. 예: 「기획을 잘한다」고 믿으며 두꺼운 기획서를 내는 기획자.
그 전형에 맞서는 한 줄을 만들어 자신을 정의한다. 예: 「100장짜리 기획서도 쓰지만, 1장으로 압축해 공유한다」.
작업물 곳곳에 그 사람이 보이게 한다. 모두를 만족시킬 수는 없으니 겨냥한 독자(회사·직무)가 호감과 호기심을 느끼도록 고른다(세그먼테이션).

나만 쓸 수 있는, 사람 냄새 나는 자기소개서와 포트폴리오가 기계적으로 다듬은 문서보다 기억에 남는다.

정리

자기소개서는 나를 정의하지 않고 행동을 묘사한다.
뼈대는 문제의식 → 해결 → 결과·배움, 문단은 PREP, 근거는 하나.
지원 동기는 채용 동기로 뒤집어 쓴다. 결론은 「그러니 나를 뽑아 달라」.
성장 배경·인성 자랑은 피하고, 단점은 20%의 쓴맛으로 넣는다.
포트폴리오는 인트로와 결론부터 만들고, 전형에 맞서는 한 줄로 차별화한다.
포트폴리오에는 회사의 문제와 이어지는 작업만 고르고, 케이스 스터디는 요약을 맨 앞에 둔다.
승부는 이력서에서 보고, 포트폴리오는 이력서의 주장을 작업물로 증명하는 부록이다.
개발자 포트폴리오는 결과보다 과정을, 저장소보다 커밋 링크와 데모 영상을 보여 주고 독자를 밖으로 내보내지 않는다.

버그 제보