AWS X Yonsei Cloud Winter Camp 후기

아직 미완성의 글입니다.

어쩌다보니 졸업을 한학기 미루게 되었다. 내 생각과는 다르게 스팩만으로는 취직이 쉽게 되지 않았고, 크리스마스 이브날에 본 면접도 결국 최종에서 떨어지게 되었다. 그 때 정말 자존감이 너무 바닥이라서 무언가에 열중해서 성과를 거두고 싶었고, 그 때 마침 학교에서 AWS Korea에서 교육을 받고, 프로젝트를 진행할 수 있는 기회가 있었다. 그래서 나름대로 '반드시 내 실력에 대한 증명을 해내겠다' 라는 각오를 가지고 참가했다. 

 

그리고 AWS에서 2주 정도 단과대 선, 후배님들과 함께 이런저런 수업을 들었다. 나름대로 과 생활을 열심히 했다고 생각했지만 대부분은 잘 모르는 얼굴이었는데, 다행스럽게도 알고 지내던 19학번 후배들 덕분에 다른 친구들도 새롭게 알게되고 쉬는 시간마다 탕비실을 털면서... 재미있게 보냈던 것 같다.

 

그러면서도 내심 자기증명을 하러 온 자리라고 생각을 했기에 괜찮은 아이디어를 클라우드에 접목시켜서 성과를 거두고 싶다는 생각을 종종 했었다. 그렇지만 프로젝트는 혼자 하는 것은 아니기에 팀빌딩에 어느정도 신경을 썼던 것 같다.

 

일단 내가 주도적으로 팀을 이끌면서 성과를 거두어야 내 능력에 대한 자기증명이 더욱 뚜렷하게 된다고 생각했기에 팀장을 자원했고, 나름 학부생치고는 화려한 스펙을 내세워서 팀원들을 구하고자 했다.

 

사실 그 전에도 희원이같은 친구들은 팀을 이미 거의 다 꾸려온 상태에서 나한테 "우리팀 올래?" 제안은 많이 받았지만 팀장을 하고 싶어서 거절을 하다보니 사실 베스트로 팀을 꾸리기는 쉽지 않았다. 일단 처음에는 같이 하기로 했던 영서하고 같이 팀을 하기로 했고, 재현이가 지훈이형과 하은이를 데려와서 팀을 꾸릴 수 있었다. 

 

그리고 이번 프로젝트에서의 내 나름대로의 목표가 있었다.

 

1. 내가 주도적인 역할을 맡아서 수상(목표 등수는 당연하게도 1등)하기

2. 수평적인 의사소통을 통해서 문제를 해결하기

3. 나와 팀원들이 모두 이 프로젝트를 계기로 성장하기

4. 팀원들과 나중에도 친하게 지낼 수 있도록 팀을 운영하기

5. 자발적으로 자신이 맡은 일을 할 수 있는 팀을 만들기

 

지금 생각하고 보면 꽤나 당돌했던 거 같다. 

 

그래도 항상 새로운 일에 대해서 도전을 시작할때는 항상 설레는 마음으로 시작하는 건 좋았다. 

그렇지만 이 때 사실 고민이 있었다. 새롭게 밑바닥부터 프로젝트를 진행하는지, 아니면 기존에 진행되던 프로젝트를 개선하여 클라우드를 활용하는지에 대한 문제였다. 새롭게 프로젝트를 진행한다면 일단 내 입장에는 새로운 기술스택을 익히기 편하다는 장점은 있었다. 다만 이 경우에는 짧은 기간동안 기획부터 시작해서 개발 외적으로 해야 할 일들이 너무 많다고 생각했고, 결정적으로 클라우드를 활용하기까지에는 꽤 시간이 많이 필요할 것이라고 생각이 들어서 기존에 진행하던 원격의료서비스 "메디로그"를 개선하기로 결정했다.

 

그래서 팀원들에게 아이템에 대해서 PT와 데모, Q&A를 진행하면서 어느 정도 이해도를 높이고자 하였다. 자율적으로 프로젝트에 참여하는 팀을 만드는 첫걸음은 바로 "모두가 아이템에 대한 이해도가 높은 상황" 이라고 생각했기 때문이다. 

 

그 후 그렇게 교육이 끝나고, 첫 회의를 진행하면서 아이템 선정과 함께 어떤 일을 해야하는지에 대한 outline을 설계했다.  

이 때 가장 중요하게 생각한 것은 바로 '나 혼자서는 이 일을 다 할 수는 없다.' 라는 것이었다. 그렇기에 팀원들이 자율적으로 프로젝트를 진행하면서 성장하기를 바랬다. 그렇기에 위험한 상황이 아니라면 직접적으로 팀원의  여유를 갖고 구현안을 함께 검토하거나 짝코딩을 통해서 개발을 진행했다.

위는 첫 회의 때 정해진 task를 정리하여 slack에 공유한 것을 일부 캡쳐했던 것이다. 

정말 고맙게도 첫 회의부터 내가 어느정도의 방향을 제시하니 다들 자발적으로 아이디어를 가져오고 개선방안에 대해서 생각하고 아이디어에 대한 토의가 이루어졌다. 특히 재현이가 이런저런 아이디어를 많이 줬는데 적극적인 팀원은 항상 프로젝트를 할 때 큰 힘이 된다고 느꼈다.

 

그리고 그 이후에는 정해진 task를 팀원들에게 할당하는 과정이 필요했다. 아무래도 자신이 맡고 싶어하는 일을 하도록 하는 것이 motivation 측면에서 더욱 좋을 것 같아서 자신이 해결하고 싶은 이슈를 해결하는 것으로 방향을 잡았다. 그리고 각자가 해결할 수 있는 문제를 맡는 것에도 신경을 써야 했다. 대표적으로 다른 친구들은 모두 4학년인데 비해 영서는 이제 막 2학년을 마친 상황이었기에 main position을 잡고 개발에 참여하는 것보다는 기능 단위의 개발을 하는 것이 조금 더 목적 달성에 수월할 것이라고 생각했기에 퀴즈와 캘린더 기능 개발을 맡기고 꾸준하게 코드리뷰를 하는 것을 목표로 했다.

 

지금 다시 슬랙을 보면 사실 많이 부끄럽다. 가장 큰 문제는 팀원들의 업무역량을 정확하게 파악이 되지 않았는데 task를 할당하다보니 비효율적인 부분이 많이 발생했던 것 같다. 어느 프로젝트를 하더라도 learning curve는 필요하겠지만, 여기에 너무 많은 시간을 써서 마감기한이 다가올수록 마음이 급해졌고, 결국 일부 기능들의 구현을 포기했다.

 

그리고 task 자체가 너무 추상적이라는 것도 아쉬웠다고 생각한다. 대표적으로 내가 맡은 일 중에서 "기존의 코드를 리팩토링을 빠르게 한다" 라는 목표가 있었는데 저런 방식으로 task를 작성하면 어떻게, 얼마나와 같은 구체적인 정보들은 처음에 생각했던 기획과는 많이 달라지게 된다. 그렇기에 다음 OKR 미팅이 되었을 때 물론 찰떡같이 완료된 task들도 있었지만, 그렇지 못한 task들도 많았다.

 

그렇지만 프로젝트를 시작하는 시점에서 만족스러운 점들도 많았다. 프로젝트를 진행할때마다 느끼는 건데, 모두가 자신이 맡은 task의 진행상황을 공유하는 것에 대해서 평소에도 정말 중요하게 생각을 했었다. 오픈소스나 협업 툴에 익숙한 사람이라면 특별히 notice를 주지 않더라도 task가 어떻게 진행되고 있는지 확인을 할 수 있겠지만, 팀 프로젝트를 처음 접하는 팀원들도 꽤 많았기에 틈틈히 상황을 공유할 수 있는 방법을 생각해야 했다. 

 

 

그래서 일단 각자 task가 완료되거나 뭔가 문제가 생긴 경우, 그게 아니더라도 공유하고 싶은 정보가 있으면 자유롭게 slack에 올려서 공유를 하고자 했다. 그리고 모든 팀원들은 디자인은 figma를 통해서, 코드는 github을 통해서 언제나 확인할 수 있도록 공유하였다. 그리고 이를 바탕으로 피드백 및 리뷰를 진행하는 방식으로 task를 진행하였다.

또한 의견을 자유롭게 말할 수 있는 환경을 조성하고자 하였다. 
그래야만 1명이 이끄는 팀이 아니라 모두가 자신의 일에 대한 이해도를 높이고, 책임감을 가질 수 있다고 생각하였다. 그렇기에 모두가 "좋아" 라고 말하지 않는 회의를 하게 되었다. 동기부여도 중요하지만, 일차원적으로 꾸준히 동기부여를 시키는 것 보다는 스스로 동기부여를 할 수 있도록 시스템을 변화시킬 수 있는 방법을 찾는 것이 효과적이고 확실하다고 생각하였기에 다 같이 참여할 수 있는 환경을 만드려고 노력했고, 팀원들의 생각과 자율성을 존중하면서도 아무 말(?)을 할 수 있도록 가벼운 분위기를 만드려고 했다.

 

그렇게 프로젝트를 진행하던 중 첫번째 큰 문제가 발생했다.

아무래도 의료쪽 서비스를 개발하다보니 의료 데이터가 많이 필요한데, 의료데이터 대부분은 공공기관의 사용허가를 받아야했고,  그 절차또한 까다로웠다. 대표적으로 연구 목적이 뚜렷하지 않으면 사용허가를 받기 어려운데, 단순히 프로젝트를 진행하는 입장에서는 허가를 받는 것이 까다로웠다. 세삼스럽게 이런 데이터들을 척척 받아왔던 성환이형이 정말 대단하게 느껴졌다. 두번째로는 허가를 받더라도 개발을 위해서는 기관을 직접 방문해서 지정된 PC로만 사용할 수 있는 경우가 많았다. 

환자 개별로 라벨링이 되어있는 데이터를 얻으려고 몇일동안 여러 방면으로 서치하고 문서작업을 하다가 결국은 범용적인 만성질환 데이터를 도저히 구할 수가 없어서 특정 질환에 한해서만 classification되어있는 데이터를 구해서 학습시키는 방향으로 변경하였다. 그 중에서 데이터셋이 가장 마음에 들었던 당뇨병 환자 샘플에 대해서 학습을 시키는 방식으로 MVP를 구현하게 되었다. 

모델은 크게 2가지 역할을 할 수 있도록 설계하였다.

1. 학습된 모델에 환자의 의료정보를 입력하면 환자가 정상, 주의, 위험군 중 어디에 속하는지 classification 해준다. 이 때 각 군에 속할 확률을 구한 다음, 가장 확률이 높은 군으로 classification한다.

2. 만약 주의, 위험군에 속한다면 이에 가장 크게 영향을 미친 상위 3개의 factor를 추출한 후, 해당 지표를 개선하기 위한 맞춤 솔루션을 제공한다.

 

두번째 문제 : 이상적인 개발 프로세스에 대한 고집과 아슬아슬한 마감기한 사이의 줄타기

한달 정도는 처음에 생각했던대로 스스로 맡은 task에 대해서 상황공유를 꾸준히 하고 자율적으로 맡기는 프로세스가 잘 진행이 되었다. 아무래도 나름대로 마감이 많이 남았다보니 심적으로도 여유가 있었던 것이 큰 것 같다. 그렇지만 몇몇 task는 계속 진행이 밀리는 느낌이 들었고, 그 느낌은 어느샌가 프로젝트를 망칠만한 큰 이슈로 다가왔다.

 

일단 첫번째로는 영서가 맡은 기능 중, 캘린더에서 심각한 오류가 발생했다. 

이전까지는 내부에서 이미 데이터를 배열로 만들어둔 다음, 화면에 뿌릴 떄 그 데이터대로 캘린더에 환자와 의사의 일정을 캘린더에 저장했는데, backend에서 DB에서 일정을 받아온 후, API를 통해 프론트엔드로 전달하는 과정에 대해서 이해도가 부족한 상태에서 코드를 작성한 것이 문제였다. 

 

기존에 배열로 만들어둔 데이터의 경우에는 lifecycle에서 API에서 받아오는 시간을 고려하지 않아도 된다. 왜냐하면 이미 frontend에 데이터가 있기 때문에 바로 rendering을 할 수 있다. 다만 서버에서 유저의 일정 데이터를 받아오는 경우에는 문제가 발생한다. 처음 rendering하는 시점에서는 일정 데이터가 존재하지 않기 때문이다. 그렇기에 없는 데이터를 요청하기에 오류가 발생한다.

 

해결방법 : react의 lifecycle을 조율하여 문제를 해결하였다. 

다만 이걸 해결하는데 생각보다 시간이 좀 오래 걸렸다.

(자세한 내용은 나중에 log 살펴보면서 쓰겠습니다...)

원래는 어느정도의 힌트만 주고 해결은 스스로 하도록 하고싶었으나 마감이 다가오니까 내가 해결할까? 라는 충동을 참기 어려웠다. 그래서 결국은...

버그를 내가 싹 다 고쳤다... 근데 정작 나도 프론트엔드 개발자가 아니기도 하고 react도 한 4~5년만에 하다보니까 까먹은 것들이 너무 많아서 재학습시간이 꽤 들었는데 이전부터 조금 더 팀관리를 잘 해왔더라면 이런 일이 없었지 않았을까... 하는 아쉬움이 들었다.  그리고 영서 개인에게도 이런 문제를 해결하는 경험을 주고 싶었는데 마감에 쫒기다보니 그러지 못한 것이 약간은 미안했다.

 

 

두번째로는 웹 퍼블리싱을 하기로 한 팀원이 업무진행이 지나치게 느렸던 것을 안일하게 대처한 것이다.

사실 나중에 술 한잔 하면서 풀기는 했지만 이 이슈가 프로젝트를 완전히 날려먹을만한 이슈인지라 정리를 하고자 한다. 

이번 캠프에서는 개발 기간이 약 1달반 정도로 짧은 편이었다. 그렇기에 각자가 배우고 싶은 기술스택을 사용해서 완전히 바닥부터 개발을 하는 것 보다는 기존에 익숙한 필드에 최대한 관련된 일을 하면서, 이러한 서비스들은 AWS와 Elastic Cloud를 활용하여 운용하는 것에 초점을 맞추고자 했다.

 

그래서 1년간의 인턴 경험이 있는 팀원에게 프론트엔드 전반을 맡겼다. 사실 이전에 인턴을 하면서 ourB를 개발할 당시에 같이 일했던 프론트엔드 개발자는 뭐든 뚝딱뚝딱 잘 만들었던 친구라서 대략 비슷하지 않을까? 라는 안일한 생각이 있었다. 나도 이전에 풀스택을 했을 때 프론트엔드쪽이 그렇게 어렵다고 생각하지 않았던 것도 어느정도 있고 말이다.

 

그래서 그 팀원이 개발 초반부에 장염이 걸리거나 시간이 잘 나지 않는다고 할 때도 관대하게 넘어갔었다. 나중에라도 시간을 투자하면 충분히 할 수 있다고 봤기 때문이다. 그렇게 '지금부턴 좀 해야하는데...' 라고 생각한 시점보다 약간 빠르게 "이거하고 저거 반드시 언제까지 끝내야해요. 백엔드에서는 API 테스트가 다 끝났고, 디자인도 다 나와서 퍼블리싱하고 API문서 참고해서 연결하시면 돼요!" 라고 말을 했다.

 

그 형도 알겠다고 하면서 이제 어느정도 업무를 시작하려고 할 때...

퍼블리싱은 완전히 처음 해본다고 했다.

 

'...?'

'그걸 왜 이제와서...?'

 

그렇지만 당장 화를 내는 것은 서로의 기분만 상할 뿐, 팀에 실질적인 이득을 가져다주지는 않는다.

그래서 최대한 빠르게 진행하라고 했고 그때부터 퍼블리싱 업무를 계속 모니터링하면서 다른 일도 하다보니까 내 개발속도가 확실히 더뎌졌다. 그렇지만 디자인과 백엔드 API가 다 짜여져있다고 하더라도 퍼블리싱이 안되면 데모에서는 아무것도 보여줄 수 없기에 신경을 써야만 했다.

 

그렇게 마음을 졸여가면서 지켜봤는데... 

이때문에 스트레스를 심하게 많이 받았기도 하고, 결국 나도 어느정도 퍼블리싱을 해서 겨우겨우 완성은 했다. 

 

이 때 느낀 게, 만약 이상할 정도로 진행상황이 느리다면 반드시 체크하고 문제를 해결할 수 있도록 해야 한다는 것이었다. 이 경우에는 사실 역할분배 문제도 물론 있었겠지만 결국 매니징이 조금 안일해서 생긴 문제라고 생각한다. 그래서 일단 문제를 급하게 해결하려고 지훈이형한테 압박을 주면서 같이 하는 방식으로 문제를 해결했는데 , 장기적으로 봤을 때 유능한 팀에서 좋은 방식은 아니라고 생각한다. 나중에 팀을 매니징할 상황이 주어지게 된다면 이 점부터 개선을 해야 할 것 같았다. 역시 PM은 아무나 하는 게 아닌가 싶기도 하고... 마지막으로 갈수록 마음이 급하니까 주먹구구식으로 운영을 하면서 내가 모든 일에 매니징이 아니라 코드를 직접 짜버리는 식으로 손은 댔다. 나중에 이 부분은 어떤 방식으로 due가 얼마 안남았을 때 팀을 이끌어야 하는지 생각을 좀 더 해봐야 할 것 같다. 여튼 그렇게 마지막 1주일은 잠도 줄여가면서 꾸역꾸역 개발을 했고, 결국 어느정도 목표한 정도로는 개발을 마무리 할 수 있었다.

 

전체적인 프로젝트 구조

먼저 유저들이 의료 데이터 등의 정보들을 입력하면,  server로 전송되어 1차적으로 설계한 mongodb 스키마로 가공되어 저장된다. 이 때 data를 바로 elastic search에 저장하지 않은 이유는 ES가 트랜잭션, rollback, ACID 속성을 보장하지 않기에  프로젝트의 main db로 사용하기 적합하지 않았기 때문이다. 그래서 MongoDB는 메인 데이터 저장소로 data ingestion에 사용하고, 분석에 필요한 필드만 ES에 동기화해서 사용했다. 마지막으로 elastic search에 저장된 데이터를 시각화하기 위해 kibana를 사용해서 시각화를 했다.

 

여기서 아쉬웠던 점은 바로 Elastic Search에 대해서 미숙했다. 그리고 사실 정형화된 데이터만 들어왔기에 굳이 ES에서 데이터를 관리할 필요성을 느끼지는 못했다. logstash를 활용한 데이터 관리와 kivana를 활용한 데이터 시각화를 지원하는 것은 편리했지만, 이번 프로젝트에서는 잘 활용할만한 방법을 찾지는 못했다.

그리고 데이터 시각화를 어떻게 하는 것이 더 효율적으로 지표를 보여주는지에 대해서 무지했다. 어떤 데이터를 잘 다루기 위해서는 그 분야에 대해서 일정 수준 이상의 지식이 있는 것이 큰 도움이 된다고 생각한다. 그렇지만 우리는 의학에 대해서 잘 알지는 못했고, 그렇기에 지표를 어떤 방식으로 보여주는 것이 더욱 효과적으로 환자의 상태를 보여줄 수 있는지에 대해서 파악하기 어려웠다.

 

cloud architecture 구조

 

그리고 상담을 하고 난 후, 의사가 직접 상담 내용을 작성하는 것에 큰 불편함을 느꼈다.
그렇기에 이를 자동화하고자 상담 시 음성녹음을 하고, 상담이 끝나면 음성 파일을 s3에 저장한다. 그리고 S3에 파일이 저장되면 해당 이벤트를 AWS lambda를 통해서 감지한 후, trigger를 통해 AWS transcribe를 통해 speech to text로 변환하는 과정을 거쳐서 음성 파일을 텍스트로 변환하였다.
그리고 chat-GPT를 이용해서 이러한 상담 데이터를 가공했다.
잘못 인식된 발음을 수정하고, 전체적인 상담 내용을 요약하도록 prompt engineering을 하였고, 이렇게 생성된 data는 backend의 API를 통해서 db에 저장되는 로직으로 구현되었다.

 

 

최종 결과

사실 정말 직전까지 bug fix를 하느라 사실 발표 준비를 그렇게 많이 하지는 못했다. ppt는 발표자가 만들어야 한다는 철학이 있어서 바쁜 와중에 ppt도 내가 설계해서 하은이하고 같이 만들어서 이 페이지에서 이런 이야기를 하면 되겠다라는 생각 정도를 가지고 발표장에 들어갔다. 원래도 사실 발표에 어느정도 자신이 있는 편이라서 이정도면 괜찮겠지... 라고 생각하고 발표를 진행을 했는데... 두달간을 갈아넣었던 걸 보여주려니까 긴장도 되고 떨렸다. 그래도 어찌어찌 발표를 어느정도 마무리짓고, 데모를 하면서 설명을 하려고 ppt를 끄고 서버를 켰어야 하는데... 실수로 서버를 꺼버렸다...

 

너무 당황해서 그런지 나도 정신줄을 놓고 횡설수설을 갈겨버렸고, 결국 데모를 의도한 것의 절반정도밖에 보여주지 못하고 발표시간이 마무리가 되었다. 팀원들이 고생했다면서 위로? 격려? 를 해주는데 사실 2달간 고생한 팀원들이 했던 걸 제대로 못보여줬다는 생각에 죄책감도 들었고, 내 노력이 이렇게 물거품이 될 거 같아서 너무 억울하고 나 스스로에게 화가 났다.

 

타팀들의 발표를 보니 다들 결과물도 괜찮았지만 그 이상으로 잘 표현을 한 것 같아서 더욱 비교되는 느낌이었다. 그렇게 온갖 생각들이 들던 발표가 모두 끝나고 화장실에 가서 세수라도 하면서 정신을 좀 차리려고 했는데...

 

"팀 순위를 발표하기 전에 먼저 팀을 이끌어줬던 리더들에 대해서 수상이 있겠습니다. 특히 몇분들은 정말 멱살잡고 팀을 이끌었다라는 말이 걸맞게 정말 학생이라고는 믿기지 않을 정도로 훌륭하게 잘 프로젝트를 진행해줬는데 그 분들 중 2명을 선정해서 수상을 하도록 하겠습니다."

그 이야기가 나오기 무섭게 우리 팀원들이 다 나를 쳐다보면서 "이거 100퍼 너한테 하는 말인데?"

솔직히 정말 고생을 많이 하긴 했어서 내심 기대를 했고, 베스트리더 2위는 희원이가 받았다.

 

그리고 "이번 대회에서 가장 열정적으로 팀을 이끌었던 베스트 리더 1위는..."

"발작버튼 팀의 강희님 정말 고생 많으셨습니다 ㅎㅎ 앞으로 나와주세요!"

베스트 리더 1위 수상

 

그 순간 그래도 어느정도 내 노력이 헛되지는 않았구나... 라는 생각이 들면서도 아까 발표를 너무 못한 게 아쉬워서 수상소감에 표현을 못해서 아쉬웠던 점들에 대해서 간단하게 이야기하고 자리로 들어갔다. 물론 프로젝트에 대한 상도 받아야 하겠지만 그래도 이렇게 못했던 말들을 다 하고 나니 속은 시원했다.

 

그리고 결국 프로젝트는 2위 수상을 할 수 있었다. 내심 우리 프로젝트가 가장 볼륨이 큰 프로젝트라고 생각하기도 했고, 완성도도 가장 높았다고 생각해서 아쉬웠지만 발표 중에 큰 실수를 한 것에 비해서는 꽤 선방했다고 생각해서 정말 안도의 한숨을 쉬었다. 그리고 실력적으로 성장한 것 이외에도 이번 대회를 계기로 다시 자신감을 얻을 수 있어서 심적으로도 꽤 의미가 있었던 대회였다. 

 

여튼 그렇게 수상이 끝난 후, 우리는 신촌으로 가서 회포를 풀면서 술을 진탕 마셨다. 그러면서 그동안 서운했던 점들을 하나씩 풀면서 "상 받았잖아~ 한잔해~" 만 몇번을 말했는지 ㅋㅋㅋㅋㅋ 그리고 취한 채로 전화하다가 잠들었다.

 

프로젝트를 마치면서...

 

그리고 사실 이런 상황을 겪다보니 꾸준하게 자신의 task를 기한 내에 마감해줬던 하은이한테 정말 고마웠다. 이미 인턴으로 일을 하면서도 항상 OKR 미팅 때 목표로 했던 일을 완료했고, 중간중간에 정보 공유 및 피드백도 정말 자주 했다. 사실 나하고 추구하는 디자인 스타일이 완전 다르기는 했지만, 그 나름대로의 매력이 있었기에 나름대로 귀여운(?) UI를 가진 서비스를 만들 수 있었다. 소소하게 하은이의 맥북하고 내 노트북하고 색감 표현이 많이 달라서 생긴 이슈 정도는 있었지만, PM의 입장에서는 계산이 서는 팀원이 있다는 것이 얼마나 소중한지 알게 되었다. 이번 프로젝트에서는 자율적으로 팀원들에게 task를 맡기는 스타일로 관리를 하였는데 그 방식의 장단점을 모두 봤던 프로젝트였다. 

 

그리고 사실 PM을 하는 것에 너무 많은 시간을 쓴 나머지, backend 엔지니어로써의 나는 솔직히 말해서 큰 발전은 없었던 거 같다. 물론 일단 머리부터 들이내밀고 봤던 이전과는 달리 nodejs의 best practice를 보고 아키텍쳐를 개선하고, 각각의 코드들을 모듈로 분리하려고 노력하긴 했다. 다만 그럼에도 이전에 했던 것을 리팩토링하는 것 그 이상도, 이하도 아니였기에 개발능력이 향상되었다고 생각하지는 않는다. 엔지니어 입장에서는 참 아쉬웠던 프로젝트였다.

고등학교때 SW 개발에 관련된 서적을 많이 봤는데 왜 관리자가 되더라도 최신 기술에 대한 트랜드를 놓지 마라고 하는지도 어느정도 이해를 한 계기가 되었고, 그 사람들이 정말 대단하다고 느끼기도 하였다. 

 

 

아직 써야 하는 부분들... (미완성)

- PM을 하면서 느꼈던 점들

 

- frontend에서 발생했던 bugfix

 

- 개발자에게 요구되는 리더십????
제품을 어떻게 만들고, 어떻게 소통할지, 어떻게 일이 되게 할지를, 스스로 결정하는 과정에 대해서 쓰기

또한 팀원에게 큰 그림을 보여주고자 노력했다. 그래야 현재 팀의 상황을 파악하고 자신이 무엇을 어떻게 해야하는지 알 수 있다.