포트폴리오보다 먼저 좋아져야 하는 것

공부를 시작하면 곧바로 포트폴리오 뭐 만들지라는 생각이 든다. 방향을 잡는 데 도움이 되지만, 너무 일찍 결과물 모양새만 신경 쓰면 오히려 학습이 얕아진다.

포트폴리오는 실력의 대체재가 아니라 실력이 남긴 흔적에 가깝다. 흔적만 만들려고 하면 금방 비어 보인다.

비어 보인다는 말이 추상적으로 들리겠지만, 실제로는 아주 구체적인 순간에 드러난다. 누군가 코드의 한 줄을 짚고 이건 왜 이렇게 했느냐고 물었을 때다.

포장보다 설명력이 먼저다

좋은 포트폴리오는 화려한 기능이 많아서보다, 내가 어떤 문제를 어떻게 풀었는지 설명할 수 있어서 힘이 있다. 그 설명력은 결국 실제로 부딪히며 만든 경험에서 나온다.

그래서 초보자는 포트폴리오 개수를 늘리기보다, 하나의 프로젝트라도 왜 그렇게 만들었는지 말할 수 있어야 한다.

README 한 장이 차이를 만든다

설명력이라는 말은 막연하지만, 그것이 문서로 남는 자리는 대개 저장소의 첫 화면이다. 아래 두 가지가 흔히 보이는 형태다.

흔한 README

# TodoApp

React, Node.js, MongoDB로 만든 할 일 관리 앱입니다.
반응형 디자인을 적용했습니다.

## 기술 스택
React / Express / MongoDB / AWS

기술 이름의 목록이다. 읽는 사람이 알게 되는 것은 거의 없다.

고쳐 쓴 README

# TodoApp

할 일을 추가하고 완료 표시하는 앱입니다. 혼자 쓰려고 만들었습니다.

## 실행 방법
npm install && npm run dev  (Node 20 기준)

## 만들면서 부딪힌 것
- 완료 표시가 새로고침하면 사라졌습니다. 상태를 화면에서만
  바꾸고 서버에 보내지 않았기 때문이었고, 저장 후 응답으로
  목록을 다시 받아 오는 방식으로 고쳤습니다.
- 목록이 200개를 넘으면 입력이 버벅였습니다. 지금은 그냥
  두었고, 왜 느린지는 아직 정확히 모릅니다.

## 다음에 할 것
- 삭제 기능, 목록 검색

기술 이름은 오히려 줄었는데 읽는 사람이 알게 되는 것은 훨씬 많다.

두 번째 문서에서 눈여겨볼 것은 아직 모른다고 적은 줄이다. 이 한 줄은 약점이 아니라, 무엇이 문제인지 인식하고 있다는 증거로 읽힌다. 반대로 모든 것이 완벽하게 해결됐다고 적힌 문서는, 질문 두어 개면 그렇지 않다는 것이 드러난다. 아는 것과 모르는 것의 경계를 아는 사람이 신뢰를 얻는다.

기록의 시점

부딪힌 것을 프로젝트가 끝난 뒤에 쓰려고 하면 기억이 안 납니다. 막혔을 때 그 자리에서 두 줄씩 적어 두십시오. 나중에 그 메모가 그대로 문서가 됩니다.

포트폴리오 전에 점검할 것

프로젝트 핵심 흐름을 직접 설명할 수 있는가
막혔던 문제와 해결 과정을 말할 수 있는가
코드 일부를 열고 왜 그렇게 작성했는지 설명할 수 있는가
다른 사람의 컴퓨터에서 실행되는가
사용 기술 이름보다 배운 점을 말할 수 있는가

개수를 늘리면 오히려 얕아진다

프로젝트를 여러 개 나열하고 싶은 마음은 자연스럽다. 하나뿐이면 부족해 보이기 때문이다. 그런데 세 개를 각각 이 주씩 만든 사람과 하나를 육 주 동안 만든 사람은, 겪은 일의 종류가 다르다. 앞의 경우는 세 번 다 시작 구간만 반복한다. 프로젝트에서 어려운 부분은 대개 시작이 아니라 중간 이후에 오기 때문이다.

기능을 붙이다가 구조가 어긋나기 시작하는 순간, 데이터가 늘어나면서 처음 설계가 안 맞는 순간, 고친 것 때문에 다른 곳이 깨지는 순간. 이런 것들은 이 주짜리 프로젝트에서는 거의 나오지 않는다. 그리고 이런 순간을 겪은 사람만이 왜 그렇게 만들었는지에 대한 답을 갖게 된다.

그래서 개수를 늘리기보다 하나를 계속 고쳐 나가는 쪽을 권한다. 같은 프로젝트에 기능을 세 번 붙이고 두 번 갈아엎은 기록은, 서로 다른 세 개의 완성작보다 대체로 더 많은 것을 말해 준다.

복사해 온 코드가 남기는 문제

강의를 따라 만든 프로젝트나 생성 도구가 써 준 코드를 올리는 것 자체는 문제가 아니다. 문제는 그 코드에 대해 물었을 때 답할 수 없는 상태로 남겨 두는 것이다. 실제로 이 지점이 가장 빨리 드러난다. 화면은 잘 도는데 인증이 어떻게 처리되는지 설명하지 못하는 상황 같은 것이다.

대응은 어렵지 않다. 남의 코드로 시작했더라도, 거기에 내 손으로 기능 하나를 붙이면 된다. 붙이려면 구조를 읽어야 하고, 읽는 동안 대부분 내 것이 된다. 그리고 그 과정에서 겪은 일이 그대로 설명할 거리가 된다. 처음부터 다 만들 필요는 없지만, 한 군데는 반드시 내가 파고들어야 한다.

어디를 파고들지 고르는 기준도 간단하다. 그 프로젝트에서 가장 중심이 되는 흐름이면 된다. 화면 색을 바꾸거나 버튼을 추가하는 것 말고, 데이터가 들어와서 저장되고 다시 나가는 경로에 손을 대야 한다. 그 경로를 이해하면 나머지는 대부분 따라온다. 반대로 주변만 만지면 아무리 오래 붙들고 있어도 설명할 것이 생기지 않는다.

그래도 만들어 두는 편이 나은 경우

이 글의 주장을 뒤집어 읽으면 곤란하다. 실력이 충분해질 때까지 아무것도 공개하지 않겠다는 태도는 더 나쁜 결과를 낳는다. 그 기준은 영원히 충족되지 않고, 그동안 만든 것들은 기억에서 사라진다. 부끄러운 코드라도 공개된 상태로 남아 있으면 나중에 다시 열어 고칠 수 있지만, 노트북 안에서 잊힌 코드는 없는 것과 같다.

맥락에 따라 우선순위가 달라지기도 한다. 정해진 마감 안에 지원해야 하는 상황이라면, 완성도를 더 높이는 것보다 있는 것을 정리해서 보여 주는 쪽이 현실적이다. 이때도 원칙은 같다. 없는 것을 있는 것처럼 쓰지 않고, 무엇을 했고 무엇을 안 했는지를 정확히 적으면 된다. 과장이 없는 문서는 규모가 작아도 힘이 있다.

그리고 지금 공개해 둔 것이 나중에 부끄러워지는 것은 나쁜 신호가 아니다. 반년 전 코드가 여전히 괜찮아 보인다면 그동안 늘지 않았다는 뜻에 가깝다. 부끄러움은 대개 성장의 부산물이다.

가장 위험한 문장

이력에 적을 때 참여했다는 표현은 범위가 모호합니다. 어느 부분을 직접 썼는지 말할 수 없다면 적지 마십시오. 확인은 대개 코드 한 줄을 짚는 것으로 끝납니다.

초보자에게 가장 설득력 있는 포트폴리오는 결과 화면보다 문제 해결 과정이 보이는 포트폴리오다.

프로젝트와 성장

더 볼 것

설명할 거리가 남는 프로젝트를 고르는 기준은 완주 가능한 첫 프로젝트에 정리해 두었습니다. 다른 사람의 컴퓨터에서도 도는 상태로 만드는 일은 한 번의 배포가 바꾸는 것과 이어집니다.

이 글의 포인트

포트폴리오는 실력을 대신하지 않는다.
기술 스택 목록보다 부딪힌 문제와 해결 과정이 더 많은 것을 말한다.
모르는 부분을 모른다고 적는 것이 신뢰를 만든다.
남의 코드로 시작했다면 한 군데는 직접 파고들어야 한다.
완벽해질 때까지 공개를 미루는 것이 더 큰 손해다.