brunch

라이킷 5 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 안영회 습작 Mar 27. 2023

프랭크 게리가 기한과 예산을 맞추는 법

HBR 구독에서 일상 활용으로

이 글은 HBR 기사 <프랭크 게리가 기한과 예산을 맞추는 법>을 읽고 활용하기 위해 생각을 이끌었던 내용과 제 생각을 함께 기록합니다.

책임 있는 일을 수행할 권한이 있는지 반드시 확인한다

프랭크 게리가 수행 착오 끝에 배운 사실이다.

게리를 책임과 비난을 같이 짊어지고 있다는 느낌을 받았지만 문제를 바로잡을 권한이 없었다.

나도 비슷한 경험이 있다. 이전에 CTO 님이 일을 수행할지 판단할 때도 비슷한 기준을 갖고 있음을 확인한 일이 있다. 어쩌면 규모 있는 설계나 프로젝트를 맡기 위해서 한 번쯤은 거쳐야 하는 시행착오일 수도 있겠다.

월트 디즈니 콘서트 홀을 짓기 위해 오랫동안 싸워 온 프랭크 게리는 프로젝트를 진행하려면 반드시 지휘권이 필요하다는 기본적인 깨달음을 얻었다. 처음부터 끝까지 지휘권을 갖고 있어야 한다. 그는 자신이 지휘권을 갖는 구조를 지칭하는 '아티스트 조직the oranization of the artist'이라는 용어까지 만들었다.

항상 이유를 묻는다

공감하지 않을 수 없는 내용이다.

모든 잠재 고객에게 늘 그래왔듯이 가장 근본적인 질문부터 던졌다. "프로젝트를 추진하려는 이유가 무엇입니까?"

맥락을 모르고 일을 하면 낭패를 보기 쉽다.

공무원들은 빌바오 미술관이 시드니의 오페라하우스 같은 역할을 해 줬으면 좋겠다고 말했다. 미술관 덕분에 빌바오 시가 국제적인 명성을 얻고 전 세계 관광객을 유치하면 경제의 활력을 되찾기를 바랐다. <중략> 프로젝트의 목표를 이해하게 된 게리는 고객이 받아들일 만한 다른 비전을 구상할 수 있었다.

<대체 뭐가 문제야>에서 배운 대로 사람들은 대체로 제대로 문제를 정의하지 않는 경향이 있다.

너무나 많은 프로젝트들이 논의 없이 추정만으로 진행된다. 그러면 위험하다. 오래된 격언처럼 '추정하지 말고 확인해야' 한다. 게리는 확인하기 위해 '왜'냐고 질문한다. 확인하지 않으면 프로젝트의 궁극적인 목표를 두고 시각 차이가 있어도 알아차리지 못한다.

진짜 문제 찾기

소프트웨어 공학을 전공할 때 요구사항을 elicit[1]한다는 표현이 너무나 인상적이었다. 그때 느낌을 떠오르게 하는 문장이다.

게리는 프로젝트를 시작할 때 의미 있는 질문을 던지고 답변을 주의 깊게 경청하면서 고객이 원한다고 생각하는 것이 아닌 실제로 원하는 것이 무엇인지를 파악한다.

효과가 없을 것이 뻔한데, 할 수 있는 일이라고 하는 사람들을 자주 본다.

대화를 질문으로 시작하고 상대방에게 진심으로 귀를 기울이는 일은 자연스럽게 되는 일이 아니다. 노벨상 수상자인 심리학자 대니얼 카너먼의 말처럼 사람들은 옳든 그르든 이미 가지고 있는 정보를 바탕으로 생각이 앞서 나가는 가용성 편향availability bias에 시달린다. 게리는 질문을 통해 이런 사고에 제동을 건다.

내가 지금 하려고 하는 일이 '지금 꼭 해야 하나?' 묻는 방법 만으로도 문제 정의에 한 발 다가설 수 있다.

시뮬레이션하고 반복하고 테스트한다

입체적인 대화 즉, 비전을 공유하기 위한 장치로 보인다.

잠재 고객이 게리의 회사를 방문하면 작업 프로세스를 이해할 수 있도록 그가 진행한 과거 프로젝트의 개발 과정에 관한 설명을 자세히 듣는다. 이런 절차가 중요한 이유는 프로젝트 초기 콘셉트에 대한 논의가 끝났다고 해서 의뢰인이 더 이상 관여하지 않는 게 아니기 때문이다. 오히려 그때부터가 시작이다. "꺼려하시는 분들도 있어요. 저희와 함께 일하려면 용감해야 한답니다."

애자일 방식이다.

게리와 팀은 그 콘셉트로 계속 새로운 시도를 반복해 나갔다. 마침내 원하는 모델을 찾았을 때, 그건 74번째 시도 만에 거둔 성과였다.

피드백의 힘을 보여주는 글이다.

예술과 건축에 조예가 깊은 그이지만 거창한 이론적 용어를 거의 쓰지 않는다는 점이 소통에 도움이 된다. 게리는 직설적이며 상대방에게도 솔직함을 기대한다. "저희의 의사소통은 아주 기초적이고 대부분 시각적인 커뮤니케이션이죠. 세련된 언어를 거의 사용하지 않아요." 게리의 회사에서 파트너로 일하는 크레이그 웹의 말이다. 모델을 보고 '좋다' '나쁘다' '맘에 안 든다'라고 말하면 끝이다. 괜찮은 아이디어는 쓰고 그렇지 않은 아이디어는 버린다. 감정이 좀 상하더라도 일이 우선이다.

기고를 위해 쓰고 있는 글의 핵심 개념인 'loosely-coupled'가 떠오르게 하는 문장이 등장한다.

전면이 물결치는 천처럼 보이는 빌딩을 상상하고 스케치하고 모델링하는 것이 이를 실제로 건축이 가능한 디자인으로 구현하는 것은 완전히 별개의 일이다.

소프트웨어 세상에도 똑같다. 비즈니스 현장에서 얻고 싶은 효과와 기능에 대한 설명과 이를 위해 프로그램과 화면을 구성하는 일은 완전히 별개의 일이다.[2]

피드백, 피드백, 피드백

"이(설계) 작업을 수작업으로 했다면 허락된 기한 동안 두세 번 정도 시도해 볼 수 있었을 것"이라며 디지털 시뮬레이션 덕분에 "수천 번에 걸쳐 설계를 시험해 볼 수 있었고, 그 덕분에 비용을 평평한 외벽과 같은 수준으로 줄일 수 있었다."라고 말한다. "변경 주문이 한 건도 없었다는 게 증거죠. 76층 타워로는 전례가 없는 일입니다."

시행착오를 피하라는 상식을 넘어선 수준이 아니라 안전하게 시행착오를 하고 거기서 배우는 법을 실현했다는 생각이 든다. 물론, 이들에게는 디지털 시뮬레이션이라는 기술이 있지만, 그것도 쓰임새에 따라 만들어졌을 테니까. 여기서 영감을 얻은 글은 별도로 쓰기로 하자.

의뢰인은 프로젝트 전체에 관여한다. "상의를 하는 거죠. 모델 제작이 좋은 이유는 의뢰인들이 모델 제작 과정이 좋은 이유는 의뢰인들이 모델 개발 과정을 시각적으로 확인할 수 있고 제가 어떤 부분에서 고민하는지 알 수 있기 때문입니다."

그렇다. 의뢰인에게 평가받는 일은 물질적 결과 확인과 종류가 다른 피드백이다.

게리는 쉽게 만족하는 법이 없다. "저는 그런 부분에서 굉장히 솔직한 편입니다." 게리는 마음에 드는 점과 마음에 들지 않는 점을 솔직하게 말한다. 의뢰인도 그렇게 해주길 바란다. 의뢰인이 의견을 제시하면 그는 열심히 듣고 의뢰인의 생각과 자신의 생각을 종합한다. "의뢰인들도 건축 과정에 참여하고 있다고 느끼죠. 제 사고 과정에 동참하고 있기 때문에 일이 어떻게 진행되는지 알아요. 그래서 '아니요, 저라면 절대 그렇게 하지 않겠습니다'라는 말도 하는 거죠. 프로젝트에 동참하고 있다고 느끼면서 진행 과정을 눈으로 확인합니다. 저는 그것이 굉장히 효과적이라고 생각합니다." 게리의 말이다.

이렇게 고객(의뢰인)을 동참하게 하려면 그들에게 분명한 동기가 제시되어야 한다. 욕망 파악과 대화가 중요하다는 사실을 다시 한번 깨닫는 문단이다.

천천히 생각하고 빠르게 행동한다

저자는 게리와 '빨리 결승선에 도달해 노력한 결과를 보여주고 싶은 프로젝트 제안자'를 대비시킨다.

이런 사람들에게 기획이란 그저 빨리 해치워야 하는 잡무에 불과하다. 그들은 땅을 파고 건물을 쌓아 올려야만 일이 진척된다고 생각한다. 일을 끝내려면 움직이는 게 먼저라고 생각한다. 물론 이해할 수는 있지만 그런 마음은 잘못됐다. 상세하고 철저한 계획 없이 프로젝트를 시작했다가 해결되지 않고 남아있던 문제가 건설 도중 다시 수면 위로 떠오르면 일정이 지연되고 비용이 초과되며 프로젝트는 차질을 빚는다.

'오너와 리더' 문제를 다시 들추게 하는 마무리다.