all2one awakening

• 1:1을 하는가?
• 팀 미팅을 가지는가?
• 상태 보고(예를 들면, 주간 보고)를 하는가?
• 상사에게 아니오라고 말할 수 있는가?
• 외부인에게 회사의 전략을 설명할 수 있는가?
• 사업의 현 상태를 설명할 수 있는가?
• 높은 자리에 있는 사람들이 주기적으로 모두 앞에 나와 그들의 생각을 공유하는가? 당신은 그들의 말을 믿는가?
• 다음으로 무슨 일을 하고 싶은지 알고 있는가? 당신의 상사가 그것을 아는가?
• 전략적인 관점에서 생각할 시간을 가지는가?
• 유언비어가 퍼지는 것을 적극적으로 막고 있는가?

(주목: 각 항목을 리더나 관리자의 관점에서 설명할 것이나, 각 질문과 설명은 일반 팀원에게도 동일하게 적용된다.)

진행 상태 이외의 주제들을 나눌 수 있는 1:1 회의를 지속적으로 갖는가? (+1)

1:1 회의가 무익하다고 말하는 사람은 거의 없다. 그러나 상황이 빠듯해질 때 제일 먼저 연기되는 미팅이 이것이다. 내 견해로는, 상황이 안좋을 때 가능한 한 피해야 할 것이 빠듯한 상황을 만든 장본인 혹은 향후 같은 일이 발생하지 않도록 방안을 짜낼 수 있는 사람과의 1:1 시간을 미루는 것이다.

더욱이, 내가 보고, 분출, 그리고 폭발(The Update, The Vent, and The Disaster)에서 썼듯이, 상태 전달은 1:1의 핵심이 아니다. 보다 실질적인 것에 관해 대화를 나누는 것이 핵심이다. 상태 보고로 시작하거나 대화의 틀을 잡는데 그를 쓸 수는 있지만, 핵심은 아니다. 건강한 1:1은 전략적이어야 하며, 다른 회의에서 쉽게 다룰 수 있는 단기 전술 사항이나 상태 전달의 재탕이 아니어야 한다.

팀 미팅은 1:1 미팅과 같은 요구 사항 — 일관성과 실질적 화제에 대한 집중 — 을 지닌다. 하지만 아직 점수를 더하기엔 이르다.

다음으로, 팀 회의 성과 측정에 중요한 것은 무엇인가 보이는 진전을 이뤘느냐이다. 당신이 무엇을 만드는지 모르고 팀에 무엇이 잘못되었는지 모르지만, 뭔가 잘못되었으면 그를 발견하고 고칠 방법에 대한 논의를 시작하는 최적의 장소가 팀 회의라는 것은 안다.

팀 회의에서 유언비어를 잠재우고 잘 동작하지 않는 부분을 고치고 있다면, 점수를 더하라.

주간 보고 등을 작성하여 이메일로 보내는가? (-1)

그렇다면, 점수를 빼라. 이 점검 목록은 한편으로 회사에서 정보가 어떻게 흘러가는지에 대한 평가이며, 이 항목은 실제 감점 요인으로 작용한다. 왜 상태를 싫어하는가? 나는 상태를 싫어하는 것이 아니다. 상태 보고를 싫어할 뿐이다.

나는 이메일 기반 상태 보고가 관리 무능과 태만의 명백한 징표 중 하나라고 믿는다. 이런 주간 보고 이메일을 작성해야 하는 그럴듯한 구실은 항상 있다. 조직이 커서 정보를 유통시킬 필요가 있어요. 작성에 15분이면 충분합니다.

허튼 소리다. 경직된 이메일 기반 상태 보고는 조직의 통제 욕구와 상상력 부족, 신뢰 부족으로 요약된다.

매일 일터에서 사용하는 협업 도구의 수를 세어보라. 이메일을 빼고 말이다. 소프트웨어 엔지니어라면, 아마도 버전 관리와 버그 추적, 위키, CRM, 프로젝트 관리 소프트웨어 등을 사용 중일 것이다. 이런 모든 도구들이 이미 매주 어떤 전술적 작업들이 이루어졌는지에 관한 충분한 양의 상태 정보를 자동으로 생성하고 있다.

누군가 상태 보고를 요청할 때, 처음 드는 생각은 이것이다. “이미 다양한 도구들에 상태 정보가 쌓여 있는데, 왜 살펴보지 않는거지?”

물론 그런 도구들의 정보에는 많은 잡음이 껴있다. 잡음을 걷어낸 보고서를 작성하면 된다. 많은 협업 도구들이 리포팅 기능을 가지고 있다. 상태 정보는 이미 다 나와 있다. 어떤 관리 지침서에서 진행 상황을 알아내는 작업을 각 작업자에게 맡기라고 추천한단 말인가? 그것은 관리자가 할 일이다.

글쎄, 제가 진정 원하는 것은 한 주 작업을 고수준에서 가늠하는 것인데요. 잘 된 일 세가지, 잘 못된 일 세가지, 그리고 그의 개선책. 자, 이제 말이 좀 통하는듯하다. 매주 전략적 평가를 하는 것은 좋으나, 그를 1:1의 시작부에서 하면 안될 이유가 무엇인가? 그러면 묻고 싶은 사항이 있을 때(있어야 한다), 심도 있는 논의를 할 수있다.

하지만 나중에 리뷰할 수 있는 기록이 남았으면 하는데요. 문제 없다, 대화를 기록하라.

상태 보고는 나를 열받게 하는 주제이다. 이제껏 수백 번 넘게 작성했으며, 매번 작성할 때마다, “왜 쓸데없는 짓을 하고 있다는 느낌을 지울 수 없지?”라고 생각하곤 했다. 상태 보고는 보통 높은 자리에 계신 분이 자신의 조직과 거리감을 느끼고는 모든 이가 주간 보고를 작성하게 하면 나아지리라 믿으면서 시작된다. 나아지지 않는다. 이메일 상태 보고는 그를 작성해야 하는 대부분의 조직원에게 다음 한가지만을 각인시킨다. “내 시간을 소중히 여기지 않는구나.” 이는 곧 다음 주제로 이어진다.

마음 편하게 상사에게 아니오라고 말할 수 있는가? (+1)

다른 말로 설명하면, 상사와의 1:1이 그 주에 있었던 다른 회의들과 무언가 다르게 느껴지는가? 건강한 의사소통 구조는 정보가 팀이나 조직, 회사를 통해 자유롭게 흐를 때에 가능하다. 만약 상사와의 회의를 위해 회의실로 들어갈 때 항상 최선의 태도를 유지한다는 마음가짐으로 속마음을 드러래지 않으려 한다면 문제가 있는 것이다.

물론, 상사란 말은 그가 당신의 실적 평가서를 작성할 것이고 당신의 경력 궤적에 영향을 미칠 수 있음을 뜻한다. 그럼에도 그가 입을 열어 허튼 소리를 한다면, 당신은 회사의 주주로서 손을 들고 “말도 안되는 소리입니다. 왜냐하면...”이라고 말할 계약상의 의무가 있다.

말하기는 쉽지요, 랜즈.

맞다, 말도 안되는 소리라고만 말아달라.

결론은 이렇다. 자기가 항상 옳다고 믿는 리더는 실수하는 것이 나약함의 표시라는 거짓 믿음과 함께 서서히 미쳐간다. 나도 실수를 한다. 거의 규칙적으로 말이다. 나는 다양한 형태로 이 일을 20년간 해왔다. 넘어지거나 남들이 나의 실수를 지적할 때면 여전히 쓰리지만, 나는 바로 내가 망쳤음을 인정하다. 왜냐하면  그래야 무엇을 잘못했는지 빨리 배울 수 있고, 그러한 교훈은 누군가의 “아니오”로부터 출발하기 때문이다.

외부인에게 회사의 전략을 설명할 수 있는가? (+1)

소통 문제에서 벗어나, 이번 질문은 전략과 맥락에 관한 것이다. 바에서 만난 사람이 회사가 무슨 일 하냐고 묻는다면, 쉽고 명확하게 회사의 전략을 설명할 수 있는가?

이는 머릿속에 명확한 회사의 지도를 그리고 있는지를 보여주는 첫번째 질문이다. 이 지도의 가치를 과소평가하기 쉽다. 리더쉽이 있는 편이라면, 아마도 쉽게 지도를 그릴 수 있을 것이다. 일개 팀원이라면, 이런 지도는 다른 누군가의 책임이라고 생각할 수 있는데, 부분적으로만 옳다. 지도를 정의하는 것은 다른 이의 작업일지라도, 그를 이해하여 평가하는 것은 순전히 당신 몫이다.

이어지는 질문들에서 확인할 수 있듯이, 랜즈 테스트는 의사소통에 대한 것만이 아니며, 맥락과 전략의 이해에 관해서도 다룬다. HP나 넷플릭스의 직원들이 지난 몇개월 사이 갈팡질팡한 회사의 전략에 대해 어떻게 느낄 것 같은가? 편안하게 아니면 걱정스럽게? 다음으로 계속하자.

어느 정도 정확하게 회사의 상태를 말할 수 있는가? (아니면 누군가나 어디론가 가서 관련 정보를 알아낼 수 있는가?) (+1)

지나친 과장일지 모르나, 나는 당신이 월가가 하듯이 회사가 성장 중인지 망해가고 있는지 독자적로 평가해야 한다고 생각한다. 기대 수익을 달성하지 못할 것이라는 발표 후 상장 회사의 주가가 어떻게 되는지 살펴본 적 있는가? 종종 회사 운영진이 어떤 방책을 갖고 있던지에 상관 없이 주가가 곤두박질친다. 비이성적이나, 이런 일이 벌어질 때 나는 월가가 그 소식이 망해가는 조짐이라고 판단했다고 본다. 운영진이 사업의 상태를 성공적으로 예측할 수 없다면, 무언가 잘못된 것이다.

이것이 공평하지 않으며 매일 수많은 요소들이 사업의 건강성에 기여함을 알고 있다. 따라서 가능한 한 많은 요소들을 연구하여 파악할 것을 추천하는 바이다. 하지만 이 작업을 마친 후에는, 비즈니스의 상태에 관한 신빙성 있는 견해를 가지거나, 아니면 믿고 의견을 구할만한 일단의 사람들이라도 알아야 한다.

이는 계속 그려나가야 하는 그림이며, 이 작업은 앞 질문에서 점수를 얻었다면 더 쉬울 것이다. 회사가 가려고 하는 방향을 안다면, 회사가 실제 그를 향해 가고 있는지 판단하는 것이 더 쉽다. 이는 자연스럽게 다음 질문으로 이어진다.

정기 회의에서 높은 자리에 있는 사람들이 모두 앞으로 나와 생각을 공유하는가? (+1) 당신은 그들의 말을 신뢰하는가? (+1)

맥락과 관련한 마지막 질문은 책임자와 관련한 것이다. 빠르게 성장하는 팀과 회사에서는 많은 일이 발생한다. 매일 말이다. 팀이 소규모일땐, 정보의 배분이 간단하고 비용도 낮다. 모두가 소리치면 닿을 거리에 있기 때문이다. 규모가 커지면, 특히 변방에서 이 의사소통의 비용이 올라간다. 디렉터나 리드, 관리자의 경우, 하는 일의 특성 상 시류에 가까이 있게 된다. 하지만 정보가 흐르도록 조취를 취하는 것 역시 그들의 의무이며, 이는 CEO에서부터 시작한다.

규칙적으로 CEO가 나서서 대체 무슨 일이 벌어지고 있는지에 관해 그의 생각을 나누는가? 직원이 10명이건 10000명이건 간에, 이는 필수적인 회의로 다음과 같은 소기의 목적을 달성한다.

• 모두에게 CEO와 대면할 기회를 준다.
• 대표가 회사의 비전을 설명할 기회가 된다.
• 바라건대 모두에게 일어나 질문할 수 있는 기회를 준다.

이 회의의 가치가 명쾌하게 느껴지지 않는다면, 나는 아마도 당신이 비즈니스의 현 상태뿐만 아니라 향후 방향까지 이미 알고 있는 운좋은 이들 중 하나일 것이라 생각한다. 멋진 일이다. 그런 이들을 위해 여기 보너스 질문이 있다. CEO 버전의 진실이 당신의 것과 일치하는가 아니면 지상에서 일어나는 일과 무관한 천상의 이야기처럼 들리는가? 전자에 해당하면 1점을 더한다. 후자의 경우, 비즈니스의 상태에 대해 당신의 진실은 어떻게 말하고 있는가? 성장인가 쇠퇴인가?

당신의 경력 계획을 말할 수 있는가? (+1) [보너스: 상사도 알고 있는가? (+1)]

자, 화제를 바꿔서, 바로 이 순간 당신의 다음 행보에 대해 내게 말할 수 있다면 점수를 더하라. 당신은 이미 하고 있는 일이 있을테니, 다음 단계를 말해보라. 거창할 필요없이 간단한 문장이면 된다. 언젠가 나는 팀을 이끌 것이다.

건강한 조직은 비단 정보의 자유로운 흐름에 관한 것만이 아니다. 그 정보를 받고 다시 유통하는 시람들이 그를 가지고 무엇을 하는가에 관한 것이다. 대개 당신은 머릿속 한켠에 분류해둔 뒤 대부분의 정보를 일단 무시할 것이다. 허나 가끔 1:1이나 회의, 복도에서의 대화 등에서 나온 정보 하나가 당신의 다음 행보와 관련하여 전략적으로 바로 유용한 경우가 생긴다.

• 안젤라의 팀은 항상 잘 돌아갔는데, 그녀가 승진했다. 그리고 나는 항상 관리자가 되고 싶었다.
• 얀의 그룹은 내가 배우고 싶어하던 기술에 관해 일하고 있는데, 얀이 방금 충원 공고를 올렸다.
• 프랭크가 짤렸다. 이러면 상당히 흥미로운 권력 공백이 생기는데…

혹자는 굳이 계획을 세우지 않아도 마찬가지의 기회주의적 도약을 할 수 있다고 주장할 것이다. 그러나 내 경험상으로 지도를 짜두는 것이 목적지에 빠르게 도착하는 더 나은 방법이다.

여기도 보너스 질문이 있다. 당신의 상사가 당신이 다음으로 하고 싶어하는 일에 관해 알고 있는가? 그는 회사에 떠다니는 정보를 더 잘 알고 있기 쉬우며, 원하던 원하지 않던 간에, 당신이 목표를 이룰 수 있는 방법을 알아낼 책임을 공유한다.

전략적 사고를 위해 별도의 시간을 가지는가? (+1)

이전 질문에서 2점을 얻었다면, 축하한다, 내 생각에 당신은 대부분보다 훨씬 나은 상태이다. 하지만 관련 질문이 하나 더 있다. 이 목표를 향해 나아가고 있는가? 달력 상의 날짜나 아니면 그냥 머릿속에서라도 현재 목표를 향해 얼마만큼 와 있는지 가리킬 수 있는가?

나는 부산한 걸 좋아한다. 정신없는 바쁨 말이다. 출근해서, 커피 한모금 마셨나 했는데, 어느덧 커피는 차갑게 식어있고 시계는 오후 6시를 가리키는 그런 상황 말이다. 바쁜 건 기분 좋다. 그러나 바쁜 것은 보통 전술적일뿐 전략적이지 못하다. 내가 장기 프로젝트 목록(Trickle List)을 유지하는 이유가 이것이다. 이는 당장보다 더 큰 일을 하라고 매일 상기시켜준다.

자신에게 투자하는 시간이 있고 상사가 그를 문제 삼지 않는다면, 1점을 더하라.

유언비어가 유통을 적극적으로 근절하고 있는가? (+1)

그레이스가 사무실에 들어서면, 당신은 그녀의 얼굴에서 그녀가 무언가 알고 있음을 눈치챈다. 그녀는 사무실 구석으로 가서는 “…소식 들었어?”라면서 이야기를 시작한다. 경제적 및 정치적 음모가 가득한 흥미로운 스토리로, 당신의 필연적 반응은 “에이, 설마”이다.

비밀의 일부가 되는 건 짜릿하다. 조직이 이전까지 감춰왔던 부분을 드러내는 순간, 당신은 이제 게임판의 더 넓은 영역을 볼 수 있음을 깨닫는다. 음, 이게 그가 짤린 이유였군. 한참 궁금했었는데. 그레이스 너무나 친숙한 말로 이야기를 마친다. “너만 알고 있어.” 아이러니한 것은 정확히 15분전 동일한 말을 그녀가 들었다는 점이다.

사람들이 회사에서 일어나는 모든 떠들석한 일들에 대해 서로 이야기 주고 받는 것을 막을 방법은 없다. 실상, 이는 장려되어야 한다. 1:1과 회의만으로는 한계가 있기 때문이다. 바꿔야 할 것은 회사를 배회하는 정보의 질이다.

정보가 부족하면, 사람들은 터무니 없는 것을 꾸며대기 시작한다. 설상가상으로 위협을 느끼기라도 한다면 최악의 상황을 과대포장한 시나리오를 꾸며낸다. 완전히 말도 안되는 소문들은 이로부터 기원한다. 알겠는가, 크리스토프는 일자리를 잃을까 두려워 누군가 자기를 엿듣고 있다는 말도 안되는 음모 이론을 꾸며낸 것이다.

적극적 개입 없이는, 유언비어가 개인의 힘을 능가하기 시작한다. 유언비어를 완전히 근절하지는 못할지라도, 고개를 들이미는 것이 보이면 그를 전파하려는 사람에게 간단히 물어볼 수는 있을 것이다. “이 헛소리를 정말 믿는거야? 이 쓰레기를 퍼뜨린 사람을 믿어?” 소문은 스스로를 정당화하지 못한다. 그러니 이처럼 유언비어 근절에 중점을 두고 있다면, 점수를 더하라.

크기와 방향

나는 지금 어디에 있는가? 그리고 대체 무슨 일이 벌어지고 있는가? 랜즈 테스트가 답하고자 하는 이 두 질문의 접점에 더 높은 차원의 목표가 있다. 이 질문에 대한 답을 구하는 과정에서 회사의 의사소통 건강도를 점검할 수 있지만, 더 높은 차원의 목표는 자기중심적인 것이다. 설명하면 이렇다.

나는 두 질문을 벡터라고 생각한다. 두 점 사이를 화살표로 연결하면 간단히 벡터를 그릴 수 있지만, 벡터는 훨씬 더 흥미로운 특징을 지닌다. 방향과 크기를 가지는 기하 개체인 것이다. 정보가 어떻게 흐르는지와 상사와 의사소통하는 법을 파악하는 것이나 당신의 경력 전략과 회사의 전략을 설명할 수 있는 것을 모두 머릿속에 벡터로 그릴 수 있다. 첫번째 점은 바로 이 순간에 관한 것이고 나머지 점은 도달코자하 는 상태이다. 이 둘 간의 거리와 방향은 어떻게 목표에 도달할 수 있는지를 보여준다. 복잡한 문제를 간단한 그림으로 나타내기에 나는 벡터를 좋아한다. 위의 질문들을 답하는 과정에서 당신의 머릿속에도 그러한 그림이 그려지기 시작했기를 바란다.

조엘 테스트와 마찬가지로, 랜즈 테스트의 점수는 절대적인 것이 아니며, 적절한 방향을 가리킬 뿐이다. 12점을 얻었다면, 당신은 회사와 회사 내 자신의 위치에 대해 명확한 그림를 가지고 있는 소수 중 하나이리라. 8에서 10점 사이라면, 소통이나 전략, 경력 개발 중 어딘가에 부족함이 있을 것이다. 어떤 질문에서 점수를 놓쳤는지 살표보라. 8점 미만이라면, 문제가 많다.

각자가 이 질문들에 답하면서 깨닫게 되는 자신이 처한 상황은 매우 다양할 것이다. 따라서 특정 해법을 처방하는 것은 어렵다. 회사는 잘 나가고 있어도, 당신은 불행하고 다음에 뭘 하고 싶은지 모를 수 있다. 일을 사랑하지만, 회사가 성장하고 있는지 어떤지에 대해선 전혀 감이 없을 수도 있다. 당신의 행로는 당신이 무엇을 중하게 여기는지에 달려있으며, 랜즈 테스트는 그를 위한 좋은 출발선이 될 것이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

퍼포스는 상용 버전 관리 시스템으로 많은 회사들이 쓰고 있습니다. 제가 다니고 있는 회사에서도 이 놈을 쓰고 있는데, 제가 쓰면서 놀란 것 중 하나는, 어찌보면 기본 기능 중 하나인 커밋한 변경사항(changelist)들은 커밋로그(퍼포스 용어로는 description)로 검색하는 기능이 GUI client에서 지원이 안된다는 점이었습니다. 물론 이것이 불가능한 것은 아닙니다. 여기 보면 여러 해법들이 나와있지요. 어쨌든 상당히 자주 쓰이는 기능이고 다른 오픈소스 도구들고 잘 지원하고 있는 이런 기능이 간편한 UI로 제공이 안된다는 것은 실망이 아닐 수 없습니다.

그래서 위 스택오버플로 답변 중 하나에 힌트를 얻어 AutoIt 스크립트로 간단한 유틸을 만들어 보았습니다. 이름은 p4search입니다. 프로젝트 위키에도 나와있지만 여기 사용 방법 다시 정리해놨습니다.

• 먼저, p4sql을 이용하기 때문에 P4Report를 퍼포스 사이트에서 다운/설치하셔야 합니다.
• 코드에 p4sql 경로가 "C:\Program Files (x86)\Perforce\P4Report\p4sql.exe"로 하드코딩 되어 있습니다; 필요하면 바꾸세요.
• 소스 .au3 파일에서 실행 파일을 빌드하려면 AutoIt 관련 도구가 필요합니다. 여기서 받으세요. (이조차 귀찮은 분들은 여기 미리 빌드된 놈들을 받아주세요.)
  p4search-32bit.exe
  p4search-64bit.exe
• 빌드된 명령행 도구는 퍼포스 사용자아뒤와 파일스펙, 찾고자 하는 로그 내용의 세 인자를 받습니다. 셋 미만의 인자를 줄 경우, 대화 상자가 나와 각 정보를 묻습니다.

• 더 편리하게, 다음과 같이 이 유틸리티를 퍼포스 클라에 사용자 도구로 통합할 수 있습니다.

저장소 내 아무 폴더 우클릭 -> 등록된 p4search 항목 클릭

나오는 대화상자에 찾고자 하는 글 입력

몇몇 분들에게나마 도움이 되었기를 ^^;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근 이놈에 관심이 꽂혔습니다. 그간 사진을 잘 찍고 싶어서 책도 몇권 사다보고 했습니다만. 제 주변머리에 꽃이나 건물, 풍경을 찍는 것이 전부였죠.

Maturity... by 85mm.ch

그러다가 "Going Candid..."라는 이북을 알게 되었습니다. 길거리의 사람들을 상당히 친밀한 거리에서 찍은 사진들이 묘하게 마음을 움직이더군요. 그래서 그 책에 추천한대로 사진을 찍기 시작했습니다. 먼저 기본 렌즈 하나로 찬밥이 되어가고 있던 제 Lumix GF1에 책에서 추천한 20mm 팬케이크 렌즈를 달아주었습니다. 그리고 인터넷을 뒤져가며 스트리트 포토크래피 팁과 작품들을 살펴보기 시작했습니다.
역시나 배짱이 있지 않으면 쉽지 않더군요; 괜히 찍을까 말까 주섬주섬하다 보면 더 어색해보이기 일수... 과감하게 찍고 아무 일 없었던 듯 사라지는게 최선인듯합니다. 이 흥미가 언제까지 갈는지 모르겠지만... 여하튼 제가 찍은 거리 사진들을 위해 플리커 계정도 하나 만들었습니다;

P1050132_2 by 20jj

다음은 관련 웹자료들입니다.

• http://en.wikipedia.org/wiki/Street_photography 위키피디아 글
  
• eric kim street photography 에릭 김이라는 거리 사진가의 사이트. 재미교포 2세인듯한데, 유용한 팁들이 많습니다.
  
• http://www.imagephoto.org/ 여러 멋진 거리 사진들을 구경할 수 있는 갤러리 사이트
• http://500px.com/ 스트리트 포토그래피에 국한된 사이트는 아니지만 좋은 사진들 많더군요.
  

여러분도 한번 스트리트 포토그래피의 재미에 빠져보시죠? ^^

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

150분까지 초대할 수 있는 링크입니다.
https://plus.google.com/_/notifications/ngemlink?path=%2F%3Fgpinv%3DqEEw-1dSIfA%3AmAC4B-SUBOA
댓글 대신 이 링크 이용해주세요.

원하시는 분은 성함/이메일 주소와 함께 댓글 남겨주세요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

현재 직장에서 툴 프로그래머로 일하고 있습니다. 소스 코드 규모가 커지고 작업하는 사람들이 많다보니, 한쪽에서 작업한 변경으로 다른 모듈 기능에 의도치 않은 장애가 발생하는 일이 잦았습니다. 특히 엔진 쪽 변경으로 에디터 관련 기능에 장애가 생기는 일이 자주 생겼습니다. 이 문제를 해소하고자 에디터 테스트를 일부라도 자동화할 수 있는 방법을 찾게 되었습니다.
(이하에서는 GUI 관점에서의 black-box testing에 대해서만 다룹니다.)

고려했던 대안들
기존에 익숙했든 AuotIt부터 시작해서 다음과 같은 도구들을 고려해봤습니다.
AutoIt

• 윈도 플랫폼에서 돌아가는 Basic과 유사한 스크립트 언어
  
• 컨트롤 아이디, 클래스, 텍스트 등으로 특정 UI 요소 식별
• 일반 용도의 자동화 도구로도 매우 유용
  

TestComplete

• 상용 테스트 자동화 도구
  
• 일반적으로 위의 AutoIt 유사한 UI 요소 식별법 사용
• 편리한 IDE 제공
• 여러 스크립트 언어 지원
  

SIKULI

• Jython 기반으로 멀티플랫폼
• 컴퓨터 비전 기반 UI 요소 인식
• 이미지 비교 결과(퍼센티지 문턱값 지정)에 따라 매치 여부 결정
  
• 기본적인 IDE 제공
• 개발 초기 단계

신선한 개념과 이미지 인식 기반이라 화면 상 임의의 요소에 반응할 수 있다는 장점에 끌려 시쿠리로 방향을 잡았습니다. 시쿠리가 어떻게 기능하지는 아래 동영상이나 튜토리얼 페이지를 보시면 금방 감잡으실 수 있습니다.

이하에서는 저의 시쿠리 실험이 어떻게 진행되었는지 이야기합니다.

진행 상황
일단 QA 팀에서 하고 있는 에디터 수동 테스트의 상당수를 자동화 하는 것이 첫 목표였습니다. 현재까지 대략 기존 수작업 테스트의 70% 정도는 자동화 했습니다. 등록된 테스트가 모두 끝나면 html 형식의 리포트를 만들게 했습니다. 각 테스트 항목의 성공 여부를 보여주고, 실패한 경우 어떤 이미지 매치가 문제였는지 표시하였습니다.
[예제 테스트 항목들]

• 에디터 실행/종료
  
• 각종 서브에디터 창 열기
• 새 레벨 생성 및 저장
• 기존 레벨 불러오기
• 레벨 익스포트
  
• 뷰모드 전환
  
• 각 서브에디터별 기능 테스트
  

하지만 작업 과정이 생각했던 것만큼 수월치는 않았습니다. 가장 큰 문제는 역시 컴퓨터 비전 기반이라는 점에 있었습니다. 화면 상 이미지에 의존한다는 것이 양날의 검이었던 것이죠.

느낀 점

• 유지보수가 힘들다: UI가 변할 때마다(아이콘, 컨트롤 텍스트, 리사이징) 테스트에 사용되는 이미지도 적절히 갱신해주어야 합니다. 상당히 번거롭습니다.
  
• UI 요소를 식별하기 위해 적절한 비교 이미지 영역을 선택하는 것이 쉽지 않다: 너무 작은 부분을 고르면 매치 영역이 여럿이 되어버리고(정밀도가 떨어지고), 그렇다고 확실하게 크게 잡으면 UI 리사이즈같은 작은 변화에 너무 민감하게 되어서 유지보수가 번거로워지는 일이 다반사였습니다.
• 테스트 성공 여부 식별의 문제: 테스트 성공 여부도 특정 UI 요소 혹은 특정 텍스트가 보이는지 여부로 결정하게 됩니다. 이 역시 노이즈에 너무 약합니다. 이론적으로는 렌더링 결과 비교도 가능합니다만, 역시 개발 중에는 렌더링 변경이 잦은 관계로 안정적인 테스트가 힘들었습니다. 가령, 백버퍼 클리어 색상이 바뀌었다든지 하면 역시 잘못된 실패 보고가 뜨고 그 때마다 테스트 이미지들을 갱신해주어야 했습니다. 결국에는, 컴퓨터에 의존하지 않고, 뷰포트 스샷을 찍어 최종적으로 테스터가 성공 여부를 판별케 하는 반자동(?) 방식을 일부 도입해야 했습니다.
• 아직 개발 초기라 다듬어지지 못한 부분이나 버그가 많다: 특정 함수 관련 메모리 릭과 같은 버그도 있었고, 키보드 레이아웃이 영어가 아닌 경우 키입력 함수(type())가 오작동하는 버그도 있었습니다(이 경우, 클립보드 함수인 paste()를 이용하는 방법으로 문제를 우회할 수 있었습니다). 매치에 사용되는 이미지 관리에도 리네이밍 같은 필수적이 기능이 IDE에 빠져있었고(최근 버전에서 해결), 테스트 세트가 커질 경우 중요한 모듈화 및 그 관리에도 현재로선 명쾌한 해답이 없는 상황입니다. 다행히, 버그에 대한 개발자의 응답 및 임시방편 제시는 생각보다 빨랐습니다. 질답 게시판도 도움이 되었고요.
  
• 디버깅의 어려움: 전문적인 디버깅 환경이 지원되지 않다보니, 긴 테스트 함수에서 특정 매치가 실패할 경우, 문제 지점을 파악하고 수정하는 과정이 더딥니다.
• 수행 성능도 이미지 비교 기반인지라 아주 빠르지는 않습니다만, 크게 문제될 정도는 아니었습니다. 개발 시에 IDE의 특정 동작이 매우 느리게 동작하는 경우가 있어 답답하긴 했습니다.
  

결론
쓰다보니 아주 몹쓸 물건처럼 묘사된 것 같습니다만...; 꼭 그렇지는 않습니다. 사실 다른 대안들에서 사용하는  컨트롤 아이디나 클래스 기반 UI 식별도 빈도는 적을지 몰라도 유사한 유지보수 문제를 안고 있습니다. 그리고 분명 그런 대안들에서는 아예 불가능한 것들이 시쿠리로는 쉽게 되는 부분도 많았습니다.

• 아직은 개발 초기로 거친 면이 많은게 사실입니다. 하지만, 개발자가 계속 의지를 가지고 개선해나가면 전망은 밝다고 봅니다.
• 내부 코드의 도움없이 순수히 외부 UI 식별만으로 안정적인 UI 테스트 자동화를 이루기는 거의 불가능합니다. 내부 스크립팅 기능을 외부에서 접근해서 자동화할 수 있다면, 훨씬 견고하고 유지보수가 용이한 테스트 세트를 구축할 수 있습니다.
  
• 렌더링 회귀 검사에 유용해보입니다.
• 개인 작업의 자동화 용도로도 강추입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

http://www.amazon.com/Game-Development-Tools-Marwan-Ansari/dp/1568814321/ref=sr_1_1?ie=UTF8&qid=1307115366&sr=8-1

얼마 전 출간 된 위 책에 제가 한 챕터를 기고했습니다. 아직 저도 책을 받아보지 못했는데...(지금 배송 중) 많은 게임 개발자분들의 적극적인 성원(?) 부탁드립니다. 어쨌든 처음 한 챕터나마 영문 집필에 참여해보았는데, 좋은 경험이었습니다. 여타 Gems 시리즈처럼 이 책도 후속권이 계속 나올 계획이고, 벌써 2권 집필자를 모집하고 있으니, 관심 있으신 분은 다음 사이트 참고하시면 될듯.
http://gamedevelopmenttools.com/

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

얼마 전, Clojure & Python, Side by Side 글을 보고 나도 수도쿠(참고1) 살버를 해스켈로 포팅해보자 마음 먹었습니다. 먼저 원 고안자인 Peter Norvig의 글(참고2)을 읽고 찬찬히 읽고 알고리즘을 이해했습니다. 알고리즘을 특별히 함수형 언어에 적절하게 바꾸거나 하지 않고 그대로 포팅할 작정이었으므로, 기껏해야 네다섯 시간 투자하면 되겠거니 생각했습니다... 실제로는 투자한 시간을 합쳐보니 총 24시간은 넘을듯 하더군요;

• 일단, 여기 최종 해스켈 코드
  

코드보기

• 결과

원 파이썬 코드는 214행이었습니다. 제 해스켈 코드는 276행이군요. 원 노빅씨의 해법이 상당히 간결하다고 봤을 때, 나쁘지 않다고 봅니다.

성능은 다음처럼 나왔습니다. 보시다시피, 해스켈 버전이 약간 느리군요. 그래도 첫 시도로는 준수한 결과라 봅니다;

• 배운 것
• 수도쿠(참고1) 퍼즐 푸는 알고리즘, 노빅씨가 잘 설명해놓으셨습니다(참고2).
• 노빅씨의 파이썬 해법(참고2), 아름답습니다. (물론, 저는 파이썬 전문가 아닙니다;)
• 두 언어가 거의 동일하게 list comprehension(참고3)을 지원해서 편했습니다.
• C++에서와 같은 의미의 변수가 없다는 사실이 생각만큼 큰 차이로 느껴지지 않더군요.
• 후글(http://haskell.org/hoogle/)과 구글이 없었다면 24시간 정도만에 어림도 없었습니다.
• 기존 C 스타일의 언어에서 너무 익숙한 반복문과 반복문 내에서의 이른 탈출이 아예 없다는 것이 포팅에서의 가장 큰 걸림돌이었습니다.
• 함수형 언어에서는 반복이 아닌 재귀로 생각해야 합니다.
• 혹은 한단계 더 나아가 fold와 monad(참고5)로 생각해야 합니다.
• 해스켈에는 fold가 참 많습니다. foldl, foldr, foldl' 그리고 foldr'. 어떤 놈을 써야 할지 많이 헷갈리더군요(참고4).
• 이해하기 까다롭기로 소문난 모나드(참고5)가 자연스럽게 필요하게 되더군요. 이 놈 없으면 과도하게 중첩된 case 문을 사용하게 됩니다.
• 해스켈이 type inference를 지원하여 필수 사항은 아님에도, 형 선언을 꼬박꼬박 해주는게 이해하는데도 그렇고 디버깅 시에도 도움이 많이 되더군요.
• 책에서 읽은대로, 정말 해스켈로 짤 때에는, 컴파일이 되면 보통 바로 그대로 문제없이 동작하더군요. 물론, 컴파일이 되게 하기가 저한테는 쉽지 않았습니다만;
• IO 모나드에서 do 용법은 해스켈에서 일반 순수 함수를 짤 때와는 정말 다른 느낌이더군요. 흡사 다른 언어인 것처럼...;
• 해스켈의 특징인 laziness가 또 머리를 더 복잡하게 합니다. (제 코드에서 볼 수 있는 것처럼, 특정 상황에서는 결과를 얻기 위해 strict 계산을 강제해야 했습니다.)

• 결론
• 해스켈은 imperative programming language와는 완전 다른 세상이다...
• 해스켈 책 하나(제 경우는 "Real World Haskell"(참고9)) 읽은 것으로는, 해스켈로 적절히 코딩하기 힘들다. (파이썬 배울 때랑은 다르던군요.)
• 제 코드 분명 최선과는 거리가 멀겁니다. 노빅씨의 알고리즘을 그래도 포팅한다는 제약 조건 하에서도 분명 더 우아한 해법이 존재할겁니다. 그 제약 조건이 없으면, 물론 훨씬 다양한 해법이 존재하겠죠(참고10).
• 시간이 참 많이 걸렸지만, 그래도 유익한 코딩 연습이었다고 생각합니다. ^^

• 참고자료

1. Sudoku - Wikipedia: https://secure.wikimedia.org/wikipedia/en/wiki/Sudoku
2. Solving Every Sudoku Puzzle: http://norvig.com/sudoku.html
3. List comprehension - Wikipedia: https://secure.wikimedia.org/wikipedia/en/wiki/List_comprehension
4. Implications of foldr vs. foldl (or foldl'): http://stackoverflow.com/questions/384797/implications-of-foldr-vs-foldl-or-foldl
5. Monads for the Curious Programmer: http://bartoszmilewski.wordpress.com/2011/01/09/monads-for-the-curious-programmer-part-1/ http://bartoszmilewski.wordpress.com/2011/03/14/monads-for-the-curious-programmer-part-2/ http://bartoszmilewski.wordpress.com/2011/03/17/monads-for-the-curious-programmer-part-3/
6. Functional Programming For Beginners: http://ontwik.com/scala/functional-programming-for-beginners/
7. A Taste Of Haskell: http://ontwik.com/haskell/simon-peyton-jones-a-taste-of-haskell/
8. Learn You a Haskell for Great Good!: http://learnyouahaskell.com/
9. Real World Haskell: http://book.realworldhaskell.org/
10. Sudoku - HaskellWiki: http://www.haskell.org/haskellwiki/Sudoku
11. Haskell Cheat Sheet: http://blog.codeslower.com/static/CheatSheet.pdf

본 글의 영문 버전을 #AltDevBlogADay에 "Sudoku Solver in Haskell"로 게시하였습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Linked list가 있다고 합시다. 이 연결 목록에 사이클이 있으면 무한루프를 돌게 되므로, 반복문을 돌기 전에 사이클이 있는지 검사하고 싶습니다. 어떻게 하면 될까요?

루프를 돌면서 한번 나온 노드들은 그 신분(C++의 경우 노드의 주소값이 편리하겠죠)을 기록해두었다가, 다 돌기 전 같은 놈이 또 나오면 사이클이 있다고 판단할 수 있겠죠. 한번 나온 놈들을 기록하는 자료구조로는 해쉬테이블이나 이진트리를 쓰면 될겁니다.

그러나 목록에 있는 아이템의 개수에 상관없이 단 두 개의 포인터만으로 사이클을 검출해내라 한다면 어떨까요? 다시 말해, 추가적인 저장소 오버헤드(위의 해쉬테이블이나 이진트리 같은)를 없게하고 알아내라는 말입니다.

이미 알고 계셨던 분을 제외하고는 방법을 짜내기가 쉽지 않을 겁니다.

첫번째 힌트 보기

두번째 힌트 보기

그 차이는... 직선 경로에서는 속도가 다른 토끼와 거북이가 출발선 이외에서는 서로 만날 일이 다시 없지만, 원형 경로를 계속 달리는 경우에는 주기적으로 다시 만나게 된다는 것입니다. 이에 착안하여 나온 것이 Floyd의 알고리즘입니다. 하나씩 아이템을 살피는 거북이 iterator(혹은 포인터)와 하나씩 걸러서 아이템을 살피는 토끼 iterator를 사용합니다. 이를 개선한(이해하기는 좀 더 어렵지만) Brent의 알고리즘도 있군요. (해당 위키피디아 페이지에 알고리즘의 파이썬 코드와 자세한 설명이 나와 있으니 꼭 한번 읽어보세요.)

저장소 오버헤드에 대한 제약이 없다면, 굳이 이런 트릭을 써야 할 필요는 없습니다만, 사이클에 대한 토끼와 거북이의 통찰은 일반적인 패턴으로 익혀둘만 하다고 생각합니다. ^^




* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

기운낼 필요가 있을 때마다 보곤 합니다. 여러분도 보시고 기운내시길! ^^








  * 이 포스트는 blogkorea [블코채널 : 정말로 아무 이야기나 올리는 채널] 에 링크 되어있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

근 1년 가까이 동면 상태였네요. ㅠㅠ

행여나 열심히 구독 중이셨던 분이 계셨다면 정말 죄송;

그간 여러 일이 있었습니다. 가족과의 파리 여행부터, 게임 개발 책에 한 장을 집필할 기회도 얻었고, 큰 기회도 한번 날리고, 시그래프 아시아도 참관하고, 라식 수술도 받고... 등등;

시간 내기가 여전히 쉽지 않지만, 조금씩이라도 풀어보겠습니다. ^^


블로그 회생 기념이로 몇가지 대단치 않은 초대장들 배포합니다.

• Project Phoenix (7장)
  
  
  
• AOL의 gmail 킬러 프로젝트라는데... 성공할지는; 그래도 games.com, love.com, wow.com 도메인의 이메일을 가지고 싶은 분들한테는 매력이 있을지도.
  
• Pinterest (무제한인듯; 어쩌면 이미 오픈 상태인지도)
  
• FFFFOUND!와 유사한 컨셉의 사이트인데, pinboard 형식으로 보여줍니다. 조금 써봤는데, 저한테는 나름 쓸만하네요.
• Passpad (이건 초대장도 없는데. 그냥 추천하고 싶어서;)
  
• 암호 관리 사이트인데, 처음엔 약간 사용이 번거롭지만, 나름 안전한듯 싶어서 추천합니다. 초대장을 따로 안줘서 직접 초대 신청하셔야 합니다.
  
• ifttt (2장)
  
• 특정 트윗이 있으면 페이스북에 내용을 올린다던가, 특정 피드가 발견되면, sms를 날리다던가 등의 작업들을 간단히 생성/관리할 수 있게 해주는 사이트. 트위터, 페이스북, sms 이외에도 다양한 서비스들을 지원하고 있습니다. 전 아직 활용처를 못찾았지만, 유용해 보입니다.

위 서비스에 관심있으신 분, 댓글 남겨주시면 초대장 한도 내에서 초대해드리겠습니다. ^^


* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.