neozest : neo+zest

같은 팀 동료가 공유해 준 글입니다. 짧은 글이지만 많은 인사이트를 얻었던 글이기도 합니다.그래서 잠시 시간을 내서 발번역을 했습니다. 의역도 조금 했습니다만, 글쓴이의 의도는 충분히 전달할 수 있을 수준이라 생각되어 같이 나눠봅니다. :)

영어를 잘하시는 분들은 원문의 감동을 느껴보세요:

http://www.azarask.in/blog/post/the-wrong-problem/

링크가 바뀐 것 같아서 수정(2023-03-16): https://uxmag.com/articles/you-are-solving-the-wrong-problem

이 글을 쓴 Aza Raskin님은 HCI 분야의 대가인 Jef Raskin님의 아들로, 파이어폭스 브라우저 개발에도 참여했으며 지오로케이션 API의 초안 작성자이기도 합니다. 현재 조본사의 VP입니다.

--------------------------------------------------------------------------

당신은 엉뚱한 문제를 풀고 있다.

일상생활에서나 직장생활에서, 혹은 무언가를 만들 계획이라면 그 과정에서  해결해야 하는 문제들이 늘 있기 마련이다. 그런데 여러분은 정작 엉뚱한 문제를 풀고 있을지도 모른다. 20세기가 낳은 위대한 기계공학자로 손꼽히는 폴 맥크레디(Paul MacCready)는 이를 한마디로 멋있게 요약했다. : "진짜 문제는 우리가 문제를 전혀 이해하지 않는다는 사실이다."

옛날 이야기

1959년은 격동의 시대였다. 디즈니는 명작 '잠자는 숲 속의 미녀'를 상영했고, 피델 카스트로는 쿠바 평의회 의장이 되었고, 아이젠하워는 하와이를 미국의 50번째 주로 공식 인정하였다. 영국의 산업계 거물인 앙리 크레머(Henry Kremer)는 예전부터 조종사의 힘만으로 동작하는 비행기가 과연 현실적으로 가능한가에 대해 호기심이 많았다. 다빈치가 가능하다고 믿었던 것처럼 크레머도 인력 비행기를 만들 수 있다고 믿었고, 이를 실현해 보고 싶었다. 그해 그는 1.5마일(약 2.5km) 떨어진 두 표지판 사이를 8자로 비행하는 인력 비행기를 처음 만든 사람에게 5만 파운드의 엄청난 상금을 주겠다고 발표했다. 또한, 최초로 인력비행기로 해협을 횡단하는 사람에게는 따로 10만 파운드의 상금을 걸었다. 이 상금을 현재 가치로 환산하면 각각 130만 달러(약 15억원)와 250만 달러(약 28억원) 정도 된다. 그 당시의 X프라이즈(XPRIZE)였던 셈이다.

그로부터 10년의 시간이 지나갔다. 수십팀이 요구조건을 충족하는 비행기를 만드려고 노력했지만 실패했다. 이제는 불가능한 과제처럼 보였다. 그 이후 또다시 10년이 지났을 때 우리의 영웅, 맥 크레디가 이 공모전에 참여하기로 결정했다. 그는 문제를 살펴보고, 기존 방법들이 왜 실패했는지, 어떤 식으로 비행기의 구조를 개선해나갔는지 살펴보았다. 그 과정에서 그는 사람들이 전혀 엉뚱한 문제를 풀고있다는 사실을 최초로 깨닫게 된다. 그는 이렇게 단언했다. "문제는 우리가 문제를 이해하지 않는다는 사실이다"

맥 크레디는 인력 비행기를 만들고자 하는 사람들이 모두 실증적 테스트를 수행하지 않고 이론과 가설에 기반하여 비행기를 만드는데 수년의 시간을 썼다는 사실을 간파했다. 그렇게 호기롭게 제작된 비행기로 시험비행에 도전했지만, 몇분뒤에는 수년간 작업한 결과물이 땅에 내동댕이치는 광경을 바라볼 수 밖에 없었다. 하늘로 떠오르는데 성공했더라도 겨우 몇백미터를 비행한 뒤에 조종사가 탈진해버리고 말았다. 연구팀들은 이렇게 얻어진 데이터를 기반으로 개선된 이론과 가설을 세운 다음 또다시 새로운 비행기를 만들고, 테스트해보고, 다시 배우는 과정을 반복해야 했다. 진행속도는 더딜 수 밖에 없었지만 그처럼 어려운 비전을 구현하는 과정에서 이런 난관은 당연한 것이라 생각했었다. 인류는 이와 비슷하게 어려운 과제를 도전해 왔다.

문제는 문제다.

폴은 우리가 풀어야 할 문제는 사실 인력 비행기가 아니라는 점을 깨달았다. 문제를 그렇게 설정해버리면 사람들의 관심은 엉뚱한 곳에 쏠리고 만다. 문제는 프로세스 그 자체였다. 매우 어려운 과제를 어떻게 해결해 나갈 것인지에 대한 성찰없이 맹목적으로 목표만 쫓은 것이다. 그는 자신이 풀어야할 문제를 새롭게 정의했다. 그가 정의한 문제는 '어떻게 하면 몇달씩 걸리던 비행기를 몇시간 내에 새로 만들 수 있는가?'였다. 그는 비닐 테이프, 알리미늄 관, 노끈으만으로 비행기를 만들었다.

첫번째 비행기는 제대로 동작하지 않았다. 너무 조잡했다. 그러나 그가 설정한 문제는 몇시간 이내에 새로운 비행기를 만들수 있는가 였으므로, 빠른 속도로 여러번 다양한 비행기를 제작해서 실험해 볼 수 있었다. 때로는 다양한 구조의 비행기를 하루에 서너대씩 날려볼 수도 있었다. 새로 만들고, 테스트하고, 다시 학습하는 과정이 몇년 혹은 몇달씩 걸렸는데, 폴은 이 과정을 수시간 내지 하루이틀 정도로 줄였다.

앙리 크리머가 상금을 내건지 18년이 흘렀다. 아무도 인력 비행기를 실제로 만들어 내지 못했다. 폴 맥크레디는 자신이 풀어야 할 문제를 새롭게 정의했다. 6개월후 맥그레디는 자신이 만든 고사머 콘돌기로 2172미터를 나는데 성공하며 상금을 거머지게 되었다. 1년 뒤, 그는 새로운 고사머 알바트로스 기를 타고 해협을 횡단했다.

도대체 어떻게 문제를 해결할 수 있었을까? 어려운 문제를 풀고자 한다면 문제를 다시 생각해보고, 어떻게 하면 해결책을 빨리 배울 수 있을 것인가를 생각해 보라. 빠른 실패를 겪으면서 더 나은 해결책을 시도할 수 있는 더 빠른 길을 찾아라. 최고의 대표작을 만들려고만 한다면 어쩌면 엉뚱한 문제를 풀고 있을 지도 모른다.

터미널에서 사용할 유틸리티를 만들다 출력 메시지에 색상을 부여하여 가독성을 높이고 싶을 때가 있다.

예를 들어 오류는 빨간색 텍스트로 표시한다거나 경고 문구는 노란색 텍스트로 표시하는 것이다.

파이썬으로 유틸리티를 개발할 경우 ColorConsole 모듈을 사용하면 된다.

https://code.google.com/p/colorconsole/

POSIX시스템에서는 아주아주 쉽다. 그냥 ANSI코드를 사용하면 된다.(예: "\x1b[30m".. 이야기 프로그램에서 안시코드가지고 놀던 기억이....새록새록.)

그러나 윈도우 command prompt의 경우 별도 WINAPI를 호출해야 한다.(쩝..MS Command Prompt는 안시코드를 지원하지 않는다. 마치 디렉터리 구분자를 '\'로 만든 것과 동일하다. 이로 인한 클로스플랫폼 개발이 얼마나 사소하게 어그러졌는지...쩝. 아니면 ANSI출력을 지원하는 command prompt 대체 프로그램을 사용해야 한다.)

colorconsole 모듈에서 제공하는 예제도 깔끔하고, 특정 위치 출력과 같은 부가기능도 사용할 수 있으므로, 다음 문서 페이지를 참고하자.

https://code.google.com/p/colorconsole/wiki/PageName?tm=6

자세한 설명을 생략한다. 다만 해당 모듈의 소스코드에서 배울 만한 스타일에 대해서만 살짝 살펴보자.

일단 terminal.py의 get_terminal() 함수부터 보자. 이 함수는 os.name에 따라 필요한 모듈을 import한 다음, 터미널 인스턴스를 생성하여 반환한다. 즉, import module을 반드시 스크립트 시작부분에서만 사용할 수 있는 것은 아니다.

def get_terminal():
    if os.name == "nt":
        import colorconsole.win        
        return colorconsole.win.Terminal()
    if os.name == "posix":
        import colorconsole.ansi       
        return colorconsole.ansi.Terminal()
    else:
        return None # Should raise exception!

win.py모듈에서 눈에 띄는 코드 부분은 WIN32API를 호출하는 방식이다.

# Window에서 런타임이 지원하는 API 호출시 필요.
import msvcrt  
# DLL 함수 및 구조체.
from ctypes import windll, Structure 

# C처럼 구조체를 사용하기.
class COORD(Structure): 
  """struct in wincon.h."""
  _fields_ = [
    ("X", SHORT),
    ("Y", SHORT)]

# 구조체를 사용하는 방법도 C와 비슷하다.
# pt = COORD(1, 2)
# pt.x = 2

# kernel32.dll의 함수를 호출할 때 그냥 짧은 함수이름으로 alias시켜준다.
# 콘솔과 관련된 함수는 다음 웹사이트를 참고하자.
# http://msdn.microsoft.com/en-us/library/windows/desktop/ms682073(v=vs.85).aspx
SetConsoleTextAttribute = windll.kernel32.SetConsoleTextAttribute

class Terminal:
    # 클래스내에서 사용하는 상수는 다음과 같이 정의한다.
    STD_INPUT_HANDLE = -10
    STD_OUTPUT_HANDLE = -11

    def __init__(self):
        # 표준 입출력의 핸들은 다음과 같이 구할 수 있다.
        # 예상대로 표준 오류 핸들은 -12이다. 
        # http://msdn.microsoft.com/en-us/library/windows/desktop/ms683231(v=vs.85).aspx
        self.stdout_handle = windll.kernel32.GetStdHandle(Terminal.STD_OUTPUT_HANDLE)
        self.stdin_handle = windll.kernel32.GetStdHandle(Terminal.STD_INPUT_HANDLE)

참고로 만약 파이프로 리다이렉션되었는지를 감지하는 방법은 있을까?

sys.stdout.isatty()를 호출하여 True인지 False인지를 보고 실제 콘솔 출력인지 파이프로의 출력인지를 알 수 있다.