AI로 일하는 개발팀은 무엇이 다를까?

Intelligence Lab / Adam

Intelligence Lab에서 AI/ML Engineer로 일하고 있습니다. 담당하는 영역은 크게 세 가지입니다.

첫째는 계약서 문서 처리 파이프라인입니다. 고객이 계약서를 업로드하면 AI가 문서를 자동으로 읽고, 계약 유형을 분류하고, 핵심 조항과 메타데이터를 추출하는 전체 흐름을 설계하고 구현합니다. 계약 당사자, 계약 기간, 금액, 해지 조건 같은 주요 항목을 정확하게 뽑아내는 것이 핵심입니다.

둘째는 LLM 기반 기능 설계와 프로토타이핑입니다. 캐비닛의 'Agentic Search' 같은 지능형 기능의 프롬프트 전략을 설계하고, RAG 파이프라인을 구축합니다. 단순히 모델을 호출하는 게 아니라, "이 기능이 고객의 어떤 문제를 해결하는가"를 PM, PD, 엔지니어와 함께 정의하고, 정확도와 사용자 경험의 균형을 맞추는 데 집중합니다.

셋째는 AI 품질 관리 체계입니다. Evaluation Dataset을 구축하고, Confidence Score 기반으로 자동 처리와 사람 검토 큐를 분리하는 정책을 설계합니다. "95% 이상 정확도"라는 숫자 뒤에는 실패 사례를 하나하나 분석하고 벤치마크에 추가하는 반복 과정이 있습니다.

아침에 출근하면 전날 실험 결과와 서비스 로그를 먼저 확인합니다. 추출·답변 정확도가 어떻게 나왔는지, 실패 케이스는 어떤 패턴인지를 살펴보죠. 오전에는 프롬프트 개선이나 RAG 파이프라인 튜닝 같은 집중 작업을 하고, 오후에는 PM·프로덕트 팀과 기능 스펙을 논의하거나 새로운 AI 기능의 PoC를 진행합니다.

2~3년 전과 가장 크게 달라진 건 AI가 개발 도구이자 동시에 제품 그 자체가 되었다는 점입니다. 예전에는 코딩 생산성을 높이기 위해 AI를 보조적으로 쓰는 정도였다면, 지금은 AI 자체가 제품의 핵심 기능입니다. 코드 작성은 물론 프롬프트 초안, 테스트 케이스 생성까지 LLM을 적극적으로 활용합니다.

회사 차원의 지원도 확실합니다. NLP 전문가인 CTO님이 합류하시면서 Intelligence Lab이 만들어졌고, Google Gemini, Claude 등 다양한 LLM API를 빠르게 실험할 수 있는 환경이 갖춰져 있습니다. "1~2주 안에 PoC를 만들어 가설을 검증하자"는 문화도 자리 잡혀 있고, 실험에 실패해도 그 자체가 학습이라는 분위기 덕분에 과감하게 시도할 수 있습니다.

가장 큰 변화는 엔지니어의 역할 자체가 바뀌었다는 점입니다. "모델 실험 담당"에서 "AI Feature 오너"로요.

예전에는 데이터 전처리하고, 모델 돌리고, 정확도 숫자를 리포트하면 역할이 끝나는 구조였습니다. 기능이 제품에 어떻게 녹아드는지, 사용자가 어떤 맥락에서 결과를 보는지는 PM의 영역이라고 생각했고요.

지금은 완전히 다릅니다. 문제 정의 단계부터 참여합니다. "계약서 요약 기능을 만든다"가 아니라 "핵심 조항 5개를 추출하되, Confidence 0.85 이상일 때만 자동 표시하고 미달 시 사람 검토 큐로 보낸다"처럼 검증 가능한 Success Criteria를 직접 설계합니다. 정확도뿐 아니라 사용자 의사결정 시간 단축률, 위험 탐지율까지 함께 측정하고요.

개발 방식도 달라졌습니다. AI 코딩 어시스턴트로 구현 속도가 빨라진 만큼, 확보된 시간을 프롬프트 전략 설계, Evaluation Dataset 구축, 실패 패턴 분석에 투자할 수 있게 됐습니다. 한마디로, "모델을 만드는 사람"에서 "AI가 제품 안에서 제대로 동작하도록 끝까지 책임지는 사람"으로 바뀐 것이 가장 큰 변화입니다.

AI 활용의 큰 방향에 대해 ‘사람은 기준 설정과 의사결정에 집중하고, AI 에이전트가 실제 구현을 담당한다는 역할 분담’에 대해서는 팀 전체가 자연스럽게 합의했습니다. 이 프레임 자체를 놓고 갈등이 생긴 적은 없어요.

다만 "어떤 서비스를 어떻게 만들 것인가"에 대해서는 항상 여러가지 의견이 있고, 논의가 필요합니다. 특정 AI 기능의 스코프를 어디까지 잡을지, 어떤 접근 방식으로 풀지, 우선순위를 어디에 둘지, 엔지니어는 기술적 실현 가능성을 중심으로, PM은 고객 임팩트를 중심으로 보다 보니 의견이 갈리는 건 당연한 일입니다.

저는 이 과정이 오히려 건강하다고 생각합니다. 서로 다른 관점이 교환되면서 한 사람의 시야로는 보지 못했던 부분이 드러나거든요. 중요한 건 논의 후 합의가 이루어지면, 팀 전체가 그 방향에 각자의 전문성을 전부 쏟는 것입니다. 저희 팀에서는 결정 이후 "나는 원래 다른 의견이었으니까"라며 빠지는 사람이 없습니다. 결과를 만들어낸 다음 회고를 통해 배우는 방식으로 일합니다.

캐비닛의 에이전틱 서치(Agentic Search) 기능을 약 6주 만에 출시한 것이 가장 기억에 남습니다.

사용자가 자연어로 질문하면 AI 에이전트가 계약서를 탐색해 필요한 정보를 스스로 찾아 답변하는 기능인데, 단순 키워드 검색과는 차원이 다른 복잡한 기능이었습니다. "6주 안에 될까?"라는 걱정이 솔직히 있었어요.

가능했던 이유는 두 가지입니다. 첫째, 목표와 스코프가 처음부터 명확했습니다. "어떤 수준까지 만들어서 출시하고, 어떤 부분은 다음 이터레이션으로 넘긴다"는 합의가 팀 전체에서 이루어져 있었기 때문에 중간에 방향이 흔들리지 않았습니다. 둘째, 팀원 간의 협업이 속도를 만들었습니다. PM, PD, 백엔드·프론트엔드 엔지니어, AI 엔지니어가 각자의 파트를 병렬로 진행하면서도 서로의 블로커를 빠르게 풀어주는 방식으로 움직였습니다.

여기에 에이전틱 소프트웨어 개발 방식이 더해지면서 실험→평가→개선 사이클을 짧게 가져갈 수 있었습니다. 빠른 출시는 개인의 역량이 아니라, 명확한 목표 설정과 팀 협업이 맞물린 결과였습니다.

에이전틱 서치 개발 과정에서 Langfuse라는 LLM 모니터링 툴을 함께 도입한 것이 대표적입니다.

사실 Langfuse는 기능 출시에 반드시 필요한 작업은 아니었습니다. 없어도 출시할 수 있었어요. 하지만 Intelligence Lab을 제대로 세팅하려면 AI 기능의 품질을 체계적으로 관리할 수 있는 기반이 필요하다고 판단했고, 개발과 병행해 도입했습니다.

Langfuse를 통해 LLM의 입출력, 프롬프트 버전별 성능, 토큰 사용량, 응답 지연 시간을 종합적으로 모니터링할 수 있게 됐습니다. 이전에는 "이 프롬프트가 잘 되는 것 같다"는 감각에 의존했다면, 도입 이후에는 어떤 프롬프트가 어떤 케이스에서 실패하는지를 데이터로 정확하게 추적할 수 있게 된 거죠.

기대 이상이었던 건, 이 모니터링 체계가 에이전틱 서치를 넘어 이후 개발하는 모든 AI 기능의 품질 관리 기반이 되었다는 점입니다. 당장의 출시에만 집중했다면 놓쳤을 부분인데, 한 발 더 나아간 덕분에 팀 전체의 AI 개발 효율이 구조적으로 올라갔습니다.

역설적이지만, 고객이 적극적으로 개선을 요청할 때 가장 크게 느꼈습니다.

처음에는 문의가 오면 "뭔가 문제가 있나?" 하고 긴장했는데, 내용을 보면 달랐습니다. "이 계약 유형에서는 이런 조항도 뽑아주면 좋겠다", "우리 회사 기준으로 리스크 판별 조건을 커스텀할 수 있나" 같은 요청들이었거든요. 단순 불만이 아니라, 이미 업무 프로세스 안에 우리 서비스를 깊이 넣고 쓰고 있기 때문에 나오는 구체적인 피드백이었습니다.

적극적으로 개선을 요구한다는 건, 그 서비스가 이미 워크플로에 녹아들어 없으면 안 되는 도구가 되었다는 증거입니다. 엔지니어 입장에서도 이런 피드백은 굉장히 값집니다. 우리가 상상한 사용 시나리오와 실제 고객이 쓰는 방식 사이의 간극을 가장 정확하게 보여주거든요. 그 피드백이 Evaluation Dataset의 새로운 케이스가 되고, 다음 프롬프트 개선의 방향이 됩니다.

크게 세 가지 방향이 있습니다.

첫째, AI 계약 리뷰입니다. 계약서 초안을 넣으면 회사 내부 가이드라인과 비교해 리스크 조항을 하이라이트하고 수정 제안까지 해주는 기능입니다. 이미 '모두싸인 리뷰'라는 서비스를 준비하고 있는데, 단순 문법 검수가 아니라 실제 리스크를 사전에 탐지하는 수준까지 가는 게 목표입니다.

둘째, AI 에이전트 기반 계약 운영 자동화입니다. 지금은 사용자가 캐비닛에서 직접 검색하고 확인하는 구조인데, 앞으로는 AI 에이전트가 "다음 주 갱신 예정인 계약 3건이 있습니다. A 계약은 금액 조건 재협상이 필요합니다"처럼 능동적으로 알려주고 행동을 제안하는 방향으로 가고 싶습니다.

셋째, 계약 데이터 기반 비즈니스 인사이트입니다. 수천, 수만 건의 계약 데이터가 쌓이면 산업별 계약 조건 트렌드, 리스크 패턴, 협상력 분석 같은 것들이 가능해집니다. 계약서가 단순한 문서가 아니라 기업의 운영 자산이 되는 거죠. 결국 모두싸인이 전자서명에서 시작해 계약의 전 생애주기를 AI가 운영하는 Full-Intelligent CLM으로 가는 여정에 기여하고 싶습니다.

모두싸인 Intelligence Lab은 AI 기술이 실제 제품이 되는 과정을 처음부터 끝까지 경험할 수 있는 곳입니다.

여기서는 모델 정확도를 올리는 것만이 목표가 아닙니다. "이 AI 기능이 고객의 어떤 문제를 해결하는가", "사용자가 이 결과를 신뢰할 수 있는가", "실패했을 때 어떻게 대응할 것인가"까지 고민합니다. AI Feature를 제품 단위로 정의하고, 실험하고, 개선하는 전체 사이클을 오너십 있게 이끌 수 있습니다.

무엇보다 33만 기업이 실제로 쓰는 서비스 위에서 AI를 만든다는 게 큰 장점입니다. 논문 속 벤치마크가 아니라, 실제 고객의 피드백으로 기술을 검증하는 경험은 쉽게 얻기 어렵습니다. 계약이라는 도메인은 수천 년간 바뀌지 않았는데, 지금 AI로 그걸 바꾸는 시점에 서 있다는 게 개인적으로 가장 흥미로운 부분입니다. 빠르게 실험하고, 실패에서 배우고, AI로 사람들의 업무 방식을 바꾸는 일에 관심이 있다면 함께하면 좋겠습니다.

전자계약으로 시작한 모두싸인의 혁신은 이제 AI 기반 CLM 플랫폼으로 확장되고 있습니다. Adam의 이야기에서 인상적이었던 건, 기술을 만드는 것을 넘어 고객의 문제를 끝까지 책임지는 태도였습니다. Intelligence Lab이 만들어갈 다음 AI 기능들이 계약이라는 도메인을 어떻게 바꿔갈지 기대됩니다.