“내가 편하려고” 만든 작은 도구가, 어쩌다 팀 공식 회고 도구가 되고 본부 임원 보고까지 올라갔습니다.
처음부터 거창하게 팀 도구를 기획한 게 아니에요. ClickUp에서 매번 반복되던 5분, 10분을 줄이려고 Claude Code로 짧게 시작했는데, 결과적으로 팀까지 움직이게 됐습니다.
매번 깎이던 10분이 아까웠습니다
저희 팀에는 협업과 품질을 챙기려고 정해둔 ClickUp 규칙이 몇 가지 있습니다. 회고 포맷을 통일해서 export하기, 운영테스트 댓글을 정해진 양식으로 남기기, 미계획 작업 비율을 회고 때 점검하기 같은 것들이에요.
규칙 자체는 모두 필요한 것이었지만, ClickUp 기본 기능만으로는 가볍게 따르기가 어려웠습니다. 문제는 큰 한 방이 아니라 매일 조금씩 깎이는 5분, 10분이었거든요.
| 매번 깎이던 시간 | 무슨 일이었나 |
|---|---|
| 회고 export 정리 (~10분) | 태스크 골라 export → AI에 포맷 요청 → 손으로 다듬기. 사람마다 형식이 제각각 |
| 운영테스트 댓글 (다섯 단계) | /banner → 색상 → 날짜 → 개발/운영 → 스크린샷. 태스크마다 반복 |
| 미계획 작업 비율 집계 | ClickUp 커스텀 필드는 export 결과에 빠짐. 매 회고마다 한 명이 손으로 집계 |
잠깐, 용어 정리. 운영테스트 는 운영 환경 배포 후 진행하는 검증 단계예요.
/banner는 ClickUp 댓글에서 색상 배너를 만드는 슬래시 명령어이고, 커스텀 필드 는 태스크에 붙이는 사용자 정의 메타데이터(예: 미계획 여부 체크)인데 기본 export 결과에는 빠지는 경우가 많습니다.
세 가지 모두 따로 보면 사소했지만, 반복된다는 점에서 같은 종류의 비효율이었어요.

매번 5분, 10분씩 깎이던 세 가지 반복 작업.
굳이 만들 만한가
여기까지 읽으면 “그러면 만들면 되지”로 들리지만, 처음 머릿속에서 일어난 일은 좀 달랐어요. 팀 도구를 만들어볼까가 아니라 내 시간을 어떻게 줄이지가 먼저였습니다.
회고 직전마다 export 방식을 묻는 사람이 되기 싫었고, 운영테스트 댓글의 다섯 단계를 매번 손으로 따라 하기도 귀찮았습니다. 거창하게 “사내 자동화 프로젝트”를 기획한 것도 아니었어요. 그냥 내 컴퓨터 앞에서 매번 똑같은 일을 반복하는 게 싫었습니다.
‘10분 × 매번’의 누적 비용
그런데 숫자로 한번 계산해 보니 생각이 좀 달라졌습니다.
운영테스트 댓글 다섯 단계까지 더하면 시간은 더 늘어납니다. 이쯤 되니 “만들 만한가”가 “만들어보고 싶다”로 바뀌었어요.
바이브 코딩이라 가볍게 시도해 볼 수 있었습니다
또 하나, 결단을 가볍게 만들어 준 건 도구 쪽이었습니다. Claude Code로 바이브 코딩을 하면 일과 사이사이에 짧게 시도해 볼 수 있었거든요.
Info
바이브 코딩이란? Claude Code 같은 AI 에이전트에 자연어로 요구사항을
넘기고, 결과를 검증하면서 반복적으로 다듬어가는 개발 방식입니다. 코드 한 줄 한
줄을 직접 짜는 대신, 의도와 검증에 집중하는 흐름에 가깝습니다.
업무 중간에 “이런 게 있으면 좋겠다” 싶은 요구사항을 그대로 Claude Code에 넘기고, 결과를 잠깐 확인한 뒤 다시 본 업무로 돌아오는 사이클이었어요. 며칠 잡고 정식 프로젝트로 시작해야 했다면 아마 시작 자체를 미뤘을 거예요.
최소 기능으로 시작했습니다
그래서 만들기 시작했지만, 처음부터 다양한 케이스를 다루려 들지는 않았습니다. 공유할 생각도 없이, 제가 매일 쓰는 두 개 기능부터 만들었어요.
기능 1. 운영테스트 댓글 자동화 (다섯 단계 → 한 번의 클릭)
가장 먼저 만든 건 운영테스트 완료 처리 모달입니다. 운영테스트 댓글을 태스크 상태 변경과 묶어서 한 번에 처리하도록 했어요.
- 라벨(내부개선/에러), 메모, 스크린샷을 한 번에 입력
- 댓글에는
2026-05-06 운영테스트완료형식의 배너가 자동 생성 - 상태 전환과 댓글이 한 번의 제출로 함께 발생

운영테스트 완료 처리 모달. 다섯 단계가 한 화면 안으로 들어왔어요.
앞서 표에 적어 둔 다섯 단계가 모달 한 번의 클릭으로 줄어들었습니다. 운영테스트 댓글은 하루에 여러 번 다는 절차라, 이 한 가지만으로도 절감 효과가 누적되더라고요.
기능 2. 스프린트 회고 자동 export (미계획 작업 비율 포함)
두 번째는 회고 export입니다. 화면 한쪽에서 스프린트를 고르면 통일된 포맷으로 회고 미리보기가 즉시 만들어지도록 했어요.
- 목표 달성 현황(완료 건수 / 전체 건수, 완료율)을 자동 집계
- ClickUp이 export하지 못하는 미계획 작업 비율도 함께 집계
- 복사·저장 버튼으로 즉시 회고 문서에 옮길 수 있음

스프린트를 고르면 통일된 포맷의 회고 미리보기가 즉시 만들어집니다. 미계획 작업 비율도 자동으로 따라와요.
미계획 작업 비율이 자동으로 따라오는 게 핵심이었습니다. 회고 때마다 한 명이 손으로 집계하던 단계가 사라졌어요.
Claude Code에 넘기고 검증하는 사이클
작업 방식 자체는 단순했어요. ClickUp을 쓰다가 불편한 부분을 메모해 두고, 잠깐 시간이 나면 Claude Code에 그 요구사항을 그대로 넘기고, 결과가 나오면 직접 써본 뒤 안 맞는 부분을 다시 피드백으로 돌리는 흐름이었습니다.
설계를 거창하게 그리지 않다 보니 처음 며칠은 동작이 자주 깨졌습니다. 다만 고치는 데 드는 비용이 낮으니 깨지는 걸 부담스러워하지 않아도 됐어요. 깨진 부분을 그대로 다음 요구사항으로 넘기면 됐거든요.
범용 도구를 만들 생각은 처음부터 없었습니다. 다른 팀에서 쓰일 만한 케이스보다 우리 팀 워크플로우에 정확히 들어맞는 동작을 우선했어요.
팀에 공유했더니
여기까지가 “혼자 쓰던 도구”의 이야기입니다. 사실 글이 여기서 끝나도 자기 시간 절감 글로는 충분했을 텐데, 막상 팀에 보여주고 나서부터 흐름이 좀 달라졌습니다.
”이거 어디서 쓰는 거예요?”
가볍게 팀 채팅에 링크를 던졌더니, 의외로 반응이 빨리 왔어요.
이거 어디서 쓰는 거예요?
회고 미리보기 기능이 필요했어요.
banner 댓글 매번 다는 거 진짜 귀찮았는데.

팀 채팅에 링크를 던졌을 때 의외로 빨리 돌아온 반응.
생각보다 많은 사람이 같은 불편을 겪고 있었던 모양입니다. 저는 “내 시간 좀 줄이려고”의 관점이었는데, 팀원들은 그 안에서 자기 자리에 맞는 쓸모를 찾아냈어요.
팀 공식 회고 도구가 되기까지
그러다 회고 자리에서 “이번 회고는 이걸로 정리해보자”는 말이 나왔습니다. 다음 스프린트엔 포맷이 자연스럽게 자리 잡혔고, 그다음부터는 회고 준비 단계에서 export 방식을 묻는 질문이 거의 사라졌습니다.
처음 만들 때는 상상하지 않았던 변화였습니다. 개인 도구로 시작했는데, 팀이 같은 포맷으로 회고를 쓰게 되니까 회고 자체의 결도 비슷해졌어요.
정량 효과, 연 43시간이라는 수치
채택 이후에 효과를 한 번 정리해 봤어요. 회고는 2주에 한 번이지만, 운영테스트 댓글은 매일 여러 번이라 같은 “10분”이라도 누적되는 양이 다릅니다. 비교를 단순하게 하려고 회고 export 준비 시간만 환산했습니다.
| 항목 | 수치 |
|---|---|
| 절감 대상 인원 | 10명 |
| 1인당 절감 시간 | 2주당 약 10분 (연 26회) |
| 연간 총 절감 시간 | 약 43시간 (10명 × 10분 × 26회 ÷ 60) |
운영테스트 댓글 자동화 효과까지 합치면 시간은 더 늘어나는데, 표에는 굳이 더하지 않았어요. 한 가지 기준만으로도 충분히 큰 숫자였거든요.
작은 것이 가장 멀리 가더라고요
잠깐 돌이켜 보면, 결과 그 자체보다 이 도구가 그 결과까지 갈 수 있었던 이유 쪽이 더 남았어요.
임원 보고까지 간 이야기
이 도구는 그 이후 팀장님 보고를 거쳐 본부 AI 활용 사례에까지 올라갔습니다. 처음 시작했을 땐 절대 상상하지 않은 자리였어요.
재미있었던 건, 보고 자료를 정리하면서 “거창한 사내 프로젝트가 아니라 한 명이 자기 불편을 줄이려고 시작한 도구”라는 점이 오히려 강점으로 읽혔다는 거예요. 작은 사이클로 즉시 만들 수 있다는 점, 그게 보고 자리에서 가장 눈에 띄었어요.
AI 도구를 쓰다가, AI로 도구를 만들어 보는 쪽으로
지금까지 AI 활용은 대부분 “남이 만든 AI 도구를 쓰는” 일이었습니다. ChatGPT를 쓰고, Copilot을 쓰고, Claude를 쓰는 식이었죠. 이번 도구는 한 발 더 나아간 사례에 가까워요.
”내가 편하려고”의 힘
마지막으로 남은 건 시작 동기 이야기예요. 이 도구는 처음부터 팀을 위해 만든 게 아니라, 내가 편하려고 시작한 작은 시도였습니다.
만약 처음부터 “팀 전체에 도움이 되는 도구를 만들자”고 시작했다면 아마 못 만들었을 거예요. 범용성을 고민했을 거고, 다른 팀에 권할 때 부담 없는 셋업을 신경 썼을 거고, 결국 시작 자체를 미뤘을 가능성이 큽니다.
거꾸로 말하면, 시작 동기가 좁았기 때문에 첫 동작을 일찍 만들 수 있었고, 일찍 만들었기 때문에 팀에 던져 볼 여지도 생긴 거예요.
마무리
업무 중에 매번 같은 자리에서 5분, 10분이 깎이고 있다면, 거창하게 기획하기 전에 내가 편하려고 한번 만들어 보세요. SaaS의 다음 업데이트를 기다리지 않고도 우리 손으로 채울 수 있는 부분이 생각보다 많거든요. 그 작은 시작이 팀이나 본부 자리까지 닿을지는, 만들기 전에는 잘 모르는 거더라고요 :)