백세코딩 #소프트웨어 개발 방법론과 DevOps

객체지향의 개념

객체지향이라는 개념은 어느정도 프로그래밍을 한 사람에게 이해가 되는 개념이다.

대부분의 개발자 중에는 객체 중심 분석/모델링(OOA/M)에 대해 믿음이 없는 분들도 많다.

객체중심이라는 개념은 '소프트웨어의 정적구조'에 무게중심을 두고 서술하고 있기 때문에 동적인 구성과 환경을 기반으로 소프트웨어를 개발하는 분들에게는 이 개념은 의미가 작게 느껴질 수 밖에 없다.

그렇다면 소프트웨어 환경에서 '정적'과 '동적' 구조의 차이는 무엇인가?

그것은 데이터의 흐름을 중요시하게 여기는 비즈니스 환경이나 서비스 중심의 환경은 대부분 순간적인 데이터 흐름을 중요시 하게 된다.

그런 환경을 '정적' 환경이라고 하고 이 환경에서는 OOA/M는 매우 효과적으로 발현된다.

하지만, 실시간으로 데이터가 흐르고 게임과 가이 끊임없이 데이터가 변화하는 구조를 동적이라고 볼수 있는데, 이 환경에서는 이러한 OOA/M은 그다지 의미가 없다(하지만 이 환경에서도 규칙적인 부분들이 있고 , 그 아키텍처들은 구분하고 정의하는 것은 연구의 목적으로는 의미가 있다. 하지만 실제 구동하는 데 있어 속도가 더 중요한 환경에서는 이러한 접근법은 의미가 없을 수 있다.)

경험중심개발

객제지향의 원점으로 돌아가서 생각해보자.

OOA/M의 시작은 유스케이스(Use case)이고 그중에서도 가장 중요한 출발점은 행위자(Actor)의 파악이다.

대부분은 행위자가 어떤 행위를 하는 것을 잘 인지하는 것이 그 원점이다.

이렇게 파악하는 이유는 시스템이나 행위자가 어떻게 이벤트를 발생시키는지를 식별하기 위해서이다.

컴퓨터라는 구조는 데이터가 들어오는 이벤트를 받아서 결과를 만들어내는 형태를 가지고 있기 때문이다.

말 그래도, 객제지향의 유스케이스와 액터, 이벤트를 찾는 행위는 컴퓨터로 어떻게 이  흐름을 생각할 것인가를 처음부터 고려하는 것이다.

대부문은 이 작업을 어떻게 디테일하게 만들어내고 이부분에서 흐름의 문제를 개선하는 방법을 더욱 더 집중해야 한다.

하지만, 대부분의 프로그래머는 이 단계를 소홀하게 넘기기 쉽다.

컨설턴트라고 불리는 전문가들이나 경험이 많은 소프트웨어 개발자들은 이 단계에서 매우 많은 시뮬레이션이나 연습을 수행하고 예외 상황들에 대해서 고려한다.

객체지향을 제대로 다루게 되는 것이다.

하지만, 객체지향에 소홀한 사람들은 이러한 단계를 가능한 간소한 상태로 클래스 구조와 같은 정적인 소프트웨어 표현법으로 바로 넘어간다.

문제는 한번 이렇게 정적인 표현을 만들어 내거나 표현하게 되면 대부분의 개발자는 그 생각에 묻히는 경향이 강하다.

기본적으로 복잡한 작업을 한번 수행한 다음에 귀찮아서 건너 뛰는 것도 있고, 유스케이스의 분석 단계에서 빠진 부분이라고 해도 대부분은 실제 구현하면서 해결할 수 있다는 믿음을 가진다.

하지만 그것은 그냥 '귀찮아서' 오판하는 행위 일뿐이다.

어떤 소프트웨어든지 '정적구조'가 한번 등장하면 대부분 그 개념에 빠진다.

그러므로 가능한 소프트웨어를 튼튼하게 만들려면, '정적구조'를 가능한 한 늦게 등장시켜야한다.

유스케이스를 통해서 '이벤트'를 가능한 많이 등장시키고 관심을 갖게 돼야한다.

그리고 종이 상에 필요한 이벤트들을 가능한 많이 나열해야 하고 그것이 거의 완전해지는 순간까지 파고들어야 한다.

소프트웨어가 제대로 만들어지는 순간은 필요한 이벤트들이 모두 나열되었을 때에 성공적으로 만들어진다.

나머지는 그것들을 재조합하는 과정이다.

물론, 그 재조합하는 과정에서 '성능'과 '속도'라는 중요한 허들이 있다.

그렇지만, 제약사항이 존재하는 분야는 생각보다 소수이고, 그 분야에 대응하는 경험과 좋은 모델은 좀 더 다른방법으로 집중해야 한다.

바로 아키텍처적인 접근방법으로 초기부터 유스케이스와 아키텍처를 동시에 그려나가는 방법이다.

이 방법은 이벤트의 비기능적인 성능부분들과 이벤트의 발생빈도와 시스템의 접근횟수, 속도에 대해서 민감하게 반응한다.

하지만 대부분의 소프트웨어 개발자들은 가장 중요한 이러한 작업을 초기에 제대로 수행하지 못하고 빠르게 '클래스 구조'를 찾거나, 자기가 아는 '플랫폼'의 아키턱처나 클래스 구조에 빠르게 대입한다.

원래 소프트웨어가 가져야 할 특성을 해당 플랫폼이나 프레임워크에 가두어 실제 문제점은 온데간데없이 사라지고 프레임워크의 특성만 남는 경우도 많다.

결론적으로 이야기하면 객제지향을 제대로 실현하려면 도메인 모델을 제대로 바라보는 연습과 수련밖에는 방법이 없다.

소프트웨어 개발이 '경험' 중심인 이유가 바로 이것 때문이다.

소프트웨어 복잡도에 신경

맥카비 복잡도 지수

소프트웨어 개발과 방법론

아주 괜찮은 방법이 시도되고 그 방법이 성공적으로 시장에서 인정되어을 때 이 방법을 소프트웨어 개발 현장에서 시도해보는 사람들이 열성적으로 생겨나면서 해당 방법론이 최고라고 평가를 받는 경우. 하지만 결론적으로 해결방법의 은빛탄환은 존재하지 않는다.

적당한 환경에서 적당하게 그 문제를 풀기에 적합한 방법이 있을 뿐이다.

다만, 한가지 이 러한 도전과 결과들에 대해서 분석하면서 얻어진 것들 있다.

매우 복잡하다고 생각되는 시스템이나 소프트웨어, 서비스를 디자인 할 대에는 매우 성급하게 결론을 두는 것이 실패의 가장 큰 원인이다.

아무리 경험이 풍푸한 개발자들이 모여서 디자인을 한다고 해도 초기에 추정으로 설정된 기능이나 요구사항에 의해서 시스템이 제한되는 경우가 있다.

하지만, 이렇게 만들어진 소프트웨어는 분명 다음 단계의 개발이 진행될때 매우큰 허들을 만들게 되고 실패의 주된 원인이 된다.

'방법론'은 이러한 경우에 크게 문제를 일으킨다.

소프트웨어의 개발 프로세스는 전통적인 워크플로우를 하나의 관점으로 보도록 집중하게 한다.

그러한 제한은 새로운 지식이나 가설 등을 적용할 수 있는 여유를 가지고 있지 않다.

결국, 잘못된 선택을 하거나 잘못된 방향으로 진행되었을 때 이러한 문제를 해결할 수 없는 경우가 발생한다.

하지만, 때론 방법론은 이러한 문제도 해결하는 해결책을 제시하기도 한다.

그것은 해당 문제를 가능한 여러 개로 쪼개고 여러 단계로 반복하도록 하는 것이다.

다만, 방법론을 사용하면서 다음의 큰 문제를 언제나 주시하자.

방법론은 제도나 논리를 고정하게 한다.

그러한 문제에 발생하는 압력을 언제나 피할 수 있는 유연성을 발휘해야 한다는 것이다.

'소프트웨어 개발에서 형식에 얽매이는 것이야 말로 삽질이다.'

소프트웨어 개발과 잉여

소프트웨어 개발자들은 '형상관리' 항목에서 현재 발생 중인 다른 사람들의 요구사항 리스트나 처리 프로세스에 대해서 볼 수있는 시간적인 여유를 주어야 한다.

그것은 내가 경험한 좋은 해결책을 이야기 할 수 있게 하는 기회를 제공하고 그 문제를 처음 맞닥뜨린 동료에게 아주 좋은 조언자로서 해결책을 제시할 수 있는 기회를 만든다.

또한 이러한 관점으로 현재 존재하는 데이터들에 대해서도 무의미하지만, 다양한 방법으로 시각화하면서 얻어지는 우연한 기회에 만들어지는 좋은 결과물들을 얻어낼 수 있다.

마찬가지로 내가 만드는 소프트웨어를 사용하는 사용자들이 해당 정보시스템에서 제공되는 데이터를을 재배치 하여 얻을 수 있는 우연한 기능들에 대해서도 관심을 가져야 한다.

소프트웨어 품질

소프트웨어 품질을 높이기 위한 최종적인 결론

'사람이 코딩하면 버그가 생긴다'

그렇다면 어떤 소프트웨어를 만드는데 있어서 가장 오류를 적게 만드는 이상적인 방법은 바로 사람의 개입을 최소화하는 것으로 생각한다.

개발자는 오류를 만들어낸다.

-소프트웨어 언어나 정규언어, 유한 오토마타 등의  세계는 형식언어를 어떻게 정의하냐에 따라 오류와 품질이 결정된다고 생각하기도 한다.

우리의 소프트웨어 프로그래밍도 이러한 형식 언어의 세계의 지배하에 있다고 보는 것이 맞다.

우선 프로그래머 대부분은 '현실'을 시스템에 '시뮬레이션'하는 것을 평생의 업으로 살아가는 것이라고 정의하자.

그럼 형식언어는 '구조, 범위 등이 명확히 규정된 언어, 자연 어어의 문법구조를 수학적 측면에서 형식화 한것으로 자연언어보다 훨씬 간단한 구조의 인공언어'라고 설명된다.

이러한 내용을 간단하게 설명하면 개발자들이 문제를 인식하고 소프트웨어를 개발하면서 만나는 구조적인 부분인 패턴, 중복, 라이브러리, 컴포넌트, 서비스 이 모든 것을 단순화한 함수로 설명하려 노력하는 것이 소프트웨어 개발활동, 형식언어로 만들어가는 활동이라 할수 있겠다.

어떤 도메인이나 특정 목적에 맞는 시스템을 디자인하고 그 시스템을 구현하고 설명하는 '형식언어'를 만드는 것이 프로그래머의 일이라고 생각한다.

그래서 프로그래머들은 처음에는 범용적인 프로그래밍 언어를 사용해 해당 도메인을 시뮬레이션하다가 해당 도메인에 맞는 구조를 발견하고 이를 구조화해서 대응되는 기능과 환경들을 서술한다.

궁긍적으로는 해당 도메인을 형식언어 수준으로 설명 가능한 세계를 창조하고 그것을 표현하는 것이 프로그래머가 해당 도메인을 구현하는 가장 궁극적인 방법이라고 생각한다.

어떻게 보면 그것이 가장 '고품질의 소프트웨어'을 얻을 수 있는 방법이라고 정의할 수 있지 않을까?

가장 궁극적인 시뮬레이션은 그 세계를 표현하는 언어를 만들어내는 것이라고 생각한다.

가장 고품질이 요구되는 소프트웨어 개발분야

실제 이런식의 소프트웨어 개발이 이루어지는 분야가 있다.

대표적인 것이 원자력, 군용기, 항공기, 선박등의 분야가 이에 속한다.

일반적인 비행기 항공엔진 제어 소프트웨어로 약 80만~110만 라인의 제품이 만들어진다.

이때 가장 중요한 것은 '이 소프트웨어가 제대로 동작하는가?'를 증명하는 것이다.

1. 요구사항을 어떻게 표현하는가?

2. 분기/조건 등의 소프트웨어 수행 조건이 제대로 구현됐는가?

중요한 것은 이렇게 어떻게 객관적으로 증명하고 보여주는 가다.

또한 항공기 같은 작은 오류가 큰 사고로 연결될 수 있는 경우나 미사일처럼 수십억 원을 호가하는 제품은 그 품질을 증명하는 방법 또한 매우 엄격하고 신중하다.

소프트웨어 아키텍처의 귀중한 실패경험

논리적으로 동작 가능한 소프트웨어를 만드는 것과 실제 사용이 가능한 소프트웨어를 만들어 서비스하는 것은 전혀 다르다.

소프트웨어 아킥텍처에게 있어 가장 중요한 품질속성을 어떻게 도출하고 이를 어떻게 괸리하느냐가 이 문제의 핵심을 차지한다.

대부분의 고품질 소프트웨어를 만드는 프로세스에는 아예 이 부분이 비용과 패키지, 프로세스의 모든 부분에 반영돼 있다.

결론적으로 비용투자 없는 고품질이란 존재하지 않는다고 봐두 무방하다.

소프트웨어 개발자들이 일반적으로 어려워하는 것들

1. 소프트웨어를 솔루션 형태의 디자인으로 만드는 것은 정말 어렵다.

-개발자들은 솔루션을 만들고 그것을 디자인하고 설계, 구현한다는 것은 정말 어려운 것이라고 인지하기 시작함.

2. 테스트 케이스를 작성한다는 것은 정말 어렵다.

- 수많은 사용자의 환경을 인지하고 그것에 대응하는 완벽한 테스트는 불가능하다는 것을  인지함.

3. 개발관련 문서작성 또한 매우 어려운 것

- 개발자들 간에 상호소통하기 위한 문서작성과 다이어그램, 모델을 만다는 것은 정말 어려운 일이다.

- 그것을 표준이나 변화해가는 기술적인 요청과 반영내용을 모두 담는다는 것은 정말 어려운 일이라고 인지함.

4. 개발자 자신이 동의하지 않는 기능 구현을 허구헌날 해야한다는것

-동의하지 않는 쓸모없다고 생각하는 기능 구현에 매달리는 현실에 대해서 이제는 약간 무덤덤하게 대응할 수 있는 개발자들의 마음가짐은 정말 관대하게 변화됨.

5. 다름사람이 작성한 코드를 다루는 것이 매우 당연하다는것.

- 다른 사람의 코드와 프레임워크에 가두어진 상태로 프로그래밍을 해야하는 상황에 대해서 두려워한다.

6. 고객과 같이 비전문가와 커뮤니케이션 해야 한다는 것

7. 업무완료에 필요한 시간예측은 필수가 되었다는 것

- 기능 단위의 시간예측과 일정에 대해서 감이 필요하다는 것은 실제 현업에 나와서만 가능하다는 것

8. 업무의 우선순위와 작업 할당이 애매하다는 것.

- 누가결정? 그 순서에 대해 아무도 모른다.

9. 이름을 만들고 이름과 의미를 부여한다는 것은 매우 어렵다는 것

- 그냥 X, Y, I, j k를 부여하면 안된다고 하는데 생각 이상으로 붙여야할 이름과 규칙들이 너무 많다.

소프트웨어 개발이 어려워지고 두려워지는 개발자들보다 더 어려운 것도 있다는 사실을 소프트웨어 개발자들은 경험으로 터득한다.

그리고 해결책도 없다는 점이다.

소프트웨어 개발자들이 피하고 싶은 사실

1. 무능력한 경영진의 삽질

2. 멍청한 동료 개발자의 어설픈 코드

3. 특정 기술이 무슨 이유에서 쓰이는지도 모르고 강제로 배우거나 사용해야 하는 것

4. 재미 있어서 시작한 개발일이 정말 반복적인 작업에 의해서 재미없어졌을 때

5. 이제 쏟아지는 버그를 만나게 되었을 때

가장 두려운 상황의 최고는 '고객과 대화를 나누는것이 가장 두렵다'과 동료와의 커뮤니케이션이다.

이러한 고객과 동료 사이에 있는 개발자는 개발하는 것이 행복하지 않다라고 느껴진다.

DevOps는 개발자가 행복하게 소프트웨어를 개발할 수 있는 환경을 만드는 것이 목표이다.

과거의 개발방법론이나 문화, 운동들이 대부분 '소프트웨어 품질'을 위해서 개개인의 시간과 능력 차이를 무시하고 진행되었다면 DevOps는 그 우선순위의 가장 높은 개념으로 개발자의 행복을 우선 순위 위에 둔다.

결론적으로 개발자가 행복하다면 자연스럽게 소프트웨어의 품질은 올라간다는 개념이다.

DevOps는 기본적으로 개발자들이 신뢰해야 형성된다.

DevOps는 소프트웨어 개발과 운영, 서비스의 효울적인 환경을 만들고자 노력하는 개발문화로써 간단하게 줄여서 설명하자면 '소비자, 사용자들읭 서비스 요구사항을 가장 빠르고 단순화하여 대응 할 수 있는 신속한 서비스 지원형태, 그리고 그것을 지원하고 유지해주는 소프트웨어 개발 문화'라고 이야기할 수 있다.

Development/Operations를 합친 말이다.

DevOps는 단순화, 신속함이라는 서비스 형태를 지향

그리고 그것을 지원하고 유지해주는 소프트웨어 개발문화를 지향하고 있다.

DevOps 장점

1. 최소인원으로 개발과 운영이 가능한 환경을 지향한다.

2. 서비스의 배포와 운영이 자유롭고 서비스가 매우 신속하고 빠르게 운영된다.

3. 배포가 자동화되며 그에 따라 고품질 서비스를 지향한다.

DevOps가 가동되고 개발 조직의 문화가 되려면 2가지 필수

1. 소프트웨어를 잘 만들어내는 개발자.

2. 잘 동작하도록 운영하는 운영자

두가지 조건을 만족시키기 위한 기본적인 환경적인 구성이 필요

소프트웨어 품질을 관리하는 제대로된 품질관리 조직 있어야 한다.

개발 조직이 빠르게 소프트웨어를 개발, 빌드, 테스트, 배포, 운영하게 할 수 있는 사이클을 신속하게 진행할 수 있는 개발환경을 갖추고 있어야 한다.

업무프로세스를 정의하고 각 조직 간의 역할을 조율하는 프로세스들이 매우 자연스럽게 자동화되어지고 효율적으로 운영되고 있어야 한다.

'소프트웨어를 잘 만들어내느 개발자'와 '잘 동작하도록 운영하는 운용자'가 만들어지게 되면 그 역할과 방법론이 효율적으로 가동되는 DevOps가 된다.

DevOps 원칙

단기간에 투입되어 얻어지는 효과가 아니다.

1. 개발자들은 기능 개발과 결함 수정 등의 변화를 얼마나 자주 일으키고 있는지 체크하고 이를 관리하거나, 관리할 수 있는 포인트를 개발자에게 제공하고 있는가? 하는 측면이 가장 먼저

2. 운영자가 실제 서비스의 안전성과 성능의 향상을 위하여 취해지는 시스템 구조적인 변화에 대해서 얼마나 두려워하고 있느며, 이를 얼마나 수치화하여 관리하고 있는지, 그리고 그 선택을 할 수 있는지가 DevOps에 가장 중요한 측면이기도하다.

3. 이러한 개발집단과 운영집단에서 선택과 운영, 개발의 우선순위 등을 고르고 선택할 수 있는 '권한과 책임'이 주어지고 있느냐

4. 큰 조직, 큰 기업, 큰 프로세스의 운영 시에는 이러한 DevOps와 같은 콘셉트는 운영하기 매우 어렵다.

그러므로 개발과 운영환경의 구분과 절차, 권한과 릴리즈절자, 규칙 등에 대해서 얼마나 세분화하고 있는지 그리고 일에 대해서 얼마나 작은 규모로 산정하고 산출하고 있는지에 대해서도 정의되어야 한다.

DevOps구현하고 싶지만 착각하고 있는 개발자 조직의 사례

1.사용하지도 않는 기능을 도출하고 이를 위하여 시간과 비용을 낭비하는경우

2. 개발후 버그를 찾고자 테스트를 하고 있다고 프로세스를 정형화하는 일이다.

실제 DevOps를 지향하는 개발조직은 내부적으로 개발 단계에서 충분하게 품질을 고려하고 디자인되고 개발을 진행하려 노력한다.

3.  예측을 위한 투자를 많이 하고 있는가? 라는 질문에 소극적인 경우

4. 정말 중요한 지표에 집중해야 하는데 소프트웨어 공학을 잘못 받아들여 너무 많은 지표를 도출하기 위하여 삽질하는 경우가 대표적인 착각된 개발조직의 경우

DevOps을 좁게 보는 진정한 장점

DevOps는 '잦은 배포'를 수행하면서 잦은 릴리즈를 수행하고 잦은 릴리즈를 통해서 위험을 하향균등화시키는 것이 주목적이라고 작게 정의할 수 있다.

그래서 애자일과도 잘 맞는다.

DevOps를 구현하는데 있어서는 최소한의 필요충분 요건이 필요하다.

1. 잦은 개발과 버그 픽스가 가능한 개발자 환경을 구현하라.

2. 공유 소스 코드 버전 관리시스템도 없다면 이러한 환경을 구성한다는 것은 거의 불가능하지 않겠는가?

3. 빌드, 테스트, 배포 단계를 자동화하려고 얼마나 노력하는가?

4. 수작업의 실수와 반복을 최소화하기 위해서 어떻게 노력하는가?

5. 개발조직과 운영조직의 협업을 위한 빈번한 커뮤니케이션 비용을 지불하고 있는가?

필요충분조건을 만족한다면 개발조직은 다음과 같은 최소한의 목표를 이루고자 준비한다고 볼수 있다.

1. 개발과 품질관리, 운영을 교집합으로 운영하려는 방법을 터득하였고 그것을 개발조직에 내재화 하고자 노력중이다.

2. 신뢰성, 보안성, 개발과 배포 사이클을 보다 더 빠르게 개선하기 위해서 배포, 테스트, 세부기능 개발, 릴리즈 관리를 목표로  조직이 운영중이다.

3. 툴이아니라, 문화와 일하는 방법에 대한 경험을 더 우선으로 하고 있다.

DevOps 가장 중요한 원칙

1. 주요기능에 집중하고 있는가?

2. 품질을 내재화하고자 노력하고 있는가?

3. 개발에 필요한 지식을 창출하기 위해서 과학적으로 접근하고 있는가?

4. 완벽한 명세서를 만들기 위한 비용보다 명쾌한 현업을 중시하여 커뮤니케이션 비용을 지출하고 있는가?

5. 가능한 빨리 개발하기 위해서 시도하고 있는가?

6. 사람을 존중하는 개발자 문화를 만들고 있는가?

7. 최적화를 위한 방안을 고안하는데 회의나 토론을 아까워하지 않고 있으며, 그것에 대해서 투자를 아낌없이 하고 있는가?

DevOps는 근본적으로 소프트웨어 개발시에 발생하는 비효율적인 환경을 제거하는것이 목표이다.

수동빌드와 수동배포를 제거하고 낮은 수준의 테스트나 저수준의 커뮤니케이션을 회파하는 것이 그 주요한 목표다.

DevOps를 실현할 수있는 가장 중요한 기본 원칙은'소프트웨어 품질에 대해서 조직에 속한 사람들이 모두 개선을 하기 위한 의지를 갖는것이다.'

DevOps는 '무리한 야근'이나 '무리한 목표' 따위는 존재하지 않게 된다.

출처-백세코딩