내일배움캠프 CH3 KPT회고

● Keep

- 활발하고 적극적인 소통

이전에는 필요할 때만 말하고 그 외에는 조용히 과제나 강의만 듣고 있는 팀에만 있었다. 그래서 따분하고 지루한 공부를 계속 하고 있었다. 하지만 이번에 같은 팀이된 사람들은 적극적으로 말을 걸고 활발하게 움직이는 모습을 보여줬다. 이 모습은 처음엔 갑자기 시끄러운 분위기가 되어 뭔가 어수선하다는 생각이 들었지만 오히려 적극적으로 대화를 함으로써 서로 어느 정도의 실력을 갖추었는지, 그리고 그 날 강의나 과제에 힘들었던 점을 쉽게 공유하여 도움을 받는 데에 부담을 적게 가지게 되는 등 긍정적인 결과를 가져왔다고 생각한다.

- 재미있는 분위기와 컨셉

팀원의 누군가가 제안한 이름이다. 나는 조 이름을 명명하는 것에 아무런 생각이 없었는데 뭔가 마음에 꽂히는 이 재미있는 이름은 앞으로의 활동에 기대를 가져다 주었다.

왕과 후궁이라는 컨셉

처음에는 캐릭터 컨셉을 만드는 것에 다소 부담을 느꼈지만 팀원 모두가 적극적으로 프로젝트에 임하는 모습을 보여줘서 다른 생각을 가지게 되었고 나중에는 열정적인 분위기 덕분에 이러한 요소는 그저 하나의 재미로 받아들이게 됐다. 아무런 컨셉을 가지지 않고 그냥 묵묵히 과제에 집중하기만 했다면 재미가 없었을 것이고 흥미가 떨어졌을지도 모른다.

 

- 유경험자의 이끌어가기

활발한 소통의 연장선으로, 팀 프로젝트 과제를 하는데 언리얼 엔진에 미숙하여 구현을 제대로 할 수 없거나 C++ 작성을 헷갈려하는 팀원이 있었는데 이렇게 어려움을 겪는 팀원을 다른 팀원이 적극적으로 지도하여 팀 프로젝트를 무사히 마무리 할 수 있었다. 적극적으로 지도한 팀원이 언리얼 엔진을 어느정도 경험을 했기 때문에 충분히 이끌어갈 수 있었다. 나 또한 C++은 잘 알지만 언리얼엔진은 기초적인 부분만 알고 있는지라 적지 않은 도움을 받았다. 그 결과, 팀 프로젝트는 무사히 마무리할 수 있었다.

내가 들은 바에 따르면 다른 팀 중에서는 제대로 마무리를 짓지 못하고 초반부만 완성하여 제출한 팀도 있다고 하던데 내가 있던 팀은 어떻게든 완성을 했다는 점에서 나은 상황이라 할 수 있다.

 

- 유비무환

팀 프로젝트 최종 발표를 앞두고 리허설을 하기로 했다. 진짜 발표를 하는 것 처럼 각자 말을 이어갔고 서로 문제점이라고 생각되는 부분을 짚어주면서 고쳐나갔다. 그리고 발표 환경은 Zoom에서 하기 때문에 팀원끼리 직접 Zoom 회의방을 하나 만들어서 테스트 해보고 어떻게 해야 문제없이 화면 공유 및 소리 출력을 하는 지도 확인했다. 그래서 우리 팀이 발표를 할 때는 막힘없이 술술 잘 풀렸고 문제없이 잘 해냈다.

같이 했던 다른 팀은 소리나 화면 공유에 문제가 발생하거나 실수를 하는 경우가 생각보다 자주 발생했는데 우리 팀은 적어도 발표를 하는 데에는 문제가 하나도 없었다.

 

● Problem

- 의견 차이에서 발생한 갈등

깊이 우선 탐색, 너비 우선 탐색, 동적 계획법 등 컴퓨터 과학에서 알고리즘은 절대로 빠질 수가 없다. 나는 프로그래머라면 당연히 가져야 하는 지식이라고 생각한다. 이전에 근무했던 회사에서 프로그램을 만든 경험을 돌이켜보면 알고리즘을 알고 있었다면 보다 더 효율적이고 빠른 프로그램을 만들지 않았을까 하는 생각을 하기도 한다. 그래서 지금도 알고리즘 공부를 하고 있다.

어느날, 팀원과 하루를 마무리를 할 때 무엇을 했는지 공유하는 시간을 가졌는데 여기서 알고리즘에 대한 의간 차이가 발생했다. 상술했듯 나는 알고리즘은 프로그래머로서 필수 사항이라고 보지만 그렇지 않는 팀원이 있었다. 요즘 게임을 만드는 데에는 그러한 알고리즘이 쓰일 일이 전혀 없다는 의견이었다. 오로지 입사를 위한 코딩 테스트에만 쓰일 뿐이라고 했다.

물론 서로 코딩 테스트에서 요구하는 알고리즘 지식이 코딩 대회 수준으로 너무 어렵다는 것에는 공통된 의견이었다. 하지만 그것이 실무에 쓰이느냐 아니냐에 대해선 끝없는 언쟁이 오갔다. 지금 돌이켜보면 서로 겪었던 경험이 달라서 다른 생각을 가지게 된 것이지만 그에 대한 존중이 전혀 없었다. 이날 언쟁은 다른 누군가가 중재를 해서 겨우 마무리했지만 좋은 상황은 아니었다.

 

- 일단 Git 저장소에 올리고 수습하기

Git 저장소에 커밋된 내용에 오류가 발생하는 경우가 종종 있었다. 여러번 또는 길게 테스트 해야 알 수 있는 부분은 어쩔 수 없지만 1번만 실행해도 바로 나오는 오류가 있는 것이 문제다. 발견된 오류마다 알려줘서 곧바로 수정이 되긴 했지만 시간 낭비임은 부정할 수 없다.

그런데 이게 다른 팀원 뿐만이 아니라 나 또한 시간 부족을 이유로 급하게 진행하다가 저질러버리는 문제이기도 하다. 올바르게 짠 코드라고 생각하여 커밋했지만 다시 해보니 오류가 발생해서 다시 고치는 행동은 올바른 행동이 아니지만 급한 나머지 나도 결국 저지르는 문제이기도 하다.

이것과 함께 Git에 익숙하지 않아서 생기는 문제도 있는데 아직 테스트 중이라서 커밋하면 안되는 파일이 저장소에 올라간 경우도 있었고 병합이나 내려받는 도중에 파일이 꼬여서 본의 아니게 파일이 삭제되는 경우도 있었다. 그나마 이 부분은 몇 번 겪도 난 다음에는 이상하다 싶으면 곧바로 다른 팀원에게 물어봐서 확인을 했기에 다시는 발생하지 않았다.

● Try

- 일단 상대방의 생각에 존중하는 자세를 취하자

내가 겪은 언쟁도 먼저 말을 꺼내기 전에 존중하는 자세를 취하고 적당히 수용하면서 그만두면 빨리 끝날 일이지만 이해가 안된다면서 계속 말을 이어간 것이 문제다. 다음부터는 대화를 할 때는 일단 상대방의 시선을 이해해보려고 노력하면 좋을 것 같다. 그리고 급하게 말을 꺼내기 보다는 차분하고 천천히 대화하는 것이 어떨까 생각한다.

- 시간이 걸리더라도 검증은 확살하게

저장소에 커밋을 하기 전에 최소 1번씩이라도 실행을 하여 검증을 했다면 다시 수정을 할 일이 최소한 절반이라도 없어졌을 것이다. 검증이 부족한 내용을 커밋하여 다시 수정하는 것보다 스스로 테스트를 하여 문제를 잡아내는 것이 시간이 덜 걸리는 일이다.

 

- 모르는 것은 물어보자

문제를 여러번 겪어 스스로 깨달았지만 그래도 다시 적자면 무언가 이상하거나 해결이 안되겠다 싶으면 우선 물어봐서 확인을 하거나 도움을 요청하는 것이 좋다. 또한 Git에서 여러 사람이 공유하는 브랜치에 병합을 한다면 사소한 파일 1개일지라도 다른 사람이 병합하고 있는지 확인을 하고 진행하는 것이 좋다.