신입 개발자 포트폴리오, 한 프로젝트를 케이스 스터디로 푸는 법

26살 박진주 씨는 노트북 앞에 앉아 포트폴리오 페이지를 열었습니다.

백엔드 개발자로 지원할 회사들을 정리하던 중, 캡스톤 프로젝트를 포트폴리오 첫 페이지에 올리려던 참이었습니다.

화면을 보다가 손이 멈췄습니다. 한 줄밖에 안 나왔거든요.

"Spring Boot로 만든 스터디룸 예약 시스템"

1년을 이렇게 한 줄로 줄여놓고 보니, 자기가 보기에도 이 시스템이 뭐가 특별한지 모르겠습니다.

기술 스택, 스크린샷, GitHub 링크. 다 있는데 뭔가 비어 있습니다.

박진주 씨처럼 막막한 신입 개발자가 많습니다. 그런데 추가해야 할 정보는 사실 정해져 있습니다.

어떤 정보를 어떻게 추가해야 하는지, 박진주 씨와 함께 풀어보겠습니다.

결과물만 보여주는 포트폴리오의 함정

신입 포트폴리오에서 가장 자주 보는 구성은 이런 형태입니다.

• 프로젝트명 — 스터디룸 예약 시스템

• 기술 스택 — Spring Boot, MySQL, Redis

• 설명 — 4인 팀에서 백엔드를 담당했습니다. JWT 인증, 예약 API 등을 구현했습니다.

• 링크 — GitHub | 데모

이걸 인사팀이 본다고 상상해 보겠습니다. 어떻게 읽힐까요?

"아, 스터디룸 예약 시스템 만들었구나."

여기서 끝납니다.

이 사람이 어떤 기술적 결정을 했는지, 어떤 문제를 만났는지, 어떻게 해결했는지는 한 줄도 안 보입니다.

결과물의 "이름표"는 있지만 결과물을 만든 "사람"이 안 보이는 것입니다.

포트폴리오의 진짜 가치는 "무엇을 만들었는가"가 아닙니다. "어떻게 만들었는가"에 있습니다.

만든 결과물은 GitHub 링크가 다 보여주고 있으니, 포트폴리오에선 결과물 너머의 것이 필요합니다.

그래서 한 프로젝트를 풀어쓸 때는 케이스 스터디 형식으로 갑니다. 케이스 스터디는 세 박자로 구성됩니다.

문제 — 과정 — 결과

이 세 가지를 채우면 포트폴리오에 사람이 보이기 시작합니다.

박진주 씨의 스터디룸 예약 시스템을 가지고 한 박자씩 풀어보겠습니다.

문제: 왜 이 프로젝트를 시작했는가

가장 많이 빼먹는 부분이 바로 여기입니다. "왜 이걸 만들었나"라는 질문입니다.

박진주 씨도 처음에는 이렇게 적었습니다.

[Before]

학과 졸업 작품으로 진행한 캡스톤 프로젝트입니다. 4인 팀에서 백엔드를 담당했습니다.

이 문장에서 인사팀이 얻을 수 있는 정보는 세 가지입니다. 졸업 작품, 4인 팀, 백엔드 담당.

박진주 씨가 어떤 문제를 풀고 싶었는지는 한 글자도 안 보입니다.

그래서 박진주 씨에게 물어봤습니다. "왜 하필 스터디룸 예약이었어요?" 답이 이렇게 나왔습니다.

"우리 학과는 스터디룸 예약을 사무실 전화로 받았거든요. 시험 기간엔 새벽부터 줄 서야 했어요. 온라인 시스템이 분명 있어야 한다고 생각했어요.

비슷한 시스템을 찾아보니 동시에 여러 명이 같은 시간대를 신청할 때 충돌 처리가 안 되는 경우가 많더라고요. 그 부분을 제대로 풀어보고 싶었어요."

이 답이 그대로 포트폴리오에 들어가야 합니다.

[After]

우리 학과는 스터디룸 예약을 사무실 전화로 받았고, 시험 기간엔 새벽 줄서기가 일상이었습니다. 온라인 시스템이 분명 필요했지만, 비슷한 서비스를 조사해 보니 동시 예약 충돌 처리가 부실한 경우가 많았습니다. 이 부분을 정확히 해결하는 시스템을 만드는 것이 캡스톤의 목표였습니다.

After 버전이 더 길지만, 읽는 사람 입장에선 정보 밀도가 훨씬 높습니다.

무엇을 풀고 싶었는지, 왜 그걸 풀고 싶었는지, 기존에 뭐가 부족했는지가 다 들어가 있습니다.

문제 정의 부분에 들어가야 할 질문 세 가지를 정리하면 이렇습니다.

• 상황 — 어떤 맥락에서 이 프로젝트가 시작됐나

• 불편 — 누구의 어떤 불편을 풀고 싶었나

• 기존의 한계 — 기존 방식이나 서비스가 왜 부족했나

이 세 가지가 다 적혀 있어야 다음 단계인 "과정"이 자연스럽게 이어집니다.

과정: 어떤 결정을 어떻게 내렸는가

여기가 케이스 스터디의 핵심입니다.

가장 빼먹기 쉬운 부분이기도 하고, 가장 가치 있는 부분이기도 합니다.

대부분의 신입 포트폴리오는 "무엇을 사용했는가"까지만 적습니다.

[Before]

Spring Boot, MySQL, Redis를 사용했습니다. JWT 인증, 예약 API, 알림 기능을 구현했습니다.

이 문장은 인사팀이 "어떤 스택을 다뤄봤구나" 정도까지만 알게 해 줍니다.

그런데 정작 인사팀이 궁금한 건 그게 아닙니다.

"이 사람은 어떤 근거로 그 결정을 내렸을까", 이게 핵심입니다.

박진주 씨의 캡스톤에서 가장 큰 의사결정은 "동시 예약 충돌을 어떻게 처리할 것인가"였습니다.

두 가지 선택지가 있었습니다. 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)입니다.

박진주 씨는 비관적 락을 선택했습니다. 그 이유를 적어 보면 이렇습니다.

[After]

동시 예약 처리 방식을 정할 때 낙관적 락과 비관적 락을 비교했습니다.

낙관적 락은 충돌이 드물 때 성능이 좋지만, 충돌이 발생하면 사용자가 다시 시도해야 합니다. 비관적 락은 락 비용이 들지만 충돌 시점에 즉시 막아줍니다.

스터디룸 예약은 시험 기간에 동시 요청이 폭주해서 충돌이 잦은 환경입니다. 사용자가 같은 시간대를 두 번 시도하게 만드는 것은 UX 측면에서 부담이 컸습니다.

그래서 락 비용을 감수하더라도 비관적 락으로 가는 것이 맞다고 판단했습니다. 실제로 시험 기간 패턴을 가정해 동시 요청 100건을 시뮬레이션했더니 충돌 누락 없이 처리됐습니다.

이 문단에 어떤 정보가 들어 있는지 보십시오.

• 두 가지 선택지를 비교했다 → 이 사람은 대안을 검토하는 사람이다

• 각각의 트레이드오프를 안다 → 이 사람은 기술 특성을 이해하고 있다

• 환경 조건과 결정을 연결한다 → 이 사람은 맥락 위에서 결정한다

• 결정을 검증했다 → 이 사람은 가설을 데이터로 확인한다

같은 "비관적 락 사용"이라는 결정도, 풀어 쓰는 방식에 따라 인사팀 머릿속에 그려지는 그림이 완전히 달라집니다.

과정 부분에 꼭 들어가야 할 것 세 가지입니다.

• 대안 비교 — 이걸 선택한 이유는, 다른 선택지에 비해 무엇이 더 나았기 때문

• 트레이드오프 — 무엇을 얻고 무엇을 포기했나

• 실패와 우회 — 시행착오를 솔직하게. 단, "결국 어떻게 해결했나"까지 함께

특히 마지막 "실패와 우회"는 신입 포트폴리오에서 강력합니다.

신입은 시행착오를 숨기는 경향이 있는데, 인사팀은 오히려 그 시행착오에서 사고력을 확인합니다.

"처음엔 낙관적 락으로 만들었는데 동시 요청 테스트에서 충돌 누락이 발견됐고, 비관적 락으로 전환했다"는 흐름이, 처음부터 비관적 락이었다고 쓴 글보다 훨씬 입체적입니다.

결과: 무엇이 어떻게 달라졌는가

마지막 박자는 결과입니다. "완성했습니다"에서 멈추는 경우가 많은데, 결과는 그 너머가 있어야 합니다.

[Before]

시스템을 완성했고 학과 캡스톤 발표회에서 발표했습니다.

이 문장은 정보가 거의 없습니다. "끝까지 갔다"는 사실 외엔 아무것도 안 보입니다.

좋은 결과 서술에는 두 종류가 들어갑니다.

정량 결과 — 숫자로 잡히는 것

• 동시 요청 N건까지 충돌 없이 처리

• 응답 시간 평균 N ms

• 학과 학생 N명이 실제 사용

정성 결과 — 숫자가 어려운 것

• 학과 사무실의 전화 응대 업무가 줄어듦

• 시험 기간 새벽 줄서기가 사라짐

• 캡스톤 발표회의 질의 흐름이나 교수 피드백

박진주 씨의 캡스톤에 적용해 보겠습니다.

[After]

시험 기간 패턴 시뮬레이션에서 동시 요청 100건까지 충돌 누락 없이 처리했습니다. 학과 학생 약 200명이 한 학기 동안 실사용했고, 학과 사무실의 예약 응대 업무가 거의 없어졌다는 피드백을 받았습니다.

캡스톤 발표회에서는 동시성 처리 부분에 대한 질문이 가장 많이 나왔고, 이 부분이 시스템의 핵심 차별점이 되었습니다.

정량과 정성이 함께 있습니다.

그리고 "동시성 처리"가 처음부터 끝까지 일관된 주제로 흐르고 있습니다. 문제에서 던진 질문에 결과가 정확히 답하고 있는 셈입니다.

결과가 약할 때를 위한 팁도 하나 적어 두겠습니다.

신입 프로젝트는 사용자 수가 적거나 정량 지표가 부족한 경우가 많습니다. 그럴 땐 솔직하게 적되, "여기까지 갔고, 다음에 무엇을 할지 알고 있다"까지 함께 적습니다.

실제 사용자는 학과 내 30명 수준이었습니다. 다음 단계로는 다른 학과까지 확장하면서 부하 테스트를 더 큰 스케일로 진행할 계획이었습니다.

이 한 줄이 있으면 "결과가 약하다"가 아니라 "현재 위치를 알고 다음을 그릴 줄 아는 사람이다"로 읽힙니다.

인사팀은 케이스 스터디에서 무엇을 보는가

마지막으로 한 번 시점을 뒤집어 보겠습니다.

인사팀이나 개발 리더가 신입 포트폴리오의 케이스 스터디를 읽을 때, 머릿속에 던지는 질문은 이런 식입니다.

• 이 사람은 문제를 어떻게 보는가 → 문제 정의에서 드러남

• 의사결정의 근거가 있는가 → 과정 서술에서 드러남

• 실패와 어떻게 대화하는가 → 시행착오 부분에서 드러남

• 결과를 측정할 줄 아는가 → 정량·정성 결과에서 드러남

• 자기 위치를 객관적으로 아는가 → 한계와 다음 단계에서 드러남

이 다섯 가지가 케이스 스터디 한 편에 다 들어 있으면, 신입이라도 "이 사람은 일할 줄 안다"는 인상이 만들어집니다.

회사 명함이 없어도, 정규직 경력이 없어도 가능한 인상입니다.

결과물의 화려함보다 결과물을 만들어 가는 사고의 흐름이 보일 때, 포트폴리오는 비로소 내가 어떻게 일했는지가 보이는 자리가 됩니다.

처음에 박진주 씨가 적었던 한 줄과 케이스 스터디 한 편이 어떻게 달라졌는지 마지막으로 정리해 보겠습니다.

[Before]

캡스톤 프로젝트: 스터디룸 예약 시스템 4인 팀, 백엔드 담당, Spring Boot · MySQL · Redis, JWT 인증

[After — 케이스 스터디 한 편의 구조]

프로젝트명: 스터디룸 예약 시스템 (4인 팀 캡스톤, 1년)

문제 — 학과의 전화 예약 시스템이 시험 기간 새벽 줄서기를 만들었고, 기존 온라인 시스템들은 동시 예약 충돌 처리가 부실했다.

과정 — 동시성 처리에 낙관적 락과 비관적 락을 비교. 충돌 빈도와 사용자 부담을 근거로 비관적 락 선택. 초기 낙관적 락 구현에서 충돌 누락을 발견하고 비관적 락으로 전환.

결과 — 동시 요청 100건 충돌 누락 0건. 학과 학생 약 200명이 한 학기 실사용. 다음 단계: 다른 학과 확장 시 부하 테스트.

기술 스택: Spring Boot, MySQL, Redis(Lock 처리) 링크: GitHub · 데모

같은 프로젝트인데도, 위의 두 줄과 아래 한 편은 인사팀에게 다른 메시지를 줍니다.

위는 "스택을 안다"고 말하지만, 아래는 "문제를 풀 줄 안다"고 말합니다.

한 페이지에 들어갈 케이스 스터디는 보통 이 정도 분량이면 충분합니다.

너무 길면 인사팀이 다 안 읽고, 너무 짧으면 사람이 안 보입니다. 문제-과정-결과의 세 박자가 다 있는 한 페이지면, 한 프로젝트는 충분히 보입니다.

이번 글에서는 한 프로젝트를 케이스 스터디 한 편으로 푸는 법을 다뤘습니다.

그런데 포트폴리오에는 보통 여러 프로젝트가 들어갑니다. 여러 프로젝트를 어떻게 선별하고 한 페이지에 배치할지는 다음 시리즈의 주제가 될 것입니다.

디자이너의 포트폴리오에도 비슷한 막막함이 있는데, 디자이너용 가이드는 이 시리즈 2편에서 만나겠습니다.