알아두면 편리한 테스트 업무 관련 용어들 (Q ~ Z)

 * RAM

: 프로그램을 RAM에 올리고 실행시킴. RAM이 크면 프로그램을 한 번에 여러 개 돌릴 수 있음. 가용 메모리

* Regression Test

: 회귀 테스트

: 소프트웨어를 수정한 후 과거에 고쳐던 버그가 다시 살아나는 것을 Regression Bug(회귀 버그)라고 하며, 그 버그를 찾는 테스트를 의미함.

* SaaS (Software as a Service)

: 서비스로서의 소프트웨어

: 소프트웨어를 제공하는 클라우드

: 소프트웨어 사용자용

* SB (Story Board)

: 개발에 필요한 정보가 들어있는 설계서

: 협업을 위한 소통 도구로 주요 사용. 예시 이미지와 함께 구현되어야 할 항목에 대한 자세한 설명을 적음.

: 원래는 영상을 제작하기 위한 용도로 작성되는 문서 (콘티)

* SI (System Integration)

: 전산시스템을 필요로 하는 곳으로부터 하청을 받아, 시스템의 기획/개발/유지보수/운영등을 대신 해주는 업종

: 갑 (발주사, 고객사) - SI 프로젝트를 발주하는 회사

: 을 (수행사) - SI 프로젝트를 수주하는 회사. 큰 규모의 SI업체 (삼성SDS, LG CNS, SK C&C 등)가 주로 해당

* SLO (Single Logon)

: SSO와 다르게 시스템 각긱이 개별 쿠키나 세션을 가지고 인증

: 계정 정보가 하나의 시스템에 존재하고, 각각의 시스템에는 서로 별도의 인증 부분이 존재 (ex. Mail.naver.com에 로그인 시 blog.naver.com에도 로그인 됨)

* Smoke Test

: 스모크 테스트

: 새로운 빌드를 만든 후 테스트를 진행하기에 앞서 해당 빌드가 정식으로 테스트 받을 만한 가치가 있는 것인지 검증하는 테스트.

: 주요 단위 모듈이나 시스템 모듈을 독립된 QA팀 또는 개발팀 내의 테스트팀이 주체가 되어 테스트 케이스 없이 시행. 테스트 환경을 처음 구축할 때 끝단(end-to-end)까지 점검하여 테스트 환경 자체에 문제가 없는지 확인한 다음 이상이 없을 때 실시.

* SMS (System Management System)

: 시스템 관리 시스템

: 여러 지역에 분산되어 있는 각각의 서버/프로그램을 통합적으로 관리해 주는 시스템

* SNB (Side Navigation Bar)

: 주로 왼쪽에 위치한 네비게이션 바 - 사이드 메뉴, 기타 메뉴

* SPA (Single Page Application)

: 최초 한번 전체페이지를 다 불러오고 응답데이터만 페이지 특정부분 렌더링

* Spotbugs

: Java에서 버그 패턴을 찾기 위해 사용하는 정적분석 소프트웨어

: 보안약점을 진단할 수 있음

* Spring

: 자바를 쉽게 쓸 수 있게 도와주는 프레임워크 (메서드, 클래스, I/F 등등 가져다가 사용하면 됨)

* SSO (Single Sign-On)

: 통합 인증

: 한 번의 로그인으로 여러 개의 다른 사이트들도 로그인 없이 이용하는 방법(자동 접속)

: 그룹웨어 서비스 (ex. Tistory.com 로그인 시 naver.com에도 로그인 됨)

* SSR (Server Side Rendering)

: 전통적인 웹 애플리케이션 방식. 요청시마다 서버에서 처리한 후 새로고침으로 페이지에 대한 응답

* Stress Test

: 각종 극한 상황을 테스트 해보는 것

* STS (Spring Tool Suite)

: 이클립스 (혹은 Visual Studio Code 또는 Theai)기반의 스프링에 최적화된 IDE

* Swegger

: 개발자가 REST API웹 서비스를 설계, 빌드, 문서화, 소비하는 일을 도와주는 프레임워크

: 다른 개발팀과 협업할 때 / 이미 구축되어 있는 프로젝트를 유지보수할 때 / 백엔드의 API를 호출하는 프론트엔드 프로그램을 제작할 때 유용함

* Syndication

: 원래 검색로봇이 해야 하는 일을 신디케이션 API라는 규약을 통해서 개별 웹사이트가 일을 대신하는 것

: 개별 웹사이트에서 콘텐츠가 신규 생성될 때, 개별 웹사이트에서 ping을 날려서 검색 사이트에서 검색에 반영될 수 있도록 허락을 얻는 것

* System Test

: 시스템 테스트

: 결함을 찾아내기 위해서 소프트웨어를 실행하여 테스트를 진행하는 것을 의미함. 주로 테스트 조직에서 담당하며, 요구되는 사항으 토대로 테스트 계획서를 작성하여 케이스를 만든다.

: 시스템이 완전히 통합되어 구축된 상태에서 정보시스템의 기능을 총체적으로 검사하는 것. 통합된 각 모듈들이 원래 계획했던 대로 작동하는지, 시스템의 실제 동작과 원래 의도했던 요구사항과는 차이가 없는지 등을 판단

: 블랙박스 테스트의 일종으로 분류

* TFT (Task Force Team)

: 회사에서 새로운 프로젝트를 추진할 때 각 부서에서 선발된 TASK에 관련된 팀원들이 임시 팀을 만들어 활동하는 것

* Transaction (트랜잭션)

: 데이터베이스와 같은 시스템에서 이루어지는 논리적인 작업 단위

: 작업이 완전히 실행되지 않거나 주간에 작업이 실패하는 경우, 전체 작업을 실패로 처리하여 데이터베이스의 데이터무결성을 지켜준다.

: 트랜잭션의 네가지 성질 (ACID) - 1. 원자성(Atomicity), 2. 일관성(Consistency), 3. 독립성(Isolation), 4. 영속성(Durability)"

* Trigger

: SQL에서, 테이블에 부착되어서 테이블에 INSERT나 UPDATE 또는 DELETE 작업이 발생되면 실행되는 코드

* Unit Test

: 단위 테스트

: 개발자가 자신이 작성한 소스 코드를 테스트하는 것을 의미함. 일반적으로 비공식적으로 진행하며, 진행 단위는 케이스에 따라 다르다.

: 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차. 각 테스트 케이스는 서로 분리되어야 함

* URI (Uniform Resource Identifier)

: 인터넷 자원을 나타내는 고유 식별자

: 인터넷에 있는 자료의 id

: URI ⊃ URL, URN등

* UV (Unique Visitor)

: 순 방문자 수

: 한 명의 방문자가 페이지를 여러 번 요청하더라도 1번의 방문 기록으로만 셌을 때의 방문자 수

* Voc (Voice of Custome)

: 고객의 소리

* WAS (Web Application Server)

: 웹서버에서 사용자가 요구하는 내용(동적인 내용)을 실행시켜주는 코드를 추가해주는 것

: Tomcat, Resin, Jeus(JSP) / IIS(ASP) / Apache(PHP)

* Waterfall Model

: 폭포수 모델. 소프트웨어 개발 모델 중 가장 오래되고 전통적으로 사용하는 모델

: 프로젝트 계획 -> 업무 분석 -> 시스템 설계 -> 프로그램 구현 -> 테스트 -> 유지보수 (폭포물이 떨어지듯 각 단계가 끝나면 다음 단계로 진행)

* WSL (Windows Subsystem for Linux)

: 리눅스용 윈도우 하위 시스템

: 윈도우에서 리눅스 실행 파일을 실행할 수 있게 해줌

알아두면 편리한 테스트 업무 관련 용어들 (F ~ P)

 * FNB (Foot Navigation Bar)

: 하단 네비게이션 바 - 하단 메뉴, 하단 로고, 주소, 카피라이팅 영역

* FO (Front Office)

: 프론트오피스, 사용자가 이용하는 쇼핑몰 웹/앱 화면

* FTP (File Transfer Protocol) 서버

: 파일 전송 프로토콜. TCP/IP 프로토콜을 가지고 서버와 클라이언트 사이의 파일 전송을 하기 위한 프로토콜이다. 파일 전송 프로토콜은 TCP/IP 프로토콜 테이블의 응용 계층에 속하며, 역사는 오래 되었지만 지금도 인터넷에서 자주 사용된다.

* Game Changer

: 게임체인저

: 어떤 일에서 결과나 흐름의 판도를 뒤빠꿔 놓을 만한 중요한 역할을 한 인물이나 사건

* GNB (Global Navigation Bar)

: 사이트 전체에 동일하게 적용되는 최상위 공통 네비게이션 바 - 공통메뉴, 메인메뉴, 대분류 메뉴

* gRPC (google Remote Procedure Cell)

: 구글에서 만든 원격 프로시저 호출

: 현재 실행중인 프로세스의 주소공간 내부가 아닌, 외부의 프로세스 또는 원격지의 프로세스와 상호작용 하기 위한 기능

: 현재 실행중인 테느워크의 자원을 사용하는 것이 아닌 외부의 자원을 사용

* GuestOS

: 진짜 내 컴퓨터에 VM깔아서 그 위에 설치한 OS

* Hexagonal architecture (= Port & Adapter architecture)

: 육각형 안쪽에 도메인과 관련된 비즈니스 로직이 들어가고, 육각형 바깥에 도메인과 상관이 없는 인프라 코드가 들어감

: Adapter - 외부에서 들어오거나 나가는 요청을 처리하는 부분 (port를 통하기 위해 거쳐야 하는 부분)

: Port - Adapter와 비즈니스 로직 접근하는 통로 (input, output 통로)

* HostOS

: 진짜 내 컴퓨터

* HotFix

: 제품 사용 중에 발생하는 버그의 취약점 보완, 또는 성능 향상을 위해 긴급하게 배포되는 패치 프로그램

: git에서 hotfix branch를 따로 파서 작업함

* I/F (Interface)

: 인터페이스

* IaaS (Infrastructure as a Service)

: 서비스로서의 인프라 환경

: IT 인프라를 제공하는 클라우드

: 돈을 넣으면 자판기에서 미리 준비된 상품이 나오듯, 이미 구성된 환경을 사용자가 필요에 따라 선택하고 조합해서 사용할 수 있게 제공

: OS머신을 제공함

: 가상서버, 가상데스크탑 사용자용

* IaC (Infrastructure as Code)

: 코드형 인프라

: 코드로 하드웨어 설정/운영 체제 설치/네트워크 구성/개발 환경 구출을 함으로써 프로젝트 환경을 가능한한 일정하게 생성 및 유지, 즉 코드로 인프라를 소프트ㅜ에어처럼 다룰 수 있음

: 사용자가 모두 동일한 환경에서 테스트할 수 있고, 문제가 발생했을 때 몇 번의 명령 실행만으로 환경을 다시 새것처럼 구성할 수 있음

* IDC (Internet Data Center)

: 데이터 센터

* idempotent (멱등성)

: 연산을 여버 번 적용하더라도 결과가 달라지지 않는 성질 (수학, 전산학)

* In-App

: 앱 안에서 이루어지는 일

: 주로 화면 하단에 in-app push 알림창을 띄워서 이벤트를 홍보한다든가 매진 임박 알림창을 띄운다든가 링크를 공유한다든가 하며, 결제 모듈로 구매 활동이 이루어지기도 함.

* JSP

: Java 기반의 웹개발 언어

* Jython

: 파이썬의 자바 구현. 자바 플랫폼에 맞추어 파이썬 언어를 구현

* KPI (Key Performance Indicator)

: 핵심 성과 지표

: 목표 달성을 위해 핵심적으로 관리할 요소들에 대한 설과 평가 기준

* LBS (Location-based Service)

: 위치 기반 서비스

: GPS 기술을 이용하여 고객 경험 가오하 서비스 제공

* LNB (Local Navigation Bar)

: 특정 지역으로 가는 네비세이션 바 - 서브 메뉴, 중분류 메뉴

* MDM (Mobile Device Management)

: 모바일 단말기 관리

: 모바일 기기의 보안을 향상시켜 비즈니스 용도로 사용하기 적합하게 하는 앱

* Meta Data

: 데이터에 대한 데이터

: 데이터에 관한 구조화된 데이터로, 다른 데이터를 설명해 주는 데이터

* mirror site ": 다른 웹사이트의 컨텐츠를 그대로 복사하여 갖고 있는 사이트

: 미러링 - 웹 사이트의 파일을 서로 동기화 하는 것 / 데이터의 안정적 보존 및 본 서버에 문제가 생겼을 경우에 대한 대비하기 위함. 미러링을 함으로써 나무위키 미러처럼 본 서버의 접속자를 분산하거나 해당 웹페이지를 빠르고 가볍게 접속 가능하다.

* MM (Man Month)

: 맨먼쓰, men per month

: 프로젝트 진행 시, 한달에 투입되는 개발자 인원 수

* NA, N/A (Not Applicable or Not Available)

: 해당 사항 없음

* NCR (Non-Conformance Report)

: 부적합 사항 보고서

: NCR이 발행 되어을 경우 반드시 조치 결과를 첨부 해야함.

* O2O (Online to Offline)

: 온라인에서 구매하고 오프라인으로 물건 받기

* O4O (Online for Offine)

: 온라인 플랫폼에서 오프라인 매장으로 고객을 유인 (ex. 아마존 고, QR코드로 체크인하여 오프라인 매장에 입장 후 물건을 골라서 상품을 들고 나가면 모바일 앱으로 바로 결제)

* OCP (Open-Closed Principle)

: 개방-폐쇄 원칙

: 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다.

* Onboarding

: 온보딩. 조직 내 새로 압류한 사람이 조직 업무 및 문화에 빠르게 적응하기 위해 돕는 과정

* PaaS (Platform as a Service)

: 서비스로서의 플랫폼

: (애플리케이션 빌드) 플랫폼을 제공하는 클라우드

: 애플리케이션 서버 (+a)제공하는 개념

: 개발자용

* PHP

: 웹개발 언어

* ping (Packet InterNet Groper)

: 네트워크의 상태를 점검, 진단하는 명령어

: ping을 보내는 대상 컴퓨터를 향해 일정 크기의 패킷(Packet, 네트워크 최소 전송 단위)을 보낸 후 (ICMPecho request) 대상 컴퓨터가 작동하는지, 또는 대상 컴퓨터까지 도달하는 네트워크 상태는 어떠한지를 알 수 있다.

: 인터넷이 안 된다고 가정할 때 공유기 또는 통ㅎ신사의 DNS서버에 ping을 보내 주고받은 패킷의 손실률을 파악하여 인터넷의 연결 상태를 진달할 수 있다.

* PMO (Project Management Office)

: 프로젝트 관리 조직

: 프로젝트 업무 범위 내에서 프로젝트를 관장하고 조정 관리하는 다양한 책임이 부과된 주체

: 프로젝트 관리 지원부터 직접 프로젝트를 관리

: 프로젝트 관리 능력을 향상시키고 발전시키기 위한 실질적인 사항을 제시해주는 조직"

* PO (Purchase Order)

: 주문 관련

* psql

: sql 인터프린터, 데이터베이스에 명령을 하고 답을 얻는 프로그램

: PostgreSQL의 command Line Interface"

* PV (Page Views)

: 페이지 뷰

: 사용자의 요청으로 사이트의 '한 페이지'가 사용자 ㅏ화면에 표시되는 요청 횟수

알아두면 편리한 테스트 업무 관련 용어들 (A ~ E)

 * .yml, .yaml 파일

: '얌 파일', '야믈 파일' 이라고 읽음

: YAML Ain't Markup Language

* 12-factors

: SaaS 개발 방법론

: 12개의 요소- 코드 베이스 / 종속성(Dependencies) / 설정(Config) / 백엔트 서비스 / 빌드(build), 릴리즈(release), 실행(run) / 프로세스 / 포트 바인딩(Port binding) / 동시성(Concurrency) / 폐기 가능(Disposability) / 개발-프로던션 환경 일치(Dev-Prod parity) / 로그(Logs) / 어드민 프로세스

* alias

: 별명, 가명. 리눅스에서 명령어를 커스터마이징 할 수 있는 기능

* API (Application Program Interface)

: 응용프로그램 인터페이스

: 운영체계나 다른 응용프로그램에게 처리요구를 할 수 있도록 컴퓨터 운영체제나 다른 응용프로그램에 의해 미리 정해진 특별한 메소스/언어/메시지 형식

* AS-IS

: AS-IS - ""있는 그대로"", 현재 업무 프로세스에 대한 분석

* TO-BE

: TO-BE - ""미래의"", 미래에 개선될 업무 프로세스에 대한 분석

* AWS (Amazon Web Service)

: 클라우드 컴퓨팅 분야. IT 인프라 구축에 필요한 온갖 서비스들을 제공

* AWS Aurora

: AWS가 MySQL 및 PostgreSQL을 호환해서 만든 RDBMS

* BAT (Build Acceptance Test)

: 빌드 수용 테스트

: 소프트웨어의 핵심 기능을 테스트하는 과정으로 빌드 진행 후 소프트웨어의 핵심 기능이 정상 작동되는지 확인함으로서. 세세한 테스트를 진행할 준비가 되어 있는지 확인하는 과정 (주로 퍼블리셔에서 진행)

* BVT (Build Verification Test)

: 빌드 검증 테스트

: 빠르게 빌드 전반에 대한 내용을 테스트 (주로 개발사에서 진행)

: MS의 BVT 속성 - 모든것을 자동화 하라. (모든 빌드가 나올때마다 테스트해야 하는 내용들을 설치, 삭제 같은 것을 자동화하여 테스트를 효율적으로 진행한다.) / 일부만 테스트하라. (기본 기능을 확인하여 빌드가 테스트 진행을 위해 사용 가능한지를 확인한다.) / 신속하게 테스트하라. (전체 빌드 검증 테스트는 몇 시간 안에 끝낸다. 수행 시간이 짧을 수록 빌드가 문제가 있는지 즉각 파악할 수 있다.) / 실패를 정확하게 인지하라. (BVT가 실패했다면, 실패 원인은 즉시 수정되어야 한다.) / 깊게가 아닌 넓게 테스트하라. (BVT는 전반에 걸친 테스트를 진행하는 것이다. 세세한 부분은 나중에 하고 주요 기능, 주요 사용 시나리오를 가능한 많이 포함시킨다.) / 디버그와 유지 보수가 용이하게 하라. (실패가 일어났다면, 그 원인을 파악하여 목룍으로 기록한다.) / 신뢰할 수 있어야 한다. (실패하였다면 즉시 알려야 한다. 타협하면 안된다.)

: 다음과 같은 기준으로 작성됨 - 반복적인 수행이 가능해야 함 / 빠르게 수행할 수 있어야 함 / 테스트 케이스의 유지 보수가 어렵지 않아야 함

* batch (batch prosessing)

: 일괄 처리

: 개별적으로 어떤 요청이 있을 때마다 실시간으로 통신하는 것이 아닌 한꺼번에 일괄적으로 대량 건을 처리

: batch program - 프로그램을 실행하면 알아서 주기적으로 점검하거나 기타 등등을 해주는 프로그램

* Beacon

: 블루투스 4.0 기반의 프로토톨을 사용하여 기기에 신호를 전달하는 무선통신장치

: 초저전력, 저렴한 비용, 넓은 활용 분야로 인해 NFC와 자주 비교됨

* Billing System

: 결제 관련 체계

* BIOS

: 부팅 전 하드웨어를 한번 초기화 하여 사용을 준비하게 하는 펌웨어

* BO (Back Office)

: 백오피스, 관리자 도구

* Case Open

: 케이스 오픈

: 일반적으로 발견되지 않은 오류라서 레퍼런스가 없는 경우, 아예 제조사에 문의해버리는 것

: IT에서는 문제 상황에 대해 검색을 해도 해결 방법이 나오지 않는 경우 자신의 케이스를 오픈해서 공론화 한 다음에 해결 방법을 찾아가도록 하는 것

* CD (Continuous Delivery)

: 소스 코드로부터 설치, 실행할 수 있는 제품을 생성하여 배포하는 과정

* CDATA ((Unparsed) Charater Data)

: xml을 파싱하기 위해 사용되는 것

: xml에 보면 <![CDATA[내용]] 이런 코드로 사용함. 파싱되지 않은 문자라는 의미. 주로 쿼리에서 많이 사용함

* CDC (Change Data Capture)

: 마지막으로 추출한 이후 변경된 데이터만 골라내는 기술

: 데이터 백업이나 통합 작업을 할 경우 방ㅇ대한 데이터를 다뤄야 하는데, 원본소스 가운데 최근 변겨오딘 데이터들만 골라 다른 시스템으로 옮기게 되면 시스템 로드도 줄이고 전체적인 작업 생산성을 향상 시킬 수 있다.

: 일반적으로 CDC라고 하는 것은 데이터베이스 로그기반 CDC를 의미한다.

* CDN (Contents Delivery Network)

: 혹은 Contents Distribution Network

: 지리적 제약 없이 전 세계 사용자에게 빠르게 콘텐츠를 전송하는 기술

: 지리적으로 분산된 여러 개의 서버

:  웹 콘텐츠를 사용자와 가까운 곳에서 전송함으로써 전송 속도롤 높임

* CI (Continuous Integration)

: 소프트웨어 개발에서 각 소프트웨어 개발자가 작업한 변경점을 프로젝트의 원래 소스 코드에 자주, 빠르게 통합하는 것이다. 각종 개발도구와 스크립트를 사용해 코드를 합치고 품질을 검사하며 테스트하는 과정을 자동화한다. 덕분에 사람이 직접 해야 하는 일이 줄어들고 문제가 생겼을 때 빨리 발견할 수 있다.

* CIMS (Computer Intergrated Manufacturing System)

: 컴퓨터 통합 생산 시스템

: 생산에 관련된 모든 활동 (설계, 제조, 관리, 판매, 개발, 자재구매 등의 각 부문)을 컴퓨터나 주변 기술을 구사하여 통합함으로써 필요한 질과 양의 정보를 제시간에 맞추어 생성/전달하고, 각 부문간의 의사 소통 및 의사 결정을 원할, 신속 그리고 효율적으로 행함으로써, 현 생산 시스템의 업무에 내재하고 있는 과제의 해결을 도모하고, 기업 전체를 탄력성 있고 효율적으로 움직이도록 하는 시스템

* CMS (Contents Management System)

: 저작물 관리 시스템

: 게시판, 레이아웃, 모듈과 같은 기능을 모아둔 웹 프레임워크, 클릭 한번으로 사이트를 만들 수 있음."

* CPU

: 뇌와 같음. 연산할 떄 쓰임. 메인 프로세서

* CRM (Customer Relationship Management)

: 고객 관계 관리

* CS 프로그래밍

: Client & Server 프로그래밍

* DAO (Data Access Object)

: DB에 접근하는 객체

* DBA (DataBase Administrator)

: 데이터베이스 관리자

* DCMS (Digital Contents Management System)

: 디지털 톤텐츠 관리 시스템

: e북, 오디오북, 동영상북 등 다양한 형태의 디지털 콘텐츠를 하나의 플랫폼에서 서비스 할 수 있도록 디지털 콘텐츠의 불법 복제 및 유통을 방지해 저작권을 보호하고 콘텐츠의 표준화된 플랫폼을 구축해 안정적인 통합 서비스 환경을 제공

* DCPM (Dynamic CPM)

: CPM - Cost Per Mille, 1천 뷰 노출당 비용

* DevOps

: 애플리케이션 개발의 품질과 속도를 개선하고 신규 또는 수정된 소프트웨어 기능이나 제품의 릴리즈 주기 단축을 장려하는 새로운 철학이자 프레임워크

: 애플리케이션 개발 팀(Dev)와 해당 IT운영 팀(Ops)팀 간의 원할하고 지속적인 커뮤니케이션, 협업, 통합, 가시성 및 투명성을 장려

* Dingbat

: 딩벳. 그림 문자(이미지) 만으로 구성된 폰트

: 자판을 누르면 그림 문자가 이력됨. 딩벳, 장식활자, 심벌 폰트(Symbol font), 파이 폰트(PI font), 이모지 등으로 표기

* DW (Data Warehouse)

: 분산되어 있는 각각의 데이터 베이스 관리 시스템들을 통합하여 관리

: 중앙 저장소 역할

* EAI (Enterprise Application Intergration)

: 기업 응용 프로그램 통합

: 기업 내 필요한 여러 어플리케이션이 있을텐데, 이런 각종 애플리케이션 간에 상호 연동이 가능하도록 통합하는 솔루션

: 통신프로토콜/데이터 타입/OS 등 각기 다른 환경에서 동작하는 애플리케이션들에 대해 상호 연동할 수 있는 기능을 제공하는 솔루션

: 파일, 온라인서비스, DB 등 각기 다른 데이터를 주기적으로 혹은 준실시간(Defered Online)으로 처리함

: 각 시스템별로 비지니스적으로 다른 처리를 하고 있지만, 각 시스템간에 공통된 영역을 효율적으로 연동하기 위해 사용함

* EAM (Enterprise Access Management)

: 통합 인증, 권한 관리 시스템

: SSO 시스템에 권한 관리, 자원 관리 등이 포함된 개념

* EDI (Electronic Data Interchange)

: 전자 데이터 교환

: 협력사 포털, 협력사끼지 정보 주고받는 시스템

알아두면 편리한 테스트 업무 관련 용어들 (ㄱ ~ ㅎ)

* 개방형 데이터 (Open Data)

: 필요로 하는 이들에게 무료로 공개하는 데이터

: 주로 정부 기관이나 비영리단체, 교육기관과 일부 사기업 등이 제공한다.

* 계정계

: 금융업에서 고객의 거래를 실시간으로 처리하는 시스템

* 기간계

: 기존에 사용하고 있는 시스템(레거시 시스템)

* 대외계

: 금융기관의 대내 망을 연결하는 시스템

* 본 수 (개발 본 수)

: 웹 페이지 화면 1개 혹은 jsp 1개 = 본 수

* 스크럼 (Scrum)

: 소프트웨어 개발 방법론 중 하나

: 애자일 개발 프로세스에 해당

: 특정 기능에 대한 계획 - 개발 - 테스트 - 기능구현 주기 (스프린트, Sprint)를 활용한 방법론

* 아카이브

: 기록 보존소. 리눅스 파일 묶음

* 어플리케이션 아키텍처 (AA)

: 오플리케이션을 설계하고 구축하는 데 사용하는 패턴과 기술을 설명

* 전문

: 결제 등을 요청하기위해 결제대행사로 송신하는 원장

* 정보계

: 거래되는 데이터를 관리 및 통계하는 시스템

* 칸반 보드 (Kanban Board)

: 소프트웨어 개발 방법 론 중 하나

: todo - in progress - done

* 크래커

: 해커로 통칭됨. 해커가 개발 영역이라면 크래커는 범죄 영역에 있음.

* 해커

: 개발자

* 크로스체크

: 문서/보고 등을 여러 개의 다른 관점/방법 등으로 검사하는 일

* 트러블 슈팅

: 시스템이나 장치 등에서 발생한 장애를 각종 수법을 써서 그 원인을 찾아내는 것

* 파일럿 프로그램

: 정식 발매된 것은 아니고 정식 발매 전 테스트용

QA로서의 건의 방법

요즘들어 QA를 시작할때의 초심을 잃어가는 느낌이다.
한번.. 두번.. 언제부터 작업물에 대한 열정이라 여기고 했던 건의나 피드백에 거부감을 가지는 모습을 보면서 남의 탓을 하면서 왜 받아들여 지지 않는지에 대한 불만만을 토하던게 일상적인 모습이 되어 버렸을까? 이런저런 푸념을 하면서 책과 웹을 떠돌던 중 처음 이 일을 할때 각오했던 일을 상기시켜주는 글을 발견했다.

1. 주관성이 강할 수 있는 건의사항(게임성 요소)은 배제하도록 한다.
- 왜 이렇게 만들었는지에 대한 기획의도를 기획서에서 찾을 수 없다면 기획자에게 기획의도를 물어보는 것을 우선으로 한다.
- 게임성은 곧 게임의 재미요소다. 자기 주관만으로 건의 사항을 내 놓아도 정말 유저에게 먹힌다라는 확신은 없기 때문에 기획자의 의도가 파악되는 한은 기획자의 의도를 받아 들이도록 한다. 서로 게임성에 대해 지향하는 방향이 다른 상태로 건의가 전달되어 테스트팀과 개발팀의 사이가 어그러 질 수도 있다. 최악의 경우 소통의 문제로 발전해 업무에 큰 방해가 되 수도 있기 때문에 조심해야 할 부분이다.

2. 데이터를 확보할 수 있는 건의사항은 데이터와 함께 전달한다.
- 데이터를 근거로 사용 할 수 있는 개선사항도 있다. 예를 들면 FPS게임의 총기 밸런스와 같은 부분이다.
- 총기 밸런스는 다른 총들과 데미지, 연사시간, 집탄력을을 비교해서 필요 시 건의사항을 작성할 수 있다. 새로 내놓는 총기가 기존 총기에 비해 너무 강하거나 약한 경우 데이터를 비교해 건의를 작성할 수 있다.

3. 데이터를 모을 수 있지만 건의사항 작성은 하지 않는게 좋은 경우도 있다.
- 데이터를 모으기 위해 테스트 리소스가 과다하게 사용되는 경우에는 지양한다.
- 데이터의 수집이 반드시 필요한 경우 실서버 등에서 유저의 로그등을 수집해서 분석하는 방식으로 우회 적용은 가능하다.



주의사항!
QA로 일을 하게 되어 게임 제작에 참여한다고 생각해 테스팅보다는 건의사항이나 리뷰에 더 치중하고 싶어하는 사람들이 많다. 그러나 곧 자신의 건의사항이 받아들여지지 않는 것에 많이 좌절하기도 한다. QA가 물론 Quality Assurance로 품질을 보증하는 업무가 맞기는 하지만 QA는 기획자가 아니다. 기획자가 미쳐 생각하지 못했던 기획의 구멍을 찾아내거나 개발자가 미쳐 수정하지 못한 코드적인 문제는 찾아내어 서포트 해주는 업무가 되어야 한다.
하지만! QA(서포트)=심부름꾼으로 여겨지는 것 역시 곤란하다. 각 담당자들의 소통간 문제로 서로간의 마음이 상해서 공유되어야 할 내용이 공유되지 않아서 문제되는 내용이 작업물에 고스란히 반영되는 피해는 없어야 한다.

부서 이야기(개발 지원/품질 관리 부서)

부서 이야기

개발 지원/품질 관리 부서
이 부서는 게임을 테스트하고, 판매가능한 정도의 수준을 가지고 있는지를 판단하는 테스트팀을 포함한다. 게임 테스트는 질적인 면과 수적인 면이 동시에 고려되어야 한다. 게임 테스트가 질적인 면에 관여한다는 것은 이것이 완벽한 게임플레이를 창조하기 위한 일종의 예술이며, 이러한 기술은 아무나 가지는 것이 아니라는 데에서 기인한다. 실제로 이 세상에는 자격 미달인 게임들이 많다. 또 한가지 게임 테스트가 양적인 면에 관여한다는 것이 이 과정에서 발견되는 버그의 숫자나 그 중요도가 평가되어야 한다는 점에 기인한다. 이것은 품질 관리 부서가 개발 초기에 주로 수행하는 작업이다.

품질 관리 팀장
품질관리 팀장의 역할은 품질 관리 팀을 관리하고 프로젝트 매니저나 게임 디자이너와 함께 게임을 게임플레이적인 면에서부터 각각의 기능이 사양서대로 잘 동작하는가에 이르기까지 모든것을 검사하는 것이다. 품질관리팀장은 게임 테스트 계획을 짜고 각각의 품질관리 요원들에게 각각 다른 분야를 할당한다. 테스트에 의한 실제적 결과들은 프로젝트 매니저에게 보고된다.

품질 관리 기술자
품질관리기술자의 역할은 프로그래밍 팀이 만든 코드를 테스트하는 것이다. 품질관리 기술자는 각 코드의 기능이 피요기능 리스트에 있는 모든 것을 포용하는지를 테스트하는데, 이는 그가 품질 관리 팀장으로부터 받은 계획서가 코드의 모든 분기를 따라가 볼 수 있는 성질의 겻이어야 한다는 것을 의미한다. 만들어진 모든 코드는 테스트 해봐야 한다. 아무리 자잘한 쿠드에라도 그 코드를 테스트하기 위한 테스트 데이터가 필요하다. 품질관리 기술자는 자신이 지금 무엇을 테스트하고 있는지를 확실하게 이해하기 위해 프로그램 코드의 배후에 있는 모든 기술적 지식들에 통달하고 있어야 한다. 이러한 테스트는 가장 상세한 레벨의 것으로써, 프로그래머 그룹이 대신하기도 한다. 이러한 테스트를 테스터가 테스트 품목의 내부 구조를 알고 있다라는 의미에서 '클리어 박스 테스팅clear-box testing'(혹은 화이트 박스 테스팅)이라고 부른다. '클리어 박스 테스팅'의 반대로는 '블랙 박스 테스팅black-box testing'이 있다.'블랙 박스 테스팅'에서는 코드가 동작한 결과물이 그 대상이 된다. 그 예로 폴리곤을 그리는 모듈이 그린 폴리곤이 실제로 화면에서 제대로 표시되는가를 체크하는 것 등이 있다. 블랙 박스 테스팅의 경우 충분히 자세한 테스트 계획서만 있다면 테스트 요원들이 수행할 수도 있다.

플레이테스트 요원
플레이테스트 요원의 역할은 게임을 실제로 해보면서 테스트를 하는 것이다. 기본적인 테스트 요원들은 프로그래머와 아티스트를 비롯한 전 팀원들이다.(명확한 플레이테스트 요원과 프로그래머/아티스트의 구분은 어렵다.) 하지만 프로젝트가 중/후반으로 진행될수록 제대로 된 플레이테스트의 중요성이 커진다. 플레이테스트의 종류에는 다음 4가지 것이 있다. 팀의 크기나 제정 상태, 그리고 플레이테스트에 할애할 수 있는 시간등의 요소들에 의해 이 4가지 방법중에 어떤것을 사용할 지를 결정하게 된다.

- 첫번째. 팀원들을 그대로 플레이테스트 요원으로 사용하는 것인데, 대부분의 경우 팀원들은 이미 자신들이 만들고 있는 게임에 대해 너무 친숙해서 객관적이기 어렵기 때문에 이는 그리 좋지 않은 방법이다. 이에 대한 좋은 대안은 게임을 좋아하는 학생들을 데려다가 플레이테스트 요원 아르바이트를 시키는 것이다.
- 두번째. 고정적인 플레이테스트 요원을 고용하는 것이다. 이 방법은 대부분 보다 큰 조직을 위한 방법이지만, 몇가지 프로젝트가 동시에 진행되고 있는 회사라면 충분히 효율적일 수 있는 방법이기도 하다. 만약 플레이테스트 요원을 충분히 사용할 만큼 프로젝트가 없다 하더라도, 이 요원을 사내의 다른 업무에도 투자할 수 있다는 점을 생각하면 이 방법은 충분히 실현 가능성이 있는 것이다.
- 세번째. 일의 양이 불규칙적이어서 고정적인 플레이트스트 요원을 고용하는 것이 효율적이지 못하다고 생각한다면, 플레이테스트 전문업체에게 외주를 주는 것도 방법이다. 전문업체에는 다양한 사양의 컴퓨터 위에서 정확하게 테스트를 해 줄 경험 있는 프로 플레이테스트 요원들이 있다. 그러므로 전문 업체는 블랙박스 테스트에 아주 적합하다. 하지만 방식 자체가 외주인 만큼 거의 완성되니 제품의 하드 웨어 호환성이나, 다른 방법으로는 찾아내기 힘든 버그를 찾기 위한 방법으로 사용하게 된다.
- 네번째. 유저에게 직접 베타 테스트를 맞기는 것이다. 이 방법은 회사의 크고 작음에 관계없이 상당히 좋은 방법이다. 베타 테스트란 거의 완성된 게임을 유저들이 직접 테스트하도록 하는 것이다. 이 경우 베타 테스트용 프로그램은 무언가 실제 제품에 비해 제약을 거는 것이 일반적이다.(베타 버전에서는 동작하지 안는 기능이 있다든지...)
베타 테스트에는 회사측의 관리가 쉽도록 미리 신청을 받은 일정수의 유저만을 대상으로 하는 클로즈드 베타(Closed beta)와, 웨상이나 잡지 부록으로 베타 버전을 뿌려서 누구나 테스트에 참가 가능하도록 하는 오픈 베타(Open beta)가 있다. 클로즈드 베타의 경우에는 정식판이 나올 때 테스터들에게는 공짜로 나누어 준다든지 하는 방법으로 테스터를 예우해 주기도 한다.

시스템 엔지니어
SE라는 약칭으로 흔히 부르는 시스템 엔지니어의 역할은 회사 내의 컴퓨터 작업 환경을 관리하는 것이다. SE의 구체적인 업무로는 사내 네트웍을 관리하고, 개발자의 PC에 적절한 프로그램을 인스톨하고, 필요한 PC를 업그레이드 하여 개발 업무에 지장이 없도록 하는 것 등이 있다.

개발자의 유형

독불장군 The Marverick
독불장군은 모든 사람들이 믿고 의지하는 재능있는 사람이다.
만약 중요하고 민감한 일을 해야 한다면 독불장군이 제격이다. 높은 수준의 기술과 넓은 지식을 함께 갖는 독불장군은 리더로서의 자리를 잘 해낸다. 물론 문제가 생기기 전까지는..
독불장군은 자기가 짠 코드에 완전한 소유권을 쥐고 누구도 다가오는 것을 허락하지 않으려고 한다. 독불장군이 보기에는, 그의 코드를 건드리게 할만큼 미더운 사람이 아무도 없다. 다른 누구도 기술이나 지식이 부족하기 때문에 코드의 순수함을 더럽힐 뿐이러서, 못 건드리게 하는 것이 최선이라 여긴다. 그가 유별나게 경쟁심이 강하거나 자만심이 강하지 않는 이상, 팀원들에게 이런 행동은 용납되곤 한다. 대부분 코드는 다른 사람들은 거의 해독 불가능하다. 이런 방식의 장벽을 전문 용어로 '직업 비밀'이라고 부른다.
하지만, 무언가 잘못되고 있을 때는 어떻게 되는가? 아무도 코드 내용을 모르기 때문에 식은땀을 흘리고 앉아서 독불장군이 문제를 해결하는 것을 기다리고 있어야 한다. 팀 전체가 한 사람 때문에 기다려야 한다는 이야기가 된다. 이것은 리스크이며 별로 좋은 상태도 아니다. 독불장군이 실패한다면, 팀 전체가 그를 따라 실패하는 것이다.
그리고 방대한 량의 이해하기도 힘든 소스 코드를 남긴 채로 독불장군이 그만둔다면 남은 팀원이 할 수 있는 유일한 방법은 독불장군이 남긴 코드를 이해하기 위해 '리버스 엔제니어링'하는 것 뿐이다. 다른 방법도 있긴 하지만, 불쾌하고 불합리한 것 뿐이다. 불행하게도 이 방식을 쓸 수 없을 수도 있는데, 독불장군은 어떤 분야에 중대한 책임을 지고 있는 경우가 많기 때문이다. 기능을 뺄 수 없거나 뺴서는 안되는 경우에는 그 기능 구현에 매달려서 독불장군이 떠나간 덕분에 생긴 지연을 감수할 수 밖에 없다.

프리마돈나 The Prima Donna
그는 최고다.
이 사람은 자기가 최고라고 알고 있기 때문에 그를 트집잡으려면 그의 분노를 견딜 수 있어야 한다. 모든 사람이 프리마돈나를 알아야만 한다. 그는 거대하지만 깨지기 쉬운 자아를 가진 존재다. 그의 의견은 언제나 최고이며, 그의 코드는 언제나 완벽하다. 독불장군과 마찬가지로 프리마돈나는 비평을 받아들이는 법을 모른다.
프리마돈나는 보통 매우 머리 좋고 기술적으로 능숙하다. 그러나 미숙한 대인 관계와 남에게 나쁜 쪽으로 영향을 미치는 기술이 그의 특기이기도 하다. 그는 세상을 두 부류로 나누는데, 그보다 머리가 나쁜자, 그리고 자기에게 위협이 되는 자가 그것이다. 그는 주로 프로젝트 리더가 되는데, 그의 댜양한 재능을 가장 잘 발휘할 위치로 보이기 때문이다. 불행하게도 이 위치야말로 팀에게 가장 큰 피해를 입힐 수 있는 곳이다.
프리마돈나는 지력과 기술로 자신에게 위협이 되리라고 여기는 모든 사람을 공격할 것이다. 그의 능력에 미치지 못하는 다른 사람은 무능한 자로 여길 것이다. 모든 사람(특히 내성적이지 않은)이 팀 내부에 불편한 움직임을 만드는 그런 공격을 견딜 수 있는 것은 아니다. 프리마돈나는 팀에게 있어 가장 거대한 위험요소다. 프리마돈나의 괴상한 행동 때문에 팀이 파괴된다면, 최고의 동료 2~3명은 잃게 될 것이다.
프리마돈나는 기본적으로 타인의 능력을 의심하며 그들의 작업을 깔보는 지배 도착자다.

부끄럼쟁이 The Shy Guy
부끄럼쟁이는 전형적인 매니아다.
부끄럼쟁이는 대단히 소극적이며, 하루에 한 두 번은 의사소통장애를 일으킨다. 부끄럼쟁이도 비평해주기 어렵다. 사실은 칭찬하는 것도 어렵다. 이것이 아이디어에 관해 서로 이야기하는 기본적인 것임에도 불구하고... 이런 사람들은 자기 컴퓨터 압에서만 편안해 하는 것 같으므로 전자 우편을 보내는 것이 최상의 의사소통 수단일지도 모른다.
부끄럼쟁이가 직접적인 위협을 가해서 팀을 일부러 파괴하는 경우는 없지만, 그가 팀에 미치는 위혐은 상당히 명확하다. 그들은 절대 함께하지 않는다는 것이 문제다. 의사소통의 부재가 가져오는 가장 큰 문제는 프로젝트의 가시성을 극단적으로 똘어뜨리며, 이거은 거대한 프로젝트에서는 매우 큰 문제가 된다.

복병 The Sleeper
복병은 정상적인 팀 동료로 보인다. 적어도 표면적으로는 그렇다. 그러나 깊이 들여다보면 그들은 그렇게 도움이 되지 않으며, 다른 팀 동료들을 조종해서 분란의 씨앗을 뿌린다.
이에는 여러가지 이유가 있다. 가장 일반적인 이유는 순수한 반골인 경우다. 복병은 단순히 권력을 인정하지 못하며 무의식적으로 어떤식으로든 권력을 부정하려고 한다. 다른 이유로는 팀 동료를 선동해서 독립적인 팀을 만들려고 한다던가, 혹은 대우가 불충분하다고 생각해서 다른 팀 동료들도 똑같이 생각하기를 바란다던가 하는 것이 있다.
복병은 알아채기 어렵기 때문에 매우 위험하다. 복병은 관리자들에게 존재를 알리지 않으며 자신의 불만은 숨긴 채 자주 믿음직스러운 사람으로 인식되곤 한다. 익명보고창구를 만들어 두면 이런 문제 있는 개발자를 찾아낼 수도 있다.

팔방미인 The Jack
팔방미인은 모든 것을 다 할 수 있지만, 어떤 것에도 최고는 아닌 사람이다.
그는 여러 '부정적인' 유형 중에는 가장 쓸모있는 편이고, 어떤 경우에는 바람직하다고 여겨지기도 한다. 팔방미인은 문제 유형 중에서 유일하게 남겨둘 가치가 있는데, 자신의 단점을 극복하도록 가르치기만 한다면 유용한 팀원이 될 수 있기 때문이다.
팔방미인의 중요한 단점은 자신의 능력을 노무나 확신하고 있어서 가끔은 그것이 지나친 자신감이 되기도 한다는 것이다.
그의 능력에 대한 믿음이 실제 능력과 만나는 타이밍은 너무 멀어서 그의 신용이 회복 불가능한 타격을 이고 나서야 발견되곤 한다. 이런 일이 생기는 이유는 자신이 감당할 수 없는 능력을 요하는 위치를 차지하기 위해 자신을 꾸며야 하기 때문이다.(팔방미인이 잘 하는 일이기도 하다.) 실패를 인정할 수 없기 때문에, 그는 허풍을 떨기도 하고 부족한 코드를 만들기도 하고 그보다 능력이 떨어지는 팀원들에게는 기술적인 변명을 하기도 한다.

모든 사람들은 완전함을 갖출 수는 없다. 위의 5가지 예시는 개발자를 기준으로 서술된 내용이지만 모든 프로젝트 업무에도 동일하게 적용이 가능하다. 자신이 과연 어떠한 유형에 속하는지 생각해 보고 서로간의 단점을 보완할 수 있는 시간을가질 수 있었으면 한다.

기획문서 이용하기

이전에 기획 및 테스팅 관련 책을 읽던 도중 다음과 같은 내용을 본 적이 있었다.

- 게임 기획서는 프로그래머들이 꼭 읽어야 한다.
- 프로그래머들은 게임 기획서를 읽지 않을 것이다.

진짜로 프로그래머들은 게임 기획서를 읽지 않을 것이다.(최근에 경험해본 프로그래머들은 기획서를 읽는 경우가 대부분이었다. 물론 이전에는 읽어보지 않는 경우를 많이 경험했다.) 매우 중오하다고 말하거나 읽어달라고 애원하거나 심지어는 초상금을 건다고 해도 프로그래머들은 기획서를 읽지 않을 것이다.
프로그래머들은 나무를 보지만 숲을 보지 못하고 기획자들은 숲은 보지만 나무를 보지 못한다는 글을 본적이 있다. 이 글에 어느정도 수긍할 수 있다.(물론 가끔 잎사귀를 보느라고 나무를 보지 못하는 프로그래머들이라는 예외도 있지만...) 나무를 보는 자세함 때문에 좋은 프로그램을 짤 수도 있는 것이겠지만, 완성된 제품에 대한 대강의 모형을 머릿속에서 그릴 수 있게 해주는 게임기획서 같은 긴 문서를 읽거나 받아들이지 않는 이유도 여기에 있다.
프로그래머가 기획서를 봐야할 이유가 있을까? 완성된 제품에 대한 상상을 하는 것은 프로그래머의 일이 아니라 기획 그룹의 일이다. 그러나 프로그래머들은 몇가지 이유에서 기획문서들을 읽을 필요가 있다. 첫번째 이유는 목표도 모르고 일을 맡아서 하면 사기도 저하되고 능률이 오르지 않기 때문이다. 두번째 이유는 일을 진행하면서 질문이 생길 때마다 디자이너가 대답하기 위해 묶여 있는 것보다 이쪽이 더 효율적이기 때문이다. 세번째 경제적인 이유때문에 몇명 안되는 사람들이 기획서를 쓰기는 하지만 여전히 모든 사람들의 좋은 아이디어를 모아 발전시키는 것이 완벽을 기하기는 더 좋은 방법이기 때문이다. 마지막으로 프로젝트의 비전을 그룹에서 함께 나누는 것은 전체적인 단결력을 강화하고 사기를 올리는 결과를 가져오기 때문이다.

게임 기획문서..

게임 개발에 참여하게 되면 기본적으로 다음 두가지를 접할 수 있다.(현실적으로 한가지만 접하게 되는 경우가 대부분이다.)

- 게임 기획서
- 기획자 노트

게임 기획서
게임기획서는 게임에 대해 자세히 설명한 문서로, 잘 읽고 이해하기만 한다면 독자는 완성된 제품의 모든것을 누앞에 그려낼 수 있을 정도로 쓰여 있어야 한다. 초기에 이 기획서는 게임에 대한 초기 프로토타입일 수도 있고 1년 후에 만들어낼 게임에 대한 상세한 묘사를 담고 있을 수도 있다. 게임기획서는 개발하는 도중에 새로운 변화들이 추가됨으로써 역동적으로 발전하게 된다.
열심히 만든 게임기획서를 가지고 프로그래머에게 가서 완성되었다고 말하면 그들은 뭐라고 말할까? 혹시 "그게 어떻게 완성된거야? 거기에 초인/불뿜는 몬스터도 들어있지 않는데.."라고 하지 않을까?
이러한 생각은 사람들이 '완성'이라는 말에대해서 잘못 이해했기 때문에 일어난다. 게임 개발에 있어서 완성이라는 말은 도큐멘트나 코드 모둘이 변하지 않을 거라는 뜻이 아니고 하나의 단계에서의 완성을 의미한다. 완벽하지 않아도 그 문서는 실제 공정에서 쓰여지게 된다. 혹시 도큐멘트나 코드를 만들던 사람이 불의의 사고를 당해 더이상 작업하지 못한다 하더라도 그가 하던 일을 중단할 필요는 없다. 그것이 일정한 단계까지 완성되어있다면 다른 사람들이 이어서 쓸 수도 있고 필요한 만큼 고쳐 쓸 수도 있다.
어찌되었든 완성이란 '끝났다'는 것을 의미하지 않는다. 완성이란 진행하는 단계의 완성을 의미하는 것이고 모든 단계가 완성되면 그 게임은 출시된다. 작업이 '끝났다'는 것은 생각할 수 있는 모든 요소를 다 집어넣고 코드, 게임 진행, 인터페이스, 그 이외 다른 부분에 있어서도 모든 일이 다 완결되었음을 말한다.

기획자 노트
기획자 노트는 기획서를 구상하는 동안 머리에서 굴러다닌 많은 생각들에 대해서 써내려간 문서이다. 만약에 새벽 2시에 봉투 뒷면에 끄적여 놓은 낙서가 마음에 든다면 그것을 노트에 붙인 후 설명을 붙이면 된다.
기획자 노트는 몇가지 이유에서 쓸모가 있다. 첫번째로 제작팀에게는 모든 문서들은 가치가 있다. 디자이너가 다음 게임에 대해서 공상하다가 의자에서 떨어져 다쳤다 해도 디자이너가 쓴 여러가지 문서들이 남아있는 한 프로젝트는 망하거나 내던져지지 않을 것이다. 두번째로 프로그래밍 코드에 대한 도큐멘트 비슷한 방식으로 유용하게 쓰인다. 게임 기획서의 한 문장은('두 유니트간의 화력비고'라든가 코인을 모으면 무엇으로 보상을 받는가?'등의 간단한 결정) 많은 시간동안의 심사숙고의 결과물이다. 그러나 누중에 '무엇이다'라는 것은 기억 할 수 있어도 '왜' 라는 것은 기억하지 못하게 된다.

'게임'이란

자신의 아이디어가 오락용 소프트웨어의 새로운장을 열만큼 엄청난 것이 아니라고 한다면 다음으로 가장 신경을 써야 할 부분은 그 게임을 '잘' 만드는 일일 것이다.

좋은 게임이라는 것은 플레이어가 무언가 새로운 것을 고안하고 그것을 잘 운용하였을 때 승리할 수 있어야 한다. 이것은 게임플레이라는 것의 본질에 매우 가까운 정의이다. 이 정의를 바꾸어 말하자면 "게임플레이는 플레이어로 하여금 전략을 짜도록 한다."이다. 이 말은 세상 모든 게임이(게임 장르로서의) 전략 시뮬레이션 게임이라는 뜻이 아니다. 이 말은 단지 테트리스에서 시작하여 최신게임에 이르기까지 그 게임을 잘 하기 위해서는 플레이어가 나름대로의 전략을 짜 내야 한다는 것을 의미한다.판매 혹은 서비스 되고 있는 게임들을 관찰해 보면, 게임이란 다음 중 한가지 이상의 목표를 달성하는 것을 목적으로 하고 있다는 것을 알 수 있다.

- 무언가를 모은다.(점수, 아이템)
- 영토를 확보한다.(바둑, 땅따먹기)
- 목적지에 먼저 도착한다.(레이싱)
- 발견(탐험, 추론)
- 다른 플레이어와의 대결

레이싱 게임이나, 대결, 영토뺏기 게임은 목표가 게임 내에서 확실히 보인다. 게임 중 누가 이기고 있는지를 언제나 금방 알 수 있기 때문이다. 이에 반하여 모으기 식 게임은 목표가 눈에 잘 보이지 않는 경우가 많은데, 이런 이유로 이러한 게임들은 대부분 플레이어가 모은 무언가의 양(점수, 아이템)에 따라 게임 내에서 보상을 해 주도록 디자인되어 있다.

- 대부분의 RPG에서 경험치를 모으면 캐릭터의 스킬이나 능력치를 향상시키는데 사용할 수 있다.
- 전략 게임에서 자원을 모으면 새로운 유닛을 생산하거나 기존의 유니트를 업그레이드 할 수 있다.
- 어드벤처 게임에서 아이템을 얻으면 새로운 퍼즐을 풀 수 있게 된다.

거의 모든 게임들은 2가지 이상의 목표를 가지고 있다는 점에 주목하자. 스타크래프트를 예로 들면 일단 경주형 게임의 요서를 가지고 있다. 플레이어들은 자원을 채굴할 수 있는 장소에 먼저 도착하기 위해 경주한다. 또한, 더욱 풍부한 자원을 모으기 위해 노력한다. 궁극적으로는 다른 플레이어를 쳐부순다는 목적이 있다.
게임 내에서 복수개의 목표를 설계할 때에는 이들을 서로 연동시키는 것이 중요하다. 만약 목표들 사이의 연동이 없으면 실질적으로는 아무런 상관도 없는 미니 게임들을 설계하고 있는 것이나 마찬가지이며 이들 미니 게임들은 절대 하나로 묶이지 않을 것이다.

당신이 가진 기본 아이디어를 게임에 반영하고자 하는 경우에는 우선 스스로에게 다음과 같은 질문을 해 보자.

- 게임의 목적은 무엇인가?
- 플레이어들은 그 목적을 어떠한 방법을 통해 이루는가?
- 게임은 실제로 어떠한 형태를 뛰게 될 것인가?
- 게임플레이를 위한 규칙은 무엇이 있는가?