포지션 상세
[우리는 어떤 팀인가.]
LinqAlpha는 기관투자자(헤지펀드·자산운용사·보험사 등)의 트레이딩과 리서치 프로세스를 돕는 AI 제품을 만드는 핀테크 회사입니다. 국내외 여러 기관 투자자가 종목 분석, 실적·공시 해석, 투자 실사(DD), 마켓 브리핑 같은 실제 리서치 업무에 LinqAlpha를 매일 사용하고 있습니다.
기관 투자자의 리서치는 도메인마다, 심지어 운용역 한 명 한 명마다 일하는 방식이 다릅니다. 같은 "실적 분석"이라도 누군가는 어닝콜 트랜스크립트의 톤 변화를 읽고, 누군가는 가이던스와 컨센서스의 갭을 봅니다. 그래서 모델 하나, 워크플로우 하나로 끝나지 않습니다. 고객의 데이터·투자 방식·관심 자산군·업무 맥락을 깊이 이해하고, 그 위에서 "무엇을 일반화된 에이전트의 행동으로 만들고, 무엇을 도메인에 맞춰 엣지에서 깎아낼지"를 production-grade로 설계해야 비로소 현장에서 "쓸 만한" 제품이 됩니다. 기관 투자자 특성상 제품에 대한 기대 수준은 매우 높고, 이 last mile의 품질을 책임지는 사람이 FDE입니다.
우리는 글로벌하게 일하는 팀입니다. 서울과 뉴욕에 코어 팀이 있고, 영국·싱가포르·홍콩에도 멤버가 있습니다. 사내에는 전직 buy-side·sell-side 애널리스트 등 금융 도메인 전문가와, 10~20명의 외국인 동료가 함께 일합니다. 그래서 영어로 된 정보(논문·기술 문서·공시·금융 데이터·고객 커뮤니케이션)를 빠르게 읽고 소화하는 능력이 매우 중요하며, 사내 도메인 전문가와 영어로 자유롭게 소통하며 "무엇을 만들고 무엇을 개선해야 하는가"를 직접 끌어낼 수 있어야 합니다.
[우리는 이 일을 이렇게 봅니다 (FDE의 정의)]
항상 고객의 문제를 정의하는 것으로부터 시작합니다. 그리고 그 문제를 가장 효과적으로 태클하는 AI 제품을 설계합니다. 이 설계는 자유도 높은 에이전트, 정형화된 워크플로우, 혹은 보다 단순한 형태의 파이프라인일 수도 있는 등 다양한 형태를 띕니다. 하지만 그 어떠한 제품일지라도 그 설계를 구상하고 개발함에 있어 LinqAlpha의 제품 전반과 유기적으로 interweave될 수 있는 agentic foundation을 염두에 두고 작업을 진행합니다.
그래서 FDE는 단순한 SI(시스템 통합) 엔지니어가 아닙니다. 저희가 찾는 사람은 고객의 페인포인트를 깊이 이해하는 동시에, 모든 고객의 페인포인트를 일반화해서 "코어(에이전트)에 넣어 일반적으로 행동을 조율할 것"과 "엣지에서 LLM 워크플로우 및 오케스트레이션으로 풀 것" 사이의 경계를 그어낼 수 있는, 도메인을 이해할 수 있는 개발자입니다.
이 경계는 추상적인 이야기가 아닙니다. 저희 제품에서 그것은 실제로 에이전트의 프롬프트·도구·모델·라우팅을 코드 배포 없이 DB 설정으로 조립·버저닝하는 시스템으로 구현되어 있습니다. 그래서 우리는 "에이전트의 행동은 하드코딩이 아니라 버전 관리되는 설정/데이터" 라는 관점으로 사고하는 사람을 찾습니다.
이 포지션의 본질은 문제 정의의 질에 있습니다.
• 전통적 엔지니어에게는 "무엇을·어떻게 만들지"에 직결되는 만큼만 문제를 정의해도 충분합니다.
• 그러나 이 포지션은 문제를 환원주의적으로(단순 엔지니어링으로 축소해) 풀지 않으면서도, 사용자의 문제를 실제로 해결하기에 '충분한' 수준으로 문제를 정의할 수 있어야 합니다.
• 우리는 에이전트를 Token-to-Token 분포를 이동시키는 장치(distribution shifter)로 봅니다. 따라서 에이전트 개선은 본질적으로 분포 이동(distributional shift)을 다루는 엔지니어링·제어 문제입니다.
• 좋은 FDE는 자신의 엔지니어링 변경이 Canonical한 데이터 분포 위에서 고객의 문제를 실제로 푼다는 것을 '증명'할 수 있고, 그 검증을 토대로 제품을 쌓아 올립니다. "좋아 보인다"가 아니라 "분포 위에서 작동함이 보인다"가 기준입니다.
또한 오늘날의 에이전트 개발은 LangGraph로 워크플로우를 짜는 작업을 넘어 에이전트가 도는 인프라부터 스케일까지를 아우르는 전 과정입니다. 그래서 우리의 바는 높습니다.
• 풀스택 메커니즘 이해 — 에이전트가 어느 노드·Pod·파일시스템 위에서 문제를 푸는지, 어떻게 스케일하는지까지 그릴 수 있어야 합니다. 우리 제품에서 한 번의 대화는 웹 클라이언트 -＞ 다수의 백엔드 서비스 -＞ 세션이 격리된 에이전트 런타임 -＞ 도구 계층(MCP) -＞ 실시간 스트리밍(SSE) 으로 흐릅니다. 이 경로 전체를 그리고, 어디에서 지연·병목·실패가 생기는지 짚어낼 수 있어야 합니다.
• 비동기·스트리밍 설계에 대한 깊은 이해 — 에이전트가 중요하다고 판단한 백그라운드 태스크는 계속 돌리면서도, 그 사이에 부분 결과를 SSE로 스트리밍해 응답하도록 레이턴시를 최소화하는 유연한 구조를 설계할 수 있어야 합니다.
• 컨텍스트 경계 설정 능력 — "이 정보가 고객의 문제를 풀기에 빠짐없이 충분한 집합인가"를 판단할 수 있어야 합니다. 고객의 말을 듣고, 올바른 질문을 던지고, 문제를 충분히 풀기 위한 '데이터와 컨텍스트의 경계'를 상상하고, 정의하고, 소통할 수 있어야 합니다.
그리고 이 일은 엔지니어링만으로는 부족합니다. 일반적인 미시·거시 경제에 대한 이해, 그리고 금융 도메인(buy/sell side, front/mid/back 무관)에서의 경험이 있으면 좋습니다. 무엇보다 금융 산업의 각 도메인 전문가가 어떤 인식 모델(perceptual model)을 갖고 일하는지, 그리고 그 인식이 업계 안에서 어떻게 공유되는지에 대한 분명한 호기심이 필요합니다. (사내에 전직 IB·운용역·애널리스트 동료가 있어, 영어로 소통하며 이 인식 모델을 빠르게 흡수할 수 있습니다.) 그리고 Claude Code 같은 AI 코딩 도구로 자신의 일을 파이프라이닝하고 스스로를 계속 스케일해 나가는 태도를 갖춘 분을 찾습니다.
마지막으로, AI 시대에 가장 중요한 역량 중 하나는 '어떤 질문을 던져야 하는지'를 아는 능력입니다. 저희는 채용 과정에서 지원자의 질문의 질을 핵심적으로 봅니다 — 주어진 문제 상황에서, 잘 정돈된 reasoning을 바탕으로 정확한 질문을 던질 수 있는 사람인지를 가장 우선적으로 평가합니다.
• 에이전트를 중심에 두고, 코어와 엣지의 경계를 설계합니다. 한 고객에서 배운 것을 일반화해, 에이전트의 일반 행동으로 환원할 것과 도메인 특화 워크플로우로 깎아낼 것을 구분합니다. 마켓 브리핑 자동화, 실사(DD) 리포트 에이전트, 비정형 문서 검색·인용 워크플로우, 정형 데이터 자연어 질의(TTSQL) 등을 에이전트가 호출·조율하도록 end-to-end로 만듭니다.
• 에이전트 행동을 '설정으로' 운영합니다. 프롬프트 블록·도구 정책·모델·라우팅을 코드 배포 없이 조립·버저닝하고, feature flag와 조건부 규칙으로 고객·맥락별 동작을 분기하며, draft 시뮬레이션 배포의 사이클로 안전하게 바꿉니다.
• 인프라부터 백엔드까지 직접 구현합니다. 외부 시스템·API 연동, 커넥터, 데이터 파이프라인, 서버 로직, 그리고 에이전트가 도는 실행 환경(노드·Pod·스토리지, warm pool, 오토스케일링)까지 — 데모가 아니라 프로덕션 파이프라인을 직접 짭니다.
• 측정 가능한 개선을 합니다. 가설의 정·반·합이 내재화된 평가·테스트 체계(LLM-as-judge, 품질 스코어, 인용·출처 grounding 검증) 를 만듭니다. 실제 사용 로그·트레이스에서 고객사별 실패 케이스를 찾아 경중을 구분하고, canonical 분포 위에서 변경 효과를 검증한 뒤 빠르게 반영합니다. (금융 답변은 출처 귀속이 품질의 필수 요건입니다.)
• 분산 시스템을 E2E로 추적·디버깅합니다. 여러 서비스와 두 개의 데이터 저장소(비즈니스 레이어 vs 런타임 레이어)를 가로질러 한 번의 요청을 끝까지 따라가고, 로그·트레이스·메트릭으로 프로덕션 문제를 진단합니다.
• 팀의 경계를 넘나듭니다. Business·Product·개발·인프라 팀, 그리고 사내 금융 도메인 전문가와 (영어로) 끊임없이 소통하며, 한 고객에서 배운 것을 제품 로드맵과 공통 인프라로 환원합니다. 태스크를 bird's-eye view와 granular view에서 동시에 봅니다.
• 코딩 에이전트로 빠르게 만듭니다. Claude Code·Cursor 같은 도구로 설계–구현–검증 사이클을 속도감 있게 돌립니다.
• 올바른 질문을 던질 수 있는 분 — 잘 정돈된 reasoning을 바탕으로, 문제 상황에서 핵심을 찌르는 질문을 던질 수 있는 분.
• 영어 정보 소화·소통이 되는 분 — 영어 문서·논문·금융 데이터를 빠르게 읽고 소화할 수 있는 분 (필수). 사내 외국인 동료·도메인 전문가, 글로벌 고객사와 영어로 업무 소통이 가능한 분을 강하게 우대합니다.
• 에이전트를 직접 설계·배포·운영해 본 분 — Python 또는 TypeScript로 에이전트를 설계·배포·모니터링·개선까지 end-to-end로 경험한 분.
• LLM 워크플로우(LangGraph)와 에이전트(Claude Code SDK)를 실제 운영 환경에 scalable하게 배포해 본 경험. 프로토타입을 넘어 사용자에게 서빙되는 수준까지 끌고 가 본 분.
• 에이전트가 도는 인프라부터 백엔드·프론트까지의 전체 동작을 그릴 수 있고, 스트리밍(SSE)·stateful 세션·비동기 설계로 레이턴시를 다룰 줄 아는 분.
• 모호한 요구와 적은 데이터로도 문제를 정의하고, 가설을 세우고, 빠르게 검증해 나가는 추진력이 있는 분.Claude Code·Codex 같은 코딩 에이전트를 능숙하게 다루는 AI-native 엔지니어.
LinqAlpha는 기관투자자(헤지펀드·자산운용사·보험사 등)의 트레이딩과 리서치 프로세스를 돕는 AI 제품을 만드는 핀테크 회사입니다. 국내외 여러 기관 투자자가 종목 분석, 실적·공시 해석, 투자 실사(DD), 마켓 브리핑 같은 실제 리서치 업무에 LinqAlpha를 매일 사용하고 있습니다.
기관 투자자의 리서치는 도메인마다, 심지어 운용역 한 명 한 명마다 일하는 방식이 다릅니다. 같은 "실적 분석"이라도 누군가는 어닝콜 트랜스크립트의 톤 변화를 읽고, 누군가는 가이던스와 컨센서스의 갭을 봅니다. 그래서 모델 하나, 워크플로우 하나로 끝나지 않습니다. 고객의 데이터·투자 방식·관심 자산군·업무 맥락을 깊이 이해하고, 그 위에서 "무엇을 일반화된 에이전트의 행동으로 만들고, 무엇을 도메인에 맞춰 엣지에서 깎아낼지"를 production-grade로 설계해야 비로소 현장에서 "쓸 만한" 제품이 됩니다. 기관 투자자 특성상 제품에 대한 기대 수준은 매우 높고, 이 last mile의 품질을 책임지는 사람이 FDE입니다.
우리는 글로벌하게 일하는 팀입니다. 서울과 뉴욕에 코어 팀이 있고, 영국·싱가포르·홍콩에도 멤버가 있습니다. 사내에는 전직 buy-side·sell-side 애널리스트 등 금융 도메인 전문가와, 10~20명의 외국인 동료가 함께 일합니다. 그래서 영어로 된 정보(논문·기술 문서·공시·금융 데이터·고객 커뮤니케이션)를 빠르게 읽고 소화하는 능력이 매우 중요하며, 사내 도메인 전문가와 영어로 자유롭게 소통하며 "무엇을 만들고 무엇을 개선해야 하는가"를 직접 끌어낼 수 있어야 합니다.
[우리는 이 일을 이렇게 봅니다 (FDE의 정의)]
항상 고객의 문제를 정의하는 것으로부터 시작합니다. 그리고 그 문제를 가장 효과적으로 태클하는 AI 제품을 설계합니다. 이 설계는 자유도 높은 에이전트, 정형화된 워크플로우, 혹은 보다 단순한 형태의 파이프라인일 수도 있는 등 다양한 형태를 띕니다. 하지만 그 어떠한 제품일지라도 그 설계를 구상하고 개발함에 있어 LinqAlpha의 제품 전반과 유기적으로 interweave될 수 있는 agentic foundation을 염두에 두고 작업을 진행합니다.
그래서 FDE는 단순한 SI(시스템 통합) 엔지니어가 아닙니다. 저희가 찾는 사람은 고객의 페인포인트를 깊이 이해하는 동시에, 모든 고객의 페인포인트를 일반화해서 "코어(에이전트)에 넣어 일반적으로 행동을 조율할 것"과 "엣지에서 LLM 워크플로우 및 오케스트레이션으로 풀 것" 사이의 경계를 그어낼 수 있는, 도메인을 이해할 수 있는 개발자입니다.
이 경계는 추상적인 이야기가 아닙니다. 저희 제품에서 그것은 실제로 에이전트의 프롬프트·도구·모델·라우팅을 코드 배포 없이 DB 설정으로 조립·버저닝하는 시스템으로 구현되어 있습니다. 그래서 우리는 "에이전트의 행동은 하드코딩이 아니라 버전 관리되는 설정/데이터" 라는 관점으로 사고하는 사람을 찾습니다.
이 포지션의 본질은 문제 정의의 질에 있습니다.
• 전통적 엔지니어에게는 "무엇을·어떻게 만들지"에 직결되는 만큼만 문제를 정의해도 충분합니다.
• 그러나 이 포지션은 문제를 환원주의적으로(단순 엔지니어링으로 축소해) 풀지 않으면서도, 사용자의 문제를 실제로 해결하기에 '충분한' 수준으로 문제를 정의할 수 있어야 합니다.
• 우리는 에이전트를 Token-to-Token 분포를 이동시키는 장치(distribution shifter)로 봅니다. 따라서 에이전트 개선은 본질적으로 분포 이동(distributional shift)을 다루는 엔지니어링·제어 문제입니다.
• 좋은 FDE는 자신의 엔지니어링 변경이 Canonical한 데이터 분포 위에서 고객의 문제를 실제로 푼다는 것을 '증명'할 수 있고, 그 검증을 토대로 제품을 쌓아 올립니다. "좋아 보인다"가 아니라 "분포 위에서 작동함이 보인다"가 기준입니다.
또한 오늘날의 에이전트 개발은 LangGraph로 워크플로우를 짜는 작업을 넘어 에이전트가 도는 인프라부터 스케일까지를 아우르는 전 과정입니다. 그래서 우리의 바는 높습니다.
• 풀스택 메커니즘 이해 — 에이전트가 어느 노드·Pod·파일시스템 위에서 문제를 푸는지, 어떻게 스케일하는지까지 그릴 수 있어야 합니다. 우리 제품에서 한 번의 대화는 웹 클라이언트 -＞ 다수의 백엔드 서비스 -＞ 세션이 격리된 에이전트 런타임 -＞ 도구 계층(MCP) -＞ 실시간 스트리밍(SSE) 으로 흐릅니다. 이 경로 전체를 그리고, 어디에서 지연·병목·실패가 생기는지 짚어낼 수 있어야 합니다.
• 비동기·스트리밍 설계에 대한 깊은 이해 — 에이전트가 중요하다고 판단한 백그라운드 태스크는 계속 돌리면서도, 그 사이에 부분 결과를 SSE로 스트리밍해 응답하도록 레이턴시를 최소화하는 유연한 구조를 설계할 수 있어야 합니다.
• 컨텍스트 경계 설정 능력 — "이 정보가 고객의 문제를 풀기에 빠짐없이 충분한 집합인가"를 판단할 수 있어야 합니다. 고객의 말을 듣고, 올바른 질문을 던지고, 문제를 충분히 풀기 위한 '데이터와 컨텍스트의 경계'를 상상하고, 정의하고, 소통할 수 있어야 합니다.
그리고 이 일은 엔지니어링만으로는 부족합니다. 일반적인 미시·거시 경제에 대한 이해, 그리고 금융 도메인(buy/sell side, front/mid/back 무관)에서의 경험이 있으면 좋습니다. 무엇보다 금융 산업의 각 도메인 전문가가 어떤 인식 모델(perceptual model)을 갖고 일하는지, 그리고 그 인식이 업계 안에서 어떻게 공유되는지에 대한 분명한 호기심이 필요합니다. (사내에 전직 IB·운용역·애널리스트 동료가 있어, 영어로 소통하며 이 인식 모델을 빠르게 흡수할 수 있습니다.) 그리고 Claude Code 같은 AI 코딩 도구로 자신의 일을 파이프라이닝하고 스스로를 계속 스케일해 나가는 태도를 갖춘 분을 찾습니다.
마지막으로, AI 시대에 가장 중요한 역량 중 하나는 '어떤 질문을 던져야 하는지'를 아는 능력입니다. 저희는 채용 과정에서 지원자의 질문의 질을 핵심적으로 봅니다 — 주어진 문제 상황에서, 잘 정돈된 reasoning을 바탕으로 정확한 질문을 던질 수 있는 사람인지를 가장 우선적으로 평가합니다.
주요업무
• 고객의 진짜 문제를 끝까지 정의하고 풉니다. "무엇이 불편한지"를 넘어 "어떤 의사결정을 더 빠르고 정확하게 하고 싶은지"까지 파고듭니다. 모호한 요구를 구체적 문제로 바꾸고, 문제를 풀기에 충분한 데이터·컨텍스트의 경계를 정의한 뒤, 설계부터 구현·개선까지 직접 끌고 갑니다.• 에이전트를 중심에 두고, 코어와 엣지의 경계를 설계합니다. 한 고객에서 배운 것을 일반화해, 에이전트의 일반 행동으로 환원할 것과 도메인 특화 워크플로우로 깎아낼 것을 구분합니다. 마켓 브리핑 자동화, 실사(DD) 리포트 에이전트, 비정형 문서 검색·인용 워크플로우, 정형 데이터 자연어 질의(TTSQL) 등을 에이전트가 호출·조율하도록 end-to-end로 만듭니다.
• 에이전트 행동을 '설정으로' 운영합니다. 프롬프트 블록·도구 정책·모델·라우팅을 코드 배포 없이 조립·버저닝하고, feature flag와 조건부 규칙으로 고객·맥락별 동작을 분기하며, draft 시뮬레이션 배포의 사이클로 안전하게 바꿉니다.
• 인프라부터 백엔드까지 직접 구현합니다. 외부 시스템·API 연동, 커넥터, 데이터 파이프라인, 서버 로직, 그리고 에이전트가 도는 실행 환경(노드·Pod·스토리지, warm pool, 오토스케일링)까지 — 데모가 아니라 프로덕션 파이프라인을 직접 짭니다.
• 측정 가능한 개선을 합니다. 가설의 정·반·합이 내재화된 평가·테스트 체계(LLM-as-judge, 품질 스코어, 인용·출처 grounding 검증) 를 만듭니다. 실제 사용 로그·트레이스에서 고객사별 실패 케이스를 찾아 경중을 구분하고, canonical 분포 위에서 변경 효과를 검증한 뒤 빠르게 반영합니다. (금융 답변은 출처 귀속이 품질의 필수 요건입니다.)
• 분산 시스템을 E2E로 추적·디버깅합니다. 여러 서비스와 두 개의 데이터 저장소(비즈니스 레이어 vs 런타임 레이어)를 가로질러 한 번의 요청을 끝까지 따라가고, 로그·트레이스·메트릭으로 프로덕션 문제를 진단합니다.
• 팀의 경계를 넘나듭니다. Business·Product·개발·인프라 팀, 그리고 사내 금융 도메인 전문가와 (영어로) 끊임없이 소통하며, 한 고객에서 배운 것을 제품 로드맵과 공통 인프라로 환원합니다. 태스크를 bird's-eye view와 granular view에서 동시에 봅니다.
• 코딩 에이전트로 빠르게 만듭니다. Claude Code·Cursor 같은 도구로 설계–구현–검증 사이클을 속도감 있게 돌립니다.
자격요건
• 문제를 '충분히' 정의할 수 있는 분 — 고객의 문제를 듣고, 기술에 대한 이해를 바탕으로 문제를 정의하며, 그것을 풀기 위한 데이터·컨텍스트의 외연(경계)을 분명히 그리고 소통할 수 있는 분.• 올바른 질문을 던질 수 있는 분 — 잘 정돈된 reasoning을 바탕으로, 문제 상황에서 핵심을 찌르는 질문을 던질 수 있는 분.
• 영어 정보 소화·소통이 되는 분 — 영어 문서·논문·금융 데이터를 빠르게 읽고 소화할 수 있는 분 (필수). 사내 외국인 동료·도메인 전문가, 글로벌 고객사와 영어로 업무 소통이 가능한 분을 강하게 우대합니다.
• 에이전트를 직접 설계·배포·운영해 본 분 — Python 또는 TypeScript로 에이전트를 설계·배포·모니터링·개선까지 end-to-end로 경험한 분.
• LLM 워크플로우(LangGraph)와 에이전트(Claude Code SDK)를 실제 운영 환경에 scalable하게 배포해 본 경험. 프로토타입을 넘어 사용자에게 서빙되는 수준까지 끌고 가 본 분.
• 에이전트가 도는 인프라부터 백엔드·프론트까지의 전체 동작을 그릴 수 있고, 스트리밍(SSE)·stateful 세션·비동기 설계로 레이턴시를 다룰 줄 아는 분.
• 모호한 요구와 적은 데이터로도 문제를 정의하고, 가설을 세우고, 빠르게 검증해 나가는 추진력이 있는 분.Claude Code·Codex 같은 코딩 에이전트를 능숙하게 다루는 AI-native 엔지니어.
