최근의 대부분의 IT 트랜드는 통합에 매우 집중이 되어있다. 90대부터 분산 시스템에 대한 관심이 매우 급증하고, 실제로 많은 시스템이 분산 시스템으로 개발이 되어왔다. 과거에 콘솔이나 터미널 형태의 단순한 방식의 접근에서 이제는그야말로 어머어마하게 분산되고, 그 리소스와 자원을 효과적으로 다루기 위해 다시 또 하여금 통합이라는 대 주제의기술들이 쏟아지고 있다. 고도로 발전한 개개의 기술들을 통합시키고 다듬어져 클라우드라는 기술로 재조명 되고 있다.

대부분 이런 새로운 트랜드와 기술들은 소프트웨어 거대 기업에 의해 마케팅이 되거나 주도되어져 온 것이 사실이다.또 한가지 새로운 것들은 전혀 새로운 것이 아니라, 하부 기술의 탄탄한 기반에 의해 쌓아 올려진 것들임을 알 수 있다.

소프트웨어 공학의 함점

대부분의 소프트웨어 업계에서 일하는 독자들은 소프트웨어 공학이라고 들어는 보았을 것이다. 매우 추상화된 학문이기도하고, 그 범위나 학문 자체가 성숙되지 않은 학문이라고 한다. 필자는 이 소프트웨어 공학이 별도의 학문이라기 보다는 다른 학문과 이어져 함께 발전하는 학문이라고 생각한다.

우리나라에서 대학교를 입학하고 컴퓨터 학과에 진학하게 되면 가장 먼저 접하는 학문이 컴퓨터 공학이다. 0,1을사용하는 비트 연산부터 시작하여 이산 수학, 컴퓨터 과학이나 구조, 운영체제, 데이터베이스, 알고리즘, 그리고 프로그래밍 언어 등으로 컴퓨터 공학을 전공하게 된다. 당장 프로그래밍 언어만 잘 이해하고 습득하여도 학교를 졸업하고 먹고 사는데 큰 지장은 없다. 이론과 실무가 다르듯이 이론 없이 실무가 가능하다는 말이다. 이론적인 성숙도가 낮더라도 자격증을 딴다는 것이 어렵지 않은 것이 현실이다.

그렇다면 우리가 왜 학교에서 컴퓨터 학문을 배우는가…? 자고로 이미지 처리를 하기 위한 프로그래밍을 하려고한다면, 컴퓨터가 사용하는 2진수의 비트 연산을 이해하지 않고서는 만들 수 없다. 더 나아가 컴퓨터가 표현할 수있는 색상의 수는 한계가 있다. 자연의 색상인 True Color에 가깝게 표현은 할 수 있지만, 컴퓨터는 절대 TrueColor를 모니터로 표현할 수 없다. 그렇기 때문에 팔레트(Pallete) 원리를 이해하면 좀 더 가까운 True Color에 접근할 수 있다.

우주 과학이나 물리학과 같은 학문도 소프트웨어 공학과 떨어질 수 없는 관계이다. 왜 블랙홀에서는 모든 물리학의 법칙이 깨지고, 블랙홀의 중력은 무한대(∞?)인가에 대한 수수께기를 풀기 위해 많은 가설이 존재하고, 이 가설을 시뮬레이션 하기 위해 프로그래밍 언어와 알고리즘 사용하여 계산하고, 더 빠른 계산 성능을 위해 분산 컴퓨팅분야까지 발전하게 된다.

여기까지의 이야기만 듣다보면 컴퓨터 공학이나 소프트웨어 공학이라는 것은 성능적인 향상을 위한 목적의 학문이라는 착각이 들기도 한다.

본질을 잃어버린 소프트웨어 공학

우선 밝혀둘 것은 필자는 소프트웨어 공학을 논할 만큼 높은 학위가 있는 것도 아니고, 소프트웨어 공학에 푹 빠진사람도 아니다. "소프트웨어 공학의 본질이 무엇이다"라고 정리해야 하는 입장도 아니지만, 본질 자체가 흐트려지고 오해되는 것에 대해 매우 애석하게 생각한다. 'Agile이 우리 회사 문제를 해결해 줄 수 있을까?' 라는 주제의 소프트웨어 공학적인 입장에서 소프트웨어 공학이란 '소프트웨어를 빠르게 개발하기 위한 방법이다' 라는 최종결론에 도달하는 것에 대한 입장에 차이에 대해 이야기 하고 싶다.

우리나라는 몇 년 동안 애자일(Agile) 개발 방법론(개발 프로세스) 에 한 동안 푹 빠져, 애자일 개발 방식이 전지전능하고 실천하면 좋은 개발 방법으로 오해하며 살아왔다. 필자는 개발자의 관점에서 쓴 '애자일에 대한 고찰' 을쓰면서 한 동안 애자일에 대해 많은 고민을 해왔다. 어떻게 실천하는 것이 좋은 것이고, 어떤 애로사항이 있는지에대해서 말이다.

애자일(Agile)과 스크럼(Scrum), 린 소프트웨어(Lean), 그리고 칸반(Kanban)과 같은 툴 등의 방법론적인 관점에서가장 대표적인 두 가지 목적에 도달하기 위한 목표를 가지고 있다.

  1. 빠른 개발과 효율성 증대, 품질 좋은 소프트웨어 납품
  2. 낭비의 제거

그리고 개발 방법을 잘 적용하기 위해서는 '사람', 즉 소프트웨어는 사람과 사람에 의한 것이라는 대 주제로 귀결된다.

바로 필자가 이야기 하려던 것이다. 소프트웨어 공학=개발 프로세스(방법론) 이라는 성립될 수 없는 공식이 성립이 된다는 것이다. 소프트웨어 공학이 소프트웨어를 빠르게 개발하기 위한다는 것이 포커싱이 되는 것은 개발 단계일 때 뿐이다. 애자일 등의 방법론은 개발을 빨리 하기 위한 방법이 맞다. 그래서 도구를 잘 이용해야 한다고 한다. 형상 관리와주기적인 통합과 빌드, 배포, 테스팅. 즉, 절차지향적인 기존의 방법을 미리 조금씩 적용함으로써 큰 사건(?)을 작은 사건으로 쪼갤 수 있으므로, 이를 빠르게 대응하기 위한 비용과 리소스도 줄어들게 된다.

그런데 말이다. 개발 단계를 벗어나면 소프트웨어 공학과 빠른 개발과는 전혀 이치에 맞지 않는 상황이 된다.

분석 단계를 보자. UML(Unified Modeling Language) 을 대신해 DSL(Domain Specific Language) 로만 이야기 해보자. (고객이나 실무자가 UML 을 알 필요는 없기 때문에 UML 은 제외한다.) 분석을 경험해본 독자라면 분석가(또는 아키텍처)의 용어와 고객이 사용하는 용어가 다르다는 것을 익히 알고 있을 것이다. 설령, 용어를 특정 단어라고 이해해도 좋다. 도메인 업무의 깊은 지식을 갖고 있는 고객의 한 문장을 도메인 지식이 앝은 분석가가 모든 의미를이해할 수 없다. 예를 들어, 관공서와의 민간 시스템간의 통신에 사용되는 "전문" 이라는 단어는 도메인 지식이 깊은 고객에게는 전문 송수신 이후에 내부 시스템적으로 변화가 일어나는 모든 속성에 대해 알고 있지만, 분석가에게는 통신 프로토콜과 전문의 스키마, 콜백 방법 에 대한 이해만 있다면, 아키텍처는 설계 단계에서 기간과 비용,인력 등을 잘못 설계할 수 있다. 필자 또한 이러한 고객의 용어를 깊이 이해하지 못하여 실제로 프로젝트 제안서를작성하고 프로젝트 투입 후 돌이킬 수 없는 실수를 한 적이 있다.

또 다른 예로, 소프트웨어 유지 보수 단계를 보자. 소프트웨어가 모두 납품이 되고 품질도 검증이 되어도, 잠깐 사용하려고 개발된 것이 아니다. 적어도 5년 이상 시스템을 운용/운영하기 위해 유지 보수를 하게 된다. 최종 소프트웨어 사용자의 요구 사항이 변할 수 있고, 관련 업종의 법이 변경되어 시스템의 일부분을 고쳐야 하는 경우도 생긴다. 예를 들어, 병원의 예약 시스템이 있다고 가정해보자. 예전에는 외래 환자는 병원을 방문하여 접수만 하면 되었지만, 선택진료제도라는 법이 생겼다. 이제는 외래 환자는 자신이 원하는 의사 선생님에게 진료를 받을 수 있게된 것이다. 물론, 시스템을 당장 바꾸는 것은 아니다. 변경될 법에 대한 내용을 미리 고시하기 때문에 정해진 기간안에만 제도에 맞게 시스템을 변경하여 릴리즈를 하면 된다.

일부만 요약해 보자.

  • 소프트웨어 요구 사항 수집
    고객과 분석가 간의 정확한 목적과 목표를 이해. 고객의 용어를 공통적인 언어(표현)로 표현하기 위해DSL을 사용한다. 요구 사항을 빨리 수집하기 위해 DSL 을 사용하지 않는다.
  • 소프트웨어 설계
    UML 등을 이용하여 설계를 한다. DSL(고객과 분석가 간의 모델)이 소프트웨어적인 언어로 변경되어야 한다. 그래서 UML을 사용한다. 필자의 블로그의 "개발자도 알아야 할 응용 프로그램 모델링1~7회" 까지 살펴보는 것도 좋다.
  • 소프트웨어 개발
    애자일과 같은 개발 방법은 소프트웨어 공학에서 다루는 대부분을 요약하여 빠르고, 높은 품질의 소프트웨어 개발을 지향한다.
  • 소프트웨어 유지 보수이 때부터는 소프트웨어는 항상 심장이 뛰고 숨을 쉬고 있다. 그렇기 때문에 안정성을 확보하는 것이가장 우선이다. 버그가 있는 릴리즈를 엄청난 손해를 끼치게 된다. (실제로 국내 쇼핑몰에서 간간히 발생하는데, 분 단위마다 억대의 손실이 발생한다고 업계 관계자에게 들은 바 있다.) 이제는 운영 프로세스가 도입되는 시점이다. 개발된 소프트웨어, 그리고 소프트웨어를 호스팅하는 하드웨어, 네트워크,스토리지 등 애자일과 같은 개발 프로세스는 여기에 비하면 빙산의 일각이다. 운영 프로세스 중 마이크로소프트의 MOF(Microsoft Operations Framework) 를 참고바란다.

소프트웨어 공학과 소프트웨어 팩토리, 소프트웨어 개발 프로세스는 별개…

이미 언급한 바, 우주/물리학에서 블랙홀의 질량이 무한대(∞) 에 대한 수수께기가 벗겨진다면 우리의 우주적인생각/시점/관념은 전혀 새롭게 바뀔 수 있다. 그리고 우주적인 학문적인 깊이는 더욱 깊어지고, 이로인하여 새로운 우주 시대를 맞이할 수 있다. 우리가 살고 있는 우주의 최초는 빅뱅이 아닐 수도 있고, 우리가 살고 있는 우주가 유일한 우주가 아닌, 다중 우주론일 수 있다. 단지 이것들이 가설로만 존재하는 이유는 아직 수학적으로 증명을 하지 못했기 때문이다.

다른 학문들이 발전하면서 소프트웨어 공학은 발전해 왔다. 특히 소프트웨어 공학이 이야기하는 10가지는 각 단계마다 의사 소통 또는 언어가 틀리기 때문에 어렵다. 고객과 분석가 간의 언어, 아키텍처와 아키텍처간의 언어, 아키텍처를 소프트웨어 개발을 위한 코드로 알게 하는 언어, 소프트웨어 개발 언어가 하드웨어가 알도록 하는 언어,소프트웨어 테스트를 위한 테스팅과 테스터간의 언어 등… 소프트웨어는 공학은 언어를 언어로 바꾸는 학문이기도 하다. 마치 구글 번역기 처럼 빨리 번역된다고 개발 성능이 나아지는 그런 것들과는 거리는 멀다.

소프트웨어를 빨리 개발하기 위해 소프트웨어 팩토리나 소프트웨어 개발 프로세스 등은 이미 많이 널려있다. 소프트웨어 팩토리나 소프트웨어 개발 프로세스는 이미 많은 사람들에 의해 빠른 개발에 필요한 요소임이 증명이되었다. 물론 칼자루를 쥔 사람이 누구냐에 따라서 다르겠지만, 이런 방법들은 현재도 꾸준히 논쟁의 대상이기도하지만, 소프트웨어를 빨리 개발하기 위한 방법들은 지금도 계속 현장에서 검증하여 나온다.

소프트웨어 공학은 그 깊이를 아직 대다수의 사람들은 모른다. 자신의 학문적인 깊이를 잴 수 없으니 공학적 깊이를 잴 수 없는 것이 당연하다. 분명한 것은 소프트웨어 개발 프로세스나 소프트웨어 팩토리, 그리고 다양한 개발 방법들은 소프트웨어 공학에서 하나의 작은 일부이다. 소프트웨어 공학은 계속 발전하고, 이론에 머물러 있는 것들이 많을 것이다. 실제로 개발 프로세스에 대한 것들만 보아도 들어보지도 못한 개발 프로세스나 방법들이 무수히존재한다. 그것을 검증하고 경험하는 것은 우리의 몫이지 공학 자체가 답을 제시해 주지는 않는다.

빛 보다 빠른 어떤 물질을 발견한다면 아인슈타인의 상대성 이론은 엉터리 이론이 될 것이다. 왜냐하면 어쨌든 틀린 이론이 될 것이기 때문이다. 하지만, 상대성 이론이 깨진다고 하여도 학문적으로는 엄청난 업적이자 이를 이해하지 못하면 더 깊은 지식을 이해하기 힘들 수 있다. 마찬가지로, 개발 프로세스가 엉터리이고 빨리 개발 할 수 없는 방법일지라도 그것이 우리가 사용하는 개발 프로세스를 있게 한 일부이고, 학문적인 부분의 하나의 작은 일부분일 것이다. 바꾸어말해, 빨리 개발하기 위해 학문이 존재한다는 것이 아니라는 말을 하고 싶다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요