[2부 2번 수필] 소프트웨어 오류에 대한 단상

아키텍처 - 설계 - 구현에 이르기까지 한치의 실수도 없이 한 달음에 끝내야 한다고 주장하는 사람들을 종종 만나곤 한다. 주로 하드웨어 부문에 있는 사람들이 이런 방식의 일처리에 익숙한데, 심지어 소프트웨어 개발에 6시그마와 같은 방법을 사용하려는 욕망을 드러내기도 한다.

소프트웨어 오류에 대해 우리가 과연 어떤 식으로 대응해야 할까? 로버트 L 글래스 큰 형님께서는 다음과 같은 주장을 통해 사람의 중요성을 강조한다.

소프트웨어 오류 제거에서 가장 중요한 요소는 제품 특성이나 프로세스 특성이 아니라 올바른 사람의 선택이다.

200% 동감이 가는 말이다. 방법론이 아무리 뛰어나고 지원 도구가 아무리 우수하면 뭐하나? 결국 오류를 찾아내는 사람이 가장 중요한 말이다.

여기까지야 너무나 많이 떠들어온 이야기라서 식상하기 일보직전일테다. 그렇다면 여기서 말하는 올바른 사람들의 특성이 무엇일까? 로버트 L. 글래스 큰형님에 따르면 다음과 같은 놀라운 사실이 밝혀진다.

우수한 사람들이 '나쁜'사람들 보다 잘못 시작하는 경우가 많다는 사실을 발견했다. 즉, 좋은 소프트웨어를 만들려면 적어도 생명 주기 포반에는 시행착오를 거치면서 불가피하게 '오류'가 생긴다는 뜻이다. 그러므로 모든 오류가 무조건 나쁘지만은 않다.

자전거를 처음 배울 때 넘어지지 않고 배울 수 있다면 얼마나 좋겠느냐만, 세상에 공짜 점심은 없다. 제대로 훈련받은 공학도라면 초반에 저지른 오류를 후반에 다시 저지르지는 않을테니, 차라리 출시 직전에 대박(?!)을 터트려 제품 전체를 위험하게 만드느니 초반에 이런저런 온갖 실수를 다 저지르도록 정책적으로 배려해줄 필요가 있다. 개발자를 믿고 신뢰하면 그 만큼 돌아오는 몫이 크다.

요즘 들어와서 초반부터 꽉 짜여진 틀에 따라 정확하게 소프트웨어를 만들어야 한다고 윽박지르는 관리자를 볼 때마다 화가 나기 보다는 연민의 정이 느껴진다. 소프트웨어 제작을 공장 컨베이어 벨트에서 진행하려는 이런 시도 때문에 소프트웨어 산업이 3D화 되고 있지 않은지 반성해볼지어다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호

[2부 1번 수필] 인지적 견해: 소프트웨어 설계를 보는 다른 시각

설계 부문의 고전인 'Design Methods'를 지은 존 크리스토퍼 존스 큰 형님 사진

소프트웨어 분야에서 소프트웨어 설계만큼 신기하면서도 어려운 공정이 없다는 생각이다. 로버트 L 글래스 큰 형님 말처럼 30여년이 넘게(지금은 45여년이 넘게) 소프트웨어를 설계해왔고, 상식적으로 필요하다 싶은 설계 방법론과 설계 언어를 모두 갖추고 있지만, '설계'에 대해 명쾌하고 가슴이 와 닿는 정의를 내리기는 무척 어렵다.

이런 상황에서도 대가들은 뭔가 달라도 다르다. 오늘은 존 크리스토퍼 존스 큰 형님이 설계에 대해 정의한 문구를 소개하고 싶다. 개인적으로 아주 좋아하는 설계 관련 이야기이기도 하다.

근본적인 문제는 예측이 올바르지 않을 경우 현실화되지 못하는 _미래_ 상태를 예측하기 위해 설계자가 _현재_ 주어진 정보를 사용해야 한다는 사실이다. 설계의 마지막 결과물은 결과물을 만드는 수단을 펼치기 앞서 미리 가정해놓아야 한다. 설계자는 영향을 미치는 사건 연쇄가 시작되는 초기에 세상에 영향을 미칠 시점을 기준으로 시간을 거슬러 올라가면서 작업해야 한다.

쉽게 설명해서, 설계자는 설계의 결과가 어떻게 동작할지 모두 알기에, 속된 말로 짜고치는 고스톱을 친다는 말이다. 심심풀이로 주변에 프로그램을 잘 짜는 친구들을 대상으로 인터뷰를 해보면 한결같은 대답이 나온다.

질문: 개발 과정 중에서 언제부터 프로그램 구현을 시작합니까? 대답: 내가 짠 프로그램이 제대로 돌거라는 확신이 설 때부터.

서투른 개발자는 프로그램 구현에 있어 부딪히는 모든 함정에 따 빠지면서 가까스로 목표를 향해 전진하지만, 뛰어난 개발자는 마치 매트릭스에서 네오가 총알을 부드럽게 피하듯 주변에 함정이 어디있었냐는 듯(실제로 함정에 빠지긴 하지만 워낙 회복 속도가 빨라서 주변 사람들에게는 함정을 피한 듯이 보일 뿐이다. :))이 목표를 향해 그대로 돌진하다.

크리스토퍼 존스 큰 형님에 이어 로버트 L. 글래스 큰 형님도 한마디 거든다.

연구 결과를 이해하려면 먼저 짧은 소프트웨어 역사 속에서 전통이 되어버린 사고에 대한 집착을 버려야 한다. 설계의 외적인 표현에 연연하지 말고 사고의 흐름에 초점을 맞춰야 한다. 설계의 비밀은 _마음_속에 있다.

이런 평범하다면 지극히 평범한 진리를 이해하지 못하기 때문에 제대로 된 프로그램을 만들기 위해서는 객체지향형 언어인 C++나 자바나 파이썬이나 루비타 기타 등등의 언어를 사용해야_만_한다고 교조주의적인 주장(예: "아직도 C를 쓰세요? 설계에 대해 X도 잘 모르시는군요.")이 나온다. 설계의 비밀은 프로그램 언어에 있지 않고 방법론에도 있지 않다. 여러분 _마음_속에 있다.

로버트 L. 글래스 큰형님은 설계의 본질을 딱 네 줄로 설명한다.

1. 마음 속으로 모델을 만들어본다.
2. 마음 속으로 모델을 실행한다. 즉, 시물레이션을 통해 모델이 문제를 해결하는지 확인한다.
3. (대게 모델이 너무 단순해서) 문제를 해결하지 못하면, 불충분한 모델에서 실패하는 부분을 찾아서 개선한다.
4. 모델이 문제를 해결할 때까지 1-3단계를 반복한다.

즉, 설계는 정신적이고, 아주 빠르고, 반복적이며, 사실상 시행착오를 거듭하는 과정이며, 마음이 문제 해결책을 구상한다. 즉 설계의 본질은 신속한 모델링, 시물레이션이며, 설계의 핵심 요소는 해결책을 제안하고 실패하는 능력과 실패를 극복하는 능력이다.

로버트 L. 글래스 큰형님의 마지막 아름다운 말씀을 전하면서 마무리 하겠다.

설계는 마음 속에서 번개처럼 떠오르는 무언가임을. 그리고 어떤 사람의 번개는 다른 사람의 번개보다 훨씬 빠르다는 사실을.

"소프트웨어 컨플릭트 2.0" 역자 박재호 올림

[1부 4번 수필] '가장 뛰어나고 명석한 두뇌들이 내놓은 보고서'

'Rapid Development: 프로젝트 쾌속 개발 전략'을 읽다보면 '10대 위험 목록'에 대한 설명이 나온다. 스티브 맥코넬은 이런 환상적인 쾌속 개발 기법의 기원을 빼놓았는데, 알고보면 미국방성(DoD) 국방과학부 특별 위원회가 발간한 보고서로 거슬러올라간다.

국방성에서 발간한 보고서는 DoD에서 소프트웨어를 개발하는 과정에서 발생하는 문제점과 이에 대한 해결 방안을 조목조목 담고 있는데, 다른 내용도 흥미롭지만 위험 관리 부문을 절대로 그냥 넘겨서는 안된다는 생각이다. 사실상 10대 위험 목록 유지는 어떤 개발 방법론도 따라오지 못하는 강력한 상황 파악 능력을 프로젝트 관리자에게 선사하므로 원시 코드 이력 관리와 일일 빌드와 함께 관리자 도구 목록에 포함시켜야 한다.

보고서에는 뭐라고 적혀 있었을까? 소프트웨어 컨플릭트 2.0 26페이지에서 잠깐 몇 글자 따와보겠다.

추천 25: ... 소프트웨어 획득 과정에서 위험 관리 기술을 필수로 만들어라.

1. 프로젝트에서 최고 위험 10가지를 밝힌다.
2. 각 위험별로 대처 방안을 세운다.
3. 매달 최고 위험, 대처 방안, 결과를 수정한다.
4. 월간 프로젝트 검토 회의에서 위험 상태를 점검한다.
5. 적절한 조치를 취한다.

무척 간단하지 않은가? 최고 위험 10가지를 항상 유지해야 하는 결정적인 이유는 바로 이 최고 위험 10가지가 현실화 되는 순간 여러분 프로젝트가 꼼짝없이 실패하기 때문이다. 장기를 두면서 자기 왕이 외통수로 몰려서 꼼짝 달짝 못하는 상황에 이르고 싶어하는 사람이 있을까? 프로젝트 진행도 마찬가지다. 외통수로 몰릴 가능성이 있는 수를 미리 검토해서 프로젝트를 진행하는 사람들에게 경종을 울리는 깃발이 바로 최고 위험 10가지 목록이다.

어떤 사안이 최고 위험 10가지 목록에 계속해서 올라가 있고 내려올 생각을 하지 않는다면 프로젝트 진행 과정에서 다른 기능 추가 작업에 앞서 위험 요소를 줄이거나 없애거나 회피하도록 노력해야 한다. 위험 목록 자체에 우선 순위와 미치는 영향을 포함시켜 둘 경우 상부에서 자원 투입을 어떻게 해야 할지 쉽게 결정할 수 있기 때문에 위험을 줄이는 과정에서 우왕좌왕 결정을 못내리고 모두 발만 동동 구르는 경우도 줄어든다.

하지만 최고 위험 10가지 목록이 주는 가장 큰 효과는 모든 사람이 위험을 자기 머리나 가슴 속에 품어 꽁꽁 감추는 대신 공론화시켜 해법을 찾으려고 노력하는 분위기 개선이다. 프로젝트를 가로 막는 위험을 이야기한 사람에게 책임을 떠넘기는 대신 모두가 위험을 제압하기 위해 노력하는 모습은 생각만해도 아름답다. 팀이나 프로젝트 단위로 힘들다고? 그렇다면 매주 개인 별 최고 위험 10가지 목록을 정리해보고 변화 추이를 살펴봐라. 프로젝트 통제 과정에서 깜짝 놀랄만한 효과가 있을 것이다.

'소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁' 역자 박재호 올림

[공지사항] 소프트웨어 컨플릭트 2.0 본문 서체

많은 분들께서 소프트웨어 컨플릭트 2.0 본문에 사용한 서체에 대해 질문을 해주셨습니다. 여러분의 궁금증을 풀어드리기 위해 몇 가지 질문과 대답을 정리해보았습니다.

• Q: 본문 서체가 보통 책에서 찾아 보기 어려운데 무엇입니까? A: 한겨례 신문사에서 만든 한결체입니다. 한겨레 신문 독자 여러분께서는 지금 신문 글꼴과 책 글꼴을 비교해보시기 바랍니다.
• Q: 왜 서체가 어색하게 보입니까? A: 기존 다른 책에서 사용하는 네모글이 아니라 탈네모꼴이기 때문입니다.
• Q: 하필 탈네모꼴 서체를 사용한 이유는 무엇입니까? A: 처음에는 어색하지만 적응되고 나면 가독성이 높고 눈이 덜 피로하기 때문입니다. 또한 소프트웨어 컨플릭트 2.0과 같은 수필 종류와 잘 어울린다는 생각도 들었기 때문입니다.
• Q: 신문사 글꼴을 사용했으므로 저작권 위반 아닙니까? A: 아닙니다. 한겨레 신문사가 한글날을 기념해서 공개했습니다. 눈썰미 있는 독자 여러분이라면 역자 서문에 "한결체를 사용한다"는 고지를 읽어보셨을 겁니다.
• Q: 앞으로도 계속해서 이 서체를 활용하실 계획이십니까? A: 출판사와 협의해서 되도록 수필 성격이 짙은 책에는 계속해서 적용해볼 생각입니다.

궁금증이 풀리셨나요? 책과 관련해서 다른 궁금증이 있으면 언제든지 역자에게 질문을 해주시면 블로그에 답변을 올려드리겠습니다.

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림