우아한테크코스 7기 레벨 1 회고

회고란?

회고란 과거를 돌아보고 그 경험에서 배운 점을 정리하는 것을 말한다.

회고는 개인의 성장과 조직의 발전을 위해 중요한 활동이다.

 

우아한테크코스 7기 레벨 1을 돌아보며 회고록을 작성해보고자 한다. 

 

 

토론

 우아한테크코스에 오기 전에는 혼자 공부하고 의사결정을 내렸기 때문에, 토론 기회가 없었다. 고립되어 있다 보니 올바르게 성장하고 있는지 알 수 없었고, 시간 가성비가 좋지 않았다. 누군가와 함께 소통하며 공부하고 싶다는 갈증이 컸다.

 레벨 1 데일리 크루들과 말을 트게 되면서 이 갈증을 마음껏 해소했다. 적극적으로 토론하며 많은 것들을 배웠다.

 

1. 모든 논리를 증명하고 팩트만 비교하는 과정에서 자바를 깊게 파볼 수 있었다. 두루뭉실하게 알고 있던 개념을 끝까지 파고 들어가는 시간을 가졌다.

2. 감으로 하던 객체지향 설계를 설명하려 노력하는 과정에서 모두가 이해할 수 있는 단어(SRP 등)의 중요성을 깨달았다. 책이나 인터넷을 통해 공부하지 않었던 터라, 대부분의 용어가 낯설었다. 이 문제를 해결하기 위해 캠퍼스에서 생활하면서 들리는 모든 말에 집중했다. 모르는 단어가 나오면 따로 메모해 놓고 이틀 안에 공부해서 내 것으로 만들기 위해 노력했다.

3. 내 의견만 밀어붙이지 않는 사람이 되었다. 초반에는 내 의견과 하나라도 맞지 않으면 이해가 될 때까지 계속해서 반박했다. 고집을 부리는 나쁜 성격이 표출된 것이다. 토론을 하며 점차 이런 태도가 잘못되었음을 깨달았다. 객체지향은 절대적인 답이 없다는 것을 알고 있음에도 나는 내 의견을 답으로 생각하고 있었다. 이를 깨달은 이후부터는 반박보다는 생각의 흐름을 물어보기 시작했다.
훨씬 원활한 토론이 되었고, 다른 사람의 의견을 받아들이며 새로운 지식도 얻을 수 있었다.

 

 

 

 

페어프로그래밍

 페어프로그래밍을 처음 접했을 때, 이런 생각이 들었다.

"프로젝트도 아니고 미션을 어떻게 같이 개발하라는 거지..?"

 

 기능 별 역할을 나누어 구현하는 것이 아니라, 같이 구현하는 경험은 처음이었다. 토론을 통해 모든 의사결정을 내려야 했다. 특정 설계를 적용한 이유를 설명해야 했고, 페어의 코드 의도를 파악해야 했다.

 두 번째 페어프로그래밍까지는 토론을 통해 의사결정을 해 나갔다.

 그러던 중, 내 의견이 대부분 채택되고 있다는 것을 깨달았다. 당시에는 참 편했다. 내 의견대로 무언가가 흘러가는 상황은 나에게 편안함을 주기 때문이다.

 

 두 번째 페어프로그래밍이 끝난 후, 지금까지 페어프로그래밍을 통해 배운 것이 없다는 생각이 들었다. 습득한 지식이 없었고, 새롭게 적용해 본 설계도 없었다. "이건 토론을 통한 결과야" 라는 변명을 대며 지금까지 하던 대로 편한 길만 걷고 있었다.

 

 이 문제를 고치기 위해 세 번째 페어프로그래밍부터는 페어의 의견을 무조건적으로 수용하기 시작했다. 페어의 의도가 완전히 잘못된 것만 아니면 마음에 들지 않더라도 전부 수용하는 것을 목표로 임했다.

 장점과 단점이 뚜렷했다.

장점: 좋던 나쁘던, 새로운 설계와 시각을 배울 수 있다.

단점: 페어의 의사결정에 종속된다. (추후 다른 설계를 반영하기 위한 리팩터링 비용이 매우 크다)

 

 마지막 미션에서 단점을 뼈저리게 느꼈다. 페어의 설계를 따라가는 과정에서, 상속을 사용하게 되었다. 평소 상속을 좋아하지 않던 터라, 나중에 리팩터링할 생각으로 따라갔다.

 상속에서 전략 패턴으로 구조 변경을 하는 데에 3일이 걸렸다. 무조건적으로 페어의 의견을 따라가는 것이 좋지 않다는 것을 깨달을 수 있었다.

 

 페어프로그래밍을 통해 의사결정을 할 때, "적당히" 의견을 조율하는 것이 중요하다는 것을 배웠다. 내 의견만을 밀어붙이면 배울 수 있는 것이 줄어들고, 페어의 의견만을 따르면 종속성이 생긴다.

 

 

 

 

스터디

 자바를 깊게 학습하기 위해 이펙티브 자바 스터디를 만들었다. 지금까지 책을 보며 공부한 적이 없던 터라, 언젠간 읽고 싶다는 마음이 있었다. 마음이 잘 맞는 크루 두 명과 두 달가량 책을 읽었다. 단순히 읽고 넘어가지 않고 각 아이템마다 토론거리를 준비해 의견을 주고받았다.

 정말 엉뚱한 곳에 꽂혀 집중하기도 했고, 자바 코드를 깊게 까 보기도 했다. 스터디 조원들이 성장하는 모습을 보며 자극받을 수 있었고, 이를 토대로 성장할 수 있었다.

 

어떤 성장을 이루었나?

1. 개념이나 장단점이 잘 와닿지 않을 때 테스트 코드를 작성하는 습관이 생겼다. 가정을 곧바로 증명할 수 있어 좋은 습관인 것 같다.

2. 예시를 만드는 능력이 발달했다. 책에서는 개념을 두루뭉실하게 설명한다. 개념이 잘 와닿지 않을 때, 적절한 예시 코드 작성을 통해 효과적인 학습을 할 수 있게 되었다.

3. 자바 바이트 코드와 조금? 친해졌다. 내부 동작이 궁금하면 자바 바이트 코드를 까 보며 학습하게 되었다. 제네릭을 학습할 때 매우 유용했다.

4. 개념을 끝까지 파고 들어가는 법을 익혔다. 관심 있는 개념의 내부 코드와 바이트 코드를 적극적으로 찾아 나서는 태도를 가지게 되었다. HashMap을 끝까지 파 보았다.

 

 

 

 

유연성 강화 스터디

 지금까지 스스로의 개발 실력에 만족하지 못했기 때문에, 공부를 하지 않으면 불안했었다. 사실 절대적으로 개발 실력이 부족한 편은 아니었다. 학과 내에서 잘하는 편이었고 지식 공유도 하고 있었기 때문이다.

 그러나, 비교 대상은 언제나 나 자신이었다. 이와 더불어, 완벽주의적 성격은 불안함을 더욱 증폭시켰다. 스스로를 몰아붙이며 번아웃도 경험했고, 포기해야겠다는 생각도 했다.

 

 유연성 강화 스터디를 통해 쉬는 것에서 느끼는 불안감을 해결하고자 마음먹었다. 4주간의 활동을 하며 쉬기 위한 마음가짐을 가질 수 있었고, 나만의 쉼을 찾을 수 있었다.

 

 그중에서도, 개발을 뺀 나에 대해 생각했던 경험이 가장 의미 있었다.

 

 나만의 쉼을 찾는 과정에서 개발을 하지 않아야만 쉬는 것인지에 대한 의문이 들었다.

"쉬는 중에도 계속 개발 생각이 난다면 개발이 없는 나는 무엇인가?"에 대해 깊게 고민했다.

 

 사람들은 경치 좋은 곳에 놀러 가거나 친구를 만나며 삶을 즐긴다. 그런 모습이 부러우면서, 거리감이 느껴졌다. 개발이 없는 나는 어떤 모습일까? 개발이 없다면 어떻게 시간을 보내야 할까?

 

 이 고민을 하며 삶이 무미건조하다는 생각, 내가 보통의 사람들과 다르다는 생각이 들었다. 깊은 슬픔과 외로움을 느꼈던 시간이었다. 그러나, 워니와의 대화를 통해 새로운 시각을 갖게 되었다. 워니는 “왜 쉴 때도 개발을 하는 것이 나쁘다고 생각하나요?”라고 물었다.

 

 순간 대답을 하지 못했고, 그 질문이 계속 머릿속을 맴돌았다. 집으로 돌아와 곰곰이 생각해 보니, 개발을 하는 것이 반드시 나쁜 것은 아니라는 결론에 이르렀다. 나는 드럼 연주와 키보드 조립을 즐기는 취미가 있다.

 

 그렇다면 개발도 그저 또 하나의 취미로 볼 수 있지 않을까? 남들과 다르다고 해서 우울해할 필요는 없었다. 중요한 것은 남들에게 피해를 주지 않는 선에서 내가 즐겁다면, 굳이 남들과 같을 필요가 없다는 것이었다.

 

나를 드럼도 치고, 개발도 하는 사람이라고 정의하기로 했다.

 

 이러한 깨달음을 얻을 수 있었던 것은 함께 고민해 주고 공감해 준 크루들과 코치 덕분이다. 

 나는 스스로의 생각에 갇혀 타인의 의견을 받아들이지 않는 경향이 있다. 만약 이 고민을 혼자 했다면, 끝없는 자괴감 속에서 헤어 나오지 못했을지도 모른다.

 

 이 경험을 통해 정형화된 쉼을 찾으려 애쓰기보다, 나만의 방식으로 쉬는 법을 찾아가는 것이 더 중요하다는 것을 배웠다.

 

 

 

 

레벨 인터뷰, 나만의 객체지향

 레벨 1이 끝나기 전, 일대다 면접 형식으로 레벨 인터뷰를 진행했다. 레벨 인터뷰를 통해 레벨 1 동안 정말 많이 성장했다는 것을 피부로 느꼈다.

 

 객체지향 핵심 원리를 사용해 내 설계를 단단한 논리로 설명할 수 있게 되었고, 뚜렷한 내 주관이 생겼다. 질문에 막힘없이 답하는 내 모습을 보고 많이 놀랐다.

 구구(코치)와 다른 크루들은 객체지향에 대한 본인의 주관이 뚜렷해서 좋다는 피드백을 주었다. 주관이 뚜렷하다는 것 자체로는 긍정적인 문장이 아니라 생각한다. "헛소리를 하지 않으면서, 자신의 의견이 확고하다" 는 것이 중요하다고 생각한다. 정답이 없는 객체지향 설계에서 나만의 설계 철학이 있는 것은 좋다고 생각한다.

 

 기술의 내부 동작에 관심이 많아 보여 좋다는 피드백도 받았다. Mocking 을 어떻게 구현할 것인가? 는 질문을 받았는데, 내가 생각하는 실제 구현 방식을 잘 설명했었다. 구구(코치) 는 "라이브러리를 사용한다" 는 대답이 아니라 "어떻게 구현할 것인가" 에 집중하는 모습이 좋다고 말해 주었다.

 

 좋은 피드백만 받은 것은 아니다. "목소리가 작아 자신감이 없어 보인다" 는 피드백도 받았다. 소심하고 내성적인 성격으로 인해 목소리가 작아진다는 것을 깨달았다.

 

 

 

 

아래 그래프는 레벨 1 동안의 내 감정과 성장 그래프이다.