[Spring_4기 본캠프] 1주차 - 팀프로젝트의 끝, 발표 | Day 16

  본 캠프가 시작하고 11월4일부터 오늘 11월8일까지 일주일간 진행했던 팀프로젝트를 발표하고 거의 끝이 났다.

왜 완전 끝이 아니라 '거의'냐.. 발표하면 끝난거 아니야? 답은 아니었다. 프로젝트가 끝나고 느낀점, 아쉬웠던 점, 프로젝트 중 생긴 문제점, 해결점, 개선하고싶은 점 등등... 오히려 프로젝트 준비 때보다 더 많은 생각을 하고 이에 대해 모두 대답을 해야 완전히 끝이 난다.

 

• KPT 회고란?

- Keep : 현재 만족하고 있는 부분, 계속 이어갔으면 하는 부분 (좋은 것을 유지)

- Problem : 불편하게 느끼는 부분, 개선이 필요하다고 생각되는 부분 (문제 정의)

- Try : Problem에 대한 해결책, 다음 회고 때 판별 가능한 것, 당장 실행가능한 것 (시도)

 

• KPT 회고의 목적

- 짧은 시간에 모든 구성원의 생각을 공유하고, 실행 가능하고 측정 가능한 Action 을 도출해낸다. Action은 다음 회고까지 실행하는 의견이다.

- 어떠한 목표를 가지고 업무를 했는지 되돌아보고, 어떤 점이 부족했는지 되돌아보고, 어떤 시도를 할 수 있을 지 파악할 수 있다. 

 

  이번 프로젝트 진행을 하고나서 KPT회고라는 방법론을 알게되었는데, 프로그래밍에만 국한되는 것이 아니라 다양한 단체, 협업에서 적용할 수 있는 좋은 방법이라고 생각되었다. 

 

[Keep] :

- 분업이 아닌 협업이라는 목표를 가지고 가자.

- 자유롭게 질문하고 성실히 답변해주는 문화를 가져가자.

- 내가 맡은 부분이 아니더라도 내가 진행하는 프로젝트 내에서는 모르는 부분이 없게끔 이해하고 배우려고 꾸준히 노력하자. 

 

[Problem] :

- 프로젝트 본격 진행 전 팀원들과 class 와 id를 획일화하지 않아 공유작업을 하는 면에서 소통에 문제가 생겼다.

- git 사용 시 일어나는 문제들 (git pull, git push를 진행 시 충돌 발생)

- 프로그래밍에 대한 지식이 부족해 내가 생각하고 있는 것을 실제로 구현할 때 생각만큼 되지 않았다.

- 질문을 하고, 답변을 받아도 해당 지식에 대한 완전한 확신을 가지고 남들에게 설명하지 못했다.

 

[Try] :

- 프로젝트 진행 시 유연한 코드 수정과 혼란 방지를 위해 클래스와 id명을 팀원끼리 명시하고 획일화하자. 주석을 잘 활용하자.

- 파일을 용도에 맞게 세분화 하고, 필요 시 branch를 생성해 동시 작업을 진행할 때 충돌을 방지하고 관리의 효율성을 높이자.

- 구글이나 서적, 챗GPT 등 1차적으로 모르는 개념에 대해 기본적으로 이해한 후 해당 지식에 대해 전문성이 있는 사람에게 질문을 하고,

다시 내가 이해한 것이 맞는 지 설명하면서 단계적으로 확신을 가져가는 방식으로 질문하자.

- 내가 할 수 있는 것 내에서도 최선을 다하고 내가 담당하지 않는 부분의 모르는 기술이더라도 꼭 물어보고 내 것으로 만들자. 

 

  처음으로 팀원들과 KPT 회고를 진행해봤는데 프로젝트 시작부터 진행했던 중간 과정, 그리고 발표까지 꼼꼼하게 되돌아보면서 내가 놓친 것이 있는지, 이번 진행이 매끄럽고 만족스러웠는지, 부족하고 아쉬운 점이 있었는지 등등 프로젝트 자체와 나, 팀원들에 대해서도 생각해볼 수 있어서 많은 것을 얻었고 또 배우게 되었다. 

당장 내가 실행할 수 없다면 어떤 식으로 개선점을 가져갈 것인지, 이번 활동에서 정말 나는 잘 해냈고 계속 지속해야할 것이 무엇인지를 

곰곰히 생각해보면서 다음 진행 때는 더 나은 방향으로 나아갈 수 있을 것이라는 자신감이 생겼다. 

 

  이번 프로젝트의 발표를 맡게되어서 정말 기뻤다. 내가 아는 것을 복습할 뿐만 아니라 몰랐던 부분을 알게되고, 배우고, 이해할 수 있는 기회를 얻었기 때문이다. 팀원 한 명이 없더라도, 그 부분을 내가 완벽하게 청중들에게 설명할 수 있어야 완벽한 발표라고 생각해왔는데 스스로 생각했을 때 굉장히 만족스러운 발표를 했다(물론 오랜만에 해봐서 호흡이 많이 딸렸지만..). 

 또, 다른 조의 발표를 들을 때 각자 정말 다른 아이디어와 취향, 구상이 신기하고 흥미로웠다. 개발자 튜터님들이 각 조에 대한 발표를 듣고 피드백도 해주셨는데 우리 조에도 해당되는 사항들이 있었다. 

 

① 디렉토리 구조에 대해 생각해라.

- 디렉토리 구조란, 프로젝트의 파일들이 얼마나 체계적으로 원하는 목적에 맞게 나뉘어져 있는지 나타내는 구조이다. 우리 조에서도 나타났던 공유 작업시 같은 파일 작업으로 충돌이 일어나 당황한 것만 봐도 디렉토리 구조를 생각하는 것이 얼마나 중요한 지 깨달을 수 있었다.

 

② 사용자 관점의 개발을 해라.

- 인터페이스 설계 시, 개발자가 아닌 사용자의 관점에서 쉽게 이해하고 사용할 수 있게 코드를 짜야한다.

- 사용자 맞춤 기능을 통해 차별화된 경험을 주어야 한다. 

- 사용자 관점의 개발을 하면 자연스럽게 품질 향상에 힘을 쓰게 되고, 사용자 또한 만족도가 올라가 선순환 구조를 가져갈 수 있겠다고 생각했다. 

 

특히 사용자 관점에서 개발을 해야한다는 것은 대학 시절 수없이 들었던 마케팅론에서의 주요 목표 중 하나였는데, 여기서 보니 매우 반가웠다. 내가 배웠던 모든 개념 중 가장 공감이 많이 갔던 구절이었다. 

 

 

Opinion

살면서 이렇게 좋은 팀이 있을까 싶을 정도로 정말 좋은 팀을 만나게 되었다. 일주일동안만 진행되는 프로젝트라서 모두 흩어지겠지만 

여기서 조이월드 팀원들과 나눴던 모든 경험들이 앞으로도 내가 팀프로젝트를 진행할 때 기준점이 될 것이다.

 

★새로 생긴 코너! 새로이 배운 개념 줄여서 나의 새배개!★

늘 줄글로 작성하고 나면 나중에 내가 원하는 개념을 찾기 힘들 것 같아서 새로 배운 개념을 짧고 간단하게 개념만 정리하는 코너를 만들어봤다. 개발사전이라고 해야할까..

 

- 트러블 슈팅 : 문제가 발생했을 때, 그 원인을 찾아내고, 해결하는 과정

- git ignore : 프로젝트에 원하지 않는 백업파일이나 로그파일, 혹은 컴파일 된 파일들을 git에서 제외시킬 수 있는 설정파일

- 디렉토리 구조 : 프로젝트의 파일들이 체계적으로 조직된 폴더 및 파일의 구조. 프로젝트의 파일들을 논리적으로 정리해주는 방법