싸피 2학기의 첫 번째 공통 프로젝트가 종료되었다. 두 번째 프로젝트의 시작하기 전에 회고를 해보려고 한다.
프로젝트 멤버 구성
공통 프로젝트는 싸피에서 임의로 정해준 반 내에서 팀을 구해야했다. 다만, 나는 웹 관련 프로젝트를 진행하고 싶었는데 임베디드를 전공한 사람들과 같은 반에 배정되어 팀 구성에 어려움이 많았다.
싸피에는 팀 구성할 때 비전공자/전공자 비율을 맞춰야 하는 조건이 있다. 그러다보니 웹을 희망하는 비전공 백엔드와 웹을 희망하지만 처음 해보는 임베디드 전공자로 팀을 이루게 되었다.
프로젝트 목표
팀을 리딩하게 되면서 우리가 어떤 걸 목표로 삼아야할까 고민이 많았다.
그래서 정해진 게 기능 목록을 최소화하되, 디테일한 개발을 해보자였다.
내가 생각한 디테일한 개발은 두 가지의 의미였다.
첫 번째로, 돌아가기만 하는 기능을 AI로 찍어내지 않는 것
두 번째로, 사용자에게 제공되는 서비스라고 가정하고 고도화하려고 노력하는 것
디테일한 개발을 하기 위해서는 전제 조건이 필요했다.
문제를 발견할 수 있고 이를 해결할 수 있는 실력이다.
다만, 우리 팀은 웹을 처음하는 사람들도 있었고 기초가 부족한 부분이 많아서 이를 극복했어야 했다.
기초 다지기
우리 팀이 기초를 다지고 실력을 키우기 위해 노력한 것은 두 가지이다.
첫 번째로, 딥다이브이다.
매일 아침 데일리 스크럼이 끝나고 2시간 정도 언어나 프레임워크 혹은 프로젝트에 쓰이는 기술을 학습하는 시간을 가졌다.
예를 들어, 클로저를 학습한다고 가정하면 개념에 이어서 추가적으로 연관된 지식을 학습하는 방식으로 진행했다.
프로젝트 기간 동안 프론트 파트는 190+개, 백엔드는 160+개가 넘는 질문에 답을 달며 학습했다.
두 번째로, 기술 블로그 작성이다.
매 주 1회 기술 블로그 작성을 하며, 프로젝트 내에 쓰이는 기술이나 진행하며 겪은 문제/해결 과정을 기록하고 서로 공유하는 문화를 만들었다.
처음에는 시간을 너무 많이 잡아먹나 고민이 있었지만,
오히려 조금씩 기초가 다져지면서 후반부에 속도가 훨씬 빨라지는 걸 느낄 수 있었다.
프로젝트가 끝나고 모두가 공통적으로 딥다이브 시간에 공부하고, 기술 블로그를 작성하면서 성장한 게 많았다고 얘기했고, 나도 그렇게 느꼈다.
프로젝트를 진행하며 있었던 작은 해프닝들을 모아봤다.
해프닝 1 - 모래로 집을 짓지 말자
우리 팀은 개발에 들어가기 전 충분한 학습을 권장했다.
OAuth 로그인을 맡은 두 명에게 로그인에 필요한 지식을 학습하도록 하고, 5일정도 지나고 작성한 로직을 팀원에게 공유하는 시간을 가졌다.
여기서 문제가 발생했는데, 소셜 로그인인데 OIDC를 사용하지 않는 로직을 짜왔다. 간단하게 설명하면 로그인 로직에 인증 과정이 없는 것과 같다.
어쩌다 이렇게 됐을까 디버깅을 해본 결과 잘못된 정보를 제공하는 블로그와 AI의 합작품이었다.
그래서 팀원 분들에게 모래로 집을 짓지 말고, 옆집에서 공짜로 나눠주는 벽돌로 집을 지어라는 주제로 강연을 하게 됐다.
그 때 했던 내용을 간단하게 작성하겠다.
우리가 만들어야 하는 서비스를 집을 짓는 거라고 생각해보자.
우리는 집을 지을 것이다.
다만, 우리는 집을 지어본 경험도 부족하고, 집을 잘 짓는 방법도 모른다.
지금 상황에서 우리가 짓는 집은 파도 한번에 무너지는 해변가의 모래성과 같다.
이렇게 지은 집을 다른 사람에게 거주하라고 권유할 수 있을까?
그 사람은 마음 놓고 우리가 지은 집을 이용할 수 있을까?
그렇지 않다.
그러면 우리는 어떻게 집을 잘 지을 수 있을까
주변을 둘러보자
해변가 옆 가게에 각자의 연장통을 들고 있는 사람들이 줄 서있는 게 보인다.
남여노소를 가리지 않고 줄을 서있고, 심지어 업계에서 유명한 건축가도 거기에 서있다.
가게 입구를 보니, 사람들이 벽돌과 설계도를 받아 나오는 게 보인다. 심지어 가게 앞 푯말에는 무료라고 적혀있다.
이 가게의 이름은 "공식 문서"이다.
건축에 대해서 가장 잘 아는 사람들이 벽돌과 설계도를 무료로 나눠주고 있다. 파도 한번에 무너지는 모래로 집을 필요가 없다.
다만, AI의 도입으로 사람들은 벽돌을 받으려 줄을 서지 않으려 한다. 잘 정리되어 있는 다른 사람의 블로그를 보거나 GPT한테 물어보지만 팩트 체크를 하지 않는다. 공식 문서 작성이 잘되어 있는 경우엔 오히려 공식 문서를 읽어보는 게 훨씬 빠를 때도 있다는 걸 간과한다.
이번 문제도 그러했다.
카카오 OAuth의 경우 공식문서가 워낙 잘 되어 있어서 공식 문서를 봤다면 소셜 로그인에서 OIDC를 안쓰는 로직을 짜지 않았을 것이다.
모래로 집 짓지 말고, 공식 문서에서 무료로 나눠주는 벽돌로 집을 짓자
맺음말
배운 것도 많고, 느낀 것도 많은 프로젝트였다.
간단한 프로젝트이다 보니 스키마만 같이 구성하면 CRUD API는 백엔드가 알아서 짤 수 있을 거라 생각했는데, 내 생각과 백엔드의 생각이 완전히 달랐던 경우가 있어서 API 명세서의 중요성을 다시금 느꼈다.
TDD로 인해서 초기에 시간을 많이 잡아먹었지만, 오히려 리팩토링이 진행될수록 시간이 절약되는 걸 느꼈다.
다음 프로젝트에서는 AI를 개발에 활용해서 와이어 프레임이나 E2E테스트, 코드 리뷰 등에 활용해볼 예정이다.
