소프트웨어는 직관적이지 않다

참으로 이상합니다. 다른 모든 이들이 불가능 할 것이라고 여겼던 사업영역을 과감하게 투자해서 세계적인 반도체, 스마트폰, TV를 만들어낸 국내 S기업이 유독 소프트웨어에서 만큼은 이전과 같은 빛을 보지 못하고 있습니다. 안드로이드와 ioS의 대항마로 야심차게 내놓은 Tizen은 2017년 인도 출시를 끝으로 역사의 뒤안길로 사라지고 있고 스마트폰에 전용 버튼까지 만들어가며 '음성 인식 비서'를 자처한 빅스비는 '불편하고 기대에 못미친다'는 사용자들의 원성을 받고 있습니다. 어깨를 나란히 한다는 기업들은 인공지능 시장에서 알파고와 알렉사를 만들고 있는데 S기업의 존재감은 미미합니다. 도대체 소프트웨어를 개발하는 것이 뭐길래 뭐든 '한다' 하면 정상 근처에 도달하던 기업이 유독 이 영역 만큼은 힘을 쓰지 못하는 걸까요? 특별한 시설도 필요 없이 그냥 성능 좋은 컴퓨터 여러 대만 있으면 되는데 말이죠.

물론 이번 포스트에서 국내 기업의 기업 문화나 개발 방법론을 지적할 생각은 없습니다. 다만 '왜 소프트웨어를 개발하는 것은 어려운 일인지'를 분석해보려고자 합니다. 이를 위해 소프트웨어 개발과 전혀 무관해 보이는 침대를 만드는 일과 비교를 해봅시다. 침대를 만드는 일은 물리적인 실체를 만드는 일입니다. Single 침대이냐, Super Single 이냐, 2인용이냐 그리고 1층 침대냐 2층 침대냐에 따라서 침대의 전반적인 크기가 결정됩니다. 크기가 적당한지 아닌지는 직접 눈으로 보고 판단할 수 있습니다. 소비자가 사용하기에 좁거나 집안에 배치하기에 너무 크다면 그에 맞게 수정 하면 됩니다. 더 가볍고 단단한 침대를 만들기 위해 특수한 재료를 사용합니다. 가볍고 단단한지는 직접 들어보고 두들겨보면 알 수 있습니다. 목수가 괴력을 지니지 않는 이상 사용자와 어느정도 공감할만한 수준으로 측정 할 수 있습니다. 가끔 공유 침대처럼 각도 조절 기능이 들어간 경우도 있는데 이것 또한 물리적 실체의 일종입니다. 침대 하부 어느지점에서 각도 조절을 시작하는것이 편리할 지를 판단하고 만들면 됩니다.

사진 1. 도깨비에 나와서 유명해진 공유 침대 입니다. 각도조절이 있는게 신기하죠?

물리적인 실체는 직관적입니다. 그렇기 때문에 침대를 만드는 사람들은 어렵지 않게 문제점을 판단하고 수정 할 수 있습니다(물론 편안한 잠자리를 만드는 일 또한 매우 어려운 일입니다) 그러면 소프트웨어는 어떨까요? 소프트웨어도 우리가 볼 수 있는 물리적 실체가 있을까요? 아마 소프트웨어 개발자가 아닌 일반인이라면 본적이 있다고 반문하실 겁니다. 집에 Widows10 데스크탑을 키면서 매일 아래와 같이 소프트웨어를 본다고 말이죠.

사진 2. 윈도우 10 바탕화면입니다. 전작보다 훨씬 깔끔해진 느낌입니다.

위 하면에서는 날씨 정보를 확인 할 수 있고 마우스 클릭으로 뉴스, 계산기, 크롬을 실행 할 수 있는 버튼을 다룰 수 있습니다. 즉 소프트웨어에서 제공하는 기능을 사용할 수 있는 인터페이스가 일반인들에겐 물리적인 실체입니다. 그렇다면 이것을 만든 사람들은 어떻게 생각할까요? 아마 개발자들은 위 화면은 그저 개발한 기능을 실행 할 수 있도록 구현한 UI 화면일 따름이라고 말할 겁니다. 그리고 물리적 실체로 아래와 같은 화면을 작업창에서 (자랑스럽게) 보여줄겁니다.

사진 3. 리눅스 커널 코드의 일부 입니다. 이 코드는 무슨일을 할까요?

사진 3은 리눅스 커널의 일부 코드를 스크린샷 한 것입니다. 네 맞습니다. 소프트웨어를 개발한 사람의 입장에선 이것이 물리적 실체입니다. 위 사진에 작성한 코드들이 컴파일 돼 이진수의 파일로 만들어지고 프로세서와 그래픽 카드는 이 파일을 실행해 사진2와 같은 인터페이스를 출력합니다. 날씨를 보여주는 화면과 크롬을 실행 할 수 있는 바탕화면은 프로그래밍 언어가 프로세서와 그래픽카드에서 유기적으로 동작한 결과물입니다.

그런데 위 코드가 무슨 기능을 하는지 느낌이 오시나요? 아마 비전공자들은 바로 읽는 것을 포기하셨을 것 같습니다. 이건 당연합니다. 그런데 전공자중에서도 커널을 다뤄본 사람이 아니라면 코드를 읽다가 금새 포기합니다. 한 번도 경험한 적이 없는 코드이니까요. 이쪽 분야의 전문가가 아니라면 코드만 봐선 무슨 일을 하는 것인지 알 수가 없습니다. 개발자가 변수와 함수명을 나름 직관적으로 표현하려 했지만 경험하지 못한 개발자에게는 깜깜합니다. 끈기 있고 경력이 많은 개발자라 하더라도 수만 라인을 단번에 분석 할 수는 없습니다. 이미 알고 있는 사람의 설명을 듣거나 또는 개발 문서를 읽고나서 그제서야 "아~" 하며 감을 잡게 됩니다. 그러고 나서 직접 로그 파일을 분석 해보면서 전체 시스템이 어떻게 동작하는지 파악하지요. 그렇다 하더라도 실제 개발까지 하려면 시간이 꽤 오래 소요됩니다.

침대를 만드는 일에 비하면 소프트웨어를 개발하는 일은 직관적이지 않습니다. 사용자의 시각에선 버튼의 크기를 바꾸는 일은 침대를 싱글 사이즈에서 더블 사이즈로 바꾸는 것처럼 느껴질 수 있지만 이것을 경험하지 못한 소프트웨어 개발자는 코드 내부에서 버튼의 크기를 결정하는 변수를 찾느라 오랜 시간을 보냅니다. 운좋게 변수를 빨리 찾더라도 변수 값의 변경이 다른 요소에 미치는 영향까지 고려해야하기 때문에 쉽사리 크기를 바꿀 수 없습니다. 버튼 크기를 바꿨다가 자칫 주변 버튼의 영역을 덮어써서 누르지도 못하게 될지도 모르니까요. 이를 위해선 UI 시스템이 어떻게 동작하는지 파악할 필요가 있습니다. 간단해 보이는 일이지만 꽤 오랜 시간이 소요됩니다. 버튼 변수의 위치와 미치는 영향을 단번에 파악할 수 있다면 쉽게 끝날 일인데 말이죠.

시스템을 개발한 사람이라면 능숙하게 할 수 있을지도 모릅니다. 그런데 직접 개발에 참여한 사람이라 하더라도 본인이 작성한 코드가 1천 라인이 넘어가면 예전에 작성한 코드들이 생소해집니다. 예전에 분명히 짠 코드 였는데 남이 짠 코드인것 마냥 느껴지죠. 만든 사람이 모른다니 일반인으로선 참으로 당황스럽지만 이런 경우는 꽤 빈번합니다. 주로 "누가 이렇게 짰어?!"라고 큰소리 치다가 본인이 수정한 이력을 확인하고 멋쩍여 하는 상황으로 연출됩니다. 그때부턴 처음 보는 사람인 것처럼 코드를 하나하나 분석하게 됩니다. 그리고 '내가 이런 코드도 짰었어?' 하며 소름 돋기도 하죠. 이처럼 소프트웨어는 만든 사람에게도 직관적이지 못합니다. 그런데 혼자가 아니라 여러 사람이 개발한 소프트웨어는 어떨가요? 상상만해도 무섭네요.

사진 4. 블루스크린 화면 많이 보셨죠? 개발 도중 블루스크린 화면을 보면 숨이 턱 막힙니다.

리눅스나 윈도우처럼 수십만 라인이 넘어가는 운영체제 소프트웨어는 매우 복잡합니다. 작업에 참여한 사람도 많고 서로 다른 요소들이 많이 얽혀 있기 때문에 간단한 수정 사항이 시스템 전반에 영향을 미쳐 사진 4처럼 시스템이 다운 되는 경우가 빈번합니다. 그런데 로그파일을 분석해보면 시스템이 다운된 원인은 꽤 단순하고 명료합니다. 침대로 치면 2층 침대의 사다리를 없앤 것이 원인이 되는 경우가 많죠. 침대를 만든 사람들의 입장에선 어처구니 없는 실수 일 것입니다. 그런데 개발할 때는 이런 문제가 발생할 것이라고 전혀 예상하지 못합니다. 문제가 터지고 나서야 자신이 바보같은 실수를 했다는 것을 깨닫고 자괴감에 빠집니다. 같은 개발자로서 책임감을 통감하면서도 전 짧은 변명을 하고싶습니다 

"코드상에선 침대의 사다리로 보이지 않아요" 

오늘도 직관적이지 못한 프로그래밍 코드와 씨름하는 소프트웨어 개발자 여러분들을 응원합니다.

아래의 링크에서 사진을 빌려왔습니다

• 사진 1. ihttp://m.iloom.com/product/iloomView.do?goodsCd=HSSE500&colorCd=CCBGM&beforeNm=%EB%AA%A8%EC%85%98%EB%B2%A0%EB%93%9C(%EA%B8%B0%EB%B3%B8%ED%98%95)
• 사진 2. https://www.theverge.com/2015/7/28/9045331/microsoft-windows-10-review
• 사진 4.  https://www.lifewire.com/how-to-fix-a-blue-screen-of-death-2624518