brunch

매거진 소프트웨어개발과 인문학

라이킷 12 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 이경종 Sep 27. 2021

Always in beta

완벽한 소프트웨어를 만드는 방법

“사과 속에 들어 있는 씨앗은 셀 수 있지만
씨앗속에 들어 있는 사과는 셀 수 없다.”

- 켄 키지, 미국의 배우, 소설가

임마누엘 칸트는 우리에게 <순수이성비판>이라는 아주 어려운 철학서로 알려진 독일의 대철학자이다. 칸트가 젊었을 때 칸트를 사모하는 아가씨가 있었다. 그 아가씨가 어느 날 칸트에게 청혼을 했다. 청혼을 받은 칸트는 즉답을 피하고 아가씨에게 생각할 시간을 달라고 했다. 합리주의와 경험주의를 통합한 철학의 대가답게 칸트는 청혼에 대해 심사숙고에 들어갔다. 이 기회를 통해 칸트는 결혼이라는 것에 대한 철학을 정리하기 시작했고, 과연 사랑은 무엇인가, 또한 어떻게 사랑을 해야 하는가에 대한 이런 저런 연구를 하게 된다. 오랜 연구와 기나긴 장고 끝에 칸트는 청혼을 받아들이는 것이 가장 합리적이고 옳은 대응이라는 결론을 내렸다. 결혼을 결심한 칸트는 그 아가씨 집으로 찾아서 문을 두드렸다. 아가씨의 아버지가 나오자, 칸트는 따님과 결혼할 마음이 섰음을 당당하게 이야기했다. 아가씨의 아버지는 칸트를 한참동안 물끄러미 바라보다가 입을 열었다.

"너무 늦었네... 내 딸은 이미 결혼해서 한 아이의 어머니가 되었네."

칸트 말고 주위에 이렇게 처신하는 사람을 보기는 아마 쉽지 않을 듯한데, 이런 칸트이기에 불멸의 철학체계를 완성할 수 있지 않을까 생각되기도 한다. 신중하게 행동하는 것이 나쁜 것은 아니다. 완벽에 대한 추구는 뛰어난 예술품을 탄생시키기도 한다.

과거의 소프트웨어 개발 방법론은 폭포수(Waterfall) 방법론이 주류였다. 처음부터 한치의 오차도 없이 설계를 하고, 하나의 버그도 용납하지 않겠다는 완벽주의가 소프트웨어 업계를 지배했다. 소프트웨어는 점점 더 복잡해지고 거대해져갔다. 이제 완벽한 소프트웨어는 존재할 수 없다는 인식이 지배론적인 사상이 되었다. 시장을 선점하고 빠르게 대응하는 것이 훨씬 더 중요한 가치가 되었다. 이런 시대의 흐름을 잘 탄 것이 빌 게이츠의 마이크로 소프트다. 윈도우를 비롯한 마이크로소프트의 제품들은 시장을 선점함으로써 지배적인 위치를 가질 수 있었다. 빌 게이츠는 현실주의자다. 타이밍을 중시한 빌 게이츠는 비즈니스 기회를 결코 놓치지 않았다. 과감하게 첫발을 내딛는다. 그게 설령 충분치 않아도 괜찮다. 버그를 보완해서 그 다음 발을 내딛으면 된다. 이것이 빌 게이츠의 방식이었다. 지금 타이핑을 하고 있는 내 컴퓨터의 윈도우10 운영체제는 하루가 멀다 하고 업데이트를 한다. 이제는 윈도우가 업데이트를 해야 한다고 알림을 띄우면 그러려니 한다. 익숙해진 것이다. 이제 소프트웨어를 빠르게 출시한 다음 지속적인 업그레이드를 통해 완성도를 높이는 것은 업계 표준으로 굳어졌다. 계속되는 개선이 지연되는 완벽함보다 낫다. 완벽하지만 사용할 수 없는 윈도우보다 어느정도 버그는 있어도 당장 쓸 수 있는 윈도우가 나은 것이다. 이제 소프트웨어 버전 1.0은 완성을 의미하지 않는다. 버전 1.0은 그냥 시작일 뿐이다. 그 다음 버전 1.1, 1.2, 그리고 버전 2.0이 나오게 될 것을 우리는 알고 있다. 이와 달리 버전 1.0에 완벽을 기하는 부류도 존재한다. 대표적인 예가 애플의 스티브 잡스다. 잡스는 이상주의자이며 또한 완벽주의자였다. 애플과 잡스는 자기들에게 가장 맞는 방식을 택한 것뿐이다. 결과적으로 성공했지만, 수십년 전 일본의 가전업체를 제외하면 이제 잡스 이외에 그런 방식으로 성공한 이력은 찾기 힘들다. 1970년대 발표된 유닉스 철학에는 이미 빠른 소프트웨어 개발 주기의 필요성이 강조되었다.

"소프트웨어를(심지어 운영체제라도) 일찍, 이상적으로 수주 이내에 사용해 볼 수 있게 설계하고 구현하라. 어설픈 부분을 버리고 다시 구현하는 것을 망설이지 마라!"

베타소프트웨어, 그리고 애자일 매니페스토

베타 소프트웨어는 정식 출시전에 사용자들로부터 검증을 받기 위해 배포하는 소프트웨어를 말한다. Always in Beta는 계속 베타소프트웨어라는 미완성 소프트웨어 상태로 있는 것을 말하지 않는다. 우리말로 의역하면 “항상 미완성 상태”라기보다는 “끊임없이 전진하라”가 더 맞는 표현일 것이다. 이는 계속되는 개선을 말한다. 폭포수 개발이 주류를 이루던 과거에는 말이 베타 소프트웨어지 최종 소프트웨어와 거의 차이가 없는 완성도를 가진 소프트웨어를 배포하는 것이 일반적인 관행이었다. 그 당시 베타 소프트웨어는 최종 사용자 테스트를 통해 발견된 자잘한 버그들을 수정하기 위한 관례적인 절차상의 소프트웨어 네이밍에 지나지 않았다. 시대는 바뀌고 바뀌어 이제 베타 소프트웨어는 빨리 시장의 반응을 보고 그에 맞춰 적절히 대응하기 위한 초도 발사 로켓이 되었다. 소프트웨어의 완성도보다는 비지니스 기회를 놓치지 않는 것이 더 중요해졌다. 비즈니스가 없으면 소프트웨어도 없다. 타이밍을 중시하는 것은 스타트업뿐만 아니라 시장의 변화에 재빠르게 대응해야 하는 많은 IT 기업들에게도 중요해지고 있다. 빠른 출시와 지속적인 업데이트는 시장선점 뿐만 아니라 아니다 싶으면 재빨리 경로를 수정할 수 있는 유연함을 제공한다. 부가적으로 시장과 고객의 지속적인 피드백을 통해 완성도를 더 빠르게 높일 수 있다. 처음부터 완벽할 수 없음을 인정하면 많은 것들이 쉬워지고 빨라진다. 인간이 하는 일이 완벽할 수는 없다. 완벽함을 지향하되 완벽함이라는 것은 없다는 사실을 잊지 않는 게 좋다. 이제 소프트웨어 개발이 추구해야 할 것은 완벽이 아닌 완료다. 그리고 이 완료는 최종 완료가 아닌 1차, 2차, 3차와 같이 거듭되는 완료를 의미한다. 이제 완료를 지향하면 완벽이 더해지는 시대가 왔다. 이것이 소프트웨어 개발의 방법론 중 하나인 애자일 정신이다. 요즘 소프트웨어 업계에 있는 사람 중 애자일이라는 단어를 들어보지 않은 사람은 거의 없을 것이다. 애자일이란 단어의 뜻은 '날렵한', '민첩함'이다. 애자일은 2000년대 초반부터 대두된 개발방법론으로 기존 폭포수 개발방법론과 달리 개발 주기를 짧게 하고 환경에 따라 유연하게 대처하는 개발 방식을 말한다. 이미 만들어놓았던 소프트웨어를 똑같이 다시 만드는 경우는 없다. 시장에 출시되는 소프트웨어는 기존에 없던 것이다. 계획은 필요하지만 처음 시도하는 일에 완벽한 계획을 세울 수는 없다. 경험이 없으면 없을수록 계획은 잘못될 가능성이 커진다. 따라서 경험이 없으면 없을수록 더욱 애자일해져야 한다. 많은 스타트업이 애자일할 수밖에 없는 이유다. 애자일 정신은 애자일 소프트웨어 개발 선언(애자일 매니페스토)이라는 문구에 담긴 네가지 가치에 있다.

첫째, 절차와 도구보다 개성과 화합을

둘째, 포괄적인 문서보다 작동하는 소프트웨어를

셋째, 계약협상보다 고객과의 협력을

넷째, 계획을 따르기보다 변화에 대응하기를

사실 애자일에서 주창하고 있는 가치들은 이상적 가치들이다. 왼쪽에 열거된 가치보다 오른쪽에 열거된 가치들을 중시한다고 하고 있지만, 사실 대부분 일하다 보면 왼쪽의 가치들로 몰려가는 게 현실이다. '절차와 도구보다 개성과 화합'을 중요시한다고 선언하고 있지만, 애자일을 적용한 대부분의 회사들이 '절차와 도구'에만 신경쓰다가 어영부영 예전 개발방식으로 돌아가곤 한다. 허나 이상적인 가치들은 우리가 계속 지향해야 하는 선善(aganthon)이라는 것에 누구도 이의를 제기할 수는 없을 것이다. 애자일의 핵심은 마지막 가치인 '변화에 대응'하는 것에 있다. 변화에 대응하려면 유연해야 한다. 하여 중요해진 것은 소프트웨어의 변경용이성이다.

유연한 소프트웨어를 만드는 법

소프트웨어 변경이 용이하기 위해서는 무엇보다도 소프트웨어 설계가 유연해야 한다. 그렇다고 미래의 확장성을 고려하여 지나치게 일반화하는 것은 좋지 않다. 마틴 파울러는 <리팩토링>에서 미래에 있을지 없을지 모르는 상황까지 고려한 추측성 일반화는 좋지 않다고 말한다. 지나친 일반화는 오히려 시스템을 복잡하게 만들고 변경이 더 어려운 구조를 낳을 수 있다. 처음부터 쓰일지도 안 쓰일지도 모르는 기능을 고려해서 복잡함을 키우기보다는 최소한의 설계를 하되 변경에 유연하게 만드는 편이 낫다. 래셔널 소프트웨어의 수석 개발자였던 그래디 부치는 시스템의 설계는 중요한 설계결정을 가지고 있는데, 그 설계결정의 중요도는 변경에 드는 비용으로 측정된다고 말한 바 있다. 깜빡하지 말자. 설계결정의 중요도가 개발에 드는 비용에 따른 것이 아니라 변경에 드는 비용이라는 것을 말이다.

애자일 개발의 핵심은 빠른 변경이 가능하도록 소프트웨어를 설계해서 구현하고 유지하는 것이고, 그 비결은 세부적인 선택사항을 최대한 유보하는 것이다. 세부적인 설계사항들은 실제 소프트웨어의 요구사양에 종속되지 않는 것들이다. 예를 들어 클라이언트-서버 구조에서 통신을 해야 하는 소프트웨어의 경우 어떤 통신 프로토콜을 쓸 것인지는 세부적인 설계에 해당한다. 특정한 통신 프로토콜을 쓰는 것으로 설계를 확정해버리게 되면 그 세부설계에 전체 시스템이 종속되는 결과를 낳는다. 통신 프로토콜은 나중에 결정하면 된다. 통신 프로토콜을 나중에 결정하더라도 개발에 전혀 문제가 없는 설계가 바람직한 소프트웨어 설계다. 현실적으로 어려운 경우 가능한 여러 대안을 선택할 수 있도록 가능성을 열어둘 수 있는 차선의 소프트웨어 설계를 지향해야 한다.

각 소프트웨어 모듈의 결합도를 가능한 낮추는 디커플링 방식이 애자일한 소프트웨어 설계 방식이다. 소프트웨어 모듈과 모듈이 서로 분리되어 있고, 가능한 명확한 경계를 가지고 있는 것이 좋다. 그 경계가 침범당하기 시작하면 모듈과 모듈 간의 종속성이 커지면서 유연하지 못한 구조가 된다. 다만 설계나 개발의 막바지까지 완벽하게 애자일할 수는 없다. 핵심 정책이 결정되면 일부의 모듈은 어느 정도의 결합도를 가질 수밖에 없다. 말이 좋아 소프트한 소프트웨어이지, 소프트웨어는 어느 정도 하드해질 수밖에 없다. 이것은 초기설계에서 후반부 개발로 가면서 더욱 그렇다. 그럼에도 불구하고 모든 설계는 반복 설계가 가능한 구조를 지향해야 한다. 그런 설계를 할 수 있는 비결은 개발자와 아키텍트의 능력에 달려있다. 좋은 설계는 상당부분을 개발자의 경험에 의존한다. 나쁜 시스템을 설계하거나 사용해보고 고생했던 경험이 좋은 시스템에 대한 통찰을 만들어낸다. 물이 자신의 힘으로 수로를 만들어 내듯이 축적한 개발 경험을 온전히 자신의 것으로 만들었다면 전체를 볼 수 있는 힘을 기를 수 있다. 이미 한번 만들어진 물길은 더 많은 물을 품을 수 있다. 물길은 과거에 자신이 만든 그 길을 따라 흐른다.

실패를 이어나가기

어떤 성공한 사업가가 기자회견을 했다. 어떻게 해서 성공을 하게 되었는지를 묻는 기자에게 사업가가 대답했다.

"성공의 비결은 올바른 선택을 한 것에 있습니다."

기자가 재차 물었다.

"올바른 선택의 비결은 무엇인가요?"

사업가가 대답했다.

"좋은 경험을 가지고 있었기에 올바른 선택을 할 수 있었습니다."

대답을 받아 적던 기자는 다시 물었다

"어떻게 하면 좋은 경험을 많이 할 수 있을까요?"

사업가는 잠시 숨을 고른 다음 좌중을 둘러보며 천천히 말문을 열었다.

"좋은 경험의 비결은 바로 잘못된 선택들에 있습니다."

장애물을 극복하게 만드는 힘은 과거에 뛰어넘었던 또다른 장애물에 있다. 에미상을 수상한 미국의 코미디언 루이스 CK 역시 좋은 공연을 하는 유일한 길은 나쁜 공연을 많이 해보는 것이라고 말한다. 힘들게 보낸 시간만큼 나아지는 것이다. 포기하지만 않는다면 말이다. always in beta 정신이나 애자일 정신 모두 경험의 순환과 축적의 과정을 이어갈 수 있는 힘에 기반하고 있다. 그 과정 속에는 당연히 실패도 존재한다. 실패에 대응하는 유연함이 핵심이다. 변경용이한 소프트웨어가 좋은 소프트웨어이고 그런 소프트웨어가 always in beta를 가능하게 한다. 실패를 두려워하지 말고 실패하면 다시 도전하면 된다. 산불은 나무를 몽땅 태워버리지만 잿더미가 된 토양에서 더욱 무성한 산림이 우거지기 마련이다. 산이 꺼지지 않는 한 숲은 더욱 울창해진다. 이 대목에서 꼭 기억해야 할 신화는 태양에 너무 가까이 갔다가 떨어져 죽은 이카로스(Icarus)에 대한 것이다.

이카로스는 그리스 신화에 나오는 인물로 다이달로스의 아들이다. 크레타섬의 다이달로스는 대장장이의 신 헤파이도토스(불카누스)만큼이나 뛰어난 발명가로 괴물 미노타로우스를 가둔 미로를 만든 인물이다. 크레타의 미노스왕의 분노를 사게 되어 미궁에 감금되었던 다이달로스와 그의 아들 이카로스는 크레타를 탈출하기로 결심하고 새의 날개에서 깃털을 모아 모아 실로 엮고 밀랍을 발라서 하늘을 날 수 있는 날개를 만든다. 날개를 단 다이달로스와 이카로스는 드디어 크레타를 탈출하게 된다. 다이달로스는 이카로스에게 너무 높이 날면 태양에 의해 밀랍이 녹으니 너무 높이 날지 말라고 충고를 하지만 하늘을 나는 것에 심취한 이카로스는 태양 가까이 높이 날아오른다. 이카로스의 날개를 고정하던 밀랍이 태양열에 의해 녹았고, 이카로스는 결국 날개를 잃고 바다에 떨어져 죽고 만다.

이카로스 패러독스(Icarus Paradox)는 과거 성공했던 상황에 안주하고 있다가 결국 혁신하지 못하고 실패하는 상황, 즉 1등의 저주와 같다. 태양 가까이 날면 날개가 녹을 수 있다는 것을 망각한 이카로스처럼 실패를 염두에 두지 않으면 완전히 실패할 수도 있다. 이것은 자만해서는 안 된다는 교훈으로 받아들여진다. 또다른 중요한 교훈이 있다. 그것은 한번의 실패로 모든 것이 무너지게 만들지 말라는 것이다. 날개가 녹아서 떨어지면 죽을 수도 있다는 사실을 안다면 날개를 하나만 만들어서는 안 된다. 유연하지 못한 소프트웨어는 한번의 실패로 싸그리 무너질 수 있다. 단 한 번의 주기로 소프트웨어를 완성하겠다는 야욕을 버리자. 소프트웨어 개발할 때는 처음부터 불가능에 도전하는 일 따위는 하지 말자. 아예 재기가 불가능한 상황에 직면할 수도 있다. 현실 가능하고 또한 가능한 작은 소프트웨어를 만들자. 그리고 그 가능성을 이어나가자. 실패할 수 있다. 그 실패로부터 배움을 얻는 일에만 실패하지 않으면 된다. 충분히 배우지 못하면 같은 실패가 반복될 것이다. 업그레이드를 통한 개선의 가치를 믿고 나아가자. 그러다 보면 시작할 때 엄두도 내지 못했던 불가능한 소프트웨어도 만들 수 있을지 모른다.

keyword