디벨로퍼웍스 한국어판 번역을 하다가 치명적인 오역을 저질렀는데, 다행히도 독자분께서 날카로운 피드백을 주셨다. 이렇게 잘못된 부분은 분명하게 지적해주시면(잘못된 부분을 지적하는 글을 블로그에 올리신 다음에는 저에게 전자편지로 알려주시면 더욱 좋겠다. RSS 피드와 구글 검색 엔진도 한계가 있으니까...), 똑같은 실수는 반복하지 않겠다(약속~~~). 다시 한번 말하지만 온라인 기사 특성상 언제든지 수정이 가능하므로, 기사를 읽다가 의문 사항이 생기면 일단 원문을 참조해서 이상한 부분을 확인한 다음에 피드백을 주시면 확인 후 바로 반영하겠다.
실수를 했으니 밧데루 하나 먹어야 겠다. 벌칙으로 이번 주에 실릴 디벨로퍼웍스 기사와 관련이 있는 흥미로운 기사를 하나 번역했다. 원문은 Let's Bury the Term Software Engineering이며, 좀 논란의 여지가 있는 내용이므로 jrogue군의 생각을 대변하지 않는다는 사실을 밝혀둔다.
이 기사를 읽고 여러분 생각은 어떤지 댓글을 달아주시면 아주 감사하겠다. 이번 주에 올라올 관련 디벨로퍼웍스 기사를 읽고 나서 여러분 생각이 어떻게 바뀔지 무척 궁금하다. :) 서두가 길었다. 자, 그러면 시작한다.
소프트웨어 공학이라는 단어를 묻어버리자
Daryl Kulak
2007년 11월 10일 토요일 작성
소프트웨어 공학은 소프트웨어 설계자와 개발자들이 하는 작업을 묘사하는 정확한 방법이 아니다. 우리는 무엇을 원하는지 조차 정확하게 모르는 비즈니스족의 기대를 충족하기 위해 끊임없이 변하는 환경에서 소프트웨어를 만든다. 소프트웨어가 공학이라는 말처럼 들리는가? 이 기사에서 토론하겠지만, 물리적인 공학도는 보편적인 물리 법칙을 다루지만 소프트웨어 설계자와 개발자들은 가차없는 변화를 다뤄야 한다. 우리 직업을 묘사하기 위해 공학이라는 단어를 사용함으로써, 우리는 스스로를 정적인 프로세스와 변화를 일상 생활에 스며들게 하는 대신 변화를 억누르려는 경향이 있는 불안정한 팀 구조에 묶어버린다. 소프트웨어, 사람, 프로세스를 공학적으로 다룬다는 관점에서 벗어나도록 우리 마음을 움직일 수만 있다면, 우리 팀은 좀더 서로에게 공명을 일으키며, 높은 생산성을 발휘하며, 변화에 기민하게 대응하는 모습을 발견할 것이다.
비교를 위해, 교량 설계와 건설을 맡은 물리 분야 공학도를 잠깐 살펴보자. 소프트웨어 개발자와 유사하게 공학도는 문제를 정의하고(강을 가로지르기 위한 길), 해법을 설계하고(청사진), 해법을 만든다(완성된 교량). 또한 프로세스 과정을 진행하기 위해 상당한 재료 실험도 들어간다.
교량 건설 vs 소프트웨어 개발
교량 건설 공학도의 주된 관심사는 미적인 측면이 아니라 교량이 얼마나 오래 버티며 무너지지 않을지를 확신하는 데 있다. 공학도는 자신이 성공했다는 사실을 입증하기 위해 여러 제약 조건과 맞붙어 싸워야 한다. 제약 조건은 고객 기대치를 포함하지만, 핵심적인 제약점은 주로 물리 과학과 관련이 있다. 빔이 위치할 장소와 볼트가 들어갈 장소는 설계를 강화하거나 파괴할지도 모르는 물리 법칙이 지배한다.
자 이제 소프트웨어 개발자 차례다. 우리 역시 특정 문제를 해결하기 위해 고용되었다. 분석하고 설계하고 만들고 테스트하고 배포한다. 여기까지는 교량 공학자의 역할과 유사하다. 하지만 제약 사항과 관련한 쟁점은 다르다. 물리학이 소프트웨어 설계자에게 큰 고려 대상이 아닌 이유는 우리가 만든 최종 제품은 만질 수 없기 때문이다. 하지만 우리에게는 다른 제약 사항이 있다. 우리 제약 사항은 비즈니스 규칙과 우리 이해 관계자의 정보 요구에서 비롯된다. 비즈니스 규칙과 이해 관계자는 개발 노력 경계/범위를 결정한다.
이제 두 가지 제약 사항을 비교해보자. 교량 공학도는 물리 법칙에 따라 일한다. 우리는 이해 관계자가 품고 있는 기대에 따라 일한다. 물리 법칙은 잘 알려져 있고, 잘 문서화되어 있으며, 상황에 무관하며, 변하지 않는다. 하지만 소프트웨어 이해 관계자가 품고 있는 기대는 일반적으로 잘 알려져 있지 않으며(심지어 이해 관계자 스스로도 모른다), 제대로 문서화되어있지 않으며, 상황에 밀접하며, 휘발성이 아주 강하다. 비행기 안에서 대표이사가 읽은 잡지 기사 때문에 진행 중간에 급격하게 요구 사항이 바뀐 프로젝트를 본적도 있다. 여러분도 마찬가지 경험을 했으리라. 때로 변화는 어이 없어 보일지도 모르며 때로 명확한 비즈니스 요구 사항일지도 모르지만, 어찌되었거나 소프트웨어 개발에서 변화는 빠지지 않는다.
변화가 바로 핵심적인 차이점이다. 소프트웨어 개발자들은 교량 공학도보다 프로젝트 생명 주기 동안에 더 많은 변화를 다뤄야만 한다. 물론 공학도는 작업이 진행됨에 따라서 문제에 대해 더 많은 사실을 익힐 것이다. 공학도는 특정 지역이 기대보다 덜 단단하다는 사실을 발견하고 이런 이유로 인해 전략을 바꿔야할지도 모르지만, 원래 문제와 물리 제약은 그대로 남아있다.
여기서 한가지 짚고 넘어가겠는데, 여기서 교량 공학도 작업이 쉽다고 말하려는 의도는 없다. 교량 건설은 엄청나게 어렵고 위대한 지성, 훈련, 창의성을 요구한다. 사회가 의존하고 있는 물리적인 구조물을 건설할 책임이 있다고 생각해보라! 하지만 내가 말하는 요점은 소프트웨어 개발 작업과 교량 건설은 근본적으로 다르다는 사실이다.
사람들 역시 달라요.
변화는 단지 차이점을 구성하는 한가지 요소일 뿐이다. 교량 공학도에게서 찾아보기를 원하는 다른 특성을 생각해보자. 교량 공학에서 "전문가 정신"은 무엇을 의미하는가? 특정 직업을 분류하기란 어렵지만 교량 공학도에게 진정으로 필요한 요소가 정확성, 정밀성, 꼼꼼함이라는 사실을 엿볼 수 있다. 이런 특성은 일반적으로 제품 위주지 사람 위주는 아니다.
이제 소프트웨어 개발에서 전문가 정신을 생각해보자. 다시 한번 말하지만 여기에는 중요한 차이점이 있다. 우리 대다수는 제품 위주가 아니라 사람 위주에 가까운 특성이 있다. 내가 지금까지 만난 최고 프로그래머는 너무 꼼꼼하거나 좀스럽지 않았다. 최고 프로그래머는 종종 창의적이고, 변화를 좋아하며, 심지어 괴짜이기도 했다. 틀림없이 최고 요구 사항 분석가는 집중력이 강하고 세부 사항에 몰입하는 공학도 유형은 아닐테다. 요구 사항 분석가는 종종 딱 떨어지지 않는 기능 요구 사항을 이해해서 비즈니스 부서나 비즈니스 사람들 영역에서 일어나는 변화와 불확실성을 다뤄야만한다. 테스터는 좀더 꼼꼼할지도 모르겠지만, 테스터 역시 소프트웨어 생명 주기 동안에 필연적으로 벌어지는 변경을 감내해야만 한다. 시련을 견뎌내는 특성은 아마도 소프트웨어 개발자에 있어 가장 바람직한 개인적인 미덕이다.
하지만 "조금 괴짜"이거나 "세부사항에 목숨걸지"않는다고 고백한 공학도가 설계한 교량 위로 차를 몰고 간다고 생각하면 어떨까? 맙소사!
소프트웨어에서, 우리는 세부 지향적인 특성을 사람 지향적인 특성과 결합한 팀을 원한다. 우리는 꾸준히 우리가 실제로 잘못된 문제를 풀고 있을 가능성에 대비해서 방어책을 마련할 필요가 있다. 따라서 우리 주변에 그다시 세부적이지 못한 사람이 이런 사실을 알려주기를 원한다. 공학도가 잘못된 강을 가로지르는 교량을 만드는 경우는 극히 드물다. 따라서 공학도는 우리처럼 잘못된 문제를 풀지도 모른다는 걱정은 하지 않는다.
변화를 억누르지 않도록 격려하세요
그렇다면 몇몇 사람들은 심지어 더 이상 사용하지조차 않는 용어를 피해야 한다고 도시락 싸들고 다니며 말리는 이유가 무엇일까? 실제로 용어 자체가 문제가 아니라 용어가 우리 팀에게 의미하는 바가 문제다. 우리 스스로를 공학도라고 생각할수록 우리는 해법, 프로세스, 사람을 공학적으로 다루려고 노력할 것이다. 공학적인 모델은 정적인 물리 구조와 기계를 만들어 내기 위해 창안되었다. 이는 끊임없는 변화와 흐름을 다루도록 고안된 개념이 아니다. 수 많은 변화가 일어난다는 사실을 안다면 우리 모두는 다른 식으로 해법에 접근해야 한다. 변화가 필요한 교량을 상상해보자. 빌딩 블록 집합으로 만들어서 분리한 다음에 재빨리 다른 강으로 이동할 수 있어야 한다. 실제로 군대에서는 임시 가교 건설에 상당히 능숙하다. 하지만 대다수 교량 공학도는 변화가 일어나야 하는 뭔가를 만드는 데 익숙하지 않다.
소프트웨어 개발에서, 변화는 우리의 끊임없는 동반자가 되어야 한다. 개발 생명 주기 동안에 일어날 변화를 다룰 준비가 되어있어야 한다. 비즈니스가 변화함에 따라서 양산에 들어간 다음에도 바뀔 수 있는 소프트웨어를 창조할 필요가 있다. 객체-나 컴포넌트- 접두어가 붙은 새로운 설계와 프로그램 패러다임은 끊임없는 변화를 촉진하는 데 사용할 도구다. RUP와 같은 반복적이고 점진적인 생명주기와 여러 애자일 프로세스는 생명 주기를 통틀어 요구 사항과 기타 요인이 바뀌는 변화에 대응하는 방법을 제공한다. "변화를 다룬"다고 말할 때, 전형적인 변경 관리에 대해 이야기할 생각은 없다. 변경 관리 모델은 의미있는 방식으로 변화를 다루지 못한다. 변경 관리 모델은 변경 억제 모델이다. 이 기사에서, 나는 정말로 비즈니스에서 일어나는 변화를 수용해서 (이를 멈추는 방법을 찾는 대신) 일상에 편입하는 방법을 설명하고 있다. 진짜 공학적인 접근 방식은 당연히 그래야겠지만 변경 억제에 초점을 맞춘다.
소프트웨어 부문에서, 변화를 억누르면 실패가 생기기 마련이다. 우리에게 주어진 제약은 변화와 한묶음으로 붙어 다닌다. 우리에게 주어진 제약은 사람의 기대, 요구, 바람, 감정이다. 마이크로소프트 사에서 비즈토크 리드 프로그램 관리자를 맡은 Jeanne Baker가 말한 바에 따르면 "우리 제품 관리자는 프로젝트 시작 시점에서 원했던 해법이 아니라 프로젝트 끝 무렵에 원하는 해법을 바란다"라고 말했다. 일반적으로 두 가지 다른 점이 있다. 우리는 우리 프로세스를 비즈니스 사람들의 기대치와 일치하도록 만들어야 한다. 우리 프로세서를 너무 공학적으로 다루면, 생명 주기 끝부분에 원하는 해법을 비즈니스 사용자에게 제공하지 못한다.
창의성을 말살하지 마세요
다행스럽게 공학적인 마음가짐이 우리 프로세스를 망가뜨리는 현상을 눈으로 확인할 수 있다. 공학적인 마음가짐은 또한 우리 사람을 망가뜨린다. 고도로 공학적인 프로세스와 조직적인 구조는 일하기에 즐거운 장소가 아니다. 관리자 입장에서 만들고 관리하기가 가장 쉬운 조직 유형은 기계와 유사한 구조라는 생각이 들지도 모르겠다. 모든 사람은 제대로 정의된 작업을 수행한다. 작업 전환은 명쾌하고 똑 부러지며 혼동이 없으며 효율성만 강조될 뿐이다. 하지만 사람을 기계 톱니 바퀴로 여기면 제약이 너무 크다. 관리자로서 여러분은 효과적으로 각 개인의 창의성을 차단할 수 있다. 그리고 창의성을 차단함으로써 변화를 가능하게 만드는 조직 능력을 억누른다. Inner Edge 잡지 편집자였던 Carol Pearson은 "끊임없는 창의성은 끊임없는 변화라는 도전에 맞서 싸우도록 만든다"라고 말했다. 창의성은 "변화에 준비된" 팀을 만들어내는 유일한 방법이라고 강조하고 싶다.
모든 인간은 일을 포함해서 각자 삶을 개선하기를 원한다. 뭔가를 수행하는 더 좋은 방법이 떠오르면, 바로 시도해보기를 원한다. 하지만 아주 공학적인 기계 조직에서는 다양한 새로운 아이디어를 다루지 못한다. 항상 누군가 변화를 추구하기 시작하면, 나머지는 변화의 충격으로부터 꼼짝 달짝 하지 못하리라는 공포심이 팽배해있다. 사람들이 기계처럼 행동하기를 원하는 조직에서 아주 당연한 현상일지도 모르겠다.
사람과 프로세스를 기계처럼 다루면 안 된다는 방식에 초점을 맞출 때, 우리가 창조하는 소프트웨어가 최종적으로는 기계라는 사실에 주목할 필요가 있다. 우리가 겪는 문제는 실제 동작하는 소프트웨어 영역을 벗어난 외부인, 즉 우리 세상에서 나머지 구성 요소인 사람과 프로세스로 기계 은유를 확장할 때 일어난다. 하지만 우리가 만든 기계가 단순히 코딩 대상이며 실행 가능한 소프트웨어 자체라고 생각을 제한할 수 있다면, 과도한 공학 문제를 겪지는 않을 것이다.
사람들의 삶을 향상시키고 직원과 팀원을 행복하게 만드는 과정에 도움을 주는 아이디어를 여기에 소개했다. 또한 스스로 진행하는 작업에 좀더 많은 통제권을 부여함으로써 행복을 달성하는 방법을 설명했다. 나는 회사에서 사람들이 느끼는 행복이 파티, 보상, 축하, 더 큰 사무실, 인정과 같은 일반적인 수단으로 개선될 수 있다고 말하지 않았다. 대부분, 이런 피상적인 행복 추구 방식을 따르더라도 사람들이 회사에서 느끼는 행복은 오래 지속되지 못한다.
지금까지 시멘트를 붓거나 호텔에서 청소를 하는 등 노동을 해봤다면, 스스로 개선을 경험할 수 있을 때 직업이 좀더 즐거우며, 그렇지 못할 때 즐겁지 않다는 사실을 깨닫고 있을 것이다.
변화를 위한 공학은 불가능하다
그러면 단순히 "변화를 위한 공학은 없는가? 그렇다. 진짜로 없다. 공학적인 기계 모델을 따르는 조직에서 여러분 팀은 조직을 위해 모든 가능한 변화 유형과 공학적인 측면을 예상해야 한다. 이런 작업은 불가능하다. 기계는 주변 환경 변화에 대응해서 창의적으로 반응하지 못한다. 무엇을 해야할지 알려줘야만 한다.
여러분은 작업 대상과 수행 방법에 광범위한 책임과 유연성을 부여함으로써 팀원들이 각자 맡은 작업을 개선하도록 도울 수 있다. 이렇게 하면 "혼돈의 왕국"을 만드는 대신 이따금 창의적인 분위기를 팀 내부에 스며들게 도와준다.
우리 프로세서와 개발자는 공학에서 벗어나는 편이 좋다. 그렇다면 "소프트웨어 공학"이라는 용어를 대신할 후보는 무엇일까? 가능성이 아주 많으며, 선택은 전적으로 당신에게 달려있다. 소프트웨어 개발이라고 부르면 그리 억지스럽지는 않다. 이 용어는 우리가 이미 광범위하게 사용하고 있기 때문이다. 다른 용어 후보로 소프트웨어 창조나 소프트웨어 통합이 있는데, 정적인 구조를 중요하게 여기지 않도록 도와준다. 소프트웨어 공학을 대신할 가장 적합한 용어를 찾는 작업은 소프트웨어, 사람, 프로세스를 공학적으로 다룬다는 관점에서 멀리 떨어지도록 우리 마음을 움직이는 노력보다 절박한 상황은 아니다. 우리 마음을 다스릴 수만 있다면, 우리는 크게 발전한 셈이다.
저자 소개
Daryl Kulak은 나스닥에 상장한 IT 컨설팅 회사인 Perficient에서 방법론 코치를 맡고 있다. Daryl은 Use Cases: Requirements in Context (Addison Wesley, 2003) 공동 저자이며, 2008년 가을에 새로 나올 Agile + Rigor을 Dr. Hong Li와 함께 집필했다. Daryl은 오하이오 주 컬럼버스 시에 살고 있으며, 소프트웨어 개발 프로세스와 팀 개선을 위해 고객과 함께 일한다.
