개발 직군 경력기술서는 **"어떤 문제를, 어떤 기술적 판단으로, 어떻게 해결했는가"**를 보여 주는 문서입니다. 사용한 기술 목록만 길게 나열하면 면접관은 그 기술로 실제로 무엇을 했는지 알 수 없습니다. 이 글은 개발자 경력기술서에서 강조할 점과 프로젝트 예시를 정리합니다. 기본 구조는 경력기술서 작성 가이드를 먼저 참고하세요.
아래 회사·프로젝트·숫자는 모두 작성법을 설명하기 위한 가상 예시입니다. 본인이 실제로 확인할 수 있는 내용으로 바꿔 쓰세요.
개발 경력기술서에서 확인하는 것
| 항목 | 면접관이 알고 싶은 것 |
|---|---|
| 맡은 범위 | 기능 전체를 맡았는지, 일부 모듈만 맡았는지 |
| 기술적 판단 | 왜 그 기술·구조를 골랐는지, 다른 선택지는 무엇이었는지 |
| 문제 해결 | 장애, 성능 저하, 복잡한 요구사항을 어떻게 풀었는지 |
| 결과 | 속도, 안정성, 개발 효율이 어떻게 달라졌는지 |
| 협업 방식 | 코드 리뷰, 배포 과정, 기획·디자인과의 소통 |
프로젝트 예시 1: 주문 조회 API 성능 개선 (가상)
고치기 전
주문 조회 API 개선. Spring Boot, JPA, Redis 사용.
고친 후
주문 조회 API 응답 속도 개선 (2024.02 ~ 2024.03, 백엔드 3명 중 담당 1명)
- 배경: 주문이 많은 판매자 계정에서 주문 목록 화면이 느리다는 문의가 반복됨
- 쿼리 로그를 분석해 주문 목록 조회 시 상품 정보를 건마다 따로 불러오는 문제(N+1)를 확인함
- 조회용 쿼리를 한 번에 가져오도록 바꾸고, 자주 바뀌지 않는 판매자 설정은 Redis 캐시로 분리함
- 변경 전후 응답 시간을 같은 조건으로 측정해 팀에 공유함
- 결과: 주문 목록 평균 응답 시간 약 1.8초 → 0.4초 (사내 모니터링 기준)
- 사용 기술: Spring Boot, JPA, Redis, MySQL
포인트는 **문제를 어떻게 발견했는지(쿼리 로그 분석)**와 **결과를 어떻게 측정했는지(같은 조건 비교)**가 함께 들어간 것입니다. 숫자를 쓴다면 측정 기준을 밝혀 두면 면접에서 설명하기 쉽습니다.
프로젝트 예시 2: 배포 과정 자동화 (가상)
배포 자동화 파이프라인 구축 (2023.08 ~ 2023.10, 단독 진행)
- 배경: 수동 배포 과정에서 설정 파일 누락으로 장애가 두 차례 발생함
- GitHub Actions로 테스트 → 빌드 → 스테이징 배포 → 승인 후 운영 배포 순서를 자동화함
- 환경별 설정을 분리하고 배포 전 필수 값 점검 단계를 추가함
- 팀원용 배포 가이드 문서를 작성함
- 결과: 이후 6개월간 설정 누락으로 인한 배포 장애 없음, 배포 담당자 없이도 팀원 누구나 배포 가능
- 사용 기술: GitHub Actions, Docker, AWS ECS
수치가 없는 개선이라도 "무엇이 가능해졌는지"(누구나 배포 가능)를 쓰면 결과가 됩니다.
자주 하는 실수
- 기술 이름만 나열하기: "React, TypeScript, Next.js 사용"은 결과가 아닙니다. 그 기술로 무엇을 만들었는지가 먼저입니다.
- 팀 전체 성과를 내 성과처럼 쓰기: "서비스 MAU 2배 성장"은 내가 한 일과의 연결을 설명할 수 있을 때만 씁니다.
- 너무 깊은 구현 설명: 함수 이름이나 코드 수준의 설명은 면접이나 포트폴리오로 넘기고, 경력기술서에는 판단과 결과를 씁니다.
- 회사 내부 시스템 이름 그대로 쓰기: "OMS v2" 대신 "사내 주문 관리 시스템"처럼 기능으로 설명합니다.
공고 키워드와 연결하기
공고에 "대용량 트래픽 처리", "성능 최적화", "CI/CD 경험"이 있다면, 위 예시 1은 성능 최적화, 예시 2는 CI/CD 경험과 연결됩니다. 공고 단어를 억지로 넣기보다 이미 한 일을 공고의 표현으로 설명하는 것이 자연스럽습니다.
프로젝트 메모를 위 구조로 정리하고 싶다면 AI 경력기술서 정리를 사용해 보세요. 메모에 없는 숫자는 만들지 않고, 빠진 정보는 따로 알려 줍니다.