필자는 대학에서 소프트웨어 공학을 가르친다.

학생들은 프로그램을 배우고, 논리적 설계에 대한 기본을 익힌 다음에 소프트웨어 공학을 배운다. 엔지니어링이라는 학문적 관점에서 소프트웨어 개발을 바라보는 것이다. 소프트웨어는 무형이지만 유기체다. 마치 살아있는 생물처럼 성장과 쇠퇴를 반복하다가 결국 소멸하는 생명 주기를 가진다.

이제는 소프트웨어를 빼고 산업을 논하기가 어렵게 됐다. 세상의 중심에 선 듯한 소프트웨어도 승승장구하면서 거침없이 발전을 했을 것 같지만 사실은 몇 차례 우여곡절을 겪었다. 소프트웨어 위기(software crisis)가 그 중 하나다.



‘소프트웨어 위기’는 1968년 독일에서 첫 모임을 가진 나토 소프트웨어 공학 학회에서 ‘프리드리히 L. 바우어’가 던진 말이다. 4년 뒤인 1972년 ‘에츠허르 데이크스트라’도 ACM 튜링상 수상연설에서 이 말을 사용했다. 컴퓨터 계산용량이 급증하고 문제의 복잡성이 더해지면서 발생하게 될 충격을 경고하기 위해 사용했다.

소프트웨어는 태생적인 한계로 인해 계속 업그레이드해야 되고, 그럴 때마다 비용이 발생한다. 업그레이드될 수록 시간과 비용은 더 커진다. 결국에는 감당하기 어려운 수준까지 비용이 올라갈 수 있다는 점을 지적한 것이다. 뒤집어 생각하면 처음 만들 때부터 오류 없이 정확하게 작동하고, 누구든 쉽게 이해할 수 있으며, 검증 가능한 컴퓨터 프로그램을 만든다는 것이 불가능에 가깝다는 것을 역설적으로 보여주는 것이기도 하다.

불과 몇 년 전까지만 해도 한국에서는 비싼 하드웨어를 사면, 소프트웨어를 공짜로 끼워줬다. 그런데 이제는 소프트웨어를 쓰기 위해 고사양의 하드웨어로 교체하는 상황으로 바뀌었다. 또 IT 서비스를 이용하기 위해 지불하는 비용 중에서 소프트웨어가 하드웨어를 앞질렀다는 통계까지 나왔다.

앞선 글에서 소프트웨어를 건축과 비교하는 경우가 많다고 소개했다. 인류가 생존하는데 의식주는 꼭 필요한 요소다. 그 중 하나인 건축은 인류의 역사와 함께 해 왔다고 해도 과언이 아니다. 건축은 생활을 위한 ‘거주 공간’이라는 필수요소와 아름다운 예술을 추구하는 ‘미적 관점’을 동시에 갖고 있다. 특히 건축 중에서도 인간의 삶과 가장 밀접하고 중요한 것을 꼽으라면 ‘주택’이다.

현대인에게 주택이 꼭 필요한 것처럼 소프트웨어도 이미 생활의 필수품으로 자리 잡았다. 그리고 편하고 아름다운 주택이 호평을 받는 것처럼 편하고 아름다운 소프트웨어도 좋은 평가를 받는다. 좋은 소프트웨어는 단순히 작동만 잘 되는 것이 아니다. 마치 건축물이 핵심 역량인 ‘안락한 거주’ 기능에 더해 예술적 가치를 가져야 높은 평가를 받는 것과 같은 맥락이다.

소프트웨어가 얼마나 많은 일상 곳곳에 스며들어 있는지 생각해보자. 주변만 돌아봐도 불편한 소프트웨어 또는 프로세스로 업무효율이 뚝 떨어지는 경우를 많이 본다. 소프트웨어 제작을 요청한 사용자와 소프트웨어를 개발하는 개발자 간에 끊임없이 오고 가는 이슈만 살펴봐도 알 수 있다.

가령 “같은 내용을 여러 번 반복해서 입력해야 해야 한다면 얼마나 불편할까?”, “소프트웨어 기능을 개선한다고 제작비 이상의 비용이 들어가면 어떻게 하나?”, “오류를 수정하는 것이 불가능하면 어떻게 해야 하나?”, “새로 만들기 어려운 구조면 어떻게 해야 하나?”, “처음에 완벽하게 만드는 것이 중요한가?”, “빨리 대충 만들어서 사용하면서 고쳐 써야 하는 것인가?” 실제 프로젝트 현장에서 제기되는 의구심과 고민이다. 이런 난제들을 해결하기 위해 수십 년 동안 소프트웨어를 공학의 관점에서 개선해 현재에 이르게 된 것이다.

이제 블록체인으로 돌아와 보자.

블록체인 기술도 크게 보면 소프트웨어다. 그렇다면 위기를 맞을 수도 있고, 그것을 해결하기 위해 엔지니어링 측면에서 바라봐야 할 때도 있다. 소프트웨어 공학 관점에서 소프트웨어를 개발할 때는 계획, 요구 분석, 설계, 구현, 테스트, 유지보수의 단계를 거친다. 시스템에 대한 짜임새 있는 계획과 요구사항에 대한 명세, 분석이 명확하게 선행돼야 좋은 결과물을 얻을 수 있다.

블록체인 프로젝트도 마찬가지다. 블록체인 비즈니스와 시스템이 어떻게 문제를 제기하고 풀어가는지 전체적인 과정을 살펴보고 검증해야 한다. 백서에 제시된 프로젝트 수행팀의 고민과 제기하는 이슈, 해결해 나가는 전략과 과정을 꼼꼼히 점검하고 판단해야 하는 것이 중요하다. 아직 완성품 없이 가능성만을 제시하는 블록체인 비즈니스인 만큼 백서의 중요성은 아무리 강조해도 지나치지 않다.

그런데도 백서조차 안 읽고 투자하는 크립토 펀드가 있다면 그 위험성이 얼마나 큰 지는 불 보듯 뻔하다. 더군다나 백서도 없이 코인을 발행하겠다는 것은 더더욱 위험한 선택이다. 블록체인 열풍을 타고 불나방처럼 암호화폐에 뛰어드는 모습이 안타까울 따름이다.

어떤 문제가 있고, 이를 해결하기 위해 어떤 소프트웨어 공학적 전략과 전술을 선택할 것인지 전혀 밝히지 않았다면 아무리 큰 보상을 내세워도 믿을 수 없는 사업이라고 단언할 수 있다. 다음 글에서는 블록체인 시스템을 소프트웨어 공학의 측면에서 하나씩 점검해 보고자 한다. /조민양 동서울대학교 교수

우승호 기자

derrida@sedaily.com