유니티 3D로 개발하다보면, 파편화된 데이터때문에 유지보수나 관리에 어려움을 겪게 되는데,
그러다 보니 Entity Class를 만들고 Dontdestroy 옵션으로 삭제되지 않는 불멸의 데이터 클래스를 생성해서 사용하는 개발자 분들이 많이 보인다.
그런데, 이렇게 하다보면 결국 소스가 꼬여서 오작동 하거나 관리상 문제로 인해 불편함을 가지고 가는 경우도 많은데 그럴 필요 없이 Static 으로 설정하여 Scene을 넘어가더라도 Data가 살아 있는 Class를 만들고 관리하는 것을 목표로 한다.
(물론 Json을 Serialize 하거나 Deserialize 하는건 다음 편에서 보자)

EntityMaster.cs파일을 하나 만들어서 다음과 같이 추가해두자.
(폴더위치는 관계없다.)

using System.Collections.Generic;
using System.Collections;

//테이블과 같은 클래스이다.
public class TestEntity
{
 public static List<SubEntity> _sub = new List<SubEntity>();
}

//1개 Row라고 생각하면 비교가 쉽다.
public class SubEntity
{
 public string _x;
 public string _y;
//Row안에 또 하나의 테이블을 가질 수 있다.
 public List<Sub2Entity> _sub = new List<Sub2Entity>();
}
//SubEntity에 포함된 클래스이다.
public class Sub2Entity
{
 public int _z;
}


이제 Scene0를 만들어서 MainCamera에 다음과 같은 Script를 만들어 Attach하자.
using UnityEngine;
using System.Collections;
using System.Collections.Generic;

public class Scene0Behavior : MonoBehaviour {
 // Use this for initialization
 void Start () {
//새로운 Sub2Entity 객체를 만든다.
 List<Sub2Entity> _sub2 = new List<Sub2Entity>();
//Sub2Entity 타입의 객체에 데이터를 넣는다.
_sub2.Add ( new Sub2Entity { _z = 1 });
//테스트엔티티 테이블에 Row를 추가하고 다음 씬을 호출한다.
 TestEntity._sub.Add(new SubEntity { _x = "a", _y = "b", _sub = _sub2 });
 Application.LoadLevel(1);
 }

}


이제 2번째 씬을 만들고 다음과 같이 코딩한후 MainCamera에 Attach하자.
* 위에서 데이터를 추가한 것이라 별도 설명은 생략한다.
using UnityEngine;
using System.Collections;
using System.Collections.Generic;

public class Scene1Behavior : MonoBehaviour {

 // Use this for initialization
 void Start () {
 Debug.Log(TestEntity._sub[0]._x);
 List<Sub2Entity> _sub2 = new List<Sub2Entity>();
 _sub2.Add(new Sub2Entity { _z = 2 });
 TestEntity._sub.Add(new SubEntity { _x = "c", _y = "d", _sub = _sub2 });
 Application.LoadLevel(2);
 }
 
}


마지막으로 3번째 씬을 만들어서 다음과 같이 코딩후 Attach하자.
using UnityEngine;
using System.Collections;

public class Scene2Behavior : MonoBehaviour {

 // Use this for initialization
 void Start () {
//시작하면 데이터를 찍는 역할이 전부다.
 Debug.Log(TestEntity._sub[1]._x);
 Debug.Log(TestEntity._sub[1]._sub[0]._z);
 }
 
}


최종 결과는 다음과 같다.

* 씬을 다음과 같이 3개로 구성했고, MainCamera에는 각각의 Script가 Attach되어 있다.
사용자 삽입 이미지
* 최종 결과는 Debug.Log로 다음과 같이 출력된다.
사용자 삽입 이미지
2015/08/07 02:14 2015/08/07 02:14
안녕하세요? 글뻥입니다.
먼저 동영상 하나 보고 본론 말씀드리겠습니다.



최근 이걸 만든 회사에서 일하고 있습니다.
현재하고 있는 일은 "인공생명체를 만들어 육성하고 교배해서 새로운 생명체를 만들어내는 메커니즘으로 게임을 구현하고 있습니다."

개발은 유니티로 할 생각이며, 이 인공생명체의 학습엔진부터 설계해서 최종적으로는 주인의 피드백에 따라 학습하는 생명체입니다. 이는 다시 유전되어 자식세대에 물려 줍니다.

작지만, 무한 게임이 가능한 아이디어라 생각합니다.

흔하디 흔한 카카오톡 게임은 아니고, 해외향으로 만들어질 예정입니다.

요건은 다음과 같습니다.

근무지 : 양재동
채용인원 : 기획자 O명, 3D 모델링/애니메이터 O명(R&D 능력 보유, 유니티 신기능 또는 제가 만든 엔진 테스트 지원, 콘텐츠 제작 표준화 업무), 개발자 O명 (유전알고리즘 또는 학습모델에 대한 이해가 있으신분이며 C# 프로젝트 유경험자로 잘하신 필요는 없습니다.)

다음과 같은 분은 지원을 자재부탁드립니다.

1. 혼자 일하는게 편하신 분
2. 문제를 혼자 떠안고 자폭하시는 분
3. 시키는것만 하겠다는 분


(저는 노예와 일하고 싶지 않습니다.)


지원처 : vicviper@live.co.kr / vicviper@lingogames.net
2013/12/09 23:50 2013/12/09 23:50
일전에 조금 어두운 포스팅을 했습니다만,
몇 가지 고민을 했습니다.

첫째, 3D개발자로써 폴리곤 기반의 모델링을 하고 텍스쳐를 입히고 애니메이션을 주는 고비용을 감당하지 않고 3D를 할 수 있을까?

둘째, 앞으로 게임을 계속 만들고 싶은 것인가?

위 2가지 물음에 스스로 대답하려 노력한 끝에 해법을 찾은것 같아요.

첫째, 게임을 계속 만들고 싶습니다.
아직 처음에 생각했던 몇몇 아이디어 들을 실현하는데 너무나 큰 어려움이 있었고 시간과 돈을 많이 쓴듯 합니다.
하지만, 열정은 그대로 라는 생각이 들었어요.
저는 사람을 사귀는데 어려워하지만, 사람들이 서로 잘 사귀고 놀고 하는 모습을 좋아하니, 게임이 사교의 수단이 될 수 있다는 가정하에 계속 게임을 만들고 싶습니다.

둘째, Polygon과 Texture는 개발자를 괴롭히는 부분입니다. 저 역시 개발하면서 무언가를 다시 배우는데는 서툴러서 조금 생존에 대한 생각을 가지고 찾아보니... 그 해답으로 Voxel을 선택했습니다.

어제 오늘 공부하며 만들어본 Voxel Modeling 결과물들입니다.

사용자 삽입 이미지
사용자 삽입 이미지
단 몇 십분 배워서 이렇게 나오니 감지덕지한 기분입니다.

사용자 삽입 이미지


차기작부터는 Voxel로 찾아 뵙겠습니다. =)
(물론 Facebook 게임으로만 찾아뵐 겁니다.
항상 응원해주신 여러분께 다시한번 감사의 말씀을 드립니다.
2013/10/23 13:41 2013/10/23 13:41
TAG
처음 나도 사업을 할 수 있을까? 생각했던 계기가 있었어요.
필라델피아에 한호선 팀장님, 박새이님과 함께 출장 갔던 적이 있었죠
Doylestown, Pennsylvania 에서 노가다 하다가 짬나면 바로 옆 Crazy Traffic (?) 이 있는 상점가로 가곤 했습니다. Yellow 지나갈때 사진 찍어대던 아이들이 있는 그런 동네였습니다.
하루는 전에 먹었던 쿠기가 먹고 싶어서 가정집 1층에 가내 수공업으로 만든 쿠키를 사러 갔더니 "다 팔려서 안판다고 하더라구요." 이상하다 싶은데 그 순간 시야에 들어온건 목조주택 1층에 상점들이 다 있는데 문이 열려 있는 곳이 별로 없었습니다.

암튼 그런곳에 우리 사무실 겸 창고가 있었는데...
한 개발자가 1인 개발하며 게임앱을 열심히 만들고 있었습니다.
그 친구에게 물어봤습죠. "너 이걸로 먹고 살만하니?" (물론 콩글리쉬!!)
그 친구왈 "응, 바로 옆 사무실 있지? 거기 디자인 하는 분 사무실인데, 동네 누나야. 아래에 사운드 스튜디오 봤어? 거긴 동네 형이야. 난 그저 개발하다가 리소스가 필요하면 그분들께 얻어 오면 되."

그제서야 깨달았습니다. Village Business Model, 최근에 화두가 잠깐 됐던 공동체. 즉, 조합시스템을...

게임업을 시작하게 됐던건 아주 오래된 꿈이었기 때문이기도 했습니다.

하지만, 저 역시 머리는 조합을 생각하는데, 몸은 기존 회사시스템에 매여있었나 봅니다. 고용을 하고 월급을 주고 팀원들에게 업무 지시하고 업무 보고받는거에 너무 익숙해져 있던 저로써는 힘든 부분이 너무 많았습니다.

혹자께서는 안타까운 이야기일거라 생각하실지 모르겠지만, 최근 1년간 출시한 게임이 딸랑 1개인 저로써는 들어가는 원가와 사람에 대한 관리 및 홀로 무언가에 대한 두려움이 있었습니다만, 최근의 일련의 사태로 인해 (궁하면 통한다고...) 몇몇 혁신 포인트가 있었습니다.

- 먼저 3D에 대한 고정관념입니다. MineCraft로 유명해진 현재의 Polygon 시스템 이전의 Voxel입니다. 마치 3차원 스프라이트 처럼 색찍고 도트 찍으면 3D로 구현이 되죠.
- 그리고 또하나는 애니메이션입니다. Voxel로 뽑은 모델을 Mesh형태로 컨버젼해서 http://www.mixamo.com/에서 애니메이션을 자동으로 Rigging하고 애니메이션이 자동으로 먹는 시스템을 보았습니다.

이모든 제가 부족했던 부분들을 매꿔주는데 비용이 겨우 1년에 150만원 정도입니다.
모델러 애니메이션 1개월치 봉급도 안되는 금액입니다.

이런 생각이 미치자, 회사를 다시 1인 개발회사로 전환하기로 하였습니다.
수많은 갈등과 문제가 터지고 상처받고 상처입는 상황이 못마땅했기도 했습니다.

대박을 기원하신 패친분들께 진심으로 심심한 사과를 드리고 싶습니다.
그런데, 이득우님과 만나 이야기를 나누면서 돌리스타운에서 본 1인 개발자가 머리속을 스치고 지나갔어요.

어느 시대나 대멸종의 시대가 온다고 생각합니다. 현 시스템이 붕괴되면 큰 공룡을 대신해서 작은 쥐들이 세상을 지배하는 시대를 말씀드리는 것입니다.

사람이 적으면 큰 돈을 못벌어도 좋아하는 게임만들면서, 누가 시킨일 하지 않아도 먹고사는 시대가 바로 스마트폰 시대가 아닐까 싶어요.

혹자는 현재의 상황에 대해 비관적으로 보겠지만, 최소한 혼자 무언가를 할 수 있다면, 몸집작은 쥐처럼 행복할 수 있다는 사실을 다시금 깨달았습니다.

그래서 몸집을 더 줄였습니다.

하루하루 새로 태어나는 기분입니다.
오늘부터 Lingogames Version 2.0 으로 다시 Reboot하려합니다.

성원해주시고 도와주신 여러분께 감사의 말씀과 아울러 죄송한 말씀드립니다.
앞으로 게임 덕질하며 최근 못올린 게임제작과정을 Facebook에 공유할 수 있다는게 너무나 좋습니다. ㅋㅋ

그래픽 Resource 해결하면서 차근 차근 밀리터리 전략게임을 업데이트 해나가는 과정을 공유 드릴께욤
2013/10/22 01:40 2013/10/22 01:40
TAG ,
회사 블로그를 안쓰다보니.. -_-;; 쩝... (걍 폭파시켜 버릴까?)

뭐 암튼 전체 일정들입니다.

1. 문제정의(끝!)
2. 사람(관찰과판단분리, 비폭력대화, 사람관찰하기, 클린랭귀지, 코칭방법, 화내기 등 끝!)
3. 커뮤니케이션 일반 (Wiki, Jira, SVN, Email 등 회사시스템 사용법 교육, 1일)
4. 기획 (시장분석, 고객정의 1일)
5. 설계와 계획 (OOP, UML, 추정계획 등 2주)
6. 개발 (Unity3D 일반, Physics, Partical, Animation 등 2주)
7. 릴리즈 (IIS, PHP, MySQL, 1주)
8. 개발관리 (형상관리, 진척관리 2주)

헐.. 언제 이걸 다 갈키나.. T_T
2011/12/15 22:45 2011/12/15 22:45
어제부터 소비자에게 무엇을 만들어 드릴까요? 라고 Facebook에다가 물어보았습니다.
"무엇을 만들어 드릴까요?"는 소비자들에게 너는 이런게 필요해!라고 하는 생각을 무엇을 원합니까?로 바꿔생각해본 겁니다.

제가 개발하면서 고통스러워 하던 수많은 것 중에 하나는 "윗 상사의 고집이나 아집으로 만들어진" 혹은 "고객의 고집이나 아집으로 만들어진" 수 많은 날밤을 새면서 기껏 만들어 놨는데 안쓰는 기능에 대한 반성이기도 합니다.

만 하루만에 3건의 Feedback을 받았네요.

젠가, 블루마블같은 모노폴리, 푸에르리코 등 제가 모르는 게임도 있었습니다.

블로그 방문자분들께도 여쭙고 싶어요.

"재미있게 하신 보드게임이 있으신가요? iPhone용 App으로 만들어 드립니다. ^^"

* 물론 저희 자원이 허락하는 순으로 우선순위 두고 만들겁니다. ^^;
 
2011/11/21 15:13 2011/11/21 15:13
TAG ,
사용자 삽입 이미지

미국이나 한국이나, 개발은 Dog's feet으로 하는 듯...

이후 안되는 영어 동원 제럴드 와인버그 님께 댓글을 달자...
사용자 삽입 이미지

이하는 Gloridea 님이 번역해주신 글입니다. (만쉐~)
어느 국가, 어느 문화를 막론하고 개발자나 테스터에게
가장 귀한 자산은 현명한 고객이다.
그 다음은 무식하고, 그 무식을 숨기려 하지 않는 고객이다.
가장 나쁜 자산은 어리석고 무식하면서도 모든 걸 아는 체 하는 고객이다.
그런 사람은 무슨 수를 써서라도 피해라.
규칙은 그에게서 당신을 보호하지 못한다.

-_-;;; 넹!!!
2011/09/19 02:17 2011/09/19 02:17
요즘 회사를 하나 만들고 (아직 개인사업자입니다. 세율이 유리해서.. ㅋ) 컨설팅과 개발, 게임 기획, 목업디자인, AC2수강에, 교정보고 있던 요구사항 탐험은 드디어 1단원이 컨펌났구요. 일나가시는 사모님대신 딸아이 등원과 하원을 책임지고 있지요.

혼자서 이일 저일하다보니 놓치는 일이 많습니다.
오늘만 해도 AC2 1:1 코칭을 놓쳤죠.

그런데, 일이 재미 있습니다. -_-;; 미치도록 하고 싶었던 일이었기 때문일겁니다.
아마도...

초기에 사업을 할건지 장사를 할건지 많은 고민이 있었는데, 네트워크를 통한 사업은 내 물건 만들어 파는 장사와는 다른 역량과 조직이 필요해 결국은 장사하기로 하고 그럼 뭘할까? 고민했었는데, 결국 SI를 빼고 제일 잘하는 게임만들기에 미친듯이 달려 오늘까지 1주 정도의 시간끝에 드디어 누군가 오면 작동하는 게임으로 이런거예요~! 할 수 있는 수준이 되었습니다. ㅋㅋ

아마도 작년쯤 필라델피아에서 본 1인 모바일폰 게임 개발자를 보면서 저도 모르게 그분과 같은 길을 걷고 싶다고 생각했나봅니다.
그런데, 일을 하고나니 개발일은 이리저리 공부하면서 혜쳐나갈 수 있는데, 디자인이 문제더군요.
글타고 디자인만 붙잡고 되지도 않는 센스를 발휘할 수도 없는 일이고...

아무튼, 겨우 겨우 우케 우케 해서 디자이너 이슈는 어느정도 해결될 기미가 보이고, 음악감독 섭외하고 암튼 종종걸음치면서 겨우 한발짝씩 나아가고 있습니다.

하지만, 가장 어려운게 주변의 시선입니다.
솔찍히 저는 나름 큰 조직에서 인정받던 PM이었습니다.
기술을 알고 있었고, 영업도 됐으며, 딜리버리에 대한 무한 책임감을 가지고 일했지요.
그런데, 갑작이 작은 회사를 차려서는 레드오션인 게임만들겠다고 하니까 주변에서는 난리도 아닌 이야기가 오고 갔습니다.
그걸 왜하냐?라는 분부터, 작게나마 모마일 게임사의 지인들을 만나서 이렇게 저렇게 알아봐주시는 분까지...
그럼에도, 주변에서는 이해를 할 수 없다는 뉴앙스를 풍기시더군요.

그게 가장 힘들었습니다. (현재까지는...)

하지만, 생각해보면 대기업에서 인정받고 잘 사는길만이 있는 걸까요?
대기업에서 잘 사는 길과 작은 벤쳐부터 천천히 성장해가는 길 중에 무엇이 더 어려울까요?

아직까지의 제 경험상 대기업에서 살아남아 팀장달고, 상무달고, 사장되는게 더 어렵다고 말씀드리고 싶어요.

제가 속해 있던 팀은 많을때는 60명 가까이, 작을때는 10여명이 되었는데 지금까지 모신 팀장님만 5분 정도였습니다.
임기가 약 2~3년 정도 되셨으니 근 10년의 세월을 보낸 훈장 정도되지요.
그런데, 팀장되기가 정말 어렵습니다. 비슷한 또래에서 뽑는 장교진급시험이 오히려 쉬울 정도지요.
능력이 출중하면 대리도 팀장하는 시절이 있었지만, 인원이 많아지고 처음보시는 분이 회사로 오셔서 팀장하시기도 하고 오히려 그 속에서 아둥바둥 팀장달려고 온갖 방법을 다 피는 사람이 쫒겨가는 걸 몇번이나 보았습니다.
팀장이 되면 상무다는건 또 쉬울까요? 외부 영입이라는 아주 좋은 수단이 있는데...
결국, 청춘 다 받치고 남은건 퇴직금 몇푼 쥐고 40대 중후반쯤 쫒겨나가거나 다른 회사 일자리를 알아보는게 "대기업인"의 모습이었습니다.

대기업이란 처음에는 안락한 요람이 되어 주지만, 그 요람에 있는 누군가를 위해 결국 자기 몫이상의 돈을 벌어와야 하는 구조입니다.
하지만, 벤쳐는 아니지요. 사장도 요람에 있을 수 없습니다. 계속 뛰어다녀야 하고 개발도 합니다.
다시말해 요람이 없으니 자기 월급 정도벌면 쉬엄쉬엄 다닐수 있다는 이야기가 되지요.

더 신기한건 지금까지 경험으로는 이 바닥에서 벤쳐로 시작해 망하는 회사는 극히 드물었습니다.
오히려 회사가 커져서 망하지요.
회사가 커지면 요람이 자연적으로 생깁니다.
직접적인 생산업무를 하지 않는 사람을 위해 더 많은 돈을 벌어야 하는데, 그게 쉬운일이 아닙니다.
결국 투자라고 하지만, 한 방 투자가 회사를 문 닫게 하던가, 아니면 천천히 고사되어 죽어갑니다.
경영적 판단 미스는 이래서 위험합니다.

이러한 경영적 판단 미스를 제외하고는 무리한 투자금 유치 또는 차입금으로 망하는 사례를 보았지요.
결국 욕심부리다 망합니다.

제가 게임업계에 뛰어든 이유는 간단합니다.
게임업계의 지각이 서서히 변하고 있다는 현상을 피부로 느끼고 있었기 때문입니다.
닌텐도나 소니와 같은 사업모델은 앞으로 살아 남기 힘들거라 생각했습니다. 예를 들어 몇 년전 고객사에서 SD-CARD로 게임을 유통하는 시스템을 구축한다는 이야기를 듣고는 다른 분께 그 프로젝트를 그대로 넘기기도 했습니다.

유통의 채널이 더이상 오프라인이 아니기 때문입니다.

앵그리버드를 만든 게임사도 52개의 모바일 게임을 만든끝에 대박을 터트렸지요.
하지만, 이게 더 쉬울까요? 아니면 대기업에서 사장되는게 더 쉬울까요?

지금 대기업에 입사하기위해 열심히 노력중인 다른 분들께 이런 이야기를 해드리고 싶습니다.
"자신있으시면 글로벌에서 한판 뜨자"라고...

저희는 올해 3종의 게임을 출시할 예정입니다. 그리고 내년 6종을 더 출시해서 총 9개의 라인업을 만들려고 합니다.
9개 중 하나라도 수익이 안나면 모를까 굉장히 매력적인 시장이 눈앞에 있음에도 모두가 애써 눈감고 귀 닫고 있는 현실이 너무 애석하고 안타까워서 몇 글자 적어봅니다.


참고 : http://www.231games.com/tag/%ec%a0%84% ··· 5aa%25a8
2011/08/06 01:33 2011/08/06 01:33

지난 시간에 USE CASE를 Activity Diagram으로 전개시키고 이를 다시 세분화하여 추정견적을 냈었다.
그러면서 다음과 같이 규모산정을 하였다.

우리가 산정한 안내를 받는다는 기능은 총 110.9 FP이다.

여기서 잠깐, 위의 챠트는 잠시 잊도록 하자. 먼저 생각해봐야 할 것은 "이 일은 몇명이서 얼마간 일해야 생각했던 기능을 모두 구현할 수 있을까?" 이다.

마치 밥이 한공기 있는데 몇 숟가락 떠먹어야 다 먹을수 있냐?라는 질문과 본질적으로 같은 질문인것 같다.
이를 공식화하면 간단하다

먼저 밥숫갈횟수 = 밥한공기용량/밥숫갈용량, 따라서, 전체 시간은 = 밥숫갈횟수*한숫갈당 씹는시간
물론 소화시간까지 계산한다면 "밥숫갈횟수*한숫갈당씹는시간+소화시간" (이건 잘 기억하자. 다음은 이 단순한 원리로 우리가 알고 있는 상식을 한번 깨보겠다.)

나는 WBS(Work Breakdown Structer)를 협오하는데 그 이유는 바로 Activity와 Due Date, 담당자로만 설정하기 때문이다.
거기다가 2Weeks이상 어떤 Activity 가 길어지면 안된다고 강제하고 있다.
물론 더 쪼게라고 이야기하고 있기는 한데 이거 하나 마음에 든다.
하지만 WBS는 다음과 같은 치명적인 오류가 있다.

첫째, 업무의 규모는 안보인다. 단지 보이는건 업무와 할당된 개발자, 종료일이다. 그게 어렵든, 쉽든 일단 2Weeks이내로 일정을 잡으면 소프트웨어 공학론자 눈에는 합리적으로 일정을 배분한것이 된다.
다시말해 위에서 계산한 "밥한공기의 용량"은 배제되는 것이다. 거기다가 SI 업계는 급하게 모인 개발자의 생산성을 모른다. 따라서, 밥 한숟갈의 용량도 알수가 없다. 즉, 밥한공기의 용량도 모르고 밥한숟갈의 용량도 모르는데 일단 밥먹는 시간은 설정된다.

둘째, WBS는 통제도구이다. "Critical Path"라는게 있다. WBS를 제대로 사용하려면 이 "Critical Path"라는 큰 줄기가 제대로 진척되고 있는지를 살펴야 한다. 그러나, 수 많은 고객을 포함한 감시/감독자들은 WBS의 모든 부분을 가지고 트집잡는다. 논쟁은 논쟁을 낳고 책임은 변명을 낳는 상황이 반복된다. 이말이 사실인지 아닌지를 보려면 WBS를 누가 원하는지를 보거나 기억해 내면 된다. WBS는 고객 또는 PM, 감리가 요청하는 문서이다.

셋째, 몇 개월에 달하는 WBS에 따른 일정 및 업무량을 100% 맞출수 있다면 그 사람에게 1억을 주라. 왜냐하면 그 사람은 로또 번호를 눈감고도 맞출 사람이다. 이말이 와닿지 않다면 이글을 읽는 걸 멈추고 당장 앞으로 10분이후 혹은 1시간 이후 혹은 4시간 이후에 자신이 뭘하고 있을지 상상해보자. 결코 일반 범인들은 10분뒤를 알 수가 없다. 이 포스팅을 시작한게 약 2시간이 흘렀는데 나는 30분 정도 쓰고 말겠다는 생각으로 시작했지만 중간 중간 이벤트가 발생하고 불려다니면서 이미 계획된 일정의 4배를 소모하고도 글을 다 쓰지 못했다. 그런데 몇 개월간의 2Weeks로 쪼게진 업무를 예측하고 계획하라고?

결론적으로 이러한 정형화되고 고정된 형태의 계획은 인간을 못살게 구는 압제의 수단이다.
따라서, 계획은 이렇게 세우는 것이 합리적이다.

1. 가장 먼저 해야할 일은 개발팀의 생산성을 측정해야 한다. 만약 이게 안된다면 연구자료를 참조하자.

물론 다른 자료도 만들 수 있겠지만 개발시 Prototype을 만들어 봄으로써 팀의 평균 생산성을 측정기록할 수도 있다.
여기서 중요한것은 최소한 한숟같의 용량을 측정해야 한다는 주장이다.
((절대 개인이 아닌 개발팀이어야 한다. 개인을 측정하고자하면 그건 또하나의 압제의 수단을 만들 뿐이고 팀웤에 도움이 안된다. 예를 축구 선수는 골로만 평가 받지 않는다. 팀의 기여도 등의 평가 기준이 있는 것이고 아무리 골을 잘 넣어도 혼자 11명을 상대로 할 수 있는건 없다. 개발도 마찬가지다. 고객의 숫자는 항상 개발팀의 숫자보다 많다. 급조한 개발팀이 단시간내에 으쌰으쌰해서 고객을 압도할 수 없기 때문이다.)

2. 정보공학에서 이야기하는 2Weeks는 지켜주자. 왜냐? 근거없는 관습이지만 2Weeks가 넘어가면 관리 한계가 드러나는것 또한 사실이다. (물론 내 경우는 1일이 넘어가면 관리한계가 발생한다.)

3. Critical Path를 먼저 설정하자. 흔히 마일스톤이라는 것으로 표현하면 된다.

암튼 다시 원점으로 돌아가 전체 규모는 110.9이므로 첨부된 파일에 있는 2003년 이후의 개인 생산성인 18FP로 나누자.
그러면 총 6.16 이나온다. 즉, 6.16 M/M가 투입되어야 구현이 가능하다는 이야기이다.
물론 사전 공부가 필요없는 전문가에 대한 이야기이다.
프로토타잎도 만들필요가 없는 전문가에 대한 이야기이다.
암튼 왠지 모르겠지만 어디서나 통용되는 2:8법칙을 적용하여 6.16은 개발 최소기간의 80%로 설정하면 6.16의 25%인 1.23을 버퍼로 추가해서 총 개발기간은 7.29가 되고 학습기간을 고려하면 고정 투자비용 1개월+7.29M/M가 투입되어야 개발이 가능하다. (물론 지도데이터나 음성 데이터등 관련 데이터가 모두 존재한다는 가정이다.)

따라서, 계획은 "Activity Diagram을 보며 업무를 Breakdown할 수있다. + 개발계획은 교육 1개월 + 7.29M/M의 투입이 필요하다."는 간단한 진실로 마일스톤을 그릴수 있는 것이다.
* 다음 그림을 다시한번 상기해보자.

기능 구현업무는 다음과 같이 나열하였었다. (3부에서)

- 초기화는 단순 입력만 이니 EI/ILF
- 목적지이름조회, 목적지주소조회는 EQ/ILF
- 주소목록선택, 목적지목록선택은 EI/ILF
- GPS좌표를 획득하는건 외부 시스템 연동으로 EIF
- 경로획득은 ILF
- 현재좌표획득은 EIF
- 음성안내는 EQ/ILF
- 현재지도갱신 EQ/ILF
- 안내종료는 EQ/ILF

이를 다시 정리하면 다음과 같다.

1. Milestone (예제)
- 개발자교육 (1M)
- Prototype (0.5M)
- 개발구현 (7.29/개발자수)
- 배포 (개발구현완료후)

2. 상세일정
- 개발자 교육 내용 및 추정기간
- Prototype 내용 및 추정기간
- 개발구현 내용 및 추정기간
- 배포 내용 및 추정기간

* 개발구현 상세일정 예제
사용자 삽입 이미지

다시말해 추정기간은 시간이라는 자원을 얼마정도 쓸지 예측한다는 의미이다.
이러게 자원소요계획을 수립하고나면 Milestone을 더 짧게 쪼게서 Iteration을 적용할 수 있다.
예를 들어 개발자 교육이 1개월 걸린다면 짧게 1주일씩 나눠서 4번 반복 할 수 있다.

Iteration1 - GPS시스템이해
Iteration2 - 앞 교육과정 요약 및 네비게이션의 이해
Iteration3 - 앞 교육과정 요약 및 경로추출
Iteration4 - 앞 교육과정 요약 및 음성안내

이처럼 가장 중요하다고 생각하는 내용을 앞에 배치하면 전체 교육기간동안 총 4번의 반복을 통해 피교육자의 이해도를 높일수 있는 장점이 있다. 개발도 마찬가지이다. 가장 중요하다고 생각되고 광범위하게 참조되는 부분부터 Iteration1에 넣어두면 Iteration2를 통해 확장할때 Iteration1에서 개발한 핵심 엔진은 기능확장과 안정화를 거치게 된다. 그리고 또 한번 열게됨으로써 개발자가 코드를 더 친숙하게 여길 수 있는 기회를 준다.

아무튼 이렇게까지 Milestone과 시간사용계획을 짜놓았다면 이제 할 일은 각각의 조직의 역할을 정의하는 일만 남았다.
반드시 CASE by CASE로 짜놓자.
예를 들면 다음과 같이 짜놓는 것이 중요하다.

1. 요구사항 수행절차
 가. 요구사항을 JIRA에 등록한다.
 나. 요구사항은 고객과 개발팀의 협의체에서 우선순위를 조정하여 XX기준(일정 또는 범위 또는 업무량 등등) 으로 상위 OO개를 수행한다.

이렇게 개발공정에서 발생할 수 있는 CASE를 예상하고 각각의 조직과 개인이 해야할 일을 명시해놓고 개발 프로세스에 적용하자. 그래야만 혼란을 미리 막을 수 있으며 Prototype 개발 기간동안 의미있는 데이터를 획득할 수 있다.

암튼, 가장중요한 것은 계획은 계획일 뿐이라는 거다.
계획을 함으로써 앞으로 발생할 일에 대한 자원(인력, 돈, 시간 등)의 소모와 만약(if)에 대한 시나리오를 검토할 수 있는 기회를 준다.

마지막으로 각각의 Iteration에 대한 계획은 나중에 다룰 기회가 있으면 또 한번 다뤄보자.

어쩌다 규모산정을 한 김에 달리다보니 계획까지 와버렸다. -_-;;
어쩐지 진도를 다 못나간 느낌이다. 다음에는 다른 영역으로 진도를 나가보자. -_-;;

2011/03/24 13:37 2011/03/24 13:37
일주일쯤 됐나? 암튼 UML 개발강좌 2편이다.
먼저 다음의 그림에 주목하자.
사용자 삽입 이미지
요구사항은 인수테스트로 검토/테스트 되어야 하며, 고수준의 설계는 통합테스트로, 세밀한 스팩정의는 유닛테스트로 검토/테스트되어야 한다.
UML이 아무리 용빼는 재주가 있다고하더라도 이러한 Software Development Life Cycle을 빗겨갈수는 없다.

왜 그럴까?
우선 요구사항이라는 녀석의 존재 때문이다. 요구사항은 어디서 오는가? 너무 당연한 대답이지만 요구사항은 고객에게서 온다.
우선 고객의 특징을 살펴보면,

1. 고객은 단위업무전문가일 경우가 많다. 물론 예외는 존재한다.
2. 고객은 기술적으로는 문외한 일경우가 많다. 아무리 과거에 기술에 몸담았다고 해도 "지금"이라는 시점으로 짜르면 문외한 인건 똑같다.
3. 고객은 자기가 원하는 것을 표현하기 어려워 한다. 특히, 한국은 체면때문에 더 힘들어 한다.
4. 고객은 결국은 돈주는 사람이다.

즉, 고객은 요구사항을 내고 개발이 끝난뒤에 요구사항 대로 개발했는지 검토한후에 그 댓가를 지불하는 사람이다.
그런데, 여기서 문제가 발생한다. 결론부터 말하자면 우리의 좌뇌가 문제이다.
좌뇌는 논리와 언어를 담당하고 우뇌는 감성과 직관을 담당한다.
우리가 누군가에게 말을 하는 이상 좌뇌를 통할 수 밖에 없으며 좌뇌는 다음과 같이 "자동차를 만들어주세요."라고 하지만 우뇌는 어떤 그림을 상상하고 있을 것이다. 아마도 다음의 그림과 같지 않을까?
1. 고객
좌뇌 - 차를 만들어 주세요.
우뇌 -
사용자 삽입 이미지
2. 개발자
좌뇌 - 차를 만들어 달라고 하는구나.
우뇌 -
사용자 삽입 이미지

좌뇌는 똑같은 이야기를 하고 있지만 우뇌는 서로 다른 이야기를 하고 있는것이다.
그러나 우리는 우뇌에서 그린 이미지를 물질세계로 끌어내어 형상화한다.
그래서 우리에게는 말이 아닌 그림이 필요하며 그림을 간략하게 그리기위해 Diagram이라는 도구를 사용하는 것이다.
따라서, UML은 다음과 같이 정의할 수 있다.
"UML은 의사소통의 도구!"
따라서, UML을 자세히 그릴 필요성이 없다는 결론에 도달한다.
자세히 선이 어쩌구요, 뭐가 어떻고 따진다고 한들 그것이 코드로 그대로 반영되는것도 아니지 않는가?
그냥 문자로 되어 있는 요구사항을 Diagram으로 표현한것이 UML의 첫번째 "Use Case"이다.

USE CASE의 정체를 떠들다가 보니 벌써 이렇게 길어지고 말았는데 그 정체를 이렇게 장황하게 설명하는 이유가 바로 정체를 제대로 알아야만 정확한 선이 어쩌고하는 논쟁으로부터 벗어날 수 있으며 어느 정도의 수준으로 Use Case를 나눠야 하는지 기준이 서기 때문이다.
결론부터 이야기하자면

첫째, USE CASE는 요구사항의 집합이다.
둘째, USE CASE는 인수시험으로 검증될 수 있어야 한다.

위의 2개의 기준은 매우 중요한 개념이다. 밑줄 쫙쫙 긋고 머리속에 박아넣고 있어야 하는 개념이다.

이제 우리가 그리기로 했었던 "3D Navigation"의 USE CASE를 그려보도록 하자.

1. StarUML을 실행하고 "Default Approach"를 클릭
사용자 삽입 이미지

2. 이제 USE CASE를 그릴차례 우측 탐색창에서 <<USE CASE MODEL>>을 더블클릭하자
좌측에 도구함에는 Use Case에 사용되는 도구가 뜬다.
사용자 삽입 이미지

우리가 사용할 도구는 UseCase와 Actor, Association, System Boundary 정도이다.
붉은 박스외에 다른 모델들은 나중에 기회가 되면 설명하던가 자습을 하던가... -_-;; 뭐 암튼 그리 중요한건 아니다.
(정말로...)

3. 암튼 제한된 도구로 배치해보니 다음과 같다.
사용자 삽입 이미지
Use CASE 하나 하나는 "인수시험 케이스"라는 생각을 가지고 그리게 되면 위와 같이 된다.
물론 다른 생각을 할 수도 있다. 그러나 나는 이렇게 생각한다. 몇가지 설명을 덧붙이면
사람모양인 Actor는 사용자, 관리자, 외부시스템등을 표현한다. 즉, 현재 네비게이션을 제외한 모든 시스템, 사람을 Actor로 표현하는 것이다.
그리고 화살표와 선이 보이는데 이건 관계를 표현한다. "-->" 하든 "--"하든 둘중 아무거나 상관없이 써도 된다.
단지 나는 사용자의 입력을 표현하는 선은 "-->"로 했을 뿐이다.
그리고 설명이 부족한 부분은 Annotaion을 클릭해서 Note와 Notelink를 사용해 추가적인 설명을 붙여 둔다.
사용자 삽입 이미지
이까지 그리는데 5~10분 정도 걸린것 같다. 자랑이 아니라 대충 그렸다는 이야기다.
왜 대충그렸을까?
이 문서는 끊임없이 살아 있는 생명체와 같기 때문이다. 무슨 이야기냐면 "UML은 개정되어야 하기 때문이다."
매번 개정할텐데 힘들게 그릴 필요가 없다는 의미이다.

아무튼 요구사항이 도출되면 이정도까지 그려두자.
다음에는 기능점수(Function Point) 기준 견적에 관한 이야기를 할 것이다.
2011/03/21 11:19 2011/03/21 11:19
TAG ,