최종 회고

Keep: 현재 만족스럽고 계속 이어나가고 싶은 부분

🫧 김유경

• 적극적인 의견 교류
다양한 의견이 필요할 때 소수만 의견을 내고 나머지는 의견 없이 동의만 하고 넘어가는 것이 아닌 본인의 의견을 제시하는 분위기라 좋았다. 그리고 본인의 의견을 주장하되 고집부리지 않고 자유롭고 수용적인 분위기의 회의시간이라 더 많은 의견이 나올 수 있었다. 이 적극적인 의견 교류가 결과적으로 팀프로젝트에 많은 도움이 됐다고 생각한다.

• 각자의 진행 상황을 공유하며 서로의 진행상황을 알 수 있었던 점
매일 조금씩이라도 진행 상황을 공유하며 서로의 상황을 알 수 있었다. 그 덕에 서로의 상황을 잘 알 수 있었고 간혹 마감기한이 임박한 경우 여유가 있는 사람이 다른 업무를 진행하며 업무 분담을 유연하게 변경할 수 있었다. 이런 점이 스프린트 기간 내의 할 일을 해내는 것에 큰 도움을 주었다.

• 공유하고 싶은 부분이나 새롭게 적용한 부분을 문서화하여 공유한 점
새로운 기술을 도입할 때 pr로만 작성하기엔 부족한 부분을 자세히 문서화하여 공유하여 본인이 맡은 부분이 아니어도 글을 읽으며 이해하기 쉬웠던 점이 좋았다.

🫧 모유경

• 의견 교류가 적극적이고 자유로운 점이 가장 만족스러운 부분이다. 더불어 초반에 토의해야하는 주제 & 자유로운 주제를 먼저 꺼내면서 유연한 분위기를 형성하기 위해 노력해주신 익님에게 감사하다는 말을 전하고 싶다!

• 진행상황을 가볍게라도 매일 공유한 부분이 좋았다. 이 과정을 통해 내가 담당한 부분이 아니더라도 일정이 여유로우면 적극적으로 업무를 맡아서 진행하려고 하는 팀 내 분위기 덕분에 일정이 밀리지 않고 마감시간에 맞춰 마무리 될 수 있었다고 생각한다.

• 공부를 하다가 새롭게 알게 된 부분이나 좋은 포스트를 만난 경우에 팀원 모두가 알 수 있도록 공유하고 설명해주는 부분이 좋았다.

• 문제 상황이나 더 공부하고 싶은 부분을 프로젝트에 실제로 적용하거나 문서화하여 기록해둔점이 좋았다.

🫧 최익

• 본인이 가지고 있는 생각에 대하여 눈치보지 않고 자유롭게 이야기하는 분위기. 어떠한 주제에 대하여 토론할 때 본인의 생각을 눈치보지 않고 자유롭게 공유하는 것과 각자 어려움을 겪는 부분이 있다면 빠르게 공유하고, 모든 팀원이 자신의 일을 제쳐두고 어려움을 함께 해결해주는 팀 문화가 프로젝트를 진행함에 있어서 너무 좋았다.

• 새롭게 알게 된 내용 공유하기. 각자 프로젝트를 진행하면서 맡은 역할이 다르고, 모두 새롭게 사용해보는 기술을 적용하는 부분이 모두 달라 학습적인 부분에서 놓칠 수 있는 부분이 많았는데, 본인이 학습하고 사용한 부분에 대해 가볍게라도 공유하여 함께 학습 할 수 있던 부분이 좋았다.

• 작은 문제애 대해 오래 토론하지 않기. 예를 들면 변수명, 함수명, 파일명 같은 어떻게보면 작은 토론 주제일 수도 큰 주제일 수도 있지만 우리 팀에게는 작은 문제로 여겨졌다. 이유는 현재 프로젝트는 우리 팀끼리만 진행을 하고 있기 때문에 우리끼리 잘 알아보면 문제가 없다는 이유였다. 상식을 벗어나지 않는 선에서 빠르게 결정하여 프로젝트를 진행하였고, 덕분에 빠르게 진행되었다고 생각한다.

• 모두 같은 목표 ‘컴포트 존을 벗어나자’. 이번 프로젝트 목표는 컴포트 존을 벗어나 새로운 기술을 사용해보며 이 기술이 왜 쓰이는지 몸소 느껴보자였다. 하지만 이 부분은 누군가에게는 좋지 않은 방향일 수 있다. ‘지금 해 보는 것도 잘 못하는데 또 다른 시도를 해보자고?’ 라고 생각 할 수 있기 마련이다. 이 부분은 나도 동의한다. 나도 지금까지 사용해봤던 기술을 잘 사용한다고 말 할 수는 없다. 하지만 이 시기가 아니면 이것 저것 시도해보기 어려울 수 있다고 생각했고, 기존 기술을 바탕으로 새로운 기술을 시도하면서 학습을 한다면 자연스레 기존 기술의 실력도 함께 오를 것이라 생각했다. 다행이 이 부분을 팀원 모두 동의 해주었거, 덕분에 새로운 기술이 왜 사용되는지 어느정도 몸소 느끼게 되었다.

🫧 현세인

• 팀원들과 초반에 각자의 목표를 공유하고 자유롭게 의견을 나누며 동일한 목표를 설정할 수 있어서 좋았습니다.

• 각자 맡고싶은 역할이 있으면 해당 역할을 맡고, 중복되는 경우 사다리타기를 통해 역할을 정했습니다. 또한 의견이 많은 경우 다수결을 통해 빠르게 의사 결정을 할 수 있었습니다.

• 의견이 일치하지 않을 때는 각자의 의견을 명확하게 제시하기 위해 시간을 가졌습니다. 각자 코드를 구현하거나 의견을 정리해 공유했으며 가장 좋은 방식을 선택하기 위해 노력했습니다.

• 타입스크립트에 대한 여러 도전을 할 수 있었습니다. 코드 리뷰를 하며 관심있게 봤던 부분은 타입스크립트입니다. 라이브 리뷰를 통해 단순히 옵셔널로 지정했던 타입도 오버로딩 사용하여 더 효과적으로 구현할 수 있었습니다. 또한 멘토님의 조언을 듣고Object.entries와 같이 타입스크립트의 추론이 엉망이 되는 경우를 직접 함수를 구현하며 해결할 수 있었으며, HTTP 상태 코드를 number 타입으로 지정하는 것이 아니라 더 엄격하게 타입을 명시하는 방법에 대해 고민할 수 있었습니다.

Problem: 불편하게 느끼는 부분, 개선이 필요하다고 생각되는 부분

🫧 김유경

• 토론을 많이 했는데 기록이 부족한 점
회의 때 토론을 많이 했는데 그것들을 모두 문서화하지 못한 점이 아쉽다.

• 마감임박 때문에 코드리뷰를 많이 하지 못한 점
스프린트 기간을 책정할 때 구현에만 초점을 두고 하다 보니 구현할 시간에 급급해서 코드리뷰를 많이 하지 못했다.

• 의미를 생각하고 하지 않고 코드를 작성한 점
폴더 구조 같은 것도 그냥 익숙한 방식이라서 했지 크게 의미를 생각하고 하지 않았다. 사실 의미를 두고 하지 않았다는 것도 멘토님과의 대화에서 알게 되었다. 그정도로 무의식적으로 짜고 있던 코드들이 많았다는 점이 아쉽고 개선이 필요하다고 느꼈다.

• 새로운 기술에 대해 깊게 파고들지 못한 점
나름 공식 문서도 읽고 블로그도 많이 읽었다고 하지만 근본적인 동작원리나 세세한 기본보다는 해당 상황에 맞는 기술들을 공부하는 데에 급급했던 점이 아쉽다.

🫧 모유경

• 기술을 공부할 때 기본적인 부분만 훑고 지나가는 듯한 인상을 많이 받는데, 시간적인 부분이 한계로 작용하기 때문이라고 생각한다.

• 공부한 내용을 글로 적어 문서화를 위해 노력하지만, 거시적으로 큰 틀만 작성하고 마무리를 해내지 못한 점이 아쉬웠다.

• 타입스크립트에 대한 이해도가 부족했던 점이 아쉬웠다.

• 의식적으로 이유있는 코드를 작성하기 위해서 노력하면서도, 고민하지 않고 습관처럼 코드를 작성하거나 구조를 설계한 부분들이 있는 존재하는 점

🫧 최익

• 처음 사용해보는 기술을 여러개 사용하다 보니 그 기술에 대해 깊게 파고들지 못한 것. 시간적인 한계도 있었지만 맡은 기능을 빠르게 구현해야 일정이 밀리지않고, 팀원들에게 피해를 주지 않기 때문에 이 부분에 대해서는 많이 놓친 것 같다.

• 코드 한 줄 한 줄을 의미있게 작성하지 못한 것. 한 줄 한줄을 의미있게 작성하지 못했다는 것은 코드를 효율적으로 구현하지 못했고, 내 코드를 볼 다른 사람이 주석없이 코드만 보고 바로 이해할 수 있을까?를 생각하면 아닌 것 같다. 이유도 위 내용과 같은 이유인데 오히려 이 부분이 팀원들에게 피해를 끼친 것 같다.

• 처음 feature 단계에서부터 코드를 제대로 작성하지 않은 것. 평소 기능 구현을 마친 뒤에 리팩토링을 진행하는 습관이 있었는데 오히려 이 부분이 독이 되는 것 같다는 느낌을 받았다. 앞으로는 코드 설계 단계에서부터 깊게 고민하여 코드를 효율적으로 짜는 것이 중요하다는 생각이 들었다.

• 공부한 내용, 트러블 슈팅에 대해 기록하지 않은 것. 프로젝트 진행과 동시에 이 부분을 병행하려 했는데 무참히 실패했다. 앞으로의 기간 동안 트러블 슈팅에 대해서 작성할 것이지만, 당시 바로 작성하는 것 과는 생생함이 다를 것 같다. 뭔가 블로그 글을 쓰려면 ‘잘’ 써야 한다는 압박감이 있었는데 동욱님께서 해 주신 조언 덕분에 그런 압박감을 내려놓을 수 있게 되었다. 결론은 일단 써야 그 다음이 있다는 것.

🫧 현세인

• 구현해보지않은 것에만 초점을 두고 역할을 선택하여 메인 기능인 아닌 비교적 간단한 것들을 담당하게 되었다. TanStack Query의 주요 기능인 캐싱, 서버 상태의 메모리 및 가비지 수집 관리, 백그라운드에서 오래된 데이터 업데이트 등 다양한 옵션들을 사용하지 못한 아쉬움이 있다.

• 새로 사용하는 기술 스택을 깊게 공부하지 않고 프로젝트에서 사용을 했다. 초반 목표는 결과물 보다는 이유있는 코드 짜기, 제대로 알고 사용하기였는데, 일정이 촉박하다는 이유로 결국 같은 실수를 반복하게 되었다. 중반쯤 목표와는 다르게 프로젝트를 진행하는 것을 깨닫고 다시 공식문서로 돌아가 기본을 다루었다.

• “길어지는 코드는 가독성이 좋지 않다.”라는 나만의 공식이 있었다. 로그인, 회원가입을 구현할 때 반복되는 코드를 줄이기 위해 상수화를 한 경우가 있었는데, 이 부분이 다른 사람이 볼 때 코드의 흐름이 끊긴다는 것을 알게되었다.

• 추상화를 할 때 라이브러리에서 제공해주는 기본적인 타입 추론 및 기능들을 이해하지않은채 하려했다.

Try: Problem에 대한 해결책

🫧 김유경

• 토론을 많이 했는데 기록이 부족한 점
• 보다 더 꼼꼼한 문서화가 필요하다 생각한다. 토론이라는 페이지를 만들어 그 페이지에 토론했던 것들을 간략하게 문서화하고 그 뒤에 추가적으로 넣고 싶은 내용들을 더 넣는 식으로 보완하면 좋을 거 같다.

• 마감임박때문에 코드리뷰를 많이 하지 못한 점
• 스프린트 기간을 넣을 때 머지데이같은 기간을 넣어서 코드리뷰 기간까지 책정을 해서 스프린트 기간을 설정하는 식으로 해야겠다.

• 의미를 생각하고 하지 않고 코드를 작성한 점
• 한 가지 기능 혹은 설계가 끝나고 나면 의식적으로라도 코드 한 줄 한 줄 짚고 넘어가는 시간을 가져야겠다.
• 특히 많이 놓치고 가는 부분인 설계, 컴포넌트 분리, 응집도, 추상화, 타입 시스템등 무의식적으로 내가 짰던 부분들을 정리해서 commit을 하기 전에 이 부분들을 한번 더 체크하는 시간을 가져야겠다.
• 또한 나 혼자 보면 놓치고 넘어갈 수 있으니 적극적인 코드리뷰도 도움이 될 듯하다.

• 새로운 기술에 대해 깊게 파고들지 못한 점
• 습관적으로 특정 상황에서 사용될만한 기술만 공부하지 말고 시간이 걸리더라도 기초부터 공부하는 습관을 길러야겠다.
• 스프린트 기간으로 바빠지기 전에 기술에 대한 기초 공부를 끝내야겠다. 막상 스프린트 기간이 되면 구현에 급급해져 기본을 공부할 시간이 적어지다 보니 계속 미루게 되는 것 같다. 애초에 이런 것을 방지하기 위해 바빠지기 전에 기초부터 공부해야겠다.

🫧 모유경

기술을 공부할 때 기본적인 부분만 훑고 지나가는 듯한 인상을 많이 받는데, 시간적인 부분이 한계로 작용하기 때문이라고 생각한다.

• 공식문서를 읽는 습관이 덜 들어서 소요하는 시간이 길다고 느껴진다고 생각한다. 반복적으로 읽으면서 습관을 형성하면 중요한 부분을 캐치하고 정리하는 시간이 자연스레 빨라질 것 이라고 생각한다.

• 알게 된 내용을 자세히 글로 적는 방식도 좋지만, 소요되는 시간이 한계로 동반한다고 생각한다. 마무리를 짓되, 대략적으로 글이나 그림으로 정리하다보면 시간을 단축하며 정리할 수 있을 것이라고 기대되어 새롭게 시도해보고자 한다!

공부한 내용을 글로 적어 문서화를 위해 노력하지만, 거시적으로 큰 틀만 작성하고 마무리를 해내지 못한 점이 아쉬웠다.

• 앞선 문제와 동일하게 시간적인 부분이 중요하게 영향을 미쳤다고 생각한다. 글을 끝까지 마무리해서 게시하는 방식으로 강제성을 부여해 나의 생각을 정리하고 학습내용을 공유하는 방식으로 시도해보고자한다.

타입스크립트에 대한 이해도가 부족했던 점이 아쉬웠다.

• 현재 코드를 바탕으로 타입스크립트를 개선할 수 있는 부분을 찾아보고, 어떻게 변형할 수 있는지 리팩토링한다.

• 정직하게 공부하기, 꾸준히 연습을 동반하는 방법밖에 없는 것 같답..

의식적으로 이유있는 코드를 작성하기 위해서 노력하면서도, 고민하지 않고 습관처럼 코드를 작성하거나 구조를 설계한 부분들이 있는 존재하는 점

• 의식적으로 고민해보고 습관이 부족해서 생기는 문제라고 생각한다. 남들이 사용하니까가 아닌, 내가 왜 해당 방식을 사용하는지 설계 및 개발 과정에서 의식적으로 고민하는 습관을 들이기 위해서 노력해야겠다.

• 나의 이유와 의견이 들어간 방식을 고민하고 과정을 기록하는 방식으로 성장을 위해 노력할 계획이다.

🫧 최익

• 의미 있는 코드 한 줄 작성, 기술에 대한 깊은 이해 부족. 이 부분은 다급함에서 오는 것 같다. 구현 일정을 맞추어 팀원에게 피해주기 싫은 것. 하지만 돌이켜 생각해보니 오히려 빠르게 구현하려고 작성한 코드가 더 팀원들에게 피해를 주는 것 같다(이해 부족은 덤). 차라리 초반에 시간이 좀 걸리더라도 더 꼼꼼하게 공식 문서를 읽고, 동작 원리에 대해 이해한 뒤 어떻게 하면 효율적으로 코드를 작성할 수 있을지 고민 한 다음 작성하는게 추후 코드 작성과 리팩토링에 있어서 더 시간을 단축시킬 수 있는 것 같다. 아직 공식 문서를 읽고 이해하는 시간이 굉장히 느리지만, 계속 연습한다면 좋아질 것이라 생각한다. 가장 중요한 건 다급한 마음을 없애기!

• 트러블 슈팅 기록하기. 매번 우리는 프로젝트를 진행하면서 문제를 해결한다. 그런데 정작 무슨 문제를 해결했냐고 물어보면 대답하지 못한다. 이유는 기억하지 못하기 때문. 기억하더라도 자세히 기억하지 못한다. 이 부분에 대한 해결을 위해 문제 해결에 대한 내용을 바로바로 모두 작성하지는 못하더라도 키워드로 작성하고 저장해 놓은 뒤 다시 보며 정리하면 기억하는데 더 도움이 될 것 같다.

• 프로젝트 초반부터 꼼꼼하게 설계하고 코드 작성하기. 최근까지는 일단 기능을 구현하고 리팩토링 하는 방향으로 코드를 작성했었는데 조금 돌아가고 오래걸리더라도 처음부터 깊게 고민하여 설계한 뒤 코드를 작성하는 습관을 가져야겠다고 생각했다. 이 부분을 해결하기 위해서는 머리속에 그려지고 있는 설계를 그림으로 나타내고, 두 수 앞을 내다본 상황마저 모두 정리가 된다면, 그 뒤에 코드를 작성하는 습관을 가지는게 아직까지는 유일한 해결책인 것 같다.

🫧 현세인

• 구현해보지않은 기능에만 초점을 두는 것이 아닌, 사용하는 기술 스택과 관련해서 배울 수 있는 것들 및 사용 목표를 설정하고 역할을 담당해야겠다.

• 처음 사용하는 기술을 초반에 빠르게 개발한다고 좋은 것이 아니다. 처음에는 느리더라도 확실하게 공부를 한 후 구현하는게 훨씬 좋다는 것을 다시 한번 느꼈다.

• 가독성을 생각할 때 무조건 상수화하고, 컴포넌트를 나누어 나만 이해하는 코드가 아닌 우리 프로젝트에 대해 모르는 사람이 보더라도 코드의 흐름이 끊김없이 읽어지는지를 확인해야겠다.

• 추상화를 하는 이유에 대해 제일 먼저 생각해봐야한다. 단순히 반복되는 코드를 줄이는 것만이 추상화의 목적이 아니다. 또한 라이브러리에서 제공해주는 타입 및 기능을 잘 활용하여, 해당 기능들이 어떠한 흐름으로 동작하고 어떤 타입을 갖고있는지 파악한 후에 추상화하는 연습을 해야겠다. 어설픈 추상화를 피해야겠다.

우리 팀에게 한 마디

🫧 김유경

• 막히는 부분이 있으면 모두 본인의 일처럼 도와주고 그로 인해 더욱 빠른 해결이 가능했다고 생각합니다. 서로 도우며 하나의 목표를 향해 나아가는 모습이 정말 이상적인 팀프로젝트였다고 생각합니다.

• 팀원 모두 각자의 의견을 어필하되 다른 사람의 의견이 맞다고 생각이 들거나 의견이 수렴되는 분위기면 본인의 의견을 접을 줄 아는 유연한 사람들이어서 정말 좋았습니다. 그 덕분에 다양한 의견이 오가더라도 트러블 없이 프로젝트가 잘 진행될 수 있었습니다. 의견을 제시할 때 근거를 가지고 제시하여 듣는 이에게 설득력을 높였던 점도 물론 있지만 기본적으로 팀원들 모두 수용적인 태도로 임해주었던 덕분이라고 생각됩니다.

• 서로의 의견을 배려하고 경청하려는 자세를 기본적으로 가지고 있는 분들이라 좋았습니다. 그 덕분에 의견을 좀 더 편하게 낼 수 있었던 거 같아요. 받아들이는 사람이 수용적이지 않으면 의견을 내는 것에 대해 조심스러워지는데 이번 프로젝트에서는 그런 것에 대한 스트레스없이 팀원들 덕분에 편하게 의견을 낼 수 있었던 것 같아요. 기술적으로도 배운 점들이 정말 많지만 서로 도우려는 자세와 의견이 다르더라도 존중하는 태도처럼 기술 외적인 것에서도 팀원들에게 많이 배울 수 있어서 정말 좋았습니다. 팀프로젝트에 들어가기 전에는 걱정이 많았지만 좋은 팀원분들을 만나 많이 배우고 갈 수 있어서 정말 감사합니다! 앞으로도 계속 연락하며 지금처럼 함께 성장하면서 지내고 싶네용ㅎㅎ 2차 팀프로젝트 다들 고생많았습니다👏👏

🫧 모유경

• 팀원 중 한 사람이 겪게 된 문제를 공유 했을 때, 팀원들이 함께 고민해보고 해결하려고 노력하는 모습들을 보면서 저도 많이 배우고 또 감사하다는 생각이 들었어요.

• 공부한 내용을 서로 공유해주고 토론하는 과정이 너무 좋았고 함께 성장이라는 표현이 참 잘어울리는 팀이라는 생각이 들었습니다.

• 함께 논의해보아야하는 주제가 나온 경우에, 팀원들이 의견을 발언하면 해당 의견을 수렴하는 경우가 많았다고 생각해요. ’이게 어떻게 유연하게 가능했을까?’를 고민해보았을 때, 의견을 듣는 사람은 팀원의 의견을 귀기울여듣고 신뢰하는 자세가 갖춰져있고, 더불어 의견을 제시하는 사람을 설득력있는 이유를 함께 제시했기때문에 가능했던 것이 아닌가 하는 생각이 듭니다. 팀원분들과 프로젝트를 진행 하면서 의견을 제시하고 또 잘 수렴하는 연습을 할 수 있게 된 것 같아서 너무 감사합니다. 자주 만나 어떻게 성장하고 있는지 좋은 소식 공유하면서 계속적으로 함께 성장하고 싶어요. 부족한 점도 많은데 늘 배려해주시고 존중해주시는 팀원들 덕분에 즐겁게 개발할 수 있었던 것 같아요. 운이 좋네요ㅎㅎ 너무 감사합니다.

🫧 최익

• 다른 사람이 겪는 어려움을 본인이 겪는 일처럼 여기고 함께 해결해주는 모습에 너무 감사했습니다. 결국 팀 프로젝트는 나 하나 잘한다고 되는게 아니라는 걸 더욱 느끼게 되었구요. 그 과정에서 나도 몰랐던 내용들을 알게 되었고, 이런 팀 문화속에서 더욱 빠르게 함께 성장할 수 있었던 것 같습니다.

• 우리 팀원 모두 본인의 이득보다는 팀 전체에 대한 이득에 대해 먼저 생각하고, 배려하고, 양보하는 모습에 너무 감사했습니다. 덕분에 프로젝트를 진행하면서 모두 트러블 없이 유연하게 진행이 된 것 같아요.

• 결국 개발도 사람이 하는 것이고 실력도 중요하지만 이번 팀 프로젝트를 통해 의사소통이 가장 중요하다는 것을 너무나 크게 느꼈습니다. 부족한 부분은 노력과 학습을 통해 따라가면 되는 것이지만, 의사소통은 본인만의 기준이 있어 트러블이 있을 수 밖에 없는 부분인데, 팀원 모두 이런 부분을 내려놓고 타인의 의견을 수렴하려는 자세로 임해주어 이 부분에 대해 정말 많이 배웠습니다. 우리 팀원 이대로 끝이 아닌 프론트엔드 개발자라는 같은 목표로 계속 함께 소통하고 공유하며 성장하여 모두 성공하면 좋겠습니다 ㅎㅎ 앞으로도 계속 연락하며 끌어주고 밀어주며 지냅시다!! 👍🏻👍🏻👍🏻 2차 팀 기간동안 고생 많았어요🙇‍♂️

🫧 현세인

• 항상 꼼꼼하게 코드 리뷰 해주고, 생각하지 못했던 부분을 덕분에 생각해볼 수 있게 되었고, 묵묵히 자신이 맡은 부분을 빠르게 구현해오고, 항상 침착하게 기술 관련 내용을 공유해준 (김)유경님! 💚

• 4P들 사이에서 꼼꼼하게 일정 관리를 해주고, 늘어지는 회의를 할 경우 결단력있게 진행해주고, 개발 과정 중 어려움이 있을 때마다 열심히 해결해주려했던 (모)유경님! 🩷

• 우리 팀의 분위기를 편안하게 만들어주어 자유로운 분위기 속 프로젝트를 진행할 수 있게 만들어주고, 개발 관련 좋은 내용들을 팀원들에게 항상 전달해주며 도움을 주었던 익님! 🧡 

• 동일한 목표를 설정하고 팀프로젝트를 즐겁게 마무리할 수 있어서 정말 좋았습니다! 책임감있게 각자 맡은 일들을 일정 기한에 맞춰 잘 진행하고, 함께 정한 컨벤션을 잘 지키고, 코어타임 시간 외에도 열정적으로 임하는 우리 팀원들이 있어서 저도 더 열심히 할 수 있었습니다!
함께 의견을 나누며 성장할 수 있어서 좋았고, 3차 팀에 가서도 각자의 장점을 발휘하여 좋은 결과 맺는 모두가 되길 바랍니당..!! 다들 고생하셨습니다~! 동욱팀 뽀에버💓