대규모 프로젝트를 처음으로 구현해 보다.
입사하자마다 내가 속한 팀의 과장 직급 인원 2명이 팀을 떠났다. [이직과 퇴사]
두 분 모두 팀장님과 협업하기 어렵다는 게 주 이유였다. [ㅠㅠ..]
그렇게 우리 팀에는 신입사원 3명만 덩그러니 남게 되었다.
팀에서 나의 주역할은 ERD 설계 후 검색 결과에 대한 캐시 처리 구현이었다.
현재 프로젝트에서는 상품 추천에 대한 특화된 요구사항이 있어서, 검색 엔진을 활용하기보다는 추천 로직 자체를 구현해서 상품을 추천하고 있다.
로직 자체가 무겁고 까다로운 경우가 많다 보니 로직에 대한 결과를 REDIS에 캐싱해서 빠르게 반환하도록 구현해야 했다.
과장님과 함께 일할 때에는 아이디어를 제시하고 논의하며 프로젝트를 진행하는 재미가 있었는데
과장님이 없는 상황에서는 내가 맡은 부분에 대해서 의논(혹은 조언을 구할)할 사람이 없어서..
동기분들과 함께 의논하여 내용을 정리해 팀장님께 승인받고 진행해야 하는 상황이 되었다.
동기 1분은 프론트 서버 구축 + 서버쪽 구현을, 동기 1분은 웹 크롤링 + 서버쪽 구현을 담당하게 되었다.
프로젝트는 꽤나 딱딱하게 흘러갔다.
처음으로 프로젝트의 시작과 끝을 경험해 봤다.
현재는 끝에 다가오고 있는데, 그 과정에서 느꼈던 아쉬움과 즐거움, 짜릿했던 경험 등등 희로애락에 가까웠던 경험을 글로 남겨보고자 한다.
기술적인 용어는 부드럽게 표현하고 감정적인 표현은 최대한 가볍고 경쾌하게 작성할 생각이다.
시간이 지나서 내가 어떤 경험을 했었는지, 어떤 것을 느꼈는지, 어떤 점이 부족했는지를 찾아볼 수 있는 글이 되었으면 한다.
나아가 프로젝트에 참여하는 기획자분들에게도 "개발자는 프로젝트에서 이런 점이 좋았고, 이런 점이 아쉬웠구나"하는 영감을 줄 수 있는 글이 되었으면 한다.
나도 나중에 어떤 프로젝트의 운명을 이끌 수도 있다.
현재의 나의 모습을 나중에 나의 팀원이 경험하는 상황이 될 수도 있으니...
결국엔 Water Fall
우리 회사의 프로젝트의 단계가 존재한다.
그리고 단계라는 구조 안에서 프로젝트가 진행된다. [크게 기획, 분석, 구현, 테스트]
기획, 분석, 구현은 자체적으로 사이클을 돌지만 테스트는 최종적으로 품질 팀에 맡기거나
해당 프로젝트의 기획자 맡기기로 하였다. [ + 자발적으로 해당 프로젝트를 사용하고자 하는 회사 사람들 ]
7개월의 여정에서 6개월까지는 기획 -> 분석 -> 구현 사이클을 반복하고
마지막 1개월에 모든 기능을 테스트하는 것으로 테스트 기간에 서버 개발자들은 기획의 의도를 놓치거나, 의도대로 실행되지 않는 로직들을 수정하거나 고쳤다.
개인적으으로 내가 느낀 프로젝트의 프로세스는 중첩된 Water Fall이라고 말하고 싶다.
[기획]
큰 테마를 가진 서비스별로 기획서가 존재한다. (해당 프로젝트의 경우 3개의 서비스에 대한 기획 문서가 존재했다.)
PPT로 제작되어 있는데, 위쪽 화면에는 해당 서비스 화면에 대한 타이틀과 수정 날짜 기획자 등등에 대한 정보가 담겨있다.
가운데 화면에는 기획 서비스에 대한 시뮬레이션 화면이 있고, 우측에는 서비스에 대한 설명이 존재하고 주요 기능에 대한 설명이 존재한다. 우측칸의 경우 추후에 오류 케이스나, 오해할 수 있는 내용에 대한 코멘트가 계속해서 추가된다.
해당 기획을 미리 살펴본 후, 기획자가 전체적인 흐름을 잡고 설명하는 기획 설명 회의에 들어가게 된다.
개발자들이 기획자에게서 기획에 대한 설명을 듣는 시간.
12명 정도 앉을 수 있는 테이블에 앉아서 PPT 수십장으로 구성된 기획안을 듣는다.
기획안을 들으면서 기술적인 이슈를 체크하고, 어려워 보이는 이슈들에 대해서 논의한다.
중간중간 1차 개발에 정말 필요한 기능인지 의문이 드는 기능들을 체크하고, 최종적으로 회의를 마친다.
이후 해당 기획에 대해서 1명이 ERD를 설계하고 팀원과 팀장이 리뷰하는 시간을 가진다.
팀의 ERD 리뷰를 마치고 나서는 ERD를 설계한 사람이 물리적 스키마를 설계한다.
이후 팀원들과 함께 엔티티들에 대한 기초적인 작업(CRUD)에 대해서 구현을 진행한다.
빠르게 앞서 나가는 기획
문제는 기획서가 더 빠르게 완성되고 있을 때 생겨났다.
팀은 기획 1을 바라보면서 설계하고 구현하고 있는데 기획 2가 완료되어서 기획 2에 대한 설명을 듣고 있는 상황이다.
머릿속은 기획 1에 대한 고민으로 복잡한 상황이기에 기획 2가 머리에 들어올 리가 없다.
(기획2를 생각할 수 있는 빈틈이 없다.)
기획 1에 대한 기능처리 및 ERD 설계가 끝나고 기획 2로 향할 때 즈음에는
기획자로부터 들은 기획2에 대한 설명은 머릿속에 존재하지 않는다.
기획2 기획서 참고 내용 + 기획2의 기획 설명 회의에서 메모한 내용 + 이해하지 못한 부분 직접 물어보기
과정을 통해서 기획 2에 대한 작업이 들어간다.
기획2를 분석하고 작업할 시점에는 기획 3이 진행되고 있다.
이렇게 기획 분석 및 구현에 있어서 우리 개발팀은 닿을 듯 닿지 못하는 속도로 기획을 쫓아갔다.
이 과정에서 개발팀은 시간에 쫓기게 되었고 기초적인 코드 컨벤션도 잡지 못하고(의논도 하지 못하고)
프로젝트를 진행했다.
3명의 개발자는 제각기 엑셀에서 마킹된 기능들을 이슈로 할당받아서 기능들을 구현했다.
서로 다른 스타일로 말이다.
리뷰도 거의 없다시피 코드 베이스에 즉각적으로 반영되었다.
아직은 기능을 테스트할 사람이 없었기 때문에 빌드되고 실행만 된다면 통과했다.
이는 추후에 스프링 스웨거(API 웹 문서)를 두게 되면서
개발자가 자체적으로 로컬 스웨거에 값을 넣으면서 처리하고 PR 올리는 방식으로 변경되었다.
[ 나의 경우는 테스트 코드로 대체했다. ]
프로젝트 프로세스 진행 방식은 워터폴 방식이지만 팀의 조직은 애자일처럼 움직였다.
주기적으로 회의시간을 가졌고 빠르게 피드백을 받으면서 프로젝트를 진행했다.
(매일 아침 ~~ 기능을 구현했다. 그 과정에서 따로 ~~ 어려움이 있었다 등등을 얘기하면서 즉각적인 피드백을 받았다.)
개발 프로세스의 흐름은 워터폴인데 조직 운영은 애자일이어서 머릿속이 더 복잡했다.
이에 대해서 이전 문화나 다른 팀의 프로세스를 듣거나 경험해보지 못했고 참고할만한 자료가 없어
그냥 이끌리는 대로 때로는 흘러가는 대로 프로젝트를 진행했다.
이렇게 무언가 잘못되고 있다는 인지된 상황 속에서
뚜렷한 의식없이 이끌려가거나 흘러가게 되는 느낌을 받았고 이 느낌은 중간 중간 회사 생활에 타성을 느끼게끔 만들었다.
변하지 않을 것이라는,
어차피 또 반복적으로 과거와 같이 흘러갈 것이라는,
뭐 다른 팀도 마찬가지겠지라는,
지금만 이렇게 처리하면 되겠지라는 좋지 않은 태도와 마인드가 팀의 분위기를 장악해버렸다.
사원인 우리가 뭘 할 수 있겠냐는 부정적인 감정 혹은 패배감이 자욱했다.
나아가 지금 해야 할 일이 산더미인데 이런 얘기를 할 여유가 있는가에 대한 자조적인 말도 자주 입밖으로 튀어나왔다.
프로젝트를 진행하면서 우리 팀이 진행하고 있는 프로젝트에 대해서
드리밍 인 코드의 "불가능의 삼각형의 딜레마"가 떠올랐다. [품질 삼각형]
저비용, 신속성, 고품질에서 2가지만 선택할 수 있다는 것이다.
우리는 저비용 신속성을 고려했고 품질을 버렸다. 품질은 프로젝트 진행 시 고려할 상황이 아니었다.
우리 팀의 개발자 3명은 양옆이 가려진 안대를 쓰고 앞만 보고 달리는 말과 같았다.
앞으로 필요한 여러 기능들에 대해서 기술을 검토할 시간은 가지지 않는다.
그저 우선순위가 높은 기능을 구현하고 나중에 대체할지 말지를 고민하자는 것이었다.
그러면서도 그런 로직에 대해서는 결합도가 상당히 강한 로직으로 구현했다.
대체할지 말지를 결정하는 것은 미래에 개발자가 감당해야 할 이슈였다..
팀장의 팀 운영은 명확했다.
빠르게 구현할 것. 구현이 확인될 때까지 집에 가지 말것.
필요한 기능이 있는데 어렵다면 외부 팀에 조언을 구할 것.
따듯한 화실 속에서 프로젝트에 대한 관리와 운영에 대해서 글로 배웠던 내가
야생에서 진행된 프로젝트에 뛰어들게 되었다.
그리고 지금은 해당 프로젝트에서 다른 프로젝트로 넘어가게 되었다.
앞으로 이전 프로젝트를 B프로젝트라고 부르도록 하겠다.
'인생 질문(취업후)' 카테고리의 다른 글
| 다시 돌아간다면 석사 생활을 할 것인가? 컴퓨터 공학과 석사 졸업 후기 (0) | 2023.10.27 |
|---|---|
| 주니어 개발자의 현업 프로젝트 2편. [어디에도 없는 사용자] (0) | 2023.01.19 |
