Onalign 기획서_v_27 - 구글 간편 로그인 구현 및 권한 설정

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

https://onalign.vercel.app/

[게시글 목차]
1. 로그인 착수와 권한 기준 구체화(v25)
2. 로그인이 바꾼 참여 구조(v26)
3. 권한은 UI와 DB에서 이중으로 막기
4. 실사용자 테스트에서 발견한 버그(v27)
5. 새롭게 정리된 설계 원칙
6. 버전 관리 인사이트
7. KPT 회고

 

1. 로그인 착수와 권한 기준 구체화(v25)

🔹결론 : 로그인은 단순한 진입 기능이 아니라, 프로젝트 소유권과 참여자 권한을 실제 시스템 규칙으로 바꾸는 작업이었다.

• 이전까지는 모든 참여자가 거의 같은 권한으로 기능을 사용할 수 있었지만,
  계정이 생기면서 '누가 프로젝트를 소유하는가'와 '어떤 기능을 누가 변경할 수 있는가'를 구분해야 했다.
• 처음에는 리더와 팀원의 화면을 크게 나누는 방식으로 생각했지만,
  실제로는 화면 전체보다 행동의 영향도와 되돌릴 수 있는지를 기준으로 권한을 구분하는 편이 자연스러웠다.

기능	권한	판단 기준
STEP 안내 문구 편집	리더 전용	회의 진행 기준을 바꾸는 설정
1인당 투표권 수 조정	리더 전용	결과에 직접 영향을 주는 운영 정책
프로젝트 삭제	리더 전용	되돌릴 수 없는 파괴적 행동
포스트잇 작성·병합·문제 표시·투표	참여자 누구나	회의 참여 과정에서 공동으로 수행하는 행동
문서 다운로드·프롬프트 추출	참여자 누구나	읽기·내보내기 성격으로 원본을 훼손하지 않음
→ 권한을 직급처럼 나누기보다, 해당 행동이 팀 전체에 미치는 영향과 복구 가능성을 기준으로 나눈 셈이다.

 

2. 로그인이 바꾼 참여 구조(v26)

🔹결론 : 구글 로그인을 붙이는 과정에서 기존의 '리더만 로그인, 팀원은 이름만 입력' 구조가 전원 로그인 방식으로 바뀌었고, 이는 기능 추가가 아니라 가치 제안 변경에 가까운 결정이었다.

• 원래 Onalign은 리더만 계정을 가지고, 팀원은 공유 링크에 접속해 이름만 입력하는 구조를 전제로 했다.
• 리더에게는 프로젝트 소유권과 영구 보존을 제공하면서도, 팀원에게는 참여 마찰을 만들지 않기 위한 절충안이었다.
  but, v26 명세에서는 팀원도 구글 로그인을 해야 참여할 수 있도록 구조가 변경됐다.

함께 바뀌는 기존 전제

• '로그인 없이 바로 참여'라는 진입 장벽 최소화 전략

• 오너와 참여자의 비대칭 로그인 구조

• 랜딩페이지의 참여 방식 설명

• 경쟁사 대비 차별점과 설문 가설

• 기술적으로는 구글 프로필 이름을 그대로 사용할 수 있어 참여자 식별과 동명이인 문제를 줄일 수 있다.
  ↔ 반면 회의 참여 전 로그인이라는 새로운 단계가 생기기 때문에, 원래 중요하게 보았던 '가벼운 참여'와 충돌한다.
  → 따라서 이 변경은 개발 편의나 데이터 구조만으로 확정하기 어렵다.
• 실제 사용자가 로그인 때문에 이탈하는지, 반복 프로젝트에서 계정 기반 재방문의 장점이 더 큰지를 확인한 뒤 결정해야 한다.

현재 남은 핵심 판단

전원 로그인을 의도한 방향 전환으로 확정할지,

기존처럼 리더만 로그인하고 팀원은 이름만 입력하도록 되돌릴지 결정해야 한다.

 

3. 권한은 UI와 DB에서 이중으로 막기

🔹결론 : 버튼을 숨기는 것만으로는 권한이 생기지 않는다. 화면과 데이터베이스 양쪽에서 같은 규칙을 강제해야 한다.

• 리더 전용 기능은 팀원 화면에서 버튼을 숨기거나 읽기 전용으로 만드는 것만으로 충분하지 않았다.
• 화면에 버튼이 보이지 않더라도 API를 직접 호출하면 데이터를 수정할 수 있기 때문이다.
• 그래서 프로젝트 삭제는 UI와 RLS(Row Level Security) 양쪽에서 막고,
  STEP 안내 문구와 투표권 수처럼 특정 컬럼만 보호해야 하는 기능은 DB 트리거를 추가했다.

보호 방식	역할	한계 또는 보완
UI 숨김·읽기 전용	사용자가 허용되지 않은 행동을 시도하지 않도록 안내	직접 API 호출까지 막지는 못함
RLS	사용자별 행 접근과 수정 권한 통제	행 단위 정책이라 특정 컬럼만 보호하기 어려움
DB 트리거	특정 컬럼 변경 시 오너 여부 재확인	RLS의 컬럼 단위 한계를 보완
→ 이 과정에서 프로젝트 데이터도 기존 JSON 묶음 형태에서 별도 테이블로 이관됐다. (데이터 구조와 보안 정책까지 함께 다시 설계하는 인프라 변경)

 

4. 실사용자 테스트에서 발견한 버그(v27)

🔹결론 : 코드가 정상적으로 실행되는 것과 여러 사용자가 자연스럽게 협업할 수 있는 것은 달랐다.

• v27에서는 로컬 환경에서 실제 사용자와 로그인·공유 링크·탭 이동 흐름을 테스트했다.
• 이 과정에서 기능 단위 테스트만으로는 발견하기 어려운 버그 4건이 확인됐다.

#	증상	원인	수정
1	공유 링크로 로그인해도 해당 프로젝트가 아니라 프로젝트 생성 화면으로 이동	OAuth 리다이렉트 과정에서 프로젝트 ID 쿼리스트링 유실	리다이렉트 URL에 쿼리스트링 유지
2	한 사람이 STEP을 이동하면 다른 참여자의 화면도 함께 이동	현재 탭 상태를 공유 데이터에 저장	개인 화면 상태로 분리
3	참여자 이름이 '본명(닉네임)' 형태로 반복 노출	구글 프로필 표시 이름 정제 로직 부족	괄호 이하 문자열 제거
4	탭 이동 시 화면이 튕기거나 부자연스럽게 늘어남	이전·다음 화면의 크로스페이드가 겹침	순차 페이드 방식으로 변경

 

5. 새롭게 정리된 설계 원칙

🔹결론 : 협업 서비스의 데이터는 '함께 보는 것'과 '각자 보는 것'을 먼저 구분해야 한다.

구분	예시	저장 기준
공유 데이터	포스트잇, 병합 결과, 문제 표시, 투표 결과, 회고 내용	모든 참여자가 동일한 상태를 봐야 하므로 서버에서 공유
개인 화면 상태	현재 보고 있는 탭, 펼침 여부, 개인 입력 포커스	다른 참여자에게 영향을 주면 안 되므로 로컬 상태로 관리

• 이 기준이 없으면 실시간 동기화를 많이 할수록 오히려 사용자의 화면 통제권이 줄어든다.

 

6. 버전 관리 인사이트

로그인을 붙이기 전에는 계정 시스템을 프로젝트 저장이 메인이라고 생각했다.

근데 리더/팀원 권한 설정에 꽤나 시간을 쏟았다.

(어라... 분명 테스트 용이하게 하려고 로그인 구현을 나중에 한 건데...?

처음부터 권한에 따른 화면 구성을 설정해놨는데 할 게 많네..?)

누가 프로젝트를 소유하는지 정하면 권한이 생기고, 권한을 정하면 데이터 구조와 보안 정책이 따라온다.

 

팀원까지 로그인시키는 순간에는 참여 경험과 기존 차별점까지 다시 검토해야 했다.

또한 자가 테스트에서 발견된 버그는 대부분 코드가 아예 작동하지 않는 문제가 아니었다.

각 기능은 동작했지만, 로그인 전후의 맥락이 끊기거나

한 사람의 화면 조작이 다른 사람에게 전파되는 식으로 협업 흐름이 어긋났다.

(이건 사실 클로드 코드가 잘 못함... 난 이렇게 화면 전환 싱크를 맞출지는 몰랐지ㅋㅋㅋㅋㅋㅋ)

 

7. KPT 회고

Keep	• 로그인 기능을 단순 인증이 아니라 권한 설계와 데이터 구조까지 함께 검토하며 진행한 점 • 리더/팀원 권한을 역할이 아니라 행동의 영향도와 복구 가능성을 기준으로 구분한 점 • 자가 테스트를 통해 기능 구현보다 실제 협업 흐름을 검증하려고 한 점
Problem	• 로그인 구현을 시작하면서 예상보다 권한 관련 작업 범위가 크게 늘어남 • 자가 테스트에서 발견된 문제들이 기능 오류보다 동기화·화면 전환·공유 범위 같은 협업 UX 영역에 집중되어 있었음
Try	• 앞으로 기능 추가 전 '사용자 가치 → 권한 영향 → 공유 데이터 여부 → 배포 검증' 순서로 체크리스트를 먼저 꼼꼼하게 확인하기 • 실사용자 테스트를 더 자주 진행해 개인 상태와 공유 상태가 섞이지 않는지 우선 검증하기