코드에 대한 고민, Next Step

이직 후, 오랜 기간 서비스된 앱을 개발하게 되면서 가장 자주 들었던 생각이 있었다.

아, 이건 레거시 구조 때문에 더이상 건드리기가 어렵다.

사실 이미 존재하는 레거시 코드를 탓하는 것은 큰 의미가 없다. 중요한 것은 앞으로 내가 작성하는 코드 역시 이러한 레거시 코드가 될 수 있다는 것이었다. 그래서 최근부터 유지 보수하기 쉬운 코드란 무엇인지, 레거시는 왜 관리하기가 어려운지 고민하기 시작했고, 관련된 내용의 글과 책을 찾아보며 나름의 결론을 내고자 했었다.

그러던 중 우연히 한 개발자의 글을 통해, 내가 고민하고 있는 포인트와 비슷한 내용을 다룬 강의가 있다는 것을 알게 되었고 그것이 바로 Next Step 의 강의 였다. 소개된 커리큘럼과 진행 방식을 보며, 투자할 가치가 있다고 생각되었고 바로 수강 신청을 했다.

의도적인 수련을 통한 학습

최근 읽었던 책에서 의도적 수련 이라는 개념을 이야기하는 부분이 있었다. 내용의 핵심은, 매일 어떠한 일을 반복하더라도 이를 의도적으로 분석하고 개선하고자 하는 노력이 없으면 실력이 늘지 않는다는 것이다. 우리가 양치질을 매일 반복한다고 양치질의 전문가가 되지 않는 것처럼 말이다.

그리고 Next Step 의 독특한 수업 진행 방식은 이러한 의도적 수련을 지속적으로 할 수 있도록 도와주는 형태로 이루어져 있었다.

수업은 다음과 같은 루틴으로 반복된다.

1. 주 1회 TDD, Clean Code, Refactoring 에 대한 오프라인 강의가 이루어 진다.
2. 배운 개념을 바탕으로 해당 주차의 과제를 수행한다.
3. 과제는 단계별로 이루어져 있으며 각 단계의 요구사항을 모두 구현하면 PR 을 보내, 담당 리뷰어에게 피드백을 받는다.
4. 모든 단계의 피드백을 반영하면 해당 과제가 마무리 된다.
5. 1-4 의 과정 반복

일반적인 강의와 가장 큰 차이점은 구현한 코드에 대한 리뷰를 받는 과정이 있다는 것이다.

매번 각 과제의 단계마다 구현한 내용에 대하여 피드백을 받는다. 이때 피드백은 문제의 해답이 아니라 방향성만 제시 해주기 때문에, 스스로 생각해보고 각각의 결정에 대한 트레이드 오프를 고려하는 시간을 만들어준다. 또한 다소 추상적일 수 있는 수업 내용을 실제 코드에서 적용해 나가는 과정에서 제대로 개념을 이해하고 넘어갈 수 있었다.

(피드백만 잘 반영해 나가도, 어느샌가 자연스럽게 클린 코드를 바탕으로 리펙토링하고 있는 자신을 발견할 수 있다.)

기억에 남는 수업 내용

수업 내용 중 기억에 많이 남았던 부분을 정리하고 이에 대한 생각들의 정리이다. (수업 내용의 일부는 미리 허락을 받고 적었다.)

클린코드를 지향해야 하는 이유

우리가 클린코드를 지향 해야하는 이유는 무엇일까?

이 물음은 인간은 완벽하지 않다는 개념에서 출발한다. 코드를 짠 순간은 빈틈이 없어 보이지만, 시간이 지날수록 스스로도 과거의 자신을 이해하지 못하며 관리하기 어려운 코드가 되어 버린다. 왜냐하면 인간 역시 스스로 계속 변화하는 변수이기 때문이다. 따라서 코드를 짜는 개발자를 믿을 수 없다. 믿어서는 안된다. 우리는 지킬 수 있는 약속을 만들고, 이 약속을 믿어야 한다.

모두가 약속에 기반하여 코드를 짜면, 설령 시간이 흘러 사람이 변했더라도 약속을 상기시키며 수월하게 관리하고 변경할 수 있다. 클린코드는 그러한 약속들이라고 생각할 수 있다.

→ 너무나 공감되는 대목이었다. 코딩의 신의 강림한듯한 날에 마무리한 후 엄청난 뿌듯함을 가지고 퇴근을 했는데, 며칠 뒤에 다시 보니 너무나 복잡도가 높아 이해하기가 어려워 결국 바닥부터 다시 짰던 경험이 있다. 같은 맥락에서 팀 차원의 공용 컨벤션이나 아키텍처 구조 등을 가이드로 정하고 이를 지키려는 노력들이 중요하다고 생각한다.

Out → In vs In → Out : 처음부터 완벽한 코드는 없다

어떠한 도메인에 대한 구현을 하게 될 때 우리는 다음과 같은 접근 방식 중 하나를 선택하여 구현을 할 수 있다.

Out → In 방식

• 도메인의 요구사항을 충족할 수 있을 정도로만 빠르게 구현한다.
• 하나의 객체가 많은 역할을 수행하고 있을 수 있다.
• 도메인 지식이 없거나 요구사항 복잡도가 높은 경우 적합하다.

In → Out 방식

• 도메인을 가장 단위의 객체부터 나누어 기능을 구현하고, 이를 확장해 나간다.
• 각 객체가 수행하는 역할이 작고 명확해진다.
• 도메인 지식이 있거나 요구사항이 단순한 경우 적합하다.

→ 이 내용의 핵심은 어떤 방식이 더 낫다는 것이 아니라 상황에 맞게 적절하게 선택해야 한다는 것이다. 나의 경우 이러한 사실을 일찍 깨닫지 못하고, Out → In 방식이 클린 코드의 규칙들을 지키지 못하는 것 같다는 느낌이 들어서 새로운 도메인이 주어진 과제를 시작부터 In → Out 방식으로 접근했었다. 처음에는 작은 레벨 부터 객체를 확장시켜 나가면서 도메인의 요구사항을 충족하는게 어렵지 않았다. 그러나 점점 스펙이 추가 될 수록, 좋지 않는 냄새가 나는 코드가 되어져 갔다. (어? 굉장히 익숙한 상황 아닌가?) 왜냐하면 도메인 지식이 충분하지 않기 때문에 설계 과정에서 놓치는 점들이 많았기 때문이다. 결국 몇 번의 갈아엎음을 반복하면서 도메인 지식이 충분히 쌓인 후에야, 새로운 스펙이 추가 됐을 때 In - Out 방식으로 구현이 가능 해지기 시작했다.

프로그래밍의 대부분이 그런 것 같다. 모든 상황에 절대적으로 적용할 수 있는 만능 키는 없다고 본다. 다만, 각각의 선택에 대한 트레이드 오프를 인지하고 있고, 그것을 토대로 상황에 맞게 선택하는 지혜가 필요하다.

팀내에서 어떻게 도입할 것인가?

수업 내용을 듣더라도 당장 내일부터 팀에 적용하는 것은 무리가 있을 수 있다. 우리는 어떤 전략을 취해야 하는가?

사람은 감성적인 측면이 더 강하기 때문에 이성적, 논리적으로 제안하는 것보다 친분관계를 쌓고 실력에 대한 신뢰 형성 후 얘기를 나누어 보는 것이 더 승산이 있다.

우선은 내가 맡은 코드부터 바꿔보는 작은 시도를 하고 성공하는 경험을 느낀다. 그렇게 작은 시도와 성공을 반복하며 범위를 넓혀 가다가 관심이 보이는 동료가 있으면 같이 이야기를 나누며 전파하고, 팀원 전체에게 전파해 나간다. 만약 이러한 과정이 실패하더라도 내 성장이 따라오기 때문에 잃는 것은 없다. 시도해 볼만한 싸움이다.

→ 감성적인 측면으로 접근한다는 새로운 관점의 설득 방식이 기억에 남았다. 실제로 강력한 논리로 무장한 의견을 제시 하더라도 잘 받아 들여지지 않는 반면, 친하고 신뢰가 있는 동료의 몇 마디에 통과가 되는 상황을 본적이 있다. 전략을 성공시키기 위해서는 다양한 무기를 활용할 필요가 있다. 좋은 무기 중 하나가 되지 않을까?

강의를 듣기 전에…

내가 강의를 듣기 전에 궁금 했었던 부분의 정리이다.

클라이언트 개발자가 들어도 될까?

• 결론적으로는 들어도 된다. 100% 자바 베이스로 [TDD, Refactoring, Clean Code] 에 대한 내용을 학습하는 것이기 때문에 개발 스택에 상관없이 내용을 따라갈 수 있다. 나는 처음 OT 시간에, 주변에 전부 백엔드 개발자분들만 계서서 수강대상이 아닌줄 알고 혼란에 빠졌던 기억이 난다.

  추가로 나는 처음 과제 진행을 할 때 기존에 익숙한 Android 스타일로 단계를 진행하다가, 관련된 피드백을 참조하여 익숙한 스타일을 깨고 다른 식으로 접근 해보기 위해 노력 했었다.

먼저 선수 과정으로 공부해야할 것이 있을까?

• git, java 가 익숙하지 않은 사람은 기본적인 개념을 익히고 가면 좋다. 물론 각 과정에서 git, java 를 깊게 다루는 것은 아니기 때문에 진행하면서 같이 익혀도 상관은 없으나, 그만큼 초반에 더 많은 시간을 투자해야한다는 것을 염두해두자.
• 객체지향의 오해와 진실, 이펙티브 자바, 클린 코드 등의 책을 읽고 가면 좀 더 빠른 이해와 과제 진행이 되지 않을까 싶다. 그러나 권장 사항일뿐 필수는 아니다.

정말 직장 다니면서 할 수 있을까?

• 할 수 있다. 그런데 각오는 해야 한다. 퇴근 후에 지친 상태에서 과제를 진행 하는게 쉽지 않다. 하루종일 코드를 봤는데, 또 코드를 봐야 한다는 압박감도 찾아온다.

  또한 뒤로 갈수록 난이도가 올라가기 때문에, 점점 더 많은 시간의 투자가 요구된다. 평일과 주말을 가리지 않고 적지않은 시간을 투자 했는데, 갈수록 한주 내에 과제를 마무리하는 것이 쉽지 않았다. (글을 쓰는 이 시점에도 아직 마무리하지 못한 과제가 남아있다. 😂)

  물론 과제에 대한 마감 기한이 없고, 하나의 과제라도 확실히 내 것으로 가져가는 것이 중요하다고 하셨기 때문에 너무 무리해서 과제를 진행할 필요는 없다.

  나 같은 경우 지속적으로 하기 위해 일종의 보상 체계를 구축 했는데, 퇴근 후 딱 한시간 만 온전히 내가 하고 싶은 것을 하고 자기 전까지 과제를 진행하는 방법이었다. 효과는 굉장했다!

야근이나, 개인적인 사정으로 강의를 못듣게 되면 어떡하나?

• 다음 기수에서도 똑같을지 모르겠으나, 내가 수강했던 기간에는 매번 강의가 끝난 후 촬영된 영상이 제공되었다. 또한 슬랙 DM 으로 언제든 궁금한 것을 물어볼 수 있기 때문에 갑작스러운 야근이나, 개인 사정으로 듣지 못하더라도 크게 걱정할 필요는 없다.

마무리 하며

이 수업 과정을 마쳤다고 해서 TDD, Clean Code, Refactoring 의 종착점에 도달했다고 얘기할 수는 없다. 오히려 이제 시작이라고, 나아가야 한다고, 출발선에 세워 주는 느낌이다. 달려가는 과정 속에서는 분명히 많은 어려움이 따라오겠지만 이제라도 올바른 레이스를 시작할 수 있게 된 것에 감사함을 느낀다. 글을 마무리하고, 미처 끝내지 못한 과제를 하러 다시 달려야겠다. 🤟

항상 열정적으로 강의를 진행해주신 재성님, 매번 디테일한 리뷰와 함께 함께 고민을 나누어 주셨던 리뷰어분들께 감사드린다.

link : https://edu.nextstep.camp/

다음 기수의 강의가 열리기 전에 미리 대기 신청을 할 수 있으므로, 관심이 있으면 클릭!