왜 소프트웨어를 만드는가?? 어떻게 소프트웨어를 만드는가??

'소프트웨어는 일을 쉽게 하기 위해서만 존재한다고 말한 분이 있다. 절대로 반대한다. 값싸고 빠른 컴퓨터 때문에 가능해진 애플리케이션이 엄청나게 많다. 그 전에는 존재하지 않았다. 시뮬레이션, 다양한 그래픽, 과거 데이터의 심층분석 등이다' - Gbentley 

이 코멘트는 두 가지의 흔한 아이디어를 수용한 것이다. 첫째는 "소프트웨어는 일을 쉽게 하기 위해서만 존재한다", 둘째는 "값싸고 빠른 컴퓨터 때문에 가능해진 애플리케이션이 엄청나게 많다"라는 것이다. 

이들 아이디어가 실제로는 정반대일까? 이런 생각이 맞나? 

"소프트웨어는 일을 쉽게 하기 위해서만 존재한다" 

나는 이것을 보조 명제라고 부르겠다. 너무 진실에 가까워서 의문이 필요없기 때문이다. 그러나 큰 문제가 있다. "위해서만"의 "만"이 문제이다. "만"이 없었다면 너무나 당연한 말이다. 일을 쉽게 하기 위해 존재하는 것이 당연하다. 그러나 새로운 일을 하는 것을 배제한 유일한 존재이유라고? 이는 엄청나게 대담한 주장이다. 

그러나 사람들이 왜 이를 받아들이는지 이해하기는 쉽다. 이메일은 우편 시스템을 대체했으며 스프레드시트는 장부를 워드프로세서는 타자기를 대체했다. 타자기는 종이와 펜을 대체했다.) 예는 더 많다. 사실 컴퓨터와 직접 연계된 소프트웨어를 제외하면 컴퓨터 없이 할 수 없는 일을 복제한 소프트웨어를 찾기는 어렵다. 개발도구나 백업 소프트웨어가 예외이다. 컴퓨터가 없다면 소프트웨어를 개발하거나 컴퓨터를 백업할 이유가 없다. 

"값싸고 빠른 컴퓨터 때문에 가능해진 애플리케이션이 엄청나게 많다" 

나는 이것을 활성화 명제라고 하겠다. 첫 번째 명제보다 훨씬 타당성이 있다. 소프트웨어가 일을 단순화한다는 사실을 부정하지 않으며 소프트웨어와 컴퓨터가 그 전에 불가능했던 일들을 가능하게 한다고 말하는 것이다. 이 명제에는 두 가지 변종이 가능하다. 하나는 컴퓨터 없이는 불가능한 것들이 있다라는 것이다. 이는 증명하기 어렵다. 

Gbentley에 의해 주어진 예 조차도 엄청난 인내력과 능력 혹은 종이와 연필로 하기에는 엄청난 팀을 필요로 하는 것이다. 더 실용적인 변종은 다음과 같다. 컴퓨터없이 가능하기는 하지만 실용적이지 않은 일들이 있다. Gbentely의 예들은 이 주장에 의해 포용된다고 나는 생각한다. 

컴퓨터를 이해하지 않고서는 이들 주장을 제대로 평가하기 불가능하다. 

예를 들어, 나는 장부책을 기계적 컴퓨터의 일종이라고 주장할 수 있다. 모든 C/R/U/D (Create/Read/Update/Delete)가 사용자에 의해 연필로 수행되는 기계적 데이터베이스이며 모든 계산은 사용자가 하지만 데이터베이스는 맞다. 이런 명제를 두고 심지어 수표책도 컴퓨터라고 할 수 있으며 컴퓨터 없이는 혹은 초인적 기억능력과 수학능력 없이는 가장 기초적 회계도 불가능하다고 말할 수 있다. 

아니면 컴퓨터가 이진 기억장치와 논리 시스템으로 임의의 데이터를 표현하는 임의의 전자기기라고 정의할 수 있다. 더 적절할 것이다. 우리가 컴퓨터라고 부르는 모든 것은 이진 장비이다. 그런가? 과학자들은 양자 컴퓨터를 만들려고 노력 중이며 온/오프 상태에 아마도 상태가 추가될 수 있다. 다른 과학자들은 생체 물질을 통합한 컴퓨터를 개발 중이며 아날로그 인터페이스가 필요하다. 하드 드라이브도 이진 기기라고 하기 어렵다. 자기 상태를 기록하기 때문이다. 자기특성은 온/오프 상태가 아니라 상대적 특성이다. 하드 드라이브는 작은 자기장의 상대적 세기를 읽는 것에 불과하다. 특정 세기보다 자기장이 크면 온 상태이다. 따라서 이진 기억장치나 처리장치가 있다고 컴퓨터라고 부르기는 어렵다. 또한 우리는 컴퓨터가 거대한 트랜지스터들이 필요하다는 보조 명제를 만들어 낼 수도 있지만 트랜지스터가 없는 컴퓨터 장비들이 존재했으며 앞으로 더 나올 것이다. 

우리는 어떻게 보면 운이 좋다. 활성화 명제는 컴퓨터의 종류, 즉 빠른 것인지 아니면 값싼 것인지를 규정하기 때문이다. 즉 4년된 PC보다 못한 것은 배제한다. 수표책, 주판 등은 현대적 컴퓨터 하드웨어보다 절대 일을 빨리 수행할 수 없다. 물론 적절한 소프트웨어가 있다는 가정이 필요하다. 이는 중요한 문제이다. 소프트웨어말이다. 

우리는 이로 인해 모든 논쟁이 시작된 명제로 가게 된다. 소프트웨어 발명가와 개발자 사이의 관계이다. 우리는 갑자기 발명가와 개발자들이 중복될 것이라고 생각하는 사람들을 배제할 수 있다. 나는 애플리케이션 XYZ는 개발자의 도움없이 사용자가 코드를 스스로 개발할 수 있다는 말을 엄청나게 들어왔다. 즉 간단한 드랙 앤 드롭 인터페이스(혹은 간단한 영어 질의, 자연어 질의, GUI 인터페이스, WYSIWYG 인터페이스)로 이것이 가능하다는 것이다. 나와 나의 경력에 있어서는 다행인 것이 이런 마술과 같은 애플리케이션이 개발된 적이 없으며 단시일내에 나올 것 같지 않다는 것이다. 

우선 완전히 새로운 방식의 컴퓨터 코드 개발과 관리를 요구한다. 최근에 여기에 대해 생각을 해 봤는데 다양한 이유로 당시에는 생각을 공유할 수 없었다. 가까운 시간내에 이를 공유할 수 있기를 바란다. 

다른 문제는 개발자들이 사용자들이 일하는 방식을 생각하는 방식이다. 이는 사용자 인터페이스 문제도 낳는다. 개발자들은 사용자의 사업적 요구를 불리안 논리와 프로시저 코드로 변환하기 위해 핵심적 실문을 이들에게 한다. 원하는 대로 부를 수 있지만 이벤트 지향의 그리고 OOP 코드는 프로시져 코드이다. 이벤트가 발생하거나 메소드가 실행된 후에 그렇게 되기 때문이다. 개발자들은 다음과 같은 질문을 한다. 

이 값이 당신의 정한 임계치를 넘으면 최대치로 낮춰야 하나 아니면 오류 메시지를 내야 하나? 

이 데이터는 리스트 아니면 스프레드시트 형태 둘 중의 어느 형태로 되나? (개발자가 사용자에 스프레드쉬트를 언급하면 실제로는 데이터베이스를 의미하는 것이지만 사용자는 데이터베이스보다 스프레드쉬트의 개념을 더 잘 받아들인다) 

어떤 상황에서 출력 스트림의 데이터를 강조해야 하나? 

이런 문제는 사업 논리를 코드화하기 위해 필요한 질문이며 잘못된 것은 없다. 그러나 이 방식의 명제가 실패한다면 사용자의 실제 요구를 잘못 파악했기 때문이다. 우리는 사용자가 "어떻게" 일을 하는지 찾는 것이지 "왜" 하는 지를 찾는 것이 아니다. 

훌륭한 예는 MS 오피스 매크로 레코더이다. 물론 최종 결과는 다양한 VBA 명령어 들이지만 MOMR이 일반 사용자를 개발자로 만든다고 주장할 수 있다. 그러나 만들어진 코드를 봐라. 모든 마우스 클릭, 키 눌림 등을 복제한 결과이다. 사용자가 "어떻게" 일을 하는지 복제한다. 따라서 MOMR 코드는 기본적인 일 외에는 쓸모가 없다. 사용자의 의도를 이해하지 못하기 때문이다. 사용자가 특정 열을 선택하고 글자체를 두껍게 한다면 매크로는 단지 열 C를 선택하고 이를 두껍게 한다고 기록한다. 열 C의 글자체를 두껍게 한다고 단순화하지 못하며 선택 동작을 제거하지 못한다! 사용자가 다른 열을 선택했을 때 이 매크로를 수행하면 이전의 선택이 없어진다. 개발자는 적절히 이 코드를 재작성할 것이다. 그러나 그렇다고 하더라도 소프트웨어는 왜 사용자가 열 C의 글자체를 두껍게 하는지 알지 못한다. 이 코드는 수행될 때마다 이미 열 C가 두꺼운 글자체로 되어 있어도 이를 반복할 것이다. 이런 결정이 열의 내용에 기반하거나 주위의 열에 기반한다면 이 매크로는 사용자의 목표를 만족시키지 못할 것이다. 

'어떻게'에서 '왜'로 전환 

개발자가 여기서 필요하다. 개발자는 사용자와 마주 않아 어떤 경우에 열 C의 글자체를 두껍게 하는지와 같은 질문을 한다. 혹은 개발자는 어떤 조건하에서 특정 열을 두껍게 하는지 물어본다. 그러나 가장 좋은 질문은 왜 특정 열을 두껍게 하는지 물어보는 것이다. 여기서 우리는 '어떻게'에서 '왜'로 넘어가게 된다. 그 대화에서 벌어지는 일은 엄청난 것이다. 개발자는 사용자가 프로젝트 명세에서 규정한 '어떻게'가 '왜'를 만족하지 않는다는 것을 알 수 있기 때문이다. 예를 들어, 사용자는 두꺼운 열이 저조한 판매실적을 나타내므로 두꺼운 열을 원한다고 말할 수 있다. 개발자는 돌아서서 당신이 필요한 것은 부진한 계좌를 표시하는 것이다. 스프레드시트에 부진한 부분과 누가 잘못하는지 만을 표시한 두 번째 탭을 둔다면 더 좋지 않겠는가? 갑자기 우리의 일은 훨씬 더 어려워지지만 결국 우리는 훨씬 행복한 고객을 얻게 된다. 

이 시점에서 소프트웨어는 '어떻게'에 대한 부분을 복제하는 것을 멈추고 '왜'를 실현하기 시작한다. 이는 이 기사를 시작하게 된 문제이다. 

비교적 최근까지 소프트웨어의 개발은 '어떻게'의 관점에서 이뤄졌다. 주어진 환경에서 원하는 대로의 언어와 하드웨어를 투입할 수 있지만 이는 과거의 일이다. 단지 최근에 와서야 소프트웨어는 '왜'를 지향하는 일이 됐다. 소프트웨어가 '어떻게'만을 만족하기 위해 개발된다면 기존 일을 쉽게 하는 소프트웨어만 존재하게 된다. '왜'를 충족시키기 위한 소프트웨어를 개발한다면 우리는 과거에 불가능했던 일을 하는 소프트웨어를 갖게 된다. (어떠한 변종 명제를 사용하건 간에) 사용자들의 '왜'는 일부 픽셀의 컬러 코드를 바꾸지 않는다. 이는 '어떻게'이기 때문이다. 사용자의 '왜'는 디지털 사진에서 적목현상을 제거한다. 

우리가 '왜'를 해결하기 시작하면 우리는 훌륭한 소프트웨어를 쓸 수 있다. 기능이 나쁜 적목제거 소프트웨어는 사진의 임의의 부분의 붉은색 점을 검정색 점으로 바꿀 수 있다. 좋은 적목제거 소프트웨어는 잠재적으로 눈에 해당하는 부위의 붉은 점만 검정으로 바꿀 것이다. 훌륭한 소프트웨어는 우선 얼굴과 같은 모양을 찾고 눈과 같은 모양을 찾은 후에 붉은 점을 검은 점으로 바꾼다. 최고의 적목제거 소프트웨어는 심지어 컴퓨터에 존재할 필요도 없다. 카메라에 있으면 된다! 카메라는 플래시를 응용해(기간, 밝기, 심지어 다양한 스펙트럼을 사용하는 몇 번의 플래시) 적목현상이 렌즈는 아니더라도 사진에 포착되지 않도록 할 것이다. 

이는 단지 하나의 예에 불과하다. 그리고 여기서 우리는 개발자와 사용자의 차이를 보게 된다. 개발자들은 사용자들에게서 너무나 멀리 떨어져있다. 그렇기 때문에 소프트웨어의 '왜'를 이해하기 힘들다. 개발자들이 사용자들이 어떻게 일을 하는지 이해해야 한다고 말하는 것은 아니다. 분명히 도움이 되기는 한다. 혹은 사용자가 소프트웨어를 생성하는 도구를 만들어야 한다고 말하는 것도 아니다. 나는 개발자들이 '어떻게' 만큼 '왜'를 이해하는 것이 중요하며 단지 '어떻게'가 아니라 '왜'를 위해 '어떻게' 코드 작업을 할지 생각하는 것이 중요하다고 말하는 것이다. 

일부 개발자들은 사용자가 얼마 되지 않는 소프트웨어를 개발하기 때문에 운이 좋다. 모든 잠재적 사용자의 '왜'를 만족해야 하는 워드 프로세서를 개발한다고 생각해 보자. 일부 사용자들은 일용품 쇼핑 목록과 같은 임의의 데이터베이스로 워드 프로세서를 사용한다. 다른 이들은 타자기를 대체하기 위해 사용한다. 다른 이들은 심지어 콘텐츠를 만들지도 않고 워드 프로세서를 사용하여 콘텐츠를 검토하고 편집한다. 다양한 사용방식이 있다. 오피스 12에서 읽은 바에 따르면 MS의 기본적 아이디어는 옳다. 사용자가 목적하는 흐름에 연관된 옵션만 보여주라. 그러나 이것도 최종목표와는 동떨어진 것이다. 아직 '어떻게'이기 때문이다. 

'왜’를 만족시켜야 비효율적인 과정 해소 

파일 시스템들은 '어떻게'를 만족하지만 '왜'를 만족하지 못하는 시스템의 훌륭한 예이다. 컴퓨터가 나온지 얼마 되지 않았을 때 디렉토리 구조는 의미가 있었다. 디렉토리 이름과 파일 이름에 저장된 정보 자체가 일종의 메타데이타였다. 문서/타임카드/2005년 7월.xls 는 분명히 타임카드 문서인 2005년 7월의 문서다. 이는 컴퓨터 이전의 100여년간 지속되어온 문서 캐비닛을 모방한 '어떻게'를 충족한다. '왜'는 필요한 데이터를 식별하고 찾는 것으로 디렉토리 구조가 잘 하지는 못하는 것이다. 사실 사용자는 타임카드, 문서, 스프레드시트, 2005년 7월 관련 등의 속성을 파일 오브젝트에 지정할 수 있다면 훨씬 좋을 것이다. 갑자기 우리는 타임카드 디렉토리에서 벗어나 타임카드로 표시된 모든 문서를 갖는 타임카드 그룹을 갖게 된다. 이는 진정 강력한 변화이다. 

즉 우리의 설계 및 개발 과정은 왜가 아닌 ‘어떻게’에 의해 좌초되는 경우가 많다. 이 정보를 위해서는 드롭다운 상자가 좋은 것같다라고 말하는 사용자를 얼마나 많이 보게 되는가? 드롭다운 상자가 최선이라고 보는 이유는 이와 유사한 것을 봤기 때문이며 더 나은 인터페이스가 있다는 사실을 모르기 때문이다. 개발자들의 관점에서 사용자가 너무나 아키텍처에 대해 소상히 설명하기 때문에 차라리 프로그래밍 하는 법을 가르치고 스스로 코딩하게 하는 것이 낫다고 생각한 경우도 많지 않은가? 이런 일이 생기는 이유는 사용자/개발자의 관계가 '어떻게'에 기반하기 때문이다. 개발자의 입장에서 사용자의 왜를 어떻게로 변환하는 것이 일이다. 그렇다. 즉 지금 하는 일의 방식보다 나은 소프트웨어를 개발하는 것이다. 바로 이것이 문제의 핵심이다. 만약 사용자의 현재 방식이 너무나 훌륭하다면 왜 소프트웨어를 원하는가? 어떻게 대신 왜를 해결하기 시작하면 우리는 비효율적인 과정들의 복제를 그만두고 실제 매체에 적절한 새로운 과정을 창조하는데 도움을 줄 수 있다. 

문제의 큰 부분은 내 생각에 프로그래밍 언어가 아직 '어떻게' 지향적이라는데 있다. 소프트웨어 개발에 '왜'는 없다. 일부 언어는 다른 것보다 조금 좋다. 예를 들어, Perl의 '당신이 적은 것이 아닌 의미하는 것을 하라'는 좋다. C는 코드를 읽는 사람들이 코드 자체를 바꾸길 원한다는 것을 이해할 때 포인팅하는 대상보다 포인터 자체를 바꾸기에 좋다. 이는 내가 AJAX에 대해 갖는 불만이다. 사람들은 AJAX를 사용해 풍부한 클라이언트의 기능을 복제하려고 한다. 그러나 실제로 이를 위한 도구는 제대로 갖춰져 있지 않다. 따라서 문제가 많다. 

기술적 세부사항은 이 기사에 적지 않겠다. 이미 여러 번 언급했기 때문이다. 그러나 AJAX 를 비롯한 다수의 웹 애플리케이션들은 이미 리치 클라이언트의 부족한 '어떻게'에서 출발해 문제를 더욱 악화시키고 있다. 사용자들은 인터넷 접속을 가진 컴퓨터에서 타이핑하기 위해 워드프로세서를 사용하는 것이 아니다. 따라서 웹 기반 워드 프로세서는 실제 '왜'를 반영하지 못한다. 나쁜 워드 프로세서가 필연적으로 생기게 되며 그 과정에서 상태가 좋지 못한 '어떻게'를 복제하게 된다. 무엇보다 이 모든 것이 나쁜 도구들을 사용해 이뤄진다. 

이 주제에 대해 훨씬 많은 생각을 갖고 있다. 그리고 개발자들이 '어떻게'에 땀을 흘리기보다 '왜'를 해결하도록 힘이 실리기 위해서 무엇이 변해야 하는지에 대한 생각도 많다.@