# 오프모임 후기 : AI는 기능이 아니라 운영 시스템이다

- 작성자: [한밤의 화가](https://community.clauders.ai/member/imported-member-lIPVkAMPEO)
- 공간: [바이브 코딩](https://community.clauders.ai/claude-code)
- 게시: 2026-03-22
- 연재: [주 1회 AI 프로젝트 빌드](https://community.clauders.ai/series/weekly-ai-build-projects) 1/4편
- 태그: #주1회빌드 #OT과제
- 주소: https://community.clauders.ai/claude-code/post/%EC%98%A4%ED%94%84%EB%AA%A8%EC%9E%84-%ED%9B%84%EA%B8%B0-ai%EB%8A%94-%EA%B8%B0%EB%8A%A5%EC%9D%B4-%EC%95%84%EB%8B%88%EB%9D%BC-%EC%9A%B4%EC%98%81-%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9D%B4%EB%8B%A4-8d513926-b07e-8869-8988-8c804e4641c1

---

## 소개

오프라인 모임에 가기 전, 저는 이미 하나의 문제를 계속 느끼고 있었습니다.

- AI가 편해질수록, **사람과 협업하는 일이 오히려 비용처럼 느껴졌습니다**
- 커뮤니케이션이 늘어날수록 속도는 느려지고, 병목이 생겼습니다
- 결국 중요한 일은 **제가 혼자 처리하게 되는 구조**가 반복되었습니다

리더 입장에서 이건 꽤 복잡한 감정이었습니다.

- 협업을 장려해야 하는데, 효율은 혼자가 더 좋습니다
- 조직을 융화시켜야 하는데, 속도는 분산될수록 떨어집니다

그래서 이런 생각까지 하게 되었습니다.

> "차라리 제가 하나의 조직처럼 일하는 게 맞는 걸까요?"

이 질문을 들고 모임에 참여했고,  
결과적으로는 **답이 아니라 방향을 바꾸는 계기**가 되었습니다.

## 진행 방법

이 모임은 단순한 정보 공유 자리가 아니었습니다.  
이미 **AX(AI Transformation)를 실제 조직에 적용하고 있는 사례**를 직접 들을 수 있는 자리였습니다.

그리고 그중에서도 가장 인상 깊었던 것은,  
👉 "AI를 어떻게 쓰느냐"가 아니라  
👉 **"AI로 조직을 어떻게 운영하느냐"**였습니다.

### 스터디장 황인준님이 공유해주신 Bkit 팝업스튜디오 사례

❗ 기존에 제가 갖고 있던 전제

- Slack을 잘 쓰는 조직 = 생산성이 높은 조직이라고 생각했습니다
- 커뮤니케이션을 늘리면 협업이 좋아진다고 믿었습니다

❗ 그런데 완전히 반대였습니다

- Slack을 **가급적 사용하지 않았습니다**
- 회의도 **최소화하고 있었습니다**

👉 이 부분이 가장 충격적이었습니다.

몇 년 전까지만 해도

> "슬랙을 어떻게 쓰느냐가 조직 생산성을 결정한다" 라는 말이 당연했기 때문입니다.

그런데 이 조직은 완전히 다른 선택을 하고 있었습니다.

선택의 이유

👉 **커뮤니케이션 비용이 가장 비싸기 때문이었습니다**

- 사람이 설명하고
- 사람이 이해하고
- 사람이 정리하고
- 사람이 다시 전달하는 구조

이 모든 것이 병목이었습니다.

그래서 내린 결론

👉 "사람 간 커뮤니케이션을 줄이고, 시스템으로 대체합니다"

실제 자동화 구조

- Google Meet → 회의 진행
- AI → 회의 내용 자동 기록
- Claude Code + MCP → 데이터 연결
- Jira → 액션 아이템 자동 생성
- Confluence → 진행 상황 누적

실제 흐름

1. 회의 진행 (Google Meet)
2. AI가 회의 내용 기록
3. 액션 아이템 자동 추출
4. Jira 티켓 자동 발행
5. 개발자는 Jira에 직접 들어가지 않습니다

   - "제가 할 일 무엇입니까?" → Claude Code에 질문합니다
6. AI가 진행 상황을 추적합니다
7. 다음 회의 전

   - "회의 자료를 만들어 주십시오" → 자동 생성됩니다

여기서 얻은 해석

이것은 단순한 효율의 문제가 아니었습니다.

- 협업을 줄인 것이 아니라
- **협업의 방식 자체를 바꾼 것**이었습니다

👉 사람 ↔ 사람이 아니라  
👉 사람 ↔ 시스템 구조로 전환된 것입니다

### 2️⃣ OpenClaw 개인 비서 사례 (뽀짝이)

이 사례는 듣고 나서 바로 실행해보고 싶다는 생각이 들었습니다.

상황

- 400명 규모 스터디 운영
- 운영자 2명

👉 기존 방식으로는 감당이 어려운 구조였습니다

해결 방법

👉 AI Agent(뽀짝이)를 도입했습니다

수행 기능

- 설문 자동 수집 및 Airtable 정리
- Slack/게시판 요약 및 응답
- 참여자 추적
- 문자 발송 자동화
- 쿠폰 발급
- 멤버십 연장 처리
- 스터디 운영 보조

👉 핵심 포인트

- "지시해야 하는 자동화"가 아니라
- **"스스로 수행하는 에이전트"**입니다

인상 깊었던 점

- 코딩보다 **업무 매뉴얼 설계에 가까웠습니다**
- Agent 구성

  - Soul.md
  - Memory.md
  - Tools.md

👉 즉,

> "AI를 사용하는 것이 아니라, AI가 일하는 구조를 설계하는 것입니다"

### 3️⃣ 제품 개발 방식 변화 (Pencil.dev 사례)

또 하나 크게 느낀 변화는 개발 방식이었습니다.

과거:

- 아이디어 → 바로 개발

현재:

- 아이디어 → 검증 → 프로토타입 → 개발

실제 프로세스

- Claude Code로 코드베이스 분석
- 통합 기획 자동 생성
- 유저 플로우 도출
- Pencil.dev로 와이어프레임 생성 (17개 화면)

인상 깊었던 점

- 디자이너 없이 진행되었습니다
- 기획, 디자인, 개발의 경계가 사라졌습니다
- 팀 간 커뮤니케이션 비용이 크게 줄었습니다

👉 결론

> "이제 만드는 것은 문제가 아닙니다"

## 결과와 배운 점

이번 모임에서 얻은 것은 단순한 기술이 아니라, **관점의 전환**이었습니다.

### 🔥 핵심 인사이트

> AI는 기능이 아니라 운영 시스템입니다

> 커뮤니케이션 비용을 줄이는 것이 AX의 핵심입니다

### 💡 주요 깨달음

1. **만드는 것은 매우 쉬워졌습니다**  
   → 이제 중요한 것은 "무엇을 만들 것인가"입니다
2. AI는 도구가 아니라 **운영의 중심입니다**  
   → 기능이 아니라 흐름 단위로 바라봐야 합니다
3. 반드시 지켜야 할 프로세스

```
문제 정의 → mock-up → 검증 → 개발
```

👉 이 프로세스는 바이브코딩 시대에도 변하지 않습니다

### 🧠 개인 실행 계획

- OpenClaw 기반 개인 비서 구현
- Pencil.dev를 활용한 빠른 프로토타이핑
- 아래 실행 루틴 유지

실행 루틴

- 개발 전 → 검증
- 개발 중 → AI 적극 활용
- 개발 후 → 리뷰 (CEO / ENG)

## 한 줄 정리 🚀

- AI를 기능으로 활용하면 → 생산성이 향상됩니다
- AI를 운영으로 활용하면 → **사업이 됩니다**

## (개인 코멘트)

이 경험은 단순한 인사이트를 넘는 것이었습니다.

👉 **사업 방향을 바꿀 수 있는 수준의 통찰이었습니다**

따라서 결론은 명확합니다.

> 이제는 더 배우는 것이 아니라, 만들어야 할 시점입니다