3년에 걸쳐 쓴 글 일곱 편이 한 화면에 다 들어왔다. 첫 글과 마지막 글의 답이 달랐다.

메모를 오래 썼다. 읽은 것, 들은 것, 생각난 것을 그때그때 적었다. 문제는 다시 안 읽는다는 것이었다. 몇 년치가 쌓였는데 열어보는 건 최근 것뿐이었다.

검색은 아는 것만 찾아준다

처음엔 검색으로 충분하다고 생각했다. 필요할 때 단어로 찾으면 되니까.

그런데 검색은 내가 뭘 찾는지 알아야 쓸 수 있다. 2년 전에 이 주제로 뭔가 적어둔 것 같다는 감이 있어야 검색어를 넣는다. 감이 없으면 그 글은 없는 것과 같다. 그리고 감이 없다. 잊었으니까 다시 만나야 하는 건데, 잊었으니 찾을 수가 없다.

그래서 내가 찾아가는 대신 관련된 게 미리 모여 있게 했다. 큰 주제별로 내가 쓴 글이 모이는 문서를 두었다. 어느 계절에 뭘 쓰고 있었는지 시기별로도 묶었다. 묶는 기준도 하나 더 만들었다. 내 글에 반복해서 나오는 이미지나 표현이다. 서로 다른 주제인데 같은 비유를 쓰는 글들이 있다. 이런 건 주제로 묶으면 안 만난다.

최신이면 엉성해도 본다

여기서 하나를 정했다. 이 문서들을 직접 관리하지 않는다.

직접 하면 두 달이면 낡는다. 새 글이 추가돼도 목록에 안 들어가고, 그러면 목록을 못 믿게 되고, 안 보게 된다. 그래서 일주일에 한 번 전부 다시 만들어지게 했다. 글을 쓰면 다음 주엔 알아서 들어가 있다.

이게 결정적이었다. 조금 엉성해도 최신이면 보고, 완벽해도 낡았으면 안 본다.

맨 앞에 쓴 일곱 편은 이렇게 만들고 나서 한 주제 문서를 열었을 때 본 것이다. 각각 쓸 때는 별개의 생각이었는데 모아 보니 하나의 질문을 계속 다르게 묻고 있었다. 3년 사이에 내 생각이 바뀐 것이다. 나는 그걸 몰랐다.

이제는 메모를 다시 찾으려고 이 문서를 여는 게 아니라 내가 어떻게 바뀌었는지 보려고 연다.

따라 해보기

메모가 쌓여만 있다면, 관심 있는 주제 하나를 정해서 그 주제로 쓴 글을 다 모아 한 문서에 링크로 걸어보면 된다. 한 번만 해보면 왜 이게 필요한지 바로 안다.

시즌(석 달 단위로 여는 모임 기간) 등록이 열리는 날이 제일 조마조마하다. 열여덟 팀, 정원을 합치면 247명. 이게 며칠 안에 채워진다. 문제는 누가 채우느냐다.

등록하는 사람은 두 부류다. 지난 시즌을 마치고 이어서 오는 기존 멤버와 처음 오는 신규 멤버. 우리는 재등록 기간(기존 멤버만 먼저 신청하는 기간)을 먼저 두고 그 다음에 일반 등록을 연다. 기존 멤버를 먼저 챙기는 게 맞다고 봤다.

여기에 함정이 있었다. 인기 팀은 재등록 기간에 다 찬다. 그러면 일반 등록이 열렸을 때 신규 멤버에게 남은 건 인기 없는 팀들이다. 처음 오는 사람이 가장 나쁜 선택지를 받는 구조다. 신규가 줄면 몇 시즌 뒤에 기존 멤버만 남고 그 다음엔 자연 감소만 남는다.

절반만 열고 나중에 푼다

재등록 기간에는 각 팀 정원의 절반만 열기로 했다. 정원이 스물이면 열 명만 받는다. 재등록 마감 시각에 나머지를 일괄로 푼다. 기존 멤버는 여전히 먼저 고르고, 신규에게도 인기 팀 정원이 남는다.

만들면서 신경 쓴 건 복원(줄여 둔 정원을 되돌리는 일) 방식이다. 절반으로 줄였다가 원래 숫자로 되돌리면 안 된다. 그 사이 팔린 만큼이 되살아난다. 정원 20을 10으로 줄이고 8명이 등록해 2가 남았다고 하자. 여기서 남은 2를 지우고 20을 새로 적으면 총 수용이 28이 된다.

그래서 되돌릴 양을 미리 적어두고, 복원할 때 새로 적지 않고 그만큼을 더한다. 남은 2에 10을 더해 12. 팔린 8을 합치면 정확히 20이다.

마감을 내 노트북에 맡기지 않는다

마감 시각을 정확히 닫으려면 그 시각에 뭔가 실행돼야 한다. 처음엔 예약 실행(정한 시각에 내 컴퓨터가 프로그램을 저절로 돌리는 기능)으로 하려 했는데, 노트북이 절전이면 그 시각이 그냥 지나간다. 지나간 예약은 깨어나도 다시 안 돈다.

그래서 마감 시각 자체를 판매 시스템에 미리 걸었다. 판매 종료 시각을 상품에 설정해두면 내 컴퓨터가 켜져 있든 말든 정확히 닫힌다. 그러고 나면 나머지 정원을 푸는 일은 급하지 않아진다. 이미 닫힌 구간이라 정원을 푸는 프로그램이 그 안에서 아무 때나 돌아도 멤버 눈에 차이가 없다.

위험한 건 실패하는 게 아니라 반쯤 성공하는 것이다

한 번 아찔한 게 있었다. 팀 하나의 재고 조회(남은 정원을 판매 시스템에서 읽어 오는 일)가 실패했는데 오류 표시 없이 이상한 값으로 돌아왔다. 그대로 두면 그 팀만 정원이 적게 복원된다. 아무도 모른다. 그 팀에 등록하려던 사람만 정원이 찼다고 느낀다. 그래서 조회가 실패하면 실패로 멈추게 고쳤다.

따라 해보기

먼저 온 사람이 다 가져가는 구조가 있다면, 전부 열지 말고 절반만 열어보면 된다. 그리고 정확한 시각에 닫혀야 하는 일은 내가 직접 하지 말고 시스템에 미리 걸어둔다.

올해 1월부터 운영을 자동화하기 시작했다. 여섯 달쯤 지나 세보니 명령 125개, 스크립트 305개, 정기적으로 도는 작업 52건이 됐다. 명령은 AI에게 빗금 뒤 이름 하나로 정해 둔 일을 시키는 지시서이고, 스크립트는 컴퓨터가 정해진 순서대로 처리하게 적어 둔 작은 프로그램이다.

이 숫자를 말하면 듣는 사람들이 놀란다. 그런데 나는 요즘 다른 목록을 더 자주 본다. 만들려다 안 만든 것들이다.

후기를 대신 쓰게 하지 않는다

이벤트 후기는 매번 오래 걸린다. 녹취를 듣고 정리하고 읽을 만한 글로 만든다. 여기에 자동화를 붙이는 건 어렵지 않고 초안까지는 실제로 도움을 받는다. 그런데 최종본은 내가 쓴다.

후기는 정보 전달이 아니기 때문이다. 그날 그 현장에 있던 사람이 뭘 보았는지 적은 기록이다. 발표자가 어느 대목에서 멈칫했는지, 어떤 질문에 방이 조용해졌는지, 누가 끝나고 남아 이야기를 더 했는지. 녹취에 없는 것들이다. 그리고 이게 없는 후기는 멤버가 안 읽는다. 요약은 어디에나 있다.

첫 인사는 편차가 없는 게 낫다

새 멤버가 오면 환영 메시지가 나간다. 발송은 자동인데 안에 들어가는 문장은 미리 써둔 것이고 사람이 승인한 것이다.

여기에 생성형 AI(문장을 그때그때 새로 지어 주는 AI)를 붙여 매번 다르게 만들 수도 있다. 안 했다. 백 명 중 아흔아홉에게 좋은 문장이 가고 한 명에게 이상한 문장이 가면, 그 한 명에게는 그 이상한 문장이 우리 첫인상이다. 첫 인사는 편차가 없는 게 개성 있는 것보다 낫다.

사람을 판정하지 않는다

이건 제일 분명하게 그은 선이다.

출석 데이터로 이탈할 것 같은 멤버를 찾는 자동화는 만들었다. 그런데 그건 안부를 묻기 위한 것이다. 이 멤버가 재등록(한 번 참여한 멤버가 다음 모집에 다시 신청하는 것)할 확률이 몇 퍼센트라거나 이 사람은 우량 멤버라는 분류는 만들지 않았다.

만들 수는 있다. 데이터가 있다. 그런데 그런 분류표가 존재하기 시작하면 운영자가 그걸 보고 사람을 대한다. 나도 사람이라 그렇게 된다. 그리고 커뮤니티에서 그건 반드시 티가 난다.

만든 것의 목록은 시간이 지나면 낡는다. 도구는 바뀌고 방식은 개선된다. 안 만들기로 한 이유는 안 낡는다. 왜 여기엔 사람이 있어야 하는지 답해 주기 때문이다.

따라 해보기

자동화를 하고 있다면, 만든 목록 옆에 안 만들기로 한 것도 써보면 된다. 그리고 그 옆에 왜 안 만들었는지 한 줄. 나중에 그 한 줄이 목록보다 오래 쓸모 있다.

AI가 일을 시작할 때마다 먼저 읽는 파일에 규칙을 다 적었다. 이건 이렇게 해라, 저건 하지 마라, 이 숫자는 여기서 가져와라. 거기 넣으면 안 잊을 줄 알았다.

그 파일이 계속 길어졌다.

읽히는 시점으로 넷으로 나눴다

규칙마다 필요한 시점이 달랐다. 그래서 언제 읽혀야 하는지로 나눴다.

항상 읽히는 것. 모르고 시작하면 사고가 나는 것만 넣는다. 멤버에게 대량 발송하기 전에 미리보기를 볼 것, 날짜는 추측하지 말고 캘린더에서 확인할 것. 이건 120줄을 넘기지 않기로 했다. 길어지면 안 읽힌다.

최근 것만 남기는 것. 최근에 난 사고에서 나온 교훈이 자동으로 쌓인다. 스무 개에서 서른 개쯤 유지된다.

찾아서 읽는 것. 지금 250개가 있다. 특정 주제를 작업할 때만 필요한 상세한 규칙들이다. 자동으로 안 읽히니, 그 주제를 시작하기 전에 해당 목록을 열어 본다.

명령 안에 두는 것. 명령(AI에게 빗금 뒤 이름 하나로 정해 둔 일을 시키는 지시서)을 쓸 때만 필요한 절차와 톤. 명령을 실행할 때 같이 읽힌다.

새 규칙을 적을 때 세 질문으로 정한다. 모르고 시작하면 사고가 나나. 특정 명령을 쓸 때만 필요한가. 특정 주제를 다룰 때만 필요한가.

같은 규칙을 두 곳에 복사하지 않는다

이게 지키기 제일 어려운 규칙이 됐다.

편해 보여서 복사하기 시작하면 두 곳이 갈라진다. 한쪽만 고치는 날이 오고, 그러면 어느 쪽이 최신인지 알 수 없어진다.

그래서 한 규칙은 한 곳에만 원본으로 두고, 다른 곳에는 그 원본을 가리키는 한 줄만 둔다. 예를 들어 쓰지 말아야 할 단어 목록은 늘 읽히는 곳에만 있다. 그 목록을 검사하는 명령에는 목록이 없고, 거기를 보라는 한 줄만 있다.

언제 읽을지를 같이 적는다

이 구조를 만들면서 생각이 하나 정리됐다.

규칙을 적는 목적은 실행이다. 적어 두었는데 필요한 순간에 안 읽히면 적은 값이 없다. 그래서 규칙을 쓸 때 이걸 언제 읽게 될지를 같이 정해야 한다.

항상 읽히는 곳은 좁아야 하고, 가끔 읽히는 곳은 넓어도 된다. 이 둘을 섞으면 좁은 쪽이 넓어져서 아무것도 안 읽힌다.

따라 해보기

팀에 규칙 문서가 하나 있고 그게 길어지고 있다면, 각 규칙 옆에 이걸 언제 읽어야 하는지를 써보면 된다. 항상 읽어야 하는 것만 남기고 나머지는 따로 뺀다.

업무 저장소(업무 파일을 모아 두고 고친 이력까지 기록하는 폴더)를 혼자 쓰다가 여러 명이 같이 쓰게 됐다. 사람마다 AI에게 파일을 고치게 하니 파일이 여러 방향에서 바뀐다.

곧 곤란해졌다. 어제와 다른 파일을 발견하는데 누가 왜 고쳤는지 알 수 없다. 커밋 기록(파일을 고칠 때마다 남는 변경 이력)에는 무엇이 바뀌었는지만 있고 왜는 없다.

부탁으로는 안 됐다

처음엔 규칙으로 적었다. 파일을 고치기 전에 오늘 업무일지에 목적을 먼저 적어 달라고.

지켜지지 않았다. 급하게 한 줄 고칠 때 업무일지를 여는 게 번거롭기 때문이다. 나부터 빠뜨렸다.

그런데 기록이 필요해지는 상황은 바빴던 날에서 나온다.

안 적으면 막히게 했다

그래서 순서를 강제했다. 파일을 편집하려고 하면, 검사 프로그램이 오늘 업무일지에 목적이 적혀 있는지를 먼저 본다. 없으면 편집이 막힌다. 업무일지 파일만은 언제나 열린다. 목적을 거기 적어야 하니까.

적어야 하는 건 세 가지다. 누가 하는가, 왜 고치는가, 무엇을 어디까지 고칠 것인가.

목적이 한 번 적히면 그 뒤로는 자동이다. 그날의 모든 편집이 시각과 파일 이름과 함께 업무일지에 쌓인다. 내가 다시 적을 필요가 없다.

세션이 시작될 때는 오늘 업무일지와 진행 중인 큰 작업 요약을 자동으로 보여준다. 어제 무슨 일이 있었는지 묻지 않아도 된다.

막는 장치가 일을 막으면 안 된다

여기서 하나를 조심했다. 이 검사가 고장 나면 아무도 일을 못 하게 된다.

그래서 검사에 문제가 생기면 막지 않고 통과시키도록 했다. 목적 기록을 한 번 놓치는 것보다 일이 통째로 멈추는 게 나쁘기 때문이다.

강제하는 장치를 만들 때는 그 장치가 틀렸을 때 무슨 일이 일어나는지를 같이 정해야 한다.

따라 해보기

팀에서 지켜지지 않는 규칙이 있다면, 더 강조하는 대신 안 지키면 다음 단계가 안 되게 만들 수 있는지 보면 된다. 그리고 그 장치가 고장 났을 때 일이 멈추지 않게 해둔다.

7월 29일, 멤버에게 나갈 공지 네 건이 안 나갔다. 예약(정한 시각에 컴퓨터가 알아서 작업을 시작하게 걸어 두는 설정)은 제대로 걸려 있었다. 그 시각에 노트북이 자고 있었고, 발견한 건 29시간 뒤였다. 안 도는 자동화는 오류를 안 내기 때문에 로그(프로그램이 남기는 실행 기록)를 봐도 안 보인다.

수요일이 우리 운영의 축이다. 그 주 세션(팀이 모이는 한 번의 모임) 준비가 수요일에 끝나야 하고, 멤버 공지가 수요일에 나가고, 다음 주 일정이 수요일에 예약된다.

여기 붙어 있는 일이 스무 가지쯤 된다. 지난주 슬랙(업무용 메신저) 정리, 핸드아웃(세션 때 나눠 주는 자료) 만들기, 이벤트 확정자 발표, 주간 백업. 순서도 있다. 명단이 확정돼야 핸드아웃을 만들고, 핸드아웃이 나와야 공지에 붙인다.

이걸 순서를 외워서 하다가 명령(AI에게 빗금 뒤 이름 하나로 정해 둔 일을 시키는 지시서) 하나로 묶었다. 그 명령 한 줄이면 처음부터 끝까지 순서대로 돈다.

예약을 걸어도 안 도는 일이 있었다

8월 9일에는 노트북이 22시간 꺼져 있었다. 그 사이 예약된 작업 두 개가 통째로 날아갔다. 이번에도 아무도 몰랐다.

예약 실행에는 함정이 있다. 시각이 지나가면 그냥 지나간다. 나중에 깨어나도 놓친 걸 따라잡지 않는다.

흐름 맨 앞에 점검을 넣었다

그래서 수요일 명령의 첫 단계를 노트북 점검으로 바꿨다. 앞으로 7일 동안 예약된 시각을 전부 뽑아 노트북의 절전 설정과 맞춰 보고, 그 시각에 노트북이 자고 있을 것 같으면 알려준다.

잠든 노트북을 정한 시각에 깨우는 기상 예약도 있다. 그런데 몇 분 간격으로 도는 작업이 아홉 개라 이걸로는 다 못 막는다. 하루에 수백 번 깨울 수는 없으니까.

그래서 가장 먼저 할 일은 아예 안 재우는 것이다. 전원을 꽂고, 뚜껑을 열어 두고, 절전을 끈다. 외출할 일이 있으면 그때만 기상 예약으로 막는다.

다섯으로 쪼개고 주 단위로 기록한다

묶은 것을 다시 다섯으로 나눴다. 성격이 다른 일들이 한 덩어리에 있었기 때문이다. 멤버에게 나가는 공지 묶음은 되돌릴 수 없어서 발송마다 미리보기를 본다.

그리고 이번 주에 뭐가 돌았고 뭐가 안 돌았는지를 수요일 날짜별로 기록한다. 중간에 끊겨도 어디까지 됐는지 파일을 열면 나온다.

따라 해보기

정해진 시각에 도는 작업이 있다면, 그 시각에 컴퓨터가 켜져 있는지부터 확인하면 된다.

2년 전에 열었던 팀들의 페이지가 남아 있지 않았다. 그 팀이 무엇을 다뤘고 파트너(팀 하나를 맡아 이끄는 사람)가 누구였는지 확인할 길이 없었다.

시즌(3개월마다 팀을 새로 여는 단위)마다 팀이 열여덟에서 스무 개 열리고, 각각 상품 페이지가 하나씩 있다. 3개월 뒤 새 시즌이 오면 또 스무 장이다.

이 반복에서 오래 곤란했던 건 만드는 일이 아니라 지난 것이 사라지는 일이었다.

지난 시즌이 조용히 없어진다

새 시즌 상품을 만들 때 지난 시즌 것을 고치게 된다. 같은 팀이 이어서 열리면 날짜와 회차만 바꾸는 게 빠르니까. 그러면 지난 시즌 페이지가 덮어써진다.

몇 시즌 지나고 나서야 알았다. 회차 주제가 뭐였는지도 찾을 수 없었다.

이게 왜 문제냐면, 멤버가 예전에 들었던 팀을 다시 찾을 때 보여줄 게 없다. 그리고 우리 스스로도 2년 전에 이 주제를 어떻게 다뤘는지 확인할 수 없다.

백업, 평가, 보완, 동기화

그래서 상품을 다루는 일을 네 단계로 묶었다.

먼저 백업이다. 어떤 작업을 하기 전에 지금 웹사이트에 올라가 있는 상품 본문을 전부 노트로 내려받는다. 이게 첫 단계인 이유는, 뒤에서 무슨 일이 생겨도 되돌릴 수 있어야 하기 때문이다. 실제로 한 번 배포 도구(노트를 웹사이트에 올려 주는 프로그램)가 상품 본문을 망가뜨린 적이 있는데, 그날 복구할 수 있었던 건 백업이 있어서였다.

다음이 평가다. 스무 개 페이지가 같은 항목을 다 갖추고 있는지 본다. 회차가 여섯 개인지, 파트너 소개가 있는지, 정원이 적혀 있는지. 사람이 스무 개를 눈으로 비교하면 열두 번째부터 흐려진다.

세 번째가 보완이다. 빠진 걸 채운다.

마지막이 동기화다. 노트가 정본이고 웹사이트가 사본이다. 노트를 고치고 올리는 방향으로만 흐른다. 웹사이트에서 직접 고치는 건 안 한다. 그러면 두 곳이 갈라지고, 갈라지면 어느 쪽이 맞는지 알 수 없게 된다.

이전 시즌은 복사본으로 남긴다

여기에 하나를 더했다. 팀을 다음 시즌으로 옮길 때 원래 카테고리에 복사본을 남긴다. 옮기기 전에 먼저 복제한다.

이게 지난 시즌이 사라지는 걸 막았다. 지금은 몇 년 전 팀들의 페이지가 그대로 있다.

따라 해보기

주기적으로 갱신하는 자료가 있다면, 갱신 전에 지금 상태를 복사해 두는 단계를 흐름의 맨 앞에 넣으면 된다. 나중에 백업하겠다는 계획은 지켜지지 않는다.

같은 알림이 하루에 열아홉 번 왔다. 다섯 사람의 요청이었는데, 그중 한 사람 것은 아홉 번 반복됐다.

이벤트 참석자 명단은 계속 움직인다. 대기자가 확정을 기다리고 확정자가 취소하고 누가 대신 신청한다.

이걸 처리하는 봇(정해진 일을 대신 해 주는 자동 프로그램)을 만들면서 승인 단계를 넣었다. 봇이 요청을 감지하면 나에게 알림이 오고 내가 눌러야 실행된다. 자동으로 명단이 바뀌는 게 무서웠다.

하루에 열아홉 번

명단에 없는 사람이 취소하겠다고 쓴 경우가 있었다. 이미 취소했거나 애초에 신청을 안 했거나. 처리할 게 없는 요청이다. 그런데 처리할 게 없다는 판정이 승인을 눌러야만 실행되는 단계에 있었다. 내가 안 누르는 동안 봇은 계속 미처리로 보고 다시 알렸다.

거슬러 올라가 보니 더 이상한 게 있었다. 참석 추가와 취소는 승인 없이 처리하기로 원래 합의했던 일이었다. 코드가 그 합의를 안 따르고 있었다. 만들 때 불안해서 일단 걸어둔 임시 조치가 그대로 굳은 것이다.

다 걷어내진 않았다

취소만 두 갈래로 나눴다. 참석 취소합니다, 불참하게 되었습니다처럼 분명하게 밝힌 문장은 자동으로 처리한다. 못 가면 어떻게 되나요, 자리 양도 되나요 같은 문장은 자동으로 처리하지 않는다. 이건 질문이지 취소가 아니다.

이 구분이 왜 필요했냐면, 취소 관련 단어를 넓게 잡아 자동 처리하면 질문한 사람이 명단에서 빠지기 때문이다. 물어보기만 했는데 명단에서 빠지는 것보다 나쁜 경험은 별로 없다.

그래서 애매한 문장은 나에게 한 번만 알린다. 알림에 취소 처리와 무시 버튼이 붙어 있고 내가 결정해서 누른다. 한 번 알린 뒤엔 다시 알리지 않는다. 앞의 열아홉 번을 안 되풀이하려고.

다른 사람을 대신 명단에 넣는 경우에도 확인 단계를 두었다. 대상자 본인에게 확인을 받는다. 동의 없이 명단에 넣지 않는다.

승인을 붙일 데는 되돌리기 어려운 일과 결정이 필요한 일이다. 그 둘이 아닌데 승인을 붙이면 안전장치가 아니라 대기열이 된다. 대기열은 내가 바쁠수록 길어지고, 혼자 운영하면 요청이 기다리는 시간도 길어진다.

따라 해보기

내가 승인해야 진행되는 일을 목록으로 써보면 된다. 줄마다 되돌릴 수 있는지, 결정이 들어가는지 두 칸을 표시한다. 둘 다 아니오인 줄은 승인을 떼도 되는 일이다.

업무와 별개로 개인 메모를 쌓아두는 폴더가 있다. 읽은 책, 다녀온 곳, 생각나는 것들. 어느 날 이 폴더가 이상하게 무겁다는 걸 알았다. 텍스트 파일만 있는데 용량이 컸다.

같은 글이 스무 번 들어 있었다

파일 하나를 열었다. 내가 쓴 글이 맞았다. 그런데 끝까지 내려보니 같은 글이 다시 시작되고 있었다. 또 내리니 또 시작됐다. 한 파일에 같은 본문이 스무 번 반복돼 있었다.

원인은 내가 만든 동기화 스크립트(다른 곳의 원본을 이 폴더로 가져오는 작은 프로그램)였다. 이미 있는 파일을 만나면 갱신해야 하는 곳에서 뒤에 이어붙이고 있었다. 실행될 때마다 한 벌씩 늘었다.

몇 달 동안 아무도 몰랐다. 나조차도. 파일을 열면 위에서부터 읽으니 정상으로 보인다. 아래에 뭐가 더 있는지는 안 내려가 본다.

정리하니 44편 5.0메가바이트가 237킬로바이트가 됐다. 스무 배 넘게 부풀어 있었다.

성공했다고 보고하는데 틀린 경우

용량보다 마음에 걸린 건 따로 있었다.

이건 오류를 낸 적이 한 번도 없다. 스크립트는 매번 성공했다고 보고했고 실제로 성공했다. 파일에 내용을 넣는 데 성공했지 파일을 올바른 상태로 만드는 데 성공한 게 아니었다.

이런 실패는 알림으로 못 잡는다. 알림은 실패했을 때 오는데 이건 실패하지 않았다.

그 뒤로 파일을 쓰는 자동화에 습관 하나를 붙였다. 쓰고 나서 다시 읽고 예상한 모양인지 본다. 줄 수가 갑자기 늘었는지, 제목이 두 번 나오는지, 어제보다 크기가 이상하게 커졌는지. 거창할 필요 없다. 어제와 오늘의 크기 차이만 봐도 이런 사고는 대부분 걸린다.

따라 해보기

자동으로 파일을 만들거나 고치는 게 있다면, 오늘 그 결과물의 크기를 적어두면 된다. 내일 다시 적는다. 숫자 두 개면 조용히 틀리는 걸 잡을 수 있다.

AI에게 같은 말을 두 번 하지 않으려고 적어 둔 규칙이 250개가 됐다. 같은 내용이 두 파일에 있고, 서로 반대되는 규칙도 있었다.

이 규칙 파일들을 메모리라고 부른다. AI가 새 대화를 시작할 때 읽고 따르는 기억이다. 사고가 나면 그 교훈을 적고, 취향이 있으면 그것도 적는다.

250개가 되면 새 문제가 생긴다

열 개일 때는 다 기억한다. 쉰 개쯤부터 뭐가 있는지 애매해진다. 250개가 되면 세 가지가 동시에 일어난다.

같은 내용이 두 파일에 있다. 몇 달 간격으로 비슷한 사고가 나면 새로 적게 된다. 예전에 적어둔 걸 못 찾아서다.

서로 반대되는 규칙이 있다. 예전에 이렇게 하기로 했다가 나중에 바꿨는데, 앞의 것을 안 지웠다. 어느 쪽을 따를지 모른다.

아무도 안 읽는 규칙이 있다. 지난 시즌(석 달 단위 모임 기간)에만 해당하는 규칙, 이미 없어진 도구를 다루는 규칙. 남아 있어도 해가 없어 보이지만 목록을 길게 만들어서 나머지를 안 읽히게 한다.

메모리를 점검하는 명령을 만들었다

그래서 메모리를 점검하는 명령(AI에게 빗금 뒤 이름 하나로 정해 둔 일을 시키는 지시서)을 하나 만들었다.

인덱스(규칙 파일 이름을 한 줄씩 적어 둔 차례)에 있는데 파일이 없는 것, 파일은 있는데 인덱스에 없는 것을 찾는다. 다른 규칙을 가리키는 링크가 깨졌는지 본다. 내용이 겹치는 쌍을 찾는다. 서로 반대되는 것을 찾는다. 오래 안 쓰인 것을 보관 후보로 뽑는다.

한 달에 한 번쯤 돌린다. 결과를 보고 지울지 합칠지 보관할지는 내가 정한다. 명령은 찾아주기만 하고 고치지 않는다.

쌓기와 정리는 다른 일이다

이걸 겪고 나서 생각이 하나 정리됐다.

지식을 쌓는 일은 자연스럽게 일어난다. 사고가 나면 적게 되고 배우면 남기게 된다. 그런데 정리하는 일은 저절로 안 일어난다. 아무도 250개를 다시 읽어보고 싶어 하지 않는다.

틀린 규칙이 섞여 있는 250개는 규칙이 하나도 없는 것보다 위험할 수 있다. 틀린 걸 믿고 실행하기 때문이다.

그래서 쌓는 것만큼 걷어내는 것을 정기적인 일로 만들어야 했다.

각 규칙에 왜 이 규칙이 생겼는지도 같이 적어둔다. 그래야 나중에 그 이유가 없어졌을 때 지울 수 있다. 이유가 안 적힌 규칙은 아무도 못 지운다.

따라 해보기

팀의 규칙이나 매뉴얼이 쌓이고 있다면, 각 항목에 왜 생겼는지를 한 줄 적어두면 된다. 그리고 반년에 한 번 그 이유가 아직 유효한지만 훑는다. 이유가 사라진 규칙은 지운다.

포트폴리오를 만들려고 자료를 찾다가, 내가 뭘 가져가도 되는지 자신이 없다는 걸 알았다. 노트와 스크립트(정해진 일을 자동으로 하는 작은 프로그램)와 문서와 원고가 한 폴더에 뒤섞여 있었다. 회사 데이터를 다루는 코드 옆에 내가 쓴 에세이 초안이 있고, 그 옆에 회의록이 있고, 또 그 옆에 개인 메모가 있었다.

몇 년을 그렇게 보냈다. 문제라고 느낀 적도 없었다.

선을 하나 그었다

경험과 결정은 내 것이다. 뭐가 문제였고 어떻게 풀기로 했는지는 내 머리에서 나왔고, 다른 데 가도 가져간다.

코드와 데이터와 시스템은 회사 것이다. 실제로 도는 스크립트, 멤버 정보, 매출 자료, 운영 계정. 회사 일을 위해 만들었고 회사에 남는다.

적어놓으면 당연해 보이는데 파일 하나하나에 대보면 애매한 게 많다. 내가 만든 자동화의 설계 문서는 어느 쪽인가. 설명은 내 것, 코드는 회사 것으로 나눴다. 뭘 왜 그렇게 만들었는지는 내 결정이고 그걸 실행하는 코드는 회사 자산이다. 그래서 내 보관함엔 ‘이런 문제가 있어서 이렇게 풀었다’는 설명만 남기고 코드 사본은 안 둔다.

내가 운영한 팀의 활동 기록은 예외로 뒀다. 내가 만든 거라 내 보관함에 두되, 거기엔 멤버 실명과 소속과 발언이 있으니 밖으로 내보내지 않는다. 보여줄 일이 있으면 이름과 회사와 특정할 수 있는 세부를 빼고 다시 쓴다. 이 블로그도 그 원칙 위에 있다.

기준 없이 오래 있었다

솔직히 계기는 이직 준비였다. 그동안 아무 생각 없이 다 내 것처럼 다뤄온 것이다.

그 순간이 좀 불편했다. 나쁜 짓을 하려던 게 아닌데 기준이 없는 상태로 오래 있었다는 게.

그래서 나가기 위해서가 아니라 있는 동안 지킬 기준으로 정리했다. 그러고 나니 오히려 편해졌다. 뭘 밖에 써도 되는지 아니까 쓸 수 있게 됐다. 기준이 없을 땐 애매해서 아무것도 못 썼다.

오래 일한 사람에게는 결정 기준이 쌓인다. 이 상황에서 이렇게 하면 안 된다는 것, 저 방법은 두 번 해봤는데 안 됐다는 것. 이건 인수인계 자료에 안 들어간다. 코드에는 결과만 남고 왜 그랬는지는 안 남는다. 그래서 회사에 남길 건 남기고, 내가 가져갈 건 내 언어로 적어 둔다.

따라 해보기

지금 일하는 곳에서 만든 것 중에 하나만 골라, 이건 내 것인가 회사 것인가를 써보면 된다. 애매하면 설명과 실물을 나눠본다. 설명은 내 것이고 실물은 회사 것이다.

어떻게 그걸 다 혼자 하세요. 이 질문을 자주 받는데 매번 답하기가 어렵다. 잘해서가 아니기 때문이다.

지금 관리하는 시즌(모집 한 번에 열리는 모임 기간)이 열여섯 개다. 그동안 열린 팀이 137개, 슬랙(업무용 메신저) 채널(주제별 대화방)이 458개. 한 시즌에 제일 많았을 때 멤버가 208명, 이벤트가 22회였다. 이걸 기본적으로 한두 명이 한다.

매 시즌 반복되는 일만 적어봐도 팀 기획과 파트너(팀을 이끄는 진행자) 섭외, 소개 페이지, 주간 레터, 이벤트와 후기, 멤버 온보딩(새 멤버 안내), 슬랙 공지, 브랜드 관리다. 이 목록을 처음 써놓고 본 날, 이게 가능한가 싶었다.

매번 같은 데서 무너졌다

솔직히 매 시즌 무너졌다. 다만 무너지는 데가 매번 같았다.

무너지는 때는 셋이었다. 오픈 2~3주 전에 소개 페이지 스무 장을 만들 때, 이벤트가 몰리는 주에 후기가 밀릴 때, 마감 직후에 명단을 맞출 때.

같은 데서 계속 무너지는데도 몇 년은 그걸 내 문제로 봤다. 더 부지런하면, 더 일찍 시작하면 될 것 같았다. 그래서 매 시즌 더 노력했는데 결과는 매번 같았다. 구조의 문제라는 걸 인정하는 데 시간이 걸렸다.

인정하고 나서야 다른 질문이 나왔다. 이걸 어떻게 다르게 만들지.

그때부터 한 시즌에 하나씩만 골랐다. 전체를 뜯어고치려 하지 않고 이번 시즌에 제일 아팠던 데 하나만. 몇 년 지나니 아픈 데를 고친 흔적이 쌓여 시스템 비슷한 게 생겼다.

1인 운영의 어려움은 일의 양이 아니었다. 양은 어떻게든 된다. 밤에 하고 주말에 한다. 진짜 어려운 건 내가 병목이 된다는 것이고, 내가 잊는다는 것이다. 그래서 내가 없어도 굴러가는 구간을 늘리는 게 자동화의 첫 목적이 됐다. 시간을 아끼는 건 두 번째다.

따라 해보기

혼자 감당이 안 되는 일이 있다면, 이번 달에 제일 아팠던 데 하나만 써보면 된다. 전부 말고 하나만. 다음 달에 또 하나.

시즌(3개월 단위 모임 기간)이 끝나고 재등록(다음 시즌에 다시 신청하는 것) 명단을 받으면 누가 안 왔는지 알게 된다. 그때는 늦다.

첫 시즌으로 들어온 멤버 중 다음에 오지 않는 비율을 세봤다. 절반이 넘었다. 처음엔 프로그램을 더 좋게 만들어야겠다고 생각했다. 그런데 떠난 분들의 출석 기록을 다시 보니 다른 게 보였다. 떠나기 전에 이미 안 나오고 있었다.

만족도 조사 대신 출석을 본다

만족도 조사는 끝나고 받는다. 그리고 답하는 사람은 만족한 사람이다. 불만이 있는 사람은 답하지 않고 그냥 사라진다.

출석은 다르다. 매 회차 기록되고, 마음이 떠나면 출석부터 흔들린다. 그래서 시즌이 도는 중에 출석을 읽어서 연속으로 빠진 멤버와 출석률이 낮은 멤버를 뽑기로 했다. 뽑힌 분에게는 안부를 묻는 메시지가 나간다. 재등록 권유가 아니라 안부다.

어려운 건 잘못 보내지 않는 쪽이었다

만들면서 시간이 제일 많이 든 일은 신호 찾기가 아니었다.

출석부에 아직 안 적힌 칸과 안 왔다고 적힌 칸은 다르다. 빈칸을 불참으로 세면 성실한 멤버에게 안부 메시지가 간다. 그래서 안 왔다고 적힌 것만 세고, 빈칸을 만나면 거기서 멈추게 했다.

이름으로 사람을 맞추면 동명이인이 걸린다. 예전에 이름으로 맞춰 보내다가 다른 분에게 메시지가 나간 적이 있다. 그래서 이름과 회사가 둘 다 맞을 때만 보낸다. 하나라도 안 맞으면 안 보내고 나에게 보고만 한다.

한 번 받은 사람은 다시 받지 않게 막았고, 따로 정하지 않으면 보내지 않게 해 두었다. 명령(AI에게 빗금 뒤 이름 하나로 정해 둔 일을 시키는 지시서)을 그냥 실행하면 누구에게 보낼지 목록만 보여주고 끝난다.

운영 자동화에서 위험은 두 종류다. 해야 할 걸 안 하는 것과 하지 말아야 할 걸 하는 것이다. 앞은 내가 나중에 직접 메우면 되지만, 뒤는 멤버가 이미 받았으니 되돌릴 수 없다. 사람들이 서로 아는 커뮤니티에서는 한 명을 놓치는 것보다 한 명에게 잘못 가는 게 더 나쁘다.

따라 해보기

끝나고 나서야 아는 숫자가 있다면, 진행 중에 미리 흔들리는 게 뭔지 하나만 찾아보면 된다. 출석이나 접속이나 응답 같은 행동 기록이다. 그리고 그걸로 사람에게 연락할 거면 확실하지 않을 때 안 보내는 쪽을 기본값으로 둔다.

모임 전에 올라가야 할 도착 확인 댓글이 올라가지 않았다. 노트북이 절전 상태였고, 나는 모임 당일 스레드(메시지 하나에 이어 달리는 댓글 묶음)를 열어 보고서야 알았다.

자동화를 하나씩 만들다 보면 어느 순간 개수를 모르게 된다. 세봤더니 정기적으로 도는 작업이 쉰 개가 넘었다.

각각은 만들 때 잘 돌아가는 걸 확인했다. 문제는 그 다음이다. 어제 그게 돌았는지 나는 모른다.

안 돌아도 티가 안 난다

자동화가 실패하는 방식은 두 가지다. 오류를 내면서 죽거나, 그냥 안 도는 것.

앞은 그나마 낫다. 오류 기록이 남는다. 뒤가 문제다. 예약(정해진 시각에 작업이 저절로 돌게 걸어 두는 설정)이 안 걸렸거나 컴퓨터가 절전이었거나 앞 단계가 안 끝나서 시작을 안 했거나. 아무 기록도 안 남는다. 로그(작업이 돌 때마다 쌓이는 기록)를 열어봐도 어제 항목이 없다.

그리고 없는 걸 알아채기는 어렵다. 매일 아침 오던 알림이 안 왔다는 걸 사람은 잘 못 느낀다. 오면 보고 안 오면 그냥 조용한 하루다.

앞의 도착 확인 댓글이 그랬다. 지나간 예약은 노트북이 깨어나도 다시 안 돈다.

실패 대신 성공을 보고하게 했다

작업마다 감시 항목을 하나씩 둔다. 시작할 때 시작했다고 알리고 끝나면 끝났다고 알린다. 예상 시각까지 신호가 안 오면 나에게 알림이 온다.

침묵 자체를 사건으로 만드는 방식이다. 안 돈 작업은 아무 소리도 안 내는데, 감시하는 쪽에서 와야 할 게 안 왔다를 사건으로 잡는다.

여기에 하나를 더했다. 감시를 붙이는 걸 직접 하지 않는다. 사람은 잊는다. 특히 급하게 만든 자동화에 감시를 붙이는 일은 항상 나중으로 밀린다. 그래서 모든 작업이 실행 프로그램 하나를 거쳐 돌게 했다. 이 프로그램이 시작과 끝 신호를 알아서 보낸다.

개수가 늘면 새 일이 생긴다

하나 만들면 일이 준다. 열 개 만들면 많이 준다. 쉰 개를 만들면 새로운 일이 생긴다. 이것들이 잘 돌고 있는지 확인하는 일이다.

개수가 늘면 자연히 따라오는 일이다. 이걸 안 하면 자동화가 늘수록 운영이 불안해진다. 무엇이 멈췄는지 모르니 문제가 생겨도 어디부터 볼지 모른다.

따라 해보기

돌고 있는 자동 작업을 종이에 다 써보면 된다. 그리고 각각 옆에 이게 안 돌면 내가 어떻게 아는지를 쓴다. 빈칸으로 남는 줄이 다음에 고칠 것이다.

멤버가 마음을 먹고 결제를 한다. 첫 모임까지 3주가 남는다.

그 3주 동안 우리가 보내는 게 뭔지 세봤다. 결제 완료 안내 말고는 없었다. 슬랙(업무용 메신저) 초대는 시즌(모집 한 번에 열리는 모임 기간) 시작 직전에 한꺼번에 나갔다. 멤버 입장에서는 돈을 내고 3주를 조용히 기다린 셈이다.

같은 길에 정반대 문제가 붙어 있었다

등록 경험을 단계로 그려 봤다. 결제, 명단 등록, 워크스페이스(우리 커뮤니티가 쓰는 슬랙 공간) 초대, 팀 채널(주제별 대화방) 입장, 자기소개, 사전 안내, 첫 회차. 일곱 단계다. 단계마다 멤버가 받는 것과 해야 하는 걸 적었더니 저점이 두 군데 드러났다.

하나는 침묵 구간이다. 결제부터 초대까지 아무것도 안 간다. 결제가 됐는지, 언제 뭘 하면 되는지 알 수 없다. 이 구간에 문의가 몰린다는 건 알고 있었는데, 그게 구조 때문이라는 건 그려 보고서야 알았다.

다른 하나는 압도 구간이다. 워크스페이스에 들어간 직후. 이번엔 반대다. 채널이 한꺼번에 보이고 공지가 쌓여 있고 자기소개를 쓰라는 안내가 있다. 처음 온 멤버는 어디부터 봐야 할지 모른다.

하나는 너무 없어서, 하나는 너무 많아서 문제였다.

없는 곳엔 예고를, 많은 곳엔 시작점을

침묵 구간에는 환영 메일을 놓기로 했다. 화려할 필요가 없다. 등록이 확인됐다는 것, 언제 무엇이 올 예정인지, 그때까지 할 일은 없다는 것. 세 가지면 된다. 기다림이 문제가 아니라 예고 없는 기다림이 문제였다.

압도 구간에는 개별 메시지를 놓기로 했다. 여기서는 시작점을 하나 주는 게 낫다. 채널이 스무 개여도 ‘먼저 이것부터 하시면 됩니다’ 한 줄이 있으면 막막함이 크게 준다.

솔직히 적어두면 이 둘은 아직 다 켜지 못했다. 설계를 마친 게 2026년 6월이고 아직 붙이는 중이다. 실제 멤버에게 가는 메시지라 나에게 먼저 보내 보고, 보낸 기록을 남기고, 같은 사람에게 두 번 안 가게 잠금을 걸고 나서야 켠다는 규칙 때문에 느리다. 이 순서는 안 바꿀 생각이다.

우리는 등록을 결승선처럼 다루고 있었다. 멤버에게 등록은 출발선이다. 결제 버튼을 누른 순간부터가 첫 경험인데, 그 첫인상이 3주짜리 침묵이었다.

따라 해보기

내가 파는 것을 처음 사는 사람이 되어, 결제 버튼부터 첫 경험까지를 단계로 써보면 된다. 각 단계에서 그 사람이 뭘 받는지 옆에 쓴다. 빈칸이 보이는 곳이 고칠 데다.

이번 시즌에 이 팀 멤버가 몇 명이죠. 간단한 질문 같은데 나는 답하기 전에 매번 세 군데를 봤다. 등록 시트(신청 내용이 쌓이는 표), 팀 슬랙 채널(업무용 메신저 슬랙에 팀마다 만든 대화방), 출석부. 세 곳 답이 자주 달랐다.

각각이 다른 때에 다른 이유로 채워지기 때문이다. 시트는 결제가 들어오면 채워진다. 채널은 초대가 나가고 본인이 수락해야 채워진다. 출석부는 시즌(3개월 단위 모임 기간)을 시작할 때 명단을 복사해서 만든다.

그 사이에 틈이 생긴다. 결제하고 초대를 못 받은 사람. 초대를 받고 수락 안 한 사람. 두 팀에 등록했는데 한 팀에만 들어간 사람. 중간에 팀을 옮겼는데 출석부만 안 고쳐진 사람. 하나하나는 사소한데 열여덟 팀에 백몇십 명이면 쌓인다.

고치는 도구가 아니라 보는 도구로 만들었다

자동으로 맞추는 쪽을 먼저 생각했다가 접었다. 세 명단이 다를 때 어느 쪽이 맞는지를 기계가 정할 수 없다.

시트에 있고 채널에 없으면 초대가 빠진 걸 수도 있고, 취소한 분을 시트에서 안 지운 걸 수도 있다. 정반대 조치가 필요한데 겉모습이 똑같다.

그래서 읽기만 하는 도구로 만들었다. 세 명단을 다 대조해서 안 맞는 것만 목록으로 뽑고 아무것도 고치지 않는다. 고치는 건 목록을 보고 내가 결정해서 따로 한다. 이 구분이 중요했다. 확인하는 일과 고치는 일을 한 도구에 넣으면 확인 결과를 못 믿게 된다. 이미 뭔가 바꿔 놓은 뒤라 원래 상태를 알 수 없다.

아무도 못 받는 초대

대조를 돌리고 나서 이름 붙일 수 있게 된 게 하나 있다.

예전에 가입한 분이 새 시즌에 다른 이메일로 등록한다. 회사를 옮겼거나 개인 메일로 바꿨거나. 우리는 새 이메일로 초대를 보낸다. 그런데 그 사람은 이미 옛 계정으로 들어와 있다.

초대는 발송된 상태로 남는다. 실패가 아니다. 그냥 아무도 안 받는다. 시트에는 등록으로 잡히고 채널에는 없다. 본인은 초대가 안 왔다고 생각하고 우리는 보냈다고 생각한다.

전에는 이걸 개별 문의로만 알았다. 말 안 하고 그냥 시즌을 흘려보낸 분이 몇 명인지는 지금도 모른다.

데이터가 여러 곳에 있으면 관리를 잘해도 갈라진다. 그래서 목표를 갈라진 걸 정기적으로 아는 것으로 바꿨다.

따라 해보기

같은 걸 두 군데 이상에 적고 있다면, 오늘 그 두 곳을 한 줄씩 맞춰 보면 된다. 다른 게 몇 개인지만 세본다. 고치지 않아도 된다.

팀 이름은 오픈 직전까지 바뀐다. 채널(팀마다 따로 여는 대화방)을 먼저 만들어 두면 이름을 다 고쳐야 하고 이미 초대한 멤버도 정리해야 한다.

3개월마다 시즌이 하나씩 열린다. 여는 데 필요한 일이 많은데, 몇 년 동안 그 일들을 순서 없이 했다. 생각나는 것부터 했고 급한 것부터 했다.

정리해 보니 두 덩어리였다.

기획과 셋업은 다른 일이다

첫 덩어리는 기획이다. 무엇을 열지 정하는 일이다. 팀을 정하고, 파트너(팀을 이끄는 진행자)를 섭외하고, 회차 주제를 잡고, 정원과 일정을 정하고, 상세 페이지를 쓰고, 오픈 공지와 레터를 예약한다.

두 번째 덩어리는 셋업이다. 정해진 것을 실제로 굴러가게 하는 일이다. 지난 시즌 채널을 정리하고, 새 팀 채널을 만들고, 회고 칸을 만들고, 등록한 멤버를 초대하고, 각 팀의 회차 칸을 미리 깔아둔다.

이 둘을 섞으면 기획이 안 끝났는데 채널부터 만들게 된다.

그래서 둘을 갈랐다. 기획 쪽 명령(AI에게 빗금 뒤 이름 하나로 정해 둔 일을 시키는 지시서)이 하나, 셋업 쪽 명령이 하나. 셋업은 기획이 끝나기 전에는 돌리지 않는다.

순서가 규칙이 되면 기억을 안 해도 된다

이렇게 나누고 나서 좋아진 게 하나 더 있었다.

셋업에 들어가는 일은 앞에 적은 다섯 가지다. 하나라도 빠지면 시즌 중간에 알게 되는데 그때는 이미 멤버들이 그 단계를 지나친 뒤다.

지금은 셋업 명령 안에 그 목록이 들어 있다. 내가 기억하지 않아도 순서대로 다 지나간다.

몇 년 동안 더 조심하는 쪽을 시도했고 매번 실패했다. 시즌 오픈 직전은 원래 조심할 여력이 없는 시기다. 그때 필요한 건 목록이었다.

아직 직접 하는 일

전부 자동은 아니다. 팀 이름을 정하는 일, 파트너에게 부탁하는 일, 상세 페이지의 첫 문장을 쓰는 일은 그대로 내가 한다. 이건 자동화할 것도 아니고 하고 싶지도 않다.

명령이 하는 일은 그 앞뒤에 붙은 반복이다. 정해진 걸 여기저기 옮겨 적고 빠진 걸 찾는다.

따라 해보기

주기적으로 돌아오는 큰 일이 있다면, 그 일을 정하는 단계와 실행하는 단계로 갈라 써보면 된다. 그리고 실행 단계는 정하는 단계가 끝나기 전에 시작하지 않는다는 규칙 하나만 세운다.

이벤트 후기 한 편을 네 번 썼다. 웹사이트 긴 글, 뉴스레터 요약, 링크드인(직장인용 SNS) 짧은 글, 인스타 카드 문장. 후기 쓰는 시간보다 옮기는 시간이 더 걸렸다.

이벤트가 끝나면 후기를 쓴다. 이 일만은 놓지 않았다. 못 온 멤버가 무슨 이야기였는지 알아야 하고, 몇 년 뒤에 다시 찾을 사람도 있다.

문제는 그 다음이었다. 네 곳은 길이도 말투도 달라서 복사가 안 됐다.

원본 글 하나를 두고 나머지를 거기서 만든다

순서를 바꿨다. 웹사이트용 긴 글을 원본으로 두고 나머지 셋을 거기서 만든다.

그냥 잘라 쓰는 게 아니다. 링크드인은 첫 세 줄에서 읽을지 말지가 갈리니 도입을 다시 만들어야 하고, 뉴스레터는 이미 우리를 아는 사람이 읽으니 배경 설명을 걷어내야 한다. 이 변환 규칙을 문서로 적어두고 그대로 쓴다.

여기에 링크드인 글은 미리 쌓아두는 방식을 더했다. 지난 후기와 인사이트 노트를 재료로 1년치를 미리 만들어 두고 화요일과 목요일에 하나씩 올라가게 했다.

발행 버튼은 사람이 누른다

여기서 하나를 못 박았다. 만드는 데까지만 자동이고, 내보내는 건 사람이 한다.

만들어진 글은 예약 도구(정한 시각에 글을 대신 올려 주는 서비스)에 초안으로 올라간다. 예약이 아니라 초안이다. 나에게 알림이 오고, 내가 열어서 읽고 고치고 승인해야 그때부터 예약이 걸린다.

왜 이 선을 그었냐면, 커뮤니티 글에는 사람 이름과 회사 이름이 들어가기 때문이다. 발표자가 그날 한 말 중에는 공개된 곳에서 한 번 더 인용해도 되는 말과 그렇지 않은 말이 섞여 있다. 이건 그날 그 현장에 있던 사람만 안다.

아직 못 푼 것도 있다. 같은 재료에서 나온 글끼리 말투가 닮는다. 형식은 다른데 문장이 비슷해진다. 지금은 몇 편에 한 번씩 아예 새로 쓰는 것으로 때우고 있다.

따라 해보기

같은 내용을 여러 곳에 올리고 있다면, 어느 하나를 원본으로 정하고 나머지는 거기서 만든다고 정해보면 된다. 그리고 원본에서 각 곳으로 옮길 때 무엇을 빼고 무엇을 더하는지 세 줄로 적어두면 된다. 다음부터는 그 세 줄대로 옮긴다.

모임 시작 30분 전이 제일 불안하다. 몇 명이 오는지 모른다.

오래 쓴 방법은 공지에 달린 이모지를 세는 것이었다. 참석하실 분은 이모지를 남겨 달라고 안내하고 그 수를 센다. 안 남긴 분은 이름을 태그해서(@를 붙여 알림이 가게 해서) 한 번 더 묻는다.

사람들은 이모지를 여러 뜻으로 쓴다

읽었다는 뜻으로 쓰고, 좋다는 뜻으로 쓰고, 응원한다는 뜻으로도 쓴다. 참석하겠다는 뜻으로만 쓰는 사람은 일부다.

그래서 이모지 수와 실제 참석자가 계속 어긋났다. 이모지는 열여덟인데 열두 명이 오거나, 여덟인데 열다섯 명이 왔다.

더 나쁜 건 이름 태그였다. 안 남긴 사람을 골라 태그하려면 누가 이 모임 멤버인지 알아야 하는데 그 명단이 정확하지 않았다. 이미 취소한 분을 태그하거나, 다른 팀 멤버를 태그하거나, 이름이 비슷한 분을 태그하는 일이 반복됐다. 공개된 채널(여럿이 함께 보는 대화방)에서 이름을 잘못 부르는 건 작은 실수가 아니다. 태그된 사람도 민망하고 그걸 보는 다른 멤버도 운영진을 믿기 어려워진다.

해석하지 않기로 했다

시작 30분 전에 프로그램이 공지 스레드(공지에 이어 달리는 댓글 묶음)에 댓글을 하나 단다. 오늘 오기로 되어 있는 사람들의 이름이 체크박스 목록으로 들어 있다. 개인을 부르는 태그는 없다. 이름은 체크박스 라벨로만 나온다. 체크는 운영진만 하고 도착 인원이 실시간으로 갱신된다.

멤버에게는 한 줄만 안내한다. 곧 시작하니 도착 예정 시간을 댓글로 남겨 달라는 것. 해석의 여지가 없다. 남기면 남긴 거고 안 남기면 안 남긴 거다.

같이 고친 게 명단 출처다. 예전엔 채널에 있는 사람이나 이모지를 남긴 사람에서 명단을 만들었다. 지금은 팀 정기 모임이면 그 시즌(3개월 단위 모임 기간) 배정 명단에서, 신청받은 이벤트면 확정 참석자 명단에서 가져온다. 출처가 하나면 틀렸을 때 어디를 고칠지 안다. 여러 개면 틀린 걸 봐도 어디를 고칠지 모른다.

한 번 사고도 있었다. 여러 이벤트가 같이 쓰는 채널에 새 워크숍 도착 확인을 걸었다. 프로그램이 그 채널에 가장 최근 저장된 명단을 가져왔는데, 다른 행사 명단이었다. 엉뚱한 스레드에 엉뚱한 명단이 올라갔다. 바로 지웠다. 한 채널에 하나의 행사만 있다고 가정한 게 실제 운영과 달랐다.

따라 해보기

사람들의 행동을 세어서 뭔가를 결정하고 있다면, 그 행동을 한 사람들에게 정말 그 뜻인지 한 번 물어보면 된다. 여러 뜻으로 읽히는 행동이면 세지 말고, 뜻이 하나인 행동을 새로 만들어 주는 게 빠르다.

시즌(석 달 단위 모임 기간)이 열리면 명찰을 만든다. 90×60밀리미터 카드에 위는 브랜드 색 띠, 아래 흰 바탕에 이름과 태그라인이 들어간다. 지난 시즌은 파트너(팀을 이끄는 진행자) 13명에 멤버 146명, 159장이었다.

원래는 디자인 툴에서 만들었다. 템플릿 하나 만들고, 이름 바꾸고, 내보내고, 다음 이름으로 넘어간다. 변수 기능(이름 칸만 바꿔 끼워 여러 장을 만드는 기능)이 있어서 완전한 수작업은 아니었지만 명단이 바뀌면 처음부터 다시 돌려야 했다.

명단은 바뀐다. 오픈 직후에 바뀌고 첫 회차 전날에도 바뀐다. 첫 모임 이틀 전에 명찰을 다시 뽑는 일이 매번 있었다.

자로 재보니 1.2밀리미터가 떠 있었다

그래서 이름을 어디서 가져올지부터 고쳤다. 멤버 명단 시트를 그대로 읽게 했다. 명단이 바뀌면 명령 한 줄(정해 둔 일을 컴퓨터에 시키는 짧은 지시)로 159장을 다시 만든다.

여기서 예상 못 한 게 나왔다. 이름을 흰 바탕 한가운데 놓아야 하는데, 처음엔 글자 크기에 대충 비례하는 값을 썼다. 흔히 쓰는 어림값이다. 인쇄물을 자로 재봤더니 이름이 한가운데보다 1.2밀리미터 위에 있었다.

1.2밀리미터는 눈으로 잘 안 보인다. 그런데 백 장을 늘어놓으면 보인다. 전체가 미묘하게 위로 뜬 느낌이 든다.

어림값을 버리고 실제 글자의 위쪽 끝과 아래쪽 끝을 재서 그 사이 가운데에 놓게 고쳤다. 편차가 0.1밀리미터 안으로 들어왔다.

감으로 때우던 걸 말로 적게 된다

이 일은 오래 생각났다. 디자인 툴에서는 눈으로 보고 가운데 같네 하고 넘어갔다. 그게 몇 년이었다.

코드로 옮기니까 내가 위치를 어떤 근거로 정하는지 말로 적어야 했고, 적어 보니 근거가 어림값이었다. 두 팀에 등록한 사람에게 명찰을 한 장 줄지 두 장 줄지, 파트너와 멤버 서식을 같게 할지도 그때그때 정하고 있었다. 시즌마다 답이 달랐다.

명찰을 코드로 옮기면서 그때그때 정하던 결정을 하나씩 글로 적었다.

따라 해보기

직접 반복하는 일이 있으면, 그 일을 남에게 시킨다고 생각하고 지시서를 한 장 써보면 된다. 쓰다 보면 내가 감으로 정하던 데가 어디였는지 드러난다. 거기가 바꿀 데다.

정원 20명에 댓글이 30개 달렸다. 위에서부터 세는 동안 댓글이 두 개 더 달린다. 다 세고 명단을 올리는 순간 이미 옛날 명단이다.

워크숍이나 특강처럼 빨리 여는 이벤트는 신청을 공지 댓글로 받았다. 폼을 쓸 때도 있지만, 공지를 본 곳에서 한 줄 쓰면 끝이니 폼보다 훨씬 많이 신청한다.

위에서부터 스무 명이 확정, 나머지가 대기다. 중간에 ‘취소할게요’가 섞여 있고 그 사람이 확정 안에 있었으면 대기 1번이 올라와야 한다. 직접 세면 몇 분 걸린다. 그래서 실제로는 마감 후에 한 번에 정리했다. 신청한 사람은 마감될 때까지 자기가 확정인지 대기인지 몰랐다. 인기 있는 건은 그게 며칠이었다.

결정할 것이 없는 일은 넘긴다

이 일에는 사람이 잘하는 데가 없다. 순서대로 세고 취소를 빼고 다음 사람을 올리는 것뿐이다.

그래서 봇(정해진 일을 자동으로 하는 프로그램)에게 넘겼다. 봇이 몇 분 간격으로 댓글을 읽어 신청 순서대로 정원까지 표시하고, 취소가 나오면 빼고 다음 사람을 올린다. 확정과 대기 명단을 공지에 갱신한다.

명단을 어디에 보여줄지도 한 번 고쳤다. 처음엔 봇이 스레드(공지 아래 달리는 댓글 묶음)에 댓글로 달게 했는데 신청 댓글 사이에 끼면서 지저분해졌다. 그래서 가능하면 공지 본문을 갱신하게 바꿨다. 공지를 열면 맨 위에 지금 명단이 있고 아래에 신청 댓글이 이어진다.

대기 3번이라는 정보

돌려 보고 예상 못 한 반응이 있었다. 대기자들이 좋아했다.

자기가 대기 3번인 걸 아는 것과 그냥 대기인 걸 아는 건 다르다. 3번이면 취소 세 개가 나오면 들어간다는 뜻이다. 기다릴지 다른 일정을 잡을지 정할 수 있다. 예전엔 이 정보를 우리만 갖고 있었다. 정확히는 우리도 마감 전엔 몰랐다.

자동화로 아낀 건 운영자의 시간만이 아니었다. 바빠서 못 알려주던 걸 멤버가 실시간으로 알게 됐다.

작은 걸 하나 더 붙였다. 이 자동화는 이벤트가 끝나면 스스로 멈춘다. 켜고 나중에 끄는 걸 반복하면 언젠가 끄는 걸 잊는다. 잊고 남은 자동화는 아무 일 안 하는 것처럼 보이다가 몇 달 뒤에 엉뚱한 공지를 건드린다.

따라 해보기

반복해서 순서를 세고 있다면, 그 일에 내 결정이 들어가는지 물어보면 된다. 안 들어가면 넘겨도 되는 일이다. 그리고 뭔가를 켤 때 끄는 방법을 같이 정해두면 된다.

후기가 늦어지는 건 쓰는 단계 때문이 아니었다. 초안은 이벤트 다음 날 나왔다. 멈춘 곳은 사진 이백 장에서 고르는 일과, 다 쓴 원고를 웹사이트 편집기로 옮기는 일이었다.

이벤트가 끝나면 녹취 파일(현장 대화를 녹음한 파일)이 하나 남는다. 그게 웹사이트에 후기로 올라가기까지 여섯 단계를 거친다. 녹취를 텍스트로 풀고, 초안을 쓰고, 사진을 고르고, 최종 원고를 다듬고, 웹사이트가 알아듣는 형식으로 바꾸고, 올린다.

멈추는 데는 늘 같았다

이 흐름을 몇 년 돌리는 동안 후기는 매번 같은 두 곳에서 멈췄다. 사진을 고르는 데와, 원고를 편집기가 알아듣는 모양으로 옮기는 데.

둘 다 결정할 것이 거의 없는 일이다. 사진은 그날 찍은 것 중에서 고르는 것이고, 형식 변환은 정해진 규칙대로 바꾸는 것이다. 그런데 직접 할 일이 많았다.

결정이 필요한 곳과 아닌 곳을 갈랐다

그래서 이 흐름을 하나로 묶으면서 각 단계에 표시를 했다. 사람이 결정해야 하는 단계와, 정해진 대로만 하면 되는 단계.

결정이 필요한 건 둘이다. 무엇을 쓸지 정하는 것과, 최종 원고를 읽고 이 문장을 내보내도 되는지 정하는 것. 발표자가 그날 한 말 중에 공개해도 되는 말과 그렇지 않은 말을 가르는 건 그 현장에 있던 사람만 한다.

나머지는 넘겼다. 사진은 촬영 시각과 일정을 맞춰 이벤트별로 먼저 나누고, 글의 대목과 어울리는 후보를 추려서 보여준다. 최종 선택은 내가 하지만 이백 장이 아니라 열 장 중에서 한다.

형식 변환은 통째로 넘겼다. 여기엔 결정할 것이 하나도 없다.

후기가 밀리지 않게 됐다

빨라지기도 했지만, 더 크게 달라진 건 이쪽이다. 예전에는 이벤트가 몰리는 주에 후기가 밀리면 그게 다음 주로 넘어가고, 넘어간 후기는 결국 못 썼다. 시간이 지나면 그날의 공기가 기억나지 않아서 쓸 수 없게 된다.

지금은 밀려도 초안이 남아 있다. 초안이 있으면 며칠 뒤에도 이어 쓸 수 있다.

따라 해보기

반복해서 만드는 결과물이 있다면, 그 과정을 단계로 적고 각 단계에 결정이 들어가는지를 표시해 보면 된다. 결정이 없는 단계에서 시간이 가장 많이 들고 있을 가능성이 높다.

2년 전에 나랑 같은 줄에 앉아 있던 사람이 지금 팀을 이끈다.

학습 커뮤니티를 한다고 하면 먼저 묻는 게 있다. 연사를 어떻게 섭외하느냐는 것이다.

이 질문에 오래 답하다 보니 우리가 실제로 하는 일과 조금 어긋나 있다는 생각이 들었다. 우리는 연사를 데려오는 것보다 파트너(팀 하나를 맡아 이끄는 진행자)를 키우는 쪽에 가깝다.

앞에 선 사람들이 원래 어디 있었나

지금 팀을 이끄는 파트너들의 이력을 거슬러 가보면 상당수가 멤버로 시작했다.

몇 시즌(석 달 단위 모임 기간) 동안 다른 팀에 참여하던 분이다. 토론에서 좋은 질문을 하고, 회고를 성실하게 쓰고, 다른 멤버 이야기에 반응한다. 그러다 자기 주제로 한 회차를 맡아본다. 잘되면 다음 시즌에 팀 하나를 맡는다.

이 경로가 우연히 생긴 게 아니다. 우리 팀 활동은 파트너가 강의하는 형태가 아니라 멤버가 돌아가며 진행하는 형태다. 토론을 멤버가 직접 이끌 수 있게 따로 안내한다. 모든 멤버가 매 시즌 진행 연습을 하고 있는 셈이고, 그러다 보면 잘하는 사람이 보인다.

밖에서 오면 그날로 끝난다

유명한 분을 모시면 그 회차는 잘된다. 사람이 많이 오고 반응도 좋다. 그런데 그 다음이 없다. 그분은 자기 일로 돌아가고 우리에겐 그날의 기억만 있다.

안에서 자란 파트너는 다르다. 이 커뮤니티가 어떻게 굴러가는지, 멤버들이 어떤 사람이고 어떤 대화를 좋아하는지 이미 안다. 설명이 필요 없다.

그리고 그분이 앞에 서 있는 걸 다른 멤버들도 본다. 같은 줄에 앉아 있던 사람이 팀을 이끄는 모습은 어떤 홍보 문구보다 세다.

다만 방치해도 되는 일은 아니다. 멤버가 진행을 연습할 기회가 있어야 하고, 잘하는 사람이 눈에 띄어야 한다. 회고와 후기 같은 기록이 없으면 누가 어떤 이야기를 했는지 몇 시즌 뒤엔 아무도 모른다.

무엇보다 운영자가 앞에 서고 싶은 마음을 눌러야 한다. 오래 하면 내가 제일 잘 안다고 느끼는 순간이 온다. 그때 내가 앞에 서기 시작하면 멤버가 앞에 설 기회가 하나 없어진다.

따라 해보기

팀이나 모임을 운영한다면, 지금 앞에 서는 사람 말고 다음에 설 사람이 누구인지 이름을 써보면 된다. 안 떠오르면 아직 그런 기회를 안 만든 것이다.

회고를 쓰려면 링크를 찾고, 문서를 열고, 이번 회차 칸을 확인하고, 없으면 만들어야 했다. 모임이 끝난 직후 피곤한 사람에게 이 네 단계는 높은 벽이었다.

모임이 끝나면 흩어진다. 두 시간 동안 좋은 이야기가 오갔는데 일주일 지나면 뭐였는지 흐릿하다.

그래서 회고를 넣었다. 네 칸이다. 좋았던 것, 배운 것, 아쉬웠던 것, 바라는 것.

쓰기까지 네 단계가 있었다

회고를 해본 사람은 알겠지만 양식 만들기는 쉽고 계속 쓰게 하기는 어렵다. 처음 몇 회차는 잘 쓴다. 그러다 한 주 빠지고, 다음 주엔 지난주 것도 안 썼으니 이번 것도 안 쓰고, 없어진다. 우리도 몇 번 그렇게 흐지부지됐다. 원인을 찾다가 앞의 네 단계를 알게 됐다.

쓰라고 하는 대신 쓸 칸을 깔아뒀다

시즌(3개월 단위 모임 기간)이 시작되면 모든 팀 모든 회차 칸을 한 번에 만든다. 6회차면 6개가 미리 생긴다. 그리고 회차 당일 아침에 그 회차 칸에 멤버 각자의 칸이 자동으로 생긴다. 자기 이름이 붙은 빈칸이 이미 있는 상태다.

이 차이가 컸다. 빈 문서에 처음부터 쓰는 것과 내 이름이 붙은 빈칸을 채우는 건 다른 일이다. 뒤쪽은 안 채우면 비어 있는 게 보인다.

회고 칸은 원래 슬랙(업무용 메신저) 공지가 올라가야 만들어졌다. 공지를 깜빡하거나 늦게 올리면 회고 칸도 같이 밀렸다. 이걸 모임 일정에 맞춰 만들어지게 바꿨다.

한 가지 제약이 있었다. 우리가 쓰는 슬랙 요금제에서는 독립된 문서를 자유롭게 못 만든다. 처음엔 한계로 봤는데 대안으로 찾은 방식이 오히려 나았다. 팀 채널(팀마다 따로 있는 대화방) 위쪽 탭에 회고를 붙이는 방식이다. 팀 채널을 열면 항상 보이니 링크를 기억할 필요가 없다.

회고가 하는 일

멤버에게는 참여한 시간이 기록된다. 시즌이 끝나면 6주 동안 뭘 배웠는지 한 화면에서 본다. 팀에는 다음 회차를 고칠 근거가 생긴다. 아쉬웠던 것에 같은 말이 세 번 나오면 그건 고쳐야 하는 것이다.

나에게는 다른 값이 있다. 만족도 조사는 끝나고 받지만 회고는 모임 직후 바로 쓴다.

따라 해보기

팀에서 회고가 자꾸 흐지부지된다면, 사람을 독려하는 대신 쓸 칸을 미리 만들어두면 된다. 이번 주 것이 이미 열려 있고 내 이름 칸이 비어 있으면 대부분 채운다.

한 시즌(모집 한 번에 열리는 모임 기간) 쉬고, 두 시즌 쉬고, 그러다 안 오게 된 분들이 있다. 이분들에게 연락을 하기로 했는데 첫 문장에서 막혔다.

오랜만이라는 말도 어색하고, 다시 오시라는 말은 너무 이르다. 한 통에 안부와 소식과 초대를 다 넣으면 그건 광고 메일이 된다.

한 통을 네 통으로 나눴다

그래서 나눴다.

첫 통은 안부만 묻는다. 아무것도 팔지 않는다. 닷새 뒤 두 번째 통에 콘텐츠를 하나 보낸다. 그동안 우리가 만든 것 중 이분이 관심 있을 만한 것. 여기서도 등록 이야기는 안 한다. 열흘째 세 번째 통에 이벤트를 하나 소개한다. 시즌 등록이 아니라 단발 이벤트다. 문턱이 낮고 와서 보고만 가도 된다. 열여드레째 마지막 통에 다음 시즌 이야기를 한다.

이렇게 나눈 이유는 우리가 팔고 싶은 것을 마지막에 두기 위해서다. 앞의 세 통이 없으면 마지막 통은 갑자기 온 광고가 된다.

메일은 되돌릴 수 없어서 보낼 때마다 멈춘다

이 캠페인에는 단계마다 멈추는 곳을 넣었다.

발송 프로그램이 회차마다 받을 사람 명단을 먼저 뽑아서 보여준다. 그 다음 본문을 미리보기로 보여준다. 내가 확인하고 좋다고 해야 발송이 시작된다. 네 통이면 이 절차를 네 번 거친다.

번거로운데 이 순서는 안 줄였다. 메일은 한 번 나가면 회수가 안 된다. 슬랙(업무용 메신저) 메시지는 지울 수라도 있지 메일은 그것도 안 된다.

그리고 이 캠페인의 대상은 이미 우리에게서 멀어진 분들이다. 여기서 한 번 더 잘못 보내면 그게 마지막 접점이 된다.

아직 직접 하는 일

정직하게 적어 두면, 이 캠페인은 아직 완전히 굴러가지 않는다. 발송은 자동으로 되는데, 결과를 추적하는 일은 아직 자동으로 되지 않는다. 누가 열었고 누가 눌렀는지는 내가 직접 시트(표 파일)에 옮기고 있다.

그래서 이 방식이 실제로 효과가 있는지를 아직 숫자로 말할 수 없다. 말할 수 있게 되면 그때 다시 쓰겠다.

따라 해보기

한동안 안 온 고객에게 연락할 일이 있다면, 한 통에 다 담지 말고 목적이 다른 여러 통으로 나눠 보면 된다. 그리고 첫 통에서는 아무것도 팔지 않는다.

저자 북토크, 브랜드 토크, 밋업 같은 이벤트를 한 시즌(모집 한 번에 열리는 모임 기간)에 스무 번쯤 연다. 이벤트마다 챙길 일은 명령(AI에게 빗금 뒤 이름 하나로 정해 둔 일을 시키는 지시서)으로 다 만들어 뒀다. 그런데도 자꾸 깜빡했다.

이벤트 하나에 챙길 일이 여러 개다. 발표자에게 등록자 정보를 보내고, 확정자와 대기자를 공지 스레드(공지 메시지 아래에 달리는 답글 묶음)에 발표하고, 시작 전에 도착을 확인하고, 끝나면 출석에 반영하고 후기를 쓴다.

도구가 있어도 언제 쓸지를 기억해야 했다

명령이 있다는 것과 그걸 제때 쓰는 것은 다른 일이었다.

발표자 브리핑은 이벤트 일주일 전쯤 보내야 한다. 확정자 발표는 전날이나 당일 오전이다. 도착 확인은 시작 30분 전이다. 시점이 다 다르고, 이벤트가 스무 개면 각각 다른 단계에 있다.

그래서 오늘 무엇을 해야 하는지 알려면 이벤트 목록을 놓고 각각 지금이 며칠 전인지 계산해야 했다. 그 계산을 매일 아침에 하지는 않았다. 뭔가 놓친 걸 발견한 날에 했다.

이벤트 이름만 말하면 되게 했다

그래서 흐름으로 묶었다.

명령을 실행하면 먼저 캘린더에서 다가오는 이벤트를 찾아 목록으로 보여준다. 하나를 고르면 지금 어느 단계를 할지 물어본다. 발표자 브리핑인지, 확정자 발표인지, 도착 확인인지.

내가 하는 건 이벤트를 고르고 단계를 고르는 것뿐이다. 각 단계가 무엇을 해야 하는지는 흐름 안에 들어 있다.

이렇게 만든 이유가 명령 설명에 그대로 적혀 있다. 개별 명령을 깜빡하지 않고 흐름으로 챙기기 위한 것이라고.

도구를 늘리면 기억할 것도 늘어난다

이 일에서 알게 된 게 하나 있다.

자동화를 하면 일이 줄어든다고 생각하는데, 도구가 열 개를 넘어가면 새로운 부담이 생긴다. 어떤 도구가 있는지, 그걸 언제 쓰는지를 기억해야 한다.

그래서 도구를 여러 개 만든 다음에는 그것들을 언제 쓰는지 알려주는 것을 하나 더 만들어야 했다. 도구 열 개보다 순서를 아는 도구 하나가 실제로는 더 자주 쓰인다.

따라 해보기

만들어 둔 도구나 체크리스트를 자꾸 안 쓰게 된다면, 그것들을 시점 순서로 다시 늘어놓아 보면 된다. 지금이 어느 시점인지만 알면 무엇을 할지가 정해진다.

그동안 연 팀 137개를 읽는 팀과 쓰는 팀으로 나눠 봤다. 오래 참여한 멤버 상당수가 한쪽에만 몰려 있었다.

한 시즌(모집 한 번에 열리는 모임 기간)을 마친 멤버가 다음에 뭘 들을지 고른다. 열여덟 개 팀이 있고 설명은 다 그럴듯하다.

추천을 만들었는데 처음엔 쉬운 것부터 했다. 인기 있는 팀을 위에 놓기. 도움이 안 됐다. 인기 팀은 이미 다들 안다. 다음으로 비슷한 주제를 권했다. 마케팅을 들었으면 마케팅을. 이것도 문제가 있었다. 같은 방향으로만 계속 가게 된다.

주제 말고 다른 축을 찾았다

팀을 주제 대신 활동의 성격으로 나눠 보니 선이 하나 보였다.

읽고 듣고 보고 탐색하는 팀이 있다. 책을 읽고 이야기하고, 사례를 보고, 남의 방식을 배운다. 인풋(새로 받아들이는 것)이 들어오는 시간이다. 반대로 쓰고 만들고 정리하는 팀이 있다. 에세이를 쓰고 자기 문제를 정의하고 결과물을 낸다. 아웃풋(밖으로 내놓는 결과물)이 나오는 시간이다.

137개를 이 축(팀을 나누는 기준)으로 다 나누고 멤버들의 등록 이력을 얹어 봤다.

인풋만 계속한 사람은 아는 게 많아진다. 그런데 자기 언어로 정리된 게 없다. 좋은 이야기를 많이 들었는데 뭐가 남았는지 말하기 어려운 상태다. 아웃풋만 한 사람은 계속 만들어 낸다. 그런데 재료가 떨어진다. 자기 안에 있는 걸 계속 꺼내면 어느 순간 새로울 게 없다.

그래서 직전 시즌이 인풋이었으면 다음은 아웃풋 쪽을 먼저 권하기로 했다.

화면은 그대로 두고 이유만 바꿨다

여기서 한 번 헛발질했다. 축을 발견하고 신나서 멤버가 지금까지 어느 쪽 팀을 거쳐 왔는지 보는 그래프를 만들었다. 보여줬더니 반려됐다.

맞는 결정이었다. 멤버는 자기 학습 이력을 분석하러 오는 게 아니다. 다음에 뭘 들을지 고르러 온다. 화면에 개념이 하나 늘면 고르는 일이 어려워진다.

화면은 원래대로 두고 추천 순서와 이유 문구에만 반영했다. 지난 시즌에 읽고 나누는 시간을 보내셨으니 이번엔 직접 써 보는 팀을 권합니다, 같은 한 줄로.

작업 중에 하나를 더 발견했다. 대상으로 잡은 멤버 150명은 모두 이번 시즌 팀을 이미 듣고 있었다. 그런데 페이지는 이 멤버들에게 이번 시즌 팀을 권하고 있었다. 권해야 할 건 다음 시즌이었다.

따라 해보기

추천이나 다음 단계를 제안하는 일이 있으면, 인기순이나 비슷한 주제순 말고 축을 하나 찾아보면 된다. 그 사람이 직전에 어느 쪽에 있었는지 보고 반대쪽을 먼저 권한다. 그리고 기준 시점이 지금인지 다음인지 꼭 확인한다.

7년 동안 쌓인 업무 대화를 한 번 훑어봤다. 어떤 이야기가 자주 나왔는지 세어 보고 싶었다.

그러다 이상한 걸 봤다. 인터뷰 시리즈를 하자는 말이 스물네 번 나왔다. 2020년 1월에 꾸준히 무언가를 하는 사람들을 인터뷰하자는 기획이 있었다. 같은 달에 직장인 이야기를 영상으로 만들자는 이야기도 나왔다. 2024년 3월에는 구체적인 기획안까지 나왔다.

한 번도 하지 않았다.

안 한 일에도 목록이 있다

세보니 이런 게 더 있었다. 유튜브는 일곱 번 언급됐고 안 했다. 뉴스레터는 네 번, 팟캐스트는 세 번 언급됐고 안 했다. 고객 관리 시스템을 도입하자는 논의는 2021년에 있었고 안 했다.

처음에는 이 목록이 부끄러웠다. 말만 하고 안 한 게 이렇게 많구나 싶었다.

그런데 며칠 두고 보니 다르게 읽혔다. 스물네 번 나왔다는 건 6년 동안 그 생각이 계속 돌아왔다는 뜻이다. 한두 번 나오고 사라진 아이디어가 아니다. 계속 필요하다고 느꼈고, 계속 못 했다.

계속 못 했다면 이유가 있다. 그리고 그 이유가 의지 부족이 아닐 가능성이 높다. 6년 동안 스물네 번이나 다시 떠올릴 만큼 마음이 있었으니까.

왜 못 했는지를 적어두기로 했다

돌아보면 이 일들의 공통점이 있었다. 전부 새로운 반복을 요구한다. 인터뷰 시리즈는 한 편 만들고 끝이 아니라 계속 나가야 하고, 뉴스레터도 팟캐스트도 그렇다.

그리고 그때마다 우리는 이미 돌아가고 있는 반복만으로도 벅찼다. 시즌은 3개월마다 오고 이벤트는 매달 있다. 새 반복을 얹을 여유가 없었다.

그러니까 이건 아이디어 문제가 아니라 여유 문제였다. 그동안 우리는 매번 다시 기획안을 썼다. 기획이 부족해서 못 한 게 아닌데.

지금은 하고 싶은데 못 한 일에 이유를 같이 적어둔다. 나중에 이 이야기가 또 나오면 기획안을 새로 쓰는 대신 그 이유를 먼저 본다. 그 이유가 해결됐으면 하는 거고, 그대로면 이번에도 안 하는 게 맞다.

따라 해보기

지난 몇 년 동안 반복해서 나왔는데 아직 안 한 일을 하나 써보면 된다. 그리고 왜 못 했는지를 한 줄 옆에 쓴다.

두 팀에 30명이 몰렸다. 나머지 열아홉 팀은 합쳐서 70명, 팀 평균 3.7명이었다.

한 시즌(석 달 단위 모임 기간) 성적표를 보면 잘된 팀과 그렇지 않은 팀이 있다. 잘된 쪽을 늘리고 부진한 쪽을 정리하는 게 자연스러운 결론이다.

그런데 그 시즌 성적을 카테고리로 묶어 보고 생각이 달라졌다.

두 팀이 15명, 열아홉 팀이 3.7명

30명이 몰린 두 팀은 같은 주제였다. 팀 평균 15명. 둘 다 정원이 일찍 찼고, 한 팀은 네 시즌 연속 마감이었다.

나머지 열아홉 팀에는 조기 마감이 하나도 없었다.

이 두 줄을 한참 봤다. 팀 평균 3.7명은 시즌 운영이 성립하지 않는 숫자다.

그리고 예전에 마감 단골이던 팀들을 찾아봤다. 세 개가 있었는데 전부 사라졌거나 부진했다. 그 빈 곳을 한 카테고리가 메우고 있었다.

잘되는 걸 늘리는 게 답이 아니었다

처음 든 생각은 잘되는 카테고리를 늘리자는 것이었다. 입문과 중급과 심화로 나눠서 세 팀으로 만들면 정원이 더 생긴다.

그런데 그렇게 하면 이 커뮤니티가 한 주제만 남는 곳이 된다. 그리고 그 주제의 유행이 지나면 통째로 흔들린다.

동시에 부진한 열아홉 팀을 그냥 두는 것도 답이 아니었다. 이 팀들은 몇 시즌째 같은 모양으로 열리고 있었다. 팀의 수명은 세 시즌이다에서 쓴 것처럼 세 시즌이 넘으면 그 주제를 원하던 사람은 이미 다 거쳐 갔다.

그래서 결론이 둘로 나뉘었다. 잘되는 쪽은 단계를 나눠 늘리되, 부진한 쪽은 줄이는 게 아니라 다시 만들어야 한다는 것.

성적표를 팀 단위로만 보면 이게 안 보인다. 잘된 팀 두 개와 못한 팀 열아홉 개로 보인다. 카테고리로 묶는 순간 팀 구성이 한 주제에 쏠려 있었다는 게 드러난다.

따라 해보기

상품이나 서비스 목록을 성적순으로 보고 있다면, 그걸 카테고리로 묶어서 다시 정렬해 보면 된다. 상위 하나를 빼고 나머지 평균을 내본다.

2019년 우리 업무 대화에서 가장 자주 나온 단어에는 콘텐츠와 커뮤니티가 있었다. 2025년에는 대신 등록과 재등록(한 번 참여한 멤버가 다음 모집에 다시 신청하는 것)이 들어와 있었다. 아무도 그렇게 하자고 정한 적이 없다.

업무 대화 7년치를 연도별로 나눠서 가장 자주 나온 단어를 뽑아 봤다.

2019년은 멤버, 시즌, 콘텐츠, 커뮤니티, 파트너, 세션이었다. 2020년에는 온라인이 들어왔다. 2021년에는 성장과 리더가 올라왔고, 2022년에는 브랜드와 후기가 있었다.

2025년과 2026년은 멤버, 시즌, 등록, 재등록, 성장, 세션이다.

콘텐츠와 커뮤니티가 사라졌다

이 표를 한참 봤다. 회의에서 이제부터 등록 이야기를 더 하자고 정한 사람이 없다. 그냥 매년 조금씩 그렇게 됐다.

이유는 짐작이 간다. 신규 유입이 줄고 재등록 비중이 늘면서 그 숫자가 매일의 걱정이 됐다. 걱정하는 것을 말하게 되고, 말하는 것이 그 조직의 언어가 된다.

문제는 이게 순환한다는 것이다. 등록을 걱정하면 등록 이야기를 하고, 등록 이야기를 하면 등록을 늘리는 방법을 기획하고, 그러면 콘텐츠는 등록을 위한 수단이 된다. 그리고 수단이 된 콘텐츠는 대체로 재미가 없다. 재미없는 콘텐츠는 등록을 못 늘린다.

걱정은 정확한데 언어가 좁다

등록을 걱정하는 게 틀린 건 아니다. 숫자가 실제로 나빠지고 있었다. 문제는 언어가 좁아진 것이다. 등록이라는 말로만 이야기하면 답도 등록을 늘리는 방법 안에서만 나온다. 할인, 마감 임박 안내, 추천 이벤트. 이런 것들이 나쁘진 않은데 이걸로 커뮤니티가 좋아지지는 않는다.

7년 전에 우리가 콘텐츠와 커뮤니티라는 말을 자주 썼을 때, 등록은 그 결과로 따라오는 것이었다. 순서가 뒤집힌 게 언제인지 아무도 모른다.

이 표를 만들고 나서 회의에서 의식적으로 다른 단어를 꺼내려고 한다. ‘이번 시즌에 멤버가 무엇을 얻어 가는가.’ 이 질문이 등록 숫자보다 먼저 나와야 한다고 생각한다.

따라 해보기

지난 몇 년의 회의록이나 업무 대화에서 해마다 자주 나온 단어를 세보면 된다. 목록이 좁아졌으면, 그동안 조직이 무엇을 걱정해 왔는지가 그대로 보인다.

없던 걸 만드는 재능이 있는 사람들이 있다. 그건 내 재능이 아니다. 내가 하는 일은 이미 있는 모임을 다음 시즌(석 달 단위 모임 기간)에도 있게 만드는 것이다. 화려하지 않고 성과로 말하기도 어렵다. 잘한 해에는 아무 일도 안 일어난 것처럼 보인다.

모임을 만들고 싶어 하는 사람을 자주 만난다. 그분들에게 필요한 정보는 어렵지 않게 구할 수 있다. 어떻게 시작하는지, 첫 멤버를 어떻게 모으는지. 이 주제로 쓰인 글이 많다.

그런데 두 번째 모임, 열 번째 모임, 3년째 모임 이야기를 해주는 곳은 드물다.

시작은 에너지로 되고 지속은 구조로 된다

첫 모임은 대체로 잘된다. 만드는 사람의 열의가 있고 오는 사람도 새로운 걸 기대한다. 준비가 부족해도 그 에너지가 메운다.

문제는 그 다음이다. 열의는 반복을 못 견딘다. 같은 준비를 열두 번째 하고 있으면 처음의 마음이 없다. 사람이 원래 그렇다.

그래서 지속은 다른 걸로 굴러가야 한다. 매번 하는 일을 목록으로 적고, 순서를 정하고, 빠지기 쉬운 데를 표시하고, 확인 절차를 만드는 것. 창의적이지 않다. 아주 지루하다. 그런데 이걸 안 하면 3년째에 사라진다.

계속 운영하면 무엇이 무거워지는지 적어 보면 이렇다. 먼저 기대치가 올라간다. 첫 시즌엔 모여서 이야기한 것만으로 좋았는데, 열 번째 시즌 멤버는 우리가 원래 어느 정도인지 알고 온다. 같은 걸 해도 평가가 다르다. 3년째 오는 멤버에게 매번 다음 것을 줘야 한다.

그리고 잘된 것도 늙는다. 성공한 기획일수록 언제 접을지를 정해둬야 하는데 이게 제일 어렵다.

계속할 수 있나

그래서 새로운 걸 제안받거나 아이디어가 떠오르면 항상 같은 질문을 먼저 한다. 이걸 계속할 수 있나.

한 번 하고 끝날 기획이면 안 한다. 아무리 좋아 보여도. 한 번 하고 끝난 기획은 멤버를 실망시키기 때문이다. 멤버는 그게 계속될 거라 기대했다가 안 이어지는 걸 보고, 이 커뮤니티가 벌여놓고 마무리를 안 한다고 느낀다.

반대로 작아도 계속되는 건 시간이 지날수록 세진다. 매주 일요일 밤에 멤버에게 보내는 레터가 그렇다. 대단한 콘텐츠가 아닌데 몇 년째 같은 시각에 오니까 멤버들에게 이 커뮤니티의 시간표가 됐다.

따라 해보기

새로 시작하려는 게 있다면 시작 방법 말고 열두 번째를 먼저 그려보면 된다. 열두 번째에도 이걸 같은 품질로 할 수 있는지. 못 하겠으면 규모를 줄여서 시작하는 게 낫다.

비슷한 주제의 팀 셋을 같은 시즌에 열었다. 등록은 4명, 2명, 1명으로 전부 미달(성공 기준에 못 미침)이었다. 합치면 7명, 우리 기준으로 성공에 해당하는 숫자다.

우리는 시즌(모집 한 번에 열리는 모임 기간)마다 열여덟에서 스무 개 팀을 연다. 주제를 정할 때는 각 팀을 따로 본다. 이 주제가 지금 필요한가, 이 파트너(팀 하나를 맡아 이끄는 사람)가 잘할 수 있는가.

우리는 다르다고 생각했다

기획할 때 우리는 세 팀이 다르다고 봤다. 하나는 실패 사례를 다루는 책을 읽고, 하나는 고전을 읽고, 하나는 아티클을 읽는다. 우리 안에서는 구분이 명확했다.

등록하려는 사람 입장에서 보니 셋 다 같은 문장이었다. 경영 관련 책을 읽고 이야기하는 모임. 차이를 알려면 상세 페이지 셋을 다 열어서 비교해야 했다.

그리고 사람은 그렇게까지 하지 않는다. 셋 중에 뭘 골라야 할지 모르면 아무것도 안 고른다. 선택지가 많으면 팔린다는 건 우리 쪽 착각이었다.

거기에 하나 더 있었다. 세 팀 중 둘을 같은 파트너가 맡고 있었다. 우리 딴에는 그 분야를 잘 아는 분이라 두 팀을 부탁한 건데, 결과적으로 그분의 준비 시간이 반으로 갈렸다.

팀 단위가 아니라 시즌 단위로 본다

이 뒤로 라인업(그 시즌에 여는 팀 목록)을 짜는 방식을 바꿨다.

팀 하나하나를 승인하는 방식으로 짜면 이런 일이 반복된다. 각각은 다 말이 되기 때문이다. 그래서 전부 정한 다음에 한 번 더 본다. 열여덟 개를 늘어놓고 등록하려는 사람 눈으로 읽는다. 여기서 둘이 헷갈리면 하나로 합치거나 하나를 뺀다.

그리고 한 파트너에게 한 시즌에 한 팀만 부탁한다.

시즌 전체를 한 번에 놓고 보면 당연한 이야기인데, 팀 단위로 결정하는 동안에는 안 보인다.

따라 해보기

지금 팔고 있는 것들을 한 화면에 늘어놓고 이름만 읽어보면 된다. 처음 보는 사람이 둘을 헷갈릴 것 같으면 그 둘은 서로 손님을 나눠 갖는 중이다.

비기술 직군을 위한 AI 학습 팀을 2024년 봄 시즌(석 달 단위로 여는 모임 기간)부터 열두 반 운영하며 같은 장면을 봤다. 대부분은 필요할 때 AI를 열어 하나 물어보고 닫았다. 마케터, 기획자, HR(인사), 영업. 뉴스는 봤고 한두 번 써봤는데 그게 일이 되지는 않았다. 소수만 일을 시작할 때부터 AI를 옆에 뒀다.

도구라고 부르면 도구처럼 쓴다

몇 시즌 관찰하고 알았다. AI를 도구라고 생각하는 사람은 도구처럼 쓴다. 번역기나 계산기 쓰는 방식이다. 이렇게 쓰면 시간이 조금 절약되고 끝이다.

옆에 둔 소수는 뭘 할지 모르는 상태에서 같이 정리하고, 초안을 받아 고치고, 놓친 게 없는지 물어봤다. 결과물의 질이 확실히 달랐다. 차이는 AI와의 관계 설정에 있었다.

그래서 이름을 바꿔봤다. 도구 말고 부사수.

부사수는 나보다 경험이 적다. 우리 회사 사정을 모르고 지난주에 무슨 일이 있었는지 모른다. 그래서 일을 시킬 때 배경을 설명해야 한다. 결과물을 받으면 검토해야 한다. 틀린 걸 그대로 내보내면 확인 안 한 내 잘못이다. 그래도 부사수는 사정을 알려주면 스스로 결정한다.

이 이름을 쓰기 시작하니 참여자들의 행동이 바뀌었다. 배경을 설명하기 시작했고, 결과를 검토하기 시작했고, 한 번에 완벽한 답을 요구하는 대신 몇 번 주고받기 시작했다.

자기 업무를 뜯어보는 일

팀에서는 자기 일 중에 뭘 AI에게 넘길 수 있는지 정하는 것부터 시작한다. 그리고 실제로 굴러가는 걸 만든다. 뉴스를 정리해 리포트로 내는 일, 데이터를 분석하는 일, 콘텐츠를 만드는 일.

목표는 자기 업무에서 반복되는 구간을 한 번 찾아보는 것이다. 한 번 찾아낸 사람은 그 다음부터 혼자 한다. 참여자의 80퍼센트 이상이 배운 걸 실제로 적용했는데, 각자 자기 업무를 재료로 썼기 때문이라고 생각한다.

기대 안 했던 결과도 있다. 시즌이 끝나고도 계속 연결돼 있다. 새 도구가 나오면 서로 알려주고 자기가 만든 걸 공유한다. 이 분야는 변화가 빨라서 한 시즌에 배운 게 반년이면 낡는데, 같이 배운 사람들이 남아 있으면 그 낡음을 서로 메워준다.

그래서 이 팀의 성과를 시즌이 끝난 뒤에도 서로 새 도구를 알려주는지로 보게 됐다.

따라 해보기

AI를 쓰고 있다면 다음에 일을 시킬 때 배경부터 세 줄 써보면 된다. 지금 뭘 하는 중이고, 누가 볼 거고, 뭘 피하고 싶은지. 같은 질문이라도 답이 달라진다.

우리 프로그램은 4년에서 7년차 직장인을 겨냥해 만들었다. 실제로 온 신규 멤버 네 명 중 그 연차는 한 명뿐이었다.

4년에서 7년차는 실무는 익숙해졌는데 다음 단계가 안 보이는 구간이다. 이 사람들에게 필요한 게 뭔지를 놓고 팀을 기획했다. 그리고 한 시즌(모집 한 번에 열리는 모임 기간)을 정리하면서 실제로 온 사람들의 연차를 세봤다.

겨냥한 구간의 적중률이 27퍼센트였다

새로 온 멤버의 연차 중앙값(연차순으로 줄 세웠을 때 한가운데 사람의 연차)이 8년이었다. 4에서 7년차 비율은 29.6퍼센트. 다섯 시즌 평균으로 봐도 27.3퍼센트다. 가장 많이 들어오는 구간은 8에서 10년차로 신규의 48퍼센트였다.

재등록(한 번 참여한 멤버가 다음 시즌에 다시 신청하는 것) 멤버는 더 위였다. 중앙값 12년. 이건 당연하다. 오래 다닌 분들이 재등록을 하니 시즌을 거듭할수록 커뮤니티 평균 연차가 저절로 올라간다.

겨냥하지 않은 연차대에 가장 많이 팔리고 있었다.

두 갈래 중 하나를 골라야 했다

이런 걸 발견하면 보통 두 가지 반응이 나온다. 타겟이 안 맞으니 마케팅을 고치자, 아니면 실제 고객에 맞춰 상품을 고치자.

우리가 정리한 선택지도 그 둘이었다. 겨냥 구간을 4에서 10년차로 넓히거나, 4에서 7년차만을 위한 팀을 난이도와 가격을 달리해서 따로 만들거나.

둘 다 비용이 있다. 넓히면 우리 프로그램이 누구를 위한 것인지가 흐려진다. 따로 만들면 팀이 하나 늘고 그 팀은 시드(처음부터 등록해 줄 기존 멤버)가 없는 상태로 시작한다.

어느 쪽을 고르든, 먼저 이 어긋남을 알고 있어야 고를 수 있었다. 그 전까지 우리는 4에서 7년차용 문구로 홍보하면서 8에서 10년차에게 팔고 있었다. 아무도 그걸 몰랐다. 마케팅 문구는 오지 않는 사람을 향해 쓰여 있었고, 실제로 오는 사람은 그 문구를 자기 이야기로 안 읽으면서도 등록했다.

따라 해보기

우리 고객이 누구라고 말할 때 쓰는 문장을 하나 써보면 된다. 그리고 실제 고객 명단에서 그 조건에 맞는 사람이 몇 퍼센트인지 센다. 두 숫자가 크게 다르면 그게 다음 기획의 재료다.

처음으로 재등록한 23명은 한 명도 빠짐없이 이전과 다른 팀을 골랐다. 여러 번 재등록한 79명도 93.7퍼센트가 매 시즌 팀을 바꿨다.

우리 커뮤니티는 석 달 단위 시즌마다 팀을 새로 열고, 지난 시즌 멤버가 다시 신청하는 걸 재등록이라고 부른다. 팀 하나가 잘되면 그 팀 멤버들이 다음 시즌에도 그 팀에 온다고 생각했다. 그래서 팀별 재참여율을 성과 지표로 봤다.

한 시즌의 재등록 멤버들이 어느 팀을 골랐는지 실제로 세봤다.

93.7퍼센트가 다른 팀을 골랐다

처음 재등록한 사람은 100퍼센트가 팀을 바꿨다. 여러 번 재등록한 사람 중 같은 팀에 남는 비율은 6.3퍼센트였다.

한 멤버가 평균 6.9시즌을 참여하고 매번 다른 팀을 고른다. 한 사람이 일곱 개 가까운 주제를 거쳐 간다는 뜻이다.

그러니까 팀 유지율이라는 지표 자체가 우리 커뮤니티에서는 의미가 없었다. 그 숫자가 낮은 건 원래 그렇게 쓰는 곳이기 때문이다.

무엇을 파는지가 달라졌다

이걸 알고 나서 우리가 파는 게 뭔지 다시 생각했다.

멤버는 이 팀의 콘텐츠를 사는 게 아니었다. 매 시즌 새로운 주제를 안전하게 시도할 수 있는 기회를 사고 있었다. 아는 사람들이 있고 진행 방식이 익숙해서 이번엔 다른 걸 해봐도 되는 곳.

그렇다면 개별 팀의 완성도만큼 매 시즌 라인업(한 시즌에 여는 팀 목록)이 충분히 다양한지가 중요해진다. 비슷한 주제만 여덟 개 열면 멤버는 갈 데가 없다. 팀 하나하나는 좋은데 커뮤니티는 정체된다.

실제로 이 관점으로 다시 보니 이해되는 게 있었다. 직전 시즌에서 바로 넘어온 첫 재등록 멤버 16명 중 6명이 다른 주제 팀에서 AI 팀으로 옮겨 갔다. 그 팀은 신규를 거의 못 데려오는데 기존 멤버가 다음 단계로 갈 때 고르는 팀이었다. 우리는 그 팀을 신규 유입이 없다는 이유로 낮게 보고 있었다.

따라 해보기

같은 고객이 두 번째로 살 때 처음과 같은 걸 사는지 다른 걸 사는지 세보면 된다. 다른 걸 산다면 상품 하나보다 라인업 전체를 관리해야 한다.

한 팀은 13명에서 15명으로 올랐다가 7명, 5명으로 떨어졌다. 주제도 좋았고 파트너(팀 하나를 맡아 이끄는 사람)도 좋았다.

뭐가 잘못됐는지 찾게 된다. 파트너가 달라졌나, 요일이 안 좋았나, 홍보가 부족했나. 매번 이유를 찾아 고쳤는데 그 팀은 계속 내려갔다.

여러 팀이 같은 모양이었다

지난 7년치 등록을 시즌(3개월 단위 모임 기간)별로 펼쳐 봤다. 팀마다 시즌별 인원을 죽 늘어놓았다. 세 시즌 이상 운영한 팀 중 75퍼센트가 내려가는 추세였다.

앞의 팀만 그런 게 아니었다. 다른 팀은 15, 15, 13, 7, 6이었다. 두 팀 다 첫 두 시즌은 성공한 팀으로 분류돼 있었다.

여러 팀에서 같은 모양이 반복되는 걸 보고 해석이 바뀌었다.

첫 시즌은 새롭다. 두 번째는 소문이 돌아 오히려 더 온다. 세 번째부터는 이 주제에 관심 있는 사람이 이미 대부분 거쳐 갔다. 하락은 그 주제를 원하던 사람을 다 만나서다.

그동안 우리가 왜 헛돌았는지 알겠다. 계속 팀을 개선하고 있었다. 커리큘럼을 다듬고 파트너를 바꾸고. 문제는 팀의 질이 아니라 팀의 나이였다.

세 번째 시즌에 알람을 걸었다

세 번째 시즌에 들어가는 팀은 자동으로 검토 대상이 된다. 네 번째면 졸업하거나 콘셉트를 바꾼다.

숫자와 상관없이 세 시즌이 되면 검토한다. 숫자가 나빠지길 기다리면 늦다. 등록이 반토막 난 시즌은 그 팀에 온 멤버에게도 나쁜 경험이다. 인원이 적으면 토론이 안 되고, 후기가 나빠지고, 다음 시즌은 더 안 온다.

잘될 때 접는 결정을 해야 하는데 이건 감정적으로 어렵다. 그래서 규칙으로 걸었다.

표현도 하나 정했다. 폐지가 아니라 졸업이라고 부른다. 말장난 같지만 다르게 작동했다. 폐지는 실패의 뜻이 있고, 그 팀을 만든 사람과 참여한 멤버에게 실패라고 말하는 셈이 된다. 졸업은 할 일을 다 했다는 뜻이다.

실제로 졸업한 팀의 파트너와 멤버가 다음 팀으로 이어졌다. 어떤 분은 다른 주제의 파트너가 됐고 어떤 분은 새 팀의 첫 멤버가 됐다.

따라 해보기

오래 해온 것이 있다면, 시작한 뒤 몇 번째인지 세보면 된다. 세 번째가 넘었으면 잘되고 있어도 한 번 검토할 때다. 검토를 햇수에 걸어두면 감정 소모가 준다.

우리는 한 시즌(모집 한 번에 열리는 모임 기간)에 주중 팀과 주말 팀을 같이 연다. 주제도 진행 방식도 비슷하고 요일만 다르다.

몇 시즌 동안 이 둘의 성적은 거의 같았다. 어떤 시즌은 주말이 조금 높고 어떤 시즌은 주중이 조금 높았다. 팀 평균 등록 인원의 격차가 0.7명을 넘은 적이 없었다.

그러다 한 시즌에 벌어졌다.

12팀 중 1팀

그 시즌 주중은 아홉 팀에 팀 평균 6.1명, 성공률(정원을 채운 팀의 비율) 56퍼센트였다. 예년보다 낮지만 크게 이상하진 않았다.

주말은 열두 팀에 팀 평균 3.8명, 성공률 8퍼센트였다. 열두 팀 중 한 팀만 정원을 채웠다.

그 한 팀을 빼고 나머지 열한 팀의 평균을 내보니 2.7명이었다. 세 명이 모여 여섯 번 만나는 모임이 열한 개 열릴 뻔했다.

공통점은 요일 하나였다

이걸 보고 나서 팀별로 무엇이 잘못됐는지를 찾는 걸 멈췄다.

열두 팀이 동시에 콘텐츠가 나빠질 수는 없다. 파트너(팀 하나를 맡아 이끄는 사람)도 다르고 주제도 다르다. 공통점은 요일 하나뿐이다.

돌아보면 그 시즌에는 주말 팀 열두 개도 많았다. 그 전 시즌들은 주말이 열여섯에서 열여덟 개였고, 그때는 주말에 오는 사람 수가 그만큼 받쳐줬다. 그 시즌엔 열두 개로 줄였다. 그래도 사람이 줄어드는 시기에 사람이 준 만큼 팀을 줄이지 않으면 한 팀당 나눠 갖는 몫이 작아진다.

그러니까 이건 배분의 문제였다. 우리는 팀 수를 정할 때 기획할 수 있는 주제가 몇 개인가로 정하고 있었다. 그 요일에 올 수 있는 사람이 몇 명인가로 정한 적이 없다.

지금은 시즌 라인업(그 시즌에 여는 팀 목록)을 짤 때 요일별로 먼저 나눈다. 이 요일에 올 사람이 대략 몇 명인지 지난 시즌들에서 보고, 그 수를 팀 수로 나눠 본다. 나눈 값이 최소 인원보다 작으면 팀 수를 줄인다. 좋은 기획이 남아 있어도 줄인다.

따라 해보기

같은 상품을 여러 시간대나 지역으로 나눠 팔고 있다면, 각 구간의 총 수요를 먼저 추정하고 그걸 구간 안의 상품 수로 나눠 보면 된다. 나눈 값이 손해를 보지 않는 최소 판매량보다 작으면 상품이 많은 것이다.

그 시즌 등록자가 가장 많았던 팀은 16명 중 처음 온 사람이 2명이었다. 다음 시즌에 뺄까 고민하던 팀은 7명 중 4명이 처음 온 사람이었다.

시즌(모집 한 번에 열리는 모임 기간)이 끝나면 팀별 성적표를 본다. 기준은 오랫동안 하나였다. 등록자 수. 많이 온 팀이 잘된 팀이고 적게 온 팀은 다음 시즌에 다시 볼 팀이다. 쉽고 분명했다.

한 시즌을 정리하면서 등록자를 신규(처음 온 멤버)와 기존(전에 와 본 멤버)으로 나눠 봤다. 특별한 이유가 있던 건 아니고 신규가 얼마나 되는지 궁금해서였다.

성적표 맨 위 팀은 신규가 16명 중 2명이었다

성적표 맨 위에 있던 팀은 16명 중 14명이 기존 멤버였다.

반대로 등록자가 부진해서 빼려던 팀은 온 사람 중 처음 오는 사람이 절반을 넘었다. 우리에게 신규를 데려오는 창구가 그 팀이었다. 하나의 숫자만 봤으면 잘라낼 뻔했다.

이걸 보고 팀을 두 종류로 나눠서 보기 시작했다. 처음 오는 사람이 문을 두드리는 팀은 주제가 대중적이거나 문턱이 낮다. 등록자 수는 대단하지 않을 수 있지만 사람을 데려온다. 이미 몇 시즌을 보낸 사람이 다음 단계로 가는 팀은 깊이 있고 전제 지식을 요구한다. 등록자가 많고, 사람을 붙잡는다.

둘은 하는 일이 다르니 같은 잣대로 재면 안 된다.

라인업에 균형을 넣었다

다음 시즌 라인업(그 시즌에 여는 팀 목록)을 짤 때 이 구분을 넣는다. 팀 목록을 놓고 데려오는 쪽과 붙잡는 쪽이 몇 개씩인지 센다.

한쪽으로 기울면 조정한다. 붙잡는 팀만 많으면 그 시즌은 신규가 거의 안 들어온다. 당장은 등록자 수가 좋아 보이는데 두세 시즌 뒤에 신규 없이 기존 멤버만 줄어드는 구간이 온다. 데려오는 팀만 많으면 반대로 오래 있던 멤버가 갈 데가 없다.

이 균형은 매번 의식적으로 맞춰야 한다. 저절로 안 맞는다. 성적 좋은 팀을 남기고 나쁜 팀을 빼는 방식으로 운영하면 자동으로 붙잡는 팀만 남기 때문이다.

이 일로 알게 된 사실은 커뮤니티 밖에서도 그대로 쓰인다. 하나의 숫자로 평가하면 조직은 그 숫자를 잘 만드는 쪽으로 움직인다. 아무도 잘못한 게 없는데 몇 시즌 뒤에 닫힌 모임이 된다.

따라 해보기

성과를 하나의 숫자로 보고 있다면, 그 숫자를 두 갈래로 쪼개 보면 된다. 신규와 기존, 첫 구매와 재구매처럼. 쪼개는 순간 맨 위와 맨 아래가 뒤집히는지 확인한다.

새로 오는 멤버를 연차순으로 세우면 한가운데가 8년차다. 8~10년차는 55퍼센트가 지인 추천으로 오고, 인스타그램으로 오는 건 21퍼센트다. 그런데 우리 콘텐츠 시간의 대부분은 인스타그램에 들어가고 있었다.

신규 멤버에게 어디서 우리를 알게 됐는지 묻는다. 전체 답을 합치면 인스타그램과 지인 추천이 비슷하게 나온다. 이 답을 연차별로 나눠 보기 전까지는, 두 채널(우리를 알게 되는 경로)을 반반씩 관리하면 된다고 생각했다.

같은 커뮤니티에 완전히 다른 길로 온다

1년에서 3년차는 인스타그램이 43퍼센트, 지인 추천이 43퍼센트로 반반이었다.

8년에서 10년차는 달랐다. 지인 추천이 인스타그램의 두 배 반이다.

11년차 이상은 지인 추천과 기존 멤버 소개가 대부분이고 인스타그램은 거의 없다.

연차가 올라갈수록 광고로는 안 오고 사람으로 온다. 당연해 보이는 이야기다. 그런데 우리가 가장 많이 만나는 사람들이 인스타그램을 거의 안 보고 오는 사람들이었다.

8년차 이상은 사람이 데려온다

이걸 알고 나서 두 가지를 바꿨다.

하나는 인스타그램의 역할을 다시 정한 것이다. 여기는 젊은 연차가 우리를 처음 발견하는 곳이다. 그러니 여기서는 우리가 뭐 하는 곳인지가 한눈에 보여야 한다. 깊은 내용은 여기서 소비되지 않는다.

다른 하나가 더 컸다. 8년차 이상을 데려오는 건 이미 우리 안에 있는 사람이다. 그렇다면 소개를 부탁하기 좋은 시점을 만들어야 한다. 전에는 이걸 우연에 맡겼다. 좋으면 알아서 데려오시겠지 하는 식이었다.

지금은 시즌(모집 한 번에 열리는 모임 기간)이 끝나고 만족도가 가장 높은 시점에, 주변에 같이 오면 좋을 분이 있는지를 묻는다. 마케팅 예산을 늘리는 것보다 이게 우리 주력 연차에 훨씬 잘 닿았다.

따라 해보기

유입 경로를 묻고 있다면 그 답을 하나로 합치지 말고 나이나 연차나 직무로 쪼개 보면 된다. 쪼개면 어떤 사람이 어느 문으로 오는지가 보이고, 지금 어느 문을 방치하고 있는지도 같이 보인다.

한 팀은 상세 페이지를 275명이 봤는데 등록이 0명이었다. 기존 멤버가 한 명도 없이 시작한 팀이었다.

새 팀을 기획할 때 우리가 고민하는 건 대체로 주제다. 이 주제가 지금 사람들이 궁금해하는 것인가, 파트너(팀 하나를 맡아 이끄는 사람)가 좋은 이야기를 할 수 있는가.

한 시즌(모집 한 번에 열리는 모임 기간)을 정리하면서 팀들을 재등록 멤버(지난 시즌에 왔다가 다시 신청한 멤버) 비율로 줄 세워 봤다. 기존 멤버, 그러니까 시드(처음부터 등록해 줄 사람)가 몇 퍼센트인가로.

콘텐츠가 아니라 시드였다

재등록 비율이 80퍼센트를 넘는 팀들이 있었다. 평균 등록 9.7명. 전원 성공이다. 50에서 79퍼센트 구간도 평균 9.3명으로 대부분 성공했다.

재등록 비율이 0퍼센트인 팀들, 그러니까 기존 멤버가 한 명도 없이 신규만으로 채워야 했던 팀들은 평균 등록이 2.0명이었다. 예외 없이 전원 미달이다.

상세 페이지를 275명이 본 팀도 여기 있었다. 주제가 안 좋았으면 275명이 안 들어왔을 것이다.

아무도 안 가니까 나도 안 간다.

시드 두세 명을 먼저 구한다

그래서 새 팀을 여는 절차를 바꿨다. 상세 페이지를 만들기 전에 기존 멤버 두세 명에게 먼저 물어본다. 이런 팀을 열려고 하는데 오실 생각이 있는지.

두세 명이 확보되면 연다. 안 되면 그 기획은 다음 시즌으로 미루거나 접는다. 아무리 좋아 보여도.

처음엔 이게 소극적으로 느껴졌다. 좋은 기획이면 밀어붙여야 하는 것 아닌가 싶었다. 그런데 0명에서 시작한 팀에 신규 멤버 두 명이 들어와서 두 명이 여섯 번 모이는 시즌을 보내는 게 어떤 경험인지 생각해 보면, 그 팀을 안 여는 게 그분들에게도 낫다.

빈 방에 먼저 들어가고 싶은 사람은 없다.

따라 해보기

새로 뭔가를 열 계획이 있다면, 만들기 전에 확실히 올 사람 두세 명의 이름을 써보면 된다. 이름이 안 나오면 아직 열 때가 아니다.

8년 동안 처음 온 1,795명 가운데 1,015명이 다시 오지 않았다. 그런데 돌아온 사람의 63.6퍼센트는 바로 다음 시즌에 왔다.

시즌은 석 달 단위로 멤버를 모아 여는 모임 기간이다. 커뮤니티를 오래 하면 재등록률(지난 시즌 멤버가 다음 시즌에 다시 신청한 비율)은 보는데 첫 등록자가 어떻게 됐는지는 잘 안 본다. 매 시즌 새로 오는 사람이 있으니 전체 숫자는 유지되기 때문이다.

8년치를 한 번 추적해 봤다. 멤버 아이디에 시즌 번호가 붙어 있어서 그걸 떼면 같은 사람을 여러 시즌에 걸쳐 따라갈 수 있다. 34개 시즌, 첫 등록 1,795명.

절반이 한 번 오고 끝났다

56.5퍼센트가 그 뒤 어느 시즌에도 다시 안 왔다.

이 숫자를 처음 봤을 때 기분이 좋지 않았다. 매 시즌 새 얼굴이 들어오는 걸 성장으로 보고 있었는데, 그 절반은 한 번 겪고 떠난 사람들이었다.

그런데 돌아온 780명을 다시 나눠 보니 다른 게 보였다. 열 명 중 여섯 명 넘게 바로 다음 시즌에 왔다. 두 시즌 안에 오는 사람까지 합치면 77.3퍼센트, 네 시즌 안이면 87.6퍼센트다.

돌아올 사람은 빨리 돌아온다. 시간이 지날수록 돌아올 확률이 급하게 떨어진다.

기회는 바로 다음 시즌이다

이게 운영을 바꿨다.

전에는 재등록 안내를 다음 시즌 오픈에 맞춰 보냈다. 시즌이 끝나고 한 달쯤 뒤다. 상품이 준비돼야 안내할 게 있으니 자연스러운 순서였다.

그런데 숫자로 보면 순서가 거꾸로였다. 돌아올 마음이 있는 사람은 시즌이 끝난 직후에 가장 뜨겁다. 그때 우리는 상품을 만드느라 아무 말도 안 하고 있었다.

순서를 바꿨다. 상품이 준비되기 전에 먼저 연락한다. 다음 시즌에 뭐가 열리는지는 아직 몰라도, 이번 시즌이 어땠는지 묻고 다음에 관심 있는 방향이 뭔지 묻는 건 지금 할 수 있다.

이탈률을 56.5퍼센트에서 50퍼센트로만 낮춰도 매 시즌 서너 명이 더 남는다.

따라 해보기

한 번 사고 안 돌아온 고객이 몇 퍼센트인지 세보면 된다. 그리고 돌아온 사람들이 얼마 만에 돌아왔는지도 같이 센다. 두 번째 숫자가 언제 연락해야 하는지를 알려준다.

멤버 한 사람이 평균 몇 번 등록하는지를 연도별로 세봤다. 충성도를 보고 싶었다.

2018년 1.54회. 2019년 2.11회. 2020년 2.05회. 2021년 2.47회. 2022년 2.82회. 2023년 2.92회. 2024년 3.43회. 2025년 3.67회.

2020년에 한 번 주춤한 것 말고는 계속 올랐다. 처음 이 표를 봤을 때 기분이 좋았다. 멤버가 우리를 더 오래 쓴다는 뜻이니까.

같은 숫자를 반대로 읽을 수 있었다

그런데 옆에 다른 표를 놓고 나서 생각이 달라졌다.

같은 기간 시즌(석 달 단위로 여는 모임 기간)별로 첫 등록과 재등록(지난 시즌 멤버가 다시 신청하는 것)의 비율이 어떻게 변했는지를 봤다. 2019년 봄에는 첫 등록이 47퍼센트, 재등록이 29퍼센트였다. 2025년 겨울에는 첫 등록이 32퍼센트, 재등록이 55퍼센트다. 나머지는 처음으로 다시 등록한 사람이다.

평균 등록 횟수가 오른 게 사람들이 더 충성해서만은 아니었다. 새로 들어오는 사람이 줄어서 남아 있는 사람들의 비중이 커진 것이기도 했다.

같은 사람들이 계속 등록하면 이 숫자는 저절로 오른다. 신규가 한 명도 안 들어와도 오른다. 극단적으로 말하면, 이 지표가 가장 좋아 보이는 순간은 아무도 새로 안 들어올 때다.

좋아 보이는 지표를 의심하는 법

이걸 겪고 나서 습관이 하나 생겼다. 좋아 보이는 숫자가 나오면 그게 좋아지는 다른 경로가 있는지 찾아본다.

평균 등록 횟수가 오르는 경로는 둘이다. 기존 사람이 더 많이 등록하거나, 새 사람이 덜 들어오거나. 둘 다 같은 방향으로 숫자를 움직인다. 지표 하나만 보면 어느 쪽인지 알 수 없다.

그래서 이 숫자는 이제 혼자 보지 않는다. 첫 등록 비율과 같이 놓고 본다. 둘 다 오르면 진짜 성장이다. 평균 횟수만 오르고 첫 등록 비율이 떨어지면 축소다.

따라 해보기

지금 잘 나오고 있는 지표를 하나 골라, 그 숫자가 올라가는 경로를 두 가지 이상 써보면 된다. 하나가 나쁜 소식인 경로면, 그 지표는 혼자 보면 안 되는 지표다.

커뮤니티를 하면 재등록률을 매 시즌(3개월 단위 모임 기간) 본다. 이번 시즌 멤버 중 몇 퍼센트가 다음에도 오는가.

이 숫자를 올리려 할 때 제일 먼저 떠오르는 건 뭔가를 더 주는 것이다. 혜택을 늘리고 이벤트를 늘리고 할인을 건다. 우리도 그 순서로 생각했다.

주제만으로는 설명이 안 됐다

먼저 본 건 모집이 미달되는 팀이었다. 시즌마다 몇 개가 정원을 못 채운다. 공통점을 찾다가 이상한 걸 봤다.

주제가 나쁜 팀들이 아니었다. 비슷한 주제인데 요일이 다른 팀들의 성적이 갈렸다.

우리는 무엇을 할지는 오래 고민했는데, 언제 할 수 있는지는 물어본 적이 없었다.

확정 전에 초안을 보여주고 물었다

정기 설문을 넣었다. 다음 시즌 라인업(그 시즌에 열 팀 목록)이 확정되기 전에 돌린다. 이게 달랐다. 확정한 다음에 만족도를 묻는 게 아니라, 확정하기 전에 선택지를 묻는다.

세 가지를 물었다. 왜 오시는지. 언제 가능하신지. 어떤 형태가 좋으신지. 그리고 다음 시즌 팀 초안을 미리 보여줬다. 아직 정리 안 된 걸 보여주는 셈이라 조금 용기가 필요했다.

응답은 30명이 넘었다. 규모에 비하면 큰 수가 아닌데 그 응답이 라인업을 바꿨다. 요일을 옮긴 팀이 있고, 실습 비중을 늘린 팀이 있고, 아예 접은 기획도 있다. 초안 단계에서 반응이 없던 걸 밀어붙이지 않기로 한 것이다.

결과로 미달 팀이 줄었고, 재등록자 비율이 66퍼센트에서 70퍼센트가 됐다.

혜택을 늘리는 방식은 무엇을 더 줄지 우리가 정한다. 설문은 멤버에게 먼저 묻는다. 응답한 30명은 자기가 의견을 낸 팀이 열리는 걸 봤다.

따라 해보기

이번에 준비 중인 걸 확정하기 전에, 쓸 사람 열 명에게 초안 상태로 보여주고 세 가지만 물어보면 된다. 왜 필요한지, 언제 가능한지, 어떤 형태가 좋은지.

내가 운영하는 커뮤니티는 3개월이 한 시즌이다. 시즌마다 팀이 열다섯에서 스무 개 열리고, 팀마다 소개 페이지가 하나씩 필요하다.

그 페이지에 들어가는 걸 세봤다. 헤드라인, 팀 소개, 6회차 주제, 진행 방식, 그라운드룰(모임에서 지킬 약속), 파트너(팀 하나를 맡아 이끄는 사람) 소개, 어떤 분에게 맞는지, 혜택, 자주 묻는 질문, 등록 절차. 웹사이트 편집기에 넣는 코드로 바꾸면 600줄쯤 된다. 스무 개면 12,000줄이다.

오픈 2~3주 전이 매번 무너졌다.

무너지는 데가 글 쓰는 곳이 아니었다

처음엔 내가 글을 느리게 써서 그런 줄 알았다. 시간을 나눠 재보니 아니었다.

팀 내용을 정하는 일은 문제가 아니었다. 파트너와 이야기하고 커리큘럼 잡는 데 시간이 드는 건 당연하고, 그게 이 일의 본론이다. 문제는 그 다음이었다. 정한 내용을 편집기가 알아듣는 모양으로 옮기는 데서 팀당 두세 시간이 사라졌다.

거기서 실수도 났다. 스무 개를 연달아 만들면 열두 번째쯤부터 앞 팀 문장이 섞인다. 회차 날짜가 지난 시즌 것으로 남거나 정원이 다른 팀 숫자로 들어간다. 오픈 당일에 멤버가 먼저 알려준 적도 있다.

쓰는 곳과 보이는 곳을 떼어냈다

페이지를 만들지 말고 내용만 쓰기로 했다.

팀마다 노트를 하나씩 둔다. 제목, 회차 주제, 정원, 파트너 이름이 그냥 적혀 있다. 편집기 문법도 태그도 없는, 사람이 읽는 문서다. 그걸 페이지로 바꾸는 일은 스크립트(정해 둔 순서대로 일을 처리하는 작은 프로그램)가 한다.

이렇게 나누니 스무 개 페이지 모양이 저절로 같아졌다. 열두 번째에서 내가 집중력을 잃어도 흔들리지 않는다. 모든 팀의 자주 묻는 질문을 바꾸고 싶으면 틀 하나만 고치면 된다. 회차가 6개가 아니거나 정원이 비면 만들다가 멈춘다. 오픈 당일에 멤버가 알려주는 대신 내 화면에서 걸린다.

다 풀리진 않았다. 격주로 도는 팀, 회차가 다섯인 팀, 워크숍이 낀 팀은 매 시즌 두세 개씩 나온다. 이런 건 그냥 직접 만든다.

따라 해보기

반복되는 일이 힘들면, 그 일을 단계로 쪼개서 각 단계에 시간을 써보면 된다. 한 단계가 나머지를 다 잡아먹고 있다. 그 한 칸만 찾으면 된다.