[TeamBlog] 기획 리뷰 - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki

estar.yoon(윤동규)/인공지능

프로젝트 개요

본 프로젝트에서 AI 챗봇 기능을 메인으로 담당하여 진행했다. 피그마에서 작성된 화면 설계서와 기능정의서를 기반으로 서비스의 전체적인 흐름과 기능을 설계하고 문서화하는 과정을 경험했다.

KPT 회고

Keep (유지할 것)

  • 피그마를 활용한 시각적 문서화: 화면 설계서와 기능정의서를 피그마로 작성하여 팀원들의 이해를 높이고 공감대를 형성할 수 있었다. 시각적 문서화는 말로만 전달하는 것보다 훨씬 효과적이었다.
  • 반복적인 피드백과 수정 프로세스: 회의에서 논의한 내용을 문서화하고 시각화하는 과정에서 발견되는 차이점을 지속적으로 수정하며, 모두가 공감할 수 있는 기획서를 완성할 수 있었다.
  • 유연한 접근 방식: 기술적 불확실성 속에서도 가능한 범위 내에서 기능을 정의하고, 개발 단계에서 기술적 제약사항을 반영하여 수정하는 유연한 접근을 유지했다.
  • 사용자 관점 중심의 기획: 단순히 기능을 나열하는 것이 아니라, 사용자 관점에서 자연스러운 흐름과 우선순위를 고려한 기획을 진행했다.

Problem (문제점 및 어려움)

  • 소통의 어려움: 회의에서 논의한 내용과 실제로 각자가 생각한 것이 다를 때가 많았고, 이를 문서화하고 시각화하는 과정에서 또 다른 차이점이 발견되곤 했다. 같은 프로젝트를 함께 논의했음에도 불구하고 서로 간의 의사소통 문제가 발생했다.
  • 기술 선택의 불확실성: 기획 단계에서 구체적인 기술 구현 방법이 명확하지 않아 기능을 정의하기가 어려웠다. RAG 적용 여부, 벡터 데이터베이스 선택, 스트리밍 방식 등 기술적인 결정이 기획의 방향을 좌우했다.
  • 기획 문서의 구체성 부족: 비개발자나 비기술적 배경을 가진 사람들과 협업할 때 쉽게 풀어서 소통하고, 개발자들이 실제로 구현할 수 있도록 명확하고 구체적인 문서를 작성하는 것이 어려웠다.
  • 기술과 기획의 연계 고려 부족: 기술적으로 구현 가능한 범위를 정확히 파악하기 어려워, 기획과 기술 간의 간극이 발생했다.

Try (다음 스프린트에서 시도할 것)

  • 정기적인 동기화 미팅 도입: 회의 후 즉시 문서화하고, 다음 미팅에서 문서를 기반으로 확인하는 프로세스를 도입하여 소통의 차이를 최소화하겠다.
  • 기술 검토를 선행하는 기획 프로세스: 기획 단계에서 기술 스택과 구현 가능성을 먼저 검토하고, 이를 기반으로 기능을 정의하는 프로세스를 도입하겠다.
  • 구체적인 기획 문서 템플릿 작성: 개발자가 바로 구현할 수 있도록 사용자 시나리오, 화면 흐름, API 명세, 예외 케이스 등을 포함한 구체적인 기획 문서 템플릿을 만들겠다.
  • 기술 리뷰 세션 정기화: 기획자와 개발자가 함께 기술적 제약사항과 구현 가능성을 논의하는 정기적인 기술 리뷰 세션을 도입하겠다.
  • 프로토타입 기반 검증: 주요 기능에 대해 프로토타입을 먼저 만들어보고, 이를 바탕으로 기획을 보완하는 방식으로 진행하겠다.

neon.ahn(안혜원)/풀스택(Frontend)

이번 스프린트에서는 기획 단계에 집중하여, 프로젝트 전반 기획 논의에 참여하고 기능 범위를 정리하였다. 특히 캘린더 도메인을 중심으로 요구사항 정의서, 캘린더 화면 설계서, 캘린더 기능 정의서를 작성하여 사용자 흐름과 화면 구성, 기능 단위를 문서로 명확히 정리하였다. 이를 통해 팀 내에서 동일한 기준으로 기능을 이해하고 논의할 수 있는 기획 기반을 마련하였다.

Keep (잘했던 점 / 유지하고 싶은 것)

👍🏻  성과

  • 프로젝트 전반의 기획 참여
    • 서비스 목표 및 주요 기능 흐름을 이해한 상태에서 기획 논의에 참여하여, 기능 범위와 화면 구성 방향을 정리하는 데 기여하였습니다.
  • 요구사항 정의서 작성
    • 기능을 화면/요소 단위로 분해하고, 각 요구사항을 문서 형식으로 정리하여 개발 착수 전 기준을 확보하였습니다.
    • 요구사항을 명시적으로 기록함으로써 팀 내 해석 차이를 줄이고, 이후 논의 시 근거 자료로 활용 가능하도록 하였습니다.
  • 캘린더 화면 설계서 작성
    • 캘린더 화면의 구성 요소(뷰 전환, 일정 리스트/상세, 필터 등)를 구조적으로 정리하고, 사용자 조작 흐름을 문서화하였습니다.
    • UI 구성과 사용자 동선을 정리함으로써 개발 단계에서 필요한 화면 단위 작업 범위를 명확히 하였습니다.
  • 캘린더 기능 정의서 작성
    • 캘린더의 핵심 기능(조회/등록/수정/삭제, 필터링 등)을 기능 단위로 정리하고, 화면과의 연결 관계를 명확히 하였습니다.
    • 기능 중심으로 문서를 작성하여, 추후 구현 순서 결정 및 영향 범위 파악에 활용할 수 있는 기반을 마련하였습니다.

Problem (개선이 필요한 점)

💨 어려움

  • 기능 정의서 작성 시 세부 명세의 부족
    • 기능 정의서를 작성할 때 단순히 어떤 기능인지 수준이 아닌, 입력값(사용자 입력/파라미터), 출력값(화면 변화/데이터), 상태(로딩/에러/빈 상태), 예외 케이스까지 매우 구체적으로 작성해야 한다는 점이 어려웠습니다.
    • 특히 입력값을 꼼꼼히 정리하지 않으면, 개발 단계에서 API 요청 형식이나 유효성 검증 기준을 다시 추적해야 하며 재작업이 발생할 수 있다는 점을 체감하였습니다.

Try (앞으로 시도해볼 것)

💡 새로운 도전

  • 기능 정의서 템플릿 표준화
    • 기능 정의서 작성 시 매번 고민하지 않도록, 입력/출력/상태/예외를 포함한 고정 템플릿으로 작성하겠습니다.
    • 목적은 문서 품질을 균일하게 유지하고, 작성 속도를 개선하는 것입니다.

💡 문제 해결 방안

  • 용어 및 데이터 정의 선행
    • ‘일정’, ‘태그’, ‘필터’, ‘반복 일정’ 등 핵심 용어를 먼저 정의하고, 필드(데이터 구조)를 간단히라도 확정한 뒤 기능 정의서를 작성하겠습니다.

yun.jeon(전윤철)/풀스택(Backend)

백엔드 요구사항 정의서를 작성했다.

회원 가입 및 마이 페이지 기능의 화면 설계서 및 기능 정의서를 맡아 기획했다.

Keep

  • 모노톤의 와이어 프레임 키트를 활용해 빠르게 화면 설계를 마치고 기능 정의에 시간을 투자할 수 있었다.
  • 개인별로 정해진 분량을 담당해 화면 설계서와 기능 정의서를 작성하니 초안이 나오기까지의 시간이 길지 않았다.
  • 서비스 방향을 한번 크게 바꿨지만 구현하고자 하는 핵심 로직을 명확히 정해두니 기획이 바뀌어도 금방 다시 쌓아올릴 수 있었다.

Problem

  • 백엔드 요구사항 정의서 작성의 디테일적인 측면이 부족했다.
  • 초안이 빨리 나오는 부분은 긍정적이었으나 각자 작업하는 방식, 생각하는 디테일함의 정도, 내용 작성 양식 등 다른 부분이 많아 상세하게 디벨롭하는 데에는 생각보다 오래 걸렸다.
  • 중간 중간 사소한 부분이 계속 바뀌는데 팀 내에서 전체의 싱크가 맞지 않았던 적이 꽤 있었다.

Try

  • 다음 스프린트 때에는 설계를 진행하기 때문에 같은 범위 내에서 다른 팀원과 겹칠 일은 없겠지만, 각자의 진행도나 서비스의 전반적인 아키텍처, 트랙 간 의존성이 있는 내용을 공유할 때에는 상호 간 싱크를 맞추기 위해 좀 더 명확한 소통이 필요할 것 같다.

david.lee(이도연)/클라우드

그룹 채팅과 단일 채팅을 동시에 고려해서 기획한 것을 KPT를 정리함.

KPT 회고

Keep (잘한 점, 유지할 점)

  • 사용 시나리오에 따라 채널을 구분했음
    1:1 채팅은 개인 상담·멘토링·AI와의 깊은 대화 등 “개인 컨텍스트가 중요한 상황”에 맞게, 그룹 채팅은 스터디·부트캠프·프로젝트 팀처럼 “여러 사람이 맥락을 공유하는 상황”에 맞게 쓸 수 있도록 두 축을 잡은 점이 좋았음.

  • 그룹/단일 채팅 공통 UX를 유지하려고 했음
    메시지 입력, 전송, 읽음, 타임라인 같은 기본 경험을 최대한 통일시키고, 상단 정보(참여자 목록, 채팅방 이름, 설정 등)만 다르게 가져가도록 생각했다면, 사용자가 자연스럽게 두 채팅 타입을 오갈 수 있게 된다는 점에서 잘한 선택이었음.

Problem (아쉬운 점, 문제점)

  • 그룹 채팅의 ‘역할과 권한’ 정의가 충분히 구체적이지 않았을 수 있음
    방장, 운영진, 일반 참여자의 권한(초대/추방, 공지 작성, 이름 변경, 핀 고정 등)을 어디까지 허용할지 명시하지 않았기에 아쉬웠음.

  • 단일 채팅과 그룹 채팅의 알림 전략이 섬세하게 갈리지 않았을 수 있음
    1:1 채팅은 거의 모든 메시지가 중요하지만, 그룹 채팅은 Mention, 공지, 특정 키워드 중심으로 알림 강도를 달리해야 함. 이런 세밀한 알림 정책(푸시, 뱃지, 사운드, 요약 등)이 없기에 사용자 입장에서 “알림이 너무 많거나, 반대로 중요한 걸 놓치는” 경험이 생길 수 있음.

Try (시도할 점)

  • 그룹/단일 채팅별 “대표 유저 시나리오”를 각 2~3개씩 스토리로 정리함
    예를 들어, 단일 채팅은 “멘토에게 이력서 피드백 받기”, “AI와 면접 예상 질문 연습하기”, 그룹 채팅은 “스터디 리마인드 공유하기”, “프로젝트 팀에서 일정·산출물 공유하기”처럼 구체적인 스토리를 글로 풀어보면, 어떤 기능이 필수이고 어떤 건 후순위인지 더 명확해질 것 같음.

  • 알림·권한·보관 정책을 ‘타입별 표’로 분리해서 정의함
    채팅 타입(1:1, 그룹, 공지/채널 등)을 행으로 두고, 열에는 [누가 만들 수 있는지 / 최대 인원 / 알림 기본값 / 메시지 보관 기간 / 핀/공지 기능 여부] 등을 두어 표로 정리하면, 기획과 개발이 같은 그림을 보고 얘기하기 쉬워질 것 같음.

  • 그룹 채팅에 “정보 정리 기능”을 더해보려 함
    단순 메시지 타임라인을 넘어서, 자주 참조하는 메시지 핀, 중요한 안내를 모아보는 공지 탭, 일정과 연결되는 메시지를 캘린더와 연동하는 기능 등을 그룹 채팅 쪽에만 선택적으로 추가해 보면 좋을 것 같음. 이렇게 하면 그룹 채팅이 잡담용이 아니라 “협업과 학습의 허브” 역할을 더 잘 수행할 수 있을 것 같음.

henry.myeong(명혜성)/클라우드

캘린더 + AI 기능을 통해 취업 일정을 관리하는 서비스 부분을 기획하였다.

기능: 캘린더, 자동 일정 추가(AI), 일정 CRUD, 알림, Todo 일정

Keep (잘한 점, 유지할 점)

  • 사용자의 핵심 페인포인트(취준 공고 별 일정 관리의 어려움)을 AI로 해결하려는 시도, 기능 간(캘린더 - AI)의 유기적 연결을 잘 설계했다.
  • AI를 이용한 자동화의 명확한 목적 달성: 단순히 LLM AI를 사용하는 것에서 끝나지않고, 공고를 통해 자동으로 일정을 추가하는 기능을 기획하여 사용자 편의성을 높였다.
  • 필수 기능 구체적 정의: 캘린더 기능의 데이터 구조를 고려하여 일정 등록 시 필요한 필수 필드, 입력 값 제한을 명확히 정의하였다.
  • 알림 로직 구체화: 단순한 알림이 아니라, 구체적 시간 설정 기능을 추가하여 리마인더의 역할까지 할 수 있도록 설계하였다.

Problem (아쉬운 점, 문제점)

  • AI 정확도에 대한 불확실성과, 복잡한 예외 케이스에 대한 정의가 부족하다.
  • AI 파싱 실패 시나리오의 설계가 미흡하다. 인식 오류 시 사용자의 개입 등을 위한 설계가 디테일하지 않다.
  • 일정 데이터의 복잡성과 모호함이 있다. 채용 공고 마감일(데드라인)과 개인 면접일정(이벤트)의 성격이 다른데, 이를 구조적으로 구분할 방법에 대한 합의가 부족하다.
  • 알림 중복 및 과다 문제에 대한 정의가 부족하다. 공고가 많아질수록 피로도가 높아지고 가독성이 떨어지는 문제에 대한 대책을 설계하지 않았다.

Try (시도할 점)

  • AI 기술의 기능적 검증을 수행한다. AI 파싱 정확도 및 결과 데이터 포맷을 정의한다.
  • 실패 및 예외 처리를 위한 UI와 로직을 추가한다. 사용자가 개입하여 수동으로 값을 정정하거나 조절할 수 있도록 하는 추가적인 기능을 구체화한다.
  • 알림 정책에 대한 검토가 필요하다. 사용자가 받을 알림의 종류에 따라 그룹화 하거나, 알림의 시점을 조절할 수 있는 개인화 로직을 검토한다.