Highly Required

소프트웨어는 관리되어야 한다

Table of Contents

#1 - 이야기를 시작하며

이 이야기를 적기 시작한 이유는 여러 이야기를 적다 보니 기초가 되는 이야기를 설명할 필요가 생겼기 때문이다. 사실 쉬운 내용이 아니니 꼼꼼하게 적어야겠지만, 다음 이야기들을 하는 것이 목적이고 적다 보니 너무 양이 많아서 일부를 나누어 우선 올린다.

소프트웨어 엔지니어의 일을 어떻게 정의할 수 있는가? 가장 기본을 이야기하면 우리는 소프트웨어를 만든다. 이 이야기에 더해 몇 가지 이야기를 적어두고자 한다.

  1. 우리는 소프트웨어를 만든다.
  2. 소프트웨어는 관리되어야 한다.

#2 - 우리는 소프트웨어를 만든다.

소프트웨어의 정의를 간단하게 하고 넘어가자. 소프트웨어는 단순히 코드나 프로그램 혹은 그 모음이 아니다. 소프트웨어는 동작의 단위로 코드뿐 아니라 다음을 포함한다.

  1. 코드의 해석결과인 실행파일(필요하다면 소스코드)
    1. 스크립트 언어 기반인 경우 스크립트 언어를 위한 런타임과 동작환경
  2. 프로그램이 동작하기 위해서 필요한 디지털 리소스(이미지, 문서, 그 외의 다양한 데이터)
  3. 설치와 운영을 필요한 문서
  4. 계약(사용권, 서비스 약관 등)
  5. 필요에 따라 위의 모든 사항이 담긴 광학디스크와 같은 매체
  6. 하드웨어 키 같은 다양한 부가적인 요소들

그리고 이를 위해서는 다음과 같은 것들이 일반적으로 필요하다.

  1. 소프트웨어의 목적과 목표를 포함한 기획 문서
  2. 프로그램을 만들기 위한 소스코드
  3. 프로그램을 빌드하기 위한 스크립트 혹은 지침서
  4. 프로그램에 사용되는 이미지를 위한 이미지 소스
  5. 외부 프로그램 사용 계약
  6. 이를 테스트하기 위한 QA 시나리오
  7. 기타 등등

각각의 조직이 프로그램이나 코드를 공급할 때 제공되는 제품의 형태는 모두 소프트웨어이다. 그리고, 소프트웨어 엔지니어가 하는 일은 코드를 작성하는 것을 포함하여 소프트웨어를 만드는 것이다. 그리고, 소프트웨어는 엔지니어만 만드는 것은 아니고 제작에 참여하는 모든 직군(디자인, 기획, 사업, 등등)의 기여하에 만들어진다.

#3 - 소프트웨어라는 제품 형식

소프트웨어가 여러 제품 형태중 하나라는 것을 말하고 나면 소프트웨어를 만든다는 것이나, 관리가 필요하다는 이야기는 단순해진다. 조직이 제품을 만드는 것이나 제품을 만드는 조직이 제품을 관리하는 것은 흔한 이야기이기 때문이다. 이제 이야기해 둘 것은 소프트웨어가 다른 제품 형식과 어떻게 다른지 그리고 이 것이 관리방법에 있어 어떤 영향을 주는지 이다.

제품 그리고 관리의 관점에서 소프트웨어의 큰 특성은 디지털 혹은 비트1가 주 기반이라는 것이다. 여기에서 유연성과 복제성이라는 특성이 나온다.2 유연성은 제품의 수정이 용이하다는 것을 의미하고, 복제성은 원본과 완전히 동일하게 복제할 수 있다는 것을 의미한다. 이러한 특성 덕에 소프트웨어는 아톰1기반 제품의 관리 및 생명주기에서 중요하게 생각되는 생산, 유통, 재고관리의 문제에서 자유롭다. 대신 제품 개발 및 개선, 출시가 더 중요해지고, 아톰기반에서는 문제가 되지 않던 복제방지나 원본 증명의 문제들이 더 중요해진다.3

생산의 문제

우선 생산의 문제를 보자. 아톰기반 제품에서 생산 및 품질관리의 가장 큰 핵심은 제품이 “제대로” 만들어지는 가이다. 아톰 기반의 제품의 경우 아톰의 특성상 같은 레시피 혹은 같은 금형을 사용하더라도 그 차이의 크기와 상관없이 각기 다른 제품이 만들어진다. 이를 관리하기 위해서 기준을 만들고 그 안에 들어오는 제품들을 동일하다라고 선언한 다음 판매한다. 품질검사와 보증프로그램 같은 사용계약 그리고 필요하다면 법적 보증이 그 동일성을 보증한다.

완벽한 복제가 가능한 비트기반 제품의 특성상 소프트웨어의 기본적인 생산관리는 단순하다.4 기준조차 필요없다. 매체의 품질만 검증되면, 제품은 동일하다. 문제는 사용자도 제품에 대해 완벽한 복제와 수정이 가능하다는 것이다. 소프트웨어의 저작권을 인정하된 이후부터 복제와 수정을 원하는 사용자와 이를 막고자 하는 제작자 간의 싸움은 지리하게 이어지고 있다. 암호표5와 제품 키라고 불리는 검증값을 가진 문자열을 이용하는 고전적인 방법에서 특정 하드웨어에 강제적인 의존성을 부여하던 시절을 지나 사용자의 하드웨어의 고윳값에 맞춘 소프트웨어를 제공하는 등의 방법이 현재 주로 사용되고 있고, 더불어 사용자와 소프트웨어가 제공하는 데이터는 교차검증하는 방법을 사용 중이다. 특히 하드웨어와 결합된 여러 플랫폼들이 강제적인 고유성을 부여하는 경우 플랫폼6은 이러한 고유성에 대한 대가로 수수료를 받고, 소프트웨어 제작자는 수수료를 주는 대신 복제의 문제에서 자유로워진다. 결국 복제와 변조에 어떻게 대응할 것인가에 대한 부분7이 하나의 소프트웨어의 비즈니스 모델이 어떻게 만들어질지 결정하게 된다.

제품의 개선

제품의 개선 과정을 간단하게 살펴보자. 아톰기반에서는 출시된 제품을 유통하고 사용자의 의견을 모은다. 다음 개선안이 결정되면 생산 일정과 재고 소진계획을 만들고, 다음 생산 사이클에 맞춰 개선안을 반영한다. 이미 구워진 빵에는 밀가루를 더할 수 없고, 달리고 있는 차에 엔진을 바꿀 수는 없다. 즉, 작은 개선이라도 하려면, 최소한 다음 생산분(로트/Lot)에 반영하거나 혹은 사용자가 사용을 멈추고 제작사에 접근하기를 기다려야 한다.

그러나, 비트는 유연하다. 소프트웨어의 세계에서는 다 구워진 빵을 밀가루로 돌리는 것도 가능하고, 달리는 차의 엔진을 바꾸는 것도 가능하다. 그리고 이제 사용자는 이러한 특성에 익숙해졌다. “패치”로 불리는 수정을 자연스럽게 받아들이고, 더 빠르고 다양한 요구를 하고 있다. 물리적 한계가 적다 보니 소프트웨어는 기획, 개선, 제품 출시를 동시다발적으로 요구받고 진행하게 된다.8 이로 인하여 단계단계를 완결성 있게 끝내고 진행하는 아톰 기반 제품과 달리 소프트웨어는 얼마나 ‘덜’ 만들고 내놓을 것인지 그리고 동시다발적으로 일어나는 각 과정의 이슈들을 파악하고, 미숙한 부분들을 관리하면서, 적절한 개선품을 적절한 때에 내어놓을 것인지 결정한 다음 빠르게 행동하는 것이 더 중요해진다9

무결성의 검증

더불어 소프트웨어의 유연성과 복제성은 무결성 검증이라는 아톰 기반의 제품은 가지지 않는 또 다른 절차 및 특징을 만든다. 비트는 마모성이 없다. 수정해도 흔적이 남지 않는다. 아톰 기반의 제품에서 금형과 같은 틀이 변할 때, 틀을 살피는 것으로 마모나 변조 여부를 알아낼 수 있는 것과는 다르다. 또 이는 단순 비교로 원본과 수정본을 구분할 수 없다는 문제로 이어진다. 원본가 사본 간의 차이가 있다고 해서, 원본이 변한 것인지 사본이 변한 것인지 판단할 수 없다. 그러므로 소프트웨어에 대한 기록을 남기기 위해서는 체크섬이나 타임스탬프 같은 디지털 지문을 남기거나 수정이 불가능한 매체에 기록하여 고유성을 부여하는 작업과 충분한 사본제작(백업)이 필요하다. 현재에 이르러 이러한 문제를 심각하게 느끼지 못하는 이유는 현대의 운영체제 및 다수의 프로그램들이 이러한 작업을 자연스럽게 지원하기 때문이다.

누군가에게 재화를 제공한다는 점에서는 비슷하지만, 관리적인 입장에서만 보면 아톰기반의 여타 다른 제품과 소프트웨어는 확연히 다르다. 이는 아톰 제품 기반의 조직이 소프트웨어 기반으로 변하거나 혹은 소프트웨어 제작이 필요할 때 주로 실패하는 원인10이 되고, 소프트웨어를 기반의 조직이 하드웨어를 만들 때 실패하는 원인이 되기도 한다.11 또, 소프트웨어를 제품으로 보지 못하게 하는 원인이며, 연구나 예술작품으로 오해되는 이유이기도 하다. 그리고, 좋은 소프트웨어 제작자(ex. 엔지니어, 디자이너, PO, 기획자, …)를 찾기 어려운 이유이자, 소프트웨어 관리자를 찾기 매우 어려운 이유이다.

#4 - 우리는 소프트웨어를 만들고 소프트웨어를 관리한다.

소프트웨어가 관리되어야 한다는 말은, 제품이 관리되어야 한다는 단순한 이야기이기도 하지만, ‘소프트웨어’ 단위로 관리되어야 한다는 이야기를 포함한다. 모든 제품에서 의사 결정의 주체가 정리되지 않거나 합의, 조율 같은 다양한 말 아래 권한을 나누기만 하고 최종 의사결정구조를 명확하게 하지 않으면 제품은 관리되지 않는다. 비트와 구조에 대한 이해와 논의가 없이 방대하게 진행된 기획과 제품에 대한 이해가 없이 최신의 트렌드 혹은 개인의 취향을 반영한 아키텍처가 탄생한다. 이러한 기획과 기술이 만날 때 제품은 방향성 없이 할 수 있는 것과 하고 싶은 것이 모인 하나의 덩어리가 된다. 혼잡하고 모호한 소프트웨어가 만들어지는 배경에는 이러한 조직문화가 있는 경우가 대부분이다.

기술과 비기술 요소가 나눠져서 관리되는 문제만을 이야기하는 것은 아니다.12 기술 조직 내에서도, 전체 소프트웨어 로드맵과 각 Tech Stack간의 로드맵, 코드와 실행파일 및 동작환경, 각각의 예시코드들을 포함하는 문서와 지식의 공유, 배포와 모니터링과 같은 다양한 세부 요소들이 소프트웨어라는 단위 하에서 관리되어야 한다는 이야기도 포함한다. 많은 조직에서 관리에 대한 무지 혹은 각 세부 요소의 특성에 맞추어 관리해야 한다는 핑계로 각 요소가 각기 관리되도록 방치한다. 이러한 조직에서는 선택기준의 모호함으로 인한 비효율성이 꾸준히 조직에 쌓인다. 각종 실수 특히 커뮤니케이션 실수가 늘어나게 되고, 업무 속도의 저하와 끊임없는 버그나 장애의 형태로 실현된다.

리더가 소프트웨어의 모든 요소13에 대한 전문성을 충분히 가지고 팀을 이끌기는 쉽지 않다. 사실 IT기술 부분 그중에도 그나마 연결되는 백엔드와 웹 프론트엔드 그리고 모바일만 엮어도 그렇다. 각각의 기술스택에서 중요한 포인트는 모두 다르다. 그렇기에 리더에게는 여러 분야에 대한 관심과 학습도 필요하지만, 한계를 인정하는 태도와 위임과 의사결정을 위한 조직구조와 위임의 결과를 판단할 수 있는 판단력과 다양한 이야기를 듣고 정리하고 또 전파할 수 있는 커뮤니케이션 기술이 필요하다. ‘오버 커뮤니케이션’과 각종 업무관리도구를 포함한 다양한 관리 기술이 이 분야에서 강조되는 이유다.

#5 - 마무리

이 이야기를 하고 나면 할 수 있는 많은 이야기들이 있다. 몇개는 짧게 적어 두려고 한다.

나는 코드중심의 소프트웨어 관리론에 대해 부정적이다. 소프트웨어는 코드가 아니다.

  1. 조직이 풀고 싶은 문제는 무엇인가?
  2. 소프트웨어를 통해 이 것을 어떻게 해결할 것인가?
  3. 소프트웨어를 만드는데 있어서 걸림돌은 무엇인가?
  4. 그 걸림돌에 집중하기 위해서 기술적 선택을 어떻게 할 것인가?

더 나은 코드를 이야기하기 위해서는 위와 같은 논리의 전개가 필요하다. 소프트웨어의 목적을 논하지 않은 좋은 코드 혹은 더 나은 코드는 하나의 거대한 사기나 환상 혹은 미신에 가깝다. 당연히 모든 코드와 모든 방법이 용납되는 것도 아니다. 조직의 미션과 소프트웨어의 목적에 최적인 코드와 방법론은 존재하며 이를 기준으로 평가되고 관리되어야 한다. 여러 트렌디한 관리지침들이 절대적인 정답이 있다고 말하며 특정 방법론을 강요하는 것이나, “냄새나는 코드”, “기술 부채”, “무한한 복지” 와 같은 단어들이 모호하게 사용되며 개인의 이익을 위해 오용되는 것은 소프트웨어가 결국은 사용자에게 제공될 제품이며 그 제품의 목적을 달성해야 한다는 본질은 잊었기 때문이라고 생각한다.

더불어 비트와 계산이론에 대한 이해 없이 소프트웨어를 만드는 것은 무모하다고 생각한다. 0과 1이라는 단순한 표현으로 여러 회로를 거쳐 복잡한 논리구조와 숫자를 표현하고 계산하고 있다는 것을 이해하는 것, 예를 들면 평균을 계산하고 출력한다는 사람에게 단순한 동작이 유리수나 실수를 다룰 수 없는 컴퓨터의 입장에서는 여러 한계와 복잡성 가지는 지, 전자계산장치(혹은 컴퓨터)에서 전자기력이 어떻게 동작하는지 이해하고 이 과정에서 전력이 얼마나 필요한지를 예상하는 것은 소프트웨어를 제작에 필수적이다. 이러한 기초적인 전자계산이론이 중학 수준의 수학적 지식과 공학적 지식임에도 불구하고 실용적이지 않다는 말과 함께 업계종자사에게 여러 교육과정과 현장에서 누락되거나 무시되고 있다. 그리고 이로 인해 많은 조직에서 일정지연이나 리소스 손실 그리고 장애등을 경험하고 있지만, 원인을 소통부족이나 실수나 경험부족 등으로 이야기하고 있다.14 사실 지연이나 장애를 경험하는 것은 그나마 운이 좋은 경우이다. 영원히 완성되지 않는 소프트웨어를 향해 나아가다 사라지는 조직들도 많다.

AI의 시대에 소프트웨어 엔지니어가 사라지지는 않을 것이라도 말해두고 싶다. 소프트웨어 엔지니어의 일이 ‘코딩’에서 많이 달라질 뿐이다. 오래전에 이러한 시대가 될 것이라고 이미 이야기한 적이 있다. 이에 맞추어 현재를 평하자면 현재의 기술 수준은 아직 부족하고 그에 반해 곧 엔지니어가 필요 없어질 것이라는 언론과 시장의 반응은 너무 과하다. 그래서 아직도 변화가 와닿지 않는 엔지니어들도 있을 것이다. 결국 모두가 코드를 작성하게 될 것이다. 그러나 검증, 판단, 선택 그리고 책임을 지는 것은 여전히 인간의 일로 남을 것이다. 판사와 변호사가 사라질 수 없는 이유와 같다. 그러나 그럼에도 불구하고 단순 “코딩”만이 기술이자 일이었던 이들에게 기회는 더 이상 없을 것이라고, 남을 수 있는 이들에게는 소프트웨어 단위의 생각, 더 다양하고도 많은 지식 특히 인간에 대한 지식이 필요해질 것이다.

Footnotes

  1. 아톰과 비트라는 개념은 ‘디지털이다’에서 니콜라스 네그로폰테 교수에 의해서 제안되었다. 아톰은 물리적인 것 비트는 그러한 물리적 매체에 담겨 있는 정보 특히 디지털 정보를 의미한다. ↩ ↩2

  2. 좀 더 적당한 표현이 생긴다면 다시 정리할 것이다. ↩

  3. 단, 이 문제는 소프트웨어의 특성에 따라 약간의 차이는 있다. 게임과 같이 제품의 특성이 매체를 강조하거나 하드웨어(혹은 아톰)에 의존적인 경우 소프트웨어는 재고와 유통의 문제를 가지게 된다. ↩

  4. 다만 결국 소프트웨어가 담기는 미디어는 아톰의 성격을 가지기에 각각의 미디어의 특성에서 생기는 별도의 관리 이슈가 있다. 더불어 예전에 주로 사용되던 광학기반 미디어(CD/DVD)처럼, 미디어의 제작/수정비용이 비싼 경우에는 더 중요해진다. ↩

  5. 게임의 복사방지 장치에 대한 이야기는 너무 길고 재미있어서 생략한다. (흑) ↩

  6. 애플, 구글, 마이크로소프트, 소니, 스팀, 닌텐도와 같은 다양한 플랫폼 제공자들이 있다. 플랫폼은 이런 고유성을 지원하기 위해서 보안 하드웨어의 사용을 요구한다. 수수료에는 복제시 피해에 대한 보험비용도 포함되어 있다고도 말할 수 있다. ↩

  7. 기업주도의 몇몇 오픈소스 소프트웨어가 소프트웨어에서 나오는 수익과 보증을 포기하고 대신 서버 기반의 서비스를 추가 제공하는 것으로 수익구조를 만드는 데에는 이러한 배경이 있다. ↩

  8. 물론 소프트웨어의 초창기에는 그렇지 않았다. 하지만, 네트워크로 패치를 전달하기 시작한지도 벌써 30년이 넘었고, 네트워크에 되어 있으면 업데이트를 찾아 자동으로 패치를 적용하는 시스템이 본격적으로 사용된 지도 25년이 넘었다. 대형 시스템에 이러한 개념들이 들어온 것은 비교적 최근이라고는 하나 이미 이 또한 10년도 넘은 이야기가 되었다. ↩

  9. 업계에서 “Done is better than perfect”라고 말하는 부분이기도 하다. 단계단계를 완벽하게 하려다가 때를 놓치는 것은 익숙한 아톰 기반 제품을 가진 회사들이 소프트웨어의 영역으로 들어올때 경험하는 가장 흔한 함정(pitfall)이기도 하다. ↩

  10. 소프트웨어 공급을 받고 유지보수계약을 안한다거나 유지보수에 해당하는 내용을 제대로 정의하지 않는다거나 하는 실수들 ↩

  11. 업데이트가 배포 가능한 하드웨어를 만들려고 시도하면 어떻게 되는지 프로젝트 아라가 말해주고 있다. ↩

  12. 개발팀과 기획팀을 나눈 다음 각 팀장끼리 로드맵을 구성하게 하는 것. ↩

  13. 백엔드, 프론트엔드, 데브옵스 등등의 기술적인 요소와 제품 디자인, UX, 개인정보보호등의 법률과 보안의 문제까지 ↩

  14. https://en.wikipedia.org/wiki/Tree_swing_cartoon 참고 ↩