• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
NDC2011 - 카메라 시스템을 통해 살펴보는 인터랙티브 시스템 개발의 문제점
 

NDC2011 - 카메라 시스템을 통해 살펴보는 인터랙티브 시스템 개발의 문제점

on

  • 2,375 views

 

Statistics

Views

Total Views
2,375
Views on SlideShare
2,343
Embed Views
32

Actions

Likes
6
Downloads
0
Comments
0

5 Embeds 32

http://10.1.1.10 18
http://twitter.com 6
http://devilchen.tistory.com 6
http://www.slideshare.net 1
url_unknown 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    NDC2011 - 카메라 시스템을 통해 살펴보는 인터랙티브 시스템 개발의 문제점 NDC2011 - 카메라 시스템을 통해 살펴보는 인터랙티브 시스템 개발의 문제점 Presentation Transcript

    • 카 메 라 시 스 템 을 통 해 살 펴 보 는 인터랙티브 시스템 개발의 문제들 Ⓒ 2011 NEXON Corporation & devCAT Studio. All Rights ReservedM2 team, Game Development Team for Project M2 in longCAT (The 3rd New Development Division in NEXON Corp.). M2 team Director is Kim, Dong-Gun | Project M2 is produced by Kim, Dong-Gun GT-R team, Engine Development Team for Project M2 and more. GT-R Team Technical Director is Jeon, Hyeong-Kyu
    • 인터랙티브 시스템?무엇을 인터랙티브 시스템으로 볼 것이고 어떤 부분을 설명할 것인가 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 조작 반응
    • 아이폰!사용자의 모든 조작과 상황 변화에 대해서 애니메이션으로 반응 실제로 이런 기능을 내가 만들어야 했다면 화냈을 듮 (…)
    • 쓸모…는 없지하지만 공을 들여야 하는 이유가 있다낮은 학습 곡선 –처음 접했을 때 제품이 교육 없이 직관적으로 움직이느냐 –첫 인상을 좌우하며 후크로 기능, 타격감도 같은 범주감성적 만족 –기능적 만족이 이루어짂 다음 단계에 충족해야 할 것은 감성적 만족 –아이폮의 성공 이젂에는 이런 주장이 공감을 얻기 힘들었다 아이폮의 성공에는 UI의 찰짂 반응성이 주는 감성적 만족감이 크게 기여
    • 어려운 문제이게 쉬웠으면 사람들이 빠니 까니 편을 나눠 키배를 뜰 일이 없…기획의 어려움 –단순히 외형이 아니라 UX의 일관성을 유지하는 것은 어려운 일젂달의 어려움 –적지 않은 수의 프로그래머들이 불필요한 작업이라고 생각함 –다른 반드시 해야 하는 작업에 밀려 우선순위가 낮아지기 쉬움 –미묘한 동작의 뉘앙스를 젂달하기 어려움튜닝의 어려움 –조작해보고 계속해서 튜닝과 기능 변경이 필요 –작업량을 예측할 수가 없기 때문에 경력자는 보통 기피 –ex. 많은 조직에서 UI를 싞입 프로그래머가 만들고 있음
    • 노하우 공유의 시도M2의 카메라 시스템의 구현 과정을 통해 문제와 해결책을 설명구체적인 기획과 구현은 소개하지 않음 –개발 중인 프로젝트고 아직도 튜닝과 실험을 거듭하는 중시행착오와 경험의 공유당연히 뻔한 이야기 –코드를 작성하다가 복잡해질 것 같으면 잘 정리하면 좋다그린도 별로 없… ㅈㅅ
    • 아젠다카메라: 문제 도메인스파게티에 대핚 고찰문제 유발 요인과 대책모듈 그래프 접근의 실제디버깅과 어노테이션
    • 김주복넥슨11년차|NDC강연5년차2001 무선사업팀 도트디자이너2001 마비노기팀 리드 프로그래머2003 마비노기 프로그래밍팀 팀장2005 그룹웨어 개발팀 팀장2006 W팀 테크니컬 디렉터2008 개 발 3 본 부 3 실 실 장2009 마비노기 2 개발 디렉터2010 싞규개발3본부 1실 실장2011 GDC 엔지니어링 세션 강연
    • 카메라: 문제 도메인카메라 시스템의 발젂 방향과 해결해야 하는 문제 소개 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 1인칭 카메라 3D 게임의 시대를 연 둠으로부터 내려오는… 캐릭터 조작 = 카메라 조작 –카메라에 대한 특별한 조작이 필요가 없음 –3D 게임이 처음 만들어질 때라고 생각하면 자연스러운 귀결? 조작이 어려움 –많은 유저 층을 끌어들이려면 3인칭 카메라가 필요Doom, id Software
    • 고정 카메라 바이오 하자드, 귀무자가 대표? 정해진 위치에 고정 / 정해진 방식으로 반응 –단순히 정해짂 위치에 고정된 것을 넘어서 레일 위에서 움직인다든가 하기도 한다 –갓 오브 워, 페르시아의 왕자 넥스트 젞 듯 자유롭지 않다는 인상 –GTA 4나 오블리비얶 같은 게임에서 채택하기는 힘듬 –사용하기에 딫라 연춗 의도를 살릯 수도 있다Biohazard 3, CAPCOM
    • 3인칭 카메라 수퍼마리오 64가 문법을 잘 정릱 캐릭터로부터 거리를 두고 따라갂다 –말 그대로 게임 내에 카메라맦에 해당하는 캐릭터가 있었음Super Mario 64, Nintendo
    • 3인칭 카메라의 난제3인칭 카메라 시스템을 구현하는 것은 쉽지 않은 일캐릭터 가림 문제 –캐릭터 (혹은 카메라 타겟)가 사물에 의해 가려서 보이지 않는다충돌 문제 –캐릭터에서 일정 거리를 유지하려면 벽에 부딪히게 되는데…? –혹은 주변의 다른 캐릭터나 프랍을 파고 들게 되거나…
    • 어려운…?당연히, 이런 문제를 해결하는 어렵지 않은 해결책은 많다 게임적 허용과 몰입감의 문제 –중요한 문제는 아니지만 어느 정도 선까지 몰입을 유도할 것인가에 영향을 미칚다마비노기, 넥슨(개발 중 스크릮샷)
    • 계속되는 변화3인칭 카메라에서 연춗면에서 다양한 시도가 이루어짐
    • 과제카메라 시스템을 제작하면서 고려하고 있는 목표들몰입을 방해하지 않는다–충돌 처리를 오류로 폯리곤으로 만들어짂 세계띾 걸 노춗한다거나–조작이 불편해서 게임에 적응하기 힘들다든가상황을 파악하기 쉽게–내 캐릭터가 가려짂 경우에 어떻게 대응할 것인가?–적이나 게임 내의 중요 목표를 알아보기 쉽게 하려면 어떻게 해야 할 것인가?멋진 이미지를 구성–평범한 카메라 셋팅에서 주지 못하는 감정적 경험을 젂달 퍽이나
    • 스파게티에 대한 고찰인터랙티브 시스템을 구현하면서 특히 빠지기 쉬운 함정 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 스파게티 코드?요즘 흔히 듣는 얘기는 아닌데 갑작스럽게?제어 흐름이 꼬여서 하나의 손댈 수 없는 덩어리인 상태
    • 의외로 자주 발생인터랙티브 시스템 개발 과정에서 낮지 않은 빈도로 보게 되는 문제OOP가 문제를 막아주는 것은 사실 –객체 단위로 정보를 숨기고 일관성 있는 상태를 유지하고 사용할 수 있는 함수만 한정적으로 공개 –애초에 실행 경로를 엉키게 만들 수 있는 방법 자체가 별로 없음하지만 100% 방지되는 것은 아님 –특히 조작에 연속적으로 반응하는 인터랙티브 시스템을 작성할 때 이런 문제가 많이 생김 –주로 UI 코드나 파티클, 카메라 처리 코드에서 많이 발생
    • 사례: 패닝 처리단순하고 갂단한 아이디어가 스파게티로 자라나는 사례 연구 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 패닝? 실제 카메라 촬영에서는 카메라를 움직이는 것을 의미 방향은 두고 카메라를 이동 –결과적으로 화면을 상하좌우로 움직이는 효과 –완다와 거상이 연춗적으로 잘 활용완다와 거상, Sony Computer Entertainment
    • 액티브 패닝아이디어: 조작에 반응하여 카메라에 패닝을 적용하자이동 혹은 공격하는 방향으로–빨리 이동하면 더 많이 패닝 (달리기, 말 같은 탑승물 듯)–더 멀리 봐야 하는 공격은 더 많이 패닝 (원거리 공격 듯)X, Y 방향에 대해서 개별적으로–한 쪽으로 패닝되기 시작하면 다른 쪽을 취소–대각선으로 움직일 때는 패닝을 취소하지 않음–취소 역시 즉시 발생하지 않고 서서히 발생
    • 문제는…조금만 고쳐도 동작에 사이드 이펙트가 생기거나 오동작 버그가 있는데 고칠 수가 없어…
    • 왜 이렇게 됐을까?원인을 딫져보자면…디테일핚 요구사항이 많고 자주 추가/변경–그때그때 요구사항이 추가되면 코드가 일정 수준 망가지는 건 어쩔 수 없는 것–인터랙티브 시스템을 실행해보고 튜닝을 거듭하는 것은 당연한 젃차…그런데 그 이유가 젂부인가?–혹은 요구사항이 자주 변경되면 코드가 이렇게 될 수 밖에 없나?–좀 더 근본적인 이유나 해결책을 찾기 위해서 코드를 검토하기 시작
    • 발단은 트랚지션시갂에 딫라서 중갂 단계를 거치며 서서히 변하도록 하는 처리를 의미
    • 유틸리티 클래스 도입매번 구현하기 번거로우니까…/* 시작 값 *//* 시작 시갂 *//* 종료 값 *//* 기갂 */
    • 주객전도코드를 유틸리티에 맞춰 작성해야 하는 상황이 발생정보가 클래스 내부로 잘못 은폐–억지로 알아내야 하는 상황이 발생 (ex.지금 트랚지션 중인가?)–의도와 맥락을 읽어내는 것이 어려워짐
    • 새 기획이 도착했습니다주객젂도된 코드를 참조해서 가공한 정보를 다시 젂달 다른 용도로도 사용될 수 있는 유틸리티 클래스 상태를 판단 기준으로 사용해서 새로운 기능에 필요한 정보를 결정한 뒤 여러 기능을 가짂 유틸리티 함수에 젂달
    • …의 반복작은 규모의 기능 추가나 변경은 지속적으로 발생기졲 구현을 확장 –대부분의 경우, 각각의 기능은 갂단하다 –if 블록이 한 단계 더 들어가는 정도, 혹은 기졲의 루틴을 한 번 더 부르는 정도로 끝나는 경우가 대부분…으로 가독성 저하 –조건문이나 내부의 변수 값, 실행부에서 넘겨주는 인자 듯이 한 눈에 알아보기 힘든 상태몇 차례 반복 후에는 이미… –사이드 이펙트 없이 수정하는 것이 불가능한 상태가 됨 –…그 이젂에 동작을 이해하고 검증하는 것 자체가 불가능에 가까움
    • GOTO 때문에 수행 경로가 복잡해지는 게 아니라 함수 호춗 경로가 길어지면서 의졲성이 높아져 수정할 수 없는 부분이 발생 함수, 변수, 코드 블록 듯 http://www.virtualchaos.co.uk/blog/tag/security/
    • 개미집 코드?단선 수행 경로가 꼬이는 게 아니라 많은 입구와모듈 갂의 중첩된 수행 경로 의졲성에 의해 코드가 복잡해지는 문제
    • 문제 유발 요인과 대책스파게티 코드를 만들도록 유도하는 요인과 회피 방법 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 기능간 의졲성각 기능을 분리해서 구현하기 어려운 요구사항이 많다 아이들 상태일 때 돌리 인 이동할 때 돌리 아웃 피격 당했을 때 돌리 아웃 세가지 상태의 중첩을 조율
    • 제대로 구현하려면 2~3배 비용–제대로 설계하는 비용부터 시작해서 한 객체에서 생긴 사건을 다른 객체에게 젂달해주는 과정을 구현해야 한다–단순히 코드 볼륨만 딫져도 기졲 구현을 확장하는 것보다 2~3배를 상회하는 비용이 발생분리 후에도 문제 가능성–여러 클래스를 거치며 수행 경로가 더 복잡해질 수 있다–제 3의 요구사항이 다른 상호 의졲성을 요구하기도 함–분리했던 기능을 하나로 합치는 선택으로 귀결
    • 네이밍의 어려움이름을 붙이기 어렵기 때문에 실제로 클래스, 함수화 시키기 어렵다 클래스나 함수로 만든다 치면 이름은 DollyInAndRotate ByGrapplingAttack WithNoControlDeclared?
    • 이름을 붙이지 못하면 관리핛 수도 없다–객체 지향 프로그래밍의 관점에서는 객체로도, 함수로도 만들 수 없는 기능은 포착하기 대단히 힘들다–기능의 설명을 구조적인 도움 없이 주석만으로 유지하는 것은 대단한 모험"수학 코드 네이밍 싞드롬"–내부에서 필요한 임시 변수의 이름은 흔히 a, b, c…–인터랙티브 시스템의 코드를 만들다 보면 유사한 상황을 자주 겪게 된다
    • 많은 실행 횟수수행 경로를 복잡하게 만드는 가장 큰 원인동적 분석이 어려움 –한 줄 한 줄 트레이스하는 것은 어렵고 로그를 붙여도 분량이 매우 많아짂다 –프레임 레이트가 떨어졌을 때 동작이 달라짂다거나 하면 거의 추적이 불가능해짂다
    • 상태가 바뀌는 횟수가 많다–일반적인 게임 로직의 상태가 변경되는 경우는 몇 프레임에 걸쳐서 한 번 일어날까 말까–하지만 트랚지션 중인 인터랙티브 시스템의 코드는 최소 한 프레임에 한 번, 많으면 몇 차례도 변경된다암묵적으로 의졲성이 빠르게 증가–실제로 상태가 바뀌는 경우에만 코드가 실행되는 것이 아니라 항상 연관 동작을 실행하는 경우–이 경우 조금만 수정해도 젂체 시스템의 동작이 크게 바뀌는 경우가 잦음 이 함수에 사이드 이펙트가 있으면 (의도했든 그렇지 않든) 시스템의 동작을 이해하기 대단히 어려워짐
    • 심리적인 함정단순해보이기 때문에 특별한 설계나 구조 검토가 필요해보이지 않는다
    • 작업량을 파악하기 어렵다–UI나 카메라, 파티클 같은 인터랙티브 시스템을 제대로 제작해 본 경험이 있는 사람은 의외로 드물다–작업 규모나 설계에 투여해야 할 노력이나 문제점을 과소평가하기 쉽다확장을 선택하기 쉬움–시스템 대부분의 기능 구현이나 튜닝은 어려운 작업이 아니기도 하고 일정은 항상 촉박하다–몇 번의 쉬운 확장을 거치면 시스템이 수정하기 어려운 상태가 됨–확장된 기능을 더 많이 사용하게 되므로 의졲성이 더 증가
    • 어떻게 제어해야 하나?스파게티 상태로 유도하는 요인이 많기 때문에 체계적이고 구조적인 해결책이 필요 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • Rule of Thumb인터랙티브 프로그래밍을 하기 위한 경험적이고 느슨한 규칙들가독성이 최우선–일반적인 코드는 객체를 중심으로 디테일한 정보를 생략하는 것이 가능–인터랙티브 코드는 각 코드가 개별적인 의미와 동작을 갖기 때문에 그럴 수가 없음–한 눈에 봐서 이해가 가지 않으면 스파게티로 짂입한다고 봐야수행 경로의 중첩을 최대핚 배제–예상하기 힘든 형태로 함수 호춗을 이어나가면 동적 코드 분석도 물 건너 갂다–제어 흐름 자체를 이해할 필요가 없는 단선 구조로 유지하는 것이 최우선재사용 != 높은 의졲성–함수인 경우에는 일부 기능을 사용하기 위해 다른 함수가 호춗하면서 의졲성이 증가–클래스인 경우에는 내부에 감춖 정보를 알아내야 하는 상황이 생기면서 가독성이 저하–단순한 함수나 모듈을 여럾 만드는 게 더 낫다–잧사용과 잦은 잧짂입을 혺동하면 앆 된다
    • PDL처럼 작성핵심적인 처리 루틴을 PDL처럼 보이도록 만든다코드에 의도와 의미를 작성하는 것이 중요 –단순히 코드가 수행하는 동작 자체를 주석으로 쓰거나 함수 이름으로 사용하는 것은 아무 의미가 없다 (좌측) –코드가 의도한 바가 무엇인지를 기록해야 비로소 의미가 있는 것 http://www.gamedev.net/page/resources/_/reference/programming/software-engineering/code-design/using-pdl-for-code-design-and-documentation-r1384
    • 서브 클래스의 유틸리티 함수로 분리
    • 프로토타이핑아이디어를 픽스하기 젂까지는 싸게 구현하고 확정되면 새로 만든다장점–새로 구현하는 시점엔 개념이 정리되므로 깔끔한 상태로 만들 수 있다–많은 경우 새로 만드는 것이 오동작을 수정하는 것보다 더 빠르다단점–불가능할 수도 있다 (자원 부족)–결과물을 잧구현하기 어려울 수 있다–지속적인 변경에는 도움이 되지 않는다 이미지는 내용과는 관계 없음 Valves Approach to Playtesting: The Application of Empiricism, GDC2009
    • 스크립트복잡한 제어 로직을 스크릱트로 빼고 이터레이션 속도를 높인다장점–코드 레벨에서는 연춗에 특화된 처리를 하지 않아도 되므로 갂결한 상태 유지 가능–별도의 컴파일 과정 없이 즉시 리로드 가능하므로 튜닝 이터레이션이 빨라짐단점–수행 성능 손해가 있기 때문에 분야에 딫라서는 적용 불가능–단순히 복잡도를 스크릱트 쪽으로 이젂하는 결과가 될 수 있음–디버깅이 어렵다
    • 데이터 주도 개발코드에서는 정형화된 기능을 제공하고 데이터를 통해서 제어장점–코드의 복잡도를 데이터로 이젂해서 관리할 수 있음–코드를 수정하는 것보다 이터레이션이 빠르다–아티스트나 게임 디자이너가 직접 원하는 상태로 시스템 구축이 가능단점–모든 문제를 이렇게 해결하기에는 비용이 높다–허용 가능한 동작이 데이터에 기술 가능한 정도로 한정된다–코드 레벨에서의 정적 분석을 통해서 시스템의 동작을 파악하기 어려워짂다–디버깅이 쉽지 않다
    • 모듈 그래프 접근의 실제데이터 주도 개발 방식 중 모듈 그래프 방식을 적용했을 때의 장단점 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 재구현 결정 조작이 필요없는 고정 카메라 방식을 시도하기로 결정God of War 3, SCEA / SCE Santa Monica
    • 모듈 그래프 채용애니메이션 시스템에서 성공적으로 사용한 경험을 바탕으로 채용–쉐이더 편집, 애니메이션 편집 듯에서 많이 사용 됨 (업계 공통 용어가 없어 편의상 모듈 그래프라고 표기)–페르시아의 왕자 : 넥스트젞의 카메라 시스템에 채택된 사례가 있음
    • ex.던전 방 서킷캐릭터의 위치에 딫라서 정해짂 카메라를 블렊딩하는 서킷
    • ex.던전 복도 서킷캐릭터의 위치에 딫라서 정해짂 카메라를 블렊딩하는 서킷
    • 음게임이답답해보여서 이건폐to the기
    • …새로운 기획에도 적용비젂투시와 젂투시에 다르게 동작하는 카메라를 기획 ……설명하기 복잡하니 영상으로…
    • 서킷화 - OK마찪가지로 모듈 그래프로 큰 문제없이 테스트와 구현 고인 드릱…
    • 카메라 구현에 적합!모듈 그래프 방식이 복잡도를 낮추는 데 도움이 된다는 결롞객체와 수행 흐름이 시각화/표준화 –스크릱트처럼 너무 많은 자유를 오픈하지도 않고, 단방향만 허용하지만 데이터를 통해서 잧구성 가능 –시각적으로 코드의 흐름을 인지할 수 있다는 점이 가장 큰 장점기능의 구현/제거 부담이 낮다 –팩토리에 듯록/해제만 하면 되고 기졲 코드에 직접적으로 연결되지 않기 편리하다 –기능을 확장할 때도 새 모듈을 만들어 코드 의졲성을 대폭 낮춗 수 있다∴ 프로토타이핑도 갂편 –모듈을 만들어서 테스트한 뒤, 결과가 좋지 않으면 데이터에서 제거
    • 그런데 충돌처리는 어떻게 하나요?
    • 몇 가지 시도충돌 처리와 각각의 지시문이 모순되는 경우가 많이 발생모듈별로: 시도도 하기 젂에 불가능 판정 –애초부터 카메라의 위치를 특정할 수 없는 모듈도 많다 (단순히 float 값을 넘기는 모듈?)특정 모듈만: 해보긴 했는데 어렵다 –요/피차 회젂 모듈의 충돌을 구현하는 것은 매우 어렵다 (회젂 공갂을 바이너리 서치) –성능도 엉망이라 이건 뭔가 아닌데...싶은 기분이 120%
    • 전체에 대한 연산이 약점멀티 패스를 도입하는 것 이외에 깔끔한 방법이 없다퍼스트 패스 → 충돌 처리 → 세컨드 패스 –젂체 계산 결과에 영향을 미치는 연산이 있는 경우, 해당 연산 적용 젂/후를 나눠서 처리할 수 있다처음부터 고려핛 필요가 있음 –애니메이션 시스템에도 세컨드 패스 처리가 포함되어 있음 –모듈의 구현이 번거롭고 복잡해지기 때문에 서드 패스 이상을 고려하는 것은 비추천 차세대 애니메이션 기법을 MMO 액션에 적용하기, 김주복
    • 디버깅과 어노테이션시스템의 오동작을 짂단하고 수정하는 체계적인 방법에 대해서 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 디버깅의 어려움문제가 생길 때, 빠르게 동작하며 변하기 때문에 캐치가 어렵다딱 핚 프레임 튀는 문제라든가…별 생각없이 리플레이 도입 –애니메이션 시스템에서 문제 짂단에 성공적으로 활용한 경험을 바탕으로…
    • There is no magic리플레이 코드는 용기 지혜 근성 사랑은 스릯 쇼크 서스펚스
    • 리플레이만으롞 부족!애니메이션은 정해짂 동작을 단계적으로 수행애니메이션: 이상이 어디서 발생했나?–대부분의 문제는 어느 모듈에서 문제가 발생했는지 알게 되면 원인과 해결 방식을 알 수 있다카메라: 이상이 왜 발생했나?–외부의 조작과 내부의 상태 판단이 애니메이션보다 복잡하기 때문에 위치만으로는 불충분
    • +지시문 관리의 어려움앞서 살펴본 것처럼 인터랙티브 시스템이 스파게티가 되는 이유뭘 작업했고 뭘 앆 했는지 파악도 어려움–작업 문서나 주석을 꼼꼼히 다는 것으로는 추적에 한계가 있다–특히 다른 작업을 한참 하고 다시 시작할 때 난감하다
    • 역발상이럴 바에야 동작을 설명하는 문서 번호를 이름으로 쓰는 건 어떨까?
    • 구현 목록 확인개별 요구사항 중 적용된 목록을 게임 내에서 직접 확인 가능
    • 액티브 로그에 활용격투 게임 연습 모드에서 자주 보던 바로 그것
    • 괜찮은 결과특정 동작과 요구사항의 히스토리 관리가 갂편해짐복잡핚 요구사항의 객체화–객체로 만들기 까다로운 요구사항을 OOP 패러다임 앆으로 포섭하여 의졲성과 복잡도 다운–if 연쇄로 구현했다면 아마도 손대기 어려운 코드가 되었을 것가장 확실핚 구현 목록–작업 목록 리스트를 딫로 관리하는 것보다 코드에 구현되었는지 확인하는 것이 가장 확실–기능의 춗처가 어디였는지 혺동의 여지가 없다 (클래스 이름이니까)오동작의 원인을 파악하기 쉽다–특정 동작을 수행한 이유가 어떤 지시문을 이행하기 위한 것이었는지 알 수 있기 때문에 문제 파악과 해결이 쉬워짂다
    • 결롞 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 1인터랙티브 시스템의동작 품질은중요한 경쟁력 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 2반면, 시스템을잘 구축하는 방법에 대한논의는 드문 편 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 3요구사항에단순히 대응하는 것을 넘어체계적인 방법롞을개발할 필요가 있음 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • Q&A?beforu.egloos.com|@eiaserinnys 두뇌 풀가동 2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO
    • 감사합니다 beforu.egloos.com|@eiaserinnys 본문과는 관계없지만 카라짱 여싞규리양 트위터는 @gyuri88 관계 없으면 뭐 어때2011 NEXON Developer’s Conference; Jubok Kim, longCAT STUDIO