Extremely Agile

오늘 뉴스를 보다보니 후쿠시마 원전 건설 과정에 참여했던 분의 글이 화제가 되고 있더군요. http://www.viewsnnews.com/article/view.jsp?seq=73255 여기서 원문을 보실 수 있습니다. 글을 읽다보니 참으로 많은 생각이 떠올랐습니다. 그 분의 말이 사실이라고 가정합시다. 우리는 뭔가를 만들면서 비슷한 실수를 저지르지 않고 있다고 할 수 있을까요?

왜, 이러한 일이 일어난 것일까요. 그 근본적인 원인은 오로지 도면상의 설계에만 중점을 두고, 현장에서의 시공, 관리를 소홀히 했기 때문입니다. 비단 그것이 직접적인 원인이 아닐지라도, 이러한 사고는 발생할 것입니다.

우리도 마찬가지 실수를 종종 저지르고 있는 건 아닐까요? 설계를 너무 중요하게 생각한 나머지, 개발은 '돌아가게만 하면 된다'고 생각하는 오류를 저지르고 있는 건 아닐까요?

십여 년 전 까지는, 현장작업에 보신(봉심)이라 부르던 전문 기술자, 현장의 젊은 감독자 이상의 경험을 쌓은 전문가가 반장으로서 반드시 있었습니다. 전문가는 자신의 일에 자부심을 갖고 있어, 사고나 하자가 발생하는 것을 수치스럽게 여기며, 사고의 두려움도 잘 알고 있었습니다. 그러던 것이 10년 쯤 전부터, 현장에 전문가가 사라졌습니다. 비전문가들을 경험 불문이라는 형태로 모집하고 있습니다. 비전문가인 사람들은 사고의 무서움을 모르며, 어떤 것이 부실 공사인지, 어떤 것이 하자인지도 전혀 모르고 작업을 하고 있습니다. 그것이 현재 원전의 현실입니다.

우리는 어떻습니까? 지금 프로그래밍을 하고 있는 현장에 전문가는 존재하나요? 프로젝트 완료를 위해 경험 없는 개발자들이 낮은 임금에 개발과 교육을 동시에 진행하도록 강요받으며 투입되고 있지는 않나요? 현장에 있었던 전문가를 '더 훌륭한 일을 하도록' 다른 곳에 배치하고 있지는 않나요?

현장에 전문 기술자가 줄어들면서, 비전문가들도 건설, 제작을 할 수 있도록, 공사 과정이 설명서(manual)화되었습니다. 설명서화라 함은, 도면을 보며 건설을 하는 것이 아닌, 공장에서 어느 정도 조립된 부품을 가져와서, 현장에서 1번이면 1번, 2번이면 2번 하는 식으로, 그저 나무 블럭을 쌓아 올리듯 짜 맞추는 것을 말합니다. 그렇게 하면, 지금 자신이 무엇을 하고 있는 것인지, 얼마나 중요한 일을 하고 있는 것인지, 전혀 알지 못한 채 조립을 하게 됩니다. 이러한 것도, 사고나 고장이 빈번히 일어나는 원인 중 하나입니다.

여러분이 테스터라면, '이렇게 저렇게 테스트하라'고 지시하는 스크립트의 지령대로, 기계화된 테스트를 하고 있지는 않습니까? 그 과정에서 여러분의 창의력을 발휘할 기회는 혹 박탈되고 있지는 않나요? 무엇을 하고 있는지도 모른 채, 오직 테스트를 위한 테스트만을 하고 있지는 않습니까?

검사관이 용접이면 용접을, ‘그게 아니지. 잘 봐요. 이렇게 하는 거지.’라고 스스로 실연(實演)해서 보여줄 기량이 없다면, 진정한 검사는 이루어지지 않습니다. 그러한 기량이 없는 검사관이 착실한 검사를 할 수 있을 리가 없습니다. 건설사나 시공주의 설명을 듣고, 서류만 갖추어져 있으면 합격을 시키는, 이것이 현재의 관청 검사의 실태입니다.

이 외에도 원문에는 참으로 많은 이야기들이 적혀 있습니다. 

이 세상에는 규정을 지키는 것 만으로 막을 수 없는 많은 위험 요인들이 존재합니다. 그래서 '시장은 천천히 좋아질 것이다'라는 낙관적인 관점의 투자자가, '언젠가는 911같은 사태가 또 일어날 것이다'라고 가정하는 비관적 투자자에게 패배하기도 하고, 규정을 '엄격히' 지켜 만들었다고 생각하는 우주 왕복선이 대기권을 벗어나 보지도 못하고 폭발하기도 합니다. 

규정은 사람이 만드는 것이기 때문에 규정 자체가 얼마나 안전한지, '허용 가능한 위험'의 위험성에 대해서 얼마나 고려하고 있는지에 대해서는 규정 자체에 대한 관리 감독이 없이는 알 수가 없습니다. 문제는 이런 규정의 헛점이 사태가 벌어진 다음에야 밝혀지게 된다는 데 있습니다.

그런 일을 방지하려면 규정-설계-실행 사이에 선순환 피드백 고리가 만들어져야 하는데, 현재 대부분의 생산 현장이나 건설현장에서 그런 피드백을 찾아보기는 힘듭니다. 

그나마 소프트웨어 개발을 하고 있는 우리들은 다행인 셈입니다. 우리는 문제가 생기면 '그다지 큰 부담 없이' 문제를 보고하고 그 해결책을 논의할 수 있습니다. 어쩌면 그것이 '소프트웨어'의 진정한 '소프트'함이 아닐까 싶기도 합니다. 

하지만 이미 쌓아올린 원전이나 다리, 건물같은 구조물에 이르면, 이야기가 조금 달라집니다. 그런 구조물들은 그야말로 '하드'한 구조물이기 때문입니다. '하드'한 구조물을 안전하게 구축하려면 그 구축과정의 윗 부분과 아랫 부분을 연결하는 피드백 고리가 가능하면 짧아야 합니다. '다 만들고 감사받는다'로는 부족하다는 이야기입니다. 

우리는 소프트웨어 개발 분야에서 우리가 얻은 교훈들이, 앞으로 더 늦기 전에 많은 분야에 반영되기를 희망합니다. 그렇지 않으면, 이런 재앙은 막기 어려울 것입니다. 

또한, '낙관적'으로 가정할 수 있는 부분은, 오직 '인간이 본질적으로 선함' 이상도 이하도 아니라는 점을 모두가 깨닫게 되기를 소망합니다. 그리하여 좀 더 철저하고, 좀 더 보수적인 개발과 구축 문화가 뿌리내리기를 희망합니다.

그리고 가능하면, 원전과 같이 재앙의 리스크가 너무나 높은 기술은 가급적인 도입을 자제할 수 있게 되기를 희망합니다. 많은 분들이 '리스크는 관리 가능하다'고 생각하십니다. 네. 물론 관리할 수 있겠지요. 하지만 인간의 '실수'는 대개 관리가 불가능합니다. 스리마일 섬의 사고도 그런 식으로 일어났습니다. 관리가 불가능한 실수가 연이어 터질 때, 그리고 그 실수의 결과가 인간이 통제 가능한 범위 밖에 있을때, 그 실수는 '관리가 가능하다'고 믿었던 리스크를 재앙으로 돌변시키고 맙니다.

그리고 마지막으로, 지금도 일본에서 일어나고 있는 모든 고통스러운 상황들이 곧 끝날 수 있기를 기원합니다.

제품을 개발할 때, 그 제품에 탑재될 기능을 흔히 필수 기능(mandatory features), 선형 기능(linear features), 감동 기능(delighter) 등으로 구분하곤 합니다.

필수 기능은 제품에 반드시 탑재되어야 할 기능, 즉 제품을 시장에 내놓으려면 반드시 들어가야 하는 기능이고,  선형 기능은 많이 들어가면 들어갈수록 고객의 만족도가 늘어나는 기능입니다. 감동 기능은 고객이 기대하지는 않는 기능입니다만, 일단 그런 기능이 있다는 것을 알면 감탄해 마지 않을만한 기능, 기꺼이 그 기능을 위해 지갑을 열만한 기능을 일컫습니다.

최근에 모니터/키보드/마우스 공유기가 필요해서 어떤 제품들이 있는지 인터넷을 뒤져서 좀 살펴봤었습니다. 과거에는 PS2 방식의 공유기가 대세였습니다만, 요즘은 USB 키보드와 마우스가 많아지는 만큼, USB 공유기도 등장하고 있습니다. 필수 기능이 PS2에서 USB쪽으로 이동하고 있다는 증거입니다.

이런 공유기에서 선형 기능은 아마도 공유할 수 있는 모니터/키보드/마우스의 개수일 것입니다. 공유 포트가 많아지면 많아질수록 고객의 만족도는 증가합니다. 물론 그에 비례해서 가격도 증가하기 때문에 고객의 만족도가 이 경우에는 반드시 선형적으로 상승한다고 보기는 좀 어려울 수도 있습니다. 하지만 이렇게 생각해보죠. 고객의 만족도가 증가하면 고객은 그 기능을 위해 기꺼이 지갑을 열고 돈을 지불하게 될 수 있습니다. 그러니 제품을 개발할 때 선형 기능에 대해 생각해 보는 것은 반드시 필요하죠.



그렇다면 만족 기능들로는 어떤 것을 생각해 볼 수 있을까요? 벨킨이라는 업체에서 내놓은 공유기 중 한 모델은 제품을 세워서 놓을 수 있도록 배려하고 있을 뿐 아니라 (공간을 덜 잡아먹습니다) 다른 제품들보다 미려한 외관을 자랑합니다. (최근에는 디자인 적인 요소가 감동 요인으로 등장하는 경우가 늘고 있습니다.) 거기다 이 제품은 여벌의 USB 포트를 제공해, 컴퓨터간에 공통의 USB 장비를 공유할 수 있도록 하는 기능도 제공합니다. USB프린터, USB 메모리 등이 이런 범주에 들 수 있겠죠. 잘만 써먹으면 USB 메모리를 통해 WIndows와 Linux간에 데이터를 아주 손쉽게 공유할수도 있습니다. ㅋㅋ

그런데 이것 말고 다른 감동 요인은 없는 걸까요?

제 책상에는 두 대의 모니터가 있습니다. 한 모니터는 Windows 머신에 연결되어 있고, 다른 한 모니터는 Linux 머신에 연결되어 있습니다. 두 모니터를 동시에 봐야 하기 때문에, 공유기로 연결하더라도 모니터는 연결할 필요가 없습니다. 오직 키보드와 마우스만을 공유해야 하기 때문에, 처음에는 Synergy라는 소프트웨어를 깔아서 키보드와 마우스를 공유하려고 했었습니다.

그런데 문제가 있더군요. 제 컴퓨터들에서는 어쩐 일인지 이 프로그램이 너무 느리게 돌아가는 겁니다. ㅋㅋ Synergy의 가장 큰 장점은, 키보드와 마우스가 두 개의 컴퓨터 사이에 Seamless하게 연동될 수 있도록 만드는 것입니다. 마우스가 윈도우 화면의 가장자리로 이동하면 그 포인터가 자동적으로 Linux 쪽 화면으로 이동하고, 키보드 제어도 자동적으로 그쪽으로 넘어갑니다. 너무 편하죠.

하지만 일반적인 공유기를 사용하면 이런 장점을 누릴 수 없습니다. 모니터를 공유기로 연결하지 않으면 두 화면을 동시에 볼수는 있을텐데, 키보드나 마우스 제어를 다른 컴퓨터로 옮기려면 단축키를 누르거나 공유기의 버튼을 눌러줘야만 합니다.

그렇다면, Synergy가 가지고 있는 기능을 제공하는 공유기가 있다면, 그것이 감동 요인이 될 수 있지 않을까요? 물론 별도의 프로그램을 깔아야 할 수도 있겠고 공유기의 가격도 올라갈 수 있겠습니다만, 두 모니터로 보는 화면이 마치 한 화면처럼 통합될 수 있다는 점에서 (운영체제가 다르고 시스템도 다름에도 불구하고!) 아주 좋은 공유기가 될 수도 있을텐데 말이죠. 저는 아직 이런 제품을 못 찾았습니다. 직접 만들어볼까도 생각해봤는데, 아시다시피 제가 HW쪽으로는 아는게 없어서 말이죠.

오늘 이 글을 보다가 든 생각입니다만, 좋은 개발자가 되려면, 아무래도 인간성이 좋아야 할 것 같아요. (사실 이 비슷한 생각을 한 지는 오래 되었습니다.) 왜 이런 말을 하냐 하면, 적어도 국내에서는 다음의 두 가지 가정이 유효하기 때문입니다.

1. 개발자에게 주어지는 환경이 아주 척박하다
2. 혼자서 모든 개발을 다 해내는 것은 어려운 일이다.

우리나라의 SW 개발 환경이 외국에 비해 그다지 좋지 못하다는 이야기는 나온지 꽤 오래된 이야기입니다. 대부분의 개발 프로젝트는 일정 중심적(date-driven)인 프로젝트이고, 개발을 진행하다보면 요구사항(requirements)도 시도 때도 없이 변화합니다. 다른 프로그래머들과 맞춰야 하는 인터페이스는 한두가지가 아니고, 그러다보면 가끔 굉장히 비생산적인 논쟁에 빠지게 되는 일도 허다합니다.

그런데 이런 비-프로그래머 중심적인 환경에서도 빛나는 프로그래머들이 있습니다. Guru는 아닐지라도, 다른 사람의 가치를 내 가치처럼 중요하게 여기고, 내 편의를 위해 다른 사람의 불편함을 강요하지 않으며, 섣불리 다른 사람의 능력을 폄하하지 않는, 그런 프로그래머들 말입니다.

통계적으로 보면 (어디까지나 제 주관적인 통계에 의한 것이긴 합니다만) 그런 프로그래머들일 수록 신기술을 습득하는 데 주저하지 않고, 맘에 들지 않는 기술이라고 해서 자기 잣대로 폄하하지 않으며, 다른 사람들과의 관계를 원만히 이끌어 갑니다. 남들이 귀찮아하는 TDD도 솔선수범하는 경향이 있고, 문제가 생기면 언제나 자기가 맡은 부분을 주저없이 의심하는 자세를 보여주죠.

하지만 개발 환경이 척박해질 수록, 이런 개발자들도 함께 드물어진다는 것은 서글픈 일입니다. 이런 개발자들이 점차로 드물어진다는 것은, 소프트웨어 기술자들을 계속하여 재생산해 낼 책무를 지는 개발집단들이 개발자들에게 바람직한 역할 모델을 보여주지 못한다는 뜻이기도 합니다.

그런 역할 모델을 보여주지 못하는 이유로는 여러가지가 있겠습니다만, 가장 큰 것으로는 "개발 집단의 상당수가 개발 방법론을 잘 모른다"는 것을 꼽을 수 있겠습니다.

startup 회사부터 좀 잘 나가는 회사까지 여러 회사를 접해보았습니다만, 폭포수적인 개발방법론이나마 꾸준히 적용해보려는 의지를 가진 회사도 드물었고, 일의 양을 정확하게 추정해 보려는 시도를 하는 회사는 더더욱 드물었습니다. 잘못된 추정으로 시작하더라도 중간 중간에 그것을 바로잡을 기회는 자주 주어집니다만, 그 기회를 제대로 이용하는 회사도 드물었어요.

보통은 "야근-대책없는 휴식-야근-대책없는 휴식-야근-대책없는 휴식..."을 소프트웨어를 릴리즈하는 그날까지 반복하죠. 회의시간은 보통 "지시사항 전달"로 변질되고, 개발자들은 요구사항을 내놓은 사람들과 대면하고 요구사항을 이해할 기회조차 갖지 못합니다. 결국 잘 만들어놓으면 "그게 아니었어..."가 되니까 다시 야근을 하게 되구요. 이런 상황에서라면 아무리 인간성이 좋은 개발자라도 종국에는 인간성이 더러워지지 않을까요?

소프트웨어 개발도 남과 더불어 하는 일이니까, 결국 사람과의 인간관계가 가장 중요하기 마련인데, 그 관계를 차단한 다음 닭장에 밀어넣어 놓고는 "니가 할 일만 잘 하면 돼!"라고 하는 꼴이죠. 결국은 나중에 가서 "왜 내 말을 제대로 이해하지 못한거야!"라고 할거면서 말이에요. :-P

이런 억지스러운 환경을 개선하려면 어떻게 해야 할까요? 저는 요즘 그 답을 찾기 위해 애쓰는 중입니다.

많은 프로그래머들이 개발을 하면서 문서 작성은 잘 하지 않습니다. 뭔가 좀 아는 사람들이 모여있는 개발 팀에서는 프로젝트 전반기에라도 가급적 설계 문서를 만들려고 애쓰는 경우가 태반인데 (아예 아무것도 하지 않는 팀도 있긴 합니다. 스파이크 솔루션이라도 간단히 만들어보면 좀 낫습니다만...) 그런 경우에라도 막상 프로젝트가 끝날 때 보면 문서의 상태와 개발 결과물의 상태가 심히 어긋나 있는 경우가 대부분입니다. 뭔가 조금씩 틀리고 잘 맞지 않죠.

극단적으로 보자면, 주석문의 상태와 코드의 상태가 다른 경우도 있습니다. 프로그래머가 코드를 변경하면서 주석문을 재검토하는 것을 잊은 것이죠.

이런 문제에 대한 '현실적인 해결책'들이 여러가지 나와 있습니다. 몇 가지를 열거해 보면

1. 코드의 흐름은 코드가 말하게 하라
2. 문서를 만들면서 코딩하라

뭐 이정도가 있겠습니다. '코드의 흐름은 코드가 말하게 하라'는 것은 가급적 코드에 '그 하는 일'이 명료하게 드러나게 만들라는 뜻입니다. 이렇게 하자면 함수 이름을 잘 지어야 하겠고, 변수 이름을 잘 지어야 하겠고, 가급적 각각의 함수는 그 길이가 짧아야 합니다. 너무 긴 함수는 이해하기 어렵기 때문입니다.

하지만 그렇다고 하더라도 코드만 보고 전체 코드의 얼개를 파악하기란 지난한(혹은 지랄맞은) 일입니다. 그래서 그런지, 저는 다른 사람의 코드를 읽어야 하는 일이 생기면 엔간하면 밑바닥부터 코드를 다시 짜고야 마는 못된 습성이 있었습니다. 지금은 그러지 않으려고 굉장히 애를 많이 쓰는 편입니다만...

그러므로 가장 좋은 해결방법은 2번입니다. "설계 후 코딩하라"는 말을 "프로젝트 전반기에 설계하고 프로젝트 후반기에 코딩하라"는 식으로 아둔하게 해석하는 대신, "설계 후 코딩"에 드는 간격을 최소한 줄여보자는 것입니다.

저는 작업을 할 때 큰 모니터에는 설계 문서를 띄워 놓고 설계를 해 나갑니다. 설계가 끝나면 바로 옆에 있는 노트북에서 개발을 합니다. (좋은 키보드는 데스크탑에 물려놓고 대체 뭐하는 짓인지 ㅋㅋ) 개발을 하다가 뭔가 이상하다 싶으면 즉석에서 테스트를 하고 설계를 변경할 때도 있습니다만, 가급적 설계를 바꿀 때에는 그 사실을 먼저 문서에 반영하고 그 다음에 코딩에 들어가도록 하고 있습니다.

이렇게 하는 것의 장점은 몇가지가 있습니다만, "조엘 온 소프트웨어"의 조엘 말대로, "코드에 손을 대기 전에 먼저 생각을 해 본다는" 점이 가장 큰 장점이겠습니다. 물론 아주 숙련된 프로그래머의 경우에는 프로그램의 설계 전부가 테스트 코드부터 시작해 일사천리로 뻗아 나오게 되는 경우도 있겠습니다만, 대부분의 프로그래머는 그렇지 않으므로, 가급적 설계에 조그마한 변경이라도 가할라치면 문서를 함께 변경해 가는 쪽이 낫겠습니다.

물론 자주 문서에 손대는 것을 싫어하는 프로그래머도 많습니다만, 조엘 아저씨의 말대로 설계가 충실한 코드는 정작 코드 자체를 작성하는 데 드는 시간은 짧습니다.

그런데 대부분의 프로그래머가 그 말을 믿지 않는 가장 큰 이유는

(1) 설계부터 구현까지에 이르는 시간 간격이 지나치게 크기 때문이고
(2) 그렇다보니 정작 코딩을 하기 시작했을 때 즈음에는 요구사항이 바뀌어 다시 설계를 해야하고
(3) 결국은 '재설계'에 투여할 시간이 부족하여 설계를 건너뛰게 되고
(4) 그러다 보니  코드 작성에 드는 시간이 그다지 줄어들지 않게 되기 때문이죠.

이것이 바로 Waterfall 식의 개발 방법의 가장 큰 병폐입니다.
 
그러니 문서를 업데이트 하는 데 드는 시간을 아까와 하지 않고, 개발과 병행해 나가는 편이 낫겠죠.

애자일 개발자들이 어떤 형태의 자리에 앉아서 일을 하도록 해야 하느냐, 하는 데 있어서는 별로 이견이 없는 편입니다. Extreme Programming의 사례를 보아도 그렇습니다만, '적극적인 협업이 가능한 형태면 좋다'의 정도인 것 같습니다. 애자일 원칙들이 대개 그렇습니다만, 정형화된 '규칙(regulation)'이 있는 건 아닙니다.

보통 프로그래머들은 협업의 문제를 컴포넌트 인터페이스 레벨에서 사고하는 경향이 있습니다. 너는 네 일을 하고, 나는 내 일을 하는데, 그 두 일이 인터페이스 레벨에서 잘 연동이 되면 만사 OK다 라는 것이죠. 물론 그렇게만 되면 프로젝트 관점에서야 만사 OK일 수도 있겠습니다만(아닐 수도 있습니다) 문제는 그런 식의 관점이 생산성 측면에서 어떠한 이득도 가져다 주지 못한다는 데 있습니다. 생산성을 극대화시키는 것이 목적이라면, 내 일/네 일 관계를 넘어서는 좀 더 기민한 형태의 의사소통이 필요합니다.

개인적인 경험에 따르면, 이러한 의사소통이 극도로 잘 이루어지는 경우에는 (설사 그 의사소통 형태가 그다지 애자일 적이 아니라고 하더라도) 프로그래머들을 개발 완료 시한 한달을 남겨놓고 소집해서 개발을 시작하더라도 완결된 프로그램을 내 놓을 수가 있었습니다. 물론, 그 중 한 사람은 '프로젝트의 성격과 범위, 그리고 관련 기술에 극도로 능통한 사람이어야 합니다. 모든 의사 소통은 그 '달인'을 통해서 이루어져야 하고, 모든 프로그래머들은 그 한 사람과 자신의 일에 대해서 의논을 해야 합니다.


이런 식의 의사소통 모델에서는 자리 배치는 그다지 중요하지 않습니다. 모든 사람이 (극단적으로 보자면) 딱 한 사람과 자신의 업무에 대해서 이야기를 하면 되니까요. 다른 사람들과 의사소통을 해야 하는 문제는 '달인' 혼자서 다 처리했습니다. 인터페이스 중재부터 시작해서, 개발 범위의 조정 등등... 각각의 개발자들은 중간의 '달인'이 내린 지침에 따라 개발하되, 자신이 담당한 모듈에 대한 클라이언트 인터페이스는 자신이 개발해서 다른 사람들에게 배포하기만 하면 되었습니다.

하지만 이런 '신적인 의사소통 모델'(중간에 마치 신과도 같은 개발자 한 사람이 떡 버티고 있는 모델)은 쉽게 찾아볼 수 있는 형태는 아닙니다. 이런 신적인 의사소통 모델이 널리 통용될 수 없는 이유는 몇 가지 있습니다.

(1) 달인이 드물다
(2) 아무도 달인의 자리에 오려고 하지 않는다.

물론 가장 큰 문제는, 저런 역할을 담당해 줄 달인이 실질적으로는 거의 없다는 점입니다. 그 정도의 권위와 카리스마를 갖춘 사람과 같이 일을 할 수 있다면 정말로 영광이겠습니다만, 그런 드문 기회는 그야말로 드물기 때문에 문제가 됩니다. 설사 그런 사람을 찾을 수 있다고 하더라도, 나중에 프로젝트가 실패하게 되면 그 사람 혼자서 '독박'을 써야 하는데, 아무리 달인이라고 하더라도 그렇게 하려고 할까요?

그렇다면 실제상황에서 써먹을 만한 기민한 형태의 의사소통은 어떻게 해야 가능해지는 걸까요? 어떻게 근무환경을 조성해야 그런 형태의 의사소통이 가능해지는 것일까요?


위의 동영상은 Daum의 제주 GMC 센터의 동영상입니다. 스마트플레이스에 올라왔길래, 참고삼아 링크를 걸어보았습니다. 다른 부분은 논외로 하고, 자리 배치만 한번 눈여겨 보시죠. 팀 내에 있는 모든 사람들이 원형으로 배치되어 등을 지고 일을 하고 있습니다. 뭔가 의논해야 할 일이 생긴다면, 바로 의자를 돌려 관련된 사람들끼리 이야기를 할 수 있는, 그런 구조입니다. 중단기적인 프로젝트를 밀어부치기에는 좋은 구조입니다.

하지만 이런 구조는 "모든 프로그래머는 자신만의 공간을 원하게 마련이다"라는 통상적인 믿음과는 좀 거리가 있습니다. 옆 사람 타이핑 소리까지 다 들릴 정도로 가까운데다, 머리를 조금만 돌리면 옆 사람 모니터까지 다 보이거든요. 물론 Pair Programming을 진행하기에는 아주 이상적인 조건이긴 합니다. 하지만 이런 구조에서 일하는 사람들은 '자신만의 무언가'를 원하게 되는 순간 근무 환경을 떠나야 해요. 근무 환경을 나서면 그 밖에는 근무와는 별 상관이 없는 이질적인 공간이 기다리고 있는데, 사람에 따라서는 그런 이질적인 환경이 사색에 오히려 방해가 될 수도 있습니다.

그러니 저는 자신만의 공간과 협업을 위한 공간 사이에 어느정도의 논리적/물리적인 구분이 존재하는 것이 바람직하지 않겠는가, 하는 생각이 들어요. 자신의 자리에서 일하다가, 협업이 필요할 때 협업을 위한 공간으로 들어가는. 뭐 그런 구조 말이죠. 다만 그 두 공간을 왔다갔다 하는게 그다지 어렵지는 않아야 합니다.

그런 구조에 대해서는 http://www.talk-with-hani.com/archives/660를 참고해 보시는 것이 좋겠습니다. 다만 관리자 입장에서 보면 모든 개발자들에게 이런 공간을 마련해 줄 만큼 돈이 없다는 게 문제가 될 수도 있겠죠. 또 다른 구체적인 사례도 있는데, http://blog.naver.com/yuzico/130007299724 를 참고하세요. 스토리 카드 보드 등등을 망라하는 재미있는 사례들을 많이 보실 수 있습니다. 자리 배치에 대해서는 그다지 상세히 언급하고 있지는 않습니다.