개발자 경력기술서
경력기술서 마스터·9분·
이 직무에서 어려운 것은 무엇을 적을지가 아니라 어디서 끊을지입니다. 만들고 고치고 다시 올리는 흐름에는 눈에 띄는 끝이 없어서, 끊는 자리를 스스로 정하지 않으면 문서가 다뤄 본 기술의 목록으로 바뀝니다.
직무별로 무엇을 적으라고 정해 둔 규정은 찾지 못했습니다 · 아래 서술은 채용을 다루는 곳들이 안내해 온 관행이며 심사 기준이 아닙니다
다뤄 본 것을 늘어놓은 줄
- ○○ 서비스 백엔드 개발 (2021.03 ~ 2024.02)
- 사용해 본 언어와 도구를 첫 줄에 나열
- 재직 기간 전체가 한 덩어리로 붙어 있음
- 무엇을 왜 손댔는지가 빠져 있음
- 운영과 장애 대응은 적을 것이 없다고 뺌
맡은 일로 잘라 세운 줄
- 주문 조회가 몰릴 때 응답이 늦던 문제 (2021.06 ~ 2021.10)
- 그 일에서 실제로 쓴 것만 그 줄 안에 적음
- 손댄 대상이 달라진 지점에서 잘라 놓음
- 왜 손대게 되었는지가 줄의 앞에 있음
- 장애가 되풀이되던 구간을 한 줄로 세움
이 일에는 눈에 띄는 끝이 없습니다
끊을 자리를 찾기 어려운 것은 일이 멈추지 않고 이어지기 때문입니다.
다른 직무에서는 맡은 일에 대체로 끝이 붙어 있습니다. 행사가 열리고 닫히거나, 계약이 맺어지거나, 보고서가 넘어가는 식입니다. 그 지점을 잡으면 한 줄의 끝이 저절로 정해집니다.
만드는 일은 그렇지 않습니다. 한 번 올린 것을 다시 고치고 그 위에 다른 것을 얹는 방식으로 굴러가서, 어제 손댄 자리와 오늘 손대는 자리가 이어져 있습니다. 지난달에 마쳤다고 말할 만한 지점이 잘 잡히지 않고, 잡았다 싶으면 그 뒤에도 같은 자리를 계속 만지고 있습니다.
여기에 자리 배치가 겹칩니다. 한 사람이 한 가지만 붙들고 있는 경우는 드물고, 새로 만드는 일과 이미 굴러가는 것을 지키는 일과 갑자기 터진 것을 막는 일이 같은 주에 섞입니다. 달력을 놓고 보면 세 가지가 겹쳐 흐르는 모양이 됩니다.
그래서 빈 문서를 열면 손이 멈춥니다. 적을 것이 없어서가 아니라 어디서부터 어디까지를 한 덩어리로 부를지 정해지지 않아서입니다. 이 직무에서 첫 어려움은 문장이 아니라 경계에 있습니다.
경계를 정하지 않으면 두 방향으로 무너집니다
다닌 곳으로 되돌아가거나, 다뤄 본 것의 목록으로 바뀝니다.
경계를 정하지 못한 채로 칸을 채우려 하면 손이 가는 방향이 대체로 둘입니다. 하나는 이력서와 같은 기준으로 되돌아가는 것이고, 다른 하나는 이름을 나열하는 것입니다. 둘 다 문서를 채우기는 하는데 남는 것이 다릅니다.
아래 표는 두 방향이 문서에 어떤 모양으로 남는지, 그리고 받아 읽는 쪽에서 무엇이 사라지는지를 정리한 것입니다.
| 무너지는 방향 | 문서에 남는 모양 | 읽는 쪽에서 사라지는 것 |
|---|---|---|
| 다닌 곳으로 되돌아감 | 소속별 한 덩어리 | 그 안에서 무엇이 달라졌는지 |
| 다뤄 본 것을 나열함 | 이름의 목록 | 어느 수준까지 손댔는지 |
| 최근 것만 적음 | 앞부분이 비어 있음 | 어떻게 그 자리까지 왔는지 |
| 새로 만든 것만 적음 | 빠짐없어 보임 | 실제로 시간을 많이 쓴 구간 |
| 결과 화면만 적음 | 만든 것의 소개 | 그 안에서 내가 맡은 자리 |
둘째 줄이 이 직무에서 가장 흔합니다. 이름을 늘어놓으면 아는 것이 많아 보이지만, 어느 이름 하나도 어디까지 다뤄 봤는지를 알려 주지 않습니다. 그러면 확인은 뒤로 넘어가고 대화 자리에서 그 목록부터 하나씩 물어보게 됩니다.
다섯째 줄은 표시가 다르게 보일 수 있어 덧붙입니다. 만든 것을 소개하는 글은 그 자체로 잘 읽히는데, 그 안에서 내가 어느 부분을 맡았는지가 빠져 있으면 회사 소개와 구별되지 않습니다. 여기서 필요한 것은 만든 것의 설명이 아니라 맡은 자리의 설명입니다.
잘라 세울 자리를 알려 주는 신호
날짜가 아니라 손댄 대상이 달라진 지점을 찾습니다.
끝이 없는 흐름에서 경계를 찾으려면 달력 대신 다른 표시를 봐야 합니다. 아래 다섯 가지는 이 직무에서 비교적 잡기 쉬운 표시들입니다. 하나씩 대 보면 붙어 있던 덩어리가 몇 개로 갈라지는지가 드러납니다.
- 손댄 대상이 바뀐 지점화면을 만지다가 처리 쪽으로 옮겨 갔거나, 하나의 덩어리를 여럿으로 나눈 시점입니다. 같은 서비스를 계속 보고 있었더라도 만지는 자리가 달라졌다면 그 앞뒤는 서로 다른 경험으로 읽힙니다.
- 바깥으로 나간 지점올렸거나 열었거나 다른 팀이 쓰기 시작한 순간입니다. 완성이라고 부를 수는 없어도 남에게 넘어간 지점이므로 줄의 끝으로 삼을 수 있습니다.
- 맡은 범위가 넓어진 지점혼자 맡던 것을 나눠 맡게 되었거나, 정하는 자리에 들어가게 된 시점입니다. 범위가 달라진 앞뒤를 한 줄로 묶으면 어느 쪽 경험인지 가려지지 않습니다.
- 되풀이되던 문제가 멎은 지점같은 장애가 반복되다가 원인을 잡아 멎었다면 그 구간 자체가 하나의 줄이 됩니다. 새로 만든 것이 없어도 시작과 끝이 분명한 드문 경우입니다.
- 아무 표시도 잡히지 않는 구간몇 달을 들여다봐도 표시가 없다면 지키는 일만 계속한 구간일 수 있습니다. 이때는 다음 절의 방식으로 따로 다룹니다.
첫째와 둘째를 함께 쓰면 대부분의 덩어리가 갈립니다. 손댄 자리가 달라진 지점에서 열고 바깥으로 나간 지점에서 닫으면, 달력에 기대지 않고도 줄의 앞뒤가 정해집니다.
다섯째를 남겨 둔 이유가 있습니다. 표시가 없는 구간을 억지로 잘라 세우면 무엇을 했다고 적을지가 마땅치 않아 결국 이름 나열로 돌아갑니다. 그 구간은 다른 방식으로 세워야 합니다.
새로 만든 것이 아니었던 구간
지키는 일에도 시작과 끝이 있습니다. 다만 표시가 다른 곳에 있습니다.
이미 굴러가는 것을 지키는 일은 눈에 보이는 산출물이 남지 않습니다. 그래서 적을 것이 없다고 여기고 통째로 빼는 경우가 많은데, 실제로 시간을 가장 많이 쓴 구간이 그쪽인 사람도 적지 않습니다. 그 구간이 비어 있으면 문서에는 몇 달치 공백이 남습니다.
지키는 일에서 경계를 찾을 때는 만들어 낸 것이 아니라 달라진 상태를 봅니다. 무엇이 자주 터지다가 멎었는지, 손으로 하던 것이 저절로 되게 바뀌었는지, 남이 알아야 알던 것이 적혀 있게 되었는지 같은 표시입니다. 셋 다 확인할 수 있는 변화이고 그래서 줄의 끝이 됩니다.
옮겨받거나 넘겨준 일도 같은 방식으로 다룹니다. 남이 만들어 둔 것을 받아 이어서 굴린 구간은 어디까지가 받은 상태였고 어디부터가 내가 바꾼 것인지를 밝혀 두면 하나의 줄이 됩니다. 이 구분을 흐려 두면 앞사람이 만든 것을 내 것처럼 적은 모양이 됩니다.
밖에 내보일 수 없는 일도 자주 걸립니다. 안에서만 쓰는 것이거나 조건상 밝힐 수 없는 것이라면 무엇을 만들었는지를 자세히 적을 수 없는데, 그렇다고 그 구간을 빼야 하는 것은 아닙니다. 다루는 대상의 성격과 맡은 자리와 달라진 상태까지는 대개 적을 수 있습니다.
달라진 상태를 표시로 삼습니다. 되풀이되던 문제가 멎었거나 손으로 하던 절차가 줄어든 지점을 찾아 그 구간을 한 줄로 세웁니다.
받았을 때의 상태와 넘길 때의 상태를 함께 적습니다. 그 두 값의 차이가 그 줄에서 내가 한 일입니다.
대상의 성격과 규모만 적고 이름은 빼도 됩니다. 밝힐 수 없다는 사실을 적어 두면 읽는 쪽에서도 그렇게 받아들입니다.
맡은 자리와 결과가 분명하면 세울 수 있습니다. 다만 일로 한 것과 혼자 한 것을 섞어 두면 어느 쪽인지 가려지지 않으므로 구분해 두는 편이 낫습니다.
둘째 문답이 이 절의 중심입니다. 이어받은 구간에서 앞사람의 몫과 내 몫이 섞이면 뒤에 확인이 들어갔을 때 어긋나고, 그 어긋남은 그 줄만이 아니라 문서 전체의 값을 떨어뜨립니다.
이 직무에서 자주 갈리는 오해
목록의 길이 · 최신 여부 · 보여 줄 것의 유무 — 셋이 가장 자주 걸립니다.
첫째, 다뤄 본 이름이 많을수록 낫다는 것입니다. 목록이 길어지면 그중 어느 것도 깊이가 보이지 않고, 확인해 보면 이름만 아는 것이 섞여 있는 경우가 생깁니다. 하나가 흔들리면 나머지도 함께 의심을 받으므로, 근거를 붙일 수 있는 것만 남기는 편이 낫습니다.
둘째, 최근에 많이 쓰이는 것을 다뤄야 값이 나간다는 것입니다. 무엇을 다뤘는지보다 그것으로 어떤 문제를 어디까지 풀었는지가 읽히는 대목이고, 오래된 것을 오래 다룬 경험도 그 안에서 무엇을 판단했는지가 적혀 있으면 그대로 읽힙니다. 이름을 바꿔 적는 손질이 아니라 판단을 적는 손질이 필요합니다.
셋째, 보여 줄 것이 없으면 적을 것도 없다는 것입니다. 밖에 내보일 수 있는 결과가 있으면 편하기는 하지만, 그것이 없다고 맡았던 일이 사라지는 것은 아닙니다. 이 문서가 요구하는 것은 구경거리가 아니라 무엇을 맡아 어떻게 판단했는지의 기록입니다.
셋을 합치면 하나로 모입니다. 이 직무의 문서가 흔들리는 자리는 기술의 종류가 아니라 경계와 판단이 비어 있는 자리라는 것입니다. 경계를 정하고 그 안에 판단을 적으면 이름은 저절로 제자리에 들어갑니다.
줄 하나를 다시 볼 때
넷째 줄을 넣어 둔 이유가 있습니다. 도구의 이름을 문서 맨 앞에 몰아 두면 어느 줄에서 무엇을 썼는지가 사라지고, 목록만 남습니다. 각 줄 안에서 그 일에 실제로 쓴 것만 적으면 목록을 따로 두지 않아도 됩니다.
여섯 줄이 다 채워졌다면 남은 것은 결과 칸의 숫자입니다. 무엇을 분모로 삼고 어느 구간을 잘랐는지는 성과를 숫자로 적는 문제를 따로 다룬 글에 정리해 두었습니다.
자주 묻는 질문
개발자 경력기술서는 기술 스택을 먼저 적어야 하나요?
이름을 앞에 몰아 두면 어느 일에서 무엇을 썼는지가 사라집니다. 각 줄 안에서 그 일에 실제로 쓴 것만 적는 방식이 실무에서 많이 쓰입니다.
운영과 유지보수만 한 기간이 있습니다.
달라진 상태를 표시로 삼아 세웁니다. 되풀이되던 문제가 멎었거나 손으로 하던 절차가 줄어든 지점이 그 구간의 끝이 됩니다.
하나의 일을 어디서 끊어야 할지 모르겠습니다.
손댄 대상이 달라진 지점, 바깥으로 나간 지점, 맡은 범위가 넓어진 지점이 표시가 됩니다. 입사일과 퇴사일은 표시가 되지 않습니다.
사내에서만 쓰는 것이라 밝힐 수 없습니다.
대상의 성격과 규모까지만 적고 이름은 빼도 됩니다. 밝힐 수 없는 대상이라는 사실을 적어 두면 읽는 쪽에서도 그렇게 받아들입니다.
보여 줄 결과물이 없으면 불리한가요?
이 문서가 요구하는 것은 구경거리가 아니라 무엇을 맡아 어떻게 판단했는지의 기록입니다. 결과물이 없어도 맡은 자리와 달라진 상태를 적으면 읽힙니다.
오래된 기술만 다뤄 봤습니다.
무엇을 다뤘는지보다 그것으로 어떤 문제를 어디까지 풀었는지가 읽히는 대목입니다. 그 안에서 무엇을 판단했는지를 적으면 그대로 전달됩니다.




