충분히 잘하고 있나요? 기준은 누가 정하나요?

AI 요약

글쓴이는 금요일 기술 면접에서 데모와 기술 질문은 잘 풀었지만 수동 코드 리뷰(manual code review)에서 실수한 뒤, 면접이 개발자의 실제 역량을 제대로 측정하는지 되짚습니다. 현재 4개 시스템에서 12개 프로젝트를 동시에 다루고 있고 모든 작업을 Rust로 작성하지도 않는데, 평소 자주 하지 않는 수동 리뷰 한 번으로 업무 수행 능력까지 부정당해야 하는지 묻습니다.

수동 코드 리뷰는 역량보다 기억을 시험하나요

글쓴이는 면접에서 수동 리뷰를 “어떻게 생각하는지 확인하는 역량 테스트”라고 설명하지만, 실제 환경은 그 목적에 맞지 않는다고 봅니다. 테스트와 벤치마크를 작성하고 도구를 활용하는 방식이 일반적인 개발 과정에 더 가깝지만, 면접에서는 익숙하지 않은 코드를 제한된 시간 안에 눈으로 살펴보고 즉시 문제를 찾아야 합니다. AI에게 1차 검토를 맡겨 명백한 문제를 고치고 파일의 맥락을 파악하는 개발자를 두고, 보조 없이는 일하지 못한다고 평가하는 것도 적절하지 않다고 말합니다.

글쓴이가 검토한 코드에서는 SHA-256 값에 맞는 자료형인 [u8; 16]을 찾아냈습니다. 면접관은 이 부분을 발견한 지원자가 많지 않다고 말했지만, 글쓴이는 최근에 비슷한 작업을 해본 경험이 있었기 때문에 알아챘을 뿐이라고 설명합니다. 한 가지 문제를 찾았다고 폭넓은 역량을 증명하는 것도 아니고, 놓쳤다고 무능을 증명하는 것도 아닙니다. 캐싱 시스템처럼 마지막으로 직접 만든 지 3년 된 대상을 검토한다면, 올바른 패턴을 기억하지 못할 가능성이 있습니다. 글쓴이는 이런 평가는 실력보다 기억과 과거 경험에 기대며, 최근에 같은 패턴을 다뤘는지가 결과를 좌우한다고 주장합니다.

경력 연수보다 다뤄본 패턴이 결과를 가릅니다

20년 경력 개발자가 10년 경력 개발자보다 항상 나은 결과를 내는 것은 아니라고 봅니다. 10년 경력자가 최근에 접한 패턴을 20년 경력자는 10년 전에 다뤘다면, 오히려 전자가 더 나은 해결책을 작성할 수도 있습니다. 경력 연수의 차이가 실제 재능보다 지금까지 접한 문제 유형의 차이를 반영하는 경우가 많다는 주장입니다.

그렇다면 채용에서 말하는 기준은 무엇인지 질문합니다. 자신감, 산업 지식, 멋진 프로젝트가 기준인가요. 글쓴이는 결국 기업이 보는 것은 채용으로 얻는 가치와 투자수익률(ROI)이라고 봅니다. Claude가 월 20달러인 상황에서 개발자를 더 이상 단순히 코드 작성자로 채용하지 않는다면, 개발자는 문제를 해결하고 빠르게 배우며 새로운 방법을 실험하고 조직에 결과를 만들어내는 능력으로 가치를 증명해야 한다고 말합니다.

가치는 측정되지만 기억은 쉽게 지워집니다

글쓴이는 과거 직장에서 저널링 시스템, 재고 시스템, 제조 시스템, 원격 배포 시스템, 현금출납부 시스템, 대시보드와 디버그 로깅 시스템을 모두 만들었다고 설명합니다. 각 기능이 곧바로 고객을 한두 명씩 늘렸고, 입사 후 3개월 안에 급여보다 훨씬 큰 이익을 만들었다고 합니다. 하지만 기업은 시간이 지나면 과거 성과를 잊고 같은 수준의 성장을 반복해서 요구합니다. 계속해서 반복 매출을 기하급수적으로 늘리지 못하면 개발자를 비용이나 위험 요소로 취급할 수 있다고 말합니다.

채용 과정도 비슷하게 작동한다고 봅니다. 기업은 최고의 인재보다 예산 안에서 위험이 낮고 기대수익이 높은 지원자를 고르며, 높은 잠재력을 가진 인재에 큰 금액을 거는 대신 작은 비용으로 작은 수익을 기대하는 선택을 한다는 설명입니다. 현재 연봉을 묻는 질문도 지원자의 실제 최저선을 파악해 협상력을 낮추려는 장치일 수 있다고 주장합니다. 연봉이 공개되지 않은 시니어 개발자 직무에서 현재 연봉이 2만 2,000달러라고 말하면, 기업이 시장가인 8만 달러가 아니라 3만 달러를 제시할 수 있다는 예를 듭니다.

면접에서 무엇을 평가해야 하나요

글쓴이는 수동 코드 리뷰가 이런 가치 절하 전략 중 하나일 수 있다고 봅니다. 실제 업무에서 모든 코드를 한 줄씩 철학적 질문처럼 검토하면 생산성이 떨어지는데, 기업이 매일 시키지 않을 일을 채용 과정에서만 요구하기 때문입니다. 반대로 프로젝트 제출은 첫날 어떤 가치를 가져오는지 보여줍니다. 기술 질문은 산업의 병목과 시장의 빈틈을 파악할 정도로 도메인을 이해하는지 확인합니다. AI를 어떻게 사용하는지 묻는 질문은 지원자의 작업 방식이 회사의 도구와 구독 계획에 맞는지 살펴봅니다. 글쓴이는 이 세 가지가 수동 리뷰 하나보다 실제 가치를 더 잘 보여준다고 주장합니다.

다만 글쓴이도 자신의 관점이 매우 비관적일 수 있다고 인정합니다. 면접에서 한 번 실패했다고 해서 연봉 기대치까지 낮아져야 하는지 묻는 것으로 글을 맺습니다. 개발자의 가치는 특정 코드 패턴을 즉시 기억하는 능력 하나가 아니라, 낯선 문제를 조사하고 도구를 활용하며 가정을 검증하고 필요한 것을 배워 결과를 내는 과정에서 드러난다는 문제 제기입니다.

dev.to 반응

• @dannwaneri — 아니요. 저는 불합격했다고 연봉 기대치가 낮아지지는 않습니다. 최근 면접은 코드와 관련된 것도 아니었습니다. DEV 직무에서 탈락한 이유는 실력 수준이 아니라 거주 지역이었습니다. SHA-256을 찾아낸 지점은 타당하다고 봅니다. 리뷰에서 한 가지를 찾아냈다고 전체 범위를 증명하는 것도 아니고, 하나를 놓쳤다고 그 반대가 증명되는 것도 아닙니다.
• @effessdev — 면접을 본 적은 없습니다. 하지만 “취업할 수 있다”는 기대가 낮아질 것 같고, 연봉 기대치가 낮아질 것 같지는 않습니다.
• @sizzlebop — 면접은 즉각적인 기억과 실제 능력을 너무 자주 혼동한다고 생각합니다. 압박 속에서 낯선 코드를 바라보고 모든 문제를 즉시 찾아내는 능력도 분명 하나의 기술이지만, 문제를 조사하고 사용 가능한 도구를 활용하고 가정을 검증하고 모르는 것을 배워 결국 견고한 해결책을 만드는 능력과는 다릅니다. 후자가 실제 개발자의 일상과 훨씬 가깝습니다. 면접에서 하나를 놓쳤다고 연봉 기대치를 자동으로 낮춰야 한다고 생각하지도 않습니다. 이상하게 구체적인 한 가지 과제는 개발자로서 전체 가치를 측정하는 매우 나쁜 방식입니다. 문제에 어떻게 접근하는지, 어떻게 배우는지, 실제로 무엇을 만들었는지, 유용한 결과를 전달하는지를 평가받고 싶습니다.
• @xulingfeng — 그냥 농담입니다 🤣. 회사가 당신을 채용할지는 실력뿐 아니라 외모에도 많이 달려 있다고 생각합니다, 하하하 🤣. 솔직히 말하면 면접에서 여러 번 떨어진 뒤 연봉 기대치를 낮추기는 합니다. 간신히 버티는 상황이라면 같은 급여나 심지어 삭감된 급여의 일자리도 괜찮습니다. 부끄러운 일은 아닙니다. 우선 버티는 일이 먼저입니다 💪.
  • @unitbuilds — 맞습니다. 형편이 어려워지면 자존심을 낮추고 받을 수 있는 것을 받는 일이 살아남는 유일한 방법일 때가 있습니다. 하지만 기업이 아무것도 없는 것보다 무엇이든 있는 편이 낫다는 사실을 알고 낮은 금액을 제시하면 나쁩니다. 연봉이 공개되지 않은 직무에 들어가 연봉 2만 2,000달러를 받는 시니어 개발자라고 말하면, 8만 달러가 아니라 3만 달러를 제시할 수 있습니다. 그래도 기존보다 나은 금액이니 재정 상태는 좋아지겠지만, 공정하지는 않습니다.
  • @xulingfeng — 속담처럼 만족을 알면 행복이 오래갑니다. 知足者长乐.
  • @unitbuilds — 가진 것에 만족하지 못하면 원하는 것을 가져도 행복하지 않을 것입니다.
  • @xulingfeng — 마음이 평화를 찾는 곳이 곧 내 집입니다. 此心安处是吾乡.
  • @effessdev — 네, 안타깝지만 외모는 매우 중요합니다 :(.
  • @xulingfeng — 🤣
  • @technogamerz — “외모에도 많이 달려 있다”니, 하하하 🤣. 뭐라고요? 🤔
  • @xulingfeng — 🤣
  • @technogamerz — 흠, 실제 사례를 하나 들어줄 수 있나요?
• @nour_dude_314 — 도발적인 의견입니다. 당신에게 기준을 정할 수 있는 사람은 당신 자신밖에 없습니다.
• @kartik-nvjk — 누가 기준을 정하느냐는 질문은 에이전트 평가(agent evals)에서 마주치는 문제와 같습니다. 직접 만든 벤치마크에서 95%를 받는 일은 사용자가 만든 벤치마크에서 95%를 받는 일과 같지 않습니다. 저는 이제 평가 세트를 두 개 유지합니다. 하나는 직접 선별하고, 다른 하나는 실제 운영 장애에서 만든 세트입니다. 두 결과의 차이를 보면 제 평가 기준이 어디에서 잘못됐는지 알 수 있습니다. 자기 평가와 외부 기준의 차이를 어떻게 생각하나요?
  • @unitbuilds — 사용자와 작성자의 차이는 결국 무엇을 중요하게 보느냐의 문제로 귀결됩니다. 사용자는 성공 경로와 실패 경로를 측정하지만, 작성자는 고립된 엣지 케이스보다 시스템 점검에 가깝게 더 일반적인 방식으로 실행할 것입니다.

원문: dev.to / 번역·요약: Trawling