소셜 게임이나 웹 게임 만드시는 분이 많은 것 같습니다. 기술적인 고민 중 하나는 Flash 기반으로 갈 것인가, HTML 기반으로 갈 것인가 일텐데요 이게 좀 민감한 문제일 수 있죠. (대부분의 소셜 게임/웹 게임은 전통적인 2D 스프라이트 애니메이션에 간단한 스크롤 등으로 구현되므로 Unity3D 같은건 일단 뺍시다)

최근 Apple와 Adobe의 신경전, Google의 기묘한 행보(한편으로는 HTML5 미는가 싶으면서 또 한편으로는 Chrome에 Flash 류 지원 강화하고. 아마도... "난 그런거 몰라, 인터넷에 광고할거니까 광고판만 키워줘염" 이런 느낌), Adobe의 6월 반격설 등등.

기업 간 이권 다툼은 그렇다 치고, 당장 현실적인 문제를 따져보면:

  • Flash를 고르면 iPhone/iPad 대응 따로 해야하는데 상당히 귀찮을 수 있음.
  • HTML를 고르면 뭔가 느릴 것 같음. 게다가 iPhone 용은 인터페이스 등이 다를텐데 어차피 따로 만들어야 하는 것 아닌가?
요런 상황이죠. 대체로 Flash를 택하고 iPhone/iPad 용은 따로 개발한다는 식으로 방향을 잡는 것 같습니다.

만약 저한테 고르라고 한다면 두 개(잠시 후 설명하겠지만 정확히는 세 개)를 다 개발하는 방향을 고르겠습니다. Lean Software Development에서 말하는 Set-based development 전략입니다:

엔터프라이즈 애플리케이션을 개발하는 회사에 다니는 친구가 중요한 의사결정을 내렸던 일에 대해 이야기해주었습니다:

"시스템에 쓸 기술 플랫폼을 골라야했지. 근데 당시에 존재하던 세 개의 선택권 중 어떤 게 우리에게 가장 잘 맞는지 확실치 않았어. 그래서 세 가지 모두 개발하기 시작했지. 그러느라 시스템의 하단부가 조금 더 일반적인 방식으로 개발될 필요가 있었는데, 결국은 그 덕분에 시스템이 매우 견고해졌지. 프로젝트 종료 직전에서야 어떤 플랫폼을 선택해야 하는지가 명확해졌는데, 그 전까지는 플랫폼을 확정할 필요가 전혀 없었어. 막상 우리가 선택한 플랫폼은 프로젝트 초기에는 고려 대상이 아니었다네."

A friend from a company that does enterprise applications told us how he made a critical decision:

"We had to choose a technical platform for a system. However, it was not clear which of the three available options was going to be the winner, let alone meet our needs. So we started developing on all three. This required the underlying development to be a bit more general than otherwise, but it turned out to be quite robust because of that. It was really not necessary to decide on a platform until quite near to the end of the project, and by that time, the correct choice was pretty obvious, but it was not the one we would have made in the beginning."

--p43, Lean Software Development - An Agile Toolkit

세 개 플랫폼 모두에 대응해서 개발하다가 프로젝트 종료 시점에 하나를 선택하고 나머지 두 개를 버리라니, 실무라고는 하나도 모르는 이론쟁이의 정신나간 헛소리같죠. 게다가, 위 사례처럼 프로젝트 종료 전에 하라는 선택하는 것도 아니라 세 개를 계속 유지하면서 가라니.


1. 세 개의 플랫폼

보통은 Flash와 HTML 두 가지 플랫폼이라고 생각하기 쉽지만 현실적으로는 세 가지라고 봅니다:

  • Flash: IE 등 느린 브라우저를 위해.
  • Webkit: Safari CSS Visual Effects를 지원하는 Safari, iPhone, iPad.
  • Canvas: 현재 버전의 Chrome과 Firefox
  • (3D 배제한다고 했으므로 Canvas 3D + WebGL이나 Unity3D 등은 일단 KIN)
따라서 IE 버전, Webkit류 버전, Canvas 버전으로 랜더링 부분을 개발하고, 이 위에 iPhone 버전, iPad 버전, 브라우저 버전으로 UI 부분을 개발하는거죠.

어떻게? 자바스크립트와 좋은 설계로.

자바스크립트에서 호스트환경(브라우저, Flash Player 등)에 의존하는 코드를 몽땅 제거하면 해당 코드는 위 세 개 플랫폼에서 모두 사용할 수 있습니다. 80~90% 이상의 코드가 한 글자도 수정없이 모든 플랫폼에서 쓰일 수 있습니다.

대충 다음과 같이 분해하면 됩니다:
  • 입출력 담당 및 호스트환경에 대한 wrapper 코드 세 벌(Flash, Webkit, Canvas)
  • 입력을 해석하고 플랫폼에 맞게 출력을 배치하는 코드 세 벌(브라우저, iPhone, iPad)
  • 나머지 몽땅
작업을 진행하면서 풀어야할 문제들은:
  • Flash와 Webkit과 Canvas의 서로 다른 작동 방식을 어떻게 잘 추상화할 것인가 (성능에 미치는 영향이 최소화되는 방식으로)
  • "나머지 몽땅" 부분에 얼마나 많은 코드를 넣을 수 있을 것인가
등이 있겠습니다만 이것들은 대체로 mystery라기 보다 problem 수준이죠.

Flash/Webkit/Canvas를 추상화하는 문제는 생각보다 삽질이 필요할 수 있습니다. 한가지만 예를 들면, 스프라이트 애니메이션 관련 API를 다음과 같이 한다고 칩시다:
  • 스프라이트를 특정 좌표에 그려주는 API
  • 스프라이트를 원하는 위치로 이동시켜주는 API
이렇게 하고 부드러운 이동에 필요한 이징 함수 등은 직접 구현해서 "나머지 몽땅" 부분에서 처리한다 치면 Canvas와 Flash에선 괜찮을지 모르나 iPhone에선 성능이 느릴 수 있습니다. Webkit에서 이징은 CSS를 이용해 선언적으로 처리해야 iPhone에서도 빠른 속도로 구현됩니다.

이런 식의 문제(어느 정도 수준에서 추상화를 할 것인지)를 잘 해결하려면 각 기술(Flash, Webkit, Canvas)의 API를 어느 정도 이해하고 실제로 삽질도 좀 해봐야하지 않을까 싶어요.

2. 부가적인 이득

위에서 인용한 글귀에도 나오지만 부가적인 이점이 있습니다. "나머지 몽땅" 부분이 플랫폼 중립적인 방식으로 설계/구현된다는 점이죠. 이게 뭔 소리인고 하니:

  • 비교적 아름다운 API
  • 완전한 테스트 가능성 (실제 커버리지가 높냐 낮냐는 개발자가 얼마나 열심히 테스트 코드를 작성하느냐의 문제)
  • 이에 따라 견고하고 유지보수 비용이 낮은 코드 확보
소셜 게임이나 웹 게임 류는 런치 이후의 운영이 매우 중요한데 여러가지를 빠르게 테스트하고자 할 때(A/B Test가 됐건 아니건), 게임 내 여러 시스템(경제가 됐건 전투가 됐건)에 대해 다수 사용자의 인터랙션을 미리 시뮬레이션해보고자 할 때 등 온갖 지점에서 엄청난 이득으로 돌아올 것이라고 확신합니다.

에.. 이건 짐작인데요, 언젠가 "나머지 몽땅" 부분에 들어있는 로직 중 상당수를 서버에서 돌려야할 일이 (여러가지 이유로) 생길 가능성이 있는데, 이 때엔 서버측 코드 새로 짜지 말고 "SSJS (server-side javascript)"를 구글링해보세요. 짐작이기는 하지만, (현재 진행중인 프로젝트라면) 서버측과 클라이언트측에 같은 일을 하는 코드가 이미 상당히 쌓여 있을 것이다에 이 돈 몽땅과 제 손모가지를...


3. 발빼기

어... 전 소셜 게임 개발 안할겁니다.

ㅌㅌ


4. 예상 FAQ

Q1: JS로 짜면 플래시 버전도 꼬진 AVM에서 실행되니까 느리잖아요?
A: 소셜 게임으로 WoW 만들거 아니니까 괜찮습니다. FarmVille 정도는 가뿐하죠.

Q2: JS로 짜면 type checking은?
A: 유닛테스트 잘 만드세요. 피가 되고 살이 됩니다.

Q3: 안해보고 이런 글 써도 되나요?
A: 믿느냐 마느냐는 님의 선택. 진실은 저 너머에...

Q4: 개발도 안할거면서 이런 글 왜 쓰나요?
A: 개버릇 남 못줘서.

Q5: Webkit CSS랑 Canvas가 정말 쓸만한가요?
A: 구글링 plz. 참고로 아이폰에서 HTML/CSS/JS로 요런짓도 가능합니다.

Q6: "나머지 몽땅" 부분에 8~90% 코드를 넣으려면 어떻게 설계를 해야?
A: 소프트웨어 설계에 대한 책들을 참고하세요. 이를테면 패턴 책이나.


...


PS: 행여나 이 글에 낚여서 삽질을 하시다가 프로젝트가 산으로 가면 제가 밥 한끼 정도 사드리는 것으로 보상을.



저작자 표시
신고

설계가 완벽할 수 없는 이유를 읽고 씁니다.

저는 윗 글에 동의합니다. 설계는 완벽할 수 없습니다(사실 명제). 그리고 저는 설계를 완벽하게 하는 것이 가능하다고 하더라도 그렇게 해서는 안된다고 생각합니다(가치 명제).


1. 설계가 완벽할 수 없는 이유

소프트웨어는 소프트한가?에서도 인용한 적이 있고, 윗 글에도 나와있지만 짧게 요약하자면 세상이 바뀌거나, 내가 더 똑똑해지기 때문에 완벽한 설계란 좀처럼 얻어내기가 힘듭니다.

하지만 가정을 해봅시다. 세상(and/or 요구사항)이 바뀔 일도 없고, 나는 이미 천재이고 모든 도메인 지식을 다 가지고 있기 때문에 더이상 똑똑해질 일도 없다고 칩시다. 그렇다면 설계가 완벽해질 수 있을 것입니다. 그런데, 설계를 완벽하게 하고나서 코딩을 시작하는 것이 과연 좋을까요?


2. 설계가 완벽하지 않아야 하는 이유

2.1. 완벽한 설계의 가치

완벽한 설계(design)라는 가정 이면에는 완벽한 분석(analysis)이 전제되어 있습니다. 하지만 설계는 설계일 뿐 작동하지 않습니다(Executable UML 같은 시도도 있지만 뻘짓으로 간주하겠습니다). 그리고 작동하지 않는 소프트웨어는 고객에게 아무런 가치를 전달하지 못합니다.

즉, 완벽한 분석에 이어 완벽한 설계를 하느라 프로젝트 기간의 (이를테면) 절반 정도가 지나도 프로젝트는 아무런 가치를 창출하지 못합니다. 그 이후에 구현 조금, 테스트 조금, 배포 조금 하는 방식을 따른다면 이 때부터 가치가 창출되기 시작하겠지만 선행 분석/설계를 하는 프로젝트의 대부분은 끝까지 그 스타일을 유지하죠. 완벽한 설계 이후에는 완벽한 구현과 완벽한 테스트 단계가 오고, 그제야 완벽한 배포를 하는 소위 완벽한 폭포수(waterfall) 프로세스가 완성됩니다. 결국 프로젝트가 완전히 끝나야 가치가 전달되기 시작합니다.

2.2. Self-funding point와 BEP

애자일 방법론에서는 사용자에게 가치를 주는 작은 기능들을 단위로 하여 약간의 분석/설계/개발/테스트/배포를 짧은 주기로 반복합니다. 따라서 프로젝트 초창기부터 작동하는 소프트웨어를 고객에게 전달할 수 있게 됩니다. 다음은 폭포수 방식과 애자일 방식의 차이를 극명하게 보여주는 그래프입니다:


출처: The Origin of Value

참고로, Self-funding point란 프로젝트에서 발생하는 수익이 프로젝트를 지속하기 위한 비용과 일치하는 지점을 말합니다. 이 지점을 지나면 프로젝트는 소위 "밥벌이"를 한다고 볼 수 있습니다. 한편, 프로젝트에 현재 투입되고 있는 비용을 지속적으로 자체 충당(self-funding)하면서, 그 이전에 투입된 비용까지 다 갚아버리는 지점을 BEP - 손익분기점 - 라고 합니다.

빨간 선은 프로젝트에 투입되는 비용입니다. 위 그래프에서는 애자일이나 폭포수나 투입되는 비용이 동일한 것으로 간주하고 있습니다. 애자일 방법론을 실천하는 사람들은 애자일 방법론이 더 저비용일 것이라고 주장할 것이고, 폭포수 방법론을 실천하는 사람들은 폭포수 방법론이 더 저비용일 것이라고 주장할 것인데, 이 부분에서는 일단 중립을 지켜보도록 하죠.

녹색선은 애자일 프로젝트가 만들어내는 가치입니다. 짧은 이터레이션을 돌면서 잦은 릴리즈를 하기 때문에 프로젝트 초반부터 가치를 생산하기 시작합니다. 파란선은 폭포수 프로젝트가 만들어내는 가치입니다. 앞에서 설명한 이유로 인해 프로젝트 막바지가 되어야 가치가 생산되기 시작합니다.

녹색선은 애자일 방법론에 유리한 방식으로 약간 편향되어 있는데, 좀 더 공평하게 하자면 기울기가 초기에는 낮다가 점점 높아지는 꼴을 취해야 합니다. 왜냐하면 초반에는 기능의 수가 적기 때문이죠. 그래프를 그런 식으로 수정하고 나면 애자일 프로젝트의 self-funding point가 조금 더 늦춰지겠지만 여전히 폭포수 프로젝트에 비해서는 빠르겠죠. 그리고 이 상태가 유지된다면 애자일 프로젝트가 폭포수 프로젝트에 비해 훨씬 이른 시기에 BEP(break-even point. 손익분기점)에 도달합니다.

추가: 위 그래프에서 애자일 방법론의 self-funding point라고 한 부분은 사실 BEP로 표시되어야 하는데 잘못 표시한 것이 아닐까 싶습니다. self-funding point는 녹색선의 기울기가 빨간선의 기울기와 같아지는 지점이어야겠죠. 이 그림보다 예쁜 그림이 Software by Numbers 본문에 나오죠:

이 그림에서는 기울기의 변화와 면적을 보시면 됩니다. 초기 투자 기간(Investment period)의 기울기가 서서히 변하고 있는 까닭은 초기부터 가치를 전달하고 있기 때문입니다. 하지만 아직은 비용이 더 크기 때문에 전체적인 가치(면적)는 마이너스 입니다. 하지만 특정 지점(self-funding point)에 이르르면 프로젝트에 투입되는 비용과 프로젝트가 창출하는 가치가 같아집니다(기울기가 0). 그 이후엔 투입되는 비용은 고정된 반면 창출되는 가치는 점점 늘기 때문에(지속적인 릴리즈) 기울기가 점점 높아집니다. 이 기간동안 초기에 투입된 비용을 갚아나갑니다(payback period). 이 상태가 지속되면 어느 순간 손익분기점(break-even time)에 도달하고 그 이후부터는 수익이 발생하기 시작합니다.


2.3. 프로젝트 중단

프로젝트가 잘 굴러가고 있다가도 갑자기 중단되는 경우가 있습니다. 일선 관리자들이나 개발자 같은 실무자들은 대체 왜 그런 결정이 내려졌는지 자세히 알지 못하는 경우가 많지만 어쨌건 빈번하게 발생하는 일입니다. 위 그래프에서 x축으로 10 정도 되는 지점에서 프로젝트가 중단되었다고 칩시다.

그래프 상으로 애자일 프로젝트는 이미 BEP를 지나 수익을 발생시키고 있지만 폭포수 프로젝트는 아직 투자 단계입니다. 사실 재무/회계 관점에서 소프트웨어 프로젝트가 거대한 블랙박스로 인식되지 않고 릴리즈 단위로 인식될 수 있다면 애자일 프로젝트는 self-funding point 이후엔 어지간해서는 중단될 이유가 없어집니다(재무/회계 관점에서 당장 그렇게 인식되지 않는다 하더라도 적어도 방어 논리를 약간은 만들어낼 수 있을겁니다).

여기서 강조하고 싶은 이야기는, 재무/회계 관점에서 소프트웨어 프로젝트가 좀 더 정밀하게 분석되면 될수록 폭포수 방식의 문제가 더 크게 부각될 것이라는 점입니다.

2.4. 재고와 도요타 생산 방식

과잉 재고는 나쁜 것입니다. 1) 재고를 최소화하고, 2) 공정 상의 흐름이 끊기지 않게 하고, 3) Push 방식이 아닌 Pull 방식을 채택하면 일단 표면적인 도요타 생산 방식이 만들어집니다. 이 중에서 이 논의와 특히 관련이 깊은 것은 앞의 두 가지 입니다. 소프트웨어에서의 재고란 노력이 투입되었으나 아직 최종 사용자의 가치와 연결되지 않은 모든 것을 말합니다. 완벽한 설계는 전형적인 재고입니다. 둘째, 공정 상의 흐름이 끊어지지 않으려면 각 단계에서 작은 단위로 끊임없이 가치가 흘러야 합니다. 앞 단계에서 거대한 작업이 끝날 동안 뒷 단계에서 손 놓고 대기하고 있으면 흐름이 끊어지는 것입니다. 완벽한 설계는 흐름을 끊기게 하는 주요 원인입니다. 완벽한 분석, 완벽한 구현,완벽한 테스트도 마찬가지 입니다.

(얼마 전에 프로젝트 시작부터 개발자가 바글바글이라는 글을 읽었는데, 프로젝트 시작부터 개발자가 바글바글한 것이 문제인 이유는 공정 상의 흐름이 끊기기 때문입니다. 즉, 앞의 공정(완벽한 분석과 설계)이 끝나지 않으면 개발자가 놀아야 하는 것이 문제인거죠. 이에 대한 해법은 두 가지입니다. 하나는, 처음엔 개발자 없이 시작해서 프로젝트 중간에 개발자를 투입하는 것, 또 하나는 공정이 끊기지 않게 해서 초반부터 개발자가 일을 할 수 있게 하는 것.

하지만, 전자의 방식대로 하려면 조직 구조가 인력 풀 방식 혹은 직군별 팀 방식으로 운영되어야 하고 각 프로젝트의 특정 단계에 소위 "투입"되거나 "파견" 나갔다가 해당 단계가 끝나면 "철수"하는 식으로 일을 해야 합니다.

이러한 조직 구성이 효과적인 면도 분명 있겠지만 저는 별로 인간적인(humane) 방식이 아니라고 생각하고, 인간은 인간적인 방식으로 일해야 즐겁고 효과적으로 일할 수 있을 것이라고 믿습니다. 이 문제는 다음 기회에 더 쓰도록 하겠습니다. Ray님 블로그의 글은 잘 읽고 있습니다만 워낙 서로의 경험이 다르기 때문인지 의견 차이가 큰 것 같습니다. 그래서 더 열심히 읽고 이해하려고 노력하고 있습니다.)

이 밖에 "The Goal"의 제약이론도 관점이 약간 다르지만 이와 유사한 내용을 담고 있죠. 이에 대해서는 도요타 방식과 제약이론이라는 글을 참고해주세요.


3. 결론

이러한 이유로 저는 완벽한 설계가 가능하다고 하더라도 완벽한 설계를 하지 않는 것이 더 좋다고 생각합니다.


저작자 표시
신고

"소프트웨어는 소프트하지 않다"를 읽고 씁니다.


1. 소프트웨어 변경 비용 모델들

소프트웨어의 기능을 변경하고자 할 때 비용이 적게 들면 이를 두고 "소프트"하다고 표현합니다. 전통적으로는 프로젝트가 시작되고 시간이 흐를수록 변경 비용이 기하급수적으로 증가한다고 말합니다. 즉, 프로젝트 초창기에는 소프트하지만 시간이 지날수록 점점 소프트하지 않게 된다는 얘기입니다. 그림으로는 보통 이렇게 그립니다:

[그림1. 전통적 모델]

Y축이 비용(Cost), X축이 시간(Time) 입니다. Barry Boehm이 대략 30년 전에 그린 그림인데 여전히 많이 인용되고 있죠. 프로젝트 초기 단계에는 구현된 결과물이 없을 테니 변경이라는 것은 고작 머리 속 생각을 바꾸는 정도일 것이고 변경 비용은 거의 0에 가깝습니다. 한편, 프로젝트가 완료되고 현장에 배치(deploy)되거나 포장되어 매장에 출시된 후에 기능을 수정하고자 한다면? 엄청난 비용이 들 수 있습니다. 일견 맞는 말 같습니다.

하지만 10년쯤 전 Kent Beck은 소프트웨어 변경 비용을 아래와 같이 낮출 수 있다고 말합니다:

[그림2. Kent Beck의 그래프]

애자일 방법론의 여러 실천법(agile practices)을 통해 그렇게 할 수 있다고 주장합니다. 간결한 설계, 지속적 통합, 잦은 릴리즈, 테스트 주도 개발, 리팩토링, 짝 프로그래밍, 전체 팀 등 다양한 요소들이 이러한 변경 비용을 가능하게 해준다고 말합니다.

이 두 가지 극단적인 주장들(그림으로만 보자면)의 중간쯤 되는 모델들도 있죠. 이를테면 Poppendieck 부부의 Lean Software Development에서는 그래프 두 개를 합쳐놓아야 한다고 주장합니다:

[그림3. 짬뽕1]

크리스탈 방법론으로 유명한 Alistair Cockburn이나 IBM의 Scott Ambler 등도 이와 비슷한 모델을 제시했었죠. David  Anderson은 Agile Management for Software Engineering이라는 책에서 이를  S-Curve 모델이라고 부릅니다:

[그림4. 짬뽕2]

대충 두 부류로 나누자면 Boehm의 그림(1번)을 전통적 변경 비용 모델로, 나머지 그림들(2,3,4번)을 애자일 변경 비용 모델로 볼 수 있겠습니다.


2. 소프트웨어가 소프트해야 하는 이유

실제로 소프트웨어가 소프트한지 아닌지(사실 명제)를 이야기하기 전에, 소프트웨어가 소프트해야 하는지 아닌지(가치 명제)를 따져보면 좋겠습니다.

소프트웨어 프로젝트가 실패하는 원인 중 단골로 꼽히는 것이 “요구사항의 잦은 변화”입니다. 요구사항의 변화 빈도를 낮추면 성공 확률을 높일 수 있다는 해석이 가능합니다. 변화 빈도를 낮추려면 소프트웨어가 소프트하지 않다는 인식을 심어주어야 합니다.

한편, “요구사항의 잦은 변화”라는 문제에 대해 근본원인분석(root cause analysis)을 해보면 다른 해법을 찾을 수도 있습니다. 애초에 요구사항이 자주 변하면 왜 문제가 되는지를 따져보는 것이죠. 그 이유는 당연히 변경 비용이 크기 때문입니다. 그렇다면 변경 비용이 대체 왜 큰 것인지를 다시 물어보는 것이죠. 결국 변경 비용을 증가시키는 원인을 찾아서 이를 충분히 제거할 수 있다면 요구사항의 잦은 변화는 더 이상 문제가 아니게 됩니다.

이와 같이 “요구사항의 잦은 변화”라고 하는 동일한 문제에 대해 서로 다른 두 가지 해법이 존재합니다. 이 두 가지 해법 중 어느 것이 더 나은 방법일까요? 애자일 방법론에서는 당연히 후자가 나은 방법이라고 말합니다.

프로젝트 성공률을 높이기 위해 요구사항의 변화를 막는 것은 기본적으로 Win-Lose 게임입니다. 프로젝트가 성공하면 개발사는 돈을 받을 수 있어서 좋지만 개발을 의뢰한 고객은 프로젝트가 진행되는 동안 발생한 시장의 변화에 맞추어 요구 사항을 수정할 기회를 포기해야 하니까요. 게다가 시장이 변하지 않더라도 요구 사항은 수정될 수 있습니다. 왜냐하면 프로젝트가 진행되는 동안 시장에 대한 우리의 지식이 변하기 때문입니다. (코드가 바뀌어야 하는 이유 참고)

따라서 소프트웨어는 소프트해야 합니다.


3. 소프트웨어는 소프트한가?

소프트웨어가 소프트한게 좋다고 치고, 그럼 과연 소프트웨어는 실제로 소프트할까요? 이게 중요한 질문일 수 있죠. 하지만 이 질문은 사실 예/아니오 질문이 아닙니다. 정도(degree)의 문제입니다. 따라서 질문을 바꿔야죠.

“소프트웨어는 얼마나 소프트한가?”

이 질문에 대해서도 대답하기가 쉽지 않습니다. 왜냐하면 어떤 소프트웨어이냐에 따라 다르고, 우리가 프로젝트를 어떻게 수행 하느냐에 따라 다르기 때문이죠. 그래서 질문을 또 바꿔야겠습니다:

“소프트웨어는 얼마나 소프트해질 수 있는가?”

질문을 이렇게 바꾸면 답을 할 필요가 별로 없어집니다. 소프트웨어는 소프트해야 한다는 위 논의에 동의하기만 한다면, 이 질문에 대한 답이 없어도 질문을 보는 순간 우리가 뭘 어떻게 해야 하는지 감이 오기 때문이죠.

우리는 소프트웨어가 최대한 소프트해지도록 노력해야 합니다. 고객에게 소프트웨어가 소프트하지 않다는 인식을 심어주기 위해 노력할 것이 아니라, 양자가 어떻게 협업을 해야 소프트웨어가 주어진 상황 하에서 조금이라도 더 소프트해질 수 있는지 알아내기 위해 노력해야 합니다.

이상적인 얘기라고 생각하실지 모르겠습니다. 그럴지도 모르죠. 특히나 내부 고객을 상대하는 상황이 아닌 대다수의 SI 프로젝트에서는 꿈 같은 얘기일 수도 있습니다.

이게 가능하냐 안 가능하냐를 떠나서 우리가 지향할 바가 무엇이냐에 대한 얘기라고 생각해주시기 바랍니다.


4. 관련자료


저작자 표시
신고
Kent Beck의 저서 익스트림 프로그래밍(Extreme Programming Explained)은 훌륭한 비유들로 가득 차 있습니다. XP 실천가들에게는 어떤 면에서는 성경과도 같은 책이죠(음, 너무 진지하게 받아들이지는 말아주세요. 약간은 농담입니다).

아래는 "운전 배우기(learning to drive)" 비유입니다.
Kent Beck님께서 비유로써 말씀하시되,

Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way. This is the paradigm for XP. Stay aware. Adapt. Change. --p11

(운전이라는 것은 차를 무작정 똑바로 몰고 가는 것이 아니다. 지속적으로 신경을 써가며 이쪽으로 조금 틀어주고 저쪽으로 조금 틀어주고 하는 것이다. 이것이 XP의 패러다임이다. 항상 깨어있고, 적응하고, 변화하라.)

하시니라. 또 비유로써 말씀하시되,

No book of gardening, however complete, makes you a gardener. First you have to garden, then join the community of gardeners, then teach others to garden. Then you are a gardener. So it is with XP. --p15~16

(정원관리에 관한 아무리 완벽한 책도 여러분을 정원사로 만들어주지 않는다. 정원사가 되려면 일단 정원 관리를 해보아야 하고, 정원사 모임에도 참여해야 하고, 다른 사람들에게 정원 관리를 가르쳐보기도 해야 한다. 그때에야 여러분은 정원사가 되는 것이다. XP도 마찬가지이다.

하시니라. 누구든지 이 책으로 말미암지 않고서는... 후략.
참고로, 정원관리는 위 의미 이외에도 여러가지 면에서 유용하게 쓰이는 비유입니다(Programming is Gardening).

* 예전 블로그에 2006년 1월 30일에 올린 글인데 퍼왔습니다.

신고
"불확실성과 화해하는 프로젝트 추정과 계획"을 읽었습니다.

중이미지보기

원제는 "Agile Estimating and Planning" 이고, "사용자 스토리(User Story Applied)"의 저자가 쓴 후속작입니다.

흥미롭게 읽은 내용들은 위키에 요약을 해두었으니 참고하시기 바라구요, 이 포스트에서는 14장(이터레이션 계획 과정)에서 소개하고 있는 이터레이션 계획의 두 가지 방법인 "속도 중심 계획법"과 "서약 중심 계획법"에 대해 써보려고 합니다.

회사에서 이 책으로 간단한 토론회 같은 것을 했는데 "서약 중심 계획법"에 대한 약간의 오해 같은 것이 있었거든요. 근데 듣고 보니 다른 분들도 오해를 할 수 있겠다는 생각이 들어서요.

오해가 뭐였냐면... 요약하자면 이렇습니다:
속도 중심 계획법에서는 지난주에 끝낸 스토리 점수(story point)에 따라 이번주 속도가 결정되는데, 속도라는 것은 원래 변하기 마련이라고 생각하는 바람에 주어진 스토리를 꼭 끝내야겠다는 의지가 부족하다. "서약"이라는 것이 필요하다. 그래서 서약 중심 계획법이 좋은 것 같다.

이런 것이죠. 하지만 속도 중심 계획법이건, 서약 중심 계획법이건 주어진 스토리를 끝내기 위해 최선을 다 할 것이라는 점에서는 차이가 없습니다. 서약 중심 계획법이라고 해서 더 엄숙하게 "서약합니다~" 이러고, 속도 중심 계획법이라고 해서 "하는대로 하다가 안되면 마는거지 뭐~" 이러는 것이 아니라는 말이죠.

그렇다면 두 계획법이 대체 뭔 차이인가?

속도 중심 계획법은 현재의 팀 속도(velocity)에 기반하여 이번 이터레이션에서 수행할 스토리들을 모두 정한 후에 이를 작업(task) 단위로 분해합니다. 팀 속도에 의해 스토리가 push 되는 방식입니다.

한편, 서약 중심 계획법은 스토리를 한 번에 하나씩 골라서 작업 단위로 분해하고 이를 시간 단위로 추정합니다. 그렇게 하고 나서 이번 이터레이션에 스토리를 추가로 더 구현할 수 있는지 물어봅니다. 개발자들이 판단하기에 그게 가능할 것 같으면 스토리를 하나 더 뽑습니다. 전자와 다르게 pull 방식으로 계획을 하는 것이죠.

이 부분 번역이 뭐랄까 좀 미묘하게 되어 있는데요, 예를 들어 아래 문장의 경우:
...'어제의 날씨'에 근거해 얼마나 많은 스토리 점수나 이상적 작업일이 다음 이터레이션에 필요할지를 결정하는 대신, 팀은 더 이상 하겠다는 약속을 할 수 없을 때까지 사용자 스토리를 이터레이션에 하나씩 추가해 넣는다. --p226

원문은 이렇습니다:
... rather than creating an iteration plan that uses the yesterday's weather idea to determine how many story points or ideal days should be planned into the current iteration, the team is asked to add stories to the iteration one by one until they can commit to completing no more.

여기에서 중요한 것은 "한 번에 하나씩"인데, 이런 부분이 번역문에서는 약간 강조가 덜 된 느낌이예요. 트집 잡자는 것은 아니고, 살짝 아쉽다는 ^^; (전체적으로 잘 읽히는 번역입니다). 아래와 같이 해보면 원문의 뉘앙스가 조금 더 살지 않을까 싶어요(정확한 번역이라기 보다 느낌을 살리기 위해 좀 뺐습니다. 실제로 책 번역할때 이런 식으로 막 빼면 곤란하죠 ㅎㅎ):
...이번 이터레이션에서 수행할 스토리의 양을 "어제의 날씨"에 근거하여 한번에 정하는 대신, 팀은 더 이상 하겠다는 약속을 할 수 없을 때까지 스토리를 한번에 하나씩 추가해 넣는다.

"어제의 날씨"에 근거하여 한번에 스토리를 왕창 밀어넣느냐(push), 스토리를 하나씩 task로 분해하면서 당겨오느나(pull)의 차이라는 것입니다. 속도에 의해 자동으로 push 되니까 속도 중심 계획법, 할 수 있다고 생각하는만큼 땡겨오니까 서약 중심 계획법인겁니다.

그래서 결과적으로는 뭐가 다른가? 전자는, 일단 스토리를 왕창 할당 받은 다음에 task로 분해해봤더니 생각보다 작업량이 많더라 하는 경우가 발생해도 이미 빼도박도 못한다는 거죠. 이로 인해 발생할 계획의 차질은 다음 이터레이션이 되어야 "팀 속도 보정"이라는 형태로 나타날 것이고요. 후자는 이런 문제가 없겠죠. (이에 대한 설명이 232 페이지에 있습니다)

신고
http://www.uie.com/articles/failure_not_an_option

위 글을 요약/번역하였습니다. 배울 점들이 있는 것 같아요.

제목: 실패는 선택이 아니라 필수이다.

0. 서문

최근 몇 달간 팀이 고생을 했다. "열라고생해서오픈했어요"라는 종류의 고생이 아니라 "리뉴얼했는데수익이확줄었어요"라는 종류의 고생이다. 사용자의 경험이 극적으로 향상될 것을 기대하며 매우 새로운 디자인을 시도해봤는데 실패했다.


1. 실패는 항상 나쁜 것인가?

실패를 최소화하는 것이 좋다고 생각하기 쉽다. 아무도 "저 놈이 프로젝트 말아먹은 그 인간이야" 하고 속닥이는 소릴 듣고 싶어하지 않을 것이다. 하지만 몇 세기에 걸친 위대한 혁신들을 살펴보면, 실패가 매우 중요한 역할을 했음을 알 수 있다. 뭔가를 배우기 위해서는 반드시 실패가 필요하다.

성공을 하면 성공을 했다는 그 사실 외에 뭔가를 배우기가 매우 어렵다. 반면 실패를 하면 무엇을 개선해야 하는지 배울 수가 있다. 세상에서 가장 넓은 여백(room)은 개선의 여지(room for improvement)라는 말이 있다.

우리에겐 실패가 필요하다. 한편, 실패에 따른 리스크를 최소화하는 것 또한 중요하다.


2. 천천히-꾸준히 접근법

아마존 같은 사이트는 디자인 개편이 조금만 잘못되어도 엄청난 손실을 입는다.

아마존은 지난 여름에 네비게이션 UI를 개선했는데 아무 보수적으로 접근했다. 아마존 쿠키(cookie)가 없는 고객들을 대상으로 UI를 노출시키고 점진적으로 확대 적용하는 방식을 채택했다.


3. 위험을 완화하기

이 방식은 시간이 좀 오래걸린다는 단점이 있지만 위험을 최소화할 수 있다는 점에도 좋다. 페이퍼 프로토타이핑을 잘 활용하는 것도 위험을 완화하는 한가지 방법이다. 또 다른 방법은 빠른 반복적(iterative) 프로세스를 적용하는 것이다.


4. 실패에 대한 오해들

여러 팀의 기획/디자인 방법을 조사하여, "생산적으로 실패하기"를 저해하는 몇 가지 공통적인 실수들을 모아보았다.

실수1 - 명확한 비전 없이 작업하기.
실수2 - 실패 후 분석(introspection)않고 지나가기
실수3 - 실패로부터 배운 교훈들을 공유하지 않기
실수4 - 반복(iteration)이나 실험에 시간을 들이지 않기
실수5 - 변화에 유연하게 대처할 수 없는 플랫폼
실수6 - 피드백 없이 너무 많은 것을 만들기
실수7 - 측정 없이 기획/디자인하기
실수8 - 불충분한 피드백. "도움이 됐습니까? 예/아니오" 정도는 부족하다.


5. 실패에 대한 문화

이번 조사에서 밝혀진 가장 중요한 요소는 실패를 대하는 조직의 문화이다. 실패를 받아들이고 이로부터 경험을 얻어 성장하게 된 점을 축하해주는 문화가 필요하다.

----
여기까지 입니다. 발번역 읽느라 고생하셨습니다 ㅋ

참고로, 다음 글도 추천합니다 - 픽사는 어떻게 집단 창의성을 길러냈을까. 제가 존경하는 직장 동료가 번역한 글입니다.

신고
< Newer     Older >

티스토리 툴바