[우아한테크코스] 체스 미션 회고

체스

체스는 가로와 세로가 각각 8줄씩 64칸으로 격자로 배열된 체스보드에서 두 명의 플레이어가 기물들을 규칙에 따라 움직여 사우는 보드 게임이다. 플레이어는 킹, 퀸 각 1개, 룩 2개, 나이트 2개, 비숍 2개 그리고 폰 8개로 총 16개의 기물을 가지고 시작하고 피스 6종류는 각각 다르게 이동한다.

 

체스는 기물을 움직이는 일반적인 방법 외에도 캐슬링, 앙파상, 프로모션과 같은 변칙적인 방법으로도 기물을 움직일 수 있다. 하지만 이번 미션 요구사항에 그런 규칙까지 구현하는 조건은 없었기에 많은 것을 구현하기보다는 구현해야 하는 요구사항에 집중하기로 페어와 얘기 후 결정했다.

 

체스 게임을 해보기는 했으나 많이 접해보지 못하여 도메인에 대한 이해도가 낮았기에 페어와 직접 게임을 하며 도메인을 이해해 보기로 했다. 확실히 글을 통해 생각만으로 이해하기보다는 직접 해보며 이해하는 것이 훨씬 도메인을 이해하는데 용이했다. 진행한 체스 게임을 생각하며 기물들의 움직임을 어떻게 구현해 볼 수 있을지 그림을 그려가며 고민해 보았다.

체스판을 하나의 좌표계를 보고 기물은 좌표계를 이동한다고 보았을 때 몇 가지 규칙을 찾을 수 있었고, 이를 통해 사용자가 입력한 위치로 해당 기물이 이동할 수 있는지 판단하기로 페어와 얘기하였다. 체스 미션에서 기물의 움직임을 정의하는 게 가장 복잡한 작업이기에 그 후 작업은 생각보다 어렵지 않았다. 이후 아래와 같은 도메인 관계도를 만들어낼 수 있었다.

도메인 관계도

처음에는 기물을 추상 클래스로 두고 이를 상속하는 방법을 선택했지만 상속에 대해 공부한 뒤 pieceType을 조합하는 방법으로 수정하였다. 여기에서 상속에 대해 학습한 내용을 확인할 수 있다. 기물이 움직이는 방법에는 2가지 방법이 존재한다.

 

해당 위치로 바로 이동하는 DirectStrategy 방법(킹, 나이트, 폰)과 해당 위치까지 슬라이딩하며 쭉 나아가는 SlidingStrategy 방법(퀸, 룩, 비숍)이 있다. 전략은 이동하는 방향에 대한 벡터를 가지고 있기에 벡터만큼 이동하며 중간에 장애물이 존재하는지 확인할 수 있다.

학습했던 부분

컨트롤러 인터페이스

지금까지 미션은 뷰에서 단지 문자열에 대한 입력과 출력만 담당하게 되는 것으로 가정하고 진행했다. 체스 미션에서는 공통되는 것 같으면서 차이가 필요한 입력 형식이 있었는데 이에 대한 변환과 검증을 컨트롤러에서 진행했고 다음과 같은 리뷰를 받을 수 있었다.

 

🏀 리뷰어 완태의 리뷰

명령어를 입력하는 방식이 변경된다면, 예를 들어 소문자가 아닌 대문자로 입력받게 되거나 버튼 클릭 방식으로 입력을 받게 되면 어느 곳을 확인하고 어떤 방식으로 변경할 수 있을까요?

 

처음 질문을 받고 든 생각은 당연히 뷰 쪽 코드를 제일 처음으로 확인하게 될 것 같았다. 뷰 쪽 코드를 확인하게 되었을 때 생각했던 로직이 없어서 당황할 것 같았다. 이를 듣고 뷰와 컨트롤러 사이 매핑에 대해 다시 한번 생각하고 고민할 수 있었다. 추가로 다음과 같은 리뷰도 해주셨다.

 

🏀 리뷰어 완태의 의견

제 개인적인 생각을 남기자면, 컨트롤러는 인터페이스가 명확하게 정의되어 있고 다양한 형태의 뷰와 인터페이스를 구현해야 한다고 생각합니다. 여기서 말한 인터페이스는 개념적 인터페이스로 다양한 뷰가 추가되더라도 입력값을 강제할 수 있게 하는 것을 의미합니다.

 

실제로 도메인보다 뷰의 변화가 빠르기에 컨트롤러에서 인터페이스를 명확하게 정의해 둔다면 여러 뷰를 쉽게 갈아 끼울 수 있을 것 같았다. 리뷰를 통해 조금 더 확장성 있는 설계에 대해 고민하고 학습할 수 있었다. 새로운 변화를 시도해 볼 수 있었고 앞으로도 다양한 시도를 해보고자 한다.

의존관계 사이클

기물이 이동할 수 있는지 확인하기 위해서는 해당 위치로 기물이 갈 수 있는지, 해당 위치로 이동하는 동안 장애물이 없는지, 해당 위치에 우리 팀 기물이 없는지의 정보 확인이 필요하다. 기물에게 이동 여부를 물어보게 되는데 기물이 존재하는 위치 정보를 보드가 가지고 있기에 보드에서 다시 한번 확인해야 한다. 이때 리뷰어가 기물에게 한 번에 물어볼 수 있을 방법이 없을지 고민해 보라고 하셨고, 아래와 같은 의견을 작성하여 리뷰어에게 말씀드렸다.

 

기물이 스스로 판단하기 위해서는 보드를 기물에 넘겨야 합니다. 하지만 결국 보드로부터 기물 메서드 호출이 발생하기에 보드 -> 기물 -> 보드 순으로 의존관계가 발생하게 됩니다. 한쪽으로 흐르는 단방향 의존관계가 아닌 양방향 의존관계를 가지게 되는 경우 결합도가 높아지게 되어 확장성이 낮아지고 유지보수가 어려워지는 문제가 발생합니다.

 

이를 확인한 리뷰어의 답변은 아래와 같다.

 

🏀 리뷰어 완태의 의견

저도 보드 -> 기물 -> 보드 사이클이 우려스럽긴 합니다. 모든 구현은 트레이드오프이기 때문에 역할과 책임을 한 곳에서 관리하기 vs 의존성 사이클로부터 방어하기 사이에서 장단점을 확인해 보고 좋은 방법을 선택하면 된다고 생각합니다. 저라면 기물 스스로 책임을 다하는 방식으로 진행할 것 같습니다. 추가로 생각나는 아이디어는 보드의 스냅샷을 카피한 후 넘겨주는 것도 방법이 될 수 있을 것 같아요.

 

이를 듣고 의존관계를 해결하기 위한 새로운 방법을 알게 되었다. 보드를 그대로 넘기게 되면 보드가 가지고 있는 메서드를 사용할 여지가 있기에 의존관계 사이클의 위험이 존재한다. 기물이 필요한 정보는 보드 자체가 아닌 보드판에 대한 정보이기에 정보만을 카피해서 넘겨주는 것은 좋은 방법이 될 수 있었다. 모든 선택은 트레이드오프라는 것을 다시 한번 느낄 수 있었고 선택하더라도 단점을 보완하기 위한 방법을 찾아낼 수 있다는 것도 직접 확인할 수 있었다.

마치며

이번 체스 미션 페어는 메리였다. 메리는 같은 데일리 조였지만, 접점이 많지 않아 얘기를 많이 해보지 못했던 크루였다. 하지만 우연히 페어로 걸리게 되어 이번 미션을 통해 친해질 수 있을 것 같아 기대됐다. 처음 만나 아이스브레이킹을 하며 많은 얘기를 나눴는데 생각이 깊은 크루임을 알 수 있었다. 체스 도메인을 이해하기 위해 설계에 많은 시간을 투자하게 되었는데 개발을 진행하지 않았음에도 끝내지 못할 불안감이 들지 않았다. 오히려 탄탄한 설계를 하여 생각한 방향대로 개발을 진행할 수 있었고, 좋은 결과물을 만들어낼 수 있었다.

 

메리는 생각이 깊고 꼼꼼한 점이 강점이 되는 크루라고 생각한다. 나의 의견을 끝까지 경청하며 생각 후 의견을 말해준다. 이해하지 못한 내용이 있다면 다시 물어보고 이해가 될 때까지 노력하는 모습이 보기 좋았다. 페어 프로그래밍을 하는데도 능숙하여 좋은 페어 프로그래밍 문화를 만들기 위해 노력하고 집에 가서도 긴 시간 고민하여 좋은 아이디어를 가져와 설명하던 모습도 인상적이었다.

 

페어 회고를 진행하며 다즐은 리더형인 것 같다는 말을 듣게 되었다. 이끌기보다는 따르는 것이 편하다고 느꼈기에 리더형이라는 단어가 나한테 어색하고 낯설었다. 이유를 물어보니 모르는 내용이 있을 때 기다려주고 생각해 볼 수 있는 기회를 주었고 팀원을 성장시켜 줄 수 있는 좋은 동료가 될 것 같다고 답해줬다. 나에게 있어서는 평범하고 당연하다고 생각했던 것이 다른 사람의 관점에서는 새로운 해석으로 다가갈 수도 있겠다는 느낌이 들었다.

 

기술적으로 아무리 뛰어난 개발자라 하더라도 소통하지 않으려 한다면 같이 일하기 싫을 것이다. 요즘은 어떤 것에 대해 잘한다라는 말보다 함께 일하고 싶다는 말이 더 깊게 다가오는 것 같다. 혼자만 빛나서 주변의 빛을 상쇄시키기보다는 적당한 밝기로 조화로운 빛을 만들어낼 수 있는 개발자가 되고 싶다.