개인 프로젝트에서 CTO가 주목하는 부분

개인 프로젝트는 회사에서 보여 주기 어려운 판단과 실행력을 드러낼 수 있는 기회입니다. 하지만 "무엇을 만들었다"만 적으면 평범해 보입니다. 읽는 사람이 주목하는 부분을 정리했습니다.

1. 왜 만들었는가

문제 상황이나 동기가 분명한지를 봅니다. "배우려고 만들었다"도 괜찮습니다. 다만 무엇을 배우려 했고, 어떻게 확인했는지가 있어야 합니다.

• 좋은 예: 직접 겪은 불편을 해결하기 위해 만들었다 / 특정 기술의 한계를 확인하려고 작은 실험을 했다
• 아쉬운 예: 유행하는 기술을 써 보려고 만들었다 (이유가 기술 이름뿐)

2. 왜 그 기술을 골랐는가

기술 목록보다 선택의 이유가 중요합니다. 다른 대안을 알고 있었는지, 무엇을 포기했는지가 한 줄이라도 있으면 이야기가 달라집니다.

3. 실제로 쓰이는가, 검증됐는가

배포되어 있고 사용자가 있다면 가장 좋습니다. 사용자가 없어도 어떻게 검증했는지를 적을 수 있습니다.

• 직접 쓰면서 겪은 문제와 개선
• 지인·커뮤니티의 피드백과 반영 내용
• 부하나 오류를 확인한 방법
• 테스트와 배포·운영 방식

4. 끝까지 이어 갔는가

처음의 기능 구현보다 그 이후에서 차이가 납니다. 장애가 났을 때 어떻게 대응했는지, 코드가 지저분해졌을 때 어떻게 정리했는지, 기능을 일부러 뺀 적이 있는지 같은 이야기가 실행력과 판단력을 보여 줍니다.

5. 내가 한 일의 범위

혼자 만든 프로젝트라면 전부 내가 한 것이니 오히려 쉽습니다. 다만 외부 라이브러리·템플릿·도구에 의존한 부분과 직접 설계한 부분을 구분해 쓰면 신뢰가 높아집니다. 도구의 도움을 받았다면 그것을 숨길 필요는 없고, 그 위에서 내가 이해하고 결정한 부분을 설명할 수 있으면 충분합니다.

이력서에는 이렇게

예시(재구성한 문장입니다)

• 약함: 개인 프로젝트 — 가계부 앱 (React, Node.js)

• 강함: 가계부를 쓰며 반복 입력이 불편해 반복 거래 자동 입력 기능을 직접 설계. 데이터가 쌓이며 조회가 느려지자 목록 조회 방식을 바꾸고 기준 응답 시간을 정해 확인. 현재 지인 10여 명이 사용 중이며 받은 피드백으로 화면을 두 차례 개편

(위 문장은 형식을 보여 주기 위한 예시이며 실제 사례가 아닙니다.)

점검 질문

1. 이 프로젝트를 한 문장으로 설명할 수 있는가 (누구의 어떤 문제를 푸는가)
2. 가장 어려웠던 결정은 무엇이고 왜 그렇게 정했는가
3. 지금 다시 만든다면 무엇을 바꾸겠는가
4. 결과를 누가 확인할 수 있는가 (링크, 저장소, 시연)

완성도보다 생각이 보이는 프로젝트가 기억에 남습니다.