F-Lab의 전사 AI 에이전트 체계, OpenClaw 도입기

안녕하세요. F-Lab에서 사내 AI 에이전트를 설계하고 운영하고 있는 Kail입니다.

최근 많은 회사에서 ChatGPT나 Claude를 쓰고 있습니다. 하지만 대부분 "질문하고 답변 받는" 수준에서 멈춥니다. 개발자들은 Claude Code를 쓰고, 비개발자들은 ChatGPT에 이것저것 물어보고. 요즘은 Claude Code를 비개발자 분들도 쓰는 분위기로 발전하고 있는 것 같습니다만, 여전히 서로의 질문 대상은 분리되어 있습니다.

저희도 처음엔 그랬습니다. 그런데 한 가지가 계속 걸렸습니다.

“이 수치 어디 있나요?”

“이렇게 조치하셨던 게 맞나요?”

”이거 누구한테 물어봐요?”

매일 반복되는 이 대화들. 이것도 비용이었습니다.

이 글에서는 F-Lab이 이 문제를 풀기 위해 전사 AI 에이전트 체계 OpenClaw를 도입하고, 운영하면서 정리한 구조, 프로세스, 가드레일에 대해 공유합니다.

AI 에이전트, 왜 따로 만들었나

요즘 Claude Code, Cursor 같은 도구들이 지속적으로 발전하고 있습니다. MCP 연동도, 스킬도 굉장히 많이 공유됩니다. 개발자 입장에서는 개인 도구로 충분합니다.

그런데 조직에서의 문제는 달랐습니다.

Claude Code는 내 로컬 코드만 봅니다. 내 대화만 압니다. 하지만 조직에서는 여러 명이 동시에 같은 데이터를 보고, 같은 맥락을 공유해야 합니다. 과거의 내용도 찾아서 확인해야 하고, 문자도 보내야 하고, CS도 처리해야 하고, 급여도 정산해야 합니다.

개인 도구로는 이걸 풀 수 없었습니다. 맥락이 개인으로 한정됩니다.

하지만 OpenClaw를 도입하는 시점부터는 달라집니다. 맥락이 조직으로 확장됩니다.

핵심은 "동시에 맥락을 공유한다"는 것입니다.

컨텍스트가 오직 PC 안에서, 메모리에서만 공유되는 것이 아니라 네트워크와 원격으로 확장됩니다.

누군가에게 물어볼 필요 없이, 슬랙에서 에이전트에게 물어보면 끝입니다. 과거의 슬랙 내용? 상관없습니다. 읽고 히스토리까지 확인합니다. 조직 전체가 해당 스레드를 공유하고 있다면 전부 같은 답을 봅니다. 물론, 이 모든 게 지하철에서도 휴대 전화로 가능해지죠.

그래서 별도의 멀티 에이전트 체계를 구축하기로 했고, 하나의 철학을 세웠습니다.

”열되 조인다.”

컨텍스트는 확장하되, 확장할 때마다 가드레일을 같이 친다.

이게 제가 세운 F-Lab 안에서 OpenClaw의 설계 원칙입니다.

OpenClaw 구조

OpenClaw는 F-Lab 전 직원이 슬랙에서 사용하는 AI 에이전트 체계입니다. DM이나 채널에서 자유롭게 대화할 수 있고, DB 조회, 문자 발송, CS 보조, 코드 구현까지 수행합니다.

현재 F-Lab에서 운영 중인 에이전트는 6마리입니다. 회사 내에 있는 PC로 돌아가고 있습니다.

하나의 만능 에이전트가 아니라, 역할별로 분리된 체계입니다. 에이전트마다 성격과 담당 영역이 명확하게 나뉘어 있습니다.

예를 들어 Flame은 기존 운영 서버 다운 시 다른 에이전트가 장애가 나는 경우에만 ECS 태스크로 임시 투입되는 응급 에이전트인데, 자기가 아주 든든하다고 생각하고 있습니다.

Labi는 CS를 전반적으로 다뤄 주는 담당자입니다. 사내에서 운영 매니저를 담당하고 있는 Eddie를 닮아 차분하고 친절합니다. (동생이거든요)

Kian은 서브 에이전트들을 총괄해주는 개발 팀장입니다. 업무를 파악하고 서브 에이전트에게 분배합니다. 기본적으로 다정하지만 소스 코드 품질 관리에 있어서는 단호합니다.

Tail은 전략 기획 담당을 합니다. 사내 분석이 필요한 자료들을 통합하고, 마케팅 전략 작업 등을 계획하는 역할을 합니다. 제법 깐깐하게 지표를 보고 판단한 뒤 할 일을 정돈해 넘겨줍니다. 

Koki는 재무 담당이고 꿀을 좋아합니다. Koki에게 돈은 꿀을 살 수 있는 수단입니다. 코키는 "I LOVE HONEY!" 하면서 신나게 정산을 돌립니다.

성격을 부여한 이유가 있습니다. 에이전트가 단순한 도구가 아니라 조직의 동료처럼 느껴져야 자연스럽게 쓰기 때문입니다.

에이전트가 맡고 있는 작업들

그래서 실제로 뭘 하고 있을까요? 현재 에이전들이 맡고 있는 작업을 하나씩 보겠습니다.

멘토링 데일리 분석

F-Lab은 개발자 멘토링 플랫폼입니다. 매일 수십 건의 멘토링 세션이 돌아갑니다. 이걸 사람이 매일 전수조사하는 건 어렵고, 가능하더라도 품질과 효율이 떨어집니다. 

Tail이 등장하고 이 분석이 고도화되었습니다. 매일 멘토링 세션 데이터를 자동으로 분석합니다. 그리고 기술/시장 트렌드 리포트와 멘토링 관리 리포트를 자동 생성합니다.

녹화되는 멘토링 음성을 분석해서, 자주 언급된 기술 키워드를 뽑아내고, 멘토와 멘티의 대화 패턴을 파악합니다. 

저희는 멘토링이 잘 이뤄지고 있는지 / 주로 어떤 내용들을 트렌드로 이야기하고 계신지 한눈에 확인합니다. 그리고 이 데이터들을 토대로 멘토링에 대한 컨텐츠 또한 빌드업합니다.

추가 컨텐츠를 생성해야 할지, 멘토님의 멘토링이 실질적으로 도움이 되는지에 대한 정보를 판단하고 해당 업무 담당자가 해야 할 액션까지 제안합니다.

이제 조직원은 이 리포트만 확인하면 됩니다. 제안된 실행안을 그대로 실행하면 됩니다. 매일매일 하나씩 들여다볼 필요도, 할 일을 매일 구상할 필요도 덜해졌습니다.

자연어 1줄로 배포까지

Kian은 개발 총괄 에이전트입니다. 자연어 한 줄을 던지면 PR, 배포까지 올라옵니다.

워크플로우가 정의되어 있기 때문에 가능합니다

아무 AI 에이전트한테 "이거 만들어줘"라고 하면 되는 게 아닙니다. Kian이 퀄리티 있는 결과를 내는 이유는, 8단계 워크플로우가 미리 정의되어 있기 때문입니다.

몇 가지 포인트가 있습니다.

Jira 없이 시작하지 않습니다. 작은 문구 수정도 예외 없이 이 흐름을 탑니다. 새 티켓이 없으면 키안이 먼저 만듭니다. Slack 대화 내용을 조회하고 티켓의 포맷까지 완벽하게 맞춥니다. 이렇게 하는 이유는, 나중에 "이거 왜 바꿨지?"라는 질문에 항상 답할 수 있어야 하기 때문입니다.

검증 순서가 고정입니다. lint → test → build/typecheck. 이 순서를 안 돌리면 "검증 완료"라고 말하지 않습니다. 순서를 건너뛰면 빌드는 됐는데 린트에서 걸리는 것 같은 상황이 생깁니다. 그래서 순서를 강제했습니다.

최종 보고는 사람에게 합니다. 에이전트가 다 하고 끝이 아닙니다. 범위, 담당, 리스크, 검증 결과를 정리해서 사람한테 보고합니다. 필요하면 배포 후 CI 상태까지 확인합니다.

실제로 어떻게 돌아가나

간단한 절차입니다. 슬랙에서 한 줄을 던집니다.

"[CRM] 멤버 통합 컨텍스트 데이터셋 및 조회 GUI 구축"

그 이후 키안이 확인하고, 기능을 정리하고, 설계를 나누고, Jira 티켓을 만들고, 브랜치를 따고, 구현하고, lint/build를 돌리고, PR을 만들고, 결과를 보고합니다.

이 기능을 구현하기 위한 작업을 쪼개고 전부 서브 에이전트에게 이관한 뒤, 완료되면 저에게 보고합니다.

서브에이전트는 역할을 나눠서 담당합니다. 자신의 역할이 정확하게 skill로 정의되어 있고, identity로 정의되어 있습니다. 기존 소스코드 구조를 훼손하지 않습니다.

전체 워크플로우가 한마디로 시작됩니다. 비개발자도 이 흐름에 가볍게 참여할 수 있습니다.

당연히 사람의 검증은 거칩니다. 검증 시 이슈가 생길 수 있습니다. 다만 그 검증을 향한 과정이 단순화되고, 접근이 쉽고 빨라집니다.

이게 조직에게 주는 것

요즘 클로드 코드 연동이 늘어나면서 FE와 BE를 동일한 레포로 두는 분들이 많아진 것으로 압니다. 하지만 저희는 기존 레포를 수정하지 않아도 대화 자체가 연결고리 역할을 해 주고 있습니다. 프론트-백엔드 연동성을 대화로 메꿉니다.

소스코드에 처음 접근하는 개발자들도 코드 구성만 보면 바로 작업이 가능합니다. PR을 봄으로써 온보딩이 코딩으로 가능해집니다.

개발자가 아니라도 개발 작업에 접근할 수 있습니다. 심지어 CLI를 쓸 줄 몰라도, 자신의 PC에 세팅을 할 줄 몰라도 동일한 작업에 접근할 수 있습니다. 만들어진 작업들은 이미 하네스를 거쳤습니다. 비개발자의 작업을 개발자는 PR으로 즉시 컨펌할 수 있습니다.

내가 직접 개발하지 않아도, 도메인 이해가 낮은 개발자도, 심지어 개발자가 아닌 사람도 바로 붙을 수 있습니다.

물론 당연히 검증은 필요합니다. 하지만, 검증에 들기 전까지 많은 작업들을 미리 보완함으로써 업무에 대한 허들이 상당히 줄어듭니다.

그 컨텍스트 공유가 슬랙에서 이뤄집니다. 커뮤니케이션 비용은 0에 수렴합니다.

확장의 과정

이 작업들을 한번에 세워 둔 것은 아닙니다. 하나하나씩, 단계적으로 넓혀왔습니다.

기존에 RAG 기반 챗봇을 사용하고 있었고, 이것이 OpenClaw 체계로 멀티 에이전트 형태가 되었기 때문에 더더욱 그렇습니다.

슬랙 챗봇          → 주요 대화만 가능
  + DB 연동        → 즉시 데이터 조회
    + 문자 발송     → 외부 액션 수행
      + CS/추천/정산 → 실제 비즈니스 활용

다만 에이전트가 단순 응답을 넘어 스스로 판단하고 외부 액션까지 수행하게 되면서 염려되는 것이 있었습니다.

바로 보안 / 데이터 손실 / 잘못된 요청입니다.

이를 위해 한 칸을 옮길 때마다, 가드레일도 같이 올라갔습니다.

가드레일

에이전트에게 많은 걸 열어줄수록, 사고가 날 확률도 올라갑니다.

문자를 잘못 보내면? 고객 데이터를 잘못 건드리면? 한 번 잘못 나가면 돌이킬 수 없습니다.

특히 F-Lab처럼 사람과 사람 사이의 신뢰가 BM의 핵심인 서비스에서는, 한 번의 오발송이 치명적입니다.

그래서 모든 에이전트 액션을 위험도로 나눴습니다.

← 안전                                    위험 →
┌──────────────┬──────────────┬──────────────┐
│   내부 조회    │  반복/단순 응답  │   외부 발송    │
│ DB · 슬랙 대화 │  비용 해지 영역  │ 문자 · 채널톡  │
└──────────────┴──────────────┴──────────────┘

가장 위험한 지점부터 가드레일을 칩니다.

외부 발송 제한

문자와 채널톡은 사용자에게 직접 나가는 액션입니다. 여기에 세 가지 제한을 걸었습니다.

일일 발송 한도 제한. 하루에 보낼 수 있는 문자 수를 제한했습니다. 에이전트가 루프에 빠져서 같은 문자를 수백 건 보내는 사고를 막기 위해서입니다.

수신자 수 상한선. 한 번에 대량 발송이 불가능합니다.

CS는 AI 전면 응대 X. 사람을 보조하는 방향입니다. 에이전트가 혼자서 고객한테 답장을 보내는 일은 없습니다.

문자 발송 게이트웨이

문자 발송을 자체 서버로 경유시켰습니다. 일일 한도, 수신자 수, 승인 단계를 적용했습니다. 에이전트가 마음대로 문자를 대량으로 쏠 수 없게 막은 겁니다.

실제로 Labi가 문자를 보내다가, 당일 중복 발송 제한에 걸려서 4명만 보내고 나머지는 시스템이 막은 적이 있습니다. 가드레일이 제대로 작동한 순간이었습니다.

DB 조회 자동화

당장 기능에 필요한 주요 데이터를 언제나 API 통신 처리로 조회할 수는 없습니다. 매번 조회한 뒤 대화를 위해 붙여 넣을 수도 없습니다.

따라서 에이전트가 DB에 접근할 수 있도록 열어 두었습니다. 하지만 접근 가능한 테이블과 컬럼을 제한했고, 동시에 read-only 계정을 사용했기 때문에 에이전트가 데이터를 삭제하거나 수정하는 건 완전히 불가능합니다.

AI 전면 응대 X

채널톡 CS 반자동화를 토대로 반복 문의 대응 시간을 단축시켰습니다. 여기서 중요한 건, AI가 전면 응대하지 않는다는 점입니다. 사람을 보조하는 방향입니다.

에이전트는 채널톡에서 조회한 데이터를 가지고 와서 워크플로우로 판단한 뒤 DB와 API에서 필요한 데이터를 조회하고, 나갈 수 있는 답변을 미리 도출해 둡니다. 혼자서 고객한테 답장을 보내는 일은 없습니다.

인프라 보안

위험한 외부 액션(문자 발송, CS 응답 등)은 샌드박스에서 먼저 실행하고, 승인 단계를 거쳐야 실제로 나갑니다.

열되 조인다. 이게 저희의 원칙입니다.

컨텍스트 확장, 그것이 핵심

정리해 보겠습니다.

OpenClaw가 뭔가. F-Lab 전 직원이 슬랙에서 쓰는 AI 에이전트 체계입니다. 6마리가 역할별로 나뉘어 있습니다.

왜 만들었나. 개인 도구로는 조직의 맥락 공유 문제를 풀 수 없었습니다. 컨텍스트를 전체로 확장하고, 동시에 모두가 같은 맥락을 공유하는 게 핵심입니다.

뭘 하나. 멘토링 분석, 문자 발송, DB 조회, CS 보조, 멘토 추천, 급여 정산, 코드 구현까지.

어떻게 개발하나. Kian 에이전트가 8단계 워크플로우로 자연어 한 줄부터 PR까지 처리합니다.

어떻게 안전하게 하나. "열되 조인다." 위험도 기준으로 나누고, 위험한 쪽부터 가드레일을 칩니다.

결국 핵심은 컨텍스트 확장입니다. 

모두의 컨텍스트 범위가 넓어지고, 전환 비용이 줄고, 업무가 빨라집니다.

F-Lab은 계속 실험소로 굴러갑니다.

앞으로의 방향

현재 OpenClaw는 F-Lab 내부에서 운영되고 있지만, 이 구조를 검증하는 과정에서 배운 것들이 많습니다.

도구를 더 깊게 쓰게 만드는 것. 그게 F-Lab이 현재 실험소로서 하는 일입니다.

시리즈 안내

이 글은 OpenClaw 도입기 시리즈의 개요편입니다. 각 주제별로 더 깊은 이야기를 다룰 예정입니다.

1. 에이전트 컨텍스트 확장 편: Labi와 슬랙 챗봇에서 DB·문자·CS까지
2. 개발자 컨텍스트 확장 편: Kian이 돕는 자연어 한 줄로 PR까지
3. 멘토링 분석 자동화: Tail의 하루 모음집

감사합니다.