래티스 FDE는 이렇게 일하고 있습니다 | 래티스 한예진 FDE 인터뷰

래티스에는 요구사항 문서를 기다리지 않는 적극적인 개발자들이 있습니다. 고객사로 들어가 업무부터 배우고, 더 나은 방식이 보이면 먼저 제안하고, 그 제안을 직접 개발해 시스템으로 만듭니다. 래티스는 이 역할을 FDE(Forward Deployed Engineer)라고 정의합니다.

오늘은 래티스의 한예진 FDE 님(이하 “예진님”)을 만나서 래티스에서 FDE로 일한다는 것은 예진님에게 어떤 의미인지 알아보는 시간을 가져보려고 합니다.

예진님은 국내 최대 조선사의 선박 엔지니어링 문서 관리 시스템, 국내 금융사의 계약 관련 업무 자동화, 계약관리 솔루션 프릭스 고도화 등 성격이 다른 산업의 다양한 프로젝트를 담당해왔습니다.

Q. 먼저 간단히 자기소개 부탁드립니다.

안녕하세요, 래티스에서 FDE로 일하고 있는 한예진입니다!

FDE는 고객사 현장에서 업무를 직접 파악하고, 그 안에서 풀어야 할 문제를 찾아 시스템으로 해결하는 역할이에요. 고객사 소통부터 기획, 개발까지 전부 맡습니다.

저는 지금까지 조선/방산 분야의 건조사양서 통합 관리 시스템과 특수선 지식 관리 시스템 등의 프로젝트들을 진행했고, 최근에는 부동산신탁사의 담보신탁 계약 업무를 AI로 자동화하는 프로젝트를 담당하고 있습니다. 그리고 래티스의 계약관리 솔루션(CLM: Contract Lifecycle Management) 프릭스의 주요 담당자로서 고도화 작업도 함께 맡고 있어요.

Q. 일반적인 개발자/SI와는 어떤 점이 다른가요?

컨설턴트, PM, 개발자, 운영 담당처럼 여러 사람이나 여러 팀이 나눠서 하던 일을 한 사람이 처음부터 끝까지 가져간다는 점이 가장 다릅니다. 개발 명세서를 그대로 구현하는 게 아니라 기획 단계에서부터 참여해서 개발 범위를 직접 만들어 나가는 거죠.

요구사항을 전달받는 사람과 개발하는 사람이 따로 있지 않으니 요구사항이 중간에서 왜곡되지 않고, 회의에서 나온 이야기가 바로 코드로 이어져요. 그만큼 속도감 있게 진행할 수 있습니다.

맥락이 한 사람에게 모인다는 것도 큰 장점이에요. 기획 문서, 회의록, 의사결정 메모를 전부 한 사람이 한 곳에서 관리하니까, 고객과 소통할 때도 "그때 왜 그렇게 하기로 했더라"를 찾느라 혼선이 생기지 않고, AI를 활용할 때도 그 맥락을 통째로 주고 바로 참고하게 할 수 있습니다.

이런 방식이 가능해진 데는 AI의 발전이 큰 역할을 했다고 생각해요. 개발 속도가 올라가면서 한 사람이 이 범위를 다 감당할 수 있게 됐으니까요.

코드보다 먼저 배우는 것

Q. 조선/방산 분야에서는 어떤 프로젝트를 맡으셨나요?

주요 프로젝트 중 하나는 선박 건조사양서 통합 관리 시스템입니다. 건조사양서는 선주와 합의한 배 한 척의 설계 기준 문서로서 엔지니어링의 핵심 문서에요. 건조사양서는 선박의 유형 및 규모에 따라 다르지만, 최소 수백 페이지 이상의 문서이고, 많은 수의 설계원들이 공동으로 생성 및 수정을 거치는 절차가 필요해요.

이 과정에서 각 부서 담당자들은 주로 메일로 파일을 주고받으며 수정하다 보니, 파일의 히스토리 관리 및 최신본 확인이 어려운 점이 있었어요. 이에 건조사양서의 항목을 모두 파싱하여 DB화하여 관리하고, 익숙한 에디터 화면에서 이를 편집할 수 있는 통합 시스템을 구축해서 설계원들의 워크플로우를 고도화하는 프로젝트를 진행했습니다.

제가 맡았던 건 그중에서도 배를 짓는 내내 쌓인 개정 내용을 최종 사양서로 확정하는 기능(‘As-Built’)이었습니다. 통상 선박의 사양서는 공종별 책임자(K.P)가 내용을 검토 및 확정하여 완성본을 도출하여 선주에게 제공한 이후에는 더 이상 수정할 수 없도록 제한이 필요합니다. 그만큼 중요한 절차이기에 단계별로 실무상 엄격하면서 까다로운 워크플로우 구현이 필요했어요. FDE가 고객의 업무를 자세하게 이해해야 하는 이유를 처음으로 체감한 프로젝트였습니다.

또 다른 프로젝트는 방산 분야의 프로젝트로 특수선(잠수함/수상함 등) 건조와 관련된 노하우 및 이슈를 관리할 수 있는 지식관리 시스템이었고, 제가 전체 기획을 총괄했던 뿌듯한 기억이 있습니다. 특수선은 통상 선도함을 따라 후속함을 건조하기 때문에 같은 이슈가 호선마다 반복되기 쉬운데, 이전 호선의 해결 방법은 여러 시스템에 흩어져 있거나 숙련된 엔지니어 분들의 머릿속에만 암묵지로 존재해서, 그분들이 은퇴하면 그대로 휘발되는 문제가 있었어요. 그 암묵지가 사라지기 전에 조직의 자산으로 모아 두자는 게 이 시스템의 목적이었습니다. 이슈 발생부터 원인 분석, 조치, 종결, 그리고 그 교훈이 지식으로 등록되어 회사의 소중한 무형자산이 될 수 있도록 돕는 의미 있는 프로젝트였습니다.

Q. 조선업의 용어부터가 개발자에게는 상당히 생소했을 텐데요. 그렇게 생소한 산업의 프로젝트를 맡으실 때는 어떻게 시작하시나요?

용어부터 굉장히 낯설었습니다. 그런데 프로젝트를 진행하려면 결국 담당자분이 어떤 상황에서 이 화면을 열게 되는지 알아야 해요. 버튼 하나를 만드는 것도 그냥 UI 문제가 아니거든요. 누가 이 버튼을 누르는지, 업무의 어느 단계에서 누르는지, 누르고 나면 일이 누구에게 넘어가는지까지 모두 파악하고 있어야 제대로 만들 수 있습니다. 그래서 개발하면서도 "이걸 어떻게 구현하지"만 생각하는 게 아니라 "왜 이 단계가 존재하지", "이 정보는 다음에 어디서 쓰이지"를 같이 생각하게 됩니다.

그래서 새 프로젝트에 들어가면 그 산업을 공부하는 게 먼저입니다. 관련 글이나 고객사에서 받은 자료를 꼼꼼히 읽어서 산업 전반과 업무 프로세스를 정확히 이해하려고 해요. 예를 들어 지금 하고 있는 금융 프로젝트에서는 담보신탁이라는 계약 구조부터 공부했어요. 위탁자가 부동산 소유권을 신탁사에 이전하고, 신탁사가 대출기관에게 우선수익권증서를 발급하고, 채무 불이행 시 신탁사가 공매로 환가해서 우선수익자에게 정산하는 구조인데, 이걸 알아야 서류 하나하나가 무엇을 위해 존재하는지가 보이더라고요. 처음에는 수십 개의 서류 목록이 각각 무엇을 의미하는지 몰라 막막했는데, 각 서류를 세부적으로 살펴보고 현업분들과 말씀 나누며 무엇을 위해 징구하는지 이해하고 나니 목록이 아니라 구조로 보였습니다.

이렇게 미리 공부하고 들어가는 이유가 있어요. 현업 미팅에서는 전문용어가 쏟아지거든요. 기본적인 용어와 프로세스를 알고 들어가야 짧은 시간 안에 밀도 있게 깊은 이야기를 나눌 수 있고, 그래야 의미 있는 문제 정의와 논의가 가능합니다.

그리고 공부한 내용은 제 언어로 정리해서 담당자분께 확인받습니다. 제가 이해한 업무 구조를 그림과 글로 보여드리고 틀린 부분을 피드백 받는 건데, 이게 생각보다 중요합니다. 잘못 이해한 채로 개발에 들어가는 걸 막아주기도 하고, 담당자분 입장에서도 이 사람들이 우리 업무를 어디까지 이해했는지 확인하시는 계기가 되거든요. 신뢰가 여기서부터 쌓이는 것 같아요.

담당자의 하루를 처음부터 복기합니다

Q. 프로젝트가 시작되면 실제로 어떤 순서로 일하시나요? 일반적인 개발 과정과 다른 점이 있을까요?

먼저 고객사 담당자분들과 현업 인터뷰를 하면서 지금 업무가 어떻게 돌아가는지, 실제 업무상 문제가 무엇인지 확인합니다. 고객이 쓰시는 문서와 자료를 직접 보면서 현재 업무를 단계별로 정리하고요. 그다음 정의한 문제를 제품에서 어떻게 풀지 설계합니다. 화면 구조를 바꿀 수도 있고, 데이터 구조나 워크플로우를 다시 잡을 수도 있어요.

고객사도 AX 프로젝트를 계획하시면서 AI를 도입해 업무 효율을 높이고 싶어 하시지만, 정작 어느 업무에 어떤 방식으로 접목해야 할지는 어려워하세요. 매일 하시는 일이라 어디에 AI를 넣을 수 있는지가 안에서는 오히려 잘 안 보이거든요. 저희는 외부인의 시선으로 업무 흐름을 처음부터 끝까지 쭉 보면서, 이 부분은 이렇게 바꿀 수도 있겠다, 저 부분은 저렇게 붙일 수도 있겠다 하는 아이디어를 여러 개 떠올립니다. 여러 산업에서 AX 프로젝트를 해 본 경험이 있으니 그런 가능성이 좀 더 잘 보이는 것 같아요. 그 아이디어들을 현업분들께 검토받고, 와이어프레임까지 그려 가면서 현업분들이 생각하시는 그림과 점점 맞춰 나가요.

프로젝트 진행 과정에서 지속적으로 방향을 고도화해나가고, 산정된 일정에 맞추어 직접 개발도 진행하게 됩니다.

개발 자체는 일반적인 개발자가 하는 것과 다르지 않아요. 확정된 기획대로 데이터 구조를 잡고, API와 화면을 만들고, 테스트하고 배포합니다. 기획까지 맡으면 코드 쪽 전문성이 얕아지지 않을까 걱정하실 수도 있는데, 실제로는 그렇지 않았어요. AI 도구가 발전하면서 반복적인 구현에 드는 시간이 크게 줄어서, 개발만 하던 때와 비슷한 밀도로 코드를 쓸 수 있거든요. 오히려 업무 맥락을 제가 다 알고 있으니 데이터 구조나 화면 흐름 같은 설계 판단이 훨씬 빨라졌고, 그만큼 코드의 구조와 품질을 고민하는 데 시간을 더 쓸 수 있게 됐습니다. 개발이 끝나면 배포하고, 정기 회의에서 직접 시연하면서 피드백을 받아요. 실제 담당자분이 써보시면 개발할 때 예상하지 못한 예외와 불편이 바로 나오거든요. 그걸 반영해서 다시 배포하는 걸 반복합니다.

Q. 현업 인터뷰는 어떻게 진행하시나요? 실제로 어떤 것들을 여쭤보시는지 궁금합니다.

접근 방식이 중요한 것 같아요. 해결 방법을 정해 두고 들어가지 않고, 지금 업무를 어떻게 하고 계신지를 있는 그대로 최대한 자세히 파악하려고 노력합니다.

업무 요청이 들어오는 순간부터 종결되는 순간까지 손이 닿는 모든 지점을 따라가면서 여쭤봅니다. 요청은 어떤 경로로 들어오는지, 필요한 자료는 누구에게 어떻게 받으시는지, 받은 자료는 어디에 어떻게 정리하시는지, 문서를 작성할 때는 어느 값을 보고 채우시는지, 검토와 결재는 누가 어떻게 하시는지까지요. 현업분들이 실제로 쓰시는 파일도 전부 받아서 봅니다. 메일 양식, 문서 서식, 실제 건의 자료 같은 것들이요. 조금 과장하면 그 업무를 거의 직접 해볼 수 있을 정도로 깊게 파고듭니다.

왜 이렇게까지 캐묻느냐면, 현업분들이 "실제로 사용하는" 시스템을 만드는 것이 목표이기 때문이에요. 그러려면 세 가지가 필요합니다. 1. 예외를 빠짐없이 처리해야 하고, 2. 기존 프로세스가 비효율적이면 규칙부터 바꾸자고 제안해야 하고, 3. 표준화가 덜 되어 있으면 표준화까지 해 드려야 해요. 이 세 가지는 업무를 겉으로만 봐서는 하기 어려워서 더 캐묻게 되는 것 같아요. 그리고 이렇게 따라가다 보면 고객이 처음 요청하신 기능이 문제의 전부가 아니라는 게 보이기 시작합니다.

Q. 그렇게 모은 내용은 어떻게 정리하시나요?

먼저 업무 방식을 플로우차트로 그려 봅니다. 그리고 받은 문서들끼리 서로 맞춰 보면서 비어 있는 지식과 궁금한 점을 전부 뽑아서 여쭤봐요. 예를 들어 계약서 서식의 빈칸 하나하나가 징구 서류의 어느 항목에서 오는지 매핑해 보면, 어디에도 출처가 없는 값이 반드시 나옵니다. 그런 것들이 질문 목록이 돼요.

정리 과정에서 가장 신경 쓰는 부분은 암묵지를 찾는 것입니다. 같은 서류를 보고도 어떤 건은 통과시키고 어떤 건은 반려하시잖아요. 그 기준이 업무규정에 다 적혀 있으면 좋은데, 실제로는 담당자분 머릿속에만 있거나 다들 암묵적으로 그렇게 하고 있는 경우가 정말 많습니다. "보면 압니다"라고 하시는 그 부분이요. 그래서 그런 항목이 나오면 "이런 때는요, 그럼 이런 때는요" 하면서 모든 경우를 다 물어봅니다. 몇 번 반복하면 담당자분이 "아, 그럴 때는 이렇게 하고 있었네요" 하면서 본인도 몰랐던 규칙이나 패턴을 정리하실 수 있게 돼요. 이렇게 머릿속에만 있던 기준을 성문화하다 보면 전체 프로세스가 자연스럽게 정리됩니다. 이 일에서 제일 재미있는 순간이기도 합니다.

Q. 담당자분들이 너무 당연해서 말씀을 안 하시는 부분도 있을 것 같습니다.

생각보다 정말 많은 것 같고, 그래서 산업과 고객을 이해하기 위해 노력을 해야 하는 것 같아요.

예를 들어, 계약서 관련 AX 프로젝트의 경우 계약서를 깊이 이해하는 것이 필요한데, 계약서에 특정한 내용이 별도로 정의되어 있지 않고, 상관행 등이 당연히 전제되어 있는 경우가 많습니다. 같은 주체의 경우에도 “위탁자”, “채무자” 등 다양한 용어로 표현되기도 하고, 법인격의 주체(법인/개인)에 따라서 계약서의 내용이 달라지기도 하기 때문에 실무를 정확히 이해해야 합니다.

그렇게 여쭤보다 보면 담당자분도 “실무상 이렇다”, “업계에서는 이렇게 본다”고 하시는 부분이 나와요. 계약서 한 장을 제대로 읽으려면 그 뒤에 깔린 전제까지 같이 읽어야 하는 거죠.

Q. 현업분들과 이야기하는 과정에서 혼선이 생긴 적은 없었나요?

같은 회사 내에서도 부서별로 용어의 정의가 달라서 서로 다른 이야기를 하는 경우도 있었어요. 같은 단어도 누군가는 특정 문서를 말하기도 하고, 다른 부서에서는 절차를 의미하기도 해서 혼란스러웠던 기억이 납니다.

이게 무서운 게, 처음에는 대화가 되는 것처럼 보인다는 점이에요. 서로 알아듣는 줄 알고 회의가 끝나요. 그런데 데이터 구조를 짜거나 개발을 다 해 놓고 나서야 그때 서로 다른 걸 말하고 있었다는 게 드러나요. 그 시점에 발견하면 테이블 구조부터 화면까지 다시 갈아엎어야 하는데, 실제로 그런 경험을 몇 번 했습니다.

그래서 이제는 프로젝트 초반에서 함께 용어를 정의하는 것부터 시작해요. Working Group 내에서 용어를 함께 정의하면, 그 용어가 최종 시스템에도 반영되기 때문에 궁극적으로 전사적으로 용어를 통일하는 효과도 있습니다.

Q. 지금은 부동산신탁사의 담보신탁 계약 업무를 자동화하고 계시죠. 어떤 프로젝트인가요?

부동산신탁사의 담보신탁 계약 업무 중에서 사람이 반복적으로 확인하고 작성해야 하는 부분을 AI와 소프트웨어로 효율화하고 있습니다. 담보신탁은 대출을 받으려는 위탁자가 부동산을 신탁사에 맡기고, 신탁사가 대출기관에 우선수익권증서를 발급해 주는 구조인데, 계약 한 건을 위해 수십 종의 서류를 위탁자와 금융기관에게서 수집하고, 각 서류에서 차주, 담보제공자, 대출금액 같은 값을 찾아내고, 그 값으로 다시 신탁계약서와 고객거래확인서 같은 작성 서류를 채우고 검토하는 과정이 있거든요.

처음에는 개별 기능의 자동화로 보일 수 있는데, 들여다보면 모든 업무가 연결되어 있습니다. 그래서 문서 하나를 자동 생성하는 기능으로 접근하지 않고, 서류 수집부터 누락 확인, AI 정보 추출, 계약서 자동 작성, 검토, 결재, 체결까지 전체 흐름을 하나의 시스템으로 어떻게 연결할지를 먼저 고민했습니다. 예를 들어 서류를 올리면 AI가 종류를 판별해서 필수 서류 슬롯에 넣고, 빈 슬롯이 곧 누락 서류 요청 메일이 되고, 슬롯에 들어온 서류에서 추출한 값이 그대로 계약서 서식의 빈칸으로 흘러가고, 작성된 서류는 다시 수집 서류와 교차 검토되는 식이에요.

조선과 금융은 용어도 업무도 완전히 다르지만, 이렇게 업무의 전체 흐름부터 이해하고 들어가는 방식 자체는 똑같았어요.

현장에서 배운 것들

Q. 고객사의 폐쇄망 환경에서도 일하셨습니다. 일반적인 개발과 많이 다른가요?

폐쇄망에서의 배포는 고객사 인프라에 대한 이해와 노하우가 필요해요.

특히, 특수선 프로젝트는 군사 기밀을 다루는 보안 과제라 외부와 완전히 단절된 방산망 안에 시스템을 올려야 했어요. 그래서 거제 현장에 직접 내려가서 방산망에 들어가 배포 작업을 한 적이 있습니다.

무엇보다 환경 자체가 완전히 달랐어요. 평소 쓰던 개발 도구도, 검색도, AI도 없는 상태에서 서버를 구축하고 배포해야 했습니다. 필요한 파일 하나를 반입하는 데도 신청을 올리고 승인을 기다려야 해서, 파일 하나가 빠진 걸 발견하면 그날 작업은 거기서 멈추는 식이에요. 익숙한 환경에서라면 몇 분이면 끝날 일이 하루 종일 걸리기도 했습니다.

이런 경험이 팀에 쌓이면서 순서가 바뀌었어요. 앞 프로젝트에서 겪었던 것들을 팀에서 문서로 정리해두고, 그다음부터는 서버를 구축하기 전에 필요한 권한, 방화벽, 접근 경로를 목록으로 만들어 한 번에 요청드리고 있습니다. 막힐 때마다 하나씩 요청드리면 그때마다 결재를 기다리느라 며칠씩 밀리는데, 처음에 목록으로 드리면 담당 부서에서도 한 번에 처리해 주실 수 있으니까요.

Q. 이야기를 들어보면 개발자이기도 하고 PM이나 컨설턴트 같기도 합니다. 직접 일해보니 어떤 역할인가요?

문제를 정의하는 사람과 해결하는 사람이 분리되어 있지 않다는 게 FDE의 특징이라고 생각해요.

고객의 업무를 이해하고 문제를 구조화하는 건 컨설턴트, 무엇을 만들지 정하고 일정과 소통을 챙기며 프로젝트를 끌고 가는 건 PM, 그걸 실제로 구현하는 건 개발자의 일과 닮아 있어요. FDE는 이 모든 업무를 한 사람이 처음부터 끝까지 가져가는 역할입니다. 결국 결과물은 작동하는 시스템으로 남아요. 제안한 대로 만들어서 실제로 쓰이니까, 그만큼 책임도 무겁고 맞았는지 틀렸는지도 바로 드러납니다.

좋은 점은 "내가 낳은 프로덕트"라는 감각이에요. 개발자로 티켓을 분배받아 일하던 때는 프로젝트에 대한 주인의식이 덜했고, 전체 기획을 이해 못 할 때도 많았습니다. 왜 필요한지 배경을 모르니 불만이 생기기도 하고, 긴급함도 잘 안 느껴졌어요. 배포되고 나서도 QA할 대상으로만 보였고요. 지금은 전체 배경과 각 기능이 생긴 이유를 다 알고, 제가 기획에 크게 영향을 줄 수 있다 보니 책임감이 훨씬 커졌고 성취감도 강하게 옵니다. 고객의 반응을 즉각적으로 들을 수 있어서 스스로의 성장에도 도움이 많이 돼요.

힘들었던 점은 컨텍스트 스위칭입니다. 업무 종류가 정말 다양해지다 보니 초반에는 그게 힘들었어요. 많은 작업을 동시에 병렬로 진행하다 보니 어떤 작업을 하고 있었는지 까먹을 때도 많았고요. 그런데 AI 시대에는 어차피 필수적인 능력이라고 생각했고, 훈련하다 보니 괜찮아졌습니다. 작업 속도가 엄청 늘었고, 혼자서도 정말 많은 일을 할 수 있게 됐어요.

Q. 마지막으로, 고객사 담당자 입장에서 래티스와 일할 때 다른 개발사와 가장 다르게 느끼실 지점은 뭘까요?

질문을 많이 받으신다는 점을 가장 다르게 느끼실 것이라고 생각합니다. 그것도 기능에 대한 질문이 아니라 업무에 대한 질문을요.

요구사항 문서를 주시면 그대로 만들어 드리는 게 서로 편한 방식이긴 합니다. 문서대로 만들었으니 책임 소재도 깔끔하고요. 그런데 그렇게 만든 시스템이 현장에서 쓰이지 않으면 그 깔끔함이 무슨 의미가 있을까요? 저희는 문서에 적히지 않은 부분을 먼저 여쭤보고, 표준화되지 않은 채 암묵적으로 굴러가던 것들을 수면 위로 올려서 같이 성문화한 다음에 개발합니다. 담당자마다 조금씩 다르게 쓰던 서류 요청 메일을 하나의 양식으로 정리하고, 건마다 달랐던 필수 서류 목록을 확정하고, "보면 안다"던 검토 기준을 조건으로 적어 내려가는 일이요. 초반에는 오히려 일이 늘어나는 것처럼 느껴져서 번거로우실 수 있어요. 하지만 한 번 정립해 두고 시스템화하면 그 이후에는 효율이 두 배 이상 늘어나는 걸 느끼실 겁니다. 다시 만드는 일이 줄어드니까요.

특히 AI를 업무에 도입하려면 이 성문화가 필수예요. 사람은 "보면 안다"로 넘어갈 수 있지만 AI는 기준이 글로 적혀 있어야 그대로 따를 수 있거든요. 그런데 그 작업을 고객사가 혼자 하기는 쉽지 않아요. 래티스는 질문을 던지고, 정리하고, 그 기준을 그대로 시스템과 AI에 심는 일을 여러 산업에서 반복해 왔으니까, 그 과정을 가장 잘 도와드릴 수 있다고 생각합니다.

그리고 이렇게 질문하고 정리하는 과정 자체가 프로젝트를 거듭할수록 발전합니다. 업무를 파악하는 방식, 정리하는 방식, 회의를 운영하는 방식이 프로젝트마다 그대로 다음으로 넘어가면서 점점 다듬어지거든요. 한 프로젝트에서 배운 게 다음 프로젝트의 출발선이 되니까, 일종의 플라이휠처럼 돌아가는 것 같아요.

---

래티스는 고객의 현장에 들어가 업무를 배우는 것에서 프로젝트를 시작합니다. 문서에 적히지 않은 예외와 암묵지까지 시스템에 담기 위해서입니다.

💼 시스템 도입을 검토하고 계시다면?

→ 문의하기로 연락 주세요.

💻 FDE로 함께 일하고 싶으시다면?

→ 채용 공고를 확인해 주세요.