🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Convex는 AI를 부정해서가 아니라 코딩 인터뷰가 지원자의 사고·소통·판단을 읽는 제한된 장치이기 때문에 AI를 배제하고, 실제 업무에서는 산출물 품질에 책임지는 한 도구 사용을 강제도 금지도 하지 않는다.

📌 핵심 요약

• Convex의 CTO James는 인터뷰가 실제 업무를 그대로 재현하지 못하는 짧고 거친 관찰 창이라고 본다. 그래서 코딩 인터뷰에서는 AI 도구가 지원자의 사고 과정이라는 신호를 흐리게 만들기 때문에 허용하지 않는다.
• 반대로 실제 업무에서는 AI 사용 정책을 강제하지 않는다. 업무의 목적은 기능을 잘 만들고 좋은 결과물을 내는 것이므로, 어떤 도구를 쓰든 최종적으로 ship하는 품질에 책임지는지가 핵심이다.
• James의 채용관은 MIT에서의 분산 시스템·프로그래밍 언어 연구 경험과 Dropbox에서 소수 인프라 팀으로 거대한 규모의 시스템을 운영한 경험에서 나왔다. 그는 높은 오너십을 가진 작은 팀에서 한 명의 채용이 장기적으로 큰 영향을 만든다고 본다.
• Convex는 점수표 중심 채용을 피하고, 서면 피드백과 라이브 디브리프를 통해 지원자가 Convex에 맞는지 판단한다. 숫자 평균보다 사고의 명확성, 취향, 판단력처럼 정성적 신호를 더 중요하게 본다.
• 딥다이브 인터뷰에서는 시스템 구조 자체보다 그 시스템이 누구를 위해, 어떤 문제를 풀기 위해 만들어졌는지를 묻는다. 강한 지원자는 대안, 제약, 트레이드오프, 지금이라면 바꿀 점을 스스로 설명할 수 있다.

🧩 주요 포인트

1. Convex의 CTO James는 인터뷰가 실제 업무를 그대로 재현하지 못하는 짧고 거친 관찰 창이라고 본다. 그래서 코딩 인터뷰에서는 AI 도구가 지원자의 사고 과정이라는 신호를 흐리게 만들기 때문에 허용하지 않는다.
2. 반대로 실제 업무에서는 AI 사용 정책을 강제하지 않는다. 업무의 목적은 기능을 잘 만들고 좋은 결과물을 내는 것이므로, 어떤 도구를 쓰든 최종적으로 ship하는 품질에 책임지는지가 핵심이다.
3. James의 채용관은 MIT에서의 분산 시스템·프로그래밍 언어 연구 경험과 Dropbox에서 소수 인프라 팀으로 거대한 규모의 시스템을 운영한 경험에서 나왔다. 그는 높은 오너십을 가진 작은 팀에서 한 명의 채용이 장기적으로 큰 영향을 만든다고 본다.
4. Convex는 점수표 중심 채용을 피하고, 서면 피드백과 라이브 디브리프를 통해 지원자가 Convex에 맞는지 판단한다. 숫자 평균보다 사고의 명확성, 취향, 판단력처럼 정성적 신호를 더 중요하게 본다.
5. 딥다이브 인터뷰에서는 시스템 구조 자체보다 그 시스템이 누구를 위해, 어떤 문제를 풀기 위해 만들어졌는지를 묻는다. 강한 지원자는 대안, 제약, 트레이드오프, 지금이라면 바꿀 점을 스스로 설명할 수 있다.

🧠 상세 정리

1. AI 코딩 인터뷰 논쟁에 대한 Convex의 입장

본문의 출발점은 기술 채용에서 AI 코딩 인터뷰가 가장 논쟁적인 형식 중 하나가 되었다는 문제의식이다. Convex는 코딩 인터뷰에서 지원자에게 AI를 쓰게 하지 않지만, 그 이유는 AI를 배척하거나 업무 현실을 부정하려는 데 있지 않다. 인터뷰는 원래도 지원자의 사고를 제한적으로만 보여주는 조악한 근사치이기 때문에, 여기에 AI 도구까지 더하면 읽고 싶은 신호가 더 흐려진다고 본다. 동시에 Convex는 실제 업무에서 엔지니어에게 AI 사용을 강제하지도 금지하지도 않는다. 핵심 기준은 도구 사용 여부가 아니라 최종적으로 어떤 품질의 결과물을 내는지에 대한 책임이다.

2. 인터뷰와 실제 업무는 같은 활동이 아니다

James가 반복해서 강조하는 문장은 인터뷰가 실제 업무와 전혀 닮아 있지 않다는 것이다. 인터뷰는 수년간 함께 일할 가능성이 있는 사람을 두 시간 남짓 관찰하는 자리이며, 이 시간 안에서 보는 것은 기능을 얼마나 잘 ship하는지가 아니다. Convex가 확인하려는 것은 지원자가 가벼운 압박 속에서 어떻게 생각하는지, 혼란스러울 때 어떻게 소통하는지, 그리고 판단의 취향이 팀과 맞는지다. AI 도구는 실제 기능 개발에는 매우 유용할 수 있지만, 이런 사고 과정과 소통 방식을 드러내는 데에는 오히려 방해가 된다. 그래서 인터뷰와 업무가 서로 다른 목표를 가진 활동임을 인정하는 것이 Convex의 정책을 일관되게 만든다.

3. James의 배경과 높은 오너십에 대한 기준

James는 MIT에서 Barbara Liskov 아래 박사 과정을 했고, 분산 시스템과 프로그래밍 언어 설계를 연구했다. 그는 언어 설계를 단순히 컴파일러를 만드는 일이 아니라 추상화에 대해 명확하게 사고하도록 강제하는 활동으로 설명한다. 이후 Dropbox에서 약 일곱 명 규모의 인프라 팀을 이끌며 엑사바이트 단위 데이터와 초당 수백만 건의 트랜잭션을 다루는 경험을 했다. 이런 배경은 Convex가 채용에서 높은 오너십과 판단력을 중시하는 이유로 이어진다. 작은 팀이 거대한 책임을 맡을 때 인원 수 자체가 해답이 아니며, 한 명의 잘못된 채용이 장기적으로 큰 비용을 만든다는 관점이 그의 채용 철학에 깔려 있다.

4. 문화는 선언이 아니라 의사결정 방식이다

Convex가 말하는 문화는 점심 정책이나 오프사이트 일정이 아니라, 아무도 지켜보지 않을 때 결정이 내려지는 방식이다. 본문은 진짜 가치란 행동을 제약하는 것이어야 한다고 말한다. 예컨대 빠르게 움직이고 부서지는 것을 감수한다는 가치는 실제 트레이드오프를 강제하지만, 안정적인 인프라를 중시한다는 문장은 누구도 불안정한 인프라를 원한다고 말하지 않기 때문에 가치로서 힘이 약하다. Convex에서 무게 있게 다루는 또 다른 가치는 정직성이고, 이는 장애가 발생했을 때 투명한 포스트모템으로 드러난다. 프로세스가 정직함을 만들어내는 것이 아니라, 문화가 정직함을 만들고 프로세스는 그것이 놓일 자리를 제공한다는 설명이다.

5. 갈등은 가치, 이유, 무엇, 방법의 층위로 다뤄야 한다

본문은 팀이 의견 충돌을 겪을 때 가치, 왜, 무엇, 어떻게라는 위계가 중요하다고 설명한다. 논쟁이 아래층인 방법 수준에 머물수록 생산성은 낮아지고, 해결되지 않는 방법 논쟁은 대개 숨겨진 이유의 불일치라는 것이다. Convex 내부 사례로는 두 하위 팀이 새 API를 빠르게 출시할지, 신뢰성 작업을 더 할지 다툰 일이 소개된다. 겉으로는 실행 방식의 문제처럼 보였지만 실제로는 그 API가 왜 존재하는지, 다음 버전이 어떤 사용자를 위한 것인지에 대한 이해가 어긋나 있었다. 이 지점을 명명하자 방법에 관한 논쟁은 약 10분 만에 풀렸고, James는 회의가 막히면 표면의 논쟁을 멈추고 더 위의 층위로 올라가야 한다고 본다.

6. Convex의 채용 루프와 점수표를 쓰지 않는 이유

Convex의 전형적인 채용 루프는 디브리프까지 대략 일곱 번의 인터뷰로 구성된다. 두 번의 전화 코딩 스크린, 두 번의 온사이트 코딩 라운드, 시니어 후보자를 위한 아키텍처 인터뷰, 딥다이브 인터뷰, 팀 대화가 포함되며, 그중 가장 중요한 단계는 디브리프다. Convex는 일반적인 점수표 기반 루프와 달리 역량별 숫자 점수를 매기지 않고 서면 피드백을 남긴다. 그 이유는 점수표가 측정하기 쉬운 것만 측정하고, 사고의 명확성이나 정신적 민첩성, 취향 같은 중요한 정성 신호를 놓치기 쉽다고 보기 때문이다. 숫자가 생기면 평균이 생기고, 대화는 이 사람이 우리에게 맞는가가 아니라 점수가 기준을 넘는가로 바뀐다는 점도 문제로 지적된다.

7. 디브리프는 결정의 장이자 면접관 훈련의 장이다

Convex에서 디브리프는 채용 여부를 결정하는 자리인 동시에 면접관들이 Convex에서 말하는 좋음의 기준을 학습하는 자리다. 모든 면접관은 회의 전에 다른 면접관의 서면 피드백을 읽고, 대화는 중재자를 통해 진행된다. 현재는 James가 모든 디브리프를 직접 운영하지만, 장기적으로는 신뢰할 수 있는 소수의 중재자를 키우는 것이 목표다. 다만 이 과정을 체크리스트로 완전히 바꾸려 하지는 않는다. 체크리스트는 절차를 포착할 수는 있지만 판단 자체를 포착하지 못하며, 판단은 신뢰할 수 있는 기준을 가진 사람이 실제로 토론을 이끄는 장면을 반복해서 보며 훈련된다는 것이 본문의 주장이다.

8. 딥다이브 인터뷰에서 보는 것은 구조가 아니라 사고의 이유다

딥다이브 인터뷰는 많은 지원자가 제안을 받거나 부적합함을 드러내는 핵심 구간으로 소개된다. Convex는 후보자에게 자신이 만든 시스템을 설명하게 하지만, 단순히 아키텍처를 자세히 묘사하는 능력만 보지는 않는다. 중요한 질문은 그 시스템의 사용자가 누구였는지, 어떤 문제를 풀었는지, 회사가 왜 그 작업에 자원을 투입했는지다. 시니어 후보자가 이 질문에 답하지 못하면 Convex에서는 좋은 평가를 받기 어렵다. 반대로 강한 후보자는 당시의 제약, 선택한 트레이드오프, 오늘 다시 한다면 바꿀 점, 명백해 보이는 대안을 왜 고르지 않았는지를 설명하고, 어떤 조건이라면 그 결정을 뒤집을지도 말할 수 있다.

9. AI를 금지하는 이유는 도덕 판단이 아니라 신호 보존이다

Convex가 코딩 인터뷰에서 AI 사용을 허용하지 않는 이유는 AI 사용 자체에 대한 도덕적 반대가 아니다. 본문은 똑똑한 엔지니어들이 Claude 같은 도구를 매일 사용한다는 점을 인정하면서도, 인터뷰에서 측정하려는 것은 그것이 아니라고 말한다. 코딩 인터뷰에서 보고 싶은 것은 지원자가 소리 내어 추론하는 방식, 모호함을 다루는 방식, 첫 번째 아이디어가 틀렸을 때 반응하는 방식이다. AI 보조가 들어오면 이 과정은 지원자가 프롬프트를 입력했고 결과가 동작했다는 사실로 압축되어 버리며, Convex가 필요로 하는 정보는 사라진다. 본문은 미쉐린 스타 셰프가 주방에서 절단기를 쓸 수는 있지만 셰프의 취향을 평가하려고 절단기 조작 장면을 보지는 않는다는 비유로 이를 설명한다.

10. 화이트보드 코딩과 워크 트라이얼의 한계

Convex의 여러 코딩 라운드는 컴퓨터 없이 화이트보드에서 진행된다. 이는 컴퓨터, IDE, AI 어시스턴트가 모두 인간이 생각하는 과정을 가릴 수 있는 요소라고 보기 때문이다. Convex가 보고 싶은 것은 후보자의 시행착오, 수정, 스스로 버그를 알아차리고 고치는 순간이다. 그래서 Convex 인터뷰를 준비하는 사람에게 중요한 목표는 완벽한 최종 코드보다 자신의 추론을 보이게 만드는 것이다. 본문은 또한 워크 트라이얼이 빠르게 코딩하는 사람을 찾는 데는 유용할 수 있지만, 시니어 아키텍처 판단을 평가하는 데는 한계가 있다고 말한다. 전략적 판단, 기술 방향 설정, 트레이드오프 감각, 멘토링, 리더십의 나쁜 결정에 반대하는 능력은 며칠짜리 trial에서 드러나기 어렵다는 것이다.

🧾 핵심 주장 / 시사점

• Convex의 핵심 논지는 AI를 쓸 수 있느냐가 아니라, 어떤 상황에서 무엇을 측정하려는가를 먼저 분리해야 한다는 점이다. 업무에서는 생산성과 품질이 목적이고, 인터뷰에서는 사고 과정의 관찰이 목적이므로 같은 도구라도 평가 맥락에서는 방해가 될 수 있다.
• 점수표를 쓰지 않는 Convex의 방식은 작은 고신뢰 조직에서는 강한 정성 판단을 가능하게 하지만, 본문도 이 방식이 대규모 조직에 그대로 확장되지는 않는다고 인정한다. 따라서 이는 보편적 채용 해법이라기보다 현재 Convex의 규모와 채용 대상에 맞춘 의식적인 선택이다.
• 딥다이브와 디브리프를 중시하는 관점은 좋은 시니어 엔지니어를 코드 작성자보다 문제 정의자와 판단자로 본다는 뜻이다. 시스템을 얼마나 복잡하게 설명하느냐보다, 왜 만들었고 누구를 위해 어떤 대안을 버렸는지를 설명하는 능력이 더 중요한 신호로 제시된다.

✅ 액션 아이템

• 코딩 인터뷰를 AI 배제 환경으로 유지하되 사고·소통·판단 신호를 더 선명히 읽을 수 있도록 과제 난이도와 대화 흐름을 조정한다.
• 실무 단계에서는 AI 사용을 강제·금지하지 않고, ship 결과물의 품질에 대한 책임을 확인하는 평가 기준으로 성과 판정을 정리한다.
• 점수표 중심 판단을 줄이고 서면 피드백·라이브 디브리프에서 사고의 명확성, 취향, 판단력 같은 정성 신호를 비교 축으로 둔다.

❓ 열린 질문

• 짧은 인터뷰에서 AI로 흐려질 수 있는 사고 신호를 가장 잘 드러내기 위한 과제/질문 설계 비중은 어떻게 잡아야 하는가?
• 숫자 평균을 버렸을 때 대안·제약·트레이드오프 설명력을 정량 지표 없이도 일관되게 비교할 수 있는 기준은 무엇인가?
• 작은 팀에서 한 채용이 장기적으로 큰 영향을 만든다는 전제하에 팀 적합도를 가늠할 때 무엇을 최우선 기준으로 둘 것인가?