기술 이름보다 먼저 보여줄 문제
서버 개발, 화면 개발, 배포 자동화라는 업무명은 경험의 출발점입니다. 그 일을 왜 했는지가 이어져야 다른 개발자가 프로젝트를 이해할 수 있습니다. 요청이 몰리는 시간에 응답 지연이 있었는지, 변경할 때마다 같은 오류가 생겼는지, 운영자가 수작업으로 처리하는 단계가 많았는지를 먼저 적습니다. 문제의 영향 범위를 설명하되 서비스 내부 수치와 고객 정보는 공개 가능한 수준으로 제한하세요.
기술 스택은 문제 해결의 맥락 안에 놓습니다. 특정 도구를 사용했다는 사실과 그 도구를 운영할 수 있다는 주장은 다릅니다. 튜토리얼에서 사용한 경험, 기능을 구현한 경험, 장애를 분석한 경험을 구분하면 면접에서 기술 수준을 설명하기 쉽습니다. 원티드의 개발자 이력서 안내를 참고할 수 있지만 특정 도구를 적으면 채용 결과가 좋아진다는 식으로 일반화하지 않습니다.
나의 구현 범위를 경계로 나누기
프로젝트 전체 구조와 직접 담당한 부분을 구분합니다. 결제 서비스에 참여했다고 썼다면 승인 요청, 정산, 취소 처리 중 어느 부분을 맡았는지 밝힙니다. 설계 제안, 구현, 테스트, 배포, 운영 중 어디까지 책임졌는지도 적으세요. 팀장이 정한 구조를 구현한 경우 이를 전체 아키텍처를 설계했다고 바꿔 쓰지 않습니다. 대신 구현 중 발견한 제약과 해결한 문제를 설명할 수 있습니다.
기여도 퍼센트가 없는 것이 결함은 아닙니다. 담당 모듈, 수정한 흐름, 검증한 조건이 분명하면 역할을 구체적으로 이해할 수 있습니다. 코드 줄 수나 커밋 수를 개인 성과의 유일한 근거로 삼는 것도 피하세요. 유지보수 과정에서 불필요한 코드를 줄인 작업은 줄 수가 감소할 수 있고, 공동 작업은 기록 방식에 따라 수치가 달라집니다. 실제 책임과 결정에 초점을 맞춥니다.
가상 사례: 조회 지연을 개선한 경험
가상 사례의 출발 문장은 조회 기능 성능 최적화입니다. 이를 풀어 쓰면 운영 화면의 검색 조건이 늘면서 동일한 데이터에 반복 조회가 발생한 상황입니다. 담당자는 조회 흐름을 확인하고 중복 요청을 줄이는 변경과 쿼리 구조 수정을 비교했습니다. 자신의 역할은 서버 조회 로직 수정과 테스트 작성이었으며, 데이터베이스 구조 변경은 동료가 검토했습니다. 이 정보만으로도 어떤 종류의 일을 했는지 더 선명해집니다.
결과를 쓸 때는 같은 테스트 데이터와 부하 조건에서 변경 전후를 비교했는지 적습니다. 가상 수치로 평균 응답 시간이 이백 밀리초에서 백사십 밀리초로 줄었다면 비교 조건을 함께 제시해야 합니다. 이 숫자는 작성 방법을 설명하기 위한 예시이며 독자의 성과로 옮겨 쓸 수 없습니다. 실제 운영 결과를 확인하지 않았다면 테스트 환경 결과라고 명시하고 운영 개선으로 확대 해석하지 않습니다.
선택하지 않은 대안도 짧게 남기기
기술 선택은 장점만 나열할 때보다 대안과 제약을 설명할 때 구체적입니다. 캐시를 추가할지 조회 구조를 바꿀지 고민했다면 데이터의 갱신 빈도와 일관성 요구가 어떤 영향을 주었는지 적습니다. 최종적으로 선택한 방법이 모든 상황에서 최선이었다고 주장할 필요는 없습니다. 당시 서비스 규모와 운영 비용, 팀이 관리할 수 있는 범위 안에서 판단했다는 맥락을 제공하세요.
대안 비교를 너무 길게 쓰면 경력기술서가 설계 문서가 될 수 있습니다. 본문에는 중요한 판단 하나를 남기고 세부 설명은 면접용 메모로 분리합니다. 면접에서는 왜 그 조건을 먼저 확인했는지, 선택이 실패할 수 있는 경우는 무엇인지까지 연습해볼 수 있습니다. 실제로 검토하지 않은 대안을 뒤늦게 검토했다고 꾸미지 말고, 지금 다시 한다면 고려할 사항으로 구분하세요.
검증은 속도 외에도 가능하다
성능 수치만이 개발 성과는 아닙니다. 오류 재현 조건을 정리했는지, 배포 실패를 조기에 확인할 수 있게 했는지, 반복적인 운영 절차를 줄였는지도 결과가 될 수 있습니다. 테스트를 추가했다면 단순 개수보다 어떤 실패 조건을 검증하게 되었는지 설명하세요. 문서화 작업이라면 새 담당자가 어떤 정보를 찾을 수 있게 되었는지, 실제 인수인계에서 사용되었는지 적습니다.
아직 효과를 측정하지 못한 변경은 적용한 사실과 기대 효과를 분리합니다. 장애가 재발하지 않았다는 문장도 관찰 기간이 필요합니다. 변경 후 일주일간 동일 조건의 오류를 관찰하지 못했다는 사실과 영구적으로 해결했다는 주장은 다릅니다. 관찰의 범위를 밝히는 태도는 수치를 화려하게 만드는 것보다 정확한 기술 커뮤니케이션에 가깝습니다. 기록이 없다면 기억만으로 복잡한 지표를 만들지 않습니다.
링크와 문서를 면접에 연결하기
공개 저장소가 있다면 프로젝트 목적, 실행 방법, 직접 기여한 부분을 읽기 쉽게 정리합니다. 회사 코드나 내부 문서를 허가 없이 공개하지 않습니다. 링크를 제출하지 못하더라도 공개 가능한 범위의 구조 설명과 검증 방식으로 경험을 보여줄 수 있습니다. 링크가 열리지 않아도 경력기술서 본문만으로 문제와 역할을 파악할 수 있어야 합니다.
경력노트의 행동 칸에는 수정한 대상과 선택 이유를, 결과 칸에는 검증한 조건을 적습니다. 사용 기술 칸은 기술을 배웠다는 목록보다 실제 사용 범위를 담는 데 활용하세요. STAR 형식으로 바꾸어 읽은 뒤 왜 이 문제가 발생했는지, 내가 바꾼 부분은 어디인지, 다른 환경에서도 같은 선택을 할 것인지 답해봅니다. 설명이 막히는 부분은 기술 이름을 추가하기보다 사실을 다시 확인할 지점입니다.
자주 묻는 질문
개발 도구 숙련도를 퍼센트로 써야 하나요?
객관적인 기준이 없다면 퍼센트보다 실제 사용 과제와 책임 범위를 적는 편이 명확합니다. 기능 구현, 운영, 장애 분석 경험을 구분해보세요.
개인 프로젝트도 경력기술서에 넣나요?
지원 직무와 관련되고 직접 한 일을 설명할 수 있다면 경험 항목으로 넣을 수 있습니다. 유급 근무 경력과 혼동되지 않도록 개인 프로젝트라고 표시하세요.