우아한테크코스 6기에 지원하기까지
작년 겨울, 제가 활동 중인 동아리에서는 교내 대학생 개발자를 위한 IT 컨퍼런스를 개최했었습니다. 해당 컨퍼런스의 강연 연사로 졸업한 선배들을 초청했었는데, 초청되었던 선배들은 대부분 우아한테크코스(우테코)를 수료해 다양한 기업에서 일하고 있었습니다. 저는 현업 선배들의 이야기를 들을 수 있는 좋은 기회를 놓치지 않고 어렴풋이 알고 있었던 우테코의 궁금했던 점들을 질문했습니다.
선배들은 우테코가 일방적인 강의식 학습이 아닌 상호 협력을 통해 함께하는 학습을 제공하고, 현장형 인재로 성장할 수 있게 도와준다고 이야기했습니다. 저는 그 대답을 듣고 꼭 우테코에 도전해봐야겠다는 생각이 들었습니다. 그렇게 시간이 흘러 6기 모집 공고가 올라왔고, 저는 저의 지난 날들을 돌아보며 열심히 지원서를 작성했습니다. 쓰고 고치고를 반복하다가 모집 마감날에 지원서를 제출헸고, 곧바로 시작될 프리코스를 준비했습니다.
프리코스 1주 차 미션 - 숫자 야구 게임
10월 19일 목요일 오후 3시, 어떤 미션이 주어졌을지 긴장 반 설렘 반으로 메일함을 열어 미션을 확인했습니다. 6기 프리코스 참가자들에게 주어진 첫 미션은 간단한 숫자 야구 게임이었습니다. 처음 미션을 확인하고 들었던 생각은, '어? 의외로 쉬운 문제네?'였습니다. 숫자 야구 게임은 이전에도 접해본 유명한 프로그래밍 실습 과제이기도 했고, 게임 자체가 복잡한 알고리즘을 요구하지도 않습니다. 그러나, 제 생각과 달리 우테코의 숫자 야구 게임은 간단하지만 간단하지 않은 미션이었습니다.
물론 우테코가 요구하는 숫자 야구 게임의 규칙도 크게 어려울 것 없이 간단했습니다. 그러나, 게임의 핵심 로직 외에 생각해야하는 것들이 정말 많았습니다. 단순한 알고리즘 코딩 테스트처럼 출력값만 요구 사항과 동일하면 해결되는 미션이 아니었습니다. 코드 컨벤션을 통일하고, 좋은 객체지향 프로그래밍을 위해 지켜야하는 원칙을 숙지하고, 어떻게 하면 더 클린 코드에 가깝게 코드를 작성할 수 있을지 매순간 고민했어야 했습니다.
첫번째 구현, 일단 동작하게 하자!
요구 사항이 이렇게 다양하고 엄격한 과제를 해보는 것은 처음이라 평소 습관처럼 일단 동작하는 숫자 야구 게임을 구현하려고 했습니다. 미션의 기능 요구 사항만 보고 구현하면서 그때그때 생각나는 클래스들을 생성하고, 메소드를 작성했습니다. 이 단계에서 저의 목표는 오로지 단 하나, '일단 잘 동작하는 쓰레기를 만들자!'였습니다. 아무리 예쁘고 예술적인 코드여도 동작하지 않으면 동작하는 쓰레기 코드보다 못하다는 말처럼, 1주라는 시간 안에 일단 동작은 하도록 만들고 싶었습니다.
중간 고사 기간과 겹쳐 조금 늦긴했지만 미션이 주어진지 3일만에 숫자 야구 게임의 첫번째 구현을 완료했습니다. 저는 기능 요구 사항은 충족했으니, 프로그래밍 요구 사항을 충족시키고자 리팩토링을 시도했습니다. 예상은 하고 있었지만 리팩토링을 시도하자마자 코드를 몽땅 갈아엎을 뻔 했습니다. 동작만하는 쓰레기는 쓰레기일 뿐이었습니다.
첫번째 구현 코드는 클래스끼리 너무 서로를 많이 의존하고 있어 서로의 역할과 책임이 모호했고, 단일 책임 원칙을 비롯한 여러 SOLID 원칙들을 위반하고 있었습니다. 객체지향 언어인 Java를 다루면서 전혀 객체지향답지 않은 코드를 작성했던 것입니다.
두번째 구현, 객체지향다운 클린 코드를 향해.
그래서 저는 클래스 설계부터 다시 시작했습니다. 그제서야 과제 진행 요구 사항에 기능을 구현하기 전, 구현 기능 목록을 먼저 작성하라는 항목이 있는 이유를 알게 됐습니다. 구현 기능 목록을 작성하면서 클래스 별로 맡을 역할과 책임을 먼저 생각해보고, 기존의 비대했던 클래스를 단일 책임만 가지는 작은 클래스들로 분리할 수 있었습니다. 역할과 책임을 가지는 객체들의 자율적인 협력 관계, 제가 아는 객체지향 프로그래밍이 설계된 순간이었습니다.
다시 설계한 구현 코드에서는 인스턴스 변수의 개수를 최대한 줄이고, 각 클래스들에게 하나의 역할만 부여했습니다. 또한, 우테코의 PR 체크 리스트를 참고해 코드 리팩토링에 집중했습니다. 리팩토링하면서 첫번째 구현 코드가 정말 지저분한 코드였다는 생각이 들자 리팩토링은 선택이 아닌 꼭 필요한 과정이라는 생각이 들었습니다. 처음 구현할 때는 꽤 멋진 코드라고 생각했던 제 자신이 조금 부끄러워졌습니다.
다음은 새로 설계하면서 클래스 별로 부여한 역할과 책임입니다.
Application:main메소드가 있는 곳으로GameController클래스를 통해 숫자 야구 게임을 시작하는 곳입니다.Command: 게임의 재시작 혹은 종료를 결정하는 명령어를 열거형으로 선언한 클래스입니다.Computer: 숫자 야구 게임에서 상대방 역할을 담당합니다. 임의의 3자리 숫자를 생성하고 이를 보관하면서 본인이 보관한 숫자에 대한 정보를 제공합니다.Game: 숫자 야구 게임에서 게임 한판 역할을 담당합니다. 사용자와 상대방으로부터 숫자에 대한 정보를 얻어 게임의 결과를 판단하고 이를 반환하는 기능을 제공합니다.GameController: 숫자 야구 게임에서 게임 진행자 역할을 담당합니다. 게임 결과에 따라 힌트를 제공하거나, 게임의 재시작 혹은 종료를 제어합니다.User: 숫자 야구 게임에서 사용자 역할을 담당합니다. 사용자가 입력한 3자리 숫자를 보관하고 해당 숫자의 규칙 위반에 대한 검증 기능을 제공합니다.GameView: 숫자 야구 게임에서 게임 진행 과정 출력 역할을 담당합니다. 야구의 전광판이라 생각하면 쉽습니다. 사용자가 실질적으로 보게 되는 인터페이스를 출력합니다.
회고하는 지금, 이 클래스 설계를 다시 읽어보니 더 세세하게 분리할 수 있었을 것 같아 아쉽지만 첫번째 구현보다는 확실히 객체지향다운 설계라고 생각합니다. 2주 차 미션에서는 이런 경험을 바탕으로 역할과 책임을 바탕으로한 클래스 설계부터 신중하게 할 예저입니다.
1주 차를 마치고
1주 차 미션은 그동안 간과했던 코드 컨벤션, 클린 코드와 객체지향다운 코드를 위한 원칙을 꼭 지켜야 했던 미션이었습니다. 저에게는 과제 자체의 알고리즘을 구현하는 것은 크게 어렵지 않았지만, 잘못 들였던 개발 습관을 고치는게 더욱 어려웠습니다. 특히, 단순한 알고리즘 문제 풀이를 생각하고 구현에만 치중하는 방식은 우테코에선 아무런 의미가 없다는 점이 신선한 충격으로 다가왔습니다.
제가 1주 차에 경험한 우테코는 빠른 결과보다 느리더라도 좋은 코드를 추구하는 과정 자체를 중요시하는 것 같습니다. 프리코스에 함께하는 많은 분들과 더 나은 코드를 위해 계속해서 토론하고 지식을 공유하는 프리코스 커뮤니티가 있는 이유도 아마 우테코의 철학을 가장 잘 활용할 수 있는 공간이기 때문이라고 생각합니다.
앞으로의 프리코스 미션에서는 클래스 설계에 많은 시간을 들이고, 어떻게 하면 더 객체지향다울 수 있을지 고민하는 과정 자체에 중점을 두고자 합니다.
