메인 프로젝트까지 모든 여정을 마치고 느낀 점들을 정리할 수 있는 시간들이 생겼다.
먼저 프리프로젝트부터 회고를 적어보도록 하겠다.
목표
프리프로젝트는 랜덤으로 팀원들을 배정하고 프로젝트 목표도 코드스테이츠 측에서 명확히 정해두었다.
프로젝트의 목표는 개발자라면 무조건 한 번쯤 거쳤을 Stackoverflow 웹 페이지를 클론 코딩하는 것
생각보다 다양한 기능을 가지고 있기 때문에 반드시 필요한 부분이 어디인지 생각하고 해당 기능을 포함할지 또는 포함하지 않을지 팀원들과 상의하고 구현해야 했다.
팀장? 제가 한 번 해보겠습니다.
처음 팀원분들과 만났을 때는 어색한 분위기가 가득했다. 관심사가 맞는지도 알지 못했고, 서로 어떤 생각을 가진 사람들인지 기본적인 정보가 없다보니 그야말로 가시방석과 같았다. 다행히 모두들 새로운 프로젝트에 대한 열정과 의욕이 샘솟는 상태여서 아이스 브레이킹을 진행했고, 조금은 나아진 분위기에서 팀장을 선출하기 위해 얘기를 나누게 되었다.
이 때 용기를 내서 팀장을 맡아보겠다고 어필했다.
팀장 역할은 어색함에 총대를 멘다기보단 항상 해보고 싶었던 역할이었다.
개발자로서 팀 프로젝트를 맡아 진행해본 경험도 없었기 때문에 새롭고 소중한 경험이 될 것이라고 생각했다. 이전까지 프로젝트를 진행해온 경험이 있기 때문에 소규모 팀 프로젝트에서 다른 사람들의 의견에 귀 기울이고 의견을 통합하고 취합하는 등의 역할을 자연스럽게 해낼 수 있을 거라는 묘한 자신감도 있었던 것 같다.
팀원분들도 나의 적극적인 모습에 손쉽게 팀장을 믿고 맡겼다.
그런데 이게 왠걸?
개발 관련해서 처음해보는 팀장 역할에 생각보다 어려움들이 많았고, 스트레스도 많이 받았다.
1. 무엇을 어디서 어떻게 왜
팀장으로서 가장 먼저 맡은 역할은 다같이 회의를 진행하고 사용자 요구사항 정의서, 화면 정의서, 테이블 명세서, API 명세서를 작성하는 것이었다. 이는 프로젝트 개발에 있어 가장 기초적인 단계이면서도 세심하게 진행해야 할 중요한 단계였다.
문제는...
개발 관련 문서 작업이 처음이었다.
이전에 학부 때 진행했던 프로젝트에서는 사용자 흐름, 와이어프레임 등을 작성했고 클라이언트와 이를 기반으로 소통했었는데, 이런 전문적인 웹 개발 문서 작성은 처음이다보니 어떤 양식을 지켜야하고 어떤 방식으로 내용을 작성해야하는지 감이 오지 않았다. 돌이켜 생각해보면 당시 수업에서는 교수님이 시니어 개발자 역할을 맡아 전체 프로젝트 진행 및 조율을 담당해 주셨으니...내가 팀장을 맡은 부분에서 얼마나 안일하게 생각했는지 알 수 있었다.
만약 당시로 돌아간다면 모든 팀원들과 함께 의견을 나누고 기본적인 규칙과 개발 규칙 등을 비롯한 기초 문서 작업을 함께 진행 했을텐데...이러한 부분을 잘 모르기도 했고, 어색한 분위기에 당황한 나머지 일찍 회의를 종료했다. 결국 눈물을 머금으며 혼자 기본 규칙과 개발 규칙의 틀을 잡고, 팀원분들에게 어떠한지 의견을 물었다.
억울하진 않았다. 내가 잘 몰라서 그랬고, 팀장이라면 이러한 부분에 대해 책임을 져야한다고 생각했기 때문이다.
2. 나는 답답한 팀장인가?
첫 단추를 잘못 끼워서 그런가, 이후에도 전체적인 진행에 있어 팀장으로서 꽤나 미숙한 모습을 보였었다.
문서 작성 과정에서 API 명세서를 백엔드가 거의 도맡다시피 진행했고, 이후 작성된 문서를 기반으로 프론트엔드에서 수정이 필요하거나 추가가 필요한 부분에 대해 말했다.
다른 사람들도 그랬지만, 어디서 무엇을 어떻게 고쳐야하는지 이 때는 감이 잘 오지 않았다. API 명세서 자체가 낯설기도 했고, request body에 어떠한 내용을 포함하는 것이 좋을지도 문서를 보는 것만으로 설명하기에는 조금 어려움이 있었다. 자연스럽게 커뮤니케이션 과정에서 문제가 발생했다.
이 때 꽤나 직접적인 말을 들었다.
팀장님 제 말이 이해가 잘 안 되시나요?
음... 이런이런 의도로 말씀하신 것 아닌가요?
아닌데요... (한숨) 제가 몇 번이나 말씀드렸잖아요.
가슴이 철렁했다.
팀원이 답답해하는 것이 느껴졌고, 미안한 감정이 들었다. 문서 작업이 처음이라 이해해달라는 말은 하고 싶지 않았다. 내 능력 부족을 통감하고는 있었지만, 그렇다고 팀원들까지 불안하게 만들고 싶지는 않았기 때문이다.
Java 공부를 이전에 했었기 때문에 어느정도 Spring 프레임워크를 이해할 거라고 자신감을 가지고 있었는데, 내가 사용했던 DAO가 아닌 DTO 방식과 2년 사이에 낯설어진 Java Spring 프레임워크의 구동방식에 대해 이해하는데 한계가 있었다. 의견 취합을 잘 하지 못하는 탓에 팀장을 괜히 맡아서 팀에 해가 되는 건 아닌가? 하는 회의감이 들었었다.
순간 망설였지만, 먼저 침묵을 깨고 대화를 시도했다.
아, 제가 ~~님의 의도를 잘못 이해하고 있었던 것 같네요. 죄송합니다.
잘못 이해한 부분에 대해 인정하고, 이후 다시 말을 꺼냈다.
제가 이런이런 의도라고 생각하게 된 이유는 이러이러한 부분 때문이었어요. 잘못 이해한 부분에 대해 조금만 더 자세하게 설명해 주실 수 있을까요?
침착하게 잘못 이해하게 된 이유에 대해 설명했고, 팀원의 의도를 잘 이해했나 확인하기 위해 답답함을 느꼈을 부분에 대해 해소할 수 있는 방법을 제시해달라고 했다. 해당 팀원분도 이를 통해 내가 잘못 이해한 부분을 명확히 이해했고, 이해하지 못했던 부분의 설명을 보완한 더욱 자세한 설명을 해 주셨다.
덕분에 해당 팀원 분의 의도와 건의 내용을 잘 이해하고, 의견을 조율할 수 있었다.
새삼 커뮤니케이션의 중요성과 위대함을 깨달을 수 있는 기회였다.
3. API 민족 대이동
누군가 "당신은 업무적으로 개선이 필요한 부분이 있다면 다른 사람에게 적극적으로 말할 수 있습니까?"라는 부분에 나는 "네, 상대방의 기분을 헤치지 않고 잘 말할 수 있습니다."라고 대답할 수 있다고 생각했다.
하지만 내가 모르는 분야에 대해 의견을 표한다는 것은 생각 이상으로 어려웠다.
프로젝트를 진행하면서 가장 눈에 밟히는 부분은 API 명세서였다.
백엔드가 주도해 완성된 문서에는 한 눈에 보기 어렵고 프론트엔드가 업무를 진행하기에는 효율이 떨어졌다.
하지만 이미 프로젝트가 꽤나 진행이 되었기 때문에 API 명세서를 정리하고 바꾼다는 건 추가적인 작업을 필요로 하고, 백엔드와 프론트엔드 양측에서 불가피한 수정들이 발생할 수밖에 없다는 사실을 팀장으로서 알고 있었기 때문에 말하기 망설여졌다.
많은 고민을 거쳤지만 결국 API 명세서를 노션 페이지에 옮길 필요성을 느껴 팀원분들에게 건의했다.
당시 API 명세서는 프로토타입이 있음에도 제대로 작성하지 못한 문서였기 때문에 활용도가 떨어졌고, request/response body에 필요한 데이터가 모두 담겨있지 않는 등 전체적인 수정이 불가피했다. 초기에 수행했어야 할 과정을 미숙함으로 인해 추가적인 작업이 필요하다는 부분에 대해 양해를 구했고, 현재 진행중인 단계에서라도 개발 과정을 일시적으로 중단하고 API 명세서를 손봐야 한다고 말했다.
아이러니하게도 개발이 어느정도 진행이 되었다보니 다른 팀원분들도 API 명세서에 대대적인 수정이 필요하다는 말에 쉽게 공감했던 것 같다. 설득하는 과정이 생각보다 수월해 건의하는 용기를 내는게 더 어려울 정도였다.
팀원들이 불만을 느끼지 않도록 기존 API 데이터를 노션 페이지로 옮기고 분류하는 초기 작업을 맡아서 작업하겠다고 말했고, 빠른 시간 안에 해당 작업을 마무리해 API 명세서를 작성했다.
이후에는 다시 한 번 심도있는 회의를 진행해 (이전의 일도 있어 이번엔 커뮤니케이션 과정이 훨씬 수월하고 능숙했다) 모두가 만족할 수 있는 API 명세서를 작성할 수 있었다.
이후에도 개발을 진행하면서 확인이 필요한 부분들을 지속적으로 의견 교류를 통해 수정/추가할 수 있었다.
만약 API 명세서를 바꾸자는 건의 없이 해당 프로젝트를 계속 진행했다면, 크게 후회했을 것이다.
이 때가 되어서야 비로소 "개발"에 있어 팀장의 역할이 무엇인지 이해할 수 있었다. 팀장은 프로젝트를 진행하면서 프로젝트의 전체적인 흐름을 이해하고 있어야 하며, 팀원 간의 의견 조율이 원만하고 자연스럽게 일어날 수 있게 틀을 유지할 수 있는 사람이라는 생각이 들었다. 또한, 프로젝트의 현실성을 유지시키면서도 발전시키기 위해 더 필요한 노력들이 무엇인지 항상 고민하고 있어야하는 직책이라고 생각했다.
4. 그래서...언제 서버 배포가 된다고요?
프리프로젝트 때 OT에서 강조했던 내용 중 하나가 "서버 배포를 작게라도 빨리 시작해라"였다.
지금 생각해보면 당연한 말이다.
API를 기반으로 하는 서버와 데이터 통신을 필요로 하는 웹 페이지 특성상 개발에 있어 가장 많은 시간을 필요로 하는 부분이 서버와의 통신 테스트 및 데이터 확인이기 때문이다.
그럼에도 프리프로젝트에서는 이러한 부분에 대해 크게 신경쓰지 못했던 것 같다.
백엔드에서 서버 배포 과정에서 목업 서버조차 띄우지 못할 정도로 치명적인 버그가 발생했기 때문에 해당 부분을 해결하지 못하면 로그인 자체가 안되었기 때문이다. 서비스 대부분이 로그인을 기반으로 작동했기 때문에 로그인을 하지 못하면 서버를 띄워도 의미가 없을 것이라는게 백엔드 팀원분들의 주장이었다.
이를 타당히 여겼다. 하지만 프론트엔드 측에서 할 수 있는 말은 하나 뿐이었다.
"그럼...최대한 빨리 서버 띄워주세요. 화이팅입니다..."
기약없는 기다림...피가 말렸었다.
지난 과정들을 돌이켜 보았는데, 역시 중간에 있었던 API 명세서 수정 과정과 의견 취합이 원활하지 못했던 점에서 발목이 걸린 느낌이었다.
당연한 말이지만, 백엔드만의 잘못이 아니었다.
전체적인 진행 과정에 있어 중간중간 많은 변경이 있었기 때문에 이전에 잘 되던 코드가 잘 안 되는 경우가 발생한 것이다. 이래서 세심한 초기 계획이 필요한건데...팀장으로서 잘 해내지 못해 아쉬운 부분이었다.
하지만 이러한 과정들이 결국 프리프로젝트를 진행하는 이유이며, 나를 더 나은 개발자로 만드는 경험이라고 생각했다. 서버의 중요성을 알고 프론트엔드가 할 수 있는 역할들이 무엇인지 고민해 보았다. 효율적인 문서작업을 위한 소통 과정과 지속적인 의견 교류를 통한 에러 최소화 등을 생각할 수 있었다.
5. 최종 과제 제출까지 3일, 서버 배포 완료
프리프로젝트 최종 과제 제출까지 3일 남은 금요일 당일 새벽 3시에 메세지가 도착했다. 백엔드 분들이 서버 배포 작업을 마무리할 수 있게 일일 진척도를 공유하는 오전 회의를 취소한 후의 얘기였다.
아침에 메세지를 확인했을 때 그 환희란...서버가 드디어 배포가 됐구나, 라는 생각이 들었다.
백엔드 분들이 몇날몇일 새벽까지 회의에 회의를 거듭해 문제를 해결한 서버가 드디어 배포되는 순간이었다. AWS EC2를 타고 배포된 서버는 에러를 유발시키는 일부 기능들을 제외하고 구현할 수 있음을 오전 회의를 통해 확인하고 바로 데이터 연동에 착수했다.
Redux-thunk와 axios를 활용해 이미 필요한 API들을 받아올 코드가 작성되어 있었기 때문에 빠르게 각 API 통신을 postman을 통해 확인하고 데이터를 대치해 나갔다. 이 과정에서 발생하는 오류들이나 누락된 데이터들을 실시간으로 백엔드에 공유했고, 주말 시간을 할애해 수정과 개발을 거듭했다.
그리고...
말 그대로 하얗게 불태웠다.
서버 배포가 늦어진다는 얘기를 들었을 때 배포 후에 어떤 순서로 개발을 진행해야할지 프론트 측에서 사전에 협의를 해 두었기 때문에 빠르고 신속하게 개발을 마무리할 수 있었다. 물론 이러한 계획에도 불구하고 밤을 새고...잠을 쪼개가면서 개발을 마무리할 수 있었지만...프로젝트를 90% 이상 구현할 수 있었다는 사실 자체가 엄청난 감동이었다.
마치며
팀장으로서, 또한 프론트엔드 개발자의 일원으로서 백엔드와 처음 협업해본 경험이었기 때문에 많은 어려움이 있었다.
비록 짧은 시간이었지만 프로젝트를 어떻게 준비해야 하는지, 의견 조율은 어떤 식으로 이루어지는지, 프로젝트 진행에 있어 중요한 부분이 무엇인지, 백엔드와 프론트엔드가 협업이 필요한 부분들이 어느 부분인지 등을 배울 수 있는 시간이었다. 이 와중에 새로운 기술 스택들을 배우고 사용해볼 수 있어서 더더욱 뿌듯한 시간이었던 것 같다.
열악한 개발 환경에서도 최선을 다해준 모든 팀원들에게 감사할 뿐이었다. (차마 메인프로젝트 때 같이하자는 말은 못했었다...미안해서...)
'개발자 일기 > 일일회고 (TIL)' 카테고리의 다른 글
| [원티드 프리온보딩 9월]1회차 회고 (0) | 2024.09.07 |
|---|---|
| Main_Project 회고 (0) | 2023.05.23 |
| 부트캠프 81, 82일차 (Pre-Project 시작) (0) | 2022.12.18 |
| 부트캠프 80일차 (Section 4 회고) (0) | 2022.12.14 |
| 부트캠프 77 ~ 79일차 (자료구조, 알고리즘, Coz' Mini Hackathon) (0) | 2022.12.14 |
댓글