프로그래머스 데브코스 14주차 회고

서론

이번 주차에는 특별한 일들이 많았다. 하나씩 차근차근 있었던 일들을 정리해 볼 필요가 있었다.

프로젝트의 설계

먼저, 캐치테이블을 클론 코딩을 하기 위한 애플리케이션의 분석 및 erd 설계, 유저 스토리 정리가 마감이 되고 월요일 날 멘토님에게 컨펌을 받을 필요가 있었다.

 

캐치 테이블을 클론 코딩을 하기 위해 도메인을 분석하면서 나타나게 된 도메인은 7개 정도로 추려졌다. 하지만, 3주 동안의 클론 코딩을 진행하면서 7개의 모든 핵심 도메인을 구현한다는 것은 욕심이라고 생각이 들었고, 팀원들에게 다음과 같은 의견을 제시했다.

"캐치 테이블이라는 애플리케이션은 본래 어떤 것을 목적으로 만들어졌을까요? 제가 생각하기에는 손님과 점주간의 관계에 있어서 예약과 웨이팅이라는 서비스를 편리하게 제공하고자 하는 목적이 아니었을까? 생각이 들어요. 이를 제외한 다른 부가적인 기능들은 대부분 유저들에게 편의성을 제공하고, SNS처럼 공유하여 유저들과의 유대감을 높이고자 목적성이 많이 느껴졌어요. 이러한 측면에서 봤을 때 애플리케이션의 핵심 도메인인 예약과 웨이팅에 대한 핵심 로직을 구현하고 이를 고도화하는 작업은 어떨까요?"

다행스럽게도 팀원들 모두 비슷한 생각을 가지고 있었고, 이를 토대로 멘토님에게도 컨펌을 받았을 때 좋은 생각인 것 같다는 대답을 듣게 되었습니다. 하지만 애플리케이션을 분석하고 이를 토대로 설계를 진행하면서 간과했던 부분을 멘토님께서 잘 캐치를 해주셨습니다.

바로 객체지향적인 설계를 하기 위한 행동 기반으로 행위를 바라보고 필요한 데이터를 추가했어야 하는데 애플리케이션 그 자체를 바라보다보니 엇 이러한 데이터도 있네? 이런 데이터도 추가해야겠다.라는 관점으로 데이터 중심의 설계를 진행하게 된 것이다.

오브젝트를 읽으면서 주니어 단계에서 가장 실수하는 부분이라는 것을 공부를 했었는데 자연스럽게 동일한 실수를 범하고 있었다는 것을 깨닫지 못하고 있었다. 해당 피드백을 바탕으로 도메인들을 정리하고 객체 관계 그래프를 정리하고 이를 토대로 유저 스토리를 다듬게 되었다. 

 

확실히 위와 같은 방식으로 설계를 했을 때 행위 기반으로 도메인들이 어떻게 서로 얽혀있어야 하는지 어떤 메시지를 보내야 객체들이 적절한 행위를 할 수 있을지에 대해서 좀 더 와닿는 느낌이 들었다. 가장 많이 실수한다고 하는 부분이라고 하니 이러한 부분에 대해서 앞으로 성장해 나가면서 설계 시에 사고를 하고 있어야 한다는 생각이 들었다.

 

프로젝트를 처음 설계 할 때 어떻게 설계를 하고 진행해나가야 하는지를 1주일 간의 시행착오로 많이 배울 수 있는 부분이었다.

NHN 게임 서버 개발자 기술 면접

두 번째로는 NHN 기술면접에 합격했다는 소식이었다. 해당 내용에 대해서는 NHN 면접 회고를 통해서 따로 작성을 할 예정이다.

프로젝트 진행 간 팀원 간의 갈등

세 번째로는 프로젝트를 진행하면서 꼭 마주치게 되는 팀원 간의 의견 차이로 인한 갈등 상황이 될 것 같다. 이번 주에 있었던 주요 갈등 상황을 정리하면 다음과 같이 정리가 가능할 것 같다.

코드를 방어적으로 작성해야 하는가

첫 번째 갈등 내용은 코드를 방어적으로 작성하기와 빨리 기능부터 구현하기에 대한 측면이었다.

이 두 부분은 다음과 같은 상황으로 두 가지를 분류를 하고 있다.

방어적인 코드를 작성했을 경우

코드를 방어적으로 작성을 한다면 클라이언트가 코드를 작성하는 과정에 있어서 문제 사항이 줄어들게 되고, 유저들의 잘못된 동작으로 인한 프로그래머가 의도하지 않은 버그가 발생하는 것을 막아 제품의 안정성을 높일 수 있다는 부분이다. 프로그래머가 예상하지 못한 버그가 존재할 수도 있지만, 이전 프리팀의 멘토님께서 말씀해 주신 그러한 예외들을 고려하고 코드를 작성하는 것이 곧 실력이다.라는 말이 기억에 남았다.

방어적인 코드를 작성하지 않고 최대한 빠르게 기능을 구현하자.

기능을 먼저 최대한 빠르게 구현하여야 한다는 측면이다.

이 부분은 이전에 회고에서 CTO 님에게 질문드렸던 내용과 직결된다고 생각이 든다. 시장에서 해당 기능을 빨리 선점을 해야 한다면 코드를 방어적으로 작성을 하면서 클린 코드, 클린 아키텍처를 고려하기보다 빠르게 구현을 하는 것이 중요하다는 부분이다. 

 

하지만, 여기서 드는 생각은 빠르게 기능을 구현하다고 하더라도 유저가 느끼기에 버그들이 많으면 안 된다.라는 생각이 들었다. 발생할 수 있는 버그들에 대해서 (여기서 말하는 버그란 서비스에 치명적인 손해를 발생시킬 수 있는 버그에 해당한다.)는 프로그래머가 유저 스토리를 작성하고 적절한 테스트를 거친 이후에 서비스를 선보여야 한다고 생각이 들었다.

 

이렇게 적절한 테스트 없이 유저들의 기대를 높여서 시장에 빨리 출시한다면 이전에 한창 기대를 받던 게임 사이버펑크 2077이 생각이 난다. 유저들의 기대를 잔뜩 안고 게임이 출시되었는지 정말 셀 수 없는 버그들이 발생하여 많은 유저들이 욕을 하고 게임을 등 돌리게 되는 그런 상황을 본 기억이 있다. 이러한 경험을 실제로 눈으로 보니 개발을 할 때 이러한 테스트는 중요하다는 생각을 가지고 있었습니다.

 

하지만 팀원분께서는 이렇게 테스트를 하나하나 다 진행하다간 핵심 도메인에 대한 기능을 구현하지 못할 것이라고 판단을 하셨는지 우선 빨리 구현을 하고자 하는 방향으로 말씀을 해주셨는데, 이 부분이 확실히 서로 간의 가치관에 차이라고 느껴졌다. 개발자가 행해야 될 책임에 대해서 시간을 더 할애하여 유저들에게 개발자의 부족함을 유저에게 안긴다는 것은 정말 안된다고 생각이 들었고 다른 팀원 또한 동일한 생각을 가지고 있었다.

 

최종적으로는 저희가 시간을 더 할애하면서 유저에게 적절한 서비스를 제공하기 위해 더 고생을 할 필요가 있다. 이것이 개발자의 책무라고 생각한다.라는 방향으로 이야기가 진행되었고 현재 애자일로 스프린트를 만들어서 진행을 하고 있는 것처럼 금요일까지 1주일간 스프린트를 진행하면서 저희가 목표했던 바를 이루지 못했다면 그때 수정을 해도 늦지 않을 것이라는 내용을 같이 전달하였다. 

이것이 곧 우리가 스프린트를 하는 이유이자 스프린트의 장점을 활용하는 것이라는 생각이 들었다.

 

프로젝트를 진행하다 보면 이러한 트레이드오프가 존재하는 많은 갈등 상황이 존재할 것이라는 생각이 든다. 이러한 부분도 이전에 스크럼 마스터를 소개해주신 리더님에게 질문을 드렸었는데, 이러한 측면은 결국 경험을 통해서 해결이 가능하다는 말씀을 해주셨다. 나 자신도 이러한 경험들을 축적해 나가면서 기준을 정하는 것이 좋을 것 같다는 생각이 들었다. 만약 선배 혹은 시니어가 있다면 이러한 부분들을 상대적으로 더 빠르게 얻어 갈 수 있을 것이다.

 

이번 주에는 선택과 집중 측면에서 오는 수요일 진행 할 NHN 컬처 면접을 잘 준비해서 좋은 문화를 가지고 있는 회사에 취업을 꼭 하고 싶다는 생각이다. 내가 좋아하는 일에 대해서 책임감을 가지고 유저들에게 좋은 게임 서비스를 제공해 줄 수 있는 그런 현실이 찾아왔으면 하는 바람이다.