Skip to content
←

Split View: 회사 밖 증거 — 무엇이 포트폴리오로 작동하고 무엇이 시간을 먹는가

✨ Learn with Quiz
|

회사 밖 증거 — 무엇이 포트폴리오로 작동하고 무엇이 시간을 먹는가

포트폴리오가 실제로 하는 일

사내 성과의 약점은 검증할 수 없다는 것입니다. 대부분 비공개이고, 팀 단위여서 내 몫을 분리해 보여 주기 어렵고, 결국 내 말로만 전달됩니다. 회사 밖의 것은 다릅니다. 링크 하나로 상대가 직접 확인합니다.

다만 대체재가 아니라 보완재입니다. 회사 밖 산출물이 사내 경력을 대신하는 경우는 드물고, 대체로 두 가지 일을 합니다. 첫째, 이력서에 적은 주장 하나에 확인 가능한 근거를 붙입니다. 둘째, 우연한 접촉을 만듭니다. 사내 성과는 검색되지 않지만 공개된 것은 검색됩니다.

그래서 판단 기준이 단순해집니다. 이것이 내 주장 가운데 하나를 확인 가능하게 만드는가. 아니라면 즐거워서 하는 일일 수는 있어도 포트폴리오는 아닙니다. 두 가지를 섞으면 즐거움도 줄고 증거도 안 남습니다.

무엇이 작동하고 무엇이 작동하지 않는가

작동하지 않는 쪽부터 봅니다. 튜토리얼을 그대로 따라 만든 것, 시작만 하고 멈춘 저장소, 자기소개만 있고 결과물이 없는 페이지, 그리고 개수입니다. 미완성 열 개는 완결된 하나보다 약합니다. 읽는 사람이 확인하는 것이 능력의 최댓값이 아니라 끝까지 가는 성질이기 때문입니다.

작동하는 쪽은 이렇습니다.

  • 완결된 작은 것. 범위가 좁고 실제로 돌아가며 남이 써 볼 수 있는 것.
  • 문제 서술이 있는 문서. 무엇을 왜 만들었고 어디서 막혔고 무엇을 포기했는지. 코드보다 이 문서가 더 많이 읽힙니다.
  • 남이 쓴 흔적. 이슈, 질문, 포크. 사용자가 몇 안 되더라도 있다는 사실 자체가 완성도의 증거입니다.
  • 내 방향과 연결된 것. 앞으로 다루고 싶은 문제 유형과 같은 종류일 때 값이 가장 큽니다.

공개 글쓰기의 효용과 한계

효용은 세 가지입니다. 첫째, 쓰는 과정에서 자기 이해의 구멍이 드러납니다. 이 효용은 아무도 읽지 않아도 발생합니다. 둘째, 검색되는 색인이 됩니다. 나중에 누군가 나를 찾을 때 이름이 아니라 문제로 찾습니다. 셋째, 우연한 연결이 생깁니다.

한계도 분명합니다. 대부분의 글은 읽히지 않습니다. 보상은 즉시 오지 않고 누적에 시간이 걸리며, 얼마나 걸릴지는 미리 알 수 없습니다. 그래서 반응을 목표로 두면 대체로 몇 달 안에 그만두게 됩니다. 목표를 자기 참조물에 두면 첫 편부터 이미 값을 회수하고, 읽히는 것은 덤이 됩니다.

한 가지 더 있습니다. 회사 일에 대해 쓸 때 공개 가능한 범위는 계약과 관할에 따라 다릅니다. 사내 정보와 고객 정보를 어디까지 쓸 수 있는지는 각자 확인해야 하는 문제이고, 애매하면 쓰기 전에 묻는 편이 안전합니다.

오픈소스 기여의 현실

첫 진입로는 대개 코드가 아닙니다. 문서 수정, 이슈 재현, 테스트 추가, 남의 변경을 읽고 정확한 질문 하나 남기기가 현실적인 시작입니다. 큰 기능 제안으로 시작하면 대체로 병합되지 않습니다. 프로젝트마다 받아들이는 범위가 이미 정해져 있기 때문입니다.

세 가지는 미리 알고 시작하는 편이 좋습니다. 반응이 없을 수 있고, 첫 병합까지 걸리는 기간은 프로젝트마다 크게 다르며, 감정 소모가 있습니다. 유지보수자는 대개 자기 시간을 쪼개 쓰고 있어서 답이 늦는 것이 개인적인 일이 아닙니다. 공개된 곳에서 거절당하는 경험은 사내 리뷰와 체감이 다르다는 점도 알아 두면 덜 흔들립니다.

이력서에서 실제로 힘을 갖는 것은 유명한 프로젝트의 이름이 아니라 협업의 흔적입니다. 리뷰를 받아들이고 고친 기록, 남의 코드를 읽고 남긴 질문, 문서에 남긴 설명이 그것입니다. 그래서 한 프로젝트에 오래 남는 편이 여러 곳을 한 번씩 스치는 것보다 강합니다.

시간 예산이라는 제약

회사 밖 시간은 무한하지 않고, 휴식과 건강과 관계와 같은 자원을 씁니다. 이 계산을 빼면 포트폴리오가 커리어를 깎는 상황이 실제로 생깁니다. 밤을 쓴 만큼 낮의 판단이 나빠지고, 낮의 결과가 나빠지면 회사 밖 증거로 회복할 수 있는 것보다 잃는 쪽이 큽니다.

그래서 시작 전에 두 가지를 정해 두는 편이 낫습니다. 주당 몇 시간을 쓸 것인지, 그리고 무엇을 보면 그만둘 것인지입니다. 종료 조건이 없으면 어떤 프로젝트도 끝나지 않고, 끝나지 않은 것은 증거가 되지 않습니다.

오늘 할 수 있는 한 가지

새로 시작하지 마십시오. 이미 만들다 만 것 중 하나를 골라 완결 기준을 한 줄로 적고 공개 날짜를 붙이는 것이 오늘의 일입니다. 기준은 낮게 잡습니다. 설치 안내와 예제 하나가 있고 처음 보는 사람이 몇 분 안에 실행할 수 있으면 끝, 정도면 충분합니다(구성한 예시입니다). 원래 계획한 범위의 대부분을 지우는 결정이 대체로 옳습니다. 지운 것은 남지 않지만, 끝난 것은 남습니다.

이 조언이 안 맞는 경우

고용 계약과 관할에 따라 사외 활동과 지식재산의 범위가 다릅니다. 무엇을 공개할 수 있는지는 회사와 나라마다 다르므로, 일반론을 믿지 말고 자기 계약을 확인해야 합니다. 이것은 조심의 문제가 아니라 사실 확인의 문제입니다.

여가 시간이 구조적으로 없는 사람도 있습니다. 돌봄이 있거나, 건강이 여유를 주지 않거나, 다른 일을 하나 더 하는 경우입니다. 이런 상황에서 회사 밖 증거를 요구하는 기준은 공정하지 않고, 그 기준에 자기를 억지로 맞추다 몸을 상하는 쪽이 더 나쁩니다. 이때는 회사 안에서 확인 가능한 증거를 만드는 편이 현실적입니다. 공개해도 되는 설계 문서, 사내 발표, 새로 온 사람을 위한 자료 같은 것입니다.

마지막으로 사내 증거가 이미 충분한 경우입니다. 경력이 쌓일수록 검증의 무게는 산출물에서 사람의 증언으로 옮겨 갑니다. 이 구간에서는 저장소를 하나 더 만드는 것보다, 함께 일한 사람 다섯 명이 나를 정확하게 설명할 수 있는 상태가 더 강합니다.

이어서 읽기

커리어를 움직이는 선택 시리즈

Evidence From Outside the Company — What Works as a Portfolio and What Just Eats Time

What a Portfolio Actually Does

The weakness of work done inside a company is that it cannot be verified. Most of it is private, it belongs to a team so your share is hard to separate out, and in the end it travels only through your own account of it. Work outside is different: one link and the other person confirms it directly.

But it is a complement, not a substitute. Outside work rarely stands in for a career inside, and it usually does two jobs instead. First, it attaches verifiable grounds to one of the claims on your résumé. Second, it creates accidental contact. Internal achievements are not searchable; published things are.

That makes the test simple. Does this make one of my claims verifiable? If not, it can still be something you do for pleasure, but it is not a portfolio. Mixing the two tends to produce less pleasure and no evidence.

What Works and What Does Not

Start with what does not. Something built by following a tutorial, a repository that was started and stopped, a page with a profile and no output, and sheer count. Ten unfinished things are weaker than one finished one, because what the reader is checking is not the ceiling of your ability but whether you go all the way to the end.

What works looks like this.

  • A small finished thing. Narrow in scope, actually running, and usable by someone else.
  • A document that states the problem. What you built and why, where you got stuck, what you gave up. This document gets read more than the code does.
  • Traces of other people using it. Issues, questions, forks. Even a handful of users is itself evidence of completeness.
  • Something connected to your direction. It is worth the most when it belongs to the same class of problem you want to work on next.

The Return and the Limits of Writing in Public

There are three returns. First, the act of writing exposes the holes in your own understanding — a return that arrives even if nobody reads it. Second, it becomes a searchable index; later someone finds you by the problem rather than by your name. Third, accidental connections happen.

The limits are just as clear. Most writing is not read. The reward does not arrive immediately, accumulation takes time, and how much time is not knowable in advance. So aiming at a response usually means quitting within a few months. Aim instead at a reference for yourself and the first piece has already paid for itself, with readers as a bonus.

One more thing. When you write about work, what you may publish differs by contract and by jurisdiction. How far you can go with internal or customer information is something each person has to check, and when it is ambiguous it is safer to ask before publishing.

The Reality of Open Source Contribution

The first way in is usually not code. Fixing documentation, reproducing an issue, adding a test, reading someone else's change and leaving one precise question — those are the realistic starts. Beginning with a large feature proposal usually does not get merged, because each project has already settled the range of what it accepts.

Three things are worth knowing before you begin. There may be no response, the time to a first merge varies enormously between projects, and there is emotional cost. Maintainers are mostly carving out their own hours, so a slow answer is not personal. And being turned down in public feels different from an internal review — knowing that in advance makes it shake you less.

What actually carries weight on a résumé is not the name of a famous project but the trace of collaboration: the record of taking a review and revising, the question you left after reading someone's code, the explanation you added to the docs. Which is why staying with one project for a long time is stronger than passing through many once each.

The Constraint of a Time Budget

Hours outside work are not unlimited, and they draw from the same account as rest, health, and relationships. Leave that calculation out and the situation where a portfolio erodes a career genuinely occurs. Nights spent make daytime judgment worse, and once daytime results slip, the loss outweighs what outside evidence can recover.

So it is better to fix two things before starting: how many hours a week this gets, and what you would have to see in order to stop. Without an exit condition no project ends, and what does not end does not become evidence.

One Thing You Can Do Today

Do not start something new. Today's task is to pick one of the things you already half-built, write its definition of done in one line, and attach a publication date. Set the bar low. Install instructions plus one example, and a first-time reader can run it within a few minutes — that is enough (this is a constructed example). Deleting most of the scope you originally planned is usually the right call. What you delete leaves nothing behind, but what finishes does.

Where This Advice Does Not Apply

The scope of outside activity and intellectual property differs by employment contract and by jurisdiction. What you may publish varies by company and by country, so check your own contract rather than trusting a general claim. This is a matter of fact-checking, not of caution.

Some people structurally have no free hours: caregiving, health that leaves no slack, a second job. A standard that demands outside evidence is not fair to them, and forcing yourself to meet it at the cost of your body is worse than not meeting it. In that case, building verifiable evidence inside the company is the realistic route: a design document that can be shared, an internal talk, material written for new joiners.

Finally, there is the case where internal evidence is already sufficient. The further a career goes, the more the weight of verification shifts from artifacts to testimony from people. In that stretch, having five people who worked with you able to describe you accurately is stronger than one more repository.

Further Reading

Career Moves series