나는 이력서와 서면 인터뷰를 많이 검토하는데, 그중 상당수는 형편없이 쓰여 있다. 이 글에서는 소프트웨어 엔지니어 직무에 지원할 때 하지 말아야 할 몇 가지를 이야기한다.

나는 Canonical에서 일한다(우리의 채용 과정에 대해서는 맺음말을 참고 바란다). 하지만 이 조언은 어느 회사에 지원하든 유용하다고 믿는다.

이 글의 대부분은 글쓰기에 대한 조언으로, 이력서나 커버 레터, 그리고 지원 과정에서 요구되는 다른 모든 서면 자료를 작성할 때 유용하다. 사실, 이 조언 대부분은 어떤 종류의 논픽션 글쓰기에도 적용된다고 생각한다.

본론에 들어가기 전에, 독자가 누구인지 기억하자. 바쁜 채용 담당자나 수백 건의 지원서를 검토해야 하는 엔지니어다. 그들은 제한된 정보로 결정을 내려야 하며, 눈에 띄고, 무언가를 만들어 본 경험이 있으며, 소통을 잘하는 사람을 채용하고 싶어 한다.

ChatGPT를 쓰지 마세요

그저 도구일 뿐이라는 건 안다. 하지만 내 말을 끝까지 들어 달라. 처음에는 “ChatGPT를 쓰지 마세요”라는 말에 “혹은 쓰더라도 신중하게 쓰세요”라는 단서를 달았다. 하지만 지금 나의 강력한 권고는 그냥 쓰지 말라는 것이다. 적어도 2023년 9월 기준으로, ChatGPT는 당신을 로봇처럼 들리게 만들 뿐이다.

지원자들이 (눈에 띄게) AI를 이용해 지원서를 쓰기 시작했을 때, 나는 “부정행위”라고 간주해 탈락시켰다. 그 후로는 방식을 바꿨다. 모든 지원서를 사람이 쓴 것처럼 평가하고, 내용이 나쁘면 탈락시킨다.

문제는 AI 도구를 확연히 사용한 지원서는 모두 형편없다는 것이다. 문법은 완벽할지 몰라도, 지루하기 짝이 없고 지원자의 경험이 거의 혹은 전혀 담겨 있지 않다.

우리 회사가 묻는 질문 중 하나는 꽤 개방적인 질문이다: “소프트웨어 운영 및 프로덕션 서비스 운영 경험에 대해 설명해 보세요”. 다음은 대표적인 ChatGPT 답변이다:

저는 소프트웨어 운영 및 프로덕션 서비스 관리 분야에서 5년의 경험을 보유하고 있습니다. 이전 직무에서 Python과 Golang과 같은 다양한 기술과 도구 세트를 활용하여 프로덕션 서비스를 배포하고 유지하는 데 중추적인 역할을 했습니다. 배포 및 릴리스 관리 프로세스를 성공적으로 감독했고, 시스템 상태를 보장하기 위해 견고한 모니터링 솔루션을 구현했으며, 신속한 해결과 근본 원인 분석을 강조하며 인시던트를 효과적으로 관리했습니다. 또한 증가하는 수요에 대응하기 위한 확장성 개선과 시스템 성능 향상을 위한 최적화 작업 경험도 있습니다.

왜 이 답변이 그렇게 끔찍한가? 구체성 없이 화려하고 수동적인 문체로 쓰였기 때문이다. 흥미롭거나 개인적인 내용이 전혀 없고, 거의 모든 소프트웨어 엔지니어를 설명해도 될 법한 내용이다.

다음과 같은 흥미롭고 개인적인 답변과 비교해 보자:

저는 삼촌의 자동차 정비소를 위해 자동차 부품을 추적하는 웹사이트(PHP와 MySQL 사용)를 만들면서 프로그래밍을 배웠습니다. 웹사이트에 1분마다 핑을 보내 오류가 발생하면 이메일을 보내주는 간단한 헬스 체크 시스템을 추가했습니다. 첫 직장에 들어간 직후에는 Ansible과 Python 스크립트를 이용해 온콜 절차 중 많은 부분을 자동화했습니다. 최근에는 Terraform으로 관리되는 EKS 클러스터에서 실행되는 세 개의 마이크로서비스를 담당하는 팀에 있었습니다. 회사에서 Datadog 로깅 및 모니터링을 구축했고, DevOps 팀과 함께 온콜 로테이션에 참여했습니다.

구체적이고, 흥미롭고, 진짜 경험이다! 예를 들어 자동화가 팀에 어떤 도움이 되었는지 설명하면 더 좋아질 수 있다: “이 덕분에 배포 시간이 2시간에서 15분으로 단축되었습니다”. 하지만 이미 첫 번째 답변보다는 훨씬 낫다.

영어가 모국어가 아니어도 괜찮다. 나는 경험이 담기지 않은 완벽한 문장보다, 당신의 경험을 반영한 다소 서툰 글을 훨씬 더 선호한다.

더 나은 프롬프트가 ChatGPT를 더 진짜처럼 들리게 할까? 그렇다, 더 나은 프롬프트가 문장을 다듬을 수는 있다. 하지만 그것이 당신의 개인적인 경험을 바탕으로 마법처럼 글을 써주지는 않는다. 글에 맞춤법 및 문법 검사기를 사용하는 것은 물론 괜찮지만, 반드시 당신의 글이어야 한다.

화려한 문장을 쓰지 마세요

위와 같은 문장을 쓰지 마세요: “Python과 Golang과 같은 다양한 기술과 도구 세트를 활용하여”. 요점이 거창한 단어들 속에 묻혀 버린다. 그냥 “저는 Python과 Go를 사용했습니다”라고 말하세요. 검토자가 고마워할 것이다.

다른 예로, 한 지원자는 다음과 비슷한 말을 했다. 그들은:

• 깊이 있는 숙련을 갖췄다고 했다 (그들은 James Gosling이 아니다)
• 그들의 여정이 시작되었다고 했다 (그들은 Bilbo Baggins가 아니다)
• 능숙하게 프로그램을 구축했다고 했다 (그들은 Stradivarius가 아니다)
• 전문성을 확장했다고 했다 (전문가일 뿐 아니라, 확장된 전문가다)
• Lambda 함수를 정성껏 제작했다고 했다 (나는 장인 정신이 담긴 Lambda를 선호한다)
• Spring Boot를 활용했다고 했다 (그냥 사용한 것 아닌가?)
• 신속하게 적응했다고 했다 (이제 좀 식상하다)
• 문서를 꼼꼼하게 읽었다고 했다 (좋다, 교정자로 채용해야겠다)
• 객체 지향 프로그래밍을 포용했다고 했다 (90년대 모든 사람들처럼)
• 견고한 경험을 선보였다고 했다 (그런데 견고한 Forth 경험도 있는 건가?)

ChatGPT를 의심했지만, 확실하지는 않다. 그냥 유의어 사전을 쓴 것일 수도 있다. 어느 쪽이든, 부사와 형용사를 11까지 끌어올리지 마세요.

과장된 수식어를 빼고 그 목록을 다음과 같이 다시 쓰는 것을 추천한다:

• 저는 Java 경험이 있습니다
• 시작했습니다
• 만들었습니다
• 배웠습니다
• Lambda 함수를 작성했습니다
• Spring Boot를 사용했습니다
• 적응했습니다
• 문서를 읽었습니다
• 객체 지향 프로그래밍을 사용합니다 (혹은 이 항목은 아예 빼세요)
• 경험을 쌓았습니다

말하지 말고, 보여 주세요!

이건 간단하다. 독자에게 어떻게 생각해야 할지 말하지 말고, 당신이 무엇을 했는지 보여 주세요. 위의 나쁜 예시들은 단순히 문장이 화려한 게 아니라, 보여 주는 대신 말만 하고 있다.

“저는 능숙하게 프로그램을 구축했습니다”라고 말하는 것은 독자에게 당신에 대해 어떻게 생각해야 할지 강요하는 것이고, “저는 500줄의 Java로 POSIX Make의 빠른 서브셋을 만들었습니다”라고 쓰는 것은 당신이 무엇을 만들었는지 보여 주는 것이다. 그것이 오픈 소스이고 GitHub 저장소로 링크할 수 있다면 더 좋다.

당신은 채용 담당자를 위해 글을 쓰고 있다는 것을 기억하세요. 그는 당신이 구체적으로 무엇을 성취했는지 보고 싶어 한다.

뻔한 내용을 쓰지 마세요

우리의 또 다른 면접 질문은 “프로덕션 서비스의 새로운 기능을 어떻게 설계하고 구현하겠습니까?”이다.

많은 지원자들은 (이번에도 아마 AI 도구의 도움을 받아) 이 질문에 대해 “교과서에서는 소프트웨어 개발 생명주기를 어떻게 정의하는가”에 대한 답을 내놓는다. 하지만 우리가 듣고 싶은 것은 당신의 경험이며, 당신만의 언어로 풀어낸 기술적인 세부 사항이다.

다음 문단은 너무 일반적이다:

새로운 소프트웨어를 설계하고 구현하는 것은 요구사항 수집, 명세서 작성, 이해관계자의 피드백 수렴, 그리고 수준 높은 구현으로 시작됩니다. 구현이 끝난 후에는 자동화된 테스트와 수동 QA가 중요합니다. 그 다음 소프트웨어를 배포하고 제대로 모니터링합니다.

대신 다음과 같이 써 보세요:

저는 간결한 명세서와 사전 계획을 선호합니다. 예를 들어 새로운 인증 서비스를 설계할 때, 저는 아키텍처 다이어그램과 API 엔드포인트에 대한 간략한 설명을 포함한 3페이지짜리 명세서를 작성했습니다. 프로덕션에 배포하기 전에는 실제 서버에 대한 부하 테스트가 중요하다고 생각해서, 유사한 스테이징 환경을 구축하고 동시 요청을 얼마나 처리할 수 있는지 측정했습니다. 프로덕션에 올라간 후에는 모니터링이 매우 중요합니다. 저는 Datadog과 Prometheus 같은 오픈 소스 도구를 사용해 문제를 탐지하고 진단해 왔습니다.

요컨대, 뻔한 내용을 쓰지 마세요. 물론 파라메트릭 다형성에 대해 쓰고 있다면 예외지만요. (농담입니다, 참을 수 없었네요.)

유행어 빙고를 하지 마세요

이것은 화려한 문장과 뻔한 내용과 밀접하게 연결된다. 별 의미 없는 비즈니스 전문 용어를 쓰지 않도록 하세요. 오늘 아침에 다음과 같은 문장을 봤다:

포괄적인 데이터 해석 및 분석을 수행하여 고객 가치를 제공하는 실행 가능한 인사이트를 도출했습니다.

The Office의 패러디처럼 들리는 것을 제외하고도, 이 문장은 사실상 아무 말도 하지 않는다. 컴퓨터 앞에서 일하는 거의 모든 사람이 “데이터를 해석하고 분석”하며, 바라건대 고객에게 가치를 주는 “실행 가능한 인사이트를 도출”한다.

유행어를 쓰면 어떤 사람들에게는 똑똑해 보일지 모르지만, 나는 그것이 별다른 말을 하고 있지 않다는 사실을 가릴 뿐이라고 생각한다.

데이터 사이언티스트로 일한다면, 대신 다음과 같이 말해 보세요:

Sunnyville Hospital에서 데이터 사이언티스트로 일하며, 저는 Python과 Pandas를 사용해 의료 장비에서 나오는 방대한 양의 데이터(하루 수 기가바이트)를 분석하여, 의사들이 수술실 절차를 개선하는 데 도움이 될 이상 징후를 찾습니다.

지시 사항을 무시하지 마세요

이건 굳이 말할 필요도 없다고 생각할지 모르지만, 일부 지원자들은 지시 사항을 잘 따르지 않는 것 같다.

예를 들어, 지원서에 “편향을 줄이기 위해 서면 인터뷰는 익명으로 작성해 주세요”라고 되어 있는데 맨 위에 실명을 적는다면, 좋은 신호는 아니다. 누구나 실수할 수 있으니 그것만으로 지원서를 탈락시키지는 않지만, 지시 사항을 무시하는 것이 당신에게 유리하게 작용하지는 않을 것이다.

이력서에 대한 몇 가지 팁

위의 모든 조언은 이력서(CV)에 쓰는 내용에도 적용된다. 다만, 이력서에 특화된 몇 가지 추가 팁을 소개한다.

GitHub 프로필을 확인하세요

GitHub 프로필 링크를 첨부한다면, 그 안에 괜찮은 프로젝트가 있는지 확인하세요. 만약 fork-of-popular-project-i-never-touched, random-university-assignment, half-baked-data-science-script 같은 프로젝트만 잔뜩 있다면, 차라리 링크를 걸지 않는 편이 낫다.

하지만 자랑스럽게 내세울 수 있는 잘 정리된 프로젝트가 두어 개 있다면, 꼭 프로필 링크를 포함하세요.

당신이 만든 것을 보여 주세요

GitHub 프로필에 대한 조언을 일반화하자면, 당신이 만든 것을 보여 주세요. 이는 스타트업이 가장 중요하게 보는 신호 중 하나이며, 규모 있는 회사에서도 효과적이다.

직접 만든 프로젝트라면 해당 웹사이트나 GitHub 프로젝트 페이지로 링크하세요. 인기 있는 오픈 소스 프로젝트에 의미 있는 기여를 했다면, 한두 문장으로 설명하고 PR 링크를 첨부하세요.

하지만 클로즈드 소스 회사에서 일했더라도, 제품의 어느 부분을 맡았는지 명확하고 자세하게 설명하면 당신이 만든 것을 보여 줄 수 있다. 예를 들면:

Shopify에서 HTML 이메일 템플릿을 재설계하여 클릭률을 15%에서 27%로 거의 두 배로 높였습니다.

영어(혹은 요구되는 언어)로 작성하세요

지원서가 영어로 되어 있다면, 이력서와 커버 레터도 영어로 작성하세요. 우리 회사는 영어로 소통하므로, 모두가 읽을 수 있도록 해당 언어로 된 지원서를 요구한다.

기술 스택: 전부 나열하지 마세요

세상에 존재하는 거의 모든 프로그래밍 언어나 프레임워크를 나열한 “기술 스택” 섹션을 넣지 마세요:

보유 기술: JavaScript, TypeScript, Node.js, React, Java, Kotlin, Python, Django, Flask, R, Rust, PHP, Perl, C/C++, Golang, C#, .NET, Bash, Powershell.

내 눈에는 다재다능한 것 같지만 어느 하나 제대로 하는 것 없는 사람으로 보인다. 차라리 다음과 같은 내용을 보고 싶다:

Python에 대한 깊은 경험이 있으며 C#을 다뤄본 적이 있습니다. 셸 스크립팅에 능숙하고 필요에 따라 새로운 언어를 빠르게 습득합니다.

나는 거의 30년 동안 프로그래밍을 해 왔고 십여 개가 넘는 언어를 사용해 봤지만, 이력서에서는 핵심적인 언어만 적으려고 한다:

저는 Go, Python, C, SQL, 그리고 영어를 유창하게 다룹니다. 또한 JavaScript, HTML, C++, x86 어셈블리도 꽤 많이 작성해 봤습니다.

눈에 띄게 만드세요

이력서 PDF를 전문적으로 보이게 만드세요. 변호사나 정장 차림 같은 의미가 아니라, 약간의 좋은 디자인을 더하라는 뜻이다. 배경을 분홍색과 초록색으로 만들라는 말이 아니라, 레이아웃과 폰트에 조금 신경을 쓰라는 것이다.

친구의 말을 인용하자면:

Word 문서처럼 만들지 마세요. 텍스트로 가득 찬 벽, 검은 테두리의 표, 형편없는 폰트, 간격 없는 레이아웃을 보면 금방 ‘소통을 못하는 사람’이라는 인상을 받습니다. “resume template”이라고 구글에 검색하면 적은 노력으로도 꽤 괜찮은 옵션을 찾을 수 있습니다.

여기에 포함할 수 있는 다른 이력서 팁도 분명 많을 것이다. 제안이 있다면 이메일로 알려 주세요.

맺음말

나는 Canonical에서 일하고 있으며, 우리는 매달 수만 건의 지원서 중에서 최고의 인재를 골라야 한다. 온라인에서는 우리의 면접 과정에 대해 많은 이야기가 오갔고, 그다지 호의적이지 않은 의견도 있었다. 솔직히 채용 과정이 더 짧아지면 좋겠지만, 그중 서면 인터뷰 부분(사람들이 가장 많이 항의하는 부분)은 실제로 꽤 유용하다고 생각한다.

흥미롭게도, 이 글을 쓰는 동안 Canonical은 지원서에 다음과 같은 문구를 추가했다:

본 지원 과정에서 저는 제 자신의 언어로만 작성할 것에 동의합니다. 표절이나 AI 혹은 기타 생성된 콘텐츠의 사용이 지원 자격 박탈 사유가 됨을 이해합니다.

나는 ChatGPT를 피하는 것이 어떤 지원서든 더 좋게 만든다고 믿지만, Canonical은 이제 그것을 요구한다. 지원자가 많은 다른 회사들도 뒤따를 것으로 예상한다.

Canonical의 문서화 책임자는 서면 인터뷰가 면접 과정의 편향을 어떻게 줄이는지에 대한 글을 썼다.

우리는 완전 원격 근무 회사이므로, 서면 소통이 중요하다. 누군가가 오직 글로 자신의 경험을 전달하고 기술적 아이디어를 얼마나 잘 표현하는지 평가하는 것은 필수적이다.

그리고 네, 우리는 항상 채용 중입니다.