free-vahn

본문

xprogramming.com RonJeffries 의 'The King's Dinner' 에 대한 오상인 님의 번역글.

--------------------------------------------------------------------------------
아래 글은 제가 전에 번역했던 것입니다. 지금 보니 넘 형편없는 번역 솜씨군요 .. ^^;

www.xprogramming.com 사이트를 둘러보는 중에 글이 너무 좋아서 번역을 하게 되었습니다. 솔직히 번역을 해 놓고 보니까 글을 읽는 것 하고 번역하는 것과는 너무나도 틀리군요. 글을 읽을 때에는 그냥 문장의 요지만을 이해하는데 중점을 두는데 번역은 단어 하나하나에도 신경을 써야되니까 힘드네요. 그리고 번역을 하다 보니까 저의 영어 문법 실력이 너무나 형편없음을 실감하게 되네요. 중고등학교때 영어 공부 좀 해둘꺼하는 아쉬움이 드네요. 현재에 영어를 문법부터 하자니 시간이 없네요. (현재 건설현장에서 종사(?)하고 있어서, 퇴근하고 나면 완전히 녹초가 되어서 공부하는게 힘드네요.^.^;, 이거 번역하는데 틈틈히 시간을 내어서 삼일 정도 걸린 것 같네요)


이 글은 XP에서 네가지 변수인 Cost, Quality, Scope, time에 대해서 왕과 한 장인과의 이야기를 하고 있습니다. 이 글의 저자인 RonJeffries는
Cost라는 용어 대신에 Resource라는 단어를 썼네요. 이 글을 읽고나면서 저는 KentBeck 만큼이나 이 사람을 좋아하게 되었습니다. 이 사람이 아마 C3의 일원이었나요? 이 글에서 왕은 고객, 수석 장인은 프로그래머 그리고 마법사는 조언자(coach)로 비유되고 있네요.


전에 XPE와 PXE를 읽었을 때 네가지 변수에 대한 내용이 어렵게 느껴졌었는데 이 글은 너무나도 쉽게 설명을 하고 있네요. 같은 내용인데도 설명 방법에 따라서 엄청난 차이가 있음을 실감하네요. 이런식으로 XP를 설명하면 더 XP를 이해하는데 도움이 되지 않을까 생각이드네요. 담에 시간이 되면 이런식으로 XP를 설명하는 글을 써볼까하네요. 이 글을 읽고 의미가 이상하다거나 더 좋은 문장과 해석이 약간 안된 부분에 대한 의견을 달아주시면 좋겠네요.


왕의 만찬(The King's Dinner)


이 짧은 이야기는 자원(Resources), 품질(Quality), 범위(Scope) 그리고 시간(Time)의 주요 측정 변수 관점에서 팀을 효과적으로 운영하는 방법에 대해서 설명을 한다. 이 글은 Ron Jeffries가 바빌로니아의 설화를 번역한 것이다.


옛날 옛적에 …


자신의 가장 가까운 수천 명의 친구들을 위한 국가적인 만찬(State Dinner)을 바라는 왕이 살았다. 그는 자신의 수석 장인(Chief Artsan)을 불러서 만찬 계획을 알렸다. 왕은 자신이 원하는 훌륭한 테이블 셋팅(settings) - 모두 금이고 온통 보석으로 아로새겨진 - 방법에 대해서 설명을 했다. 수석 장인은 약간의 초안을 잡고 왕이 바라는 바에 동의했다. 왕과 수석 장인은 몇 주내에 다시 만나기로 약속과 테이블 셋팅에 대한 제작 일정(schedule)을 잡는데 동의했다.


몇 주후에, 수석 장인은 왕에게 알렸다. 수석 장인은 왕에게 원형 셋팅(prototype settings)의 생성을 보이는 시간 일정과 최종 테이블 설정에 대한 제작 일정을 제시했다. 그 일정은 11월내에 끝내는 것이다. 그러나, 왕은 날씨가 좋은 10월의 어느 날에 연회를 하기를 원했다. 다음 회의 전에 수석 장인은 10월까지 완료되는 것에 동의했다.


일정대로 수석 장인은 원형 모델을 가지고 나타났고, 10월까지 완료되게 제작 일정을 수정했다. 수석 장인은 또한 진행 과정을 확인하기 위해 주기적으로 만나기를 권했다. 왕은 짧은 마감 시간상의 이유로 장인이 간략화한 원형 모델을 검토했다. 왕은 접시에 더욱 많은 케루빔(cherubs, 아기 천사의 그림), 보석으로 치장된 더욱 아름다운 조각과 나이프와 포크에 더욱 복잡한 소용돌이 장식을 요청했다. 수석 장인은 이러한 새로운 형태는 일정을 위태롭게 한다고 얘기했지만, 왕은 장인에게 누가 왕이고 왕이 아닌지를 상기시켰다(역주 : 아마도 왕은 자신이 지위가 높으니 자신의 말을 무조건 따라야 한다고 말하는 것 같다). 수석 장인은 물러났다.


다음 회의시, 다소 시간이 늦어졌다. 너무 적은 보석이 준비되었다. 그래서 접시는 완전하지 않았고, 너무 적은 나이프와 포크가 준비되었다. 왕은 장인에게 더욱 열심히 일하라고 요구했다. 수석 장인은 반발했지만, 왕은 다시 자신과 수석 장인간의 상대적인 위치를 상기시켰다. 왕은 추가적인 재검토를 요구했다. 심지어 이미 동의했던 것보다 더욱 자주 말이다.


다음 회의시, 더욱 많은 것이 완료되지 않았다. 왕은 완료된 것을 보기 위해 작업장(shop)을 방문하기를 마음먹었다. 다음날 왕이 도착했다. 장인들(역주: 작업장안에 있는 장인들이다. 수석 장인을 포함하여)은 다소 안절부절못했지만, 그들은 자신들의 기술을 알고 있으며 대개 보통의 노력으로 계속 일을 했다(?, 이 부분 해석이 영 다소 이상하군요. 제가 워낙이 영어와 국어가 딸리니 좋은 해석이 안되네요). 아무 것도 하고 있지 않은 사람을 가리켜 "저 사람은 무엇을 하고 있느냐?"하고 왕이 물었다.


"오, 왕이시여! 그는 눈과 손을 쉬고 있습니다"라고 수석 장인이 대답했다.
"괘씸하고 무례하게 시간을 낭비하고 있군. 저들은 밤에 쉬어야지, 작업 중에는 아니다"라고 왕은 얘기했다.
"오, 왕이시여! 지당하신 말씀이십니다."라고 수석 장인이 대답했다.
"저쪽에 있는 사람은 지금 무엇을 하고 있느냐?"하고 왕이 물었다.
"오, 왕이시여! 그는 자신의 연장을 다듬고 있는 중입니다"라고 수석 장인이 대답했다.
"또다시 시간을 낭비하고 있군. 일이 잘 안되는 것이 이상할게 없군. 차후, 도구를 다듬는 것은 작업 중에가 아니라 밤에 하도록 하여라"라고 왕이 말했다.
"오, 왕이시여! 왕께서 바라는 데로 하겠나이다"라고 수석 장인이 한숨을 쉬며 말했다. 다음 검토 때까지 그들은 만나지 않았다(They parted until the next review. 원문에는 이렇게 나와 있는데 parted라는 해석을 어떻게 해야할지 고민했다. 문장상 서로 떨어져 지냈다는 의미로 해석했다).


다음 검토시의 중도에서, 수석 장인은 수석 집사(Chief Steward)에게 작업하는데 도움을 줄 새로운 견습생 - 특히 연장을 다듬는 - 을 요청했다. 왕의 예산에 염두는 두는 집사는 집사의 구시대적인 방법으로 문제를 해결했다. 그것은 요청에 응답하지 않는 것이다.
다음 검토시, 실제로 더욱 많은 작업이 완료되었다. 왕은 완성된 접시와 용품들을 관찰했다. 처음에 만족스러운 미소였지만, 더욱 자세히 살펴볼수록 눈살을 찌푸리게 되었다. "이 접시의 케루빔 장식은 거칠군, 좋지 않아. 이것이 그대가 최선을 다해 할 수 있는 것이라면 손님들에게 감명을 주지 못할 것 같군."라고 왕은 투덜거렸다.


"오, 왕이시여! 작업은 거칩니다. 그것은 왕께서 무딘 연장을 사용하라고 했기 때문입니다"라고 수석 장인이 대답했다.
"짐은 서투르게 작업을 하라고 명령한 적이 없다, 장인이여! 짐은 시간을 낭비하지 말라고 했다!"라고 왕이 말했다.
"오, 왕이시여! 왕께서 좋은 음식과 셋팅 없이 좋은 연회를 할 수 없는 것처럼, 장인들은 무딘 연장으로 좋은 예술품을 만들 수 없습니다."라고 수석 장인이 말했다.
"짐이 그대에게 모든 것을 말해야 하는가? 연장을 다듬을 누군가를 고용해라!"라고 왕이 소리쳤다.
"오, 왕이시여! 저는 연장을 다듬을 목적으로 새로운 견습생을 요구했었습니다. 하지만, 집사는 저의 요청에 답하지 않았습니다."라고 수석 장인이 말했다.
"이런 내부적인 문제로 짐을 괴롭히지 말아라, 장인이여!, 짐은 왕이다. 장인들에게 필요할 때마다 연장을 다듬도록 허락하노라. 하지만, 그들은 초과 작업을 해야만 하느니라"라고 왕이 소리쳤다.
"오, 왕이시여! 그렇게 하겠나이다"라고 수석 장인은 시무룩하게 대답했다.
왕은 다시 관찰했다. 즉시, 그는 다시 격노하게 되었다. "이 접시의 많은 것은 아직 보석으로 세공 되지 않았군. 무엇이 잘못되었느냐?"라고 왕이 물었다.
"오, 왕이시여! 보석의 손상이 증가했었습니다."라고 수석 장인이 대답했다.
"이것의 원인이 무엇이냐? 그대들의 솜씨가 부족한가?"라고 왕이 말했다.
"오, 왕이시여! 외람되오지만, 보석 세공은 세밀한 작업입니다. 주기적인 휴식 없이는 조각가의 눈은 피로해지고 손은 떨립니다. 결과적으로 작업이 제대로 되지 않습니다"라고 수석 장인이 말했다.
"그대는 매우 어리석군, 그대는 짐의 비싼 보석을 망친 작업자를 벌하도록 해라. 명백히 그 작업자는 조심성이 없도다"라고 왕이 말했다.
"명한 대로하겠나이다"라고 수석 장인은 말했다.


다음 검토시, 왕은 그동안의 의심이 말끔히 사라졌다(the king swept into the area filled with suspicion and with a visible air of challenge, 보통 challenge가 도전이라는 뜻이지만 여기서는 suspicion과 비슷한 뜻으로 쓰인 것 같네요. 적당히 말을 예쁘게 만들어야겠는데 힘드네요). 왕이 세공의 품질이 개선되었다는 것을 알았을 때 조금 평온을 되찾았으며, 대부분의 접시가 보석으로 제대로 되었다는 것을 알았을 때, 매우 행복하게 되었다. 그러나, 이 때 왕은 완료된 작업의 수를 세어보았다. 그리고 품질이 향상된 반면에, 많은 작업이 완료되지 않았다는 것을 알았다.


"지금 무엇이 잘못되었는가, 장인이여? 그대는 벌을 받아야겠군?"라고 왕이 말했다.
"오, 왕이시여! 저의 중요한 몇 몇 장인들이 벌로 인하여 아프게되었습니다. 왕이 명하시어 작업을 할 수 없습니다. 게다가, 몇 몇은 왕국을 떠나 자신의 진가를 더욱 발휘하게 될 이웃 왕국으로 갔습니다. 결과적으로, 작업자가 줄어들었고 생산량이 줄어들었습니다"
"짐은 그대의 장인들에게 초과 노동을 지시했다, 이로 인해 향상이 아니 되었는가?"라고 왕이 소리쳤다.
"오, 왕이시여! 사실 그 반대였습니다. 다시, 장인들은 자신이 더욱 인정을 받게될 곳을 찾아서 왕국을 떠났습니다. 남아있는 장인들은 대부분 기술들이 낮습니다. 그들은 정력적이기는 하지만, 왕이 요구한 작업을 하기에는 경험이 부족합니다. 그리고 초과 노동으로 그들이 피로해질수록, 다시 작업을 망치게 되었습니다"라고 수석 장인이 말했다.
"이것은 받아들일 수 없군! 짐은 그대에게 대단히 실망했소, 장인이여. 그대의 처소로 돌아가서 운명의 결정을 기다려라"라고 왕은 말했다. 그리고 수석 장인은 떠났다. 확실히 끝이었다.


왕은 매우 근심했다. 수석 장인은 왕의 기대를 저버렸으므로, 죽어 마땅하다. 그러나 국가적인 만찬은 중요하며 셋팅은 완성되어져야 했다. 그리고, 왕은 이런 일을 허락하는데 언짢았지만, 수석 장인은 왕이 명령했던 대로 열심히 수행했었다. 왕은 자신의 젊은 시절 이후로 조언자였으며 회의시 잘난 체하는(?, sounding board) 마법사에게 조언을 구하기로 결심했다.


사자를 보내기 전에, 큰 폭발과 연기는 마법사의 도착을 알렸다. 마법사는 누군가가 자신을 생각할 때를 항상 안다고 전해졌다.


후에(?, After jumping a bit), 왕은 시간을 낭비하지 않았다. 왕은 만찬에 관련된 사건들을 설명했으며, 이 때 자신의 걱정을 얘기했다. "마법사여! 수석 장인은 짐에게 불복종하는 것처럼 보이므로 죽여만하오. 그런데, 적절히 수석 장인에게 충고할 수 없음 때문에 문제를 나무라는 것을 짐이 참지 말아야하오? 그리고, 수석 장인이 없는 그런 경우에, 장인들이 과연 어떻게 만찬을 준비할 수 있소?"라고 왕이 말했다.


마법사가 손을 들어 허공에서 비둘기를 만들어냈다. 칼을 빼어 비둘기의 창자를 드러내려는 순간에, 자신이 왕궁에 있음을 상기했다. 비둘기를 자신의 넓은 주머니에 넣고, 대신 손가락으로 딱 소리를 내어 약간의 불꽃의 섬광 후에 연기를 자욱하게 했다. 마법사는 단지 마법사만 볼 수 있는 패턴을 식별하는 연기가 흩어지는 것을 보았다. 마침내 왕에게 돌아왔다.


"폐하, 저는 오랜 동안 이 문제에 대해 생각해와서 약간의 식견을 말할 수 있습니다. 숙고해야하는 작업의 관점들에서 이것은 단지 네 개뿐입니다. 이것을 자원(Resource), 범위(Scope), 품질(Quality) 그리고 시간(Time)이라 합니다. 자연 불변의 법칙은 이 관점들과 관련되어 있습니다. 이것들에 대해서 고찰을 하고 어떻게 관련되었는지 보겠습니다"라고 마법사가 말했다.
마법사가 계속해서, "저는 폐하께서 요구하는 작업 즉, 일의 모든 합(the sum of all tasks)을 범위라 하겠습니다"라고 했다.
"마법사여! 흥미로운 이름이지만 짐은 그대의 이상스러운 방법에 익숙하오. 계속하시오"라고 왕이 말했다.
"지금 자원들을 고찰해보겠습니다. 이 자원들은 폐하께서 가지고 계신 장인들의 수입니다. 만약 한 장인이 없어졌다면, 작업 또는 범위가 증가 혹은 감소하겠습니까?"라고 마법사가 물었다.
"그것은 없어져 버린 장인이 유능하느냐 그렇지 않느냐와 그에게 주어진 책임이 무엇인지에 의존하오"라고 왕이 대답했다.
"오, 왕이시여! 폐하께서는 현명하십니다. 그러나 폐하께서 정당히 요구할 때, 폐하의 장인들은 꽤 유능하며 그들은 확실히 책임을 일반적으로 현명하게 분배합니다. 그렇다면, 이 때 자원들의 감소의 결과는 무엇이겠습니까?"라고 마법사가 물었다.
"짐은 여전히 짐이 요구한 것을 요구하오. 그리고 작업은 최상의 품질이여야 하오. 이 때, 작업은 더 많은 시간이 소요되어야 하오"라고 왕이 생각 깊게 대답했다.
마법사는 끄덕였다. "오, 왕이시여! 그렇습니다. 만약 범위와 품질이 변하지 않고 자원이 감소된다면, 이 때 시간은 늘어날 것입니다. 폐하는 현명하십니다"라고 마법사가 말했다.
마법사는 계속해서, "오, 왕이시여! 지금 만약 폐하께서 일정한 자원을 가지고 보다 적은 시간으로 장인들이 동일한 작업을 산출하기를 원하는 경우를 생각해보겠습니다. 이 때 무엇이 발생하겠습니까?"라고 마법사가 물었다.
"그들은 짐을 기쁘게 하기 위해 더 많이 일할 것이오"라고 왕이 대답했다.
"이것을 폐하께서 경험하셨습니까?"라고 마법사는 장난스레 물었다.
"그들이 그렇게 했음에도 아니오. 처음에 일하는 것처럼 보였지만, 전체로는 보다 적게 일이 완료됐소. 그리고 짐이 더욱 많은 결과(output)를 요구했을 때, 작업 자체는 형편없었소. 그들이 더 많이 일하는 것은 단지 형편없는 결과를 나았을 뿐이오. 그리고 어떤 중요한 장인들은 실제로 이 왕국을 떠났소"라고 왕이 시인했다.
"오, 왕이시여! 범위와 품질의 관점에서 이러한 것을 대입할 수 있겠습니까?"라고 마법사가 물었다.
"마법사여! 생각해 보겠소. 음, 짐은 이렇게 생각하오. 만약 자원과 범위가 동일하게 남아 있고 시간이 감소된다면, 이 때 품질은 불가피하게 감소되어야 하오"라고 왕이 대답했다.
"오, 왕이시여!, 맞습니다"라고 마법사가 동의했다.
"그러나, 이것은 받아들일 수 없소!, 짐이 원하는 물건은 최상의 품질이어야 하오!"라고 왕이 울부짖었다.
"폐하, 이 때 완성될 수 있는 공식이 무엇입니까?"라고 마법사가 물었다.
왕은 자신의 왕국을 보면서 생각에 잠겼다. "마법사여, 그대의 질문은 짐의 능력을 시험하는 것 같소. 그러나 생각해 보겠소. 짐은 그대의 미궁을 완전히 볼 수 있소. 기다리시오, 생각났소! 그대는 왕인 짐조차도 이 관점들의 네 가지들 모두를 요구할 수 없음을 깨닭게 하는군. 만약 짐이 자원, 시간과 품질을 가진다면, 이 때 자연(Nature)은 범위를 지배(control)하오. 그런데도, 짐이 자원, 품질 그리고 범위를 가진다면, 이 때 자연은 시간을 지배할 것이오. 이것이 그대의 과제요?"라고 왕이 말했다.
"오, 왕이시여! 폐하께서는 현명하십니다. 폐하께서 말씀하신 대로입니다. 폐하의 장인들은 이런 주어진 제약 속에서 폐하를 잘 시중합니다. 그들은 자신들의 기술을 항상 최상으로 발휘되게 적용할 것입니다. 그러나 그들은 이런 자연의 법칙을 바꿀 수 없습니다"라고 마법사가 대답했다.
"이 때 짐은 아무 것도 할 수 없거나, 완성될 것 혹은 언제 완성될 것인지에 대해 생각할 수 없는가?"라고 왕이 울부짖었다.
"오, 왕이시여! 그렇지 않습니다. 작업 중에, 폐하의 수석 장인은 이런 관점들간의 관계를 잘 이해합니다. 만약 폐하가 그에게 세 가지(역주: 자원, 범위, 품질과 시간 중에서 임의의 세 가지 것)에 관해 바라는 것을 말한다면, 그는 네 번째(역주: 선택된 세 가지 이외의 한가지의 것)의 값을 측정할 수 있습니다. 그리고 어떤 사건이 세부적인 결과를 변경한다할지라도, 그는 자신의 측정에 대한 진행 정도를 폐하가 결과를 바라는 꼭 좋은 때에 알려드릴 수 있습니다"라고 마법사가 말했다.
"마법사여, 잘된 일이오. 그대는 짐을 도와주었소. 그리고 수석 장인의 생명을 구했소"라고 왕이 말했다.


왕은 마법사에게 물러가라고 말하기도 전에, 이미 그가 없어져 버린 것을 알았다(처음에 연기처럼 나타난 것처럼 연기처럼 사라졌을 것 같군요^.^;). 으쓱거리며, 왕은 수석 장인에게 사자를 보냈다.


수석 장인은 최악의 상황을 예상하며 왕궁에 들어갔다. 그러나 그는 마음속으로 자신과 자신의 작업자들은 최선을 다했다고 생각했다. 떨리지만 당당히, 그는 왕의 검을 기다렸다(역주: 즉 죽음을 기다렸다).


"장인이여, 두려워 말라. 짐은 그대가 말했던 것을 지금 이해했소. 짐이 생각했던 만찬을 최고로 준비하기 위한 방법에 대해 그대가 말한 것을 신뢰하오. 그러나, 초대장은 발송되어서 날짜를 연기할 수 없음을 명심하시오. 더욱 많은 장인들이 도움이 되겠소?"라고 왕이 물었다.
수석 장인 잠시 생각했다. 이 때 그는 "몇 몇 장인들을 추가함으로 향상되겠지만, 이것은 시간에 대해 효과가 매우 적을 것입니다. 또는 아마도 새로운 장인들에게 우리들의 방법(methods)을 가르치므로 효과가 느려집니다"라고 수석 장인이 대답했다.
왕은 못마땅하기 시작했다. 이 때 자신이 배웠던 것을 생각했다. "장인이여, 그대가 추천하는 것은 무엇인가? 그대가 최선을 다해 짐을 시중들기를 알고 있소"라고 왕이 말했다.
"오, 왕이시여! 그렇습니다. 여기 저의 해결책이 있습니다. 저희는 자원들을 많이 변경할 수 없으며 시간은 한정되어져 있습니다. 폐하께서는 최상의 품질을 바라십니다. 이것은 저희가 범위를 변경하도록 하게 하는 것입니다"라고 수석 장인이 말했다.
"장인이여, 그대는 짐이 오늘 배웠던 어구를 사용했다. 짐의 마법사와 이야기 한적이 있느냐?"라고 왕이 물었다.
"오, 왕이시여! 실제로, 마법사는 저희가 작업을 어떻게 할 지에 대해 자주 충고를 했습니다. 그는 이것을 작업 프로세스(Work Process, 고대에 이런 어구를 사용했으리라고는 생각을 못했네요^.^;)라 했습니다. 그는 색달랐지만, 그의 생각은 저희의 작업에 강력한 효과를 미쳤습니다"라고 수석 장인이 말했다.
"장인이여, 그는 색다르지, 참으로 색달라. 그러나 계속해서, 범위에 대해서는?"라고 왕이 말했다.
"여기 저희가 할 수 있는 것이 있습니다. 저희는 다음과 같은 방법으로 최상의 품질로 왕께서 바라는 모든 셋팅 장소를 만들어낼 수 있습니다. 저희는 전에 보였던 접시의 디자인을 더욱 간단히 할 수 있습니다. 예를 들어, 케루빔을 제거하는 것입니다. 여전히 최상의 품질일지라도 저희는 간단한 용품을 제공할 수 있습니다. 또는 보다 적은 접시나 용구들을 만들어 낼 수 있습니다. 이 세 가지 가운데, 폐하께서 선택하여 주십시오"라고 수석 장인이 말했다.
왕은 생각했다. 이윽고 결정을 내렸다. "짐의 손님들은 왕궁 동물원의 관람 동안 에피타이저 - 식욕을 돋구는 간단한 음식, 흔히들 에피타이저라고 해서 굳이 번역을 피했다 - 를 먹을 것이다. 짐은 손으로 한 입에 먹을 수 있는 음식을 준비할 것이다. 이런 음식은 쟁반에 담아 손님들에게 돌아다니는 순결한 처녀가 제공해야 한다. 그러므로 보다 적은 접시와 용구가 필요로 할 것이다
"오, 왕이시여! 좋습니다. 그러나 여전히 시간이 촉박합니다. 열심히 일할지라도 작업을 완료하지 못하는 위험이 남아 있습니다"라고 수석 장인이 말하며 떠나려고 했다.
"장인이여, 기다려라. 그대는 아무것도 배우지 않았는가? 위험이 남아 있다면, 아직 일이 끝난 것이 아니다. 더 얘기를 해야 한다"라고 왕이 말했다.
장인은 기다렸다.
왕은 계속해서, "그래, 그대는 국가적 만찬을 최대한 가능하게 할 그대가 제안한 세 가지 모두를 이행할 것이다. 그대는 짐이 이미 명령했던 것 보다 적은 수의 접시와 용구들을 만들 것이다. 그대는 그대가 만드는 이것들의 디자인은 더욱 간단하게 할 것이지만, 여전히 짐이 바라던 최상의 품질을 유지할 것이다. 이렇게 할 수 있는가?"라고 왕이 말했다.
"오, 왕이시여! 물론입니다. 만약 제가 만찬을 위한 접시들에 노력을 많이 들인다면, 그렇지 않은 다른 접시들의 디자인을 더욱 간단히 할 것입니다. 그리고 유사하게 다시 만찬을 위한 접시들의 아름다움을 돋보이게 할 용구들을 간단하게 할 것입니다" 라고 수석 장인이 대답하고 평온을 되찾았다.
"그래, 장인이여! 이것은 충분할 것이다. 그 외에 더 있는가?"라고 왕이 말했다.
"오, 왕이시여! 그러시다면, 두 가지가 있습니다. 첫째, 무엇이든지 잘못되면, 인도(delivery, 적당한 단어가 없어서 보통 인도라고 번역들을 하기에 그대로 썼다)를 보장하기 위한 세부 디자인의 변경할 권리를 간청합니다. 저는 당연히 폐하께 즉시 동의를 얻기 위해 알릴 것입니다"라고 수석 장인이 말했다.
"장인이여! 좋다. 그러나 만약 세부 디자인을 변경하고자 한다면 그대는 짐에게 노력의 감소에 대해 요청을 해야한다(?). 짐은 에피타이저를 변경할 할 수 있는 것과 마찬가지로, 만약 필요하다면 후식을 변경할 수 있다"라고 왕이 말했다.
"오, 왕이시여! 정말이지 현명하십니다. 그렇게 하겠나이다"라고 수석 장인이 말했다.
"장인이여! 그러면 두 번째는 무엇인가?"라고 왕이 말했다.
"오, 왕이시여! 이것은 너무 수월하여 확실치는 않으나(?), 목적들을 간신히 충족하기 보다는 그 이상이 되어야 하는 경우가 있습니다. 이러한 경우라면, 왕께서는 적당히 디자인을 더 세련되게 하는 것을 좋아하십니까? 혹은 손님들에게 약간의 선물을 주길 바랍십니까?"라고 수석 장인이 말했다.
"이것은 확실하지만, 아마도 목표를 간신히 충족하기 보다는 초과할 것입니다. 이러한 경우에, 왕께서는 디자인을 적절히 강화하는 것을 좋아하거나, 손님들을 위한 약간의 선물을 바라십니까?"
왕은 얼굴 표정이 밝아졌다. "지금 그대는 모든 면에서 짐을 지원하는 진정한 수석 장인처럼 느껴지는군. 짐은 지금 과도한 압력으로부터 그대를 벗어나게 하여 그대가 더욱 많은 혹은 적은 일을 하지 않도록 하겠다. 그러나 지금 너무 깊게 생각하지 말아라. 그대가 더욱 많은 일을 할 수 있다는 것을 발견할 때 기다려라. 마법사가 말했던 것처럼, 범위가 증가될 수 있다는 것을 발견할 때 무엇을 할 것인지에 대해 함께 모여서 결정할 것이다. 아마도 휴식(time off, 원래 일시적인 중단이라는 뜻인데 휴식이라는 의미가 더 어울릴 듯 합니다)이 주어질 것이다(Perhaps we will even give your people some time off 혚 no, this is, after all, only the 10th century).(이후에 몇 문장이 더 있는데 도저히 해석이 안되겠더군요. 도대체가 무슨 말인지 .. ^.^; I am ahead of myself. Workers혪 rights are centuries away. In any case see Us, and together we shall decide what to do)라고 왕이 말했다.
"오, 왕이시여! 원하신 대로하겠습니다. 저는 지금 폐하를 섬길 수 있음을 확신합니다"라고 수석 장인은 행복해하며 인사하고 떠났다. 그리고 왕은 자신의 장인들이 자신이 요구한데로 수행할 수 있다고 확신했다.
만찬은 매우 성공 이였으며, 수석 장인은 한 하녀와 가깝게 되었다. 후에 그들은 행복하게 살았다.


다음 이야기에서는 왕은 이렇게 말할 것이다. "마법사여! 그대는 짐에게 자연이 자원, 품질, 범위 그리고 시간과의 관계를 지배한다는 것을 알려주었소. 그러나 짐은 이웃 왕국의 장인들은 짐의 장인들보다 더욱 많은 것을 생산한다는 것을 들었소(역주: 즉, 이웃 왕국의 장인들이 더 속도(velocity)가 빠르다는 말이다). 이것은 무엇이오?"라고 왕이 말했다.
마법사가 대답하기를 "오, 왕이시여! 자연은 실제로 이들의 관계를 조정하여, 폐하의 장인들은 더욱 열심히 일하거나 더 오래 일함으로써 결과를 향상시킬 수 없습니다. 그러나, 그들은 자신의 일하는 방법을 향상시킴으로써 증가시킬 수 있습니다. 이것에 대해 알아보겠습니까?"

본문

우사의 길
번 역 : 서석호
출 처 : Applied Software Architecture

12.1 Creating a Vision
-유능한 architect가 되기 위해서는 비젼이 필요하다. (최종 시스템이 어떤 모습일지, 용도가 무엇인지, 그리고 나머지 회사에서 추진 중인 과제 및 비즈니스적 목표와 연관성이 짙은지, 등등...) architect는 application domain (**소프트웨어 사용 용도?**) 과 시장 정보를 잘 알고 있는 것이 중요하다. 이를 배우든지, 아님 다른 자원을 찾아야 한다. 이는 좋은 소프트웨어 아키텍쳐를 디자인 하는데 중요하기 때문이다. architect로서 당신은 당신 제품이 갖춰야 할 사양과 한계를 알아야 한다. 당신은 이를 이용하여, 시스템의 전체적인 견해를 만들 것 이다. 처음에는, 각각 컴포넌트가 대강 무엇을 할 것인지를 생각할 것이다. 하지만, 이를 완성하기 위해서는 노력 이상의 것이 필요하다. 기초적인 아이디어들을 구상하고, 디자인이 필요로 하는 요소들을 생각하고, 피드백을 받고, 아이디어들을 약간 고치던가, 다시 도전 해야 할 것 이다. 이는 무한한 반복의 과제이다. 종종 새로운 기술을 쓰는 것이, 새로운 시장들을 공략하던가, 시장에 반응하는데 빠르다 (**time-to-market ... 확실하지 않으나 제 생각에는...**). 만일 프로젝트 메니저와 architect가 진정으로 이 과제가 시행될 수 있다고 생각하지 않는다면, 다른 과제를 찾아 나서는 것이 가능성이 없는 과제와 실랑이를 버리는 것 보다 낳기 때문이다. architect의 무한한 상상력을 지속 시키려면, 그들은 지속적으로 자신이 속해 있는 분야의 신기술들을 알고 있어야 한다. 당신은 회사의 기술들은 물론 시장의 신기술들을 알고 있어야 한다. 제품의 사용자들 또한 영감(?)중에 하나이다. 사용자의 견해를 이해하기 위해서는 당신은 에플리케이션, 마케팅, 그리고 커스터머 전문가와 이야기해야 할 것이다. 하지만, 사용자의 사이트를 직접 가보는 것 만큼 좋은 것이 없다. 사용자가 어떻게 제품을 사용하는지, 사용자가 어떠한 문제점들과 맞닥들이고 있는지, 또 어떤 부분의 개선을 원하는지를 직접 알 수 있기 때문이다. 한번 첫 아키텍쳐 디자인이 설립되면 (종종 종이 한쪽에) architect는 이를 감독하고, 정리-진행하고, 결정하고, 이행시기는 일을 해야 한다. 당신은 프로젝트 메니저와 함께 팀을 하이레벨 디쟈인 부터 제품개발까지 하게 될 것 이다.
architect로서 당신은, 아키텍쳐 디자인의 주요 인터페이스 부분을 정리하고 제어 해야 할 것 이다. 왜냐하면, 당신이 주요 컴포넌트들을 알고 있고, 이것들이 어떻게 서로 조합이 되어 시스템을 이루는지 알기 때문이다. system architect가 시스템의 하드웨어를 설정하지만, 당신이 사양을 정하고 소프트웨어가 전체적인 제품에 어떻게 맞는지를 정하고, 나중에 이 정해진 시스템 인터페이스가 될 수 있다는 것을 정한다. 아키텍쳐의 스케치로 당신은 상업적 구성요소들과 현존하는 소프트웨어를 이용해 시스템을 구상할 것이다. 이 비전을 현실화 하는 과정에서 당신은 새로운 기술을 만들어 낸다든지 아님 조직에 변화를 가져올 것이다. 당신은 자주 팀에게 새로운 기술을 배우고 소개하는 개척자가 될 것이다. 잘못된 점이나 고쳐야 할 점을 찾을 때마다 당신은 중간에 이들을 팀과 연락하며 고쳐나가야 할 것이다.

12.2
software architect로서 당신은 프로젝트 메니져의 주요 기술 고문이 될 것이다. 그리고 또한 프로젝트 내의 주요 기술들을 결정 짓게 될 것이다. 프로젝트를 전체적으로 책임지고 있는 프로젝트 메너져와 동등한 관계는 아니지만, architect는 프로젝트 메니져와 가깝게 일을 하게 될 것이다. 하지만, 프로젝트 메니져에게는 믿을 수 있는 능력을 가진 architect가 필요하고, 이에게 기술적인 권한을 줘야만 성공할 수 있다. 어떤 프로젝트에는 메니져와 architect를 한사람이 하는 경우도 있다. 이두 임무를 합함으로써 둘중의 하나에만 치우치는 위험성이 있을 수 있다. 하지만, 작은 프로젝트들에서는 이 두 임무가 효과적으로 합쳐질 수 있다. 혹은, 두사람이 (architect와 technical lead -기술자) architect의 임무를 나눠서 하는 경우도 있다.
큰 프로젝트에서는 인터페이스의 조종이 중요함으로, 한사람이 architect의 임무를 다 수행 할 수 없을지도 모른다. 이런 경우에는 그룹의 architect가 system design review board (**?**)를 이룬다. 이들은 전통적인 권한으로 architecture을 완전한 상태로 보전 한다.
table 12.1은 메니져와 architect의 기타 역할들을 적고 있다. 프로젝트 메니져는 프로젝트의 구성과 자본을 확보하고 그리고 스케쥴을 관리한다. architect는 팀을 architecture 디자인과 이행 부분을 감독한다. architect는 기술적인 측면에서 모든 것이 어떻게 연관되어있는지를 알고 있으며, 이 정보를 이용하여, 프로젝트 메니져에게 어떻게 자원과 인력을 배치해야 하는지를 조언한다.
(**table 생략**)
대부분의 프로젝트에서 개발팀 조직은 소프트웨어 개발 조직과 유사하다. 다시 말해, architect가 프로젝트 메니져에게 팀장의 선택과, 섭-시스템 팀의 크기, 필요로하는 능력, 등등의 조언을 하는 능력이 매우 중요하다. 많은 경우에, 하이-레벨 디자인 팀의 맴버들이 나아가서 서브 시스템과 주요 컴포넨트 개발들을 지도한다. architect의 자문들이 이들의 디자인 능력과 잠재적 인력 경영능력 (**people management skills**) 등을 프로젝트 메니져와 다른 메니져들이 요구 할 가능성이 높다.
프로젝트 메니져는 마케팅과 협상을 하고 제품의 필요 조건을 상세한 조건으로 해석한다. architect는 필요 조건들을 설립하지는 않지만, 이를 비평하고 기술적으로 가능한지를 가늠져야한다. 아키텍쳐 디자인이 진형되어가며, architect는 필요 조건을 다시 정의 할 것을 교섭해야 할 지도 모른다. 왜냐하면, 이들 조건을 충족 시키는 것이 불가능 하던가, 다른 더 중요한 요소들과 맞 바꿔야 할지도 모르기 때문이다.
프로젝트 메니져는 직원 관리를 한다. 예를 들어서 해고, 고용, 능력 평가, 봉급, 과 보너스 등을 관리 한다. architect는 지망자 인터뷰와 직원들의 기술적인 능력을 알고 있어야 한다. 둘 다 팀을 프로젝트가 완성 될 때까지 이끈다.
이 둘의 관계가 잘 적용되고 있을 때는, 프로젝트 메니져는 architect의 기술적 자문을 지원하고, 이를 돕기위해 직원들을 교육하며, computer-aided software engineering tools를 사고, 아님 전문가를 고용하여 이를 가능케 한다.
프로젝트 메니져가 제품의 품질을 보장하기는 하나, architect가 디자인의 품질을 지도한다. architect는 상세 디자인과 코드 속의 의존물들이 architecture design에 따르고 있는지를 살피지만, 더욱더 깊이 내려가서 코드가 상세한 디테일 디자인 까지 따르는지를 확일 할 필요는 없다. 이는, peer review (**동료들이 서로의 일을 검토하는 것**) 상태에서 더 효과적이기 때문이다.
프로젝트 메니져는 프로젝트 팀의 생산력을 제는 책임을 진다. architect는 디자인의 목표를 달성할 수 있도록 하는데 중점을 둔다. 이를 실현하기 위한 한가지 방법으로는 팀내의 가이드 라인(코드와 템플리트)의 확립과 시행이다.

12.3
하이 레벨 디자인 팀은 주로 소프트웨어 architect와 서브시스템의 팀장이나, 기술쪽 전문가, 혹은 분야 전문가들로 이루어진다. 소프트웨어 architect로서 당신은 디자인 팀의 리더이며, 초기의 디자인 결정들을 내려야하는 사람이다. 여러 가지의 서로 충돌하는 요구들의 균형을 정하고 팀이 이들 교환들을 잘 할 수 있도록 지도 해야한다.
architect로서 당신은 어느 정도 분야의 지식을 가지고 있어야 하나, 전문가여야 하지는 않다. 왜냐 하면, architect는 도메인과 소프트웨어 엔지니어링 사이를 잇는 다리이기 때문에 당신은 도메인에 관한 지식으로 디자인 교환을 분석하지만, 디자인을 실행하는 지식 까지는 필요 하지 않다. 당신에게 도메인/분야 경험이 부족하다면, 자주 분야의 전문가에 의존할 수 있다.
당신은 항상 당신에게 필요한 정보나 완전한 전 팀의 일치를 갖고 있지는 못하겠지만, 당신은 시간에 적합한 판단을 내려 데드라인을 맟춰야 한다. 토론을 종료하고 결정을 내려야할 시기가 왔다는 것은 당신이 결정을 하는 것이다.
당신은 빨리 전체적인 결정을 내리고 그에 따른 위험을 찾아 내야 한다. 다른 결정들을 정확하게 시간에 맟춰내리는 것에도 기술이 있다. 이는 결정을 최대한 늘려, 너무 늦지 않게, 내리는 것이다. 장점은 디자인이 융통성이 유지되고, 좀 더 유연하게 변화된 필요 조건이나 다른 요건들에 맟춰 질 수 있다. 하지만, 명심해야 할 점은 나중에 고칠 수 있는 결정을 내리는 것이 결정을 아주 안내려 개발을 지연 시키는 것보다 훨 유용하다는 점이다.
스케줄에 의존하는 요소들을 보고 결정을 내려야하는 시기를 찾도록 하자. 당신의 자원에 앞서 일하고, 당신의 목표의 뒤에서 일함으로서, 당신은 당신의 결정들로 몇가지 제약들을 해결 할 수 있다. 당신은 제품 출시의 마케팅 우선도와 프로젝트 스케줄, 그리고 신기술이 미칠 영향들을 알고 있어야 한다. 기술의 선택은 다른 선택들에도 영향을 미친다는 것을 알아야 한다. 예를 들어서, 소프트웨어 플렛폼의 선택은 상업적 도구 선택이나 팀의 교육 과정에 영향을 미친다. 이 모든 것들이 다 구성 요소 발표 계획에 들어가는데, 이는 시스템 개발 전략을 결정한다.
architect로서 당신은 전체적인 글로발 결정을 책임진다. 당신은 마이크로매니져가 되기에는 시간이나 자원이 턱 없이 부족하다. 당신은 결정의 부분부분을 특정 분야의 전문가에게 맏기고, 디자인과 이행 작업 및 결정을 팀에게 맏긴체 팀을 필요할 때 감독해야 한다.

12.4
software architect는 소프트웨어 개발 팀 (software development team)의 감독 역할을 한다. 일단, 마케팅이 제품의 개념과 제품의 필요 사항들을 정하고 나면, architect는 프로젝트 메니져와 함께 디자인 팀을 구성한다. 소프트웨어 개발은 주로 소수의 인원으로 하이 레밸 디자인 부터 시작을 한다. 이 시점에서 더 많은 인원을 끌어 들이고 싶은 충동을 자제하라. 이 페이즈에서는 작으면 작을 수록 좋다.
직원 보충은 로우레밸 디자인과 이행 (implementation) 작업이 설립되면서 더해진다. 프로젝트의 크기에 따라, architecture 디자인은 특정 팀 리더나 직원에게 배정하기 좋은 시점이다. architect는 프로젝트 메니져와 함께 일하며 각 팀 멤버들에게 작업을 할당한다. 우리는 (저자) 당신이 초기의 개발 시점에서 아키텍쳐 디자인의 컴포넨트들을 프로토타입으로 감정하길 권장한다. 이는 프로젝트의 위험성을 낮추고 새로운 팀 멤버들의 아키텍쳐와 기술 교육에 도움을 주기 때문이다.
어찌 되었든, 소프트웨어의 아키텍쳐 디자인을 완성하는 것이 전부는 아니다. architect로서 당신의 임무는 아키텍쳐의 디자인에서 시작 된다; 끝나는 것이 아니다. 당신은 모두가 이 디자인을 이해하는데 도움을 줘야하고, 실질적으로 이행/임플라멘트 될 수 있다고 설득해야 한다. 이를 행하기 위해서는 당신은 팀 멤버들과 어느 정도의 대화 관계를 설립해야한다. 이로 그들에게 중요한 디자인 요소들을 가르치고 그들의 의견을 들어야 한다. 여기서 매우 중요한 것은 그들을 끌어들이는 것이다. 또한 당신은 주고 받고 관계의 감독과 더 독재적인 역할의 결정자 사이에 균형을 줘야 한다.
팀 멤버들은 상세하게 서브 시스템을 디자인 할 수 있을 정도로 소프트웨어의 아키텍쳐 디자인을 잘 알고 있어야 한다. 이를 시작하는 한가지 방법은 시스템의 나머지에 그들의 서브 시스템과 그 인터페이스의 분해를 디자인 하게 하는 것이다. 그들에게 이행/임플레멘트에 필요 시간을 어림하게 하는 것을 프로젝트 메니져가 스케줄을 정하는데 유용하게 사용될 것이다. 이 연습은 또한 각 팀 멤버들에게 아키텍쳐 디자인과 개발 스케줄에 수요권을 느끼게 해줄 것이다.
좋은 감독관의 기질 중 하나는 언제 방종해야 하는지 아는 것이다. architect로서 당신은 디자인의 전체적인 구조를 공급해야 하지만 동시에 각 팀 멤버들에게 자기가 맡은 부분의 시스템을 디자인하는 책임과 과제를 맡겨야 한다. 무엇이 적당한지는 디자인의 진기함, 관련된 위험성, 그리고 팀의 능력에 따라 매우 주관적인 것이다. 가끔 당신은 팀 멤버들의 사소한 실수를 용납할 수도 있을 것이다. 이것을 통해서 그들이 배우고 또한 이 실수가 프로젝트의 목표를 위험에 빠뜨리지 않는 이상 말이다.
시스템이 발전해감에 따라, 당신은 아키텍쳐의 정직함을 유지하는데 기여해야 한다. 당신의 임무는 제품의 유지 단계에 들어 가며 바뀐다. 이 단계에서는 당신의 개입이 덜 필요 할 것이다. 하지만, 가끔은 원래 디자인에서 동떨어지기 시작해 더 이상 유지가 안되는 아키텍쳐를 다시 조직 하기 위해 많은 노력을 기여해야 하는 수도 있다. 아니면, 현존하는 시스템이 새로운 제품버전으로 업데이트 되어서 새로운 제품 목표를 이에 수용하기 위해 아키텍쳐가 제구조 되는 경우에도 많은 노력이 필요하다. 요즘 대부분의 소프트웨어 제품들이 새로운 버젼의 발표로 서서히 발전되어 간다. 대부분의 경우에 본래 버젼의 아키텍쳐가 장기간의 제품 발전에 따른 예측할 수 없는 기술 진보와 제품 사양들을 수용할 수 없기때문이다.

12.5
소프트웨어 아키택트는 팀 멤버들의 활동을 아키텍쳐의 디자인 요소들에 맟춰 정하게 된다. 소프트웨어 아키텍쳐는 제품 개발을 완성하기 위한 엔지니어링과 관리에서 만들어져야하는 타협을 통일하는 주제이다: 소프트웨어 아키텍쳐는 프로젝트의 많은 국면이 회전하는 중심의 요소를 제공한다. 메니져는 아키텍쳐를 복잡한 과정을 처리가 가능한 과제들로 나누는 개체라고 여길 수 있다. 기술적 마케팅에서는 아키텍쳐로 제품의 사용 기간동안의 새로운 기술을 첨부를 지원하는데 사용할 수도 있다. 소프트웨어 엔지니어들은 성능, 재활용 가능성, 그리고 발전에 대해 걱정을 할 수도 있다. 즉, 소프트웨어 아키텍쳐의 선택, 개발, 그리고 정련은 소프트웨어 개발의 성공 여부의 가장 중요한 부분이다.
아키텍쳐의 수문장으로서, 당신은 아키텍쳐에 영향을 미치는, 영향을 받는 사람들의 활동을 주관한다. 디자인이 완성됨에 따라, 당신은 주요 인터페이스들을 조종하고 설립한다.
아키텍트는 또한 소프트웨어의 개발과정을 따라가며 중요한 아키텍쳐 디자인이 이루어 졌음을 확인해야한다. 디자인 리뷰는 두가지의 일을 수행하는데, 이는 아키텍쳐의 견고함과 품질을 보증하며, 참가자들이 디자인을 이해하는 것을 보증하는 것이다.
키텍트는 프로젝트 메니져와 함께 일하며 디자인의 다른 분야 별로 팀리더의 책임을 설립해야한다. 또한 당신은 팀리더들간의 화합을 주관해야 할 것이다. 그들은 그들의 책임하에의 서브시스템들이 아키텍쳐에 맞을 수 있도록 하기 위해 서로 같이 일해야 한다.
디자인의 일관성과 아키텍쳐가 따라 가진 것은 당신의 책임이다. 만일 따를 수 없는 상황이 발생하게 되면, 이는 이유가 기록 되어야한다.

12.6
분석과 하이 레벨 디자인 외에도, 소프트웨어 아키텍트는 시스템의 임플라멘팅에서 역할을 한다. 소프트웨어 엔지니어 중 소프트웨어 아키텍트가 되고자 하는 사람들은 오늘의 프로그래밍 기술에 맞추고, 신기술과 새로운 기본사양들을 알고 있어요 할 것이다.
소프트웨어 아키텍쳐와 상세한 디자인 사이에 항상 확실한 차이가 없다. 종종 아키텍트는 시스템의 위험도가 높은 부분들을 상세히 들여다보기를 원한다. 왜냐 하면, 디자인 이행이 알려져있지 않기 때문이다. 로우레벨을 상세히 봄으로서 초기의 디자인 개념을 갖는데 도울 수 있다. 아키텍트는 시스템의 수직 박편을 이행 함으로서 이행에 따른 위험을 감축할 수 있다.
명심해야 할 것은 아키텍트가 이행한 것이 팀 멤버들을 교육하는데 사용될 수도 있다는 것이다. 예를 들어, 객체지향적인 개념으로 문제를 접근하면 아키텍트가 초기의 배이스 클래스들을 디자인하고 코드를 임플레멘트 한것들이 다른 사람들이 배우는 예제로 사용 되는 것이다.

12.7
아마도 소프트웨어 아키텍트의 가장 중요한 역할은 소프트웨어 아키텍쳐를 지지하는 것이다. 소프트웨어 아키텍쳐는 당신의 조직의 중요한 재산이며, 아키텍트로서 당신은 이 재산의 가치를 조직이 상기 시켜야 한다.
당신은 현존 하는 소프트웨어의 아키텍쳐도 잘 알고 있어야 한다. 이들을 이용해서 새로운 아키텍쳐를 개발할 수도 있고, 합쳐서 제품군 아키텍쳐 (product-line)로 만들어 질수도 있기 때문이다. 당신은 또한, 경제적으로 수지에 맞는 제품군 아키텍쳐를 만들 기회를 찾아야 할 것이다. 프로덕트 메니져들을 자연스레 한가지 프로젝트에 몰두하지만, 아키텍트로서 당신은 제품의 굴레를 벗어나 다시 쓸 기회들을 봐야 한다. 아키텍트는 현존하는 소프트웨어 아키텍쳐 기술들과 새로이 나타나는 소프트웨어 아키텍쳐 기술들을 지지하고 평가해야 한다. 당신은 연구 결과와 다른 기관의 경험의 도움도 받아 이 기술들을 평가해야 할 것이다. 이들 외부의 결과와 경험들은 당신에게 경영진들이 조직네에 새로운 기술을 지원하기 위해 설득하기 위한 자료를 재공한다.
소프트웨어 아키텍트는 또한 소프트웨어 아키텍쳐를 개발 과정에 수용하기 위해 일을 해야 한다. 소프트웨어 아키텍쳐 디자인 과제와 이에 따른 결과들을 조직네의 기본적인 운영 순서로 만들어야 한다. 이는 더 하이 레벨의 아키텍쳐 디자인 서류를 만드는 것을 의미 할 수 있으며, 좀더 형식적인 기관에서의 아키텍쳐 디자인 검토를 의미 할 수 있다. 아니면, 여러 개의 조직과 인터페이스의 기초가 되는 프로토 타입들을 만드는 것이다. 어떤 경우에라도, 아키텍트는 아키텍쳐 디자인 검토를 지지해야하고 아키텍쳐 서류의 표준을 세워야 한다.
당신의 조직에 소프트웨어 엔지니어링 발전 그룹이나 챔피언이 있다면, 당신은 당신의 역할을 분명히 해야 한다. 프로젝트 중 문제가 많은 프로젝트에는 역할이 확실한 아키텍트나 역할이 확실한 임플러맨팅을 위한 개발 단계가 존재치 않는다.
설사 당신의 프로젝트에 공식적인 소프트웨어 아키텍트가 있다 하더라도, 이는 권한을 가진 정식적인 자리가 아닐 수 있다. 당신은 프로젝트 메니져와 함게 일을 해가며 당신의 의미와 역할을 인증 시킬 필요가 있다. 않그러면, 프로젝트가 압력에 놓였을때, 당신의 역할은 단순히 위기들을 차례 차례 맞는 것 외에는 아키텍쳐로서의 일을 할 수 없기 때문이다. 시야가 넓은 아키텍트 없이는, 종종 아키텍쳐는 단기의 편의 사항이 장기에 해로울 수 있다. 이렇게 되면, 아키텍쳐는 서서히 원래 추구했던 디자인에서 다른 제어가 힘들은 디자인으로 넘아간다. 그리고는 이행되는 시스템의 비젼이 사라지게 된다.

12.8
만일 지금 막 소프트웨어 분야에 뛰어들어 앞으로 소프트웨어 아키텍트가 되는 것이 목표라면, 당신은 우선은 전문적인 소프트웨어 엔지니어가 되는 것에 관점을 두어야 할 것 이다. 무엇 보다도 경험이 유능한 소프트웨어 아키텍트가 되는데 중요하기 때문이다. 이 분야를 걸으면서 당신은 기술적인 면과, 리더쉽, 대화 능력, 그리고 인적 능력을 개발하는 것이 중요하다.
당신은 처음에 개인 공헌자로 소프트웨어 엔지니어에서 원로 소프트웨어 앤지니어가 되어 나중에 팀리더로서의 책임을 맡을수도 있다. 당신은 늘어나는 책임과 더 도전적인 작업들을 받아 들여야 한다. 이상적으로, 당신은 경험이 많은 아키텍트 아래에서 일을 하게 될 것이다.

본문

Refactoring과 Pattern의 관계는 모순적이면서 의미심장합니다.
전통적인 방법론적 접근법은 강화된 디자인에서 S/W를 구현하는 반면 XP 적인 접근법은 구현 먼저, 좋은 디자인 도출의 방법입니다.
GoF가 설명했던 Design for change와 Target for Refactoring의 관계와도 맥을 같이하는데요..  
즉, 모든 발생할 수 있는 상황에 대비하도록 패턴들을 적용해서 절대 뚤리지 않는 방패(디자인)을 만들 것인가? 시행착오를 통해 정제되는 모델을 패턴으로 인도할 것인가? 의 접근법의 차이 입니다.
상철님이 아래 게시판에서 말했던 대로 이런 서로간의 다른 목적과 접근법이 상반된 둘 간의 허를 보완하고 있습니다.

일반적인 패턴의 사용 시점은 분석모델 설계, Architecture 수립단계, 디자인 단계, 구현 단계에 걸쳐 각각 Analysis, Architectural, Design, Idiom 패턴을 적용합니다.
하지만 '얼마만큼 적용할 것인가?'가 관건이 될 겁니다.
패턴을 배웠던 초창기에 오버하게 패턴을 적용해서 예쁜 디자인을 만들고 구현시에 감당치 못한 군더더기 때문에 자승자박했던 경험이 많았습니다.
이런 전차로, 제 사견으로는 예측가능하고 이 중에서 특히 진짜로 발생할 사실들에만 패턴을 적용하는 게 좋을 듯 합니다.
그리고 발견되는 예측 못 했던 문제들을 Simple한 코드로 구축하고 (XP의 접근법 처럼) 어느정도 완성도가 이뤄졌을 때 패턴을 적용하는 것이죠..
하지만 여기에도 역시 개발자의 능력에 따라 '정도'의 차이가 있을 겁니다.
경험 많은 개발자들은 패턴을 적용할 범위가 넓겠고 그렇지 않은 개발자들은 적을 겁니다.
즉, 아무리 Pattern Vocabulary나 Pattern System, Pattern Laguage를 많이 확보하고 있다 하더라도 선견지명이 있거나 신기 있는 개발자가 아니면 보배로 만들기 힘들다는 거죠..
- 소프트웨어의 위계적 고찰에서도 말했던 바와 같이 바로 이 부분이 소프트웨어적 접근법에 회의를 느끼는 부분이지만요..

물론 초창기 패턴의 교육시에 패턴의 장점을 침소봉대했던 것이 사실입니다.
'패턴이면 다 돼!!' 라는 투의 매력을 강조한 반면 적용 시 주의점에 대해서는 설명하지 않았던 탓이겠죠..
"고기를 잡았으면 그물을 버려라"란 왕필의 말 처럼 패턴을 배웠으면 최대한 패턴을 적용하지 않도록 하라고 권하고 싶습니다.

제게 패턴을 소개해줬던 재하님의 "패턴이 지은 죄는 패턴으로 닦아라!!" 란 말이 기억납니다.
이제 RF란 든든한 도구가 생겼으므로 "패턴이 못 본 구멍은 RF로 막아라!!"라고 수정하고 싶은데요.. 패턴과 RF와의 관계가 바로 이런 조화가 될 것 같습니다.
이런 전제라면 패턴을 사용할 단계는 RF를 기준으로 개발전과 후라는 symmetrical한 구도가 되는군요...

하지만 여기에 시행착오와 선경지명이라는 인적인 요소가 자리하는군요..
바로 이 구멍을 설명할 수 있고 밝혀진다면 아마도 이 논의는 종결 될 것 같습니다.


끝으로 위의 Pattern과 Refactoring에 투영된 접근법 (RUP vs. Xp)전쟁은 이제 변증적인 방법을 모색할 단계가 아닌가 생각이 듭니다.


objectworld.org

본문

objectworld.org에 종호님 질문(패턴 랭귀지가 되려면 어떤 걸 만족시켜야 하나요?)에 대한 답.

안녕하세요? 종호님..... UML1 스터디에 안 나간지 오래되서 얼굴 못 뵌지 꽤 됐네요..
잘 지내시죠???

패턴 랭귀지의 조건을 규정하기란 퍽 힘든 일 같습니다. 그렇기 때문에 대부분 개념에 대한 정의는 규정 보다는 직유로 많이 표현하고 또, 정의되었다 해도 단체나 학회마다 의견이 다를 뿐더러 너무 추상적이어서 정확한 이해를 유도하기 힘듭니다. - 아마도 오류, 예외 가능성을 배제하다 보니 추상화 레벨이 엄청 높은 정합적 정의를 내리지 않나 싶습니다.

이런 전차로 저 또한 패턴 랭귀지에 대한 '이미지 설명' 정도 밖에 못 할 것 같은데요...


"The limits of my language are the limits of my world." - Ludwig Wittgenstein or "No Pattern is an Island"


패턴 랭귀지를 묘사 할 때 흔히 'Domain Specific Language'라고 합니다.
특정 도메인에 등장하는 패턴들의 집합으로서 도메인의 지적, 경험적 자산을 정리해놓은 거라 할 수 있습니다.
그렇기 때문에 패턴 랭귀지는 단순히 특정 도메인에 등장하는 패턴들을 서술 하지 않고 패턴들 간의 관계를 정의하고 있습니다. (No Pattern is an Island)
하지만 "No Pattern is an Island"란 단어는 그다지 생경하지 않지요? GoF의 Design Patterns 에서도 등장한 개념입니다.
GoF의 Pattern Vocabulary 개념과 다른 점은 패턴 랭귀지에 와서는 특정 도메인에 등장하는 문제점과 다른 문제점들의 상호관계를 정의합니다.
그리고 그대로 그 문제점을 해결할 수 있는 패턴들과 다른 패턴들간의 관계로 매핑시킵니다.
즉, 하나의 Problem과 패턴의 관계는 1:1..n 의 관계가 되며 이 (1..n 개의) 패턴들이 다른 Problem에 대한 (1..n 개의) 패턴들과 상호관계를 갖게됩니다.
이렇게 유기적으로 구성된 특정 도메인의 패턴 집합체를 패턴랭귀지라고 합니다.

상술했던 비트겐슈타인의 말에서 어림잡을 수 있듯이 이런 각각의 (도메인에 대한) 패턴 랭귀지를 정복한다면 소프트웨어 시스템이라는 거대한 체계에 대한 지평이 넓어지겠죠...


패턴들간의 관계


패턴 랭귀지의 패러다임에 들어서면서 패턴에 대한 자산이 꽤 많아졌습니다. 그러다 보니 전술했던 것 처럼 하나의 Problem에 하나 이상의 Pattern이 등장하게 되고 패턴들간의 관계도 다양하게 구성될 수 있는데요..
패턴 랭귀지의 특징 중 하나가 이 패턴들의 다양한 관계에 있습니다. 그 '관계'들을 설명하자면 대충 다음과 같습니다.

1) 상생할 수 없는 관계 (재하옹에 의하면 경쟁관계) :
    하나의 Problem에 대한 같은 Solution을 갖는 패턴들의 관계입니다. 그렇기 때문에 개발자는 각 패턴의 Force에 따라서 하나의 패턴만 선택하게 되죠..

2) 포함 관계 :
    하나의 패턴이 존재하기 위해서 다른 패턴(들)을 사용하는 경우입니다. Architectural Pattern과 Design Pattern의 관계가 이런 형태를 보이는데요... 이를테면 MVC 패턴은 이벤트 전달을 위해 Observer 패턴을 사용하고 또, 메시지의 detail한 부분과 처리의 추상화를 위해 Command를 사용하죠...

3) 사용 관계 :
    패턴이 처리를 위해 다른 패턴을 사용하는 경우입니다. 2번의 [포함 관계]와 다른 점은 2번의 패턴들의 관계가 Aggregation 관계 라면 3번의 관계는 Association 관계 정도 되며 2번은 '구성'의 (sub 패턴이) 필수 요소인 반면 3번의 경우는 '처리'의 관점에서 다른 패턴을 사용합니다. POSA2의 예로 Reactor가 Connection에 대한 처리를 위해 Acceptor-Connector를 사용하는 경우입니다. - 2,3번의 다른점을 정확히 표현하기 힘들군요.. ^^;

4) 인접 관계 :
    패턴들 간의 Sequencial Cohesion을 갖는 경우입니다. J2EE 패턴의 경우 Business Delegate에서 클라이언에게 비즈니스 서비스 인터페이스를 제공하고 Business Delegate는 실제 서비스 처리를 위해 Session Facade에게 위임하는 경우입니다.

끝으로 Douglas C. Schmidt 박사는 패턴들간의 관계를 위해서 다음 두가지 스텝을 밟는다고 합니다.
1) Identify pattern relationships.
2) Define pattern ordering.

본문

RUP에서나 Xp에서나 아키텍처를 논할 때 메타포어를 이용하라고 권하고 있습니다. 우리는 쉽게 공감대 형성을 위해 즉, 인식이 적은 대상을 설명하기 위해 잘 알고 있는 개념이나 형상을 비유하여 설명합니다. 하지만 메타포어의 오용으로 많은 혼란과, 더불어 비생산적인 소모를 하게 되는데요... 메타포어를 사용한다면 공감대가 형성된 대상을 적용해야 할 겁니다. class를 설명하기 위해 이데아를 메타포어로 사용한다면 이데아를 모르는 청자는 class를 이해하기 위해 더 큰 짐을 지게 되는 경우가 생깁니다. 다음으론, 메타포어를 공격할 때는 메타포어로 적용한 context 안에서 해야할 것입니다. Brooks의 No silver Bullet을 논하면서 소프트웨어 공정과정에서의 많은 난점들과 늑대인간과 다른 점을 공격한다면 피곤해지죠.. ^^ 사실 metaphor는 옳은 표현이 못 되는 것 같습니다. 메타포어는 의미상 직유(simile)이지 은유가 아닙니다. 끝으로 메타포어 사용은 쉽고 개념적 유사도가 높아야 할 것입니다. 잘 못된 메타포어로 대상을 오해하는 경우가 더러 있죠?

본문

패턴의 설명을 일축할때 신상호님이 말했던 '패턴은 우라다'란 명언을 사용합니다. 패턴은 흔히 반복적으로 발생하는 일반적인 문제와 요구영역에서 해결책을 인도하고 있습니다.

이제와서 패턴을 디자인의 관점으로만 보지 않습니다. 물론 상당부분 디자인의 문제를 포함하고 있지만 POSA 1(Pattern Oriented Software Architecture)[1]의 분류처럼 Architecture, Design, Idiom의 단계와 범위에 따라 분류하기도 하고 Process Pattern[2]이나 Analysis Pattern[3]에서 처럼 소프트웨어 공정과정에서 패턴을 적용하기도 합니다.

좀 더 영역을 확대한다면 형태와 행동을 갖는 모든 것이 패턴일 수 있습니다. 그런 의미에서 가라데의 형이나 태권도의 품세, 태극권의 식(式)은 유명한 패턴이라 할 수 있습니다.

무엇보다도 패턴을 간단명료하게 설명하기위해선 패턴의 아버지인 알렉산더의 말을 빼놓을 수가 없습니다.

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”- Christopher Alexander [AIS+77]


하지만 패턴이란 무공을 펼치는 것은 쉽지 않습니다. 그것은 당구에서 맛세이(=찍어치기)를 하기 위해서 300 다마 정도 되어야 하는 것과 같습니다. 아무나 당구공을 찍어칠 수 있지만 찍어칠 때를 구분하는 것과 때를 안다 하더라도 적절히 적용하기란 아무나 할 수 없죠... 그래서 Fowler는 패턴을 '반쯤 익은 빵'으로 비유합니다. 나머지 반은 내가 지지고 볶아야한다는 거져...

여기에 패턴의 위력과 허수가 존재합니다. customizing해야만 쓸 수 있는거져... 왜냐하면 패턴은 일반적인 내용을 말하지만 나의 컨텍스트는 일반적이지 않기 때문이죠.. (참고로 패턴적용시에 도움이 되는 항목은 - GoF 분류법 기준으로 - Applicability, Consequences, Implementation이 있습니다. 어떤 경우 Structure와 Sample Code는 더욱 혼선을 가져오기도 합니다.)

본인도 그러하거니와 패턴을 적용해서 패턴을 욕하는 대부분의 사례가 이 허수에 빠지는 것입니다. 적용할 경우와 적용법을 모르고 Structure로 대들었을 때죠..


기계론적 세계관에 대한 회의...

근래들어 패턴의 이런 모습에 회의를 느꼈습니다. 사실 패턴 뿐만 아니라 Software Engineering에 대한 회의인데요.. '적용자에 따라 결과가 달라진다면 '공학적'이라 할 수 없다. 적어도 공학이라 한다면 A가 해도 B가 해도 똑같은 결과가 나와야하지 않은가?'란 내용입니다. Software Engineering적 접근은 모든 경우의 수를 predictable할 수 있거나 그렇지 않다면 모든 것을 해치울 수 있는 준비에 그 목적이 있다고 할 수 있습니다. 다분히 공학적이고 기계론적이죠..
하지만 대부분 '모든 것'에 대한 범위나 정도 설정은 겪고나서 정의/해석하게 됩니다.
이런 맥락에서 Software Engineering은 Software Engineering Oriented의 성격이 강합니다. 근대에 이르러 뉴튼과 칸트의 출현은 모든 기계론적 세계관을 일단락했습니다. 인간의 모든 성격을 오성으로 표현할 수 있으며 떨어지는 사과 하나도 역학으로 충분한 설명이 가능합니다. 이런 가정과 전제에서 인간의 인생까지도 기계론적으로 설명 가능합니다. 그래서 기계론을 결정론이라고 부르기도 합니다만...

사실 Software Engineering의 패러다임들은 인문학과 다른 학문의 그것을 많이 차용한 듯 합니다. 50년을 조금 넘는 역사의 문제가 크겠지만 적어도 그것을 능가할 수 없는 무엇이 아쉽습니다. 더구나 Software Engineering 노력이 칸트나 뉴튼이 완결한 세계관에 이르지도 못 한다는게 거듭 아쉽습니다.

다시 패턴의 문제로 돌아가서 패턴은 이런 Software Engineering의 성격을 그대로, 정확히 반영하고 있습니다. 근래들어 전술한 생각과 함께 들었던 회의는 패턴이란 현상의 원리를 정의하는건데 본질에 미치지 않나 싶습니다. 다시 말하자면 패턴이란 반복적이고 유사한 현상에 대한 설명일 뿐이지 본질은 아니지 않는가? - 사실 이 논의를 위해선 현상과 본질, 그리고 원리에 대한 심도있는 개념정리가 필요하겠지만 일단은 유보하겠습니다.
아마도 이 본질, 즉 원리안에 원리가 밝혀진다면 구력 30과 500이 같이 맛세이를 쳐도 같은 결과가 오지 않을까?


[1] Pattern-Oriented Software Architecture, Volume 1: A System of Patterns by Frank Buschmann (Author), Regine Meunier (Author), Hans Rohnert (Author), Peter Sommerlad (Author), Michael Stal (Author)

[2] Process Patterns, : http://www.bell-labs.com/user/cope/Patterns/Process/index.html

[3] Analysis Pattern, Reusable Object Models (Object-Oriented Software Engineering Series) -- by Martin Fowler; Hardcover