저번 주까지만 해도 연극 준비가 머리에 가득했다. 생각보다 바쁘지는 않았지만 바쁜 것만 같은 나날이 지나갔다. 주말에도 열심히 연극을 준비하고, 외우지 못한 대사는 그때 가서 다시 떠올리는 것으로 하고… 월요일에는 1시에 출근하는 날이라 비교적 여유롭게 준비할 수 있어 좋았다. 2시부터 곧바로 연극이 시작되는 바람에 다시 휘몰아쳤지만…
🤸🏻♂️🤸🏻♀️ 연극, 브리+네오조 회식
연극은 정말정말 재미있었다. 다들 웃고 박수치느라 정신이 없었다. 팀마다 처음 보는 사람들과 일주일간 호흡을 맞춰나가면서 재미있는 연출을 보여줬다. 특히 이번 기수에서 최초 백스테이지 사용, 최초 CG 사용 등 참신한 아이디어가 많이 나와주면서 관객들이 더 몰입하며 볼 수 있게 되었던 것 같다. 이재용 회장님과 포비의 등장은 지금 생각해도 너무 참신했다.
연극으로 하루를 마무리하고 나서는 다음 날의 미션을 앞둔 회식(?)이 진행됐다. 우리 조는 브리조였는데, 켈리네 조인 네오조와 함께 많은 크루들과 이야기를 나눌 수 있는 시간을 가졌다. 피자, 치킨, 떡볶이… 끊이지 않았던 음식들과 대화로 시간 가는 줄 몰랐다. 80명이나 되는 사람들을 한 번에 알아갈 수는 없었지만, 이번 기회로 네오 크루들과 말도 섞으면서 얼굴을 익혀나갔다.
우리 조까지 해서 스무 명이면.. 이 기세로 한두 달 안에 우리 크루들 얼굴과 이름을 외우는 게 목표다! 켈리 로키 몰리 알파카 페드로 폭포 포케 로빈 무빈 리브 다들 반가웠어요 💁🏻♂️ 이후에 선릉 캠퍼스에서 파티를 찾았으나 실패한(?) 쿠키, 토다리까지 멋있는 신고식과 함께 합류했다.
🚧 테스트 주도 개발
TDD는 들어본 적 있었고, 책에서 하는 대로 구현도 따라해 본 적 있었다. 하지만 왜 쓰는지에 대한 대답을 스스로 할 수 없어 개발할 때에는 사용하지 않았던 것 같다. 기껏해야 구현한 코드에 대한 테스트를 작성하는 정도였다.
이번 네오의 강의에서는 TDD에 대해서 진행했다. 왜 테스트를 먼저 작성할까? 요구사항만 잘 작성하면, 테스트 코드만 잘 작성한다면, 단위 테스트만 잘 작성하면 되는 것 아닌가? 라는 기본적인 부정 질문으로부터 생각을 다져나가기 시작했다.
강의를 들으면서 생각이 바뀌었다. 중요한 것은 테스트를 짰다는 것이 아니라, 필요 이상의 코드를 작성하지 않게 된다는 점이다. 구현 코드에 치중하면 돌아가는 쓰레기가 되고, 이 때에 리팩터링이 필요해 가독성과 유지보수를 챙기는 사이클을 반복하게 된다. 이를 절차로 정형화한 것이 TDD라고 할 수 있다. 테스트 코드를 보면 어떻게 동작할지 정확하게 알 수 있다. Readme와 같은 문서들은 수정하지 않으면 변경사항이 반영되지 않는다. 코드는 거짓말하지 않는다!
TDD에서는 아래와 같은 세 가지를 반복하면서 코드를 발전해나간다.
- 테스트 코드를 작성한다. 어떤 동작을 하는지 명확하게, 단위 테스트를 촘촘하게 작성한다.
- 테스트가 동작하는 가장 빠른 해결 방법을 가져와서 테스트가 동작하도록 한다.
- 2에서 구현에 집중했으니 이번에는 코드를 깔끔하게 만드는 데에 집중한다. 이때, 테스트도 그대로 돌아야 한다! (Regression Test)
여기에서 주의해야 할 점은, 구현할 때 가장 빠르게 해결할 수 있는 방법을 사용하는 것이다. 코드가 더러워져도 좋다. 지금 해야하는 것은 테스트 코드가 통과하도록 하는 것에 집중한다. 다만, 이 또한 TDD를 시작하기 전에 요구사항 분석을 진행하는 것은 필수 요소이다. 무엇을 해야 할지를 명확하게 아는 것이 제일 중요하다.
이와 같이 개발을 진행하게 된다면, 점진적으로 설계를 개선해나갈 수 있다. 필요하지 않은 코드를 작성하지 않게 되며, 코드에서의 과한 기교를 방지할 수도 있다 (No overengineering). 테스트가 완성돼 있기 때문에 기능을 추가하는 데에 용이하므로, 작은 성취감을 계속해서 가져가면서 리듬감을 챙길 수 있게 된다. 이 부분이 참 좋다. 코드를 모두 완성했을 때에 몰려오는 성취감을 쪼개둔 뒤, 각 기능 테스트마다 나눠서 간식을 넣어 둔 기분이었다. 테스트 코드에서 초록 불을 확인하는 것을 싫어하는 개발자가 얼마나 될까?
계속해서 작은 것을 달성해 나가야 한다. 너무 먼 미래를 보는 것은 지양해야 한다. 요구사항이 바뀌면 그때 돼서 리팩터링을 진행하면 된다. 내가 코드리뷰를 받을 때마다 해주시는 이야기는 “이게 필요할까요?” 라는 말이었다. 덕분에 지금 당장 필요하지 않은 클래스와 인터페이스를 과감히 버릴 수 있었다. 관리가 어려워지기 전까지는, 불편함을 느끼기 전까지는 그대로 두자. 리팩터링을 하는 데 드는 시간과 노력도 비용이다.
머릿속에서 내가 생각한 구조를 구현하는 것은 지극히 본능적인 것이다. TDD는 테스트 – 구현 – 리팩터링을 강제해 머릿속의 구조가 정말 필요한 것인지를 확인할 수 있도록 한다. 구현하는 때마다 “이렇게 구현하는 게 맞아?” 라고 스스로 끊임없이 되묻는 연습을 하자.
You don’t have a crystal ball, you can’t see the future and predict that a change request will happen.
🔮 마법의 수정구는 없다. 우리는 미래에 어떤 요구사항이나 변동이 다가올 지 예측할 수 없다.
https://stackoverflow.com/questions/24614035/issues-with-the-open-closed-principle
🏳 final이 뭐라고…
파라미터에 final이 붙는 것이 어떤 역할을 하는가? 에 대한 토론에서 시작되었다. 컴파일 타임에서만 작동하는 것 같은 느낌이었고, 페어는 JVM이 구동될 때, 다른 구역에 저장되어서 바뀌지 않도록 하는 장치가 있을 수 있다는 이야기였다. 페어의 코드리뷰에서 메서드 파라미터에서의 final에 대한 질문으로 동시성과 관련된 답변이 오면서 이 논란(?)이 불거졌는데, final과 저장 공간에 대한 레퍼런스를 쉽게 찾지 못했기 때문에 어려웠다.
Reflection API로 어떻게든 바꿀 수 있고, new 연산자를 쓰기 때문에 힙에 저장된다는 것 등을 공식 문서를 찾아가면서 퍼즐을 맞추듯이 빈 틈을 채워나갔다. 결국 JVM 명세와 언어 설명서, 가비지 컬렉팅 관련 문서까지 뒤져보면서 나만의 정답을 찾아내기 시작했다. GC까지 많은 공부를 했으니 얻어가는 건 많았다고 생각한다! 😃
🪜 2차 미션, 사다리 게임과 반성
저번 자동차 미션을 마치고, 새로운 미션과 함께 이번에 함께하게 된 페어는 상돌이었다. 상돌과 나의 코드 스타일이 너무나 비슷해서 우스갯소리로 같이 일하면 서로 배울 수는 없을 것 같다는 이야기도 했다 🤣. 그 정도로 코드 한 줄 한 줄 작성할 때마다 나도 그렇게 생각했는데? 라는 말을 많이 주고받았다.
이번 미션부터는 깃허브의 Co-Author 기능을 사용해서, 커밋에서도 우리 둘의 아이콘이 모두 뜨도록 했다. 둘이서 코드를 짰지만 한 사람의 커밋으로 들어간다면 조금 서운(?)하니깐.. 이렇게 페어 프로그래밍을 하면서 우리 둘 다 코드 짰다는 성취감을, 잔디를 심을 수 있게 됐다.
1단계 미션은 어렵지 않았기에 금방 구현하고 리팩터링을 마무리했다. 상돌의 리뷰어가 먼저 리뷰를 남겨주셨는는데, TDD에서 생각했다면 쉽게 찾아낼 수 있었던 몇 가지 필요없는 클래스들을 집어 주셔서 나의 PR을 날릴 때에 코멘트를 추가해 두었다.
1단계 미션의 두 번째 코드리뷰에서 리뷰어님의 말씀에 충격을 받았다. 프리코스에서 인덴트를 지키며 예외 발생 시 재입력을 받아야 하는 요구사항이 존재했다. 자동차 경주를 할 때에도 해당 요구사항을 추가적으로 넣어 구현했고, 인덴트 1의 제한 사항이 추가되면서 재귀를 사용해야 하는 상황이 발생했다. 이를 해결하기 위해서 이런 글도 써가면서 문제를 잘 해결한 것 같아 기분이 좋았었는데, 리뷰어 분 입장에서는 요구사항에 적혀있지도 않은 것에 너무 많은 공을 들였다고 보셨던 것 같다.
우테코에 합격했지만, 아직도 나는 프리코스에 살고 있었다. 객체의 역할과 TDD에 대해서 조금 더 파고들었어야 했는데 그러지 못했다. 주된 학습 사항과 요구사항이 아님에도 작성하는 바람에 리뷰어 분께서 확인해야 할 것이 늘게 되었다. 기분이 묘하면서도, 먼저 리뷰어 분께 죄송하다는 생각이 먼저 들었다. 2단계 미션 시작과 함께 해당 부분을 과감하게 삭제했다. 불필요한 메서드나 클래스를 삭제하고, 보기 쉬운 코드를 작성하기 위해서 고민했다.
☕ 케이, 안나와의 커피챗
kth990303으로 유명한 우아한형제들 케이와 6기 안나와 이야기할 기회가 생겨 한 시간 넘게 재밌는 이야기를 나눴다. 안나가 많은 질문을 준비해와서 질문답변하는 것도 들었다. 사실 나는 케이와 대학교 동기라… 가볍게 들어갔는데, 안나가 케이에 온전히 집중하는 시간을 방해한 것만 같아서 미안한 마음도 있었다. 알고리즘 관련된 이야기, 공부를 어떻게 하면 좋을 지, 성과/학습 마인드셋과 같은 다양한 주제로 꽉꽉 찼던 한 시간이었다!
🤔 바쁜 일상과 멘탈 관리
주중에는 거의 매일같이 저녁 시간에도 남아 공부했다. 월화수에는 JVM 명세와 Java 문서를 확인하는 데에 시간을 들였고, 목금에는 Garbage collection 문서를 보면서 어떤 방식으로 JVM의 메모리를 관리하는지를 배웠다. 특히나 GC, JVM 부분은 한국어로 정리된 블로그 글들과 명세에서의 차이점이 몇몇군데 보여서, 확실히 원서를 보고 학습하는 게 더 나았던 듯하다. JVM이 단순 명세이고, 이를 구현하는 구현체에서 GC를 제공한다는 개념을 적어둔 곳을 많이 못 봤으니… 👀
주말 동안에는 고등학교 때 자퇴하고 다녀온 꿈틀리인생학교의 홈커밍 데이가 있어서 잠시 다녀왔다. 내가 처음 들어갔을 때가 1기였고, 지금 졸업한 게 8기니 벌써 시간이 많이 흘렀다. 학교를 더이상 운영하지 않는다는 이야기를 도착해서야 듣게 되었는데, 인생에 큰 변환점이 되어 주었던 곳이 사라지게 된다니 마음이 좋지만은 않았다. 살면서 기쁘거나 힘들거나, 선택의 상황이 올 때마다 학교에서 머물렀던 1년의 시간이라는 게 도움이 정말 많이 됐다.
학교가 강화에 있는데다 교통편이 좋지 않아 가는 데에만 3시간이 걸린다. 아무래도 일요일에는 코드를 작성해야 할 것 같아서 당일치기로 다녀왔다. 3시간 동안 가서, 5시간 정도 즐기고 3시간동안 다시 돌아왔다. 😥 가만히 앉아 있는 게 더 힘들었던 하루였다. 집에 돌아오니 12시가 넘었다. 돌아오면서 1단계 2차 PR 리뷰를 확인해서 육체적으로 힘든 중에 멘탈 관리도 어려웠다.
레벨 1이 가장 여유롭고, 스터디도 많이 열린다고 하는데, 2-3레벨이 되면 얼마나 더 바빠질 지 감이 오지 않는다. 분명 케이가 쉬울 거라고 했었는데… 아무래도 당한 것 같다 🤣 시간 잘 쪼개서 지내야지.