제1장 남들이 안 알려주는 소프트웨어 개발의 본질들

jongfeel commented 4 months ago

제1장 남들이 안 알려주는 소프트웨어 개발의 본질들

1-1 들어가며

소프트웨어나 서비스를 만들 때, 아무런 준비도 없이 무작정 기한을 정하고, 싼 임금의 저숙련된 사람들을 많이 투입해서 만들어도 된다고 생각하는 경영자나 고객 들을 많이 만나볼 수 있었습니다. 이것은 매우 위험한 생각이라고 저는 생각 했습니다.

1-2 이상한 나라의 소프트웨어 개발

1) 왜 우리 회사/부서가 만들기로 한 소프트웨어는 제때 안 나오나?

이렇게 물어보는 이유가 있습니다. 경영이나 사업을 추진하는 데있어서 ‘시기’가 제일 중요하기 때문입니다. 예컨대 가을 프로모션에 맞춰서 나와야 하는 홍보용 홈페이지나 서비스가 제때 나오지 못하면 이건 물 건너 가는 일입니다.

소프트웨어 개발이 적절한 시간에 맞춰 완료되지 못한다면 대부분 사람은 의사결정권자인 당신에게 가장큰 책임을 물을 것이고, 그것으로 당신은 상처받게 될 것입니다.

2) 내부 하청이 되어버린 소프트웨어 개발: 인간 소외의 현장

무언가 만들어 내고 이것으로 사업하는 모든 사람들이 그냥 ‘X를 던지듯’ 나눠서 일하려고 합니다. 이 일을 누가 받는지, 뭐 하는지 관심이 없고요.

이런 상황에서 아무리 워터폴, 애자일 이야기를 해봤자 아무것도 해결되지 않습니다. 프로세스 자체가 없고 잘못될 수밖에 없는 의사결정 구조를 그대로 두고 있는 상황에서 뭐가 되겠습니까? 진단이 잘못된 상황에서는 어떤 해결책도 없다고 봅니다.

“결국 대부분의 소프트웨어 프로젝트 문제점은 그일을 하는 사람들의 의사결정 구조의 문제점을 닮아간다. 프로세스만 문제가 아니다.” (콘웨이의 법칙과 비슷한 말이긴 합니다.) 이는 시스템을 설계하는 의사결정 과정이 꼬이면 제품이 망하는 것을 말하고자 하는 것입니다.

1-3 사람들이 잘 모르는 소프트웨어 개발의 본질들

1) 소프트웨어 개발의 본질: 인간이 지금까지 해온 일들 중에 제일 어려운 불확정적인 일

요즘 무얼 만들어도 다 소프트웨어 개발이다
소프트웨어 프로젝트의 성공 확률은?
- 2020년에는 약 31%만 성공했습니다. 그 전의 자료들을 대충 봐도 평균 30% 안쪽의 성공 확률입니다.
- 많은 사람들이 ‘성공’에만 눈을 돌리지 ‘지금 벌이는 일이 얼마나 쉽게 실패’ 할 수 있는 일인지는 고민하지 않습니다. 따라서 이것이 제일 먼저 우리가 시각을 바꿔야 하는 부분입니다.
지금 당신은 세상에서 가장 어려운 일을 하려 하고 있다
- 이 프로젝트의 최고 의사결정권자는 무엇을 만들어야 하는지, 고객의 피드백이 어떠한지, 시장은 어떻게 변하는지에 대한 정보를 모든 구성원이 알게 하고, 구성원들의 일을 힘들게 하는 방해물을 없애주어야 합니다. 이것이 최고 의사결정권자의 책임입니다.
최고의 고객이 되어야 한다: ‘무엇을 만들지’를 알고, 요구하고, 때로는 방향을 수정할 수 있어야 한다.
- 당신은 훨씬 능동적으로 움직여야 하며 정확하고 빠른 의사결정을 내려주어야 합니다. 그것이 당신의 역할입니다.

2) 소프트웨어 개발은 반복/반복/반복이다: 한 번에 끝나지 않는다

소프트웨어 개발을 생각한다면 죽을 때까지 지속적으로 개발한다고 생각하세요
- ‘소프트웨어 개발 일정을 잡을 때는, 반복적으로 나눠서 출시한다고 생각하는 게 답이다’가 정답입니다. 더 심하게 말하면 ‘안 끝날 수도 있다’입니다.
- 소프트웨어 개발 일정을 생각한다면 여러 번 배포하면서 피드백을 받고 방향을 다시 잡고 갈 수밖에 없다가 정답입니다.
소프트웨어 개발을 시작했다면, 이것이 끝없이 가야 한다고 생각해야 한다
- 하나의 완결된 제품이 나와야 합니다. 단 1개나 2개의 기능만 가지고 있어도 됩니다. 하지만 그 자체로 완결된 제품이어야 합니다. 이러한 제품을 바로 최소 기능 제품 (minimum viable product, MVP)이라고 합니다.
- 가장 중요한 것은 매 반복마다 피드백을 받아야 한다는 것입니다. 당신에게서, 당신의 고객에게서, 그리고 개발진에게서 말입니다. 그리고 그 피드백은 반드시 다음 개발의 방향을 바꿀 수 있어야 하고요.
- 개발을 하다 보면 모든 상황을 다시 봐야 하는 상황이 꼭 벌어집니다. 언제나 상황이 처음과는 달라지기 때문입니다. 이러한 변화에 대해 받아들일 준비를 하고 개발하는 것과 그렇지 못하고 개발을 진행하는 것은 큰 차이가 납니다.

3) 소프트웨어의 가격은 모두 유지보수 때문이다

유지보수성이란 무엇인가?
- 유지보수성이 왜 중요하냐? “이 물건을 얼마나 오래쓸 수 있느냐”를 좌우하기 때문입니다. 잠깐 쓰고 버릴 물건에 큰돈을 들이는 바보는 없습니다. 그 물건을 오래 쓰려고 한다면 어딘가 고장이 날 거고 때로는 확장을 해야 할수도 있을 것입니다. 그때 이를 해결하고 갈 수 있는 물건이라면 가격이 비싸도 사는 게 맞지요.

소프트웨어의 유지보수성과 자동차의 유지보수성을 비유로 설명하면 이렇습니다.

오일 교환(oil change): 소프트웨어도 주기적인 업데이트와 유지보수가 필요합니다. 새로운 기능 추가, 버그 수정 등의 작업을 통해 소프트웨어가 원활하게 동작할 수 있도록 유지해야 합니다.
타이어 교체(tire replacement): 소프트웨어도 기술 적인 변화나 새로운 환경에 맞춰 업데이트해야 합니다. 만약 구식 기술로 개발된 소프트웨어를 사용하면 보안상의 문제나 성능 저하 등이 발생할 수 있습니다.
배터리 교체(battery replacement): 소프트웨어에서도 기술적인 디자인 이나 코드의 품질이 떨어지면 시간이 지남에 따라 성능이 저하되거나 오류가 발생할 가능성이 높아집니다. 이런 경우 배터리를 교체하듯이 소프트웨어의 일부를 리팩토링하거나 개선해야 합니다.
자동차 정비(car maintenance): 소프트웨어도 코드 리뷰, 테스트, 디버깅 등의 과정을 통해 안정성과 신뢰성을 유지할 수 있습니다.

유지보수성을 높이기 위해 개발자들은 아래의 일을 해야 합니다.

명확하고 간결한 코드 작성하기
모듈화와 재사용성 고려하기
테스트와 자동화
문서화
보안 고려
정기적인 업데이트와 버전 관리
사용자 피드백 수렴과 반영

일회용 선거 사이트의 세계

2015년, 이준행이란 개발자가 한겨레에 기고한 『일회용 선거사이트의 세계』 라는 글이 있는데, 한마디로 이야기해서 선거철이 되면 선거 출마자를 위해서 뭔가 ‘보여주는’ 사이트가 하나씩 만들어지고 사라진다는 것입니다.

사이트를 그냥 ‘온라인상에 붙어있는 전단지’로만 생각하면 이 이상 생각하지 않아도 될지 모릅니다. 그러나 만약 이 정치인이 ‘내 정치 인생에서 계속 국민들과 소통하는 플랫폼으로 만들겠다’라고 한다면 다른 선택을 해야 합니다.

4) 문제 그 자체에 대해 알아보자

지금 만들어야 하는 소프트웨어가 해결해야 하는 ‘문제’를 얼마나 알고 있나요?

GE는 이른바 Six sigma로 유명했습니다. 이는 경영의 문제를 해결하는 데 ‘통계적’ 분석을 통해서 어떻게 높은 성과를 낼지를 고민하는 방법론이었습니다. 이 방법론이 너무 이상하게 느껴진 이유는 '문제가 무언지 파악’하는 데 대부분의 시간을 쓰는 것입니다.

우리는 그 문제에 대해서 결국 다 끝나서야 알게 됩니다. “어떤 문제를 해결해야 하는가?”를 묻는 것은 ‘문제의 가치’를 따지는 것입니다. 정말 중요한 X가 무엇인지를 정의 하고 이를 탐구하는 과정은 절대 시간 낭비가 아닙니다.

커네핀 프레임워크 (cynefin framework): 우리가 해결해야 하는 문제의 속성은 뭔가?

커네핀은 의사결정을 지원하는 데 사용되는 개념적 프레임워크로서 1999년 데이브 스노든 (David Snowden)이 IBM 글로벌 서비스에서 근무할 때 만든 것입니다.

조직이 문제를 학습하면 할수록 혼란 (chaotic) → 복잡 (complex) → 복합 (complicated) → 명확 (clear) 혹은 단순 (simple)의 단계를 거쳐서 이 문제의 본질을 알게 된다는 프레임워크입니다.

현실에서 대부분의 문제는 ‘복잡 (complex)’에 있습니다. 비즈니스도, 대민 서비스의 설계도 보통 이렇습니다. 그런데 이럴 때 창발적 실천법 (emergent practice)이 아니라, 명확 (clear)하다고 생각해서 이른바 모범사례 적용 (best practice) 으로 가버린다면 어떻게 될까요? 제대로 대응할 수 없을 것입니다.

복잡한 일을 한 번에 처리하려다 망한 사례: NEIS 4세대로 보는 공공 IT서비스 개발의 문제점

진짜 문제는 10년마다 시스템을 갈아엎고 한 번에 모든 문제를 해결하려는 빅뱅 방식의 프로젝트 개발 방식으로 접근했기 때문이었습니다.

문제는 소프트웨어 개발 자체는 커네핀 프레임워크의 관점에서 보면 복잡 (complex)한 단계라는 것입니다. 요구사항은 명확할지 모릅니다. 하지만 이를 실제 구현해 보면 생각했던 설계대로 구현할 수 없는 경우가 많은 게 일반적 입니다.

현재 조달 방식은 반복개발방식으로 소프트웨어나 서비스를 만들 수 없는 구조라는 것입니다. 조달청 홈페이지에 있는 조달 절차대로 라고 하면 적격심사 통과에서 무조건 최저 입찰 업체가 뽑히는 구조입니다. 그런데 복잡 (complex)한 문제를 해결하기 위해서는 위에서 언급한 대로 ‘창발적 실천법 (emergence practice)’으로 접근해야 합니다. 그러면 자연스레 비용은 올라갈 수밖에 없습니다. 한마디로 비쌀 수밖에 없습니다. 그런데 최저가격을 제시한 업체를 뽑으니 뭔가 이상하게 될 수밖에 없습니다.

무슨 문제를 먼저 풀지?

소프트웨어 설계에서 핵심적인 (Center) 의사결정들은 무엇일까요? 첫째, “누가 이 소프트웨어를 사용 하는가?” 둘째, “이 액터들이 해결하고 싶은 문제 3가지만 고르라고 하면 무엇인가?” 입니다.

와인버그의 지혜 - 좋은 고객이 최고의 자산이다

어느 국가, 어느 문화를 막론하고 개발자나 테스터에게 가장 귀한 자산은 현명한 고객이다.
그 다음은 무식하고, 그 무식을 숨기려 하지 않는 고객이다.
가장 나쁜 자산은 어리석고 무식하면서도 모든 걸 아는 체하는 고객이다.
그런 사람은 무슨 수를 써서라도 피해라.
규칙은 그에게서 당신을 보호하지 못한다.

사례 - 반복적인 찔러보기-느껴보기-반응하기는 어떤 효과를 보여주나요?

소프트웨어나 서비스 개발 시 ‘반복적으로’, ‘찔러보기-느껴보기-반응하기’를 해가면서 만들 수 있는 방법론을 찾아서 적용하고, 제도를 도입해야 더 성공할 것입니다.

1-4 해봐서 안 되는 이론은 버리고 되는 거 하자

1) 대뇌가 하는 말, 소뇌가 하는 말

소프트웨어를 만들거나 디자인을 하는 복잡 (complex)성을 가진 일들에 생각 하지 않고 습관적인 반응만 보이면서 접근하면 망한다는 것입니다. 이성을 가지고 대뇌가 해야 하는 탐험을 소뇌가 못 하게 하면, 망하지 않고 배겨낼 것이 없기 때문입니다. 사실 이렇게 되는 가장 큰 이유는 현재 자신의 모습을 그대로 받아들이는 ‘자기 인식’이 제대로 갖춰지지 않았기 때문입니다. 이 자기 인식이 제대로 갖춰지지 않으면 학습 능력 (learning capability, LC)이 떨어지게 됩니 다. 그래서 현재의 문제를 제대로 해결할 방법을 제시하지 못하게 됩니다. 변화를 일으키고 싶다면, 생각의 습관을 바꿔야 합니다.

2) 습관적으로 우리가 가져다 쓰려고 하는 것들

피라미드 위계 조직구조

지배와 통제, 지시와 명령, 그 속에서 억압과 착취가 생기는 위계질서하의 피라미드 구조를 가지고는 소프트웨어 개발과 같은 복잡 (complex)한 문제를 해결하기가 어렵습니다. 조직 자체가 실험을 하기에 적합한 구조가 아니기 때문입니다.

우리가 무언가 조직을 만든다고 하면 그 조직의 직무를 ‘신분’으로 착각하고 ‘갑질’이라고 할 만한 일을 하려고 합니다. 그리고 그런 걸 할 수 있게 시스템을 설계합니다. (인사 평가, 성과급 지급 등을 동원하죠.) 이런 거 하지 말라는 것입니다.

워터폴로 몰아치기

피드백이 없는 조직의 업무 방식으로 인해 고객은 이상한 제품을 받게 됩니다. 이로 인해 고객의 불만족이 생겨 프로젝트가 실패할 수 있습니다. 따라서 효율적인 개발과 고객 만족을 위해서는 단계별로 일을 진행하며 피드백을 받아야 합니다.
‘설계-개발-테스트-출시’를 한 번에 하려 하지만 이렇게 일이 되지 않습니다. 소프 트웨어는 끝없이 반복해서 개발하고 출시해야 하기 때문입니다.

한국형 프로젝트들 그리고 백만대군 양성

한국형 프로젝트들이 돌아가는 상황을 보면 커네핀 모델에서 이야기하는 명확(clear)한 일이라고 생각하고 접근하는 일이 많기 때문입니다. 외국에서 잘되는 소프트웨어/서비스가 있으니 우리는 그냥 이를 그대로 베끼면 된다고 생각하는 것이지요.

3) 다르게 일해서 다른 결과를 얻자

로마식 조직구조: DANO의 시작

무언가 지배하는 구조가 아니라, 각자의 영역이 있습니다. 그리고 이 조직을 총괄하는 역할을 누군가가 맡고 있습니다. 모든 일은 ‘합의에 의해 처리’하고, 서로 도와주는 ‘보충의 원리’에 의해 조직을 운영합니다. 이런 조직경영의 원리를 최동석 박사님은 다노 (decentralized autonomous networked organization, DANO)라고 이름 지었습니다. 누군가 착취하고 평가만 하는 사람을 바라보게 만드는 것이 아니라 서로 협력하고 합의하고 도와주는 조직을 만드는 모델을 만든 것입니다.

다노 경영 이론의 구조는 6개의 요소로 돌아갑니다. 1. 비전(vision), 2. 전략, 3. 조직, 4. 성과, 5. 인사, 6. 역량입니다.

여기서 제일 중요한 건 바로 ‘비전’입니다.

비전이란 의사결정에 갈등이 생길 때, 열어보는 것이어야 합니다. 서로 다른 의견을 가질 때, 이 비전을 보고 다시 합의를 하는 겁니다. 바로 ‘중장기적인 목표이자 미래상’입니다.

애자일 방식: 다시 발견한 인간이 일하는 방식

애자일 개발 선언에서 보듯, 애자일이란 것은 ‘무슨 프로세스를 돌리면 일이 잘 끝난다’를 다루는 이야기가 아닙니다. 이것은 ‘원칙’을 ‘선언’한 글입니다. 이 선언된 원칙을 실행하기 위해서는 어떤 방법이든 써도 됩니다.

애자일 방식이 소프 트웨어 개발과 같이 불확실성이 큰 일을 다루기에 맞게 일을 하기 때문에 소프트웨어 프로젝트, 프로덕트 개발에 유리합니다. 굉장히 많은 부분에서 불확실한 것들을 해결해 줘서 상대적으로 성공할 확률이 높습니다.

유명한 개발자이고 애자일 선언에도 참여했던 로버트 마틴은 자신의 책 『클린 애자일』 에서 애자일 방법론이 발견된 상황을 설명하고 있다.

애자일은 이른바 ‘아재들’의 잊힌 고대문명 (Lost technology)이라는 놀라운 사실을 저는 이 책에서 알았습니다.

한국형을 넘어서 정부는 인프라를, 민간은 다양한 시도를

국가는 국가가 잘하는 것을 하면 되고 민간은 민간이 잘하는 일을 하게 하면 됩니다. 국가는 민간이 잘 되게 협력과 보충을 해주고, 민간은 국가가 다채우지 못하는 부분을 자신들의 서비스로 채워줍니다. 이렇게 해야 산업계 전체 생태계가 살아날 수 있습니다.

우리가 소프트웨어를 만드는 일은 복잡(complex)한 일이기 때문에 “찔러보기-느껴보기-반응하기(probe-sense-respond)” 방식으로 일해야 한다고 했습니다. 그렇게 하려면 다음과 같은 것들이 필요합니다.

모든 구성원들이 같은 계급의 인간으로 존중받아야 합니다.
업무 구조는 계층이 있고 문제해결을 위해 모두 지혜를 모아서 의견을 내고 이를 합의해서 진행해야 합니다.
모든 일은 “찔러보기-느껴보기-반응하기(probe-sense-respond)” 단계를 통해서 점진적으로 접근하도록 순서를 지켜갑니다.
하루마다, 매주마다, 수주마다, 한 달마다, 출시 이후에도 꾸준하게 피드 백을 받고, 이를 검토하고, 대응할 수 있는 구조가 살아 움직여야 합니다.
이 모든 일들을 하는 데 있어서 전 조직원들이 심리적 안정감을 느끼고 새로운 시도를 하면서 배울 수 있어야 합니다.

1-5 요약

인간이 배제 되어 있는 상황에서는 어떤 산출물도 효과적으로 생성되기 어렵습니다.

소프트웨어 개발관리의 핵심은 불확실성의 관리입니다. 소프트웨어 개발은 커네핀 모델에서 이야기하는 복잡 (complex)한 문제로 분류되며 이때 할 수 있는 접근 방식은 찔러보기-느껴보기-반응하기입니다.

최고의 고객은 무엇을 원하는지 이해하고, 요구사항을 명확하게 전달하며, 필요할 때는 방향을 수정할 수 있는 고객입니다. 훌륭한 고객이야말로 우리가 확보할수 있는 최고의 자산입니다.

과거의 이론이 잘 안 돌아갔다는 것을 인정했다면, 현실을 반영한 새로운 이론을 도입하는 데 주저하지 말아야 합니다.