Talk with Hani

우선 퀴즈 하나를 내고 시작해보자. 프로젝트에서 만드는 산출물 가운데 실제 개발에는 도움을 주지 않지만 들어가는 노력이 상당히 많은 건 무엇일까? 물론 정답은 없다. 사람이나 프로젝트에 따라 다르지만 내 경험에 비춰 생각해 보면 매뉴얼이 그렇다. 매뉴얼은 정말로 손이 많이 간다. 물론 프로젝트에 따라 매뉴얼을 작성하는 사람이 프로젝트 외부에 있을 수도 있지만 보통 프로젝트 팀 내에서 매뉴얼을 만든다. 사실 매뉴얼은 프로젝트가 종료될 시점에 만들기 때문에 팀에 큰 부담이 없다. 하지만 소프트웨어 화면을 캡처해 화면마다 설명 이미지를 넣고 그걸 문서로 만들다 보면 상당한 자원이 들어간다.

물론 열심히 만들어 놓은 매뉴얼을 사용자가 잘 읽어 보고 소프트웨어를 사용할 때 도움을 받으면 그걸로 만족이겠지만, 내 경험을 보더라도 시스템을 사용하면서 막혔을 때 매뉴얼을 읽으면서 도움을 받았던 경우가 별로 없다. 매뉴얼에 적힌 정보는 상당히 뻔한 내용이어서 굳이 매뉴얼을 읽어보지 않아도 되는 것들이 많았다. 정작 시스템을 사용하면서 곤란을 겪으면 헬프 데스크나 개발자를 찾아서 문제를 해결했다.

시스템이 업그레이될 때 매뉴얼도 함께 수정하면 그나마 매뉴얼이 의미가 있지만 대부분 시스템이나 소프트웨어와 매뉴얼이 따로 노는 경우가 허다했다. 매뉴얼을 만들어 보기도 하고 매뉴얼을 두고 시스템을 사용해 보면서 얻은 결론은 그다지 도움이 되지 않는 매뉴얼은 차라리 만들지 않는 편이 더 낫다는 것이다. 그런데 막상 매뉴얼을 만들지 않자니 뭔가 개운하지 않다. 그렇다면 매뉴얼을 만들지 않으면서도 묘한 뒷맛을 느끼지 않으려면 어떻게 해야 할까?

지금은 아이폰이 대세라 모든 휴대폰이나 스마트폰이 아이폰을 기준으로 평가받는다. 잠시 아이폰이 대세인 세상을 잊고 연아폰이나 햅틱폰처럼 피처폰이 대세였던 때로 돌아가보자. 아이폰 가격과 맞먹는 피처폰을 2년 약정으로 사와서 포장을 뜯을 때마다 항상 보게 되는 부속품이 있다. 바로 매뉴얼이다. 피처폰의 다양한 기능을 설명해둔 매뉴얼은 상당히 두껍다. 제품박스가 작아서 가로, 세로 크기를 늘릴 수 없기에 두께가 상당하다. 이 매뉴얼을 볼 때마다 휴대폰에 기능이 참 많구나, 라는 생각을 한다. 하지만 그렇게 생각만 할 뿐 실제로 매뉴얼을 읽어 보진 않았다.

아이폰을 처음 샀을 때의 기억이 생생하다. 꿈에도 그린 아이폰을 드디어 우리나라에서 써볼 수 있다는 기분 때문이기도 하지만 포장을 뜯었을 때 본 매뉴얼 때문이다. 아이폰도 휴대폰인지라 기능을 설명하는 매뉴얼이 있었지만 그 분량이 정말 적었다. 기존 휴대폰의 매뉴얼과 비교했을 때 10분의 1도 채 안 되는 분량이었다. 아이폰의 기능을 생각하면 휴대폰보다 기능이 더 뛰어날 텐데도 설명서의 분량이 상당히 적다는 사실에 놀랐다. 그렇다면 왜 아이폰의 매뉴얼은 일반 피처폰의 매뉴얼보다 분량이 적을까?

답은 아이폰은 매뉴얼이 필요 없게 만들었기 때문이다. UI가 직관적이어서 굳이 매뉴얼을 찾아 기능을 공부하지 않아도 한 번 보면 누구나 쓸 수 있다. 프로젝트를 하면서 매뉴얼을 만들지 않아도 될 힌트를 아이폰에서 얻을 수 있다. 우리가 만드는 소프트웨어를 직관적이고 쓰기 쉽게 만들면 된다. 다시 말해, 소프트웨어 자체에 매뉴얼이 담겨 있으면 된다.

명백한 것은 빼고 의미 있는 것을 넣으라는 말이 있다. 매뉴얼이 필요 없는 시스템을 만들자는 관점에서 이 말을 해석하면 이렇다. 명백한 매뉴얼이 없어도 시스템의 UI가 뛰어나서 UI만 보고도 그 의미를 파악할 수 있게 만들어야 한다. 이렇게 하지 못하다 보니 우리가 만든 시스템 때문에 고생할 사용자를 위해 매뉴얼을 만들어야 하는 것이다.

이 글은 최근에 출판된 ‘대한민국 소프트웨어 리스타트’에서 발췌한 것입니다.

도서구입 Yes24 교보문고 알라딘 리브로 인터파크

최근에 일이 폭풍을 쳐서, 한동안 아두이노 프로젝트에서 손을 떼었다. 다행히 설 연휴의 틈을 타서 다시 아두이노 프로젝트를 시작했다. 설 연휴지만 시간을 충분히 내기는 쉽지 않았다. 간단하게라도 초음파 센서와 자율 주행 알고리즘을 구현하기로 했다. 초음파 센서는 앞과 진행 방향의 오른쪽의 장애물을 인식하도록 2개를 달았다.

초음파 센서를 달은 아두이노

간단한 자율 주행 알고리즘을 만들었다. 스텝 모터를 사용하지 않아서 자세 제어가 깔끔하게 되지 않는다. 그리고 자율 주행 알고리즘도 손 볼 때가 많다. 기본적으로 로봇이 벽을 타고 이동하도록 만들었다. 버벅임이 심하지만 일단 큰 그림에서 로봇이 벽을 타고 주행하기 때문에 만족하기로 했다. 다음 번 주기에서는 카메라 센서를 달거나 자율주행 알고리즘을 손봐야겠다.

버벅이지만 벽을 타고 주행하는 아두이노

지난 주까지 작업해서, 아두이노에 모터를 달아 주었다. 원래 이번 주 계획은 아두이노에게 초음파 눈을 2개 붙여 줄려고 했는데, 이 일은 잠시 미루기로 했다. 그래서 이번 주에는 아두이노에 달아 놓은 와이파이를 사용해서 PC나 아이폰에서 동작 명령을 내리는 기능을 추가하기로 했다.

모터를 달고 나서 하드웨어 추가는 잠시 쉬고 있는 아두이노

명령을 내리는 클라이언트는 브라우저를 사용해서 PC나 아이폰과 같은 플랫폼에 상관없이 구동되게 했다. 클라이언트는 HTML과 jQuery를 사용해서 초간단으로 구성했다. 로딩을 없애기 위해서 Ajax를 사용했다. 서버는 아파치와 php를 사용해서 만들었다. 클라이언트와 통신하는 Ajax page와 클라이언트에서 수신한 데이터를 아두이노에서 접속해서 정보를 가져가는 페이지로 구성했다. 초간단으로 구현하기 위해서 http 기반 통신으로 아두이노와 서버가 통신하게 구성했다. 아두이노는 http로 서버에 접속해서 클라이언트에서 입력한 데이터를 받아와서 모터를 구동하게 했다.

통신 구성도

아두이노에서 모터 구동 코멘드는 100ms 인터럽트로 돌렸고 서버와 통신하는 것은 loop 함수에 두었다. http가 무거운 관계로 클라이언트에서 전달한 명령를 수신하는 데 약 1초 정도 지연이 생기는 것 같았다(이것은 정확하게 측정하지 않은 데이터다. 대략 느낌이 ㅎ). 이 지연을 없애려면 별도 프로토콜을 만들어야 하는데, 이건 차후 반복주기(iteration)에 수행하는 것으로 하고 넘기겠다. 어쨌든 현재는 아이폰과 PC로 전후진, 좌우회전 명령을 줄 수 있고 이 명령을 받아서 아두이노가 움직인다. 정말로 이제는 초음파 눈을 달아야겠다.

브라우저 기반의 컨트롤러(이것도 고칠 게 많다)

대한민국 소프트웨어는 위기다?!

이 위기를 도약의 발판으로 삼고 싶으신가요? 그렇다면 ‘대한민국 소프트웨어, 리스타트’, 이 책을 한 번 읽어 보세요.

Yes24 교보문고 알라딘 리브로 인터파크

스페인에 가면 당연히 봐야 하는 건축물들이 있다. 그중에서 반드시 봐야 하는 건축물을 꼽으라고 한다면, 아마도 ‘사그라다 파밀리아 성당’일 것이다. 이 성당은 건축가 안토니 가우디가 설계한 것으로, ‘가우디 성당’이라고 더 잘 알려졌다. 가우디가 이 성당의 건축을 맡은 것은 1883년이었다. 그는 죽기 직전까지 이 성당의 건축에 매달렸지만, 아쉽게도 완공이 되는 것을 보지 못하고 죽었다. 그렇다면 이 성당은 언제 완공이 되었을까? 아니다. 이 성당은 지금도 건축중이란다. 관광수입으로 조금씩 짓고 있다고 한다.
 

 
미국의 산호세에 가면 기괴한 건물이 하나 있다. ‘윈체스터 맨션’이라는 건물인데, 총기를 제조하는 원체스터社의 상속녀인 사라 윈체스터가 지은 건물이다. 이 건물이 이상한 이유는, 건축이유에서 찾을 수 있다. 사라는 그녀의 남편이 죽자 남편 회사의 일부 지분과 남편의 재산을 상속받는다. 어느날 남편의 혼과 이야기를 나눈 주술사에게 충격적인 이야기를 든는다. 남편은 주술사를 통해서 부인에게 이런 이야기를 전했다고 한다.
 
“부인, 우리가 만든 총에 죽은 원주민들과 동물들 그리고 당신이 살 집을 지으시오. 단, 공사를 멈추지 마오. 공사를 멈추면 당신은 죽음을 맞이하게 될 것이오.”
 
이 이야기를 듣고 기절초풍한 사라는 어떻게 했을까? 산호세로 이사해서 지금의 윈체스터 맨션에 자리를 잡았다고 한다. 처음에 이 집은 방 몇만 있었다. 하지만 그녀는 이사하고 나서 공사를 시작했다. 그리고 그녀가 죽을 때까지 약 38년간 공사를 쉬지 않고 했다. 그 동안 수 백 채의 방을 지었고 그만큼의 방을 부수기도 했다. 무계획적인 공사 덕분에 맨션에는 엄청난 규모의 계단이 생겼고 어떤 방에는 사람이 살 수 없게 만들어지기도 했다고 한다.
 

 
전함 바사에 관한 이야기다. 전함 바사는 예전 포스트에서도 소개한 적이 있다. 1620년 대 스웨덴은 폴란드와 전쟁중이었다. 스웨덴 임금은 해상권을 장악하기 위해서 화력이 강력한 전함을 만들 것을 지시했다. 이 프로젝트의 책임은 ‘헨릭 허비슨’이 맡았다. 서로 모순되는 요구사항이 너무 많은 탓에 전함을 건조하는 일은 쉽지 않았다. 그 중에서 가장 어려운 것은 많은 수의 대포를 장착하는 것이었다. 어찌어찌하여 전함은 건조되었고 드디어 출항하는 날이 밝았다. 첫 출항을 자축하는 축포를 발사하다가 웃지 못할 사건이 벌어졌다. 대포가 너무 강력하다 보니 축포의 반동으로 배가 기울고 말았다.
 

 
앞에서 설명한 가우디 성당, 윈체스터 맨션, 전함 바사의 공통점은 무엇일까? 여러가지가 있겠지만, 난 ‘아키텍처’라고 본다. 가우디가 죽고 나서 수십 년이 지났음에도 원래 계획대로 공사가 진행될 수 있었던 이유는 무엇일까? 가우디가 성당의 전체적인 청사진인 ‘아키텍처’를 잘 잡았기 때문이다. 유령 들린 집의 대명사가 된 윈체스터 맨셔의 경우는 어떤가? 아키텍처라고 부를만한 것이 없다. 그 집의 공사를 총괄한 사라 윈체스터의 목적은 공사의 진행이었다. 결국 아키텍처의 부재는 사람이 살지 못하는 기괴한 집이 만들어지게 했다.
 
전함 바사의 경우는 어떨까? 통일성이 있고 그 규모의 배를 만드는 일이었기 때문에, 아키텍처는 분명히 있었다. 하지만 아키텍처를 설계하면서 요구사항이 제대로 반영될지 요구사항 간 모순이 없는지 검토하지 않았기 때문에 출항하자마자 침몰하는 운명을 맞게 되었다.
 
결론적으로 보자면 아키텍처가 좋거나 이상하거나 나쁘면, 그 결과물도 좋거나 이상하거나 나쁘다. 앞의 예들은, 분야는 다르지만 아키텍처가 얼마나 중요한지를 보여주는 좋은 사례라고 생각한다. 그렇다면 소프트웨어에서 좋은 아키텍처란 어떤 특징을 가져야 할까? 최신 UML 도구를 사용해서 그리고 UML을 실행해서 아키텍처의 성능 평가를 할 수 있어야 좋은 아키텍처를 그리는 것일까? 이것도 중요한 조건이겠지만, 난 아키텍처를 그리는 표기법이나 도구는 정말 부차적인 요소라고 생각한다. 즉 아키텍처를 그리는 목적에 부합하지 않는다면, 아무리 좋은 표기법이나 도구를 써도 소용없다.
 
최근에 내가 쓴 ‘대한민국 소프트웨어 리스타트’에서도 아키텍처와 아키텍트에 대해서 몇 개 chapter를 할애했다. 그 가운데 좋은 아키텍처가 가져야 할 조건으로 두 가지를 이야기했다. 요구사항은 기능 요구사항과 비기능 요구사항으로 나눈다. 요구사항 측면에서 보자면 아키텍처는 기능 요구사항을 잘개 쪼개서 개발자가 단위 설계에 집중해서 자신이 맡은 모듈을 만들 수 있는 수준으로 나눌 수 있어야 한다. 흔히 말하는 분해(decomposition) 작업을 하면서 응집성이 높고 결합성이 낮은 구조가 되도록 아키텍처를 구성해야 한다.
 
다음으로 비기능 요구사항을 아키텍처가 담아낼 수 있을지 검증해야 한다. 예를 들어서 고객이 비기능 요구사항의 하나로 가용성을 요구했다. 가용성의 수준이 99.99%라고 한다면, 과연 우리가 만드는 소프트웨어 시스템이 이런 가용성을 달성할 수 있을지 어떻게 알 수 있을까? 만약에 아키텍처에서 이런 것들을 고민하지 않는다면 개발자들의 단위를 완성하고 나서 각 단위를 모두 합치고 통합테스트를 해보기 전까지 이런 가용성을 만족할 수 있을지 알 수 없다. 물론 이런 통합테스트도 해야 한다.
 
하지만 통합테스트에서 가용성을 만족하지 못했을 때 어떻게 해야 할까? 부분 최적화라는 피말리는 작업을 해야 한다. 밤을 새고 휴일을 반납한 채 부분최적화를 해도, 아키텍처의 구조적인 문제 때문에 해결이 안된다면? 그렇기 때문에 비기능 요구사항을 만족할 수 있을지 아키텍처를 설계하면서 관련자들이 상세하게 살피고 검토해야 한다.
 
아키텍처와 아키텍트가 중요하다고 말한다. 그런데 왜 중요하죠?라고 물으면 제대로 답을 하는 사람이 그다지 많지 않다. 소프트웨어를 만드는 조직이라고 한다면, 그 규모의 크기와 관계 없이 어떤 시스템을 만들든 반드시 아키텍처를 설계하고 검증해야 한다. 이 작업을 제대로 하지 않고 생기는 문제를 처리하기 위해 삽질을 하는 것은, 그 누구의 잘못도 아니다. 바쁘니 아키텍처 같은 건 고민하지 말고 일하라고 지시한 경영층의 과실과 이에 동조한 엔지니어의 작품이다. 그래서 새해엔 우리 모두 아키텍처에 조금 더 관심을 갖는 시간이 되었으면 좋겠다.
 

대한민국 소프트웨어는 위기다?!

이 위기를 도약의 발판으로 삼고 싶으신가요? 그렇다면 ‘대한민국 소프트웨어, 리스타트’, 이 책을 한 번 읽어 보세요.

Yes24 교보문고 알라딘 리브로 인터파크