원티드에서 주관한 FE 프리온보딩 인턴십 4월 과정에 한 달간 참여했고, 수료를 코 앞에 두고 있다. 어떤 경험이었는지 기록해 두었다가 나중에 다시 읽어보면 재미있겠단 생각에 생에 첫 팀 단위 프로젝트의 회고를 작성한다.

첫날부터 도망치고 싶었다..!

동료학습의 어려움

프리온보딩 과정은 100명의 참가자가 10명씩 10개 팀을 이루어 팀 프로젝트가 아닌 동료학습 하는 식으로 진행되었다. 이 동료학습이 참 흥미로운데, 10명의 팀원이 각자의 방식으로 프로젝트를 처음부터 끝까지 완수해 보는 것에서부터 시작한다. 이후 하나의 Best Practice 도출을 위해 코드를 어떤식으로 작성하는 게 더 좋을지 팀원들과 논의하고 리팩토링한다. 즉, 동료학습은 10개의 코드베이스를 하나의 Best Practice로 잘 버무려 빚어내야 하는 고난도의 challenge였다.

지금까지 내게있어 팀 프로젝트라 함은 기능단위 개발이었다. 팀원1은 A 기능을 만들고.. 팀원2는 B를 만들어서 PR, 코드리뷰 후 하나의 브랜치에 병합하며 작업한다. 이러한 팀 프로젝트에서는 비교적 내 역할에만 충실해도 별문제가 없었다. 그런데 동료학습이라는 이 낯선 작업 방식은 익숙해지기 전까지 여러 가지 형태로 시련을 안겨주었다. 이제 막 대면해서 서로가 낯선 10명의 생각을 단일화하는 건 여간 쉬운일이 아니었다. 특히 첫날에는 '아.. 이거 계속 하는 게 맞나?'라는 고민을 진지하게 거듭했던 것 같다.

얕게 아는 건 중요한 순간에 아무런 도움이 되지 않았다

10명의 팀원이 Discord 음성채팅에 모여서 어색하게 자기소개를 마치고 어떤 식으로 동료학습을 진행 하는 게 좋을지 머리를 맞대 보았지만 뾰족한 방법이 나오질 않았던 것으로 기억한다. 대부분이 신입이거나 경력이 짧은 주니어 개발자들이기 때문에 그럴 수 밖에 없었다고 생각한다. 그때 내가 5명씩 팀을 쪼개자는 제안을 냈다. 10명은 소통하기에 비효율적으로 많은 인원이라고 생각했다. 독서모임이나 술자리도 경험상 4~5명일 때가 재밌다. 5명씩 팀을 나누면 소통이 좀 더 활발해질 것 같았다. 그래서 A,B팀이 두 개의 Best Practice를 도출해낸 뒤, 최종적으로 10명이 이 두개를 다시 합치면 될 것 같았다. divide and conquer 느낌으로다가. 다행이도 다른분들이 동조를 해 주셨고 순조롭게 출발하는 듯 싶었다.

팀을 쪼개긴 쪼갰는데 어떻게 Best Practice를 도출하지? 똑같은 문제에 봉착했다. 일단 우리팀은 각자의 사전 과제 코드를 팀원들에게 소개하면서 리뷰하는식으로 진행해 보았다. '이 부분 잘 만드셨네요'와 같은 대화가 오고갔다. 팀원들의 코드에서 장점을 찾아보는 과정이 생각보다 재밌었다. 내 코드엔 어떻게 적용할 수 있을지 고민해보면서. 그러다가 한 팀원의 코드에 내가 딴지를 걸었다. '이 부분 이렇게 작업하셨는데 ~~한 이유로 XX하게 하는 게 좋지 않을까요?' 그 분도 고민끝에 충분히 합리적인 이유로 그렇게 코드를 작성하신 모양이었다. 그래서 의견이 잘 좁혀지지 않았다. 이 당시 경험이 기억에 좀 선명하다.

내가 제안한 방식이 좀 더 타당하다고는 느꼈는데 충분한 근거를 제시하지는 못했다. 그렇게 소모적인 대화가 잠깐 오고갔던 것 같다. 내 생각을 명료히 정리해서 표현하지 못함에 상당한 답답함을 느꼈다. 정리는 커녕 머릿속이 복잡해져서 내가 무슨말을 하고있는지도 잘 모른채 아무말이나 했던 것 같다. 그리고 깨달았다. 얕게 아는 건 중요한 순간에 아무런 도움이 되지 않는다고. 얕은 지식으로는 면접관은 커녕 팀원도 설득하기가 어려웠다. 깊게 파고들어본 경험이 왜 강조되는지를 다시 한 번 생각해보는 계기였다.

지금와서는, 그리고 당시에도 어렴풋이 느꼈는데, 51:49의 문제였다고 생각한다. 그러니까 어떤 방식을 택하든 별다른 지장이 없는, 단순한 방식의 차이 정도였다고 생각한다. 그런데 나는 조금이라도 더 좋은 방식이 있다면 그걸 찾아서 적용해야 하는거 아닌가? 라는 생각에만 매몰되어있었던 것 같다. 정작 그것보다 팀으로 작업하는데 있어 훨씬 중요한 건 합심하는 것이었는데.

흑역사 1

좋은 코드를 위한 궁리보다 합심하는게 우선이었다

코드리뷰가 끝난 뒤에도 Best Practice를 도출하는 데는 어려움을 겪었다. 누가 어떤 기능을 좋은 코드로 작성했는지는 알게 되었는데, 그것들을 합치는 건 또 다른 문제였다. 당시의 막막했던 감정이 아직도 선명하다. 내가 속한 5명의 팀은 어떤 식으로 작업해야 좋을지를 계속해서 고민만 하다가 어느 정도 진척이 된 다른 팀에 합쳐져서 작업을 도우는 방식으로 진행되었다. 이때 10명이 하나의 vscode에서 live share를 이용해 코드를 마구잡이로 수정하는 방식으로 작업헀는데, 회의감이 물밀듯 들어온 시점이다..

우리 팀 5명이 생각한 Best Practice의 방향과는 상당히 다른 방식의 코드베이스였고, 무엇보다 여러 명이 동시 작업 중이다 보니 작업물을 브라우저에 띄워서 확인해 볼 수가 없었다. 이런 식으로 해서 좋은 코드를 작성할 수 있을까? 나는 직전에 한 명 조차도 설득하질 못했고, 더 나은 방안이 떠오르지도 않았기에 체념하고 묵묵히 작업했던 것 같다. 일단 끝내고 보자...

그래도 무식해 보이는 위 방식이 아무런 변화를 낳지 않은 건 아니었다. 비슷한 처지의 주니어들끼리 몇 시간이고 머리를 맞대어 궁리해봤자 얼마나 좋은 코드를 작성할 수 있을까? 그래봤자 시니어의 관점에선 허점투성이인 코드가 아닐까? 중요한 건 최선이라고 생각하는 방향으로 마음을 한데 모으는 것이었다. 좋은 방법을 궁리만 하다가는 아무것도 진척되지 않았다. 우리가 Best practice 선정에 어려움을 겪고 방황했던 건 이때문이었다고 생각한다. 완벽한 방법이 아니더라도 합심만 하면 프로젝트는 어떻게든 굴러가더라. 일단 방향을 잡고 쭉 밀어붙이니 어떤 식으로든 결과물이 나왔고, 마음에 평온이 찾아왔다. 코드가 맘에 들지는 않았지만 좀 더 나은 코드로 개선하는 것은 이다음 스텝이었다.

우리 팀이 합심하는 데 있어 혁혁한 공을 세운 몇몇 팀원들이 있다. 힘든 상황에서도 좋은 분위기를 유지하고자 노력했던 작은 행동들, 나는 그런식으로는 팀에 잘 기여하질 못했던 것 같아서 정말 감사하다. 내 도망 욕구를 억누르고 한 번 잘 해보자는 마음가짐을 가질 수 있었던 것도 그분들 덕분이니 나로서는 특히 더 감사하다.

협력에 있어 커뮤니케이션, 특히 좋은 분위기를 유지하는 것이 얼마나 중요한지를 느꼈다. 나는 '분위기를 해치지만 말자'는 타입이었는데 조금씩 나서야 할 필요성을 느꼈다.

이후로는.. 원만하게 진행되었습니다!

지금까지는 첫 주차 동료학습 과제에서 절반 분량의 Best Practice를 도출하기 까지의 과정이었다. 나머지 절반의 Best Practice를 도출해보기 이전에 각자가 코드를 리팩토링 할 수 있는 기간이 있었는데 이 때는 다른 팀원들도 납득할 수 있을 만큼 괜찮은 코드를 짜기 위해 많은 노력을 기울였다. 뿌듯하게도, 첫 주차의 꽤 많은 Best Practice가 내 코드에서 차용될 수 있었다.

첫째날의 고난을 경험한 뒤로 팀의 분위기도 많이 밝아졌고 팀원들의 의견이 제법 잘 모여졌다. 회고를 통해 각자의 피드백을 반영했고, 다음 주차 과제부터는 훨씬 더 효율적인 동료학습을 할 수 있었다. divide and conquer 전략은 생각보다 무효했다. 대신 10명의 코드리뷰 후 베이스가 될 프로젝트를 하나 선정하여 Best Practice라 생각되는 방향으로 해당 프로젝트를 리팩토링 하는 방식으로 작업했다. 리팩토링이 필요한 feature 단위로 몇몇 구성원이 달라붙어 페어 프로그래밍 -> PR -> Merge했다. 이 때 2~3명 단위의 live share 작업방식은 꽤 유용했다.

도망치지 않음으로써 얻은 것들

8 + 9

과제가 주어지면 (거의) 식음을 전폐하고 (사실상) 자는 시간 빼고는 과제에 매진했다. 과장좀 보태면 그렇다. 코드를 작성하고나면 항상 무어라 콕 집어내긴 어려운 부족함, 아쉬움이 맴돌았는데 이것들을 극복해보고자 시간을 쏟았다. (과제 수행 기간이 3일 정도로 짧았기에 가능했다.) 조금만 더 고민해보면 레벨업 할 수 있을것 같은 느낌을 받았다. 그리고 지금은 조금 더 나은 코드를 작성할 수 있게 된 것 같아 만족하고 있다. 여기에는 다른 사람들의 코드를 참고한 게 많은 도움이 되었다.

단언컨대 내 코드만 충분히 오랜 시간 더 살펴봤다고 해서 이만한 효과는 못 봤을 것이다. 내게는 8명 팀원의 코드가 있었다. 그리고 다른 9팀의 Best Practice가 있었다. 우리 팀원의 코드 작성법은 내게 계속해서 자잘한 자극을 주었던 것 같다. 이렇게 색다른 방식으로도 코드를 짤 수 있구나! 이러한 자극에 노출되다 보면 다른 팀의 결과물도 궁금해진다. 다른 팀의 코드는 나와는 아무런 생각이 공유되지 않은 날것이여서 그 의도를 추측해보며 코드를 살펴봤던 게 많은 도움이 되었다. 특히 9팀의 코드는 정말 유익했다.

Mr. fundamental

과제와 별도로 진행되었던 멘토님의 강의도 굉장히 유익했다. 다 한 번쯤은 접해본, 뻔한 내용 같았던 커리큘럼이 내 부족함을 콕 집어준 훌륭한 교보재로 기능했다. 덕분에 앞으로의 공부 방향성을 정립할 수 있었다.

전 회사에서 대대적인 리팩토링을 진행할 때 A 코드의 수정 여파가 B에도 영향을 끼치는 사이드이펙트에 치를 떨고는 테스트코드 작성을 공부해야겠다고 생각했었다. 충분한 테스트 커버리지 달성은 자신감 있는 리팩토링 감행으로 이어진다는 내용의 영상을 보고선. 그런데 멘토님의 강의를 들어보니 사이드이펙트에 시달렸던 건 내 코드에 관심사의 분리(SoC)에 대한 고민이 부족했던 까닭임을 알 수 있었다.

테스트코드도 중요하지만 OOP 기본기 먼저! 응집도/결합도, 의존성, 책임분리 등의 개념을 내 코드에 어떻게하면 접목시킬 수 있을지 고민해보면서 시야가 조금씩 넓어짐을 느낄 수 있었다.

나는 출중한 기본기 덕분에 Mr.Fundamental이라는 별명을 가진 농구선수를 좋아했었다!

나는 어떤 팀원이었을까?

Keep

'내 할 일'은 그럭저럭 잘 수행했다. 기간 내에 프로젝트를 1차적으로 완성해 오는 부분이라든가.
팀원들의 코드에서 장점을 찾고, 자신감을 복돋아 주고자 노력했다. (소심하게)

Problem

4주차 과제 레포를 Private으로 생성한 바람에 멘토님의 과제 피드백을 듣지 못했다. 다른 불이익이 없길 바랄 뿐이다..
팀원들이 자유롭게 질문하거나 의견을 표출할 수 있는 환경을 조성하는 데 부족함이 있었던 것 같다.
팀원들이 각자의 고충으로 힘들어할 때 아무런 위로를 못 해주었다. 이런 상황을 뒤늦게 눈치챘고 알아챈 뒤로도 별다른 도움은 못 주었던 것 같다.

한 개발자의 회고에서 발견한 내용. '존중받고 있다고 느끼게 해주는 팀'이 중요하다는 내용이 정말 공감갔다.

2020년 10월 회고

Try

깊게 공부하자.
'아는 선에서 도움 드릴 수 있다'는 의사표현을 해보자.
유쾌한 분위기 조성에 힘써보자
타인의 기분을 해치지 않는 선에서 내 생각을 또렷하게 표현하고 싶다. 설득까지도 가능하다면 다할나위 없겠다.

팀원들의 코멘트

자랑 및 추억회상 겸, 팀원들의 회고에 적힌 나에 대한 코멘트를 가져와 봤다.