
그룹웨어 개발 검수, 기능 94% 완료인데 업무가 안 이어지는 이유
94%였습니다. 회차별로 받은 요구사항 124건을 코드와 한 건씩 대조했더니, 117건이 완전히 구현됐다는 판정이 나왔습니다.
부분 구현이 6건, 빠진 기능은 0건이었습니다. 기록에 남은 판정을 더하면 123건이라, 1건은 어느 쪽으로 판정됐는지 남아 있지 않습니다.
검수표만 보면 넘겨도 되는 상태입니다. 그런데 써 보던 쪽에서 먼저 연락이 왔습니다. 칸반에서 업무를 추가하면 피드에 안 나온다는 내용이었습니다.
초록 117칸의 정체
보험대리점(GA) 지사에 들어가는 사내 그룹웨어였습니다. 수십 명 규모 조직이 피드·업무·캘린더·전자결재·근태·파일을 한곳에서 쓰도록 만든 시스템입니다.
요구사항은 13개 영역으로 나눴습니다. AI 에이전트 22개가 영역을 맡아 코드와 대조했고, 판정마다 반박하는 검증을 한 번 더 붙였습니다.
| 판정 | 건수 |
|---|---|
| 완전 구현 | 117건 (94%) |
| 부분 구현 | 6건 |
| 미구현 | 0건 |
| 기록 없음 | 1건 |
부분 6건은 내용만 보면 사소한 편입니다. 업무에 우선순위 필드가 아예 없었고, 프로젝트를 만들 때 색을 고를 수 없었습니다.
투표 글 작성 화면에는 첨부 버튼이 숨어 있었습니다. 다른 글 유형에는 다 있는 버튼입니다.
하위업무는 일부러 줄여 둔 경우였습니다. 개별 상태·마감·담당자 없이 제목과 완료 체크만 있는 체크리스트로 만든 상태입니다.
나중에 온 요청서에는 하위업무마다 옵션을 따로 달고 AI로 생성하게 해 달라는 내용이 있었습니다. 줄여 둔 설계를 그 요청에 맞춰 다시 봐야 하는 상태였습니다.
여기까지는 흔한 검수 결과입니다. 문제는 이 표가 '있는가'만 묻는다는 점이었습니다.
칸반에서 만든 업무가 피드에 없다
업무 생성 기능은 있었습니다. 피드도 있었습니다. 체크리스트에서는 둘 다 초록입니다.
피드에서 만든 업무는 피드에 글로 남았습니다. 칸반에서 만든 업무는 남지 않았습니다.
같은 기능에 들어가는 길이 둘이었고, 피드에 글을 남기는 동작은 한쪽 길에만 붙어 있었습니다. 피드만 보는 팀원은 새 업무가 생긴 걸 모르게 됩니다.
기능 단위로 세면 이런 결함은 어느 칸에도 걸리지 않습니다. 그래서 질문을 바꿔 다시 셌습니다.
"X를 만들면 Y에 반영되는가." 기능과 기능 사이에서 늘 지켜져야 하는 이 약속을 개발 쪽에서는 불변식이라고 부릅니다.
33개 연결 중 21개가 어긋남
업무와 피드, 일정과 캘린더, 파일과 첨부, 알림, 집계 화면, 사용자 수명주기로 6개 도메인을 잡았습니다. 여기서 뽑아 하나씩 추적한 연결이 33개입니다.
이번에는 에이전트 35개가 나눠 맡았고, 끊김 판정은 반대편 검증으로 두 번 확인했습니다.
끊김 7건, 부분 14건이 나왔습니다. 끊김이나 부분이 아닌 연결은 12개입니다.
끊긴 쪽은 대체로 이런 모양이었습니다.
| 이렇게 하면 | 이렇게 돼야 하는데 | 실제로는 |
|---|---|---|
| 글에서 @멘션 | 불린 사람에게 알림 | 어떤 채널로도 안 감 |
| 결재선에 참조 지정 | 참조자에게 알림 | 참조함을 열기 전엔 모름 |
| 전사 공지 발행 | 대상 직원에게 알림 | 앱을 안 열면 모름 |
| 칸반에서 업무 삭제 | 연결된 피드 글 정리 | 제목 없는 글이 남음 |
| 휴가 화면에서 승인 | 연동 결재문서도 처리 | 결재함에 대기로 남음 |
| 직원 비활성 처리 | 결재 차례를 넘김 | 문서가 영구 대기 |
마지막 줄이 가장 위험했습니다. 퇴사 처리를 데이터베이스에서 직접 하는 순간, 그 사람이 결재할 차례인 문서는 기안자가 풀 방법 없이 멈춥니다.
담당 업무와 소유 프로젝트도 주인 없이 남습니다. 퇴사자가 처음 생기는 날 바로 드러나는 결함입니다.
알림도, 공지도, 결재도 체크리스트에는 있음으로 표시돼 있었습니다.
요청서가 몇 번 왔는지 아시나요
감사를 하다가 구멍이 하나 더 보였습니다. 요구사항 자료가 몇 번에 걸쳐 왔는지부터 정리가 안 돼 있었습니다.
다시 세 보니 전달본은 6건이었습니다. 채팅에 붙여 보낸 화면 자료 4건, 텍스트 파일 1건, 채팅 첨부 파일 1건입니다.
그중 5회차 채팅 첨부가 스펙 문서에 빠져 있었습니다. 작성 팝업, 하위업무 AI 생성, 프로젝트 참여 승인제 같은 요청이 들어 있었는데, 대화 기록을 거슬러 뒤지고서야 찾았습니다.
체크리스트는 스펙에서 뽑습니다. 회차 하나가 빠진 채로 세면 분모부터 실제 요청보다 작아집니다.
그 뒤로는 자료를 받는 즉시 회차와 날짜를 스펙 대장에 적습니다. 한 줄이면 끝나는 기록인데, 빠뜨리면 나중에 대화 기록을 통째로 뒤지게 됩니다.
고치는 변경에도 반대편 리뷰
구멍을 찾은 그날 밤까지 변경 6건을 배포했습니다. 알림 결손, 삭제 뒤 남는 글, 우선순위 필드 같은 소형 수선 21항목이 그중 한 건으로 묶였습니다.
변경마다 다른 AI 모델에게 반대편 리뷰를 맡겼습니다. 구현한 쪽과 다른 눈으로 "이게 어디서 깨지나"만 찾게 하는 방식입니다.
이 리뷰가 배포를 막아야 할 결함 14건을 배포 전에 잡았습니다. 업무 하나에 피드 글이 두 번 생기는 이중 게시물, 이미 완료된 결재 문서를 동시에 건드리는 경쟁 상태, 담당자를 전원 해제할 수 없는 문제, 대표 담당자가 뒤바뀌는 문제 같은 것들입니다.
연결을 고치는 변경은 그 자체로 새 연결을 만듭니다. 칸반 업무에 피드 글 생성을 붙이자 바로 이중 게시물 위험이 생겼습니다.
반대편 리뷰도 틀릴 때가 있었습니다. 코드를 읽은 시점이 달라 이미 고친 부분을 결함으로 짚은 경우가 있어서, 지적마다 실제 코드를 다시 열어 확인했습니다.
사람이 정할 몫은 표로
수선을 하다 보면 코드로는 답이 안 나오는 질문이 섞여 나옵니다. 퇴사 처리를 만들 때 특히 그랬습니다.
| 질문 | 정한 답 |
|---|---|
| 퇴사로 결재선이 비면 문서는? | 앞선 승인이 있어도 자동 반려 |
| 퇴사자가 소유한 프로젝트는? | 그 방 관리자에게, 없으면 처리한 관리자에게 |
| 퇴사자가 맡던 업무는? | 담당 해제 후 만든 사람에게 재배정 알림 |
| 퇴사 처리는 누가 하나? | 관리자, 대상이 관리자면 개발자만 |
첫 줄은 처음 권고안과 다른 답으로 정해졌습니다. 사람 없이 마감되는 문서는 만들지 않고 재기안을 감수하는 보수적인 쪽입니다.
이런 결정을 코드 안에 조용히 박아 두면 나중에 왜 그렇게 움직이는지 아무도 설명하지 못합니다. 표로 뽑아 승인받은 결정은 기록으로 남고, 바꿀 때도 어디를 고칠지 바로 보입니다.
검수 일정이 잡혔다면
맡겨 둔 시스템의 검수를 앞두고 있다면 이 순서로 준비해 보세요.
- 기능 체크리스트를 스펙에서 뽑되, 판정을 완전·부분·없음으로 나누세요. 부분에는 의도적 축소인지 메모를 달아 두세요.
- 연결 목록을 따로 만드세요. 업무를 만들면 피드·알림·캘린더·검색 중 어디에 떠야 하는지 기능마다 적습니다.
- 들어가는 길이 둘 이상인 기능은 길마다 따로 적으세요. 칸반과 피드처럼 같은 업무를 만드는 화면이 둘이면 연결도 두 줄입니다.
- 삭제와 퇴사를 꼭 넣으세요. 만들 때의 연결은 눈에 잘 띄는데, 지우거나 사람이 빠질 때의 연결은 목록에서 자주 빠집니다.
- 전달물 대장을 붙이세요. 회차·날짜·형식·스펙 반영 여부 네 칸이면 충분합니다.
- 정책 질문 목록을 따로 두세요. 개발 쪽이 임의로 정한 동작이 있는지 묻고, 있으면 표로 받아 승인하세요.
이 글의 그룹웨어는 가상 조직과 더미 데이터로 옮긴 시연 데모가 있습니다. 대시보드·프로젝트·회의실 예약·전자결재 화면을 눌러 보면 연결 목록에 어떤 줄이 들어가야 할지 감이 잡힙니다.
지금 만드는 시스템의 스펙과 화면이 있는데 연결 목록을 어떻게 뽑을지 막막하다면, 상담 요청으로 스펙 문서를 보내 주세요. 기능 표 옆에 둘 연결 목록 초안이 첫 산출물입니다.
기능 검수표와 연결 검수표
두 장은 묻는 말부터 다릅니다. 같은 회의에서 함께 펴 놓고 쓰도록 칸을 맞춰 두었습니다.
| 항목 | 기능 검수표 | 연결 검수표 |
|---|---|---|
| 묻는 말 | 이 기능이 있는가 | 만들면 어디에 뜨는가 |
| 한 줄 예 | 업무 우선순위 필드 | 칸반에서 만든 업무 → 피드 글 |
| 판정 칸 | 완전 · 부분 · 없음 | 이어짐 · 부분 · 끊김 |
| 뽑는 곳 | 스펙과 요청서 | 화면 간 동선과 알림 규칙 |
| 이번 결과 | 124건 중 117건 완전 | 33건 중 끊김 7 · 부분 14 |
| 놓치기 쉬운 줄 | 의도적 축소, 늦게 온 회차 | 삭제와 퇴사, 두 번째 진입로 |
| 함께 붙일 문서 | 전달물 회차 대장 | 사람이 정할 정책 목록 |
회의에서 "있는데 안 된다"는 말이 나오면 두 번째 표부터 펴 보세요. 이번에 끊긴 7건 가운데 첫 번째 표에서 빨간불이 켜진 줄은 하나도 없었습니다.
이어서 읽기
정산 프로그램 마진이 실제보다 크게 나올 때, 공식부터 보는 법
정산 앱이 띄운 누적 지사마진이 본사 확정 장부의 약 4.5배였고, 적자인 달 셋을 흑자로 그리고 있었습니다. 장부 항등식은 원 단위까지 맞았는데 화면 공식이 13항목 중 2항목만 보던 사례와 화면을 점검하는 3단계 절차를 적었습니다.

매장 예약 관리, 엑셀 대신 작은 예약 시스템으로 시작하기
담당자별 예약이 메모장과 메신저에 흩어진 매장이라면 업무 전체를 바꿀 필요는 없습니다. 접수와 담당자 일정, 일별 예상 매출만 묶은 예약 화면의 크기를 데모로 짚고 엑셀로 충분한지 가르는 문항과 첫 범위를 적었습니다.

본사 마감 엑셀 양식이 매달 바뀔 때, 업로드가 반만 들어가는 문제
본사가 보내는 월 마감 엑셀은 매달 열이 빠지고 형식이 바뀝니다. 보험대리점 지사의 마감 적재를 다시 만들며 정한 기준, 처음 보는 변화에서 멈추고 넣은 뒤 DB에서 다시 세는 방식을 실제 숫자와 실패까지 함께 적었습니다.