혼자서 웹툰도 만들고, 영상도 제작하고, 블로그도 운영하다 보면 한 가지 고민이 생긴다. AI 도구는 점점 많아지는데, 정작 작업을 처리하는 내 손은 여전히 바쁘다는 것이다.

웹툰 하나를 만들더라도 먼저 기획을 하고 대본을 작성해야 한다. 그다음 이미지를 만들고, 캐릭터가 달라지지 않았는지 확인하고, 말풍선에 들어갈 글자를 정리해야 한다.

영상으로 만들고 싶다면 다시 콘티를 준비하고 생성 도구를 실행해야 한다. 블로그 글은 본문을 쓰는 것으로 끝나지 않는다. 이미지와 검색 최적화, 워드프레스 편집까지 신경 써야 한다. 여기에 주식시장 분석이나 새로운 프로젝트 기획까지 추가하면 해야 할 일이 끝없이 늘어난다.

ChatGPT, Claude, Gemini처럼 도움을 받을 수 있는 AI는 많다. 그런데 각각의 AI가 만들어 준 결과물을 다른 도구로 옮기는 일은 결국 사람이 해야 하는 경우가 많았다. 어느 순간부터 이런 생각이 들었다.

‘AI를 여러 개 사용하는 것과 실제로 업무를 자동화하는 것은 다른 일 아닐까?’

내가 일일이 AI 도구를 옮겨 다니는 대신, 하나의 지시를 내리면 각자 맡은 일을 처리하는 가상의 회사가 있으면 어떨까? 그 생각에서 출발한 프로젝트가 WEEDSTOON OFFICE다.

이번 프로젝트의 전체 구축 작업은 Google Antigravity를 이용해 진행했다. 내가 원하는 기능과 작업 방식을 정하고, Antigravity를 통해 실제 코드와 화면으로 구현한 뒤 다시 테스트하고 수정하는 방식이었다. Antigravity는 구축에 사용한 개발 환경이며, 완성된 WEEDSTOON OFFICE 자체가 Antigravity에서 실행된다는 뜻은 아니다.

처음에는 직원 열 명으로 시작했지만, 이후 코드 검토와 개인 비서 역할을 추가해 열두 명으로 확장했다. 이번 글부터 WEEDSTOON OFFICE의 1차 개발 과정을 다섯 편에 나누어 기록해 보려고 한다.

처음부터 3D 사무실을 만들 생각은 아니었다

처음 구상은 조금 더 복잡했다. 여러 AI가 일을 나눠 처리하려면 각자 실행되는 프로그램과 업무를 관리하는 서버가 필요하다고 생각했다.

그래서 Docker 컨테이너를 여러 개 사용하고, PostgreSQL과 Redis로 데이터를 관리하며, n8n으로 업무 흐름을 연결하는 구성도 검토했다. 각각 잘 알려진 기술이고 실제로 유용한 도구다.

하지만 내가 만들고 싶은 것이 무엇인지 다시 생각해 보니 문제가 있었다. WEEDSTOON OFFICE는 수백 명의 직원이 접속하는 기업용 업무 시스템이 아니었다. 집에서 혼자 사용하는 PC 한 대를 중심으로 웹툰과 영상, 블로그, 리서치 업무를 처리하기 위한 개인 작업실이었다.

시스템을 관리하는 데 컴퓨터 자원을 많이 사용하면 정작 중요한 AI 이미지·영상 제작에 사용할 자원이 줄어들 수 있었다. 그때 사용하던 PC 환경은 다음과 같았다.

• 운영체제: Windows 11
• GPU: NVIDIA GeForce RTX 5070
• GPU 메모리: 12GB
• 시스템 RAM: 32GB

일반적인 데스크톱 환경에서도 실제로 운영할 수 있는 시스템을 만드는 것이 중요했다. 그래서 복잡한 서버 구성 대신 필요한 기능만 남기는 방향으로 설계를 바꿨다.

무거운 서버 대신 가벼운 구조를 선택했다

최종적으로 선택한 주요 기술은 FastAPI, SQLite, JSON 기반 작업 원장, Three.js였다. 처음에는 이름만 들어도 낯선 기술들이었다. 하지만 각각의 역할을 나누어 생각하니 구조가 조금씩 단순해졌다.

FastAPI는 Python으로 만든 프로그램들이 서로 요청과 결과를 주고받을 수 있도록 해 주는 서버 역할을 맡았다. SQLite는 업무와 프로젝트 관련 데이터를 저장하는 데 사용했다. central_task_ledger.json은 현재 진행 중인 업무와 상태를 추적하는 작업 원장으로 설계했다. 그리고 Three.js는 직원들이 일하는 모습을 보여줄 가상 사무실 화면을 만드는 데 사용했다.

• FastAPI: 업무 요청 접수와 처리
• SQLite: 프로젝트 및 업무 정보 저장
• JSON 작업 원장: 작업 상태와 진행 정보 관리
• AI 직원 모듈: 각 업무의 실행과 결과 처리
• Three.js: 3D 사무실과 업무 상태 표시

여기서 중요하게 생각한 것은 시스템 자체가 AI 모델처럼 무거워지지 않도록 하는 것이었다. 웹툰을 그릴 때는 이미지 생성 모델을 실행하고, 영상을 만들 때는 영상 생성 모델을 실행해야 했다. 그런데 이를 관리하는 사무실 서버까지 지나치게 많은 메모리를 사용한다면 비효율적이라고 생각했다.

그래서 서버는 가볍게 유지하고, 실제 AI 생성 작업에 컴퓨터 자원을 집중하도록 설계했다. 다만 개발 원고에 적힌 서버 유휴 메모리 수치는 별도의 측정 환경과 범위를 확인하지 못했으므로 여기서는 확정하지 않는다.

물론 가벼운 서버를 만든다고 해서 모든 문제가 해결되는 것은 아니었다. GPU 메모리가 부족해지거나 서로 다른 AI 모델이 자원을 차지하는 문제는 이후 개발 과정에서 따로 해결해야 했다. 이 내용은 다음 편에서 자세히 소개하려 한다.

첫 번째 직원 10명에게 이름과 직책을 주었다

서버 구조를 정한 다음에는 어떤 업무를 맡길지 고민했다. 여기서 WEEDSTOON OFFICE의 가장 중요한 특징이 만들어졌다. 기능마다 이름과 직책을 가진 AI 직원을 배치하는 것이었다.

단순히 AI를 열 개 연결하는 방식은 아니었다. 업무를 접수하는 직원, 기획하는 직원, 대본을 쓰는 직원, 그림을 그리는 직원과 결과를 검수하는 직원을 구분하고 싶었다. 처음에는 열 명으로 시작했다.

초기 직원 구성

• 최현우 · AI 운영총괄: 자연어 업무 접수와 직원별 작업 배정
• 강진아 · QC 팀장: 대본·이미지·영상 결과물 품질 검토
• 정상만 · 기획부장: 아이디어 기획과 리서치, 전략 분석
• 신아디 · 세계관 디자이너: 캐릭터·배경·세계관 설정
• 한소설 · 수석각본가: 스토리와 대본, 장면별 콘티 작성
• 오창세 · 블로그·웹소설 작가: 블로그 원고와 콘텐츠 집필
• 정드레 · 작화 디렉터: ComfyUI 기반 웹툰 원화 제작
• 이기안 · 웹툰 감독: 말풍선 식자와 웹툰 편집
• 김지운 · 영상 감독: 이미지 기반 AI 영상 제작
• 구라모 · 사운드 감독: 음성·효과음·최종 영상 마스터링

이렇게 이름과 역할을 나누자 업무를 설명하기가 훨씬 편해졌다. 예를 들어 내가 ‘주식시장을 풍자하는 네컷만화를 만들어 줘’라고 지시하면, 먼저 최현우가 요청을 접수한다. 이후 정상만이 아이디어를 정리하고, 한소설이 네컷에 맞는 대본을 작성한다. 정드레가 그림을 만들고 이기안이 말풍선과 대사를 넣으면 웹툰 결과물이 만들어지는 구조다. 중간에는 강진아가 각 단계의 결과를 확인하도록 설계했다.

처음에는 이런 역할 분담만 잘 만들어 놓으면 직원들이 자연스럽게 협업할 것이라고 생각했다. 하지만 실제 개발에서는 그렇지 않았다. 업무가 잘못 전달되거나, 다른 프로젝트의 캐릭터가 섞이거나, 요청하지 않은 작업까지 실행되는 문제가 나타났다.

직원에게 이름과 역할을 부여하는 것보다 더 중요한 것은 그 직원이 어떤 조건에서 일을 시작하고 어디까지 작업해야 하는지 명확하게 정하는 것이었다. 그 문제들은 이후 개발하면서 하나씩 수정했다.

열 명의 AI 직원이 모두 다른 AI 모델일까?

여기서 한 가지는 구분할 필요가 있다. WEEDSTOON OFFICE에 AI 직원 열 명이 있다고 해서 열 개의 대형 AI 모델이 각각 독립적으로 실행되는 것은 아니다. 직원은 업무를 담당하는 프로그램 모듈과 AI 모델, 작업 규칙을 묶어서 표현한 개념이다.

서로 다른 직원이 같은 언어모델을 사용하더라도, 맡은 역할과 전달받는 지시문이 다르면 다른 업무를 수행하도록 설계할 수 있다. 예를 들어 운영총괄과 기획부장은 같은 계열의 언어모델을 사용하더라도 하는 일이 다르다. 운영총괄은 사용자의 요청을 분류하고, 기획부장은 실제 기획안을 만든다.

작화 디렉터는 언어모델만으로 그림을 만드는 것이 아니라 ComfyUI와 연결해 이미지 생성 작업을 담당한다. 웹툰 감독은 생성된 이미지에 한국어 대사를 넣기 위해 별도의 이미지 편집 코드를 사용한다. 이렇게 업무별로 필요한 도구가 달랐다.

그 때문에 AI 직원을 많이 만드는 것보다 각 직원이 어떤 도구에 접근할 수 있고 어떤 결과를 만들어야 하는지 정하는 일이 중요했다.

업무 상태를 보여주는 3D 사무실도 만들었다

처음에는 AI 직원들의 작업을 텍스트로만 표시해도 충분하다고 생각했다. 예를 들어 ‘기획 중’, ‘이미지 생성 중’, ‘검수 대기’ 같은 상태만 보여주는 방식이다. 하지만 직원과 업무가 늘어나면 여러 로그를 읽어야 현재 어떤 일이 진행되고 있는지 알 수 있었다.

그래서 조금 다른 방법을 생각했다. 직원들이 책상에 앉아 일하는 사무실을 화면에 만들어 보는 것이었다. 이때 사용한 기술이 Three.js다.

Three.js는 웹브라우저에서 3D 공간을 표현할 수 있는 도구다. 이 기술을 이용해 책상과 직원 캐릭터를 배치하고, 업무 상태에 따라 직원의 모습이나 상태 표시가 바뀌도록 만들었다. 내가 지시한 일이 어느 직원에게 전달됐는지, 지금 어떤 작업이 진행되고 있는지 3D 사무실에서 확인할 수 있도록 구성했다.

여기서 직원 캐릭터가 움직인다고 해서 AI가 실제 사람처럼 독립적인 판단을 하고 있다는 뜻은 아니다. 직원이 맡은 작업 상태를 사람이 쉽게 알아볼 수 있도록 표현한 화면이다. 실제 성공 여부는 업무 기록과 결과물도 함께 확인해야 한다.

그래도 직접 실행 화면을 보니 단순한 업무 자동화 프로그램과는 느낌이 달랐다. 텍스트로만 보던 작업들이 눈에 보이는 사무실 안에서 진행되는 것처럼 표현되기 시작했다. 내가 원했던 ‘혼자 일하지만 여러 직원과 함께 작업하는 사무실’의 형태가 조금씩 갖춰지는 느낌이었다.

Google Antigravity로 개발하면서 느낀 점

이번 프로젝트를 진행하면서 Google Antigravity의 장점도 확인할 수 있었다. 가장 인상적이었던 것은 능동적으로 작업을 진행한다는 점이었다. 내가 원하는 기능을 설명하면 실제 코드와 화면을 구현하는 단계까지 빠르게 이어졌다.

가상 직원의 역할을 정하고 서버 구조를 바꾸거나 3D 사무실 화면을 수정하는 과정에서도 이런 실행 방식이 도움이 됐다. 혼자 개발하는 입장에서는 아이디어를 실제 프로그램으로 만들어 확인하는 데 걸리는 시간을 줄일 수 있다는 점이 큰 장점이었다.

하지만 기능 하나를 빠르게 구현하는 것과 프로그램 전체가 안정적으로 작동하는 것은 달랐다. 새로운 기능을 추가하면서 기존 기능에 영향을 주거나, 업무 흐름이 원래 의도와 다르게 실행되는 문제가 발생할 수 있었다. 결국 실제 화면과 결과를 확인하고, 문제가 생기면 원인을 찾아 다시 수정하는 과정이 필요했다.

이번 프로젝트에서 느낀 것은 Antigravity가 개발을 상당히 능동적으로 진행하는 도구라는 점이었다. 다만 그 능동적인 실행을 어디까지 허용하고 어떤 단계에서 검수할 것인지는 개발자가 정해야 했다. 이런 경험은 앞으로 다른 AI 개발 도구를 사용해 비교할 때도 중요한 기준이 될 것 같다.

10명으로 시작한 사무실이 12명으로 늘어나기까지

처음부터 직원 열두 명을 계획했던 것은 아니었다. 콘텐츠를 기획하고 웹툰과 영상을 만드는 역할을 중심으로 열 명을 설계했다. 하지만 프로그램이 복잡해지면서 코드와 시스템의 문제를 점검할 기술이사와 이메일·일정 같은 개인 업무를 관리할 비서가 필요해졌다.

그래서 이후에는 강코덱 CTO와 최고야 대표 직속 비서를 추가해 열두 명으로 확장했다. 다만 이 두 직원의 실제 구현과 연동 과정은 이번 첫 편에서 자세히 설명하지 않으려고 한다. 그 과정에서도 여러 시행착오가 있었기 때문이다.

이번 1편은 WEEDSTOON OFFICE를 왜 만들었고, 어떤 구조로 시작했는지를 소개하는 글이다.

다음에는 실제로 일을 시켜 봐야 했다

여기까지 만들고 나니 3D 사무실과 직원들의 역할은 어느 정도 형태를 갖추었다. 하지만 보기 좋은 사무실을 만드는 것이 최종 목표는 아니었다. AI 직원들에게 실제로 웹툰을 그리게 하고, 영상을 만들고, 블로그 원고를 작성하게 해야 했다.

그 과정에서 또 다른 문제가 기다리고 있었다. 내 PC에 장착된 GPU는 RTX 5070 12GB 한 장이었다. 그런데 언어모델과 이미지 생성 모델, 영상 생성 모델은 모두 상당한 컴퓨터 자원을 사용했다. 직원은 여러 명인데 GPU 작업실은 하나뿐인 상황이었다.

다음 편에서는 이 문제를 해결하기 위해 AI 모델들을 교대로 실행하고 GPU 메모리를 관리하도록 만든 과정을 다룰 생각이다.

관련 글: Google Antigravity로 시작한 첫 H5 게임 《매스워》