긍정적 사고, 음식의 절제, 규칙적인 운동

12가지 필수적인 소프트웨어 개발 원칙과 개념

업계에 처음 발을 들여놓는 젊은 개발자들은 한꺼번에 많은 원칙과 개념에 대한 이야기를 듣게 된다. 관리자로 올라서는 경력 개발자는 그동안 피해 왔지만, 기술적인 측면에 폭넓은 영향을 미치는 비즈니스 개념에 대한 이야기를 듣게 된다.

다음은 지난 20년 동안 소프트웨어, 그리고 소프트웨어 비즈니스에 있어 가장 중요한 12가지 개념이다.

1. 권한 없는 책임

경력이 어느 정도 된다면 권한 없는 책임을 접해봤을 것이다.

극단적인 사례를 들면 경비원에게 분기별 수익 책임을 지우는 것이다. 경비원이 아무리 노력해도 회사의 수익성을 높일 수는 없다. 경비원이 영업 회의에 참석한다 해도 신참 영업 사원이 전화를 더 많이 걸도록 유도할 수는 없다. 영업 사원을 움직일 영향력이 없기 때문이다. 마케팅 회의에 참석해봤자 마케팅 부서에서 새로운 캠페인을 구상하도록 이끌 수도 없다.

물론 극단적인 예다. 그러나 짊어지는 책임과 실제 행사할 수 있는 영향력 사이의 격차는 그 정도가 얼만큼이든 스트레스의 원천이다. 권한 없는 책임은 조직적인 기능 장애를 나타내는 징후이며(모든 조직에 어느 정도는 있음), 해결책은 권한을 높이거나 책임을 낮추는 것밖에 없다.

2. 반복하지 말 것

 “반복하지 말 것” 원칙은 시스템에서 표현은 명확하게, 한 번만 해야 한다는 것이다. 코드 한 블록을 잘라내서 여러 곳에 붙여 넣을 경우 그 설계에는 결함이 발생한다. 그 결함을 가장 먼저 수정해야 한다.

이 원칙을 위반할 경우 시간을 낭비할 뿐만 아니라 유지보수 문제도 발생한다. 여러 지점에서 잘라내서 붙여넣기한 버그를 모두 찾아 수정해야 한다. 또한 보안 결함이 복제되는 경우를 상상해 보라.

이 문제를 수정하는 방법은 전체 아키텍처를 수정하는 것부터 코드 생성기, 종속성 주입에 이르기까지 많지만 어떤 방법을 사용하든 일단 수정해야 한다!

3. 필요할 일이 없다

앞으로 필요할 것 같아서가 아니라, 지금 필요한 기능을 구현하라. 앞으로 필요할 것 같다면 십중팔구 필요할 일이 없다. 나중에 정말 필요해지면 그때 가서 넣으면 된다.

모듈을 설계하면서 그 모듈이 이번 릴리스와 앞으로의 릴리스에서 해야 할 모든 작업을 미리 생각하고 반영하려 한다면 앞으로 일어나지 않을지도 모르는 기능까지 지원하는 쓸데없이 복잡한 소프트웨어를 만들게 된다.

미래를 예측하는 것보다 현실을 이해하는 편이 훨씬 더 정확하다. 현재에 집중하라.

4. 최소 실행 가능 제품

새로운 무언가를 만들 때 최선은 *할 수 있는* 모든 일을 시원찮게 하는 것보다 정말 잘 할 수 있는 최소한의 일을 하도록 하는 것이다. 이것을 최소 실행 가능 제품(Minimum Viable Product, MVP)이라고 한다.

MVP를 하면 사용자나 고객에게 유용성을 시연하기가 더 쉬워진다. 또한 잘못될 경우 고쳐야 할 부분도 더 적고 실패할 경우 잃을 투자도 더 적다.

5. 좁고 깊게

이 개념은 MVP와 관련된다. 모든 사람에게 모든 것을 줄 수는 없다.

제품이나 기업이 더 많은 일을 하려고 노력할수록 잘 할 수 있는 가능성은 낮아지고 비용과 복잡성은 높아진다. 넓고 얕은 것은 바람직하지 않다.

집중의 문제다. 규모가 큰 조직이나 성숙한 소프트웨어는 “플랫폼”과 사업부를 만들어 더 많은 리소스를 적용할 수 있지만 작은 회사는 한꺼번에 너무 많은 것을 하면 안 된다.

그러나 대규모 조직에도 “좁고 깊게” 원칙은 필요하다. 조직 또는 플랫폼의 각 부분에 대한 원칙으로 두어야 한다. 개별적인 폭이 모여 넓게 될 수는 있지만 각각의 요소는 깊어야 한다.

6a. 최소 비용(운영의 탁월성)

6b. 최고의 제품(제품 리더십)

6c. 최고의 토털 솔루션(고객 친밀성)

 “최고의” 또는 가장 효과적인 조직은 이 세 가지 전략 중 하나를 추구하는 조직이다. 결과적으로 이러한 조직은 가장 비용이 낮은 조직, 최고의 조직, 또는 최고의 서비스를 제공하는 조직이다.

가장 낮은 비용에 초점을 맞출 경우 그 분야에서 최고의 제품이 될 수 있는 최신 기능 일부를 구현하지 못하게 된다.

최고의 서비스(고객 친밀)를 제공하는 데 초점을 맞출 경우 일반적으로 제품이 여러 방향으로 분산되어 각 고객에 따라 대폭 맞춤 제작된다. 이 경우 혁신과 사용 편의성 측면에서 대가를 치르게 된다.

이 목표 중 규모의 확장이 용이한 것은 두 개뿐이다. 가장 낮은 비용 또는 최고의 제품이다. 원하는 검색 결과를 얻지 못할 때 구글 고객 서비스에 전화를 걸 수 없는 이유가 여기에 있다.

7. 테스트 먼저

현대 IDE에서는 테스트를 가장 먼저 해야 한다. 이는 단위 테스트를 먼저 작성한 다음 여기서 클래스 등을 생성해야 함을 의미한다. 결과적으로 테스트가 용이한 소프트웨어가 되므로 더 높은 품질의 소프트웨어가 만들어진다. 또한 계약에 의한 설계와 같은 다른 설계 원칙을 따르도록 유도하는 효과도 있다.

8. 계약에 의한 설계

각 루틴에 대해 그 루틴이 어떤 작업을 하고 그 작업을 위해 무엇이 필요한지를 알아야 한다. 방법은 계약에 의한 설계(Design by Contract)다. 여기서 계약은 소프트웨어의 각 요소를 위한 형식적이고 간결하며 확인 가능한 인터페이스 사양을 말한다. 이 접근 방법을 사용하면 부작용, 전역 변수 및 기타 여러 가지 잘못된 것들을 피할 수 있다.

9. 경합 조건에 주의

일반적으로 경합 조건은 계약에 의한 설계의 다중 쓰레드 위반을 의미한다.

가장 단순한 형태로 보자. 두 개의 쓰레드가 동일한 변수를 변경할 때 한 쓰레드가 먼저 한다면 문제 없다. 그러나 두 번째 쓰레드가 변수를 먼저 변경하는 경우 오류가 발생하고 이것이 경합 조건이다.

이러한 종류의 설계 결함을 탐지하는 것이 불가능할 때도 있다. 간헐적이며 부하가 큰 경우에만 발생하는 경우가 많으므로 단위 테스트로 포착할 수 없다. 고도의 방어적 설계와 쓰레드 간 협업을 피하는 것이 경합 조건을 방지하기 위한 좋은 방법이다. 그러나 메시징 및 이벤트 지향 소프트웨어에서도 다른 버전의 경합 조건이 발생할 가능성은 있다(다만 확률이 낮을 뿐임). 동시성은 어렵다.

10. 콘웨이의 법칙

콘웨이의 법칙(Conway's Law)이란 팀의 커뮤니케이션 구조를 반영하는 소프트웨어를 개발할 수밖에 없다는 법칙이다. 바꿔 말하면 팀의 근본적인 구조를 바꾸지 않고서는(바꾸기는 무척 어려움) 소프트웨어의 근본적인 구조를 바꿀 수 없다.

11. 빠른 실패

 “빠른 실패(Fail Fast)” 원칙은 실리콘 밸리에서 인기 있지만 어디에 적용해도 좋다. 기본적인 개념은 오류가 발생할 경우 소프트웨어는 대놓고, 거침없이 그 오류를 드러내야 한다는 것이다.

아마추어 프로그래머는 모든 변수에서 null을 확인하고, null이 될 수 없는 경우에도 이를 0이나 빈 문자열 등으로 대체한다. 그런 다음 불가능하고 잘못된 상황이 발생했는데도 코드를 계속 실행시킨다. 최고의 개발자는 소프트웨어가 null 포인터 예외를 뱉거나 실제 오류 자체를 내뱉도록 한다.

프로젝트 관리에서 빠른 실패란 존재할 수 있는 정치적 또는 기술적 장벽을 최대한 조기에 찾아내는 것을 의미한다.

비즈니스에서 빠른 실패란 궁극적인 실패를 향해 또는 이른바 ‘라면 수익’을 향해 천천히 투자하기보다 상품이나 비즈니스를 입증하거나 반증하는 대담한 계획을 추진하는 것을 의미한다.

12. 맨먼스 미신

프로젝트 종반에 인력을 추가하면 프로젝트는 더 늦어진다. 고전 ‘맨먼스 미신(The Mythical Man-Month)’은 40년도 넘은 과거의 책임에도 오늘날 소프트웨어 엔지니어링의 많은 오류를 설명한다.

이 용어는 “언제 끝나요?”라는 질문에 냉소적으로 답하는 데도 사용된다. 내 일정은 나도 모른다. 다른 일이 없었다면 신비한 3인일(man-days) 내에 이미 마쳤겠지만, 회의가 6번 더 남았고 그 회의에서도 누군가는 똑 같은 질문을 던질 것이다.

원문보기: 

https://www.infoworld.com/article/3233866/application-development/12-essential-software-development-principles-and-concepts.html

...

경영은 다른 사람들을 통해 목표를 달성하는 기술이다.

경영자는 충분치 않은 자본과 지식, 인적자원을 갖고

일할 수밖에 없다. 따라서

함께 일하는 사람들을 발전시키는 것은 경영자의 중요한 임무다.

- 프라이스 라인 창업자 제이 워커 회장 

경영과 리더십 모두 사람에 관한 일입니다.

내가 스스로 하는 것이 아니라 다른 사람의 마음을 사서

그들이 최고의 성과를 내도록 하는 것이 곧 경영이요,

리더십의 요체입니다.

직원 최우선의 원칙, 그 이유가 여기에 있습니다.

...

'대답은 빨리'를 

기본 원칙으로 삼읍시다. 

악기를 두드리면 바로 소리가 나는 것처럼, 

민첩한 반응을 하도록 평소에 자신을 단련해 

나갑시다. '지금 말씀드리기가...' 하며 대답을 

회피하는 사람들이 있습니다. 꿀 먹은 벙어리가

되어 상대를 답답하게 만드는 사람도 있습니다. 

이렇게 하면 기회는 날아가 버릴지도 모릅니다. 

모든 일에 있어서 행운은 절묘한 타이밍과 

아주 밀접한 관계를 맺고 있습니다. 

- 마쓰우라 야타로의《일의 기본 생활의 기본 100》중에서 - 

* 때로는 신중한 대답도 필요합니다.

그러나 신중함이 길어지면 대답이 늦어집니다.

평소 모든 일에 답을 준비하고 사는 것이 좋습니다.

답이 준비되어 있지 않으면 모처럼 찾아온

절호의 기회를 잃을 수도 있습니다. 

빠른 대답이 답입니다.

.

나는 반대 의무라는 원칙을 모든 신입사원과 공유한다.
가장 직급이 낮은 사람이
최상급자 의견에 동의하지 않는 것을 의미한다.
상급자에게 이게 당신의 임무고 가치라고 들었는데,
일이 제대로 되고 있지 않다고 할 수 있는 사람들을 뽑는다.
- 빅터 호 (미국 핀테크 회사 파이브 스타즈 회장)

상사의 잘못된 의견에 반대를 표명할 수 있는 것은
권리를 넘어 의무가 되어야 합니다.
매킨지에서는 모든 컨설턴트들에게
상사의 의견이 잘못되었거나 고객의 이익에 반한다고 생각할 때
반대의견을 제시해야할 의무를 부여합니다.
누구나 자유롭게 발언을 해도 불이익을 당하지 않는다는
심리적 안전감이 필요합니다.

.

인간은 아무리 이기적이라 해도
그의 본성에는 특정 원칙이 존재하고 있어
타인의 행운에 관심을 가지고
타인에게 행복을 안겨주고 싶어한다.
비록 자신은 타인이 기뻐하는 모습을 보는 것 외에는
아무것도 얻지 못한다 해도 말이다.
- 아담 스미스, ‘국부론’에서

우리는 너무나 당연하게
‘인간은 이기적이다’는 명제를 받아들여 왔습니다.
그러나 최근의 다양한 실험과 현실의 사례 속에서
우리 속에 이타성이 크게 존재한다는 것을 발견하고 있습니다.
남을 먼저 생각하는 것이 결국은 나를 위한 것이 됩니다.

.

원칙과 융통성은 함께 가야한다.
원칙이 뼈대라면 융통성은 근육이다.
뼈는 혼자서는 못 움직이고, 근육이 움직여야 함께 움직인다.
그러나 근육은
 뼈 자체의 방향과 한계를 벗어나서 움직일 수는 없다.
근육이 뼈의 원래 각도보다 더 큰 움직임을 요구하면
 부러지게 마련이다.
- 김낙회 제일기획 전 사장, ‘결단이 필요한 순간’에서

매출과 핵심가치, 단기 수익과 장기 성장, 이익과 원칙,
유형과 무형, 변해야 할 것과 변하지 말아야 할 것 등
 양립하기 어려운 가치 중 하나를 택하는 것은
 비교적 쉬운 일입니다. 그러나
‘or’가 아닌 ‘and’를 지켜낼 때
 비로소 위대함의 경지에 올라설 수 있습니다.