2022/12/09

포네틱 알파벳 (Phonetic Alphabet)

영화에서, 혹은 군대나 비행장에서 특정 알파벳을 우리가 알고 있는 명칭이 아닌 다른 방식으로 부르는 것을 들은 적이 있을 것이다.
언어는 이야기하는 사람마다 발음이 다르고 나라별로도 발음이 약간씩 다르다. 이에 유사한 발음으로 인해 혼란이 생길 수 있는 부분을 방지하고자 표준화하여 부르게 된 발음이 이번에 다룰 "포네틱 알파벳 (Phonetic Alphabet)" 이다.

ex.) "A"는 "I" 혹은 "8" / "M"은 "N" / "D"는 "B"


2022/12/08

알아두면 편리한 테스트 업무 관련 용어들 (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

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

* 해커
: 개발자

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

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

* 파일럿 프로그램
: 정식 발매된 것은 아니고 정식 발매 전 테스트용

2016/07/24

2016년 크리티카 여름 업데이트!!

2016 여름 업데이트를 기다리면서!!
이번에는 흥할 수 있는 업데이트로 가득하기를 기원합니다!!

http://www.kritika.com/Gate/160526_Season3

2013/07/13

Sword Art Online 09 - Alicization Beginning -

프롤로그 1 인계력 372년 일곱째 달

1

도끼를 쥔다.
든다.
내리친다.
 동작은 겨우 그뿐이지만, 조금이라도 마을을 놓았다간 도끼는 빗나가 단단한 나무껍질이 두 팔에 가차 없는 반동을 안겨준다. 호흡, 박자, 속도, 체중이동, 이 모든 것을 완벽하게 제어해야 비로소 무거운 도끼의 날이 간직한 위력을 모두 나무에 전달해, 높고 맑은 소리가 기분 좋게 울린다.
 머리로는 알아도, 실천이 되면 이게 좀처럼 마음먹은 대로 되지 않는다. 유지오가 열 살 되던 해 봄에 이 일을 맡은 후로 벌써 두 번째 여름이 왔지만, 그런 회심의 일격은 열 번에 한번 나올까 말까 했다. 도끼 쓰는 법을 가르쳐준 전임자 가리타 할아버지는 백발백중인 데다 무거운 도끼를 아무리 휘둘러도 피곤한 기색조차 보이지 않았는데, 유지오는 겨우 50번 만에 두 손이 마비되고 어깨가 시큰거려 팔을 들 수 없었다.
 "마흔.....셋! 마흔.....넷!"
 정신을 바짝 차리고자 한껏 큰 소리로 숫자를 세며 도끼를 거목 밑동에 꽂아댔지만, 솟아나나 땀에 시야기 부옇게 흐려지고 손바닥은 미끄러졌으며 명중률은 점점 떨어졌다. 반쯤 자포자기한 심정으로 꽉 쥔 도끼를 몸과 함께 휘둘렀다.
 "마흔.....아홉! 쉰.....!"
 마지막 일격은 손이 완전히 빗나가, 밑동에 깊이 파인 도끼 자국에서 멀리 떨어진 나무껍질에 부딪치는 바람에 귀에 거슬리는 금속성이 울렸다. 눈에서 불똥이 튈 정도로 큰 반동에 유지오는 견디지 못하고 도끼를 떨어뜨리곤 그대로 몇 걸을 휘청휘청 물러나 두꺼운 이끼 위에 털썩 주저앉았다.
 거친 호흡을 되출이하고 있으려니, 오른쪽에서 웃음기를 머금은 목소리가 들렸다.
 "좋은 소리가 난 건 50번 중에 세 번뿐이었어. 전부 합치면, 어, 마흔한 번인가? 보아하니 오늘 시랄 수(水)는 네가 쏴야겠다. 유지오."
 목소리의 주인은 조금 떨어진 곳에 드러누운 동갑내기 소년이었다. 당장은 대꾸도 못하고, 앉은 채 손을 더듬어 가죽 물주머니를 찾았다. 이미 미적지근해진 물을 벌컥벌컥 들이켜 겨우 한숨 돌린 유지오는 뚜껑을 꼭 잠그며 말했다.
 "흥, 그러는 너도 아직 마흔세 번밖에 안 되잖아. 금방 따라 잡을 거야. 자, 네 차례라고.... 키리토."
 "네, 네."
 유지오와 어렸을 적부터 함께 놀았던 둘도 없는 친구이자, 작년 봄부터는 이 우울한 <천직(天職)>의 단짝이기도 한 키리토는 땀에 젖은 까만 앞머리를 쓸어 올리더니 두 다리를 위로 쭉 펴고 이영차 몸을 일으켰다. 하지만 금방 도끼를 주우러 가지는 않고 손을 허리에 대며 머리 위를 올려다본다. 그 모습에 이끌려 유지오도 시선을 하늘로 향했다.

2013/01/28

QA로서의 건의 방법


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

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

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

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



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

2012/07/02

통찰력과 직관력

* 통찰력
 : 사물이나 현상의 환히 꿰뚫어보는 능력
 (유사 : 관찰력)

* 직관력
 : 판단이나 추리따위의 사유 작용을 거치지 않고 대상을 직접적으로 파악할 후 있는 능력

통찰력은 사물이나 현상을 더욱 넓은 시각으로 볼 수 있는 안목이 생길 때 얻을 수 있는 반면 직관력은 볼 수 없는 것을 볼 수 있게 되었을 때 얻을 수 있다.

통찰력은 높은 망루에서 다양한 각도로 볼 수 있을 때 생기며, 직관력은 더 깊은 곳에서 볼 수 있는 안목을 얻을 때 생긴다. 통찰력은 지금까지와는 다른 공부를 할 수 있을 때 생기는 반면 직관력은 깊이 있는 경험을 통해서 얻을 수 있다.

2012/06/28

액션 게임에서의 타격감이란...

흔히들 액션 게임을 좋아하는 사람들은 다음과 같이 말하곤 한다.
"저 게임은 타격감이 쩔어(??)!"
"그래픽은 좋은데 타격감은 별로야"

이렇게 쉽게 입에 오르내리는 타격감의 정의는 무었일까?

이 질문에 대해 속시원하게 대답해 줄 수 있는(단순히 답변만이 아니라 누구나 공감할 수 있는..) 사람이 있을까? 이 질문에 대한 나의 생각은 다음과 같다.

타격감(打擊感)

* 유저의 지시를 받은 캐릭터가 다른 캐릭터를 공격하는 순간 유저가 느끼게 되는 반응 혹은 느낌
* 사물이 부딪혔을 때 상황과 최대한 유사하도록 묘사하는 것
* 두 사물의 충돌 질감 (소리+물리적 반작용)과 시각적 효과(파편+금)
* 상대방을 공격했을 때 돌아오는 피드백

이런 타격감을 살리기 위해 게임에서 사용하는 대표적인 방법은 다음과 같다.

* 타격 순간에 걸리는 듯한 느낌을 이용한 연출 기법
* 화려한 이펙트
* 현실감 있는(그러나 때로는 과장된) 사운드
* 타격 대상의 리엑션 (맞은 쪽으로 날라가기 등등..)

사실성 있는 타격감을 보여주기 위해 현실이라 착각할 정도의 리얼함을 제공하기도 하지만 때로는 그 사실감이 타격감을 반감 시키기도 한다.

지금 만들고 있는 게임에서 가장 많은 노력을 투자하는 것이 초(超) 액션인데.. 왜 거듭될 수록 내 눈에는 뭔가 허전하게 보이는지....

이쯤 읽었으면 어떤 게임인지 짐작이 가겠지....

2009/01/07

Happy New Year~! (새해 복 많이 받으세요~!)

2009년 새해가 밝았습니다.
새해 복 많이 받으세요. (블로그에 오는 사람은 없지만 혹시라도 실수로 들어오신 분들도 새해 복 많이 받으세요. ^^)

2008/04/14

혈액형별 선호하는 공간

이미지를 클릭하시면 본래 사이즈로 확인이 가능합니다.

혈액형별 산타크로스

이미지를 클릭하시면 본래 사이즈로 확인이 가능합니다.

O형 부부 사이에서도 AB형 자식이 태어난다고?

그동안 단순하게만 생각했던 혈액형에 관한 상식을 다시 깨우쳐준 글입니다.

어느 유전자 감식 회사의 문의게시판에 이런 글이 올라왔다. "남편과 저는 모두 O형입니다. 그런데 아기가 A형이에요. 아기는 남편과 똑같이 생겼습니다. 남편과 저의 혈액형은 모두 확실한 데 어떻게 이런 일이 있을 수 있는지요. 남편 몰래 유전자 검사를 받고 싶은데 남편의 머리카락만으로 가능한지요?"

상담게시판 담당자는 모근(毛根)이 달린 남편의 머리카락을 보내면 유전자 검사를 받을 수 있으니 전화 상담을 받으라는 답글을 남겼다. 남편과 똑같이 생겼으니 남편의 애일 가능성이 높다. 유전자는 거짓말을 하지 않으니까. 그런데 '거짓말 하지 않는 유전자'가 문제다. 엄마와 아빠가 모두 O형이면 아기도 O형이어야 하는 게 정상적인 중학교 과학교육을 받은 사람의 상식이지만 이 상식도 예외가 있다.

O형 부모 사이에서도 A형이나 B형 자녀가 태어날 수 있다. 부모의 어느 한쪽 혈액형이 '봄베이(Bombay) O형'인 경우다. 그리고 부모가 모두 봄베이 O형이라면 AB형 아기도 가능하다. 봄베이 O형은 처음 발견된 인도의 봄베이 지역을 따서 이름을 붙였다.

봄베이 혈액형을 이해하려면 중학교 생물 시간에 배운 '유전'을 잠깐 되새겨 보아야 한다. '유전자형'과 '표현형'이란 단어가 기억나는가? ABO 혈액형에서 A, B, AB, O형 혈액형은 표현형이다. O형은 누구에게나 피를 줄 수 있지만 O형 피만 수혈할 수 있다는 식의 혈액형의 상관관계는 익히 알고 있는 지식이다. 아무 혈액이나 수혈 받지 못하는 이유는 원래 갖고 있던 혈액과 수혈한 혈액이 엉기기 때문이다.

혈액이 섞였을 때 엉기거나 엉기지 않는 것은 무엇이 결정할까? 먼저 혈액의 구성성분을 살펴보자. 혈액을 가만히 두면 혈구와 혈청으로 분리되는데, 혈구는 적혈구와 백혈구 같은 고체성분이고 혈청은 맑은 노란색 액체다. 혈구는 항원(응집원)으로, 혈청은 항체(응집소)로 작용해 둘이 맞으면 엉기는 것이다.

A형 혈액의 적혈구에는 A라는 항원이, B형 적혈구에는 B라는 항원이 있다. AB형 적혈구에는 A, B 항원이 모두 있으며, O형 적혈구에는 A, B 항원이 없다. 한편 A형 혈청에는 anti-B 응집소가 있어 B형 적혈구가 들어오면 엉긴다. B형 혈청에는 anti-A 응집소가 있어 A형 적혈구가 들어오면 엉긴다. O형 혈청에는 anti-A, anig-B 응집소가 모두 존재해서 A형 적혈구, B형 적혈구 모두 엉긴다. AB형 혈청에는 응집소가 없으니 엉기지 않는다.

여기서 잠깐, A형 환자에게 O형 혈액을 수혈할 때, 넣어주는 O형 혈청이 A형 환자의 적혈구와 만나 엉기지 않을까 하는 의문을 제기하는 사람이 있을지 모른다. 맞다. 하지만 수혈하는 O형 혈청은 환자 몸속의 전체 혈액에 비하면 적은 양이기 때문에 혈액에 섞이면 희석되어 큰 문제가 되지 않는다. 그래서 병원에서는 큰 사고로 대량의 혈액이 필요할 때 가급적 같은 혈액형의 혈액을 수혈한다.

그렇다면 봄베이 O형이란 무엇일까? 봄베이 O형은 분명히 A형 또는 B형 '유전자'를 갖고 있지만 적혈구에는 A형 또는 B형 '항원'이 없는 경우다. 그래서 어떤 응집소와도 엉기지 않는다. 따라서 유전자형은 A 또는 B형이지만 표현형은 O형이 되는 것이다.

이게 무슨 말일까? H, A, B 항원의 구조를 살펴보면 A, B 항원은 H 항원이 먼저 만들어진 뒤 A, B 항원이 붙어있는 것을 알 수 있다. 봄베이 O형은 어떤 이유에서 H항원이 만들어지지 않아 다음에 만들어져야 할 A항원이나 B항원이 만들어지지 않은 것이다.

A항원 또는 B항원을 만드는 유전자가 있으니 자식에게 유전자는 그대로 전달되어 '중학교 지식'으로는 있을 수 없는 O형 둘이 만나 A형, B형, AB형이 태어나는 것이다. 앞서 소개한 문의자나 남편의 유전자 검사를 해보면 둘 중 하나 이상이 봄베이 O형으로 나타날 것이다.

우리나라에는 봄베이 O형 외에도 여러 가지 희귀혈액형이 있다. 전체 인구의 0.4퍼센트를 차지하는 비교적 풍부한(?) Rh형은 ABO식 혈액형과는 별도로 Rh항원의 유무에 따라 구분하는 혈액형 판별법이다. 대부분의 사람들은 Rh항원이 있는 Rh+형이다. ABO와 별도로 구별하는 것이기 때문에 Rh-형은 혈액형을 'A, Rh-'라는 식으로 표기한다.

cis-AB형은 A, B 항원을 만드는 유전자가 염색체 하나에 동시에 들어가 있는 경우다. 예를 들어 AB형과 O형이 만나면 A형 혹은 B형이 나오지만, cis-AB형인 경우 AB형 혹은 O형으로 나온다. 이 외에도 -D-(바디바)혈액형, Duffy(a)-(더피 에이 음성) 혈액형, 밀텐버거 혈액형 등이 있다.

최근 Rh-형 혈액을 구한다는 방송자막이 드문 까닭은 Rh- 혈액형이 늘어서가 아니라 'Rh 음성봉사회'가 활발히 활동하면서 필요한 혈액을 비교적 원활히 공급하고 있기 때문이다. 오히려 헌혈하는 사람이 적어 '희귀혈액형'보다 '일반적인 혈액'이 부족하다는 것이 문제일 것이다.

인류 역사상 최초로 사람에게 수혈을 한 것은 1667년이지만, 혈액형은 1901년에야 규명되어 혈액형에 따른 수혈이 가능하게 됐다. 사람이든 동물이든 여러 종류의 혈액형이 있어서 수혈할 때마다 구별해야 하는 것은 불편하게 느껴진다. 조물주는 어떤 이유로 자연선택에 불리하게 작용할 이런 '불편'을 숨겨두었을까? (글 : 이정모 과학칼럼니스트)

자연의 합성

이전에 어디선가 다운받아 재미있게 봤던 그림입니다 ^^
그리신분의 센스가 돋보이네요...

일본 화투

- 일본 화투게임 "토비다세! 트러블 화투 도중기"를 하기위해 일본의 화투룰을 알아보던 중 4가지 종류의 게임 방식을 알게 되었습니다. 기본적으로 한국에서 하는 룰과 상당 부분이 유사하지만 훨신 간단하여, 쉽게 배울 수 있습니다. 참고로 일본에서는 화투=야쿠자 라는 개념이 일반적인지라 그다지 좋은 이미지는 아니라고 합니다.

1. こいこい(코이코이)

2명이서 즐기는 화투 게임으로, 바닥에 8장을 깔고 10장씩 들고 진행합니다. 나머지 20장은 덮어 쌓아 놓고 시작을 하는데, 놀이 방법은 우리의 맞고 게임과 비슷하고 점수계산법이 약간 차이가 있습니다.

일단 점수가 나면 계속경기를 진행할 것인지를 결정해서 ‘코이(こい, 来い)’를 외치게 되는데, 여기서 ‘코이’는 ‘Go’가 아니라, 우리말의 ‘와봐! 덤벼봐!’정도의 말로 이해하면 될 것 같습니다. 아마 이 말이 우리나라로 들어오면서 발음이 비슷한 Go로 바뀌었고, 끝내는 GO STOP으로 그 명칭도 바뀐 것으로 보입니다. 하지만 일본에서의 게임명칭은 그대로 ‘코이코이(こいこい, 来い来い)’이지요.

아무튼 점수가 나면 그대로 그 판을 끝낼 수도 있지만, 더 높은 점수를 내고 싶거나 상대방이 점수가 나기 어려워 보일 때는 ‘코이(こい, 来い)’를 외쳐 게임을 속행할 수 있습니다. 만약 ‘코이(こい, 来い)’를 한 경우 새로운 점수를 추가하지 못하면 그 판을 끝낼 수 없습니다. 반대로 상대방이 점수를 낼 수도 있기 때문에 유념하여야 하며 ‘코이(こい, 来い)’의 타이밍이 이 게임의 키포인트인 것은 우리나라와 마찬가지인 것 같습니다.

<점수계산법>

점수는 정하기 나름이지만 일반적으로 광 5장을 전부 모은 경우 15점(광이란 글자는 쓰여 있지 않습니다.), 비광 이외의 광 4장을 전부 모은 경우 13점, 비광을 포함해서 광을 4장 모은 경우 12점, 비광 이외의 광을 3장 모은 경우 6점으로 계산합니다. (지역에 따라 사광 10점, 비사광 8점인 경우도 있으며 3광은 족보에서 제외하는 경우도 있습니다.)

3광과 9월 열끗의 2장을 모은 경우(花見=꽃구경에 한잔) 3점, 8광과 9월의 열 끝의 2장을 모은 경우 (月見=달구경에 한잔) 3점입니다. (이 역시 지역에 따라서 족보에서 제외되는 경우도 있습니다.)

멧돼지, 사슴, 나비(いのしかちょう=이노시카쵸, 저록접)의 3장을 모은 경우엔 3점, 우리가 흔히 멍텅구리라고 하는 10끗짜리는 5장이 1점으로 5장 째부터 1점씩 계산하게 되고, 홍단 (赤短=1, 2, 3월의 5끗짜리 패) 3장을 전부 모은 경우에 6점, 청단(青短=6, 9, 10월의 5끗짜리 패) 3장을 전부 모은 경우 6점, 그리고 5끗짜리 패를 5장 이상 모은 경우 5장 째부터 1점씩 계산합니다.

또, 피를 10장 이상 모은 경우에 10장 째부터 1점, 패를 받는 시점에서 같은 달의 것이 4장 모두 들어온 경우(親権)엔 1점이나 경기에 승리를 한 것으로 하며, 판이 끝나고도 양쪽 모두 점수를 못났을 경우에 선 의 승리로 하여 6점으로 계산하는데, 9월의 10끗짜리나 비의 10끗짜리는 피로도 이용 가능한 것도 우리와 같습니다. 그러고 보니 점수계산 방법도 우리의 맞고와 비슷합니다. (지역에 따라 총통은 족보에서 제외하는 경우도 있으며, 9월&12월 열끗을 쌍피로 사용하지 않는 경우도 있습니다.)


2. 하치하치

3명이 즐기는 화투 게임으로 바닥에 6장, 그리고 각각 7장씩 나누어가지고 진행합니다. 나머지 21장은 바닥에 덮어 쌓아놓고 시작을 하는데, 놀이 방법은 우리의 고스톱 게임과 비슷하고 3명이상인 경우는 패를 보고나서 쉴 것인지 참여할 것인지를 결정하게 하는 것도 우리의 고스톱과 비슷하지만, 쉬는 자는 10점을 내놓아야 하며 승리자에게 이 점수가 합산 된다는 것이 다릅니다.

일반적으로 패를 나누어 받으면 손에 든 화투에 ‘야쿠(役)’, 즉 우리가 흔히 말하는 ‘약’이 있는지를 확인하고 시작을 하게 되는데, 점수계산방법은 위의 ‘코이코이(こいこい, 来い来い)’에서와 같으나, 처음 바닥에 1광 3광 8광중 1장이 있었을 때, 점수를 두 배로 계산하기도 하고, 비광과 오동의 광중 1장이 있을 때는 4배로 계산하기도 하는 등 지역이나 즉석에서의 룰에 따라 차이가 있습니다.

3. はなあわせ(하나아와세)

하나아와세는 그림만 맞추어 가면 됨으로 놀이 법이 가장 간단하며, 이렇게 그림을 맞추어 가면서 점수를 취득한다하여 하나아와세(はなあわせ, 花合わせ)란 명칭이 붙은 것으로 추측됩니다.

놀이 방법은 우리의 민화투와 같고, 점수도 광은 20점, 열 끗 10점, 띠 5점, 피 1점으로 우리와 같이 계산하며, 약의 경우도 5광은 100점, 비광을 제외한 4광의 경우는 50점, 마츠키리보-즈(まつきりぼうず, 松桐坊主)라 하여 송광, 오동의 광, 팔광을 모두 취하면 30점, 청단 홍단은 모두 30점, 이노시카쵸(いのしかちょう, 猪鹿蝶)라 하여 멧돼지, 사슴, 나비의 석장을 모두 취하면 30점입니다.

그리고 삼광과 팔광, 그리고 9월의 10끗을 모두 취하면, ‘달구경하며 한잔, 꽃구경하며 한잔’이란 의미로 30점, 팔광과 9월의 10끗을 취하면 ‘달구경하며 한잔’이란 의미로 20점, 삼광과 9월의 10끗을 취하면 ‘꽃구경하며 한잔’이란 의미로 20점, 그리고 비의 넉 장을 모두 취하면 20점으로 계산하며, 약의 점수와 취득한 점수를 합하여 일괄계산을 합니다.

4. 오이쵸카부

오이쵸카부는 화투를 사용하는 게임의 한가지로 간단히 카부라고 줄여서 말하기도 합니다. 대부분 이 놀이에서 화투를 사용하나 요즘은 카드나 카부 전용카드까지 만들어져 사용되기도 합니다. 이 놀이 역시 우리나라에서 ‘가보’로 잘못 알려져 있는 바로 그 놀이와 마찬가지로, 손에 든 패와 뒤집은 화투의 숫자를 합하여 9에 가까운 사람이 승리를 하는 것입니다.

특히 이 게임에서는 0을 부타(ブタ:돼지), 1을 핑(ピン), 2를 니조-(ニゾウ), 3을 산타(サンタ, 三太), 4를 요츠야(ヨツヤ), 5를 고케(ゴケ), 6을 록포-(ロッポウ, 六法), 7을 나키(ナキ), 8을 오이쵸(オイチョ), 9를 카부(カブ)라고 부르는데, 오이쵸카부의 어원도 가장 좋은 8의 오이쵸와 9의 카부가 합쳐져서 생겨난 말입니다.

특히, 이 게임에서는 몇 개의 특수한 ‘야쿠(やく, 役)’가 몇 개 있는데, 이에 대하여 잠시 살펴보면 4와 1이 오는 경우를 ‘싯핑(シッピン, 四一)’이라 하여 선에게만 유효하며, 이것이 들어오면 선은 이 판에 건 모든 후순위자의 점수를 모두 빼앗게 됩니다. 또 9와 1일 경우도 ‘구핑(クピン, 九一)’이라 하여, 역시 선에게만 유리하며 이 역시 이 판에 걸려있는 모든 사람들의 점수를 빼앗을 수 있습니다.

그리고 석장모두가 같은 달이 들어올 경우는 광풍이란 의미의 아라시(アラシ,嵐)라 하여, 싯핑(シッピン, 四一)’이나 ‘구핑(クピン, 九一)’에 위에 있으며, 판에 걸린 모든 점수의 3배를 받을 수 있고, 누구에게나 효과는 똑같습니다.

위에서 こいこい(코이코이), 하치하치, はなあわせ(하나아와세), 오이쵸카부에 대한 설명은 했지만 실제로는 "토비다세! 트러블 화투 도중기"에 사용 되었던 룰인 こいこい(코이코이)를 제외하고는 상세하게 조사하지는 못했습니다. 나중에라고 기회가 된다면 다른 룰에 대해 좀더 자세하게 정리하는 시간을 가지도록 하겠습니다.

2008/03/19

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

부서 이야기

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

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

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

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

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

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

스크린으로 부활하는 추억의 만화영화

소재의 고갈일까? 할리우드의 레이더는 바닥을 드러낸 자국의 코믹스를 거쳐 해외의 만화판으로까지 촉수를 뻗치기 시작했다. 개봉을 앞둔 워쇼스키 형제의 <스피드 레이서>부터, 영화화된다는 소식에 국내의 만화 팬들을 경악케 했던 <드래곤볼>까지. 그야말로 봇물 터지듯이 왕년의 만화영화들이 영화화되고 있는 형국인데…. 그런 만화영화를 보며 자랐던 나 같은 세대에게야 쌍수를 들고 환영할 만한 일이다.

사실 트렌드와도 같은 이런 현상은 작년 <트랜스포머>의 대성공 덕분이다. 극장흥행만 7억달러, DVD 및 부가판권 판매로만 3억달러. 합이 10억달러가 넘는 수익을 파라마운트사에 안겨준 이 영화는 로봇도 블록버스터 영화의 매력 있는 소재가 된다는 것을 증명했다. 어디 이뿐이랴. 개봉과 동시에 완구회사 하스브로에서 출시한 트랜스포머 변신로봇완구들은 날개 돋친 듯 팔려나갔으니. 그런 대성공은 영화를 찍기 전 “당최 장난감 영화 따위를 만든다는 게 가당찮은 일이냐”며 마뜩찮은 태도를 보이던 감독 마이클 베이를 머쓱하게 만들 정도였다.

<트랜스포머>의 대성공은 감쪽같이 실사화를 가능케 한 기술력에 대한 확인이기도 했다. “이제 컴퓨터 그래픽으로 표현 불가능한 대상은 없다”란 자신감과 함께 흥행에 대한 확신까지 더해지면서 할리우드의 대형 제작사들은 너도나도 비슷한 류의 영화제작에 뛰어들게 된 것. 이런 흐름이 그 레이더를 일본이나 심지어 유럽까지 뻗치게 한 셈이다.(트랜스포머도 그 원조는 80년대 초반 일본의 완구회사 다카라에서 만든 변신로봇이었다.) 솔직히 그 대상이 일본 애니메이션에 집중되어 있어 원작이 될만한 작품이 전무한 우리나라의 현실이 씁쓸하기도 하지만. 그 바람을 타고 아기공룡 둘리나, 라이파이, 독고탁 등 우리나라 추억의 만화 캐릭터들도 실사화될는 지도.^^

분명한 건 우리에게 무척이나 익숙한 만화영화들을 할리우드에서 새롭게 성형한 모습으로 줄줄이 만날 예정이란 것이다. 어쩌면 향후 10년간 할리우드 영화 제작의 한 패러다임이 될 수도 있는(한동안 미국 마블과 DC 코믹스의 영화화가 대세였던 것처럼) 추억의 만화영화 실사화하기. 어떤 왕년의 캐릭터들이 화려한 디지털 의상을 갈아입고 대기 중인지 살펴 볼까나.
.
.
.
스피드 레이서 (2008년 5월 개봉 예정)
최근 실사화되고 있는 영화 중 가장 고참격이다. 처음 TV애니메이션으로 제작된 게 1967년이니. 원작명은 <마하 GO GO GO>이며 우리나라에서도 <달려라 번개호>란 이름으로 방영되어 큰 인기를 거뒀더랬지. 1997년 34부작으로 새롭게 탄생한 리메이크 버전이 미국에서 <스피드 레이서>란 이름으로 방영되어 큰 인기를 거뒀고, 열렬한 팬인 <매트릭스>의 워쇼스키 형제가 영화화하기로 결심. 비 등 국내 연기자들까지 출연진으로 합세하며 현재 제작 마무리 단계란다. 워쇼스키 형제가 팝스 레이서 역을 맡은 존 굿맨에게 1967년 원작에서의 카이젤 수염까지 기르라 요구했다니 원작과 전혀 생뚱맞은 모습으로 나올 것 같지는 않다.


드래곤볼 (2009년 4월 개봉 예정)
이 만화의 위대함을 어떻게 설명할 수 있을까? 몇 가지 미사여구로는 도저히 표현할 수 없을 정도로 도리야마 아키라의 <드래곤볼>은 만화 역사상 가장 굵직한 작품이다. 1984년 일본의 <소년점프>에 연재된 뒤 일본 출판만화의 공식을 바꿔놓았고 한국의 만화시장까지 점령했으며(1990년대 초반 아이큐점프에 연재되었던 <드래곤볼>은 한국만화시장을 꼭대기까지 끌어올렸다 다시 그 끝을 알 수 없는 바닥을 치게 한 양날의 검 같은 존재다.), 뒤이어 제작된 수많은 버전의 애니메이션 역시 공전의 히트를 쳤다. 이런 ‘망가’의 상징과도 같은 <드래곤볼>을 일본, 한국도 아닌 미국에서 영화화한다니 생뚱맞아도 이렇게 생뚱맞은 소식이 없다. 이연걸 주연의 <더 원>을 만든 중국계 제임스 왕 감독이 연출을 담당하고 야무치 역으로 god의 박준형이 출연하는 등 어떻게든 동양적인 정서를 넣고자 노력은 하는 것 같은데 솔직히 기대 반 우려 반이다. 뭐 할리우드의 뛰어난 기술력으로 표현될 에네르기파라든지, 원기옥이라든지, 광마참 같은 등장인물들의 필살기를 보는 재미는 있겠지.참! 우리들의 영웅 손오공 역에는 스티븐 스필버그 감독의 <우주전쟁>에서 아버지 톰 크루즈 속 어지간히 태우던 철없는 아들 역을 맡았던 저스틴 채트윈이 맡는다고 한다. 흠, 서양인이 연기하는 손오공이라, 글쎄….


아키라 (2009년 여름 개봉 예정)
1988년 제작된 오토모 가츠히로의 <아키라>는 관객보다는 수많은 만화가 및 영화감독들에게 지대한 영향을 미친 작품이다. 미국에도 재패니메이션을 상징하는 작품으로 수많은 마니아들을 거느리고 있는 불세출의 걸작. 인간의 상상력으로 묘사할 수 있는 가장 매혹적인 디스토피아라는 극찬과 함께 이제까지 실사화된다는 루머가 수없이 떠돌았다. 결국 판권을 가지고 있는 일본 강담사의 선택을 받은 영화사는 할리우드의 워너 브라더스. 아직 구체적으로 결정된 사항들이 부족해 로우리 로빈슨이라는 신인 감독이 뉴욕을 배경으로 2부작에 걸쳐 제작한다는 정보만 알 수 있을 뿐이지만 개인적으로 가장 기대되는 작품이다. 주인공 가네다와 그의 친구들이 몰던 바이크가 어떻게 실사화될지 상상만 해도 흥분된다.^^


G.I 조 (2009년 여름 개봉 예정)
나 같은 서른 전후의 남자들에게는 트랜스포머보다는 G.I 조 장난감을 갖고 놀던 기억이 더 선연하다. 당시 미국의 완구회사 하스브로로부터 판권을 가져 온 영실업에서 거의 백종에 달하는 G.I 유격대 시리즈를 내놓았기 때문. 그런데 당시로선 가격이 만만치 않아 잘 사는 친구가 잔뜩 사 모은 장난감들을 보며 무척 부러워했던 기억이 난다.^^; 최근의 트렌드와는 어긋나있는 자국 캐릭터의 영화화지만 부가판권 판매에서만큼은 <트랜스포머>를 능가할 폭발성을 갖고 있으리라 예상된다. 앞서 이야기했던 것처럼 어린시절 갖고 놀던 G.I 조에 대해 호의적인 추억을 갖고 있는 어른들이 세계적으로 무지 많기 때문. 미국 경매 사이트 이베이에서 가장 비싸게 낙찰되는 완구류가 하스브로에서 만든 G.I 조 초기작일 정도다.(조잡해 보이는 완구 하나가 만 달러가 넘는 경우가 허다하다.) 파라마운트에서 하스브로와 손잡고 이룩했던 <트랜스포머>의 흥행을 예상하고 있는 초기대작. 시에나 밀러, 조셉 고든 레빗, 레이 파크 등 개성있는 출연진들의 분장과 연기도 기대할 만하다.


갓차맨 (2009년 개봉 예정)
“슈파슈파슈파슈파~ 우렁찬 엔진 소리…”로 시작되는 독수리 오형제의 주제가를 모르는 30대가 있을까. 원제인 <과학 닌자대 갓차맨>보다 독수리 오형제(오남매가 맞겠지만-ㅅ-;)가 친숙한 이 애니메이션 역시 할리우드에서 영화화된다. 감독이 <닌자 거북이> 실사판을 만든 케빈 먼로라니 대략 좌절이긴 하지만 불새가 되어서 싸우는 우리 형제들을 실사로 만나는 것은 실로 반가운 일. 오형제 역은 대부분 서양 배우들이 맡겠지만 둘째인 콘돌 ’죠’ 역만큼은 개성있는 동양계 배우가 했으면 하는 바람이 간절하다. 디스코 바지와 몸에 쫙 달라붙는 티셔츠 등 오형제들이 입었던 70년대 유행패션도 꼭 재현해 주길.^^


아스트로 보이 (2009년 개봉 예정)
데즈카 오사무의 걸작 <아톰>도 할리우드에서 제작된다. <아톰>은 이미 2003년 세련된 모습의 리메이크 극장판으로 제작된 바 있고 <몬스터> <20>의 우라사와 나오키가 데즈카 오사무에게 바치는 오마주인 만화 <플루토>를 연재 중일 정도로 재패니메이션의 상징과도 같은 존재다. 할리우드에서 <아톰>의 영화화에 눈독을 들인 이유는 극장 수입보다는 캐릭터, 완구 등의 부가판권 수입에 거는 기대가 더 커서일 듯.(아스트로 보이 티셔츠는 미국에서 꽤 인기 있는 아이템이란다.) 실사가 아니라 3D 애니메이션으로 제작될 예정이며 감독 역시 <누가 로저래빗을 모함했나> <월레스와 그로밋> 등의 제작에 참여한 애니메이터 데이비드 보워스 감독이 낙점됐다. 아톰 목소리를 맡을 배우는 <어거스트 러쉬>의 귀여운 소년 프레디 하이모어란다. 글쎄, 귀여운 외모라면 몰라도 사춘기가 임박한 소년의 목소리는 좀 걱정되는데^^;;


볼트론 (2009년 개봉 예정)
어릴 때 진정 갖고픈 장난감이 있었으니 바로 백수왕 고라이온이었다. 5마리의 사자가 합체하면 거대한 로봇으로 탄생되는 고라이온. 그야말로 트랜스포머 따위는 ‘쨉’도 안 되는 변신합체로봇계의 로망과도 같은 존재였으니. 아버지에게 조르고 졸라 생일선물로 받고선 입이 함지박만하게 벌어졌던 기억이 아직도 생생한데.^^ 미국에서도 <볼트론: 우주의 수호자>란 이름으로 변형되어 인기를 얻은 이 로봇 애니메이션을 20세기 폭스에서 실사 영화화한다. 한참 파라마운트에서 제작 중인 <트랜스포머2>에 대적하기 위한 20세기 폭스의 야심작이려나. 예정대로 잘 만들어진다면 가오가이거나 메칸더V 등 웬만한 일본 거대 로봇들은 스크린을 통해 만날 수 있을 듯 하다.


로보테크 (2009년 개봉 예정)
일본 로봇 애니메이션의 양대산맥 <기동전사 건담>과 <신세기 에반게리온> 사이에 또 하나의 걸출한 작품이 있었으니 바로 <초시공 요새 마크로스>다. 1982년 TV 시리즈로 첫방영을 한 뒤 1984년 극장판 <마크로스: 사랑, 기억하고 있습니까>로 공전의 히트를 기록한다. 1980년대 후반 미국에 <로보테크>란 이름으로 건너가 엄청난 인기를 끌면서 VF-1J 발키리를 표현한 완구가 불티나게 팔렸었다. 특유의 매커니즘을 보여 준 VF-1J 발키리의 로봇 디자인과 여주인공 린 민메이의 아름다운 모습이 20년이 훨씬 지난 지금도 참신한 작품. 1983년 김청기 감독이 제작한 <스페이스 간담 브이>가 이 <초시공 요새 마크로스>를 그대로 표절했다는 시비에 시달리기도 했다. <스파이더맨>시리즈의 토비 맥과이어가 이 로봇애니메이션에 푹 빠져 유년시절을 보냈다는 것은 유명한 사실. 그래서인지 토비 맥과이어는 <로보테크>란 이름으로 실사화되는 영화에 주연 뿐 아니라 제작자로도 참여한다.


스머프 (2008년 11월 개봉 예정)
“랄~랄라랄라라 랄라랄랄라” 흥겨운 노래를 부르며 숲으로 소풍을 가던 푸른 꼬맹이들. 역사상 가장 매력적인 요정들인 스머프를 어찌 잊을 수 있으랴. 50년도 더 묵은 벨기에 태생의 이 만화는 1980년 미국에서 애니메이션화된 이후로 국내에서도 큰 인기를 끌었다. 악역인 가가멜과 아즈라엘은 얄미운 친구들 별명으로 딱이었고, 팬시며 옷에다 스머프 스티커를 붙이고 다니는 아이들도 꽤 많았더랬다. 공산주의 사회의 작은 축소판이라는 재밌는(?) 루머가 돌기도 했더랬지. 이 스머프를 파라마운트사에서 3D로 재탄생시킨다니 어떤 3D 애니메이션보다 기대되는 게 사실. 어떤 할리우드 배우가 성우로 참여할 지도 궁금하고 특히 가가멜과 아즈라엘이 어떻게 표현될지 무척 기대된다. <슈렉>을 능가하는 캐릭터 파워를 발휘하리라 예상.

※위에 언급된 영화들은 모두 할리우드에서 제작되는 작품들. <신세기 에반게리온> <건담> <타임보칸> <20> 등 현재 일본에서 영화화 준비 중인 만화들도 많다. 뭐 <데스노트>나 <신조인간 캐산> <러프> <돌격! 크로마티 고교> 등 원작의 명성을 갉아먹은 영화들이 대부분이라 기대보다는 우려가 더 크지만.-ㅅ-;(개인적으로 나카시마 미카가 주연을 맡은 <나나>가 만화를 원작으로 한 일본 영화 중 최고가 아닐까 하는 생각도)

2008/02/04

[PSP] 파타폰(パタポン) 1/10

Prologue
옛날에...
파타폰족의 선조는 신이 치는 북에 의해
지혜와 용기와 힘, 그리고 기적을 얻었다.
신이 이끄는 파타폰족의 선조는
그곳에 있는 무언가를 구하고
세계의 끝을 목표로 삼았다.
앞을 가로막는 모든 적을 토벌하고
유명한 보물을 전부 손에 넣어
그들 앞에 보이는 모든 땅을 답파했다.
자신들의 신에게 모든 것을 바친
파타폰의 선조는
긴 세월을 초월해 전설이 되었다.
언젠가 영광을 되찾기 위해서
- 파타폰의 귀환 -

과거에 신은 어딘가로 떠났고
파타폰들은 세계의 한 구석에서
쓸쓸히 살아가고 있었습니다...
그리고 파타폰에게 힘을 준다고 전해지는
전설의 북을 찾아나선 용자들도
마을로 귀환하는 도중 지쳐가고 있었습니다.
신이시여 부탁드립니다...

부디 파타폰들을 구원해주소서...
<첫번째로 얻게되는 용기의 북!>
이제 본격적으로 게임이 시작된다.
처음에는 '쿵쿵쿵' 하는 리듬에 맞춰 ○ 버튼을 눌러주자.
그러면 곧이어 파타폰이 나타나는데...
하타폰 : 『이 북은... 왠지 힘이 넘치는 것 같아!
엣! 혹시 신!?
신께서 오실거라 믿고 목숨을 걸고 지키고 있었어요!
이 북을 받아주세요!』
하타폰 = 기수
<두번째로 얻게되는 힘의 북이다>
하타폰 : 『신의 북소리와 파타폰의 노래를 교대로!』
힘의 북을 입수하였으니 이제부터는 이동과 공격이 가능하다.
하지만 이번 스테이지에서는 이동만 쓰게 된다.
4박자에 맞춰 북을 울려보자!
이동 : □ □ □ ○
참고로 북으로 명령을 내리면 파타폰들이 노래를 부르며 행동을 취한다.
이 때는 커맨드를 입력하지 말고 기다렸다가
행동이 끝나고 바로 다시 명령을 내리도록 하자.
즉, 4박자는 명령, 4박자는 행동, 이런 패턴의 반복이다.
<당신을 위해 싸운 야리폰을 찾아 동료로 만들어주세요!>
이제 슬슬 감도 왔겠다. 앞으로 계속 전진!!
야리폰 1 : 『에... 하타폰...? 신을 찾은거야!?』
하타폰 : 『그래!』
야리폰 1 : 『이런 경사가♪』
첫번째 야리폰을 찾았으면, 계속 전진하도록 하자.
야리폰 = 창병
야리폰 2 : 『아아... 신이시여... 북의 힘에 감사드려요!
나도 수행하게 해줘!』
마찬가지로 계속 앞으로 전진해보자.
그러면 또 다른 야리폰이 다가온다.
야리폰 3 :『야야~ 얘들아! 굉장해 이 소리, 굉장해요 신님!
좋았어~ 파타포리스로 돌아가자!』
<뭐... 뭐지!? 뭐야 이건!?>
<조심하세요!! 뭔가 커다란 것이 다가오고 있어요!>
곧이어 공룡같은 녀석이 따라올텐데,
녀석한테서 도망쳐야 한다.
열심히 박자에 맞춰 □ □ □ ○ 소리를 울려보자.
<앞에 수상한 녀석들이 나타나긴 하지만 공격해오지는 않으니 신경쓰지말자>
<이런 깃발을 지나면 끝>
이번 스테이지는 스샷과 같은 깃발을 통과하면 끝이다.
대부분의 스테이지가 깃대를 통과해야 끝나므로 알아두도록 하자.
<각 스테이지를 클리어하면 클리어 시간과 전리품 등의 내역을 확인할 수 있다>
<클리어 후 로딩화면에서 게임진행에 필요한 힌트를 얻을 수 있다>
◇ 교대로! ◇
4박자의 리듬에 맞춰 교대로 연주하자.
신 : 『파타 파타 파타 폰』
파타폰 : 『파타 파타 파타 폰』
섹션이 최고조에 달하면 파타폰들은 피버상태가 된다!

2007/11/26

개발자의 유형

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

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

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

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

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

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