[Portfolly] 스프린트 1주차 회고

벌써 메인 프로젝트(Portfolly)의 1주 차 스프린트 기간이 지났습니다. 정확하게는 주말 제외 7월 7일(금)까지였지만, 늘 주말까지 넉넉하게 추가 사용하기 때문에 매주 일요일마다 회고를 가지게 되었습니다. 이번 프로젝트는 특별하게도 멘토링 시스템이 존재해서, 매주 수요일 멘토님께 프로젝트 현 상황에 대한 보고를 하고 피드백을 받게 되었습니다.

지난주는 프로젝트를 막 시작하면서 여러 가이드라인을 제공해 주셨는데, 지금 작성하는 회고 방식이 바로 그 중 하나입니다. 정확히는 회고 방식이라기 보단 취업 전 나를 돌아보는 과정이지만, 질문에 답을 하다보니 저절로 회고가 되어서 매주 일요일 회고시간에 같은 질문에 답을 하면서 달라지는 모습과 쌓이는 내용을 점검하고자 합니다. 늘 어디서 보고 배운 KPT 회고를 엉성하게 하고 마치기 일쑤였는데 이건 조금 더 구체적으로 분석할 수 있다는 점에서 좋은 방법이라고 생각되어 꾸준히 해볼 생각입니다.
 
 
 

1. 나의 약점은 무엇인가

 
1) 컴포넌트 단위로 UI 작업을 할 때 시간이 너무 오래 걸렸습니다.
이전 Pre-Project 때도 느낀 부분이었습니다. 기능에 관련된 코드를 짤 때는 '당장 굴러가게 만든 다음 나중에 정리하자'라고 생각하며 코드를 작성하느라 행동이 느리지 않은 반면, 오히려 아무 기능이 없는 UI를 구현할 때면 이 컴포넌트를 어디까지 확장시킬 수 있을지, props를 너무 많이 받을 바엔 차라리 별개의 컴포넌트로 떨어트릴지, 기능이 들어가기도 전에 코드가 너무 복잡한 건 아닌지 고민하느라 한 줄 한 줄 작성하는 시간이 너무 길었습니다.
 
2) 옛날부터 늘 환경 설치가 힘들었습니다.
특히 이번에는 vite, typescript를 기반으로 다양한 라이브러리를 설치하다 보니 더 그랬던 것 같습니다. 원하는 조합으로는 지원이 안 되는 라이브러리가 있었는데, 그럴 때마다 왜 지원이 안 되는지, 그걸 해결하기 위해 무슨 컴파일러를 사용해야 하며 어떤 설정을 추가해야 하는지 정리하느라 머리가 아팠습니다. 분명 다음에 똑같은 환경에서 프로젝트를 진행할 때 지금처럼 버벅거리지 않으려고 설치 과정을 하나하나 기록해 두었는데, 나중에 확인해 보니 너무 뒤죽박죽이고 또 몇몇 부분은 그저 블로그를 보고 따라 했을 뿐 이 설정이 무슨 설정인지 설명을 못 하는 부분도 있었습니다.
 

2. 나의 강점은 무엇인가

 
1) 다소 길게 느껴지는 초기 작업이 끝나면 뒤로 갈수록 코드를 작성하는 시간이 많이 감소합니다.
이번주는 UI, 작은 데이터 요청 기능밖에 구현하지 않았지만, UI의 경우 재사용 컴포넌트를 만들고 나면 재활용의 연속이라 편했고, 기능적인 부분에서는 자주 쓰는 API 요청을 따로 빼두어 함수로 만들어두면 그 후에 호출하는 건 금방이었습니다.
 
2) 지나온 프로젝트 경험을 잊지 않고 같은 실수를 반복하지 않는 코드를 작성하려고 노력합니다.
서버 요청을 낭비했던 경험이 있다면 이번에는 더 나은 방식으로 비용을 줄인다든지, Pre-project 때 엉성하게 배우고 대충 사용한 react-query를 다시 공부하여 라이브러리의 장점을 최대한 살리는 것을 목표로 기능을 구현하고 있습니다.
 

3. 나의 팀워크 방식은 어떠한가

 
이번주는 팀워크에 관련해서 여러 가지로 생각이 복잡했던 시간이었습니다.
 
1) 본래는 프로젝트 설계를 제대로 마무리하고 이를 문서화한 뒤 다 같이 정해둔 걸 지키는 방향으로 가고자 하였습니다.
지금까지 프로젝트를 하면서 늘 기획/설계 단계에서 문서를 정확히 검토받고 구현에 들어갔기 때문에 거기에 익숙해져서 당연히 그래야 한다고 생각했습니다. 하지만 이번 팀활동에서는 그 또한 개인의 차이가 있음을 깨달았고, 저의 방식이 피곤함을 가져다줄 수도 있다는 것을 알았습니다. 또한 문서화를 할 거면 작성한 내용을 적어도 두 번은 꼼꼼히 확인받아야 한다는 걸 알게 되었습니다. 당시에 긍정의 대답을 얻더라도, 각자 머릿속에 생각하는 부분이 다른 채로 긍정할 수도 있기 때문에 헷갈릴만한 부분을 꼼꼼하게 정정하고 재차 물어봐야겠다고 생각했습니다.
 
2) 각자 의견에 대한 이유를 공유하고 적절한 방안을 찾는 토의를 가지고자 했습니다.
그런데 저도 모르게 이유를 공유하는 게 아니라 이유를 집착하는 사람이 되어버린 것 같습니다. A방안에 대한 이유가 궁금하면 그냥 솔직하게 물어보면 되었을 텐데, 당시에는 직설적으로 이유를 물으면 조금 따지듯이 들릴  
거라고 생각되었습니다. 그래서 '나의 이유를 먼저 설명하면서 상대방의 이유를 유도하자'라고 판단했고, '저의 경우 ~한 이유로 B방안을 제안하는 거거든요'라고 말했는데 되려 이유를 추궁하듯이 말해버린 것 같습니다. 오히려 '~한 이유로 내 의견이 무조건 맞아'라고 고집을 부리는 것 같은 태도처럼 보인 것 같습니다. 돌려말하되 목적을 정확하게 전달할 수 있는 충분한 기술이 없다면 차라리 솔직하게 궁금한 점을 묻는 게 더 나은 소통 방식이라는 걸 배웠습니다.
 
3) 때로는 팀원의 성향에 따라 분석과 배려를 적절히 선택해야겠습니다.
또한 위와 같이 이유를 추합 하여 모색하는 것도 개인의 성향차이라는 걸 알게 되었습니다. 협업을 중시하는 방향이라면 그냥 다수결의 의견을 바로 따르는 게 편한 경우도 있다는 걸 알게 되었습니다. 누구 하나 더 특출 난 실력이 있는 것도 아닌데 이유를 묻고 장단점을 분석하는 과정은 현재 제가 가진 수준에서는 크게 메리트가 없다는 것을 알았습니다. 그냥 모두의 의견을 따라보고, 직접 겪은 뒤에 어떤 점이 좋았고 어떤 점이 부족했는지 깨달으면 되는 거였다는 걸 늦게 알게 되었습니다.
 
4) 당장 오해부터 하지 말고 먼저 물어보는 방식의 태도를 가져야겠다고 생각했습니다.
구현을 막 시작하고 라이브러리를 하나로 통일하는 게 어떠냐는 의견이 들어와 조금 당황했던 상황이 있었습니다. 두 라이브러리 사이에 충돌이 났다는 사실을 전달받지 못했기 때문에 그냥 특정 라이브러리로 통일하자는 의견이 조금 강제적으로 느껴졌습니다. '기술 스택 정할 땐 그런 말 없었는데 왜?'라는 불편한 마음을 가지고 다음날 회의에 참석했는데, 두 라이브러리 간 충돌이 일어났다는 말을 듣고서야 '아, 그냥 내가 먼저 이유를 물어볼 걸'이라는 생각이 들었습니다. 오해로 인해 기분이 상하기 전에 조금 더 자세히 소통하려는 자세를 가지기로 했습니다.
 

4. 나의 열정은 어떤 방식으로 표출되는가

 
프로젝트에 대한 꼼꼼한 정리 및 노트북 앞에 앉아있는 시간으로 표출됩니다.
 
잘 해내고 싶은 프로젝트일수록 과정 중에 어설픈 부분이 없게 최대한 설계를 꼼꼼히 하고자 하는 타입입니다. 분석이라는 건 구현 도중에도 발생하고 설계는 언제든 수정될 수 있지만 구현에 돌입하기 전 기반이 되어줄 만큼은 작성하는 게 저의 방식입니다.
 
또한 당연한 거겠지만, 프로젝트에 진입하게 되면 늘 노트북 앞에 앉아있는 시간이 배로 길어지는 것 같습니다. 다만 풀리지 않는 문제로 스트레스받으며 앉아있기보다는 조금 더 해볼까 라는 마음으로 즐겁게 집중하는 편이라 더욱 이를 열정이라고 표현할 수 있는 것 같습니다.
 

5. 나의 근면성실을 어떻게 설명할 수 있는가

 
1) 개발 과정을 작성하며 프로젝트를 진행하고 있습니다.
개발을 하다가 깨달은 부분을 나중에 까먹지 않기 위해 반드시 기록을 해둡니다. 가끔 에러 해결에만 급급하여 기록을 깜빡할 수도 있지만 지난 프로젝트에서 그랬다가 후회한 적이 많아서 이번 메인 프로젝트만큼은 닥친 문제와 해결과정, 참고자료를 가볍게 기록해 둡니다. 그리고 기록을 참고하여 매주 주말 그에 대한 구체적인 블로깅을 (느리더라도) 조금씩 합니다.
 
2) 제가 작성한 코드를 제가 잘 모른다면 그건 코드로 받아들이지 않습니다.
자료가 방대한 환경에서 코딩을 하다 보니 다른 사람의 코드를 눈치껏 조금만 조합해도 잘 굴러가는 결과물을 얻을 수 있는 것 같습니다. 예전에는 그렇게라도 기능이 동작을 하면 기뻐하곤 했는데, 이제는 스스로 정확하게 분석이 가능한 코드가 아니라면 절대 작성하지 않습니다. 어떤 코드를 작성해보고 싶다면 정확하게 뒷받침할 근거가 존재할 때까지 분석하고 공부합니다.
 

6. 나는 왜 업무를 즐기는가

 
1) 늘 생각지도 못한 부분에서 신경 써야 할 점들을 깨닫는데, 그 과정에서 재미를 느낍니다.
다양한 프론트엔드 개발 관련 도서를 읽다 보면 '이런 부분까지도 구체적으로 신경 쓸 필요가 있구나'라고 깨닫는 점들이 우수수 쏟아집니다. 그런 것들을 보다 보면 이전에 작성한 코드의 부족한 점을 깨닫게 되고, 다음 프로젝트 때는 새로운 방식을 도입하게 됩니다. 그 과정이 마치 게임처럼 끊임없는 도전 과제가 떨어지는 것 같아 질리지 않고 발견하는 재미가 쏠쏠한 것 같습니다.
 
2) 앞으로도 평생 '이 분야에선 배울 만큼 다 배웠다'라는 지루한 생각이 들지 않을 것이기 때문입니다.
프론트엔드 개발이 특히 새로운 기술로 교체되는 기간이 짧아 끊임없이 배우는 것에 지치는 경우도 있다고 하지만, 저는 오히려 그 부분이 적성에 맞다고 생각합니다. 한 가지에 정착해서 평생을 보내면 자칫 지루하고 딜레마에 빠질 수 있는데 배울 것들이 끝도 없이 쏟아지니까 마음은 조급하되 지루할 틈이 없어 계속해서 즐기게 됩니다. 특히 이번 프로젝트에서는 Node.js로만 구현해 본 웹소켓 통신을 Spring boot를 사용하는 백엔드 팀원과 도전해 볼 생각에 기대하는 마음이 큽니다.
 

7. 내 능력 중, 내가 구직하고자 하는 회사가 기대하는 것 이상의 능력이 무엇인가

 
사실 이 부분은 조금 판단하기 어렵게 느껴집니다.. 회사가 기본적으로 가지는 기대치는 모르겠지만 그래도 골라보자면
 
1) 오래 버티고 적응할 마음가짐이 강한 편입니다.
전혀 다른 환경에 닥치게 되었을 때 그만두고 싶다는 생각보다는 빨리 적응하고 편하게 임하는 방법을 터득하는 편입니다. 또한 새로운 환경 속에서 새롭게 배우고 깨닫는 걸 좋아하기 때문에 커다란 벽이 닥쳤을 때 금방 좌절하지 않습니다. 그걸 피해서 지나갔을 때 얻게 되는 쾌감을 알기 때문에 도전 정신으로 맞닥뜨리는 편입니다.
 

8. 내가 신뢰할만한 사람인 걸 어떻게 설명할 수 있는가

 
1) 지금까지 계획한 일 중에 시간이 부족하거나 능력 밖이라서 해내지 못한 적은 없었습니다.
느리다면 느리다고 먼저 고백하고, 시간/능력 문제로 해결하지 못할 것 같으면 제시하지 않습니다. 예전에는 부족함을 감추고 싶어 무작정 해보겠다고 대답해 놓곤 도움을 부탁한 적이 있는데, 그때의 반성 뒤로 지금은 할 수 있는 것과 없는 것을 명확하게 구분 짓게 되었습니다.
 

9. 내가 체계적인 사람이란 걸 어떻게 증명할 수 있는가

 
1) 프로젝트를 최대한 자세히 설계하려고 하고, 기획한 설계에 따릅니다.
개발 실력은 뛰어나지 않지만.. 몇 년간 전공자로서 프로젝트를 진행하는 방법을 배우면서 체계적으로 프로젝트를 진행하기 위해서는 무슨 과정을 거쳐야 하는지는 알게 되었습니다. 갑자기 다른 말이 나오거나 두 번씩 회의를 거쳐야 하는 일이 발생하지 않도록 추상적인 기획은 피하는 편입니다. 본 프로젝트도 노션에 문서화를 하여 헷갈리거나 다시 한번 확인이 필요한 부분을 언제든 펼쳐볼 수 있게 정리해 두고 구현에 돌입했습니다.
 

10. 내가 고객중심으로 사고하는지 어떻게 설명할 수 있는가

 
1) UI 설계를 하면서 아주 디테일한 부분이라도 사용자 흐름을 정확히 판단합니다.
사소한 부분이라 중요해 보이지 않더라도, 현실에서 사용하는 웹사이트를 떠올리면서 최대한 사용자가 거쳐야 할 생각의 흐름을 줄이고자 합니다. 아주 간단한 예를 들자면, 글쓰기 권한이 없는 사용자의 경우 글쓰기 버튼을 눌렀을 때 '권한이 없습니다.'라는 알림을 띄울 수도 있지만, 애초에 보이지 않는 편이 사용자가 자신의 권한을 파악하는 데 있어 더 적은 생각의 흐름을 가지게 되므로 그쪽을 더 지향합니다.
 
2) 기능적인 측면에서도 고객이 더 편하게 기능을 사용할 수 있도록 성능 향상을 우선시합니다.
본 프로젝트에서는 포트폴리오 이미지를 보여주는 게 핵심 기능이기 때문에 고화질의 이미지를 어떻게 고객에게 빨리 보여줄 수 있는지 기능적인 측면을 고려하며 코드를 개선하고자 합니다.
 

11. 내가 다른 팀원과 다르다면 어디가 다른가

 
1) 시간이 걸리더라도 구체적인 설계를 하려고 합니다.
구현 기간에는 구현에만 집중할 수 있도록 기획/설계 단계에서 최대한 근본적인 설계를 먼저 끝마치고자 합니다. 프로젝트에 대한 문서화를 중요시하며 그때그때 작은 회의를 거쳐 결정하기보다는 초반에 진지하고 구체적으로 기반을 세워두는 걸 우선시하는 편입니다.
 
2) 다양한 의견에 대해 토의를 나누며 분석하는 걸 선호하는 편입니다.
최대한 서로의 의견에 대해 장단점을 깊이 분석하고 모든 조건을 만족할 수 있는 새로운 방안을 떠올리는 과정을 좋아합니다. 다만 여유롭게 공부할 수 있을 때나 그렇게 하는 게 좋다는 걸 최근에 알게 되었습니다.
 

12. 내가 한 모든 업무를 나열해 보시오

 
<UI>
1. 메인(카테고리) 페이지 카테고리 NavBar
2. 유저 프로필 컴포넌트
3. 포트폴리오 작성/수정 페이지
4. 포트폴리오 상세 보기 페이지
5. 게시판 댓글 영역 컴포넌트
 
<기능>
1. 포트폴리오 상세 보기 페이지 MSW로 GET 요청 테스트
2. 좋아요 버튼 기능 작업 중