우아한 테크 켐프 7기 2주 동안의 여정

 

4월에 처음 알게된 우아한 테크 켐프라는 좋은 기회를 운 좋게 잡았고 현재 2주의 시간이 흘렀습니다. 처음은 어떤 사람들을 만날 수 있고 어떤 성장을 할 수 있을지가 매우 매우 기대가 되었죠. 그리고 2주가 지난 시점에서 어떤 과정을 진행해왔는지 내가 잘하고 있는 것은 무엇이고 더 잘할 수 있는 점은 무엇인지 천천히 회고를 하고자 합니다.

🎮1주차 미션

처음으로 마주친 미션은 체스 게임 구현이었습니다. 1단계부터 8단계까지 마치 게임처럼 미션이 구성이 되어있었고 하나씩 단계를 진행해가면서 추가되는 기능을 어떻게 하면 쉽게 적용할 수 있을 것인지를 고민하면서 진행했던 미션이었습니다. 저는 체스를 구현하기 위해서 3가지의 객체를 통해서 구현하기로 했습니다.

• 보드(Board)
  체스의 상태를 모두 관리하는 책임을 부여하여 체스 판 위에서 어떤 위치에 말이 존재하는지 그리고 체스에서 적용되는 규칙이 무엇인지를 알고 있는 객체입니다.
• 체스말(Piece)
  체스에서는 다양한 말이 존재하죠. 하지만 모든 말은 이동하고 공격할 수 있다는 공통된 규칙이 적용됩니다. 이러한 책임을 가지고 있는 추상 객체로서 사용했습니다.
• 규칙(Rule)
  다양한 체스말이 존재하는 것 처럼 다양한 규칙들이 존재합니다. 체스는 규칙이 정해져있어서 확장할 가능성이 없지만 새로운 규칙을 적용할 수 있다는 가정 하에 규칙이라는 객체를 추출하게 되었습니다.

일반 규칙을 적용해보자!

3가지 객체 중에서 가장 어려웠던 설계는 규칙이었습니다. 체스에서의 규칙은 어떤 말인지에 따라서 적용되는 규칙이 다르고 그 말이 이동하는 패턴이 정해져있다고 생각했습니다. 그래서 처음 설계한 규칙 인터페이스에서는 체스 말의 타입과 위치 정보를 입력 받고 이동이 가능한지를 판단하도록 구현하였습니다.

    /**
     * 구현된 체스 규칙에 맞는지 확인할 때, 사용합니다.
     * @param type 이동할 체스말의 타입을 나타냅니다.
     * @param from 이동할 체스말의 현재 위치를 나타냅니다.
     * @param to 이동할 위치를 나타냅니다.
     * @return 이동이 가능한 경우 true를 반환하고 이동이 불가능한 경우에는 false를 반환합니다.
     */
    public boolean accept(Type type, Location from, Location to){
        return true;
    }

간단한 이동과 공격을 구현할 때는 충분히 괜찮은 인터페이스였습니다. 하지만 앙파상, 케슬링, 승진과 같은 특수 규칙을 알게 되었을 때, 처음 설계한 인터페이스로는 기능을 구현할 수 없다는 한계를 마주하게 되었습니다.

특수 규칙을 구현을 하면서 개선하기

현재 체스 게임의 실행 로직은 사용자의 명령을 입력받고 게임의 명령을 실행하고 턴을 넘기는 실행 방식을 적용하고 있습니다. 하지만 승진과 같은 체스의 규칙을 적용하게 되면 이동이라는 명령을 수행한 이후에 같은 사용자에게 승진 명령을 입력 받아야하는 상황이 생겼습니다. 특정한 상황의 규칙을 수행하였을 때, 게임의 상태를 동적으로 변경하기 위한 방법을 고민하게 되었고 생각한 방식은 Event를 활용하자! 였습니다.

 

특정한 체스의 규칙이 성립하게 되면 적용할 이벤트를 생성하고 이러한 이벤트를 사후에 처리하는 로직을 적용하게 되었습니다. 이를 활용해서 복잡한 규칙에서 요구하는 사후 처리와 관련된 로직을 구현할 수 있게 되었습니다.

https://www.chess.com/ko/terms/castling-chess-ko

하지만 다음으로 마주친 어려움은 케슬링을 구현하면서 만나게 되었습니다. 케슬링은 킹과 룩을 스위치시키는 특수한 규칙입니다. 케슬링을 하기 위해서는 이동 경로가 체크를 당하면 안되고 룩이 한번도 움직이지 않은 상태이어야만 했습니다. 하지만 지금의 인터페이스는 게임의 상태를 확인할 수 없기 때문에 현재의 구조로는 구현을 할 수가 없었습니다.

처음 설계에서는 이동하는 체스 말의 위치 정보를 통해서 규칙을 구현할 수 있다고 생각했지만 복잡한 규칙을 구현하기에는 역부족이었습니다. 그래서 리펙토링을 수행하게 되었습니다.

    /**
     * 구현된 체스 규칙에 맞는지 확인할 때, 사용합니다.
     * @param type 이동할 체스말의 타입을 나타냅니다.
     * @param from 이동할 체스말의 현재 위치를 나타냅니다.
     * @param to 이동할 위치를 나타냅니다.
     * @param game 체스 게임 객체를 나타냅니다.
     * @return 이동이 가능한 경우 true를 반환하고 이동이 불가능한 경우에는 false를 반환합니다.
     */
    public boolean accept(Type type, Location from, Location to, Game game){
        return true;
    }

현재 체스 게임의 상태를 알기 위해서 게임의 상태를 모두 관리하고 있는 game을 새로운 인자로 받게 되었습니다. 특수 규칙 구현체에서는 게임의 상태를 보고 규칙이 적용될 수 있는지 여부를 판단 할 수 있도록 구현하게 앙파상과 캐슬링과 같은 특수 규칙을 구현할 수 있었습니다.

🤔 1주차 후기

1주차는 가벼운 마음으로 진행해도 괜찮다고 했지만 구현할 수록 유연한 구조를 만들고 싶은 욕심이 생기기도 하고 주위에서 열심히 고민하고 코딩하는 모습을 보니까 열심히 하게 되었던 1주일이었습니다. 계속해서 좋은 구조를 고민하고 리펙토링도 계속해서 했지만 코드 프리징 시점에서 보면 아직도 부족한 점이 눈에 많이 보여서 아쉬움이 많이 느껴졌던 1주일이기도 했습니다.

🕹️2주차 미션

2주차 미션은 WAS 만들기입니다. 하나씩 추가되는 요구사항을 구현하면서 순수한 자바로 WAS를 만들어보는 미션인데요. WAS는 써보기만 했지 만들 생각은 하지않아서 자극을 많이 주는 주제이기도 했습니다.

무엇을 학습할까?

WAS를 만들면서 학습할 수 있는 것은 무엇일까 고민하게 되었습니다. 우선 Http의 스텍을 구현하면 http에 대해서 좀 더 깊게 이해할 수 있는 좋은 기회이기도 하고 WAS의 구현에 대해서 깊게 이해할 수 있는 기회이기도 하다는 생각을 하게 되었습니다. 저는 이번 기회를 통해서 WAS의 구현에 대해서 깊게 이해하는 것을 목표로 두고 미션을 수행하기로 했습니다.

톰켓 커넥터

java에서 많이 사용되는 WAS로는 Tomcat이 있습니다. 톰켓은 어떻게 소켓을 관리하고 있는지가 먼저 궁금했습니다. 그래서 Tomcat의 구현을 참고하여 WAS를 구현하면서 톰켓이 어떻게 커넥션을 처리하는지를 이해하고자 했습니다. 미션의 제약사항으로는 java.nio 패키지를 사용할 수 없었기 때문에 NIO 방식의 커넥터를 참고할 수 가 없었습니다. 그래서 Tomcat 9 이후로는 Deprecated 된 BIO connector를 먼저 참고했습니다. JIOEnpoint의 구현을 살펴보면서 초기 톰켓이 어떻게 커넥션을 처리했는지 알 수 있었습니다. 이후에는 현재 톰켓이 사용하고 있는 NIO, NIO2 방식을 적용한 구현을 살펴보면서 어떻게 요청을 비동기 처리하는지 살펴볼 수 있었습니다.

Jar와 File class

Jar로 패키징된 리소스 파일을 읽을 때, 에러가 발생하는 상황을 마주치게 되었습니다. 문제의 원인은 Jar 내부의 파일을 File 클래스를 사용해서 읽었기 때문이었는데요. Jar로 패키징된 리소스는 압축된 파일이기 때문에 File을 이용해서 읽을 수 없다는 것이었습니다. 프레임워크의 도움을 받아서 리소스를 읽었기 때문에 이전에는 경험하지 못했던 에러였습니다.

🤔 2주차 후기

WAS를 구현하면서 HTTP의 스펙을 다시 한번 공부할 수 있는 좋은 기회였습니다. 그리고 특히 톰켓의 코드를 분석하면서 톰켓이 어떻게 동작을 하는지 알 수 있어서 좋았습니다. WAS 구현 미션은 총 3주간 진행이 되기 때문에 앞으로의 요구사항을 하나씩 구현하면서 톰켓을 좀 더 자세히 살펴볼 수 있을 것 같습니다.

🎉 회고

2주간 정말 시간이 빠르게 지나갔습니다. 2주간 최선을 다해서 성장하기 위해서 고민하고 구현하고 토론해서 시간이 빨리 갔나? 생각이 들기도 하네요.

2주 회고글을 작성하면서 이번 기회를 통해서 얻을 수 있던 장점은 무엇일까? 그리고 2주간 아쉬운 점은 무엇일까? 생각을 해보았는데요.

😄좋은점

우아한 테크 켐프에서 좋은 점 중에 하나는 많은 소통을 경험할 수 있다는 점입니다. 2주간 이렇게 많은 소통을 할 수 있나? 생각할 정도로 많은 대화를 나누었던 것 같네요. 같은 미션을 수행하면서도 중요하게 생각하는 점, 구현 방식 등 다양해서 더 재미있게 활동할 수 있던 것 같습니다.

또다른 좋은 점은 위키입니다. 위키를 통해서 학습한 자료와 회고록 등을 공유하고 있는데 이런 문서를 읽으면서 서로 다른 생각이나 지식을 얻을 수 있다는 점은 빼놓을 수 없는 장점이네요. 저도 좋은 영향을 많이 미치고 싶어서 위키를 작성할 때, 좀 더 많은 시간을 들여서 작성하려고 노력하고 있습니다!

미니 스쿼드 세션도 좋은 점 중에 하나입니다. 매주 금요일 마다 2명씩 자유로운 주제로 발표를 하고 있는데요. 매번 새로운 내용의 발표를 들을 수 있어서 재미있고 유익한 시간이라고 느껴졌던 것 같습니다. 2주 동안 4번의 세션 모두 흥미러워서 앞으로의 16명의 발표를 기대하고 있습니다!

🤒아쉬운 점

아쉬웠던 점은 코드 리뷰가 힘들었다는 점이 아쉬운 점이라고 생각이 들었습니다. 주에 2번 정도는 랜덤하게 조를 편성해서 그 동안 수행한 과제에 대해서 리뷰를 하는 활동을 가졌는데요. 코드 리뷰에 대해서 미숙한 부분이 있기도 하고 리뷰해야할 코드의 사이즈가 크기도 해서 질 좋은 코드 리뷰를 만들기가 힘들었습니다. 좋은 코드 리뷰에 대해서는 좀 더 고민하고 개선해야겠다는 생각을 했습니다. 다음 주에는 구현을 시각화해서 이해를 돕도록 개선하고자 합니다!

🏃앞으로!!

여기까지 2주간의 여정을 한번 정리해보았습니다. 앞으로 남은 8주간의 여정도 모두들 힘내서 파이팅했으면 좋겠습니다!!