# 11 - 아키 텍 쳐 
 design patterns 	 ( 12 ) 
 # 10 - 정말 큰 문제 들 해결 . . 
 좋 은 글 감사 합니다 . ㅎㅎ 
 # 11 - 아키 텍 쳐 본문 
 devtimothy 2019 . 04 . 15 09 : 05 
 우리 는 큰 문제 를 작 은 기능 들 의 조각 으로 나누 었 고 , 작 은 조각 에 대해서 는 해결 방법 을 알 고 있 다 . 그러나 유스 케이스 다이어그램 과 특징 리스트 , 그 외 에 도 고려 해야 할 사항 이 많 다 . 처음 에 우리 는 무엇 을 해야 할까 ? 당연 하 게 도 요번 챕터 주제 와 같이 아키 텍 쳐 가 필요 하 다 . 
 아 키 텍 쳐 는 시스템 의 분할 , 나뉜 부분 들 사이 의 연결 과 상호 작용 메커니즘 , 그리고 시스템 의 디자인 에 사용 된 원리 와 결정 사항 들 을 담 고 있 는 시스템 의 구조 를 말 한다 . 
 아 키 텍 쳐 는 디자인 의 구조 이 고 , 프로그램 의 가장 중요 한 부분 들 과 그 들 사이 의 관계 를 명확히 보여 주 며 , 뒤죽박죽 복잡 한 내용 을 잘 정리 된 프로그램 으로 바꾸 는데 도움 을 준다 . 
 우리 가 1 장 에서 말 했 던 < 쉬운 3 단계 로 좋 은 소프트웨어 만들 기 > 를 여기 서 도 적용 가능 하 다 . 
 첫째 단계 는 < 고객 이 원 하 는 기능 을 하 도록 하 라 > 이 다 . 특징 리스트 를 잠시 살펴보 자 
 게임 시스템 프레임 웍 특징 리스트 
 1 . 다양 한 타입 의 지형 을 지원 한다 . 
 2 . SF 소설 이나 판타지 소설 에 등장 하 는 가상 의 시대 를 포함 한 다양 한 시대 를 지원 한다 . 
 3 . 게임 특성 에 맞 는 여러 타입 의 부대 또는 유닛 들 을 지원 한다 . 
 4 . 새로운 작전 수행 이나 전쟁 시나리오 를 위한 추가 모듈 을 지원 한다 . 
 5 . 사각형 의 타일 들 로 구성 된 보드 를 제공 하 고 각 타일 은 지형 타입 을 가지 고 있 는다 . 
 6 . 누구 차례 인지 에 대한 정보 를 유지 한다 . 
 7 . 기본 적 인 이동 을 관장 한다 . 
 이 중 에서 뭐 가 가장 중요 할까 ? 어디 서 부턴가 는 먼저 시작 해야 한다 . 구성 요소 가 없 는데 시스템 구성 요소 사이 의 관계 에 대해 논하 기 란 어렵 다 . Board 와 Units 모듈 이 어떻게 상호 작용 하 는지 알 고 싶 다면 ? 먼저 는 기본 적 인 내용 을 먼저 알 아야 할 것 이 다 . ) 물론 관계 에 대해 알아내 는 것 만 이 가장 중요 한 일 은 아니 다 . ) 
 아키 텍 쳐 에 대한 세 가지 질문 
 시스템 의 본질 이 되 는 부분 인가 ? 
 그 특징 이 시스템 의 핵심 인가 ? 
 이것 은 " 도대체 " 무슨 의미 인가 ? 
 무슨 뜻 인지 확신 이 서 지 않 는다면 그 특징 에 대해 관심 을 기울이 라 . 
 확실 치 않 은 일 은 오래 걸리 고 , 시스템 의 나머지 부분 을 발목 을 잡 을 수 있 다 . 
 도대체 어떻게 해야 하나 ? 
 구현 하 기 까다로운 문제 가 있 다면 , 시간 을 들여 문제 발생 을 막 는다 . 
 위 세 가지 질문 을 보 았 다면 , 무엇 이 중요 한지 살펴보 자 . 
 게임 을 위한 보드 - 1 
 게임 특유 의 유닛 - 1 , 2 
 프레임 웍 은 기본 적 인 이동 을 관장 한다 . - 3 
 시스템 의 본질 
 시스템 의 본질 이란 가장 기본 적 인 수준 이 완성 되 었 을 때 를 말 한다 . 우리 가 부가 적 으로 넣 은 화려 한 기능 이나 아이디어 가 본질 은 아니 다 . 특징 을 찾 을 때 는 " 이 특징 이 구현 되 지 않 으면 시스템 이 해야 할 일 을 정말 하 는 걸까 ? " 라는 답 에 " 아니 요 " 라고 답 한다면 본질 적 인 특징 을 찾 은 것 이 다 . 쉽 게 말 하 자면 , " 잘 돌 아 가 는가 ? " 부터 확인 하 는 것 이 다 . 
 나 의 개발 이야기 를 잠깐 하 자면 , 나 는 레스토랑 예약 서비스 를 운영 하 는 스타트업 에서 일 하 고 있 다 . 어느 날 음식 을 먹 으러 갔 다가 음식점 앞 에 대기 리스트 적 는 판 이 있 는 것 을 보 고 우리 서비스 에 적용 하 면 좋 겠 다는 생각 이 들 었 다 . 가장 먼저 했 던 일 은 대기 등록 용 앱 을 만드 는 일 이 었 는데 , 정말 간단 하 게 앱 을 만들 었 다 . 
 손 님 이 대기 등록 을 하 게 한다 . ( 이름 , 전화 번호 , 인원 수 ) 
 매장 관리자 앱 과 대기 등록 앱 이 실시간 으로 목록 이 갱신 되 게 한다 . 
 차후 에 는 여러 가지 기능 이 무궁무진 하 게 많 아 졌 지만 … 최소한 의 조건 을 맞추 어 개발 을 했 던 기억 이 있 다 . 초기 단계 에서 는 시스템 이 어떻게 발전 할지 몰라 세부 적 인 것 을 만드 는 것 을 자제 하 기 도 했 다 . 시스템 의 전체 를 보 기 위함 이 다 . 
 특징 리스트 가 있 다고 하 더라도 결정 하 기 애매 한 것 들 이 많이 있 을 것 이 다 . 비록 시스템 을 직접 작성 해 보 진 않 았 더라도 우리 가 어떻게 해야 할지 모르 는 것 은 아니 다 . 새로운 세부 사항 이 있 는 것 뿐 이 다 . 그러나 가령 멀티 쓰레드 를 이용 한 채팅 서버 구축 을 해야 하 는데 , 쓰레드 와 네트워크 프로그래밍 에 대해 잘 모른다면 , 이 는 어떻게 해야 할지 모르 는 것 이 다 . 
 애매 한 것 들 이 많이 있 겠 지만 , 어찌 됐 건 우리 가 가장 먼저 해야 할 일 은 익숙 한 부분 부터 찾 아서 시작 하 는 것 이 다 . 
 위험 요소 를 줄여라 
 게임 을 위한 보드 
 게임 특유 의 유닛 
 프레임 웍 은 기본 적 인 이동 을 관장 한다 . 
 여러 과정 을 거쳐서 우리 는 위 세 가지 가 중요 한 특징 임 을 확인 했 다 . 그렇 다면 뭐 부터 만들 어야 할까 . 다 중요 해 보이 면 어쩌 지 ? 혹은 사람 들 마다 중요 하 게 여기 는 게 다르 다면 어떻게 해야 할까 ? 
 중요 한 것 은 위험 요소 를 줄이 는 방향 으로 진행 하 는 것 이 다 . 위험 요소 를 최소 화 하 려면 Board 인터페이스 부터 작성 하 는 게 좋 겠 다 . 
 보드 의 높이 와 너비 는 게임 설계자 가 제공 한다 . 
 보드 는 주어진 위치 에 있 는 타일 을 반환 한다 . 
 유닛 들 을 타일 에 추가 하 고 , 주어진 x , y 위치 에 있 는 모든 유닛 들 을 반환 한다 . 
 Board . ts 클래스 를 새로 만든다 . 
 Board 에서 너비 와 높이 를 받 아서 새로운 보드 를 만드 는 생성자 를 추가 한다 . 생성자 는 보드 를 사각형 타일 들 로 x , y 위치 에 하나 씩 채운다 . 
 타일 의 x , y 위치 가 주어지 면 주 어 진 위치 에 있 는 타일 을 반환 할 메소드 를 작성 한다 . 
 타일 의 x , y 위치 에 맞 게 유닛 을 추가 하 는 메소드 를 작성 한다 . 
 주어진 x , y 위치 에 있 는 타일 위 의 모든 유닛 들 을 반환 하 는 메소드 를 작성 하 라 . 
 위 요구사항 은 상식선 에서 보강 한 내용 이 다 . 그러나 경계 해야 할 것 은 너무 구체 적 인 내용 까지 는 생각 하 지 않 는 것 이 다 . 너무 깊이 세세 한 내용 까지 파고들 면 좋 은 유스 케이스 를 뽑아내 는데 도움 이 되 질 않 는다 . 
 시나리오 들 이 위험 요소 를 줄이 는 데 도움 이 많이 된다 . 사실 많 은 사람 들 이 유스 케이스 작성 에 그렇게 공 을 들이 지 는 않 는다 . 예약 서비스 를 개발 한다고 생각 해 보 면 , 간단 하 게 생각 할 때 는 고객 이 예약 을 한다 . 예약 을 할 때 는 이름 , 전화 번호 , 인원 수 를 입력 한다 . 정도 이 지만 , 사실 예약 경로 가 다른 루트 로 들어올 수 도 있 다 . 인 스타 그램 DM , 전화 , 블로그 , 카톡 등 … 전화 번호 를 모르 지만 예약 은 등록 해야 하 는 경우 가 생길 수 있 다 . 
 지금 우리 는 보드 를 만들 고 있 고 , 여기 서 는 보드 가 어떻게 사용 되 는지 를 생각 할 수 있 다면 더 좋 을 것 이 다 . 가령 8 X 10 칸 의 보드 에서 1 , 3 위치 에 있 는 부대 가 4 , 5 위치 에 있 는 부대 를 친다 등 의 내용 들 을 나타낼 수 있 겠 다 . 아마 지금 내 가 생각 지 못한 다양 한 이슈 들 이 있 을 것 이 다 . 
 시나리오 를 작성 하 면 유스 케이스 는 필요 가 없 을까 ? 그렇 지 는 않 다 . 시나리오 는 빠르 게 문제 를 해결 할 때 보편 적 인 요구사항 을 찾 는데 도움 이 된다 . 그러나 이 는 유스 케이스 를 이용 할 하나 의 경로 일 뿐 이 다 . 위험 요소 를 줄이 는 데 는 고객 에게 좋 은 요구사항 을 뽑아내 는 것 이 다 . 
 우리 는 시나리오 를 이용 해서 모듈 이나 코드 조각 의 기초 적 인 내용 을 이해 하 고 , 앱 의 기본 적 인 부분 들 을 채워 나갈 수 있 다 . 자 , 그러면 시나리오 를 한번 작성 해 보 자 . 
 보드 시나리오 
 게임 설계자 가 높이 와 너비 를 가지 고 보드 를 생성 한다 . 
 플레이어 2 가 탱크 들 을 4 , 5 로 옮긴다 . 
 플레이어 2 가 군대 를 4 , 5 로 이동 한다 . 
 플레이어 1 이 포병 을 4 , 5 로 이동 한다 . 
 게임 이 4 , 5 의 유닛 들 을 요구 한다 . 
 플레이어 1 과 플레이어 2 가 전쟁 을 치른다 . 
 게임 이 4 , 5 의 지형 을 요구 한다 . 
 플레이어 2 의 유닛 이 전쟁 을 승리 한다 . 
 플레이어 1 의 유닛 들 이 4 , 5 에서 제거 된다 . 
 플레이어 1 이 잠수함 을 2 , 2 로 이동 한다 . 
 게임 이 2 , 2 에 있 는 지형 을 요구 한다 . 
 코드 구현 
 코드 를 여기 에 놓 자 
 배열 의 배열 을 사용 하 면 사각형 보드 판 만 써야 하 는 거 아니 냐 ? 그래프 자료 구조 나 좌표계 클래스 는 왜 안 사용 하 냐 ? 라고 생각 할 수 도 있 겠 다 . 유연 성 을 생각 한다면 좋 은 생각 이 지만 , 요구사항 에 맞춰서 작성 할 했 을 뿐 이 며 , 또한 필요 이상 의 복잡 한 방법 을 쓰 지 는 않 았 다 . 
 Tile 과 Unit 을 너무 완벽 하 게 만들 고자 하 지 말 자 . 우리 가 고민 할 내용 은 Board 클래스 를 만들 어 주요 특징 들 이 작동 하 게 하 는 일 이 다 . 
 Tile 클래스 가 유닛 추가 / 삭제 를 , Board 가 getTile ( ) 메소드 를 이용 해 타일 을 반환 할 수 있 는데 왜 addUnit , removeUnit 메소드 를 Board 에 추가 할까 ? getTile 을 호출 해서 Tile 이 알 아서 하 면 안 될까 ? 
 Unit 관련 오퍼레이션 이 getTile ( ) 을 통해 반환 되 는 Tile 객체 들 을 통해 해결 할 수 있 다 . 
 우리 는 Unit 관련 메소드 들 을 Board 에 추가 하 기 로 하 고 , Board 가 게임 설계자 의 시작점 이 되게 하 기 로 했 다 . 
 Tile 메소드 들 을 protected 로 선언 했 고 , Tile 과 같 은 패키지 의 클 래스 들 만 이 addUnit , removeUnit 메소드 를 직접 호출 할 수 있 다는 것 을 알 게 될 것 이 다 . 그래서 Board 객체 를 이용 해서 타일 , 유닛 , 지형 을 조작 하 게 됐 다 . 
 지금 은 시스템 프레임 웍 전체 를 코딩 하 려고 하 는 것 이 아니 다 . 핵심 특징 을 나누 고 , 프로젝트 주요 위험 요소 를 줄이 는 것 을 선행 한다 . Unit 클래스 와 Tile 클래스 를 작성 하 는 데 시간 들이 는 것 이 위험 을 줄이 는 데 도움 이 되 지 않 을 것 이 다 . 시스템 의 핵심 이 자 프로젝트 성패 가 달려 있 는 곳 이 라고 결정 한 부분 이 Board 클래스 니까 , Board 가 동작 하 는 데 충분 한 만큼 만 Unit 과 Tile 에 신경 쓰 자 . 
 큰 위험 요소 를 줄이 거나 없애 고 난 후 에 는 Unit 클래스 와 같 은 작 은 특징 에 신경 을 쓸 시간 이 많 아 진다 . 
 좀 더 질서 있 게 , 덜 혼란 스럽 게 
 게임 시스템 프레임 웍 핵심 특징 
 1 . 게임 읠 위한 보드 - 시스템 의 본질 
 2 . 게임 특유 의 유닛 - 본질 , 이것 은 무슨 의미 지 ? 
 3 . 이동 관장 - 이것 은 뭐 고 , 어떻게 하 지 ? 
 이제 구조 도 갖추 었 겠 다 , 클래스 간 에 어떻 게 조화 되 는지 생각 해 보 자 . 
 Board 는 Tiles 다 차원 배열 을 통해 Tile 을 소유 하 고 , Tile 을 Unit 을 소유 한다 . Board 는 Unit 타입 에 대한 변수 는 가지 고 있 지 않 지만 , Unit 객체 를 받아들이 는 메소드 들 이 연결 되 어 있 어서 Unit 클래스 와 연결 된다 . 
 Unit 클래스 도 준비 되 었 고 , 게임 특유 의 유닛 들 에 대해 해결 해 보 는 건 어떨까 ? Board 와 Unit 간 상호 작용 이 일어나 는지 도 볼 수 있 다 . 
 가능 하 면 이미 만들 어 진 내용 을 기초 로 만들 라 . 요구사항 과 다이어그램 만 있 을 때 는 무엇 부터 할지 선택 해야 한다 . 그러나 코드 와 클래스 가 있 으니 , 이미 만든 것 과 관련 된 핵심 특징 을 선택 하 는 것 이 쉬운 선택 일 것 이 다 . 
 아 키 텍 쳐 는 디자인 의 구조 이 고 , 프로그램 의 가장 중요 한 부분 들 과 그 들 사이 의 관계 를 명확히 보여준다 . 
 유닛 에 대한 정의 
 게임 특유 의 유닛 들 에 대해 이해 하 려면 , 게임 설계자 와 이야기 하 는 것 이 가장 좋 겠 다 . 유닛 에 대해 다음 같 은 내용 들 이 피드백 되 었 다 . 
 공격 치 
 방어 치 
 무기 착용 
 캐릭터 간 의 관계 
 군대 , 우주선 , 비행기 … . 
 프레임 웍 에 기반 한 각 게임 은 다른 종류 의 유닛 들 이 있 고 , 유닛 들 은 다양 한 속성 과 능력 을 갖추 고 있 다 . 그래서 각 게임 마다 유닛 에 대해 속성 들 을 가질 수 있 어야 하 고 , 그러 한 속성 들 에 대한 여러 데이터 타입 을 지원 할 수 있 어야 한다 . 
 그렇 다면 다양 한 타입 의 유닛 들 중 에 무엇 이 공통점 일까 ? 모든 유닛 타입 에 적용 되 는 기본 적 인 내용 에 는 무엇 이 있 을까 ? 
 유닛 들 도 다양 한 속성 을 가지 고 있 을 것 이 다 . 그렇 다면 , 앞서 서 기타 상점 프로그램 을 짤 때 처럼 , 기타 , 만돌린 등 으로 여러 개 의 클래스 로 쪼개 는 것 이 좋 은 디자인 일까 ? 유닛 수 가 100 개 , 200 개 늘어난다면 ? 관리 가 어려움 이 있 을 것 이 다 . ( 스타크래프트 만 해도 유닛 수 가 엄청 많 지 않 는가 . ) 
 좋 은 디자인 은 항상 위험 을 줄여 준다 . Unit 클래스 에 디자인 하 는 가장 좋 은 방법 을 찾 음 으로써 , 처음 부터 잘 만들 수 있 다 . 전체 시스템 에 깊숙히 들어가 작업 해서 타 코드 에 영향 주 는 Unit 클래스 에 수정 을 가해야 하 기 전 에 , 게임 특유 의 유닛 들 이 무엇 인지 알아냈 을 뿐 아니 라 , 기본 적 인 Unit 클래스 를 정의 하 고 , 프로젝트 진행 중 에 별다른 변경 없이 Board 클래스 와 같 은 다른 클 래스 들 과 연결 될 수 있 다 . 
 아 키 텍 쳐 핵심 은 위험 을 줄이 고 , 질서 를 잡 는 일 이 다 . 
 ( 최근 에 작업 했 던 알림 톡 템플 릿 전송 기능 의 경우 에 도 기존 에 잘 설계 했 더라면 주말 에 개고생 하 는 일 이 없 었 을 텐데 … 정말 최신 유행 하 는 기술 서 보 는 것 보다 중요 한 게 이런 기본 서 들 을 찾 아 읽 는 것 인 듯 하 다 . 왜 늘 나 는 사고 가 터진 후 에 이런 깨달음 을 얻 게 되 는 건가 ㅠㅠ ) 
 우리 는 코딩 을 한 부분 도 있 고 , 안 한 부분 도 있 다 . 시스템 의 기본 적 인 이해 가 필요 해서 코딩 이 필요 한 경우 가 있 다 . 그러나 모든 것 들 의 우선 순위 는 프로젝트 의 위험 도 를 줄이 기 위함 임 을 기억 하 자 . 
 고객 과 이야기 하 는 것 이 능사 는 아닐 수 있 지만 , 우리 가 개발 하 고자 하 는 것 이 무엇 인지 목표 를 명확히 한다면 우리 를 혼란 스럽 게 하 는 것 은 잘 걸러낼 수 있 다 . 
 객체 지향 분석 설계 는 많 은 코드 가 관련 된 것 은 아니 다 . 가끔 은 가장 좋 은 소프트웨어 작성 은 코드 작성 을 피하 는 일 일 수 도 있 다 . 
 ( 개발 하 면서 기존 에 있 는 기능 들 을 운영 적 으로 풀어내 면서 문제 를 해결 하 게 되 는 경우 가 있 다 . ) 
 이동 관장 
 특징 에 대해 무슨 말 인지 이해 가 가 지 않 을 때 는 고객 에게 직접 물 어 보 는 게 최고 다 . 각 유닛 이 얼마나 많 은 칸 을 움직일 수 있 는지 에 대한 이동 속성 을 가지 고 있 고 , 게임 은 지형 을 확인 해서 이동 이 가능 한지 확인 한다 . 여기 서 더 복잡 한 계산 으로 나아간다면 , 비행기 가 건물 을 통과 해서 날아간다 던지 , 비행기 의 속도 가 바람 의 영향 을 받 는다던지 하 는 것 도 생각 할 수 있 다 . 
 이동 에 대해서 기본 적 으로 느껴 지 는 공통점 이 있 는가 ? 그 특징 을 어떻게 시스템 에 녹여낼 것 인가 ? 
 유닛 들 은 한 타일 에서 다른 타일 로 이동 할 수 있 어야 한다 . 
 이동은 계산 이나 , 각 게임 특유 의 알고리즘 을 근거 로 하 며 , 가끔 유닛 의 게임 특유 의 속성 들 과 관련 된다 . 
 이동 전 에 , 움직임 이 가능 한지 를 확인 한다 . 
 유닛 의 속성 들 은 유닛 이 얼마나 멀리 갈 수 있 는지 를 확인 하 는 데 이용 된다 . 
 유닛 이외 의 요소 도 이동 에 영향 을 준다 . 
 이 동의 합법 성 을 확인 하 는 알고리즘 은 게임 마다 다르 다 . 
 사용 되 는 속성 의 수 나 이동 에 영향 을 주 는 요소 들 은 게임 마다 다르 다 . 
 이동 에 영향 을 주 는 요소 는 게임 마다 다르 다 . 
 결국 은 게임 마다 다르 다 라는 결론 이 섰 다 . 이동과 관련 된 내용 은 게임 설계자 에게 맡겨야 하 는 듯 하 다 . 불 확실 성 이 높 기 때문 이 다 . 공통점 으로 는 이론 상 Movement 인터페이스 를 만들 어 MovementAlgorithm 과 LegalMovement 같 은 객체 를 받아들이 는 move ( ) 메소드 를 정의 할 수 있 다 . 그러면 각 설계자 는 이 를 상속 받 아 확장 할 수 있 다 . 
 좋 은 코드 는 잘 설계 되 고 , 의도 된 대로 작동 한다 . 좋 은 소프트웨어 는 잘 설계 되 고 , 스 케 쥴 에 맞 게 제작 되 며 , 고객 이 원 하 는 기능 을 한다 . 이게 아 키 텍 쳐 가 필요 한 이유 다 . 
 우리 는 먼저 Board 를 위한 기본 클 래스 들 을 도출 했 고 , 고객 에게 잘못 된 보드 를 만들 어 주 는 위험 을 줄이 기에 충분 한 코드 를 작성 했 다 . 그 다음 으로 는 유닛 에 대해 정의 하 고 , 클래스 다이어그램 을 이용 해 어떻게 문제 를 해결 할지 계획 했 다 . 마지막 으로 , 이동 을 다룸 으로서 게임 설계자 가 고민 할 내용 이 무엇 인지 생각 해냈 다 . 
 많 은 코드 를 작성 하 진 않 았 지만 , 제 때 에 제대로 된 기능 의 소프트웨어 를 만들 수 있 다고 확신 하 는 프로젝트 가 되 었 다 . 
 다음 장 에서 는 디자인 원리 들 에 대해서 알아보 자 . 
 구독 하 기 공부 하 는 블로그 
 ' design patterns ' 카테고리 의 다른 글 
 # 11 - 아키 텍 쳐 ( 0 ) 
 # 10 - 정말 큰 문제 들 해결 하 기 ( 0 ) 
 # 7 - 분석 : 내 가 만든 소프트웨어 를 실제 세상 으로 ( 2 ) ( 0 ) 
 # 7 - 분석 : 내 가 만든 소프트웨어 를 실제 세상 으로 ( 0 ) 
 ' design patterns ' Related Articles 
 # 10 - 정말 큰 문제 들 해결 하 기 2019 . 04 . 11 
 # 7 - 분석 : 내 가 만든 소프트웨어 를 실제 세상 으로 ( 2 ) 2019 . 03 . 29 
 Prev 1 2 3 4 5 · · · 38 Next