최근에 AI팀과 SA팀을 합쳐 FDE 조직으로 통합했습니다.
반년 넘게 FDE로 일하면서 혼자도 해보고 팀으로도 해봤는데, 그 과정에서 내린 결론을 정리했습니다.
AI 부서를 따로 둘 이유가 있을까
먼저 조직 얘기부터 하겠습니다. 최근 저는 AI팀과 SA팀을 합쳐서 FDE/SA로 통합했어요.
통합한 이유는 간단합니다. AI가 더 이상 리서처의 영역이 아니라면, 굳이 구분된 부서로 둘 필요가 있을까 싶었거든요.
한번 생각해보죠. 요즘 AI 개발이라고 부르는 것들이 실제로 뭔지. 대부분은 이미 서빙되고 있는 모델을 가져다가 인퍼런스하고, 필요한 형태로 래핑하고, 혹은 하네스로 감싸서[1] 에이전트를 만드는 선에서 끝납니다. 모델 자체를 만드는 게 아니에요. 남이 만들어 놓은 것을 어떻게 엮을 것인가의 문제죠.
이걸 별도의 전문 부서가 해야 할 일이라고 부를 수 있을까요. 저는 아니라고 봤습니다.
물론 예외는 있습니다. 모델을 지속적으로 건드리는 일이라든지, 파운데이션 모델을 직접 다루는 일이라든지, MLOps로[2] 배포하고 운영하는 오퍼레이션 엔지니어라면 얘기가 완전히 다르죠. 그건 진짜 별도의 전문성이 필요한 영역입니다. 그게 아닌 이상 AI 디벨롭먼트 부서를 따로 운영하기는 좀 힘들 것 같더라고요.
결국에는 전체를 FDE로 가되, 솔루션 아키텍트라는 직군은 여전히 중요하니까 FDE/SA라는 이름을 붙였습니다. 아키텍처를 설계하는 능력이 사라진 게 아니라, 그 능력을 고객 안에서 쓰는 형태로 바뀐 것뿐이거든요.
FDE라는 롤, 그리고 흔한 오해
FDE는 팔란티어에서 먼저 만든 롤입니다.[3] Forward Deployed Engineer, 고객 안으로 들어가서 같이 팀을 이루고 목적을 이루는 엔지니어죠.
이게 왜 생겼는지를 보면 성격이 분명해집니다. 팔란티어는 온톨로지 시스템을 고객사에 내재화시켜야 했어요.[4] 제품을 팔고 끝나는 게 아니라, 고객의 데이터와 업무 구조를 그 시스템 위에 올려야 하는 겁니다. 그러려면 고객의 도메인을 아는 사람이 안에 들어가 있어야 하죠. AI 시스템을 구축하고 에이전트를 도입하는, 그런 고객 니즈를 충족하려고 만들어진 롤입니다.
그런데 포워드 디플로이드라는 이름 때문인지, 상주로 들어가서 한 명이 히어로처럼 모든 걸 처리하는 구조라고 생각하시는 분들이 좀 있습니다. 실제로도 그렇게 일하는 경우를 많이 봤어요. 고객사에 한 명 꽂아 넣고, 그 사람이 요구사항 받고 설계하고 구현하고 배포까지 다 하는 그림이죠.
그런데 실제로는 그렇지 않습니다. 적어도 저는 그렇게 해서는 안 된다는 결론에 도달했어요.
이 오해가 왜 문제냐면, 채용과 평가가 전부 거기에 맞춰지기 때문입니다. 혼자 다 하는 사람을 뽑으려고 하니까 기준이 계속 올라가고, 그런 사람은 시장에 거의 없어요. 어렵게 뽑아도 그 한 명이 감당할 수 있는 만큼이 그 프로젝트의 상한선이 됩니다. 조직이 아니라 개인의 역량에 프로젝트를 거는 구조가 되는 거죠.
저도 FDE로 전환한 이후에 여러 프로젝트를 혼자 해보고, 팀원들과 함께 해보기도 했습니다. 거기서 내린 결론은 이겁니다.
혼자 일하는 것보다는 조직화된 소규모 팀으로 하나의 문제에 집중하는 것이 옳다.
혼자 일하는 게 편한데, 왜 안 되는가
먼저 솔직하게 말하면, 저는 혼자 일하는 게 더 편합니다.
예전에 개발팀과 나눠서 일해 봤어요. 제가 고객 앞에 서서 PM 역할을 하고, 뒤에서 개발팀이 받아서 처리하는 식이었습니다. 혹은 AI 컴포넌트만 제가 개발하고 일반적인 코어 백엔드 서비스는 개발팀이 주도하기도 했고요.
그런데 하나의 통합된 팀으로 묶이지 않으면 힘들더라고요. 고객이 어제 한 말이 오늘 바뀌는데, 그걸 다른 부서에 전달하고 이해시키고 일정을 다시 잡는 데 드는 비용이 생각보다 큽니다. 다른 부서와 협업하는 것보다 빠르게 피드백을 주고받는 게 훨씬 중요했어요. 그래서 소통 비용이 큰 관계라면 차라리 혼자가 낫다는 게 제 결론이었습니다.
그러면 혼자 하면 되지 않느냐. 여기서 벽에 부딪힙니다.
혼자 일하면 반드시 마주하는 것들이 있어요. 무엇이 있을까요.
일단 시간이 무한하지 않습니다. 이게 전부라고 해도 될 만큼 큽니다. 하고 싶은 것과 제안하고 싶은 것은 머리에 다 떠오릅니다. 이렇게 하면 되겠다는 그림도 그려져요. 그런데 그걸 구현까지 제가 맡으면 시간이 감당이 안 됩니다.
경험이 쌓이면 나아지지 않느냐고 하실 수 있는데, 절반만 맞습니다. 이전 프로젝트 경험이 밑바탕이 되긴 해요. 예전에 했던 것들이 다음 프로젝트에서 판단을 빠르게 해주는 건 분명합니다. 그런데 기업마다 기간도 다르고 버짓도 달라서 똑같이 적용할 수가 없습니다. 저기서 통했던 구성이 여기서는 예산 때문에 못 쓰는 경우가 계속 생기거든요.
설계를 하다 보면 구현할 시간이 없다
구체적인 예를 들어 보겠습니다.
엑셀에 수기로 입력해서 나중에 연말정산에 쓰는 업무가 있다고 합시다. 이걸 디지털 트랜스포메이션 하고 싶다는 요청이 들어옵니다.
방법론은 되게 많죠. 당장 떠오르는 것들도 많습니다. 문제는 그다음입니다.
사람이 원래 만들어 온 프로세스가 있어요. 원래 있던 프로세스가 있고, 그런 지침들도 있습니다. 원래 사람이 이렇게 일을 했다, 여기를 클릭하고 저기에 입력하고 이렇게 진행했다는 절차가 있는 거죠. 그러면 이걸 하나씩 판단해야 합니다.
그거를 API로 바꿀 수 있는지 봐야 하고, API가 없으면 에이전트가 실제로 그 화면에 들어가서 작업하게 할 것인지 정해야 합니다. 에이전트로 간다면 또 에이전트의 워크플로우가 필요하겠죠. 어디서 사람이 확인하고 어디서 자동으로 넘어갈지도 정해야 하고요.
이게 다 설계입니다. 그리고 그 설계하는 일들을 하다 보면 정작 구현할 시간이 부족해서 프로젝트가 끝나 버립니다.
그걸 어떻게 할 것인가에 대한 부분이 가장 커요. 방법을 몰라서가 아니라, 방법은 아는데 컴포넌트 하나하나까지 제가 다 구현하기가 실제로 되게 힘들다는 겁니다. 이게 제가 많이 부딪혔던 한계예요.
그래서 규모로 나눕니다
모든 프로젝트에 팀이 필요하다는 얘기는 아닙니다. 저는 규모로 나눠서 봅니다.
전체가 아니라 부분 포지션만 가져가는 AX라면[5] 혼자 해도 전혀 문제가 없다고 생각하는 주의입니다. 소규모 엔지니어링이 필요한 정도, 에이전트 하네스 하나 붙이는 정도라면 오히려 혼자가 빠르죠. 앞에서 말한 소통 비용이 안 드니까요.
하지만 대규모거나, 고도화된 그래프 엔지니어링이[6] 필요하거나, 페르소나를 깎아야 하거나, 에이전트 하나가 아니라 정교한 시스템을 만들어야 한다면 다릅니다.
이런 것들에 대해서는 기존 프로세스를 AI에 맞는 형태로 바꾸는 작업이 먼저 필요한데, 그건 코드를 짜는 일과 성격이 완전히 다릅니다. 업무를 다시 그리는 일에 가까워요. 그 과정에서 요구되는 게 너무 많습니다.
결국에는 보조하는 사람이 필요했습니다.
다들 같은 얘기를 하고 있다
제가 챙겨보는 유튜버들이 있습니다. 빌더 조쉬도 있고[7], 스페이스와이의 황현태 CEO님 글도 많이 봐요.[8] 그런데 팔란티어까지 포함해서 공통적으로 이야기하는 내용이 있더라고요.
롤 자체가 분리되어야 한다는 것, 그리고 소규모 팀을 이루어야 한다는 것입니다.
서로 다른 곳에서 서로 다른 맥락으로 말하는데 결론이 같으면, 그건 좀 믿어볼 만하다고 생각했습니다.
그럼 소규모 팀은 어떻게 생겼을까요.
일단 오케스트레이션을 할 수 있는 가장 높은 티어의 사람이 한 명 필요합니다. 전체 문제를 보고 누가 무엇을 할지 배분하는 사람이죠. 그리고 그를 보조해 줄 수 있는 두 사람이 필요합니다. 두 사람이라고 말한 건 저희 팀이 세 명이라서 그런 거고, 요는 보조할 수 있는 팀원이 있어야 한다는 겁니다. 황현태 CEO님이 말하는 팟도[9] 서너 명 규모예요.
이건 약간 PM과 PO의 개념이 있는 것 같습니다. 프로젝트 매니저를 맡을 수 있는 시니어 레벨이 최상위 레이어에서 고객과 소통하는 역할을 맡고, 나머지 인원이 테크와 서포트를 맡는 구조죠. 이 구조가 저는 되게 인상 깊었습니다.
결국 파악하는 게 FDE의 일이다
역할을 나누는 얘기를 하기 전에, FDE가 실제로 뭘 하는 사람인지 한번 짚고 가겠습니다.
제가 갖고 있는 건 도메인입니다. 고객의 업무가 어떻게 굴러가는지에 대한 지식이죠. 그런데 이 도메인 지식은 처음부터 제 안에 있는 게 아니에요. 고객에게 요구사항을 전달받거나, 아니면 고객도 정리하지 못한 것들을 제가 파악해서 만들어내는 겁니다.
사실 후자가 더 많습니다. 고객이 자기가 원하는 걸 정확하게 문서로 정리해서 주는 경우는 거의 없어요. 이거 좀 자동화하고 싶다는 말 한 줄에서 출발하는 경우가 대부분이죠.
결국 파악하는 게 FDE의 일입니다. 제품을 만드는 건 그다음이에요.
그래서 팀을 나눈다고 할 때도 이 파악하는 일을 누가 어디까지 맡을 것인가가 기준이 됩니다.
에코와 델타
그래서 저희도 에코와 델타라는 체계를 채택했습니다.
다만 팔란티어의 에코와는 성격이 좀 달라요.[10] 팔란티어에서 에코는 비즈니스 도메인 전문가를 모셔와서 그 도메인에 참여시키는 목적이 큽니다. 금융이면 금융을 아는 사람, 제조면 제조를 아는 사람을 데려오는 거죠.
저희는 그렇게 하기가 어렵습니다. 고객사의 업종이 매번 다르거든요. 그래서 제너럴한 지식을 가지고 고객의 요구사항을 이끌어내는 사람을 에코라고 부르기로 했습니다.
에코는 비즈니스 트랙에 가깝습니다. 고객 요구사항을 듣고 구체화하는데, 테크보다는 이 프로세스를 어떻게 정의할 것인가에 무게가 있어요. 인풋이 뭐고 아웃풋이 뭔지, 그 사이에 어떤 컴포넌트를 끼워야 하는지, 그리고 그게 실제로 동작 가능한지에 대한 간단한 PoC 검증까지가[11] 범위입니다. 어떻게 보면 전통적인 프리세일즈의 역할이죠.
델타는 에코가 구체화해 온 범위를 기술적으로 구현합니다.
겹치지 않으면 무너집니다
여기서 제일 중요한 게 하나 있습니다. 두 역할은 반드시 겹쳐야 합니다.
델타가 고객 입장이나 요구사항을 전혀 모르면 어떻게 될까요. 에코한테 무리한 부탁을 하게 됩니다. 이건 기술적으로 이렇게 해야 하니까 고객을 설득해 오라는 식이죠. 반대로 에코가 테크를 모르면 델타한테 무리한 부탁을 하게 됩니다. 고객이 원하니까 이거 되게 해달라는 겁니다. 둘 다 프로젝트를 망칩니다.
사실 두 사람 다 전체 문제에 걸쳐 있긴 합니다. 에코가 기술을 아예 안 보는 것도 아니고, 델타가 고객을 아예 안 만나는 것도 아니에요. 다만 어느 쪽이 더 비즈니스, 그러니까 고객에게 밀접하게 있는가, 어느 쪽이 더 테크와 구현에 집중되어 있는가의 문제입니다. 완전히 잘라내는 게 아니라 무게중심을 어디에 두느냐인 거죠.
그래서 두 분야 간의 슬라이딩 윈도우는 필요하고, 그 안에서 최대한의 시너지를 내야 합니다. 도메인 지식과 구현 능력이 함께 뒷받쳐져야 하나의 시스템을 내재화하고 도입할 수 있는 거죠.
저는 이 두 역할을 혼자서 다 해봤습니다. 에코처럼 일하다가 델타처럼 일하고, 그러다 다시 에코로 돌아오는 식이었어요. 소규모도 대규모도 진행해봤는데, 결국 시간적으로 부족한 것들이 있더라고요. 한 사람 안에서 두 역할이 겹치는 건 겹침이 아니라 그냥 과부하입니다.
결국 에코팀과 델타팀으로 나눠서 운영하는 것이 베스트였습니다.
사람을 맞는 자리에 앉히는 일
역할을 나눴으면 사람을 앉혀야 합니다. 그런데 팀을 운영하다 보면 사람들 성향이 다 같지가 않아요.
저희 팀만 봐도 비즈니스 성향이 뚜렷한 분과 테크 성향이 뚜렷한 분이 나뉘어 있습니다. 고객 앞에서 말이 술술 나오는 사람이 있고, 코드 앞에서 편안한 사람이 따로 있어요. 이런 분들을 좋은 포지션에 위치시키는 것도 팀장의 능력이겠죠.
최근에 유튜브를 봤는데 이런 얘기가 나오더군요. 내 팀원이 떠난다고 했을 때 가장 먼저 돌아봐야 할 것은, 이 사람을 올바른 포지션에 앉혔는가라는 겁니다.[12]
이 말이 오래 남았습니다. 보통은 처우나 조직 문화를 먼저 떠올리잖아요. 아니면 그 사람의 역량이 부족했나를 보게 되고요. 그런데 자리가 안 맞으면 그 사람은 매일 자기가 잘 못하는 일을 하면서 지내는 거예요. 그만큼 이제는 그 포지션이 갖고 있는 기술적인 한계보다, 그 포지션에 진짜 맞는 업무를 할 수 있는 사람이 필요한 거죠.
아직 답을 못 찾은 것들
여기까지가 지금 제가 내린 결론인데, 솔직히 정리가 안 된 것들도 있습니다.
하나는 팀 크기입니다. 에코팀과 델타팀으로 운영하는 게 베스트였다고 했는데, 팀이 세 명인 상황에서 이게 팀을 둘로 쪼갠다는 뜻인지 한 팀 안에서 역할만 나눈다는 뜻인지 저도 아직 명확하지 않아요. 지금은 후자에 가깝게 하고 있습니다.
또 하나는 SA의 자리입니다. FDE/SA로 이름을 붙이긴 했는데, 솔루션 아키텍트가 에코에 가까운지 델타에 가까운지, 아니면 둘 다 걸치는 제3의 역할인지는 더 해봐야 알 것 같습니다.
마지막은 판단 기준이에요. 혼자 할 규모와 팀이 필요한 규모를 나눈다고 했지만, 실제로 프로젝트를 처음 받았을 때 그걸 어떻게 판별할지는 아직 감으로 하고 있습니다. 이건 사례가 더 쌓여야 기준이 나올 것 같아요.
정리하면
말이 좀 돌아갔는데, 하고 싶었던 얘기는 하나입니다.
FDE 조직은 소규모 팀으로 운영해야 한다.
에코와 델타로 나누든, 서너 명짜리 팟으로 구성하든 상관없습니다. 중요한 건 혼자 일하는 것이 마냥 좋은 것은 아니더라는 겁니다. 저는 혼자가 편한 사람인데도 그렇게 결론이 났어요.
혼자 할 때는 제가 못 하는 부분이 그대로 프로젝트의 한계가 됩니다. 설계에 시간을 쓰면 구현이 밀리고, 구현에 붙으면 고객과의 대화가 끊기죠. 팀이면 그게 안 됩니다. 정확히는, 안 되게 만들 수 있습니다.
소규모 팀을 구성하고, 각자 장점이 뚜렷한 사람을 맞는 자리에 앉혀서 최고의 프로젝트를 만들어내는 것, 결국에는 그게 중요하겠죠.
주석
[1] 여기서 하네스는 모델 호출 주변을 감싸는 실행 골격을 말합니다. 프롬프트 구성, 도구 호출, 반복 제어, 실패 처리 같은 것들을 묶어 놓은 층입니다. 모델을 바꾸는 게 아니라 모델을 쓰는 방식을 코드로 고정하는 작업에 가깝습니다.
[2] 머신러닝 모델의 학습, 배포, 모니터링, 재학습을 운영 관점에서 자동화하는 실무 영역입니다.
[3] Forward Deployed Engineer는 고객사 안에서 소프트웨어를 개발하고 배포하는 고객 대면 엔지니어를 뜻합니다. 위키피디아는 이 롤을 a customer-facing software engineer who develops and deploys software within a client company로 정의하고, The role was popularized by Palantir Technologies라고 적고 있습니다. Forward Deployed Engineer, Wikipedia
[4] 팔란티어 Foundry의 온톨로지는 고객사의 데이터와 업무 개념, 그리고 그 위에서 실행되는 액션을 하나의 의미 계층으로 묶는 구조를 말합니다. 제품을 도입한다는 것이 곧 고객의 업무 구조를 이 계층 위에 올린다는 뜻이라, 고객 안에 들어가 일하는 롤이 필요해진 배경이기도 합니다.
[5] AX는 AI Transformation을 줄인 말로, 디지털 전환(DX)에 빗대어 쓰는 표현입니다. 조직의 업무 방식 자체를 AI에 맞게 다시 짜는 쪽에 무게가 있어서, 모델을 도입한다는 말보다 범위가 넓습니다. 앞서 인용한 스페이스와이도 FDE+AI 기반 AX 모델이라는 표현을 씁니다.
[6] 문서나 데이터를 개체와 관계의 그래프로 구성해 검색과 추론에 쓰는 방식을 가리킵니다. 단순 벡터 검색으로 답이 안 나오는 영역에서 최근 자주 언급됩니다.
[7] 빌더 조쉬 (Builder Josh) 유튜브 채널. 기업과 스타트업에서 실제로 쓰이는 AI를 다룹니다. youtube.com/@builderjoshkim
[8] 스페이스와이(SpaceY)는 2022년 1월 설립된 국내 스타트업으로 황현태 대표가 공동창업했습니다. 기업과 전문 인력을 잇는 DIO를 운영하며, FDE에 AI 에이전트를 결합한 FDE+AI 모델을 내세우고 있습니다. 황현태 대표는 실리콘밸리에서는 이미 제품형 B2B SaaS에서 고품질 인력이 현장에 들어가 커스터마이징하는 FDE 모델로 흐름이 이동하고 있다고 말합니다. 황현태 대표 링크드인
[9] 팟은 하나의 목표를 함께 맡는 소수 인원의 실행 단위를 뜻합니다. 부서 단위 조직과 달리 문제 하나를 기준으로 묶였다가 흩어지는 구성을 가리킬 때 씁니다.
[10] 본문에서 말하는 에코와 델타는 팔란티어 방식을 그대로 가져온 것이 아니라 저희 조직에 맞게 다시 정의한 것입니다. 팔란티어 생태계에서 통용되는 구분에서는 델타가 데이터 파이프라인, 온톨로지 모델링, 에이전트 설계를 포함한 프로덕션 구현을 맡고, 에코는 구축된 솔루션이 실제 업무에 정착하고 계속 가치를 내도록 운영과 확산을 맡는 쪽에 가깝습니다. 본문의 에코는 그보다 앞단, 요구사항을 끌어내고 프로세스를 정의하는 역할에 무게가 있습니다. 같은 이름을 쓰지만 범위가 다르다는 점을 감안하고 읽어주세요.
[11] Proof of Concept. 여기서는 완성품을 만드는 것이 아니라, 정의한 프로세스가 실제로 동작할 수 있는지를 최소한으로 확인하는 수준을 뜻합니다.
[12] 기업의 핵심인재를 구분하는 질문 7가지 (퇴사한 이형). https://youtu.be/FPXPxtBOS7E?si=w6im7pWqiUKxlLka
참고
이 글의 주장과 판단은 제 경험에서 나온 것입니다. 위 자료는 용어와 사실관계를 확인하는 데 참고했습니다.