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

Onalign 기획서_v_30 - 문서화·녹음·프롬프트 추출 고도화

by mekite 2026. 8. 3.

Onalign(흩어진 의견을, 하나의 방향으로)

https://onalign.vercel.app/

 

더보기

[게시글 목차]
1. 전원 로그인 방식 최종 확정(v28)
2. 실제 서비스에 맞춰 랜딩페이지 다시 쓰기
3. 로컬 완료와 배포 완료는 다르다(v29)
4. 같은 버그가 다시 나타난 이유
5. 로그인 이후 달라진 온보딩 기준
6. 문서화·녹음·프롬프트 추출 고도화(v30)
7. 버전 관리 인사이트
8. KPT 회고

 

1. 전원 로그인 방식 최종 확정(v28)

🔹결론 : '리더만 로그인, 팀원은 이름만 입력' 방식은 폐기하고 모든 참여자가 구글 계정으로 로그인하는 구조로 확정했다.

  • v28에서 랜딩페이지까지 모든 참여자가 로그인 후 프로젝트에 참여한다는 전제로 다시 작성하기로 했다.
    (구글 아이디 없는 사람은 없겠지...)
구분 기존 전제 v28 확정
리더 구글 로그인 후 프로젝트 생성 구글 로그인 후 프로젝트 생성
팀원 공유 링크 접속 후 이름만 입력 공유 링크 접속 후 구글 로그인
참여 방식 설명 로그인 없이 바로 참여 별도 회원가입 없이 구글 계정으로 합류

함께 수정해야 하는 기존 전제

• 오너와 참여자의 비대칭 로그인 가설

• 로그인 없는 참여가 시작률을 높인다는 기존 설문 가설

• EasyRetro·TeleRetro보다 참여가 가볍다는 기존 비교

  • 대신 링크 하나로 같은 프로젝트에 합류하고,
    참여 기록과 프로젝트 이력을 계정 단위로 이어가는 방향으로 가치 제안을 다시 설명해야 했다.

 

2. 실제 서비스에 맞춰 랜딩페이지 다시 쓰기

🔹결론 : 랜딩페이지는 처음 세운 기획을 설명하는 화면이 아니라, 현재 사용자가 실제로 경험할 제품을 설명해야 한다.

  • 기능은 로그인·회고·문서화까지 확장됐지만,
    랜딩페이지는 여전히 이전 버전의 서비스 흐름을 설명하고 있었다.
  • v28에서는 기능을 더 추가하기보다 랜딩페이지와 실제 제품 사이의 불일치를 먼저 정리했다.
발견한 불일치 수정 내용
팀원도 로그인이 필요하지만 안내 없음 공유 링크 접속 후 구글 로그인으로 참여한다는 문구 추가
서비스 흐름이 4단계에서 끝남 의견 작성 → 문제 정리 → 우선순위 투표 → 회고 → 문서화의 5단계로 확장
프롬프트 추출 기능이 소개되지 않음 '회의가 끝나면, 문서까지' 섹션을 추가해
docx·마크다운·프롬프트 추출을 함께 설명
  • 특히 프롬프트 추출은 단순 보조 기능처럼 보이지만,
    Onalign이 회의를 진행하는 도구에서 회의 이후 정리까지 이어지는 도구로 확장됐다는 점을 보여준다.
  • 기능이 만들어졌다고 사용자에게 가치가 전달되는 것은 아니기 때문에,
    랜딩페이지에서도 실제 사용 흐름 안에 배치해야 했다.

 

3. 로컬 완료와 배포 완료는 다르다(v29)

🔹결론 : '수정했다'는 기록은 로컬 코드가 아니라 실제 배포 환경에서 확인됐을 때만 완료로 볼 수 있다.

  • v27에서는 로그인·권한·공유 링크 관련 기능과 버그 수정이 로컬에서 완료된 상태였다.
  • v29에서야 해당 변경이 커밋·push 되어 실제 서비스에 배포됐고,
    랜딩페이지 개편도 실사이트에서 다시 확인했다.
상태 기준
로컬 완성 개발 환경에서 코드 수정과 기본 테스트가 끝난 상태
배포 완료 원격 저장소에 반영되고 실제 서비스 빌드가 완료된 상태
배포 검증 완료 실제 계정·공유 링크·브라우저에서 사용 흐름까지 확인한 상태
  • 이 구분은 문서상 표현을 엄격하게 만들기 위한 것이 아니라, 실제로 같은 버그가 다시 나타나는 원인을 찾는 데 필요했다.

 

4. 같은 버그가 다시 나타난 이유

🔹결론 : 같은 버그가 재발한 것이 아니라, 서로 다른 버전의 코드를 수정하고 배포하고 있었다.

  • v29 실사용자 테스트에서는 이전에 수정했다고 기록했던 공유 링크 이동 문제와 탭 동기화 문제가 다시 확인됐다.
  • 처음에는 수정이 제대로 되지 않았거나 버그가 재발한 것으로 보였다.
    but, 확인 결과 GitHub 저장소와 로컬 저장소가 7월 15일부터 서로 다른 갈래로 분리돼 있었다.
문제 실제 원인 처리
수정한 버그가 배포 후 다시 나타남 로컬 수정본과 원격 배포본이 다른 히스토리를 가짐 저장소 이력 확인 후 force push로 기준 버전 통일
헤더에만 이름 정제 미적용 동일 표시 로직이 카드와 헤더에 따로 구현됨 헤더에도 같은 이름 정제 로직 적용
schema.sql 재실행 시 오류 삭제하는 정책명과 생성하는 정책명이 다름 정책 이름을 통일해 반복 실행 가능하도록 수정
→ 버전 관리는 코드를 보관하는 일이 아니라, 지금 어떤 상태가 기준인지 같은 답을 갖게 만드는 일에 가까웠다.

 

5. 로그인 이후 달라진 온보딩 기준

🔹결론 : 로그인 전에는 세션을 기준으로 봤던 상태를, 로그인 이후에는 계정을 기준으로 관리할 수 있게 됐다.

  • 기존 온보딩 투어는 접속 세션마다 처음 한 번 노출되는 방식이었다.
  • 로그인이 생긴 이후에는 같은 사용자가 다시 접속했는지를 구분할 수 있으므로,
    세션 단위보다 계정 단위가 더 자연스러워졌다.
기존 변경 이유
세션당 1회 노출 계정당 1회 노출 동일 사용자의 반복 접속 여부를 계정으로 판단 가능
재노출 기준 없음 30일 후 다시 1회 노출 장기 미사용자의 기능 기억을 다시 보조
  • 로그인 기능을 추가하면서 인증 외에도 온보딩, 재방문, 사용자별 설정처럼
    계정을 기준으로 설계할 수 있는 범위가 함께 넓어졌다.

 

6. 문서화·녹음·프롬프트 추출 고도화(v30)

🔹결론 : 유료 AI API를 붙이지 않아도, 입력 방식과 선택지를 다듬는 것만으로 문서화 경험을 더 구체화할 수 있다.

  • v30에서는 새로운 대형 기능보다 이미 구현된 녹음·문서·프롬프트 추출 기능의 사용성을 높일 수 있는 항목을 정리했다.
    모든 제안은 기존 Web Speech API 또는 클라이언트 코드 범위에서 구현 가능한 항목만 남겼다.

6-1. 우선순위 1 : 녹음 충돌 방지

항목 처리 방향
동시 녹음 충돌 방지 누구나 녹음을 시작할 수 있는 기존 권한은 유지하되,
이미 녹음 중이면 다른 참여자의 시작 버튼을 비활성화

6-2. 우선순위 2 : 프롬프트를 목적에 맞게 조정

항목 설명
프롬프트 템플릿 선택 정리 문서, 액션 아이템, 슬랙 공유용 요약, 경영진 보고용 등 목적별 지시문 프리셋 제공
포함 항목 체크박스 회의 녹취록·회고·문제 목록 등 필요한 항목만 선택해 프롬프트 길이 조절
  • 기존 프롬프트 추출은 모든 내용을 하나로 묶어 복사하는 데 초점이 있었다.
    but, 회의 목적에 따라 필요한 결과물은 다르다.
  • AI 기능을 직접 만드는 것보다 어떤 자료를 어떤 형태로 넘길지 선택하게 하는 방식이 현재 서비스 범위에 더 적합했다.

6-3. 우선순위 3 : 출력물과 편집 경험 보강

영역 제안
문서 출력 PDF 내보내기, docx 목차·생성일자 푸터, 특정 시점 문서 스냅샷
녹음 언어 선택, 일시정지와 완전 종료 구분, 녹취록 인라인 편집
프롬프트 추출 복사 전 미리보기, 글자 수 표시, 불필요한 부분 제거
  • 여기서 중요한 것은 기능 수를 늘리는 것이 아니라,
    회의 결과가 실제 다음 업무로 넘어갈 때 필요한 선택지를 제공하는 것이다.

 

7. 버전 관리 인사이트

이번 버전에서는 새로운 기능을 만드는 일보다,

이미 만든 기능과 설명·배포 상태를 맞추는 데 더 많은 시간이 들었다.

(이 버그 찾아서 해결하면 저 버그가 나타나고 저 버그 고치면 다른 버그가 나타난다...

여름이라 그런가 버그가 많네 껄껄)

처음에는 이 작업이 개발 이후의 정리 단계라고 생각했는데,

실제로는 제품 신뢰도와 직접 연결되는 일이었다.

(이것이 유지보수인 걸까나...★)

 

랜딩페이지가 실제 서비스와 다르면 사용자는 들어오기 전부터 잘못된 기대를 갖게 된다.

그래서 작업이 어느정도 완료된 상태가 되면 랜딩페이지 내용도 바꾸는 작업을 같이 진행 중이다.

(이게 또 토큰이 많이 쓰이는 원인이 된다..)

 

이번 작업에서 계속 확인한 것은 '기능이 있는가'보다

'현재 사용자에게 실제로 같은 상태가 전달되고 있는가'였다.

서비스 화면, 랜딩페이지, 기획서, GitHub, 배포 사이트가 각각 따로 움직이면

어느 하나만 맞아도 제품 전체는 맞는 상태가 아니다.

일관성이 잘 유지되고 있는가?를 중점으로 보았다.

 

8. KPT 회고

Keep • 전원 로그인 여부처럼 기존 가치 제안을 바꾸는 결정을 열린 질문으로 남겨두고, 확정된 시점에 랜딩페이지와 기획서를 함께 수정한 점
• 로컬 완성·배포 완료·배포 검증을 구분해 기록한 점
• 유료 AI API를 추가하기보다 현재 기능의 선택지와 사용 흐름을 먼저 고도화한 점
Problem • 로컬 저장소와 GitHub 저장소가 다른 갈래로 분리된 상태를 늦게 발견해, 이미 수정한 버그가 다시 나타난 것처럼 보였음
• 실제 기능이 바뀐 뒤에도 랜딩페이지와 기존 가설 일부가 이전 전제를 유지하고 있었음
• '수정 완료'와 '실제 배포 확인 완료'를 같은 상태처럼 기록했던 구간이 있었음
Try • 각 버전 종료 시 '기획서 → 로컬 코드 → 원격 저장소 → 배포 사이트 → 랜딩페이지' 순서로 상태 대조하기
• 기능 상태를 제안·로컬 구현·배포·배포 검증으로 구분해 기록하기
• 문서화 고도화는 기능 수보다 회의 이후 사용자의 다음 행동이 자연스럽게 이어지는지를 기준으로 판단하기