[우아한테크코스] 2월 한달 회고

3월 중순에 적어보는 2월 회고록.
 
드디어 시간이 생겼다!
면 거짓말이고 드디어 시간을 다룰 여유가 생겼다.
 
2월 한 달간 내가 한 일

1. 연극
2. 자동차 경주 미션
3. 사다리 게임 미션
4. 자취, 졸업

 

아니 도대체 연극을 왜…?

우리 조원 모두는 우테코에서 연극한다는 사실을 알고 있었다지만 나는 전혀 모르고 있었다.
첫날 OT에서 갑자기 연극을 한다는 소식을 듣고
아, 연극팀이 와서 초대 무대를 하나? 복지 짱이다! 싶었다.
그런데 그 연극을 내가 한다는 것… 절망적이었다.
안 그래도 낯 심하게 가리는데 연기를 하라니 ^__^
 
그 당황스러운 마음가짐으로 일주일 간 연극을 준비했다.
각자 아이디어를 가져오기로 해서 자료 조사(?)를 하는 과정에서도 이게 맞나? 싶었다.
뭘 생각하긴 했는데 이거로 하나의 연극을 꾸려야 한다는 게 너무 부담이었다.
 
몇 번의 회의를 통해 아이디어를 거르고 합치고 발전시켰다.
회의 초반에는 막막함만 가득했는데 회의를 거칠수록 틀이 보이고 완성작이 보이는 게 신기했다.
혼자 하는 것보다 함께 했을 때의 결과물이 훨씬 좋았다.
왜 우리가 사회에 나가면 어쩔 수 없이 협업을 해야 하고 왜 협업 스킬을 중시하는지 알게 되었다.
 
우리 조는 이상한 상사 세 명이 사원 하나와 신입사원 하나를 갈구는 스토리로 연극을 꾸렸는데,
나는 갈굼 당하는 역할이 당첨돼서 무난하게 큰 긴장감 없이 한 것 같다.
혼자 했으면 엄청 떨렸을텐데 다섯 명이 같이 무대에 오른다는 사실과 다섯 명의 성격이 비슷하다는 사실과 첫 번째 순서라는 사실이 굉장히 큰 위안이 되었다.
 
처음엔 연극을 한다는 사실 자체가 싫었지만, 어쨌든 그 황당한 활동을 어찌저찌 해내면서 오히려 조원들과 가까워진 것 같다. 그리고 연극 무대를 통해 다른 조 크루들도 볼 수 있어서 모든 크루들의 닉네임은 모르지만 얼굴은 익숙해졌다.
재밌게 잘 한 것 같은데... 시간이 흘러서 미화된 건가?
 

첫 번째 페어 프로그래밍 미션: 자동차 경주

1단계 PR 주소
2단계 PR 주소
 
사실... 첫 페어 미션 후 나는 나에게 크게 실망했다.
 
졸업 프로젝트 끝나고 3개월 동안 개발을 쉬어서,
맥북 사용이 익숙지 않아서,
나는 구현하고 리팩토링하는 스타일이어서 등… 핑계는 많았다.
근데 사실 그냥 잘 못하는 사람이었다.
 
그런 나와 달리 페어 리비는 이미 준비된 사람 같았다. 많이 학습한 듯 보였고 미션 과정에서 리비와의 소통은 보통 리비가 사용하는 패턴을 묻는 나, 딱 그것이었다. 리비의 모든 생각이 나의 생각보다 낫다고 판단했고, 모든 부분에서 리비에게 납득되어서 결과물을 보았을 때 내 코드 같지가 않았다. 물론 덕분에 익숙하지 않은 패턴들을 많이 접해볼 수 있었고 리비가 설명을 정말 잘해줘서 얻어가는 지식이 많았다. 열심히 배워서 다음 미션에 적용하기도 했다 ㅎㅎ 😗
 
하지만 리뷰어로부터 리뷰 요청을 받을 때 내 코드를 리뷰받는다는 느낌이 들지 않았다. 다른 사람의 코드를 리뷰받는 느낌이었고 리뷰어의 리뷰에 코멘트를 달 수 없었다. 그러면서 나 일주일 동안 뭐 한 거지.. 하며 힘이 빠지기도 했다.
 
그런데 피드백 강의에서 네오는 오히려 힘을 쫙 빼고 코드를 구현했다. 기술이나 패턴 하나 없이 온전히 성공시키는 것에 집중한 코드를 구현했다. 그리고 크루들이 패턴에 대해 언급하면 왜요? 굳이? 그게 지금 왜 필요하죠? 일단 구현하는 게 먼저 아닌가요?라고 말했다. 거기서 조금 충격을 받았다. 설계를 완벽하게 해야 한다고 생각했는데 어쨌든 일단 우리에겐 데드라인이 있으니 쓰레기라도 만드는 것이 중요하다는 것. 아직은 작은 프로그램이니 패턴이 꼭 요구되는 것은 아니라는 것. 사용하는 게 중요한 것이 아니라 왜 사용하는지가 중요하다는 것!
 
단순히 나의 배움이 짧아서 자신감이 떨어졌던 게 부끄럽기도 하면서 강의가 정말정말 큰 힘이 되었다.
그래서 피드백 쓰라길래 익명에 힘입어 열심히 적었다 ㅎㅎ 그런데 그 피드백을 네오가 강의에서 언급해 줬다. 두둥

페어 미션에서 상대적으로 여러 패턴을 활용하지 못하는 저를 보면서 '내가 잘 못하고 있나'라는 의구심이 자주 들었는데, 강의에서 정답은 없다고 말씀해주셔서 위로가 되었고 자신감을 얻기도 했습니다.

아직 페어와의 프로그래밍이 익숙하지 않아서 제 의견을 강하게 피력하기보다는 수긍하는 방향으로 진행하였습니다. 그래서 그런지 리뷰를 받았을 때 제 코드가 아닌 타인의 코드를 리뷰받는 느낌이었습니다.

다음 미션부터는 저의 스타일도 주장해보려고 합니다. 그리고 이런 과정이 페어 프로그래밍을 하는 이유라고 생각합니다 ㅎㅎ 좋은 강의와 미션 감사합니다. 앞으로도 잘 부탁드립니다!

 
이 정신 상태로 힘들기도 했는데, 네오가 내가 적었던 글을 언급하면서 이런 감정을 느낀 사람이 많을 거라고, 네오가 원하는 방향이 이런 거라고 말해주었다. 응원한다고도…! 말해줬다…!
내가 썼다는 거 아무도 모르는데 뭔가 내 속마음 들킨 것 같아서 나 혼자 얼굴 빨개졌다. 네오가 응원해줬을 때는 나 혼자 왕감동 먹었다. 수업 끝나고 마침 네오랑 대화할 기회가 있어서 내가 쓴 거라고 완전 위로받았다고 말하기도 했다.
 
> 앞으로는 내 의견도 열심히 얘기해 봐야지! 다짐했던 첫 번째 미션이었다.
 

두 번째 페어 프로그래밍 미션: 사다리 게임

1단계 PR 주소
2단계 PR 주소
 
이번 미션 페어는 옆 조의 트레였다.
데일리 미팅 제외하고는 옆 조와 이야기할 기회가 많이 없었는데 잘 됐다! 싶었다.
 
트레와의 미션에서 나는 트레의 스타일 일부를 흡수했다.
(이렇게 페어의 장점을 하나둘 흡수하다 보면 나도 어느새...? 오호호)
 
나는 결과물이 보여야 힘을 얻는 스타일이라서, 요구사항을 정리하거나 설계하는 부분을 간략히 하고 넘어가는 편이었다. 근데 트레는 달랐다. 요구사항을 작성하면서 대략적인 설계를 생각하고 구현을 시작했다. 나도 사실 급하고 초조해서 그렇지 느린 편이라 천천히 하는 스타일을 선호하는데 페어가 그렇게 해주니 옳지 너무 좋구나 하고 그대로 따랐다.
 
요구사항을 정리하면서 대략적인 게임의 흐름과 설계가 파악되니 구현을 할 때 훨씬 편했다. 이 도메인이 어떤 역할을 갖는지 아니까 불필요하게 작성되는 코드도 적었고 미션에 대한 이해도가 높아지니 페어와 소통하기도 더욱 수월했다.

[축하] 드디어 페어를 설득했다! [축하]

나는 출력 뷰 OutputView와 출력될 메시지를 가공하는 MessageResolver 클래스를 분리하고 싶었다.
프리코스 때 뷰에 도메인 넘기는 것이 찝찝해서 이걸 어떻게 해결해야 할까 고민만 하고 넘어갔었는데 (물론 지금 생각하면 DTO 사용해서 어쩌구...), 첫 번째 페어 미션에서 리비의 방식을 보고 좋은 방식이라고 생각했다. '뷰와 로직을 분리해서 도메인 전달을 막을 수 있고 메시지를 가공하는 것과 콘솔에 출력하는 역할을 분리할 수 있다'라는 근거를 갖고 열심히 코드까지 적어가며 트레를 설득했다. 토의하는 과정이 꽤 길었고 코드를 보더니 트레가 내 의견에 동의해 줬다. 결론적으로 우리의 MessageResolver는 양쪽 리뷰어 모두에게 부정적인 평을 받았지만 그럼에도 재밌었고 뿌듯했다. 아, 그중 인상 깊었던 피드백은 '결국에는 같은 역할로 보인다'와 '뷰 출력 방식이 변경된다면 해당 객체도 변경되어야 할 것'이라는 피드백이었다.
 
나는 원래 불필요한 감정 소모와 시간을 쏟기 싫어서 웬만하면 상대방에게 수긍하는 편이었는데, 트레와의 미션을 통해 충돌하고 설득하는 과정이 재밌어졌다. 상대와 의견이 달라도 건강하고 재밌는 토의가 가능하구나! 싶었다.

리뷰어와의 소통

이번 리뷰어는 알렉스였다. 첫 리뷰 요청을 보냈을 때 꽤 늦게 답변이 와서 조금 당황했었는데 그만큼 꼼꼼하게 리뷰를 보내주셔서 많이 도움되었다. 이번 미션에서는 내 의견을 많이 정리하고 이야기하려고 노력한 것 같다. 리뷰어에게 수긍할 때도 그냥 수긍하는 것이 아니라 어떤 부분에서 납득이 되었고 내 생각이 어떻게 바뀌었는지 설명했다. 그러다보니 내 생각이 정돈되는 느낌이었다. 그 과정이 정말 재밌었다. 무조건 받아들이는 태도가 아닌 내 의견을 이야기하고 상대의 의견을 묻는 과정이 매우 중요하다고 생각했다.

TDD 사용해보기

이번 미션의 핵심은 TDD 방식을 적용해보는 것이었는데, 내가 느낀 TDD의 이점은 아래와 같다.

1. 테스트를 작성해보며 대략적인 설계가 가능하다.
2. 테스트 작성에 의무감을 부여하니 테스트를 작성할 수밖에 없고 그렇다면 테스트 작성의 이점을 더더욱 얻게 되는 것. 테스트 코드를 모두 통과한다는 것은 정말 큰 안정감을 주는데, TDD는 어떻게 보면 그러한 안정감을 강제하는 것 같다.
3. '나중에 테스트 짜다보니 테스트하기 힘들어서 코드 수정해야겠다' 의 과정이 줄어든다.

그리고 다른 인상깊었던 이유들

• 귀찮긴 하지만, 중압감을 귀찮음으로 바꿀 수 있으니 오히려 좋다.
• 테스트 작성 과정은 내가 왜 구현하는지에 대한 생각 정리 과정.
• 내 코드에 근거를 갖기 위함
• 콘솔 디버깅 최소화

다른 크루들이 이야기하는 TDD의 이점도 인상깊었던 게 많았는데 못 적었다.. 다음엔 적어둬야지.
 
> 토의하며 설득하고 설득 당하는 과정의 재미를 느꼈던 두번째 미션이었다.

---

 
이렇게 2월 한 달간의 회고를 마무리한다.
나만 그런지 모르겠는데 페어 프로그래밍을 마치고 나면 페어에게 전우애 비슷한 게 생긴다. 모두 나중에 잘 됐으면 좋겠다.
 
회고가 처음이라서 내 감정을 어느정도까지 드러내야할지 모르겠다.
너무 일기처럼 적은 것 같아서 조금 부끄러운데 언젠가는 이 수위를 적절히 조절할 수 있는 날이 오겠지?