본문 바로가기
Portfolio/Project 4. Onalign

Onalign(흩어진 의견을, 하나의 방향으로) 기획서_v_21(이전 내용 총합본)

by mekite 2026. 7. 22.

 

서비스 첫화면 캡쳐

 

일을 하며 많은 회의에 참석한 경험과

PM 트랙에 합류하여 프로젝트에 전부 참여해 온 경험을 합쳐

(참고로... 프로젝트가 끝나면 작성하는 팀별 KPT 회고를 다른 팀 내용까지 전부 봤다

장시간 회의는 나만 느끼는 불편함이 아니라 공통적으로 언급되는 내용이었다)

'내가 무언가 할 수 있지 않을까?'라는 생각에 해당 서비스를 기획하고 구현하게 되었다.

 

센터에서 근무할 적, 퍼실리테이션을 처음 접했고,

회의가 재밌게 느껴졌던 기억은 그게...처음이었다....ㅋㅋ..ㅋㅋㅋㅋ

아무튼 신선한 경험에 퍼실리테이션 강사님께 자문을 구하며 어깨너머로 배웠는데,

(의도적으로 교육 기획에 퍼실리테이션 강사 초빙을 넣었다... 사심 만땅)

원래는 전지에 포스트잇을 붙이는 작업을 하고

같은 내용은 병합하고 다른 내용은 구분하며 결론을 도출해 내는 기법이다.

 

일반적인 회의보다 직관적이고 참여형이다 보니

소극적인 팀원도 부담 없이 참여할 수 있는 게 장점이었다.

내가 퍼실리테이션을 강조하는 이유도 이와 같다.

소외되는 팀원 없이 모든 의견을 들어보고,

해당 프로젝트에 대한 이해도를 평준화시키는 것.

 

이것을 해결하기 위해~(발명왕 밥테일st)

퍼실리테이션 기법을 서비스로 만들게 되었다~!

 

이 서비스의 장점은 별도의 텍스트화를 할 필요 없이

포스트잇 내용을 작성하면 문서에 자동적으로 갱신되는 것이다!!!

그리고 '문제로' 올리면 왜 문제로 올렸는지 이유를 작성하게 하고

팀원들이 어떤 문제를 중요하게 생각하는지 우선순위를 도출하기 위해 투표 기능도 넣었다.

(경쟁사 분석 하고 싶은데 없는 모양이다...

왜 없나? 생각해 봤는데 강사도 해 본 입장으로,

재료비랑 강사비 받으려면 실제로 하는 게 좋긴 할 것 같다)

 

아직 테스트 중이라 로그인은 구현 전인데 곧 구현하게 될 것 같다.

 

 

더보기

[게시글 목차]

0. 요약
  🔹왜 (Why) — 문제와 근거
  🔹무엇 (What) — 지금 만들고 있는 것
  🔹어떻게 (How) — 지금까지 만든 것과 확정된 설계
  🔹아직 열려 있는 것
  🔹다음 액션(지금 할 수 있는 것 순서대로)
1. 문제 정의
2. 목표 사용자
3. 경쟁 환경 분석
4. 차별점(가치 제안 가설)
5. 신규 기능 설계: 아이데이션 → 회고 연결
   5-1. 문서 탭 표준 항목 추가
   5-2. 녹음 → 문서 보강 연동 — 무료 구현 가능성 검토(LLM 연동 전, 사용성 검증(리스크 최소화)을 위함)
6. 계정 시스템과 데이터 영구 보존
   6-1. 리더/팀원 화면 분리(예고, 세부 미확정)
7. MVP 범위
   7-1. PRD 4요소 보강(Must 한정, 강의 개념 적용)
8. 검증해야 할 가설과 지표
9. 리스크 및 추가 조사 필요 사항
10. 외부 근거 자료: 회의 비용과 퍼실리테이션 효과
   10-1. 장시간·비생산적 회의 비용
   10-2. 동시에 쓰기'의 학술적 근거
   10-3. NGT 장단점
11. 학술적 근거에 대한 반론과 한계
   11-1. Production Blocking은 EBS에서 다른 이야기
   11-2. 회고 자체의 실증 근거가 얇음
   11-3. 실명 공개 투표의 편향 위험 — 검토 후 실명 유지로 최종 확정
   11-4. 확실한 것 vs 불확실한 것
12. 가설별 사전 판단 기준(설문 배포 전 확정)
13. 배포 현황 및 서비스명
   13-1. 지난 라운드 미확인 사항 → 확인 완료
   13-2. 계획-구현 불일치 → 최종 확정(2차 명세서로 재확인)
     13-3. 5장(아이데이션→회고 연결) — 구현 완료 확인
   13-4. 음성 녹음 기능 — 계획보다 가볍고, 더 완성도 있게 구현됨
   13-5. 그 외 확인된 것
14. 자사 근거 : 캠프 KPT 회고 데스크리서치
15. 로그 설계
16. 에러케이스 / 정책
17. 데이터 드리븐 기획 5단계 검토

 

• 문서 성격 : 외부 마감 없는 개인 프로젝트.
• 서비스명 : Onalign(On+align : 정렬해 나가는 중) 확정
• 🚀배포 : https://onalign.vercel.app (테스트 진행 중, 로그인 구현 전)
• 이 문서의 독자 : 본인 — 의사결정자 겸 실행자를 겸함.
→ so, '누구를 설득할 근거'보다 '다음에 뭘 할지 스스로 판단할 근거'가 우선

 

0. 요약

🔹왜 (Why) — 문제와 근거

  • 캠프 아이디어 회의에서 '문제 정의' 단계에 가장 많은 시간을 쓰고,
    그마저도 서로 다른 말로 같은 문제를 가리키는 걸 못 알아채 회의가 길어지는 걸 직접 관찰했다.
  • 근거는 세 겹이다
    • 본인 관찰(1차)
    • production blocking 등 심리학 이론(보조)
    • 노션 동시편집 데이터 유실 경험(가장 구체적, 엔지니어링적 사실)
      → 외부 회의 비용 통계(연 392시간, 67% 비생산적)와 캠프 KPT 회고 11개 팀 실제 사례로 추가 검증했다(10, 14장).

🔹무엇 (What) — 지금 만들고 있는 것

  • 5~15인 소규모 팀을 위한, 로그인 없이 이름만으로 참여하는 퍼실리테이션 도구.
    의견 작성 → 병합 → 문제 정리 → 우선순위 투표 → 회고(KPT) → 문서화까지 한 프로젝트 안에서 이어진다.
    메인 경쟁자는 EasyRetro/TeleRetro이며,
    이들과 달리 '아이데이션과 회고를 잇는다'는 게 가장 방어력 있는 차별점이다(3, 4장).

🔹어떻게 (How) — 지금까지 만든 것과 확정된 설계

  • 구현 완료 : 의견 작성(다중 보드, 병합, 보류함), 문제 정리, 우선순위 투표, 회고 탭(참여자별 KPT·개인 단위 완료·우선순위 해결여부 토글), 문서 탭(표준 4필드, 녹음→녹취록 반영), 랜딩페이지 개편(7, 13장)
  • 의도적으로 미룸 : 로그인(테스팅 완료 시점 착수), 그에 종속된 리더/팀원 화면 분리·수익화(6장)
  • 알면서 택한 트레이드오프 : 투표는 익명 대신 상시 실명 — '누가 왜 투표했는지 물어볼 수 있어야 한다'는 1장 원칙의 연장(11-3장)

🔹아직 열려 있는 것

  • 5~8인 규모에서 동시 작성이 실제로 효과 있는가 — 학계도 결론 없음(11-1). 실사용 로그로만 판단 가능
  • 회고가 실제로 팀에 도움이 되는가 — 실증 연구 자체가 얇음(11-2).
    → '회고를 잘하게' 보다 '완료 전환율'부터 확인하는 게 현실적

🔹다음 액션(지금 할 수 있는 것 순서대로)

  • 12장 설문 배포(캠프 내부+외부 최소 15~20건)
  • 사전 판단 기준(12장)과 응답 대조, 유리하게 재해석하지 않기
  • 로그인은 테스팅이 얼추 끝난 뒤 착수
    (언젠가는 하겠지.. 언젠가는...)

 

 

1. 문제 정의

🔹결론 : 문제는 '발언 부족'이 아니라 '서로 다른 말로 같은 문제를 가리키는 걸 못 알아챔'이다.

  • 출발점 : 시장조사가 아니라 캠프 아이디어 회의 관찰
    • 시간 대부분을 '문제 현상/문제 정의'에 씀
    • 상대 의도를 못 알아채 회의가 길어짐
  • 기존 워크플로우(의견 → 병합 → 문제 정리)와의 정합성 확인
    • 원래도 '의도가 겹치는 의견을 눈에 보이게 모으는' 구조였음
    • 풀어야 할 병목은 '말 못 함'이 아니라 '수렴 안 됨'

🔹근거 축 3가지(우선순위 순)

  1. 본인 관찰(1차 근거) — 캠프 회의에서 직접 겪음
  2. 외부 조사(보조 근거) — 직장인 약 절반이 침묵, 원인은 두려움보다 무력감
  3. 노션 동시편집 버그(가장 구체적, 신규) — 같은 자리 동시 편집 시 데이터 유실 경험
    • 포스트잇마다 편집 영역 분리 → 동시 충돌 원천 차단
    • 심리학 이론과 무관한 엔지니어링적 사실, 논문 불필요

+) 독립 설계 목표 : '재미있게' — 생산성 축과 무관, 10~11장 학술 근거로 정당화/반박 대상 아님

 

※ 정확히 하자면: 실제 구현은 완전 독립 저장이 아니라 "최신 상태 재조회 후 내 항목만 반영" 방식 — 충돌 확률을 낮추는 것이지 원천 차단은 아님.

 

가설 1

포스트잇 분리 시 (a) 동시편집 데이터 유실 방지 [사실에 가까움] + (b) 의도 파악 실패로 인한 지연 감소 [검증 필요]

→ 남은 숙제 : 지금의 '병합'은 누군가 먼저 '같은 얘기다'라고 알아채야 작동 → '알아채지 못하는 순간' 자체는 못 없앰(5장 이후 계속)

 

2. 목표 사용자

🔹결론 : 1차 타깃은 이미 문제를 겪고 있는 게 확인된 집단(캠프)이다.

(하지만 대학 운영팀 종사자가 서비스 배포 완료되면 학생들에게 사용하게끔 하고 싶다는 제의가 들어왔다)

  • 1차 타깃(확정) : 캠프의 5~15인 소규모 팀
    • '문제 현상 정의' 단계에 시간 최다 소요 + 의도 불일치 경험 그룹
    • 10장('첫 실사용자 = 본인 팀')과 정확히 일치
  • 2차 확장 타깃(v1 범위 밖) : 프로덕트/디자인 팀, 애자일 코칭 조직
    • 전제조건 : 아이디어 회의 자체를 이 도구로 진행 — 검증 예정

 

3. 경쟁 환경 분석

🔹결론 : EasyRetro/TeleRetro가 메인 경쟁자다. '아이데이션-회고 연결'을 가볍게 제공하는 도구는 없다.

  • 시장 카테고리: 'Brainstorming Software' ↔ 'Retrospective/Agile Facilitation Tools' 사이(후자에 더 가까움).
    → 두 카테고리에 걸쳐 있다는 것 자체가 4장 핵심 차별점.
도구 성격 강점 약점(기회)
EasyRetro 회고 전용, 링크 참여 가볍고 무료, 템플릿 250개+ 세션 간 연결 없음(킥오프-아이데이션 미연결)
TeleRetro 회고 전용 + 펄스 서베이 세션 사이 팀 상태 추적 가능 연결이 "분위기"에 한정, 목표·우선순위와는 무관
ClickUp/monday/
Notion (참고)		 범용 업무관리 + 회고 템플릿 회고-작업(Task) 연결 가능 무겁고, 워크숍 특유의 동시작성 경험 약함
  • 핵심 발견: 아이데이션(시작 시점 우선순위)과 회고(종료 시점 회고)를 같은 프로젝트 안에서 가볍게 잇는 도구
    ⇒ 조사 범위 내 없음 → 5장 근거
  • 기타 확인 사실
    • 투표 기능(익명·인당 제한·자동집계) 불만이 FigJam 커뮤니티에 반복 제기
    • 협업 화이트보드 시장 : 20억~45억 달러(2025~26), 연 12~20% 성장
      → 단, 범용 시장 수치이며 회고 전용 소도구 시장 크기는 자료 없음

 

4. 차별점(가치 제안 가설)

🔹결론 : 5가지 차별점 중 방어력이 가장 큰 건 '아이데이션-회고 연결'이다. 전부 미검증 가설이다.

/ 차별점 핵심
1 오너는 계정, 참여자는 이름만 영구 기록 + 참여 마찰 제로 동시 확보 (6장)
2 하나의 흐름에 특화 의견→병합→문제정리→투표 강제, 산으로 안 감
3 프로젝트별 저장/재방문 회고는 반복 행위 — 이력이 쌓이는 구조
4 이미지 한 장 요약 별도 정리 작업 불필요
5 아이데이션-회고 연결 (신규) 시작 때 우선순위를 종료 시 회고에서 재확인 — 방어력 최대

 

 

5. 신규 기능 설계: 아이데이션 → 회고 연결

🔹결론 : '회고' 탭이 5번째 탭으로 상시 존재하고, 참여자 각자 KPT를 작성·완료하며, 완료할 때마다 그 사람 몫이 문서 탭에 반영된다. 우선순위 해결여부 체크는 토글로 켜고 끌 수 있다.(v18, 확정 — 5장 설계 완료)

  1. 탭 구성 : 의견 작성 → 병합 → 문제 정리 → 우선순위 결과 → 회고
    (5개 탭 상시 노출, 이전 설계의 '완료 버튼으로 잠금 해제' 방식에서 단순화됨)
  2. 회고 포맷 : KPT(Keep-Problem-Try), 참여자 수만큼 입력 칸 제공 — 누가 작성했는지 이름과 함께 표시(실명, 병합/문제 등 다른 기능과 일관된 방식)
  3. '완료' 버튼 : 참여자 개인 단위 — 팀 전체를 기다리는 게이트 없이, 각자 자기 KPT를 다 쓰면 자기 버튼만 누름 → 그 사람 몫이 '과정 문서'와 '결과 문서' 양쪽에 반영됨. 완료 후에도 잠금 없이 자유롭게 재수정 가능
  4. 우선순위 해결여부 체크 (토글, 확정) : 회고 탭 상단에 ON/OFF 토글스위치
    • ON : 아이데이션 우선순위 상위 문제 목록 + 해결됨/부분해결/미해결 체크 섹션이 참여자별 KPT 입력칸 위에 표시
    • OFF : 이 섹션 없이 KPT 입력칸만 표시
    • 기본값 : ON (핵심 차별점 요소이므로 기본 노출, 문제 정의로만 끝난 프로젝트는 팀이 직접 꺼서 숨김)
    • 토글 권한 : 참여자 누구나 (되돌리기 쉬운 화면 설정이라 리더 전용 아님)
    • 근거 : '이 회의가 문제 정의만 할 예정이었는지, 해결방안까지 도출하는지는 팀마다 다르다'는 판단 — 강제 노출이 아니라 선택 가능하게 둠

※ 의도적 제외 : 액션 아이템 담당자·마감일·Jira 연동 → ClickUp/monday 영역, 체급 밖

 

📌 확정 이력


질문 결론
우선순위 문제 자동 표시 + 해결여부 체크를 회고 탭에 유지할지 ✅ 유지, 단 ON/OFF 토글로 (기본 ON)
"완료" 버튼 권한 ✅ 참여자 개인 단위, 팀 전체 게이트 없음
"완료" 후 개별 KPT 재수정 가능 여부 ✅ 잠금 없음, 언제든 자유 수정
프로젝트 상태(진행중/완료) 필드를 별도로 둘지 ✅ 제외 — 완료가 개인 단위라 불필요

 

5-1. 문서 탭 표준 항목 추가

🔹결론: '과정 문서'·'결과 문서' 둘 다 목적/배경/추진방향/기대효과 4개 필드를 공통으로 갖고, 인라인 편집 가능해야 한다.

필드 적용 대상 비고
목적 과정 문서 + 결과 문서 공통 인라인 편집
배경 과정 문서 + 결과 문서 공통 인라인 편집
추진 방향 과정 문서 + 결과 문서 공통 인라인 편집
기대 효과 과정 문서 + 결과 문서 공통 인라인 편집
  • 기존 콘텐츠(과정 문서: 개요·참여자·의견모음·문제정리 / 결과 문서: 개요·우선순위 TOP5)는 이 4개 필드 아래에 이어지는 구조로 배치
  • HTML/마크다운/이미지 내보내기 전부에 이 4개 필드 포함
  • 4개 필드는 프로젝트 단위로 한 번만 입력하면 과정/결과 문서 양쪽에 동일하게 반영 (별도로 두 번 입력하지 않음)

5-2. 녹음 → 문서 보강 연동 — 무료 구현 가능성 검토(LLM 연동 전, 사용성 검증(리스크 최소화)을 위함)

🔹결론 : 텍스트를 문서에 넣는 것 자체는 무료로 가능하다. 다만 무관한 두 가지 무료 티어 리스크가 있다.

  • 텍스트 이관 자체 : 추가 비용 없음. 텍스트는 용량이 작아 Supabase 무료 DB(500MB)로 충분
    ⚠️ 기기 커버리지 리스크 : Web Speech API는 Chrome/Edge 데스크톱에서만 안정적. iOS Safari 등 모바일 브라우저는 지원이 불안정하거나 미지원 — 참여자 일부 기기에서 녹음 자체가 안 될 수 있음
    ⚠️ Supabase 무료 티어 운영 리스크(녹음과 무관, 프로젝트 전체에 해당) : 7일간 DB 요청 없으면 프로젝트 자동 일시정지(2026년 기준 여전히 유효).

 

6. 계정 시스템과 데이터 영구 보존

🔹결론 : '로그인 없음'과 '영구 기록'은 오너/참여자 역할을 나누면 둘 다 지킬 수 있다.

  • 충돌 지점 : '로그인 없음' = 참여자 마찰 제거용. 이번 요청(영구 기록) = 오너의 소유권·영속성 문제 → 다른 축
  • 절충 해법
    • 오너 : Google/GitHub 로그인, 계정에 프로젝트 귀속
    • 참여자 : 기존과 동일, 이름만 입력
  • ✅ 확인 완료: 참여자는 로그인 없이 링크 참여 유지. 리더가 프로젝트를 생성하고 링크를 공유하는 구조로 확정
  • ✅ 구현 시점 확정(v20): 로그인 기능은 테스팅이 대략 완료되는 시점에 착수 예정. 지금은 의도적으로 미루는 것 — 6-1(리더/팀원 화면 분리), 수익화(무료 한도) 등 로그인에 종속된 항목들도 자연히 같은 시점 이후로 순연됨

6-1. 리더/팀원 화면 분리(예고, 세부 미확정)

  • 리더 로그인이 구현되면 리더와 팀원은 다른 화면을 보게 될 예정이다.
    구체적으로 무엇이 갈릴지는 로그인 기능을 실제로 설계하는 시점에 다시 다룬다
    → 지금은 랜딩페이지 카피에 이 방향성만 반영한다.
  • 예외 하나 확정 : 회의 녹음(15장 3번)은 팀 전체에 영향을 주는 되돌리기 어려운 결정이 아니라
    개인이 켜고 끄는 선택 기능이라, 리더 전용이 아니라 참여자 누구나 가능하도록 확정했다.
  • 기술적 전제 : OAuth는 실제 도메인·백엔드·DB 필요 → Claude 아티팩트 환경 불가능 → 프로토타입에서 실배포 앱으로 전환 신호
  • 구현 옵션(난이도 낮은 순) : Supabase Auth(DB 포함) > Clerk(UI 완제품, DB 별도) > Auth.js(자유도 높음, 조립 많음)
  • 수익화 (확정)
    • 계정당 무료 프로젝트 개수 제한(ex. 2개) → 초과 시 구독/건당 결제
    • DB 설계 시부터 '사용자-프로젝트' 1:N이 아니라 사용자에 plan·사용량 필드 포함
    • 정확한 숫자·가격은 보류 (데이터 없이는 추측) — 지금은 '구조만' 준비, Stripe 연동은 이후 결정

 

7. MVP 범위

🔹결론 : 세 번의 방향 전환(좁히기→넓히기→계정 추가) 후 지금 구조. 계정 시스템은 기능이 아니라 인프라 결정.

구분 항목 비고
Must 이름 기반 참여, 색상 자동 배정 구현 완료
Must 포스트잇 작성/삭제, 보드 내 병합 구현 완료
Must 문제 정리, 우선순위 투표 구현 완료
Must 프로젝트별 저장/재방문 구현 완료
~~Must~~
(제외 확정, v18)		 ~~프로젝트 상태(진행중/완료) 필드~~ 회고 완료가 개인 단위로 확정되며 불필요해짐 — 7장에서 제외
Must
구현 완료(13-3 확인)		 "회고" 탭(5번째) → 참여자별 KPT 입력 5장 참조. 2차 명세서로 구현 확인
Must
구현 완료(13-3 확인)		 회고 "완료" 시 과정/결과 문서 양쪽에 반영 5장 참조. 개인 단위 완료 게이트까지 정확히 구현 확인
Must
구현 완료(13-3 확인)		 문서 탭 표준 4필드(목적/배경/추진방향/기대효과) 5-1장 참조. 과정·결과 문서 공통, 구현 확인
Should 이미지 내보내기(아이데이션+회고 통합) 기능 확장
Should 다중 의견 보드 수요 미검증
Should
구현 완료		 보류함(파킹랏) 캠프 KPT "미결 안건 기록 누락" 대응, 2차 명세서로 구현 확인
Should
구현 완료		 프로젝트 목표 한 줄 고정 캠프 KPT "목표 미합의" 대응, 2차 명세서로 구현 확인
Should
구현 완료(13-4 확인)		 회의 녹음 → 텍스트 변환(발화자 구분 없음) Web Speech API(브라우저 내장, 무료). 문서 탭 "회의 녹취록"에 직접 반영, 유료 전환 근거는 소멸
Could 실시간 동기화 고도화(폴링→웹소켓) 인원 증가 시 재검토
Could 회고 포맷 다양화 수요 확인 후
Could → 재검토 완전 익명 모드 "이름 기반" 차별점과 충돌 → 11-3 절충안으로 좁힘
Out of scope 담당자·마감일 지정, Jira/Slack 연동 범용 업무관리 영역, 의도적 제외
인프라
(기능 아님)		 OAuth 오너 로그인 + 실배포 6장 참조
인프라
(기능 아님)		 프로젝트 생성 횟수 카운트 + 결제 전환 6장 참조

 

7-1. PRD 4요소 보강(Must 한정, 강의 개념 적용)

기능 이름 기능 설명 우선 순위 구현 기준
이름 기반 참여 로그인 없이 이름 입력 → 색상 자동 배정 Must 재방문 시 자동 입장
포스트잇 작성/병합 자유 텍스트, 2개 이상 선택 시 병합 Must 병합 후 원본 텍스트·작성자 전원 보존
문제 정리·투표 문제 표시→상단 고정, 항목당 1표·전체 한도 Must 중복투표 차단 UI, 한도 소진 시 버튼 비활성화
프로젝트별 저장 프로젝트 단위 영구 저장 Must 기기·새로고침 무관 데이터 유지

 

8. 검증해야 할 가설과 지표

🔹결론 : 가설 9개(A~I) 중 H·I는 설문으로 검증 불가 — 실사용 로그·별도 실험 필요.

가설 핵심 상태
A 로그인 없음이 세션 시작률을 높인다 미검증
B 항목당 1표 규칙이 만족도를 낮추지 않는다 미검증
C 프로젝트 재방문이 실제 발생한다 미검증
D 같은 팀이 아이데이션→회고까지 이어 쓴다 미검증
E 오너-참여자 로그인 비대칭이 자연스럽다 미검증
F 병합이 의도 파악 실패를 줄인다 (단, 병합은 "알아챈 사람" 필요 — 5장 한계 연결) 미검증
G 무료 한도 초과 반복사용자가 존재한다 미검증
H 5~8명 소규모에서도 동시작성이 효과적이다 설문 검증 불가, 근거 가장 약함
I ~~"투표 중 익명·종료 후 공개" 절충안~~ → 기각, 실명 유지로 확정 (v20, 11-3 참조) 결정 완료, 검증 불필요
[측정 지표]
• 세션 완료율 / 세션당 평균 참여자·포스트잇 수 / 재방문율
• 이미지 내보내기 사용률 / 프로젝트 완료 전환율 / 계정당 프로젝트 생성 개수 분포
→ 위 지표를 계산할 원본 로그 설계는 16장 참조 (강의 개념 검토 결과 누락 확인)

 

9. 리스크 및 추가 조사 필요 사항

🔹결론 : 가장 큰 리스크는 '범위 확장'과 '간격 문제' — 둘 다 지금 구조의 근본 가정과 직결된다.

  • 동시편집 한계 : 2초 폴링, 10명↑ 동시 작업 시 지연·충돌 가능 — 실사용 규모 확정 필요
  • 시장 크기 불명 : 회고 전용 소도구만의 시장 자료 없음 — 정성 인터뷰(5~10팀)가 더 효율적
  • 차별점 지속가능성 : 로그인 없음/워크플로우 특화는 Miro/FigJam이 쉽게 모방 가능.
    아이데이션-회고 연결도 EasyRetro/TeleRetro가 '이전 세션 불러오기' 하나만 추가하면 좁혀짐
  • 범위 확장 리스크 : 아이데이션+회고 통합 = '한 곳에서 다 됨' 장점 + '둘 다 어중간' 위험 공존
  • 간격 문제 : 분기 단위 프로젝트는 팀 재방문 확률↓, 스프린트 단위(1~2주)는 연결이 자연스러움 → 목표 사용자 재조정 가능성
  • 프로토타입 → 실앱 전환 리스크 : 계정 시스템 도입 = 호스팅 비용·개인정보 처리·OAuth 검수 책임 발생.
    → 전환 시점은 별도 의사결정 필요

 

10. 외부 근거 자료: 회의 비용과 퍼실리테이션 효과

🔹결론 : 캠프 설문(호의적 편향 위험)과 무관한 외부 문헌으로 '문제 실재 여부 / 메커니즘 근거 / 한계'를 각각 확인했다.

10-1. 장시간·비생산적 회의 비용

지표 수치 출처
연간 회의 시간 평균 392시간/년 Fellow, 2025
비생산적 인식 67% Fellow, 2025
집중력 손실 30분 내 52% Flowtrace, 2025
경제적 손실(미국) 2,590억~3,990억 달러 (편차 큼) HBR/Laxis, 2026
손실 인시 연 약 240억 인시 Laxis, 2026
업무 방해 78%가 본업 지장 Speakwise, 2026
회의 후유증 76% 완전 소진 Speakwise, 2026
안건 없는 회의 반복 64%, 일회성 60% Flowtrace, 2026
※ 주의 : 손실 금액은 기관별 편차 큼 → 인용 시 '약 2,600억~4,000억 달러' 범위 표기 권장

 

10-2. 동시에 쓰기'의 학술적 근거

연구 핵심 연결
Production Blocking
(Diehl&Stroebe, 1987/91)		 발언 순서 대기 구조가 생산성 저하 유발 실증 동시 작성 설계의 이론적 근거
메타분석 (Mullen et al., 1991) 개인 작업이 그룹 대비 평균 83% 더 많은 아이디어 정량적 근거
NGT (Delbecq&Van de Ven, 1975~) 침묵 작성→공유→명확화→투표 구조가 동조 감소 현재 워크플로우와 구조적 동일

 

10-3. NGT 장단점

구분 내용
장점 동등 참여 보장, 시간 절약, 아이디어量 증가, 종결감 제공
단점 한 번에 한 주제만(→다중 보드로 대응 중)
단점 숙련 퍼실리테이터·준비시간 필요(→온라인 경량화로 상당수 해소 주장 가능)
단점 초기 침묵 단계 즉흥성 제한(→병합이 보완하는지 검증 필요)

 

10-4. 문서 반영 요약

대상 반영 내용
1장 캠프 관찰(1차) + production blocking(보조)
가설 F 핵심 효과는 병합보다 '동시 작성' 단계 — 검증 우선순위 조정
4장 '숙련 퍼실리테이터 불필요' 포지셔닝 근거
7장 다중 보드 = NGT 약점 선제 대응
위 표는 유리한 근거만 모았을 위험 → 11장에서 반론 별도 정리

 

11. 학술적 근거에 대한 반론과 한계

🔹결론 : 반박 가능한 지점이 최소 2곳(11-1, 11-3) 있고, 1곳(11-2)은 업계 관행 자체의 약점이다.

11-1. Production Blocking은 EBS에서 다른 이야기

  • Diehl&Stroebe(1987)는 대면 회의 전제 — 타이핑 방식은 '전자 브레인스토밍(EBS)' 별도 범주
  • Dennis&Valacich(1993) : EBS는 production blocking 사실상 없음 (유리)
  • BUT Dennis&Valacich(1999) : EBS 우위는 9명↑ 큰 그룹부터. 5~8명은 개인작업과 차이 없거나 미결론
  • BUT Pinsonneault et al.(1999) : EBS 우위 자체가 "착시(illusion)"일 수 있다는 반박, 논쟁 진행 중
    → 함의 : 목표 사용자(5~15명) 중 5~8명 구간은 학계 미결론 영역.
    가설 F는 '5~8명에서는 성립 안 할 수도 있다' 전제로 재작성 필요

11-2. 회고 자체의 실증 근거가 얇음

  • 회고는 압박 시 가장 먼저 부실화/생략되는 관행으로 반복 보고
  • 게임형 회고 개선 시도의 효과 근거는 거의 없음
  • 학생 팀 실증 연구 : 성찰 수준이 피상적
    → 함의: 4장 차별점 5번이 '학계도 증명 못한 가정' 위에 있음.
    '회고를 더 잘하게'보다 '회고를 하긴 하게'(완료 전환율)에 먼저 집중이 현실적

11-3. 실명 공개 투표의 편향 위험 — 검토 후 실명 유지로 최종 확정

  • 닷보팅 : 명시 기준 없어 편향·위계·지배적 목소리에 왜곡 가능
  • 공개 투표 : 다수/영향력자 쏠림 위험, 익명 투표 권고 다수

11-4. 확실한 것 vs 불확실한 것

가정 확실성
대면 발언 순서 대기 → 생산성 저하 확실(40년 검증) — 단, 우리는 디지털이라 그대로 적용 안 됨
디지털 동시작성, 5~8명에서도 효과 불확실(11-1)
NGT 구조가 동등 참여 보장 비교적 확실(단점 존재)
회고가 팀에 도움 생각보다 약함(11-2)
실명 투표가 공정한 결과 반대 증거 있음 — 알면서 실명 유지로 확정(11-3, v20)

 

12. 가설별 사전 판단 기준(설문 배포 전 확정)

🔹결론 : 응답 15~20건 이상부터 아래 기준과 결과를 '대조만' 한다(기준은 사후에 변경 X).

가설 문항 통과 기준 기각 기준 처리
문제 재정의 2-2 ≥60% <40% 40~60% 애매, 자유응답 보완 판단
A (로그인 없음) 4-1 평균≥4.0/60%↑ 평균<3.0 낮아도 유지(비용 낮음, 확신 약함만 기록)
B (1표 규칙) 4-3 "나쁘다"<30% >45% 30~45% 온보딩 보강, 45%↑ 선택형 전환 검토
D (연결 수요) 5-1, 3-4 평균≥3.5 & 1~2주↑40% 평균<3.0 낮으면 4장-5번 Should로 하향
E (로그인 비대칭) 6-1, 6-2 평균≥3.5 참여자계정 원함>40% 높으면 참여자 계정 재검토 승격
F(b) (병합 효과) 4-2 평균≥3.5 평균<3.0 낮으면 유사의견 자동감지 장치 필요
G (수익화 임계) 7-1 "4개+"≥20% <10% 20%↑ 한도 2~3개, 10%↓ 한도 5개+
H (5~8인 효과) — 설문 불가 — 실사용 로그로만 판단, 보류
I (투표 절충안) — — — 기각 확정(v20), 실명 유지로 결정됨 — 판단 기준 불필요

 

13. 배포 현황 및 서비스명

🔹결론 : 저장 방식·'문서' 탭 정체는 확인 완료. 대신 계획-실구현 사이 불일치 2건과 미구현 1건을 새로 발견했다.

13-1. 지난 라운드 미확인 사항 → 확인 완료

항목 확인 결과
데이터 저장 방식 이원화 확인 : 참여자 이름 재진입 기억=localStorage(클라이언트), 프로젝트/보드 데이터=Supabase(서버)
'문서' 탭의 정체 5장 회고(KPT) 화면이 아님. 과정 문서/결과 문서(TOP5)를 HTML·마크다운·이미지로 내보내는 리포트 화면으로 확인됨

 

13-2. 계획-구현 불일치 → 최종 확정(2차 명세서로 재확인)

항목 상태
우선순위 투표 위치 ✅ '우선순위 결과' 탭에서 투표하는 것으로 최종 확정. 2차 명세서에서도 동일하게 재확인되어, 의도적 설계로 받아들이고 5·7장 서술을 이 기준으로 정리한다
투표 익명 절충안
(11-3, 가설 I)		 ✅ 결정 완료(v20). 절충안을 기각하고 상시 실명 공개로 확정 — 이유는 '누가 왜 투표했는지 궁금할 수 있다'는 것, 1장 되묻기 원칙의 연장선. 편향 위험은 인지한 채로 감수하는 트레이드오프로 명문화(11-3 참고)

 

13-3. 5장(아이데이션→회고 연결) — 구현 완료 확인

  • 2차 명세서(6. 회고)로 v18 설계와 전부 대조 확인됐다 : 참여자별 KPT(본인 칸만 편집), 개인 단위 '완료'
    (완료 안 한 회고는 문서 미반영, 완료 후에도 수정 가능하고 수정 즉시 문서 반영),
    우선순위 해결여부 토글(기본 켜짐) — 설계와 구현이 정확히 일치. 남은 열린 질문 없음.

13-4. 음성 녹음 기능 — 계획보다 가볍고, 더 완성도 있게 구현됨

  • 계획(15장 3번)은 Whisper 등 외부 STT + 서버리스 함수를 전제했는데,
    실제로는 브라우저 내장 Web Speech API로 구현됐다.
  • 2차 명세서 세부 사항 갱신 → 갱신 내역 ▼
    • 서버·외부 API 비용 없음 → '유료 플랜 전용 기능' 후보였던 수익화 근거는 소멸(6장 참고)
    • 대신 Chrome/Edge 한정, 브라우저 자동 종료 시 재시작 필요 등 제약 존재
    • 연동 방식이 애초 요청(Q3, '문서 내용 보강')대로 확정 : 녹음 중지 시 결과가 '포스트잇으로 저장'이 아니라 문서 탭 '회의 녹취록'에 직접 반영되는 것으로 최종 구현됨 — 5-2장의 목적과 정확히 일치
    • 신규 확인 : 중복 문장·단어 정리(요약은 아님) 기능, .txt 다운로드 추가
    • 권한 거부·미지원 브라우저 예외 처리 포함 → 17장 정책과 일치, 상태를 '제안'에서 '구현 완료'로 변경

13-5. 그 외 확인된 것

  • 온보딩 투어가 11단계로 확장(회고·문서 표준 필드 추가에 따른 자연스러운 증가),
    대상 요소가 없을 때도 흐름이 끊기지 않도록 복원력 보강
    → 이전에 지적했던 '화면 벗어남' 버그 수정에 이어지는 개선으로 보임
  • 데이터 모델 원칙('원본 하나, 표시만 여러 곳')이 문제/보류/투표/해결여부/회고까지
    일관되게 적용된 것을 명세서 '데이터 모델 메모'에서 명시적으로 확인
    → 설계 원칙이 코드 레벨에서도 지켜지고 있음

 

14. 자사 근거 : 캠프 KPT 회고 데스크리서치

🔹결론 : 11개 팀 실제 회고에서 이 기획서 가설과 겹치는 패턴 5개 확인(실명은 전부 익명 처리).

패턴 내용(익명화) 연결
미결 안건 기록 누락 미룬 항목 미기록 → 다음 회의 시 팀원마다 다르게 기억, 혼란 15장 신규 기능 근거
확정/논의중 미구분 최종안 못 찾음, 중복 논의 발생 '문제로 상단고정' 기능이 정확히 겨냥
→ 설계 방향 실증
목표 미합의 진행 결과물 완성 후 서로 다른 정의였음을 인지.
한 팀은 'align' 단어 직접 사용		 1장 핵심 재정의 실증, 서비스명과 우연 일치
인원↑ 동기화비용↑ 6인 팀, 조율에 매일 추가시간 소요, 피로 누적 가설 H(5~8인 효과)에 대한 실제 사례 1건
(표본1, 방향성 지지)
주제 이탈 논의 중 이탈로 회의 장기화 4장 차별점 1번과 정확히 일치
※ 한계 : 무작위 표본 아님(같은 캠프), 12장 설문과 유사 편향.
단, Onalign 존재 전 작성된 회고라 확증편향보다 '우연한 실증'에 가까움

 

15. 로그 설계

  • 출처 구분: pageview/event 구분 프레임워크 = 강의 개념. 아래 구체 스키마 = 필자 적용
종류 이벤트명 속성 대응 지표
pageview tab_view project_id, tab_name, timestamp 세션 완료율
event note_created project_id, note_id, user_name, timestamp 평균 포스트잇 수
event note_promoted_to_problem project_id, note_id, timestamp 문제정리 도달 여부
event vote_cast project_id, note_id, user_name, timestamp 투표 참여율
event project_status_changed project_id, from_status, to_status, timestamp 완료 전환율
→ '의견작성→문제등록→투표→완료' 깔때기 구성 가능. 실구현 시 이벤트명·속성 변경 가능성 있음

 

16. 에러케이스 / 정책

  • 출처 구분: '실패 케이스를 정책으로 정의' 프레임워크 = 강의 개념. 개별 케이스·정책 = 필자 판단
케이스 문제 소지 제안 정책
투표권 동시 소진 충돌 2초 폴링 구조상 동시 사용 시 유실/초과 가능 저장 시점 서버 잔여 재확인, 초과 시 후순위 요청 거부+알림
저장 실패(네트워크) Supabase 저장 실패 시 입력 유실 가능 재시도 안내 + 로컬 임시보관 후 재전송
오너 계정 이탈 오너 삭제/이탈 시 참여자 접근권 불분명 오너 삭제 시 프로젝트 읽기 전용 전환
동명이인 충돌 같은 이름 2인 참여 시 구분 불가 재입력 시 자동 구분자 부여(지연, 지연_2)
녹음 중 미인지
(신규, 15장 3번 연결)		 누군가 녹음을 시작해도 다른 참여자가 모를 수 있음 — 개인 선택 기능이라도 진행 중임은 전원이 알아야 함 녹음 중에는 상단에'🔴녹음 중' 배지를 모든 참여자 화면에 상시 노출

 

17. 데이터 드리븐 기획 5단계 검토

  • 출처 구분: 5단계 프레임워크 = 강의 개념. 단계별 평가 = 필자 판단
단계 상태 이유
문제 정의 충분 관찰+이론+실사례 3중 근거
데이터 수집·분석 부분적 외부·자사 데이터는 완료, 1차 설문은 계획 단계
가설 수립·실험 가설 강함/실험 약함 H·I 실험설계(표본·기간·기준) 뼈대만 존재
결과 분석·의사결정 기준만, 실행 전 데이터 미수집 — 진행단계상 당연한 공백
지속 개선 암묵적 존재만 재검토 주기 미명시

 

⚠️ 지속 개선 재검토 시점

• 설문 응답 20건 이상 도달 시

• 실사용 배포 후 4주 경과 시

• Could 항목 실행 결정 시

 

더보기

[참고 자료]

'Portfolio > Project 4. Onalign' 카테고리의 다른 글

Onalign 기획서_v_27 - 구글 간편 로그인 구현 및 권한 설정  (0) 2026.07.29
Onalign 기획서_v_24 - 문서 저장법 수정 및 프롬프트 추출 기능 추가  (0) 2026.07.27

관련글

티스토리툴바