매니저가 당신의 포트폴리오를 엽니다.

당신의 이력서에는 5년의 자동화 (automation) 경험이 있다고 적혀 있습니다. README에는 Selenium, Playwright, Appium, Jenkins, Docker, Kubernetes가 나열되어 있습니다. 그는 스크롤을 내립니다. 코드가 없습니다. 브라우저 탭이 닫힙니다.

이것이 바로 당신의 모습입니다. 기술이 부족해서가 아니라—당신은 기술을 가지고 있습니다—당신의 공개적인 증거가 마치 쇼핑 목록처럼 읽히기 때문입니다. 당신이 나열한 도구들은 새벽 2시에 불안정한 테스트 (flaky test)가 실패했을 때 당신이 어떻게 생각하는지, 혹은 개발자에게 버그가 실제 상황임을 어떻게 설득하는지에 대해 아무것도 말해주지 않습니다.

만약 당신이 단순한 기록 및 재생 (record-and-playback) 이상의 것을 요구하는 역할을 맡는 데 진심이라면, 포트폴리오를 키워드 빙고 카드처럼 취급하는 것을 멈춰야 합니다. 여기 당신의 기회를 즉시 망치는 세 가지 실수와 그것을 정확히 수정하는 방법이 있습니다.

실수 1: 도구 과시 (Tool jockeying)

들어본 적 있는 모든 자동화 프레임워크 (automation framework)를 나열하는 것은 본능적인 반응입니다. 채용 담당자는 "Cypress, Playwright, Selenium, WebDriverIO에 능숙함"이라는 문구를 보면, 당신이 각 도구에서 npm init을 한 번씩 실행해보고 끝냈다고 가정합니다.

대부분의 테스터들은 코드가 있어야 할 빈 공간이 두려워서 도구들을 앞세웁니다.

경험 많은 테스터는 의도적으로 작성된 하나의 테스트를 보여주며, 자신이 선택한 트레이드오프 (trade-off)를 설명하는 주석을 함께 달아둡니다.

차이점은 양이 아닙니다. 목적이 분명한 대기 전략 (wait strategy)을 사용하여 로그인 흐름을 처리하는 단 30줄짜리 스크립트가, 6개의 도구가 나열된 이력서보다 당신에 대해 더 많은 것을 가르쳐줍니다. 저 또한 과거의 프로젝트들을 다시 읽어보고, 왜 특정 어설션 (assertion)이 존재했는지에 대해 아무것도 말해주지 않는다는 것을 깨달은 후 제 프로젝트들을 삭제한 적이 있습니다. 그 조용한 민망함이 바로 당신이 개선될 준비가 되었다는 신호입니다.

포트폴리오에 담긴 결과물은 반드시 한 가지 질문에 답해야 합니다: "이 사람은 무엇을 결정했고, 왜 그렇게 했는가?" 도구 목록은 각주로 옮기세요. 실제 테스트가 메시지를 전달하게 하세요.

실수 2: 완벽한 테스트의 함정

모두 통과(green builds)된 테스트로 가득 찬 포트폴리오는 함정입니다. 모든 팀은 실제 자동화가 깨진다는 것을 알고 있습니다: CI 노드가 느리게 실행되거나, 서드파티 API (third-party API)가 속도를 제한하거나, DOM이 아주 잠깐 늦게 렌더링되기도 합니다. 통과하는 테스트만 보여주는 것은 당신이 업무의 추한 부분들을 어떻게 다루는지 숨기는 일입니다.

대부분의 테스터들은 모든 단언문(assertion)을 흠잡을 데 없이 다듬습니다. 숙련된 테스터는 재시도 로직(retry logic), 명시적 로깅(explicit logging), 그리고 실패를 예상했다는 증거까지 포함합니다.

해결책은 테스트 케이스를 다섯 개 더 추가하는 것이 아닙니다. 이미 디버깅할 때 하는 사고 과정을 코드로 녹여내는 것입니다. 쇼케이스 테스트에 장치하여 작은 문제에도 살아남고 다음 엔지니어에게 단서를 남기도록 만드세요. 마치 실패했을 때 당신의 이름을 욕할 팀원에게 건네주는 것처럼 작성하세요.

다음은 관리자가 보고 싶어 하는 종류의 의사결정 과정을 보여주는 실행 가능한 Python 코드 조각입니다. Playwright를 사용하여 로그인하고 일시적인 오류에 대해 재시도하며 스크린샷을 캡처합니다.

from playwright.sync_api import sync_playwright, expect

def test_login_with_retry(page):
...

이것은 복잡하지 않습니다. 하지만 이 코드는 이야기를 전달합니다: 당신은 UI 테스트가 취약하다는 것을 알고 있고, 즉시 실패하는 대신 재시도를 선택하며, 디버깅을 더 빠르게 만드는 아티팩트(artifacts)를 남긴다는 것입니다. 기술적인 세부 사항은 로케이터 전략이 아니라 로깅과 스크린샷입니다.

이것이 채용 관리자에게 가르치는 것은 다음과 같습니다: 당신은 자동화가 작성하는 작업(writing job)이 아니라 유지보수하는 작업(maintenance job)이라는 것을 이해한다는 것입니다. 이 구분이 풀(suite)을 소유할 수 있는 사람과 단순히 티켓만 처리하는 사람을 구분합니다.

실수 3: 영향력에 대한 증거 부족

그 내용을 읽는 채용 담당자는 훑어보기를 멈추고 당신의 판단력(judgment)을 평가하기 시작할 것입니다. 그 순간이 바로 이 모든 과정의 핵심입니다.

이번 주의 실행 과제 (This week’s action)

당신의 GitHub 프로필이나 고정된 리포지토리(pinned repo)를 여세요. 가장 자랑스럽지 않은 테스트를 하나 찾으세요. 너무 깔끔하기만 하거나, 너무 빈약하거나, 혹은 너무 조용한 것 말입니다. 그곳에 당신이 필요하다고 알고 있는 로깅(logging)을 추가하세요. 그리고 그 테스트가 왜 존재하는지, 그리고 만약 실패한다면 어떤 일이 발생하는지를 설명하는 문장을 그 위에 작성하세요. 그리고 푸시(push)하세요.

당신은 자신의 포트폴리오를 아무런 준비 없이 읽었을 때, 당신이 단순히 문서에서 복사해서 붙여넣기만 하는 또 다른 테스터가 아니라는 것을 증명하는 결정적인 지점을 짚어낼 수 있습니까? 만약 그럴 수 없다면, 다른 곳에 지원하기 전에 그것부터 수정하세요.