커서는 왜 딱 50명만 볼까

오늘 GeekNews 상위권은 공교롭게도 하나의 질문으로 이어집니다. 도구가 아무리 좋아져도 결국 누가, 어떤 구조로, 무엇에 시간을 쓰느냐가 결과를 가른다는 것입니다. 100명에게 연락해 남은 사람을 뽑는 채용, 라이브러리를 애플리케이션 전체에 노출하는 백엔드, 에이전트를 켜두고 방치하는 개발 방식은 모두 같은 실수를 저지릅니다. 오늘의 TOP3를 정리했습니다.

커서 인재 총괄이 말한 파멸의 퍼널

응답한 20명은 상위 20%가 아니다

Cursor의 인재 총괄 Adam Ward는 대부분의 회사가 쓰는 채용 퍼널을 파멸의 퍼널(Funnel of Doom)이라고 부릅니다. 100명에게 연락해 20명이 응답하고, 면접 단계마다 탈락시켜 마지막에 남은 한 명을 뽑는 구조입니다. 문제는 그 20명이 상위 20%가 아니라 단지 그 순간 연락에 응할 사정이 있었던 20명이라는 점입니다. 애초에 최적이 아닌 집단을 대상으로 아무리 정교한 평가 절차를 돌려도 규모가 커질수록 결과는 평균으로 회귀합니다.

대안은 모든 채용을 임원급 서치처럼 운영하는 것입니다. 순서는 세 단계입니다. 첫째 스코핑(Scoping), 우리 회사에서 이 역할의 상위 1%가 무엇을 뜻하는지 먼저 정의합니다. 둘째 매핑(Mapping), 그 기준에 맞는 전 세계 최고의 후보자가 50명뿐이라고 가정하고 명단을 만듭니다. 셋째 끈질긴 추적(Relentless Pursuit), 그 사람들과 몇 주에서 몇 년까지 관계를 이어갑니다.

회사 로고는 능력의 대리 지표가 아니다

Ward는 유명 회사 경력을 개인 능력의 대리 지표로 쓰는 관행을 경계합니다. 특정 시기 특정 팀이 훌륭한 성과를 낸 것은 참고할 신호이지만, 그 팀에 있었다는 이유만으로 개인이 뛰어난 것은 아니라는 것입니다. 기준은 우리 제품과 역할에서 성공하는 데 필요한 이전 가능한 역량이어야 합니다. 최근 여러 직군에서 중요해진 시스템 사고 역시 거창한 추상 능력이 아니라 문제를 정의하고 잘게 쪼개 장애물을 하나씩 제거하는 매우 전술적인 실행력에 가깝다고 설명합니다.

후보자 발굴에서 가장 효과가 높은 방법은 AI 검색이 아니라 현재 직원들의 네트워크를 사람이 직접 깊게 파는 일입니다. Cursor에는 인상적인 사람을 발견하면 공유하는 Hiring Ideas 슬랙 채널이 있고, 채용 조직 밖의 직원들이 먼저 후보 신호를 공급합니다. 채용 담당자의 역할은 결정을 대신하는 것이 아니라 채용 관리자가 옳은 결정을 내리도록 신호를 모으는 확신 엔진(Confidence Engine)입니다. 최종 Hire/No Hire 판단은 다수결이 아니라 채용 관리자가 내립니다.

Rust와 PostgreSQL로 백엔드 짜는 법

HTTP, 서비스, 저장소 3계층으로 자른다

Sylvain Kerkour는 Rust가 Go보다 백엔드 개발 생산성이 낮을 수 있다는 점을 먼저 인정합니다. 그럼에도 강한 타입 시스템과 컴파일러가 보장하는 정확성, zero-cost abstraction 덕분에 코드 1만 줄 이상, 엔드포인트 100개 규모에서 비즈니스 로직 버그를 줄이거나 높은 성능이 필요한 서비스에는 충분히 값을 한다고 말합니다.

권장 스택은 층으로 정리됩니다. 맨 아래 비동기 런타임 tokio, 그 위 TLS는 rustls와 tokio-rustls 조합, HTTP 코어는 hyper, 웹 프레임워크는 axum, 클라이언트는 reqwest, 미들웨어 추상화는 tower, 관측성은 tracing입니다. TLS로 rustls를 고른 이유가 실용적입니다. Rust 네이티브라 정적 링크가 가능하고, 서버나 Docker 이미지의 OpenSSL 버전을 맞추는 배포 문제와 크로스 컴파일 난이도가 함께 줄어듭니다.

애플리케이션 코드는 HTTP/스케줄러/워커 계층, 서비스 계층, 저장소 계층 세 개로 나누고 각 계층은 바로 인접한 계층하고만 통신하게 합니다. HTTP 핸들러가 저장소를 직접 호출하지 않는다는 규칙 하나로 프레임워크 교체 비용이 한 계층에 갇힙니다. HTTP 계층은 요청을 서비스용 구조체로 바꾸고 결과를 응답으로 되돌리는 일만 합니다. 인증, 검증, 비즈니스 불변조건은 전부 서비스 계층에 모입니다.

PostgreSQL 하나로 큐와 리더 선출까지

저장소 계층은 SQL만 담당합니다. 여러 데이터베이스를 갈아 끼우기 위한 추상화 계층이 아니라 쿼리를 한 파일에 모아 재사용하고 컬럼 변경 범위를 쉽게 찾기 위한 장치입니다. sqlx의 Executor를 감싼 Queryer 트레이트를 쓰면 같은 저장소 메서드가 커넥션 풀과 트랜잭션 양쪽에서 동작합니다. unique 제약 위반 같은 DB 오류를 EmailAlreadyInUse 같은 도메인 오류로 바꾸는 것도 이 계층의 몫입니다.

캐시는 저장소가 아니라 서비스 계층에 둡니다. 이 엔티티를 한 시간 캐시해도 된다는 판단은 데이터 접근이 아니라 비즈니스 규칙이기 때문입니다. 대부분은 moka로 충분합니다. 백그라운드 작업 큐도 별도 메시지 시스템 없이 PostgreSQL로 구현하고, 복제본 여러 대에서 Cron이 중복 실행되는 문제는 PostgreSQL advisory lock으로 리더를 선출해 막습니다. 프론트엔드 빌드 결과물은 rust-embed로 바이너리에 넣고 axum fallback 핸들러로 제공해 CDN과 CORS 처리를 통째로 없앱니다.

2026년 Stripe Staff 엔지니어의 하루

도구가 좋아진 만큼 기대치가 올라갔다

Stripe의 Staff Engineer인 Riccardo Bedin이 쓴 회고는 낙관적이지 않습니다. 그는 AI로 일이 편해진 것이 아니라 AI를 써서 더 큰 영향력을 내야 한다는 기대가 올라갔다고 말합니다. 사내 Developer Productivity 조직이 제품 엔지니어를 내부 고객처럼 대하며 Anthropic과 OpenAI의 최신 모델을 새 모델 공개 며칠 안에 파일럿으로 열어줍니다. 모델별 사용 비용을 보여주는 맥 앱과 소프트 리밋이 있지만 도달하기 어렵고, 추가 한도 요청도 빠르게 승인됩니다. 결과적으로 Staff에게는 도구를 쓰지 못했다는 변명의 여지가 점점 줄어듭니다.

흥미로운 건 Stripe가 AI 사용량을 강제하지도, 최소화하도록 지침을 주지도 않는다는 점입니다. 각자 상황에 맞게 판단하도록 맡깁니다. 대신 프로젝트 일정이나 약속한 영향력을 달성하지 못한 이유를 설명하기는 이전보다 어려워졌습니다.

에이전트를 병렬로 돌리는 게 아니라 관리하는 일

Staff 수준에서는 대형 프로젝트 여러 개를 동시에 다룰 컨텍스트와 판단력이 필요합니다. Bedin은 이를 위해 서로 다른 환경에서 N개의 에이전트를 두 번째 두뇌처럼 병렬로 돌린다고 말합니다. 다만 진짜 문제는 병렬 실행 자체가 아니라 관리입니다. 각 에이전트가 어디까지 진행됐는지, 새 에이전트를 어떻게 시작할지, 지금 무엇을 하고 있는지, 결과물 품질이 충분한지 확인하는 일입니다. 여기에 정답이나 표준 워크플로우는 아직 없고, Stripe도 도구와 몇 가지 권장사항만 제공한 뒤 각자 방식을 찾게 둡니다.

또 하나의 기준은 혼자 잘하는 것으로는 부족하다는 것입니다. 그는 Staff의 역할을 RPG의 아우라에 비유합니다. 멘토링, 코드 리뷰, 디자인 리뷰로 주변 엔지니어와 프로젝트의 수준까지 끌어올려야 하고, 평가에도 동료 피드백이 반영되므로 고립된 상태의 성과는 기준을 충족하지 못합니다. 업무 강도에 대해서도 솔직합니다. 하루 네 시간만 일하며 좋은 평가를 기대한다면 맞지 않는 곳이며, 더 똑똑하게 일하라가 아니라 더 똑똑하게도 더 열심히도 일해야 한다는 쪽에 가깝다고 적었습니다.

관련 글

• 레디스 만든 그가 요즘 꽂힌 것
• 팀장은 하루 종일 뭘 할까
• AI가 만든 화면, 왜 티 날까
• 결제 공룡이 10조를 던졌다
• Anthropic Hid Something in Every Word Claude Writes

출처

1. GeekNews – 인재 밀도가 높은 팀을 만드는 법, Cursor 인재 총괄 Adam Ward
2. YouTube – Adam Ward 인터뷰 원본
3. GeekNews – Rust와 PostgreSQL로 확장 가능한 백엔드 서비스 구축하기
4. kerkour.com – Building scalable backend services with Rust and PostgreSQL
5. GeekNews – 2026년 Stripe에서 Staff Engineer로 일한다는 것
6. Medium – Being a Staff Engineer at Stripe in 2026