brunch

You can make anything
by writing

C.S.Lewis

by 생계형 개발자 Feb 12. 2018

소프트웨어는 보이지 않는다

왜 소프트웨어를 개발하는 것은 어려울까? 첫번재 이야기.

참으로 이상합니다. 다른 모든 이들이 불가능할 것이라고 여겼던 사업영역을 과감하게 투자해서 세계적인 반도체, 스마트폰, 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층 침대의 사다리를 없앤 것이 원인이 되는 경우가 많죠. 침대를 만든 사람들의 입장에선 어처구니없는 실수 일 것입니다. 그런데 개발할 때는 이런 문제가 발생할 것이라고 전혀 예상하지 못합니다. 문제가 터지고 나서야 자신이 바보 같은 실수를 했다는 것을 깨닫고 자괴감에 빠집니다. 같은 개발자로서 책임감을 통감하면서도 전 짧은 변명을 하고 싶습니다