테오의 스프린트15기 후기

한호수 (The Lake)·2023년 6월 29일
1
post-thumbnail

첫째날, 팀 캔버스를 통해 생각 합치기

각자 준비해온 아이디어를 많은 사람들 앞에서 소개하고 많은 좋아요를 받은 아이디어를 위주로 팀을 나누는 시간을 가졌다. 아쉽게도 내 아이디어는 뽑히진 않았지만 좋아요 6개를 받아서 나름 위안이 되었다.

나누어진 팀원들과 각자의 장점과 단점 그리고 서로 주의할점 등 이야기를 나누고 우리 프로젝트의 목적과 가치에 대해서 이야기해보고 글로적고 서로 호응해주는 시간을 가졌다. 처음엔 어색했지만 시간이 지나면서 조금씩 풀렸고 우리가 만들 서비스와 유사한 레퍼런스를 찾아오기로 약속하고 헤어졌다.

둘째날, 아이디어 스케치

숙제로 조사해온 레퍼런스를 공유하며 구체적으로 서비스를 그리는 단계인데, 원래 아이디어를 제공해주신 PM 님께서 개인사정으로 스프린트에 참여하지 못하게 되셨다.
처음에는 팀원들과 무척 당황했지만 충분히 할 수 있다고 생각하고 다음 주제로 이야기를 나누었다.

  • 내가 생각하는 우리 서비스의 궁극적인 목적은 무엇일까요?
  • 내가 생각하는 우리가 만들 서비스의 주요대상은 누구일까요?
  • 고객 여정 맵 (기존에 우리들의 대상은 목적을 이루기 위해서 어떻게 했나요?
    어떤 생각으로 시작해 어떤 단계를 밟고 어떤 부분에 만족하고 어떤 부분에서 힘들어하며
    우리는 어떻게 도와줄수 있을까요?
    (단계, 행동, 생각, 행복한 순간, 고통의 순간, 기회)
  • 내가 생각하는 우리가 만들 서비스가 추구해야 할 핵심가치는?

해당 주제로 글을 쓰고 각자 발표하며 각자가 생각하는 서비스 이미지를 나누는 시간을 가졌다. 여기서 유익했던건 사람들이 글로 작성한 내용만 이야기하는게 아니라 발표를 할때에는 미처 글로 쓰지 못한 부분들이 존재해서 듣는사람들이 핵심 키워드를 뽑아주는게 좋다는 점이었다.

여기서 나온 내용을 가지고 아이디어를 구체화하기 위해 어떻게하면 ~ 할 수 있을까 라는 질문을 만들어 각자 문제를 해결하기 위한 해결책을 내기로 했다. 이부분에서는 제시된 해결책에 대해서 더 깊이 이야기를 나누고 싶다면 5명의 생각을 각각 적고 발표하는 시간을 가지며 구체적인 해결책을 만들어나갔다.

가장 어려웠던 것은 무엇이든지 결정을 하지 말라는 테오의 주의사항이었다. 무엇이든지 확정낸다면 아이디어가 굳어진다는 의견이었고 공감하고 있었다. 그래서 어떠한 문제들을 해결하기위한 아이디어를 나열하고 기록만 해두는 식으로 다음으로 넘어갔다.

중간에 팀원들과 아이디어를 맞추는 과정에서 서로 생각하는 그림이 달라 조율하는 시간이 있었지만 해결되었고 각자 스토리보드 그려오기 과제를 받아 둘째날은 마무리하게 되었다. 마무리 도중 ZEP에서 주변을 둘러봤는데 8시반 중에서 제일 마지막까지 남아있어서 뿌듯했고 열정적인 팀원들을 만나 행운이라고 생각했다.

셋째날, 최종 솔루션 결정하기(스토리보드 정하기)

셋째날, UX 결정권자를 투표를 진행하게 되었고 과분하게도 내가 선정되었다. 셋째날은 결정을 하는날로써 UI를 결정할 사람을 뽑고, 기술스택을 정할 PL도 뽑는시간을 가진것이었다. ( PL은 프론트와 백엔드 각각 머지말티푸가 뽑혔다. )

그리고 숙제로 그려온 레이아웃들과 그에 따른 기능들을 서로에게 소개하는 시간을 가지고 투표를 통해 여론을 조사하고 내 결정에 의해서 UI가 결정되었다. 결정을 해야한다는 자리는 부담스러웠지만 결정하는사람이 없다면 사공이 많으면 배가 산으로 간다는 말처럼 구체적인 서비스가 만들어지기 어려워질것이라 생각했다.

UI가 결정된 후 간략한 BDD 방법론을 통해 사용자의 행동에 따른 소프트웨어의 변화를 예측하고 그에 따른 시나리오를 작성하였다.

이 후 프론트와 백엔드, 각각 기술스택을 정하고 각자 맡을 부분을 정해서 개발을 진행하기로 하였다. 실제 개발기간은 금요일 새벽부터 월요일 오후까지라서 한 서비스를 만드는 시간으로는 부족하지만 빠르게 MVP를 만드는 경험을 한다고 생각하고 개발을 시작하였다.

넷째,다섯째날 개발시작 및 마주친 이슈들

Airbnb ESLint

Airbnb ESLint를 사용하는데 Lint Error가 너무 많이 났다. 매우 엄격하다는것은 알고 있어, 개발을 하면서 필요하지 않는 옵션은 제거하기로 했지만 우리에게 불필요한 옵션이 너무많았다. 시간이 조금 걸리더라도 처음부터 옵션을 정해 우리만의 lint를 정하고 가는게 더 빠른 개발을 하고 통일성 있는 코드를 만들 수 있었을 것 같아 아쉬웠다.

GPT API

백엔드에서 GPT API를 통하여 취미에 대한 답변을 가져올때 40초가 걸리는 이슈가 있었다. 우리 서비스는 사용자의 선택에 따라 나온 취미를 추천해주고 선택한 키워드를 GPT에 물어 답변을 가공해서 전달해주는 서비스인데 40초라는 시간은 너무나 파괴적이었다.
여러가지 해결책이 제시되었지만 가장 현실적인것은 MVP를 만드는것이니 GPT API를 사용하면 DB에 저장하고 유저가 같은 질문을 한다면 DB에 있는 답변을 보여주는것이었다. 이후 프롬프트를 수정하여 간략한 답변을 받을 수 있게 개량해보기로 하고 없는 질문 같은경우에만 GPT를 사용해 받아오기로 결정하였다.

CORS

프론트엔드 개발을 하다보면 필수적으로 나오는 CORS 에러를 마주쳤다. 막연하게 백엔드에서 header 값에 Access-Control-Allow-Origin* 로 주면 되는것으로 알고 있었는데, API 호출 시 헤더에 Access-Control-Allow-Origin 가 담겨있지 않았다. 백엔드분들이 해결해보려고 했는데 해결이 안되서 프록시 서버로 우회해서 해결하였다. 개발환경에서는 Vite.config.ts에 proxy를 설정하여주고 배포환경에서는 우리가 배포한 netlify의 설정파일을 만들어 proxy를 설정하였다.

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import * as path from 'path';

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: [{ find: '@', replacement: path.resolve(__dirname, 'src') }],
  },
  server: {
    proxy: {
      '/api':
        'https://www.api.com', // api 주소
    },
  },
});
// netlify.toml
[[redirects]]
from = "/proxy/*"
  to = "https://www.api.com/:splat" // api 주소
  status = 200
  force = true

[[redirects]]						// 하위 route로 진입 시 notFound 조치
from = "/*"
  to = "/index"  
  status = 200

여섯째날, 회고, 서비스공개, 네트워킹

가까스로 약속한 시간에 README까지 작성을 완료하였고 네트워킹 시간을 가지며 스프린트의 다른 조들과 각자 서비스를 소개하는 시간을 가지며 질문하는 시간을 가졌다. 이야기를 들어보니 짧은시간안에 모르는 사람과 협업과 개발을 하려하니 우리와 마찬가지로 쉽지 않았다고 말했다.

마지막으로 팀원들과 모여 피그마에서 4LS 회고를 하며 좋은점, 배운점, 아쉬운 점, 개선해야할 점을 각자 적어보고 발표하는 시간을 가졌다. 각각 프로젝트, 협업과 팀, 스프린트를 주제로 3번의 회고를 겪고 다음 스프린트는 어떻게 할지 생각해보는 시간을 가지고 6일간의 스프린트를 마무리하였다.

Lesson

협업은 쉬우면서 어렵다.

내 의견을 상대방이 이해할 수 있게 전해야하며, 기분 나쁘지 않게 전해야할때도 존재했다. 반대로 상대방의 의견을 정확히 이해했다고 생각했지만 막상 개발을 시작하니 이해하지 못한 부분이 많아 난항을 겪기도 하였다. 하지만 배운점이 있다면 협업할때 상대방의 의견에 많은 호응을 해주고, 더 많이 의견을 나눠봐야지 실제 업무를 시작했을때 의사소통의 차이로 벌어지는 시간낭비를 줄일 수 있다는 점이었다.

백엔드와의 협업경험

첫 프로젝트를 진행할때에는 부트캠프에서 제공해주는 백엔드 API를 사용하여 프로젝트를 진행하였기 때문에 백엔드와 어떤 협의를 할 수 없었고, 이미 안정화 된 API이기 때문에 별다른 문제가 없었다. 하지만 이번 프로젝트를 진행하면서 어떤 경로로 요청하고 어떤 형식의 데이터를 받을 것인지 협의를 하면서 이런게 진정한 협업이구나를 생각했다.

서비스 출시가 끝이 아니다.

너무나도 당연한것이지만 서비스 출시가 끝이아니라 반복되는 스프린트를 통해 점점 서비스를 완성시켜나가는 것이다. 직장생활을 하는 팀원들이 있어 많은 시간들을 투자할 순 없겠지만 내가 개선해나갈 수 있는 부분은 개선하면서 완성도를 높혀볼 생각이다.

좋은 경험을 할 수 있게 노력해준 테오와 모승, 꾺, 수달 및 스테프 여러분께 감사합니다.

profile
항상 근거를 찾는 사람이 되자

0개의 댓글