프로그래밍 실력을 늘리려면 프로그래밍을 많이 해보는 것이 중요하다는 것은 아마 부정하는 사람이 없을 것입니다. 그렇지만 우리는 안타깝게도 무엇을 프로그래밍할 것인가에 대해서는 별로 이야기하지 않는 것 같습니다. 사실은 연습하는 것 자체 이상으로 어떻게 연습하는가가 무척 중요합니다. 실력이 느는 속도에 큰 영향을 주기 때문이지요. 여러분은 어떤 프로그램들을 만들어왔습니까?

소프트웨어 테스팅 분야에서 헬로월드(화면에 hello world 찍기)처럼 자주 쓰이는 문제가 있습니다. 삼각형 세 변의 길이를 입력하면 그 삼각형이 어떤 삼각형인지 출력해주는 프로그램(예컨대, 정삼각형, 이등변, 직각, 예각, 둔각, 삼각형아님 등)의 테스트를 설계하라는 문제입니다. 예를 들면, 1, 1, 1을 입력해서 정삼각형인 걸 확인한다 등의 일련의 테스트들을 설계하는 것이죠. 이는 소프트웨어 테스팅에서 ECP(Equivalence Class Partitioning)라고 불리는 기본적인 기술을 훈련하는 문제입니다. 그런데 흥미롭게도 이 문제를 전문가들은 진행하지 못합니다. 초보자들은 잘 푸는데 말이죠. 전문가들은 질문에 대해 답을 듣지 못하면 진행이 의미 없다고 하며 진행하지 않습니다. 예컨대 "이 프로그램은 누가 사용할 건가요?" 같은 질문이지요. 그러면 통상적인 선생은 이렇게 답할 겁니다. "아유, 그런 거 없어요. 그냥 푸세요." 근데, 한번 생각해 봅시다. 현실에서 사용자 없는 프로그램이 존재하기나 하는지요. 사람이건 또 다른 프로그램이 되었건 항상 사용자는 존재합니다. 그런데 우리는 매우 비현실적인 상황을 가정하고 문제를 푸는 겁니다(어떻게 보면 이런 건 "시험머리"를 키우는 거겠죠). 전문가 입장에서는 사용자가 누구냐에 따라(수술용 장비에 들어가는지, 산수 교육용인지 등) 전혀 다르게 테스트 설계를 해야지 말이 된다는 것이지요.

이런 이유로 교육학과 경영학의 교육/훈련 효과 연구에서 이런 식의 단순화된, 그리고 맥락이 배제된 문제 학습이 실전(특히 학습전이가 많이 필요한 -- 다시 말해 응용력이 필요한 분야)에서 별 빛을 발하지 못하는 것이지요.

관련하여 대학 후배들을 위해 십년도 전에 썼던 글이 있는데, 요즘에도 어떤 프로그램을 만들어야 할지 고민을 하는 친구들을 많이 봐서 블로그에 공개합니다.

아래 글에 하나만 추가하자면 아래에서 "자신을 위한" 프로그램 부분은 정말 자기에게 니즈가 있는가 판단하는 것이 중요합니다. 그렇지만 대부분 착각을 합니다. 예컨대, 이런거 있으면 좋겠다는 니즈가 아닙니다. 통상 몇 개월 동안 지속적으로 사용하지 않는다면 실질적 니즈가 없을 확률이 높습니다. 관련해서는 린스타트업의 접근법을 참고하시면 좋을 것 같습니다.

---

What to Program

무엇을 프로그램할지 고를 여유가 있는 사람의 입장에서 묻는 "우리는 무엇을 프로그램할까"

학교에서 숙제로 내주는 것들이란 정말 숙제를 위한 숙제인 경우가 있다. 아니, 꼭 그렇진 않더라도 나는 뭔가 내 페이스에서 스트레스 없이 내가 원하는 것을 만들어보고 싶다. 어찌되었건 프로그램을 잘하려면 프로그램을 자주 해봐야 한다고 말하지 않는가. 그럼 도대체 무엇을 프로그램할 것인가?

나는 일차적으로 단순한 것을 권하겠다.

이 단계가 넘어서면(한 달 정도면 넘어서지 싶다) 자신에게 가까운 것을 프로그램하라고 하겠다. 주희의 근사록이라는 책이 있다. 말 그대로 "가까운 것들에 대한 생각을 적은 기록"이라는 말이다. 공부는 무릇 가까운 곳에서 시작해야 한다고 말한다. 내 삶 속에서 제대로 구현되지도 않으면서 우주를 걱정하는 것은 "위기지학"(자기를 위한 공부)을 하라는 가르침에 어긋난다.

철학적인 언설을 떠나, 이것이 어떤 의미가 있으며, 왜 중요한가.

프로그래밍의 궁극은 "사용자"와 프로그램의 사용을 통해 그가 받는 "현실적 가치"에 있다. 프로그래밍을 하면서 사용자를 생각하지 않는 것은 도무지 아무 의미가 없다. 프로그래밍이라는 행위 자체가 성립하질 않는다. 골방에 틀어박혀 자기만족적인 지적 유희를 즐기는 해커가 아니라면 말이다. 우리는 사용자의 마음을 꿰뚫어야 한다. 여기에 있어 직접 사용자가 되는 것만큼 좋은 방법은 없다. 업계에서 혹자는 요구사항 분석시 사용자와 한 달 간 같이 생활해 보라는 말도 한다.

자신을 위한

자기 삶에서 의미가 있는 프로그램을 만들게 되면 스스로가 사용자가 된다. 목적이 분명해 진다. 자기가 편한 프로그램을 만드는 것이다. 이 프로그램은 꼭, "내가 쓸 마음이 나는 프로그램"이어야 한다(그 프로그램을 만들고 싶은 열정이 생기고, 그걸 생각하면 가슴이 두근거린다면 더더욱 좋다 -- 이런 호기가 있을 때 그것을 충분히 누리도록 하라). 아무리 간단한 프로그램일지라도 나에게 가치있는 프로그램은 존재한다. 특정 언어에 대한 경험이 한 두 달일지라도 분명 그런 프로그램을 만들 수 있다. 대부분은 다른 프로그램들을 엮어주는 것일지도 모른다. 만약 난관에 부딪혔다면 책을 읽고, 사람에 묻고 자료를 검색해서 기술과 도구를 배우면 된다.

이 프로그램을 개발해서 일주일이고, 한달이고 매일 매일 사용해 봐야 한다. 일주일에 한 번 사용하는 프로그램을 만들기보다 매일 사용할만한 프로그램을 만들라. 자신이 하는 작업을 분석해 보라. 무엇을 자동화하면 편리하겠는가. 그것을 프로그램 하라. 그리고 오랜 기간 사용해 보라. 그러면서 불편한 점을 개선하고, 또 개선하라. 때로는 완전히 새로 작성해야할 필요도 있을 것이다(see also DoItAgainToLearn). 아마도 이 단계에서 스스로를 위한 프로그램을 작성하다 보면 아이콘을 이쁘게 하는데 시간을 허비하거나, 별 가치없는 퍼포먼스 향상에 시간을 낭비하지는 않을 것이다. 대신 무엇을 프로그램하고 무엇을 말아야 할지, 무엇을 기계의 힘으로 해결하고 무엇을 여전히 인간의 작업으로 남겨둘지, 즉, 무엇을 자동화할지 선택하게 될 것이다. 또한, 같은 문제를 해결하는 여러가지 방법(기술, 도구, ...) 중에서 비용과 이익을 저울질해서 하나를 고르는 기술을 익히게 될 것이다.

사실 이 단계에서는 꼭 어떤 사용을 전제로 하지 않더라도 열정을 갖게 해주는 프로그램이라면 괜찮다. 어떤 것에 대해 호기심이 생기는가? 컴퓨터로 실험을 해보고 싶은가? 그 생각이 밥을 먹거나, 잠을 자거나 떠나지 않는다면 프로그램 하라. 그냥 이걸 프로그램하면 공부가 될 것 같다든가, 혹은 남들이 다 하길래 한다든지 하는 것과는 질적으로 다른 경험을 할 것이다. 열정을 가진 것은 대부분 가슴 속에 그 모양이 이미 형성이 되어 있다. 조각가는 조각품의 형상을 이미 가슴 속에 품고 있다. 최한기는 이것을 강조한다. 일이 제대로 이루어지려면 그 일을 흉중에 품고 있어야 한다고. 머리 속에서, 정말 손끝에 잡힐 것만 같고, 그 프로그램이 살아있는 것 같이 느껴진다면 프로그램 하라. 자신의 아이디어를 컴퓨터가 이해하는 언어로 표현해 내는, 그리고 그 프로그램이 자신의 아이디어를 더 발전시키게 하는 능력을 갖게 될 것이다.

타인을 위한

이 과정이 어느 정도 되면, 타인을 위한 프로그램을 작성할 수 있다. 나에게는 별 의미가 없지만 남에게 "아주 귀중한 가치를 주는" 프로그램을 만들어라. 서로 만들어줘도 좋다. 자신이 컴퓨터 공학과라면 국문학과 학생에게 프로그램을 만들어주라. 그와 가까이 지내고 그가 진정 원하는 것이 무엇이며, 진정 필요로 하는 것이 무엇인지(원하는 것과 필요로 하는 것은 다르다) 분석하고, 프로그램 해줘라. 그가 그 프로그램을 한 달 이상 사용하는가? 그래야 한다. 그 정도로 가치있는 프로그램이어야 한다. 가치있는 프로그램이 꼭 복잡하거나 거대할 필요는 없다. 그가 프로그램의 수정을 요구한다면 가능하면 모두 들어주어라. 그게 힘들다면 그를 납득시켜라. 아마도 이 단계에서 타인을 위한 프로그램을 작성하면서 "작성자"와 "사용자"간의 프로그램을 통한 커뮤니케이션의 중요성에 눈을 뜨게 될 것이다. 인터페이스에 대해 고민할 것이다. 얼마나 이쁘냐보다, 얼마나 실수할 행위유발성을 제공하지 않느냐, 그리고 어떤 메타포를 사용할 것인가(이에 대해서는 비지칼크란 프로그램을 연구하라) 하는 문제를 생각할 것이다.

타인들을 위한

이 단계를 거치면 이제는 타인들을 위한 프로그램을 작성한다. 일단 사용자가 다수이다. 또, 어떤 사용자 집단을 상정할 수는 있지만 개개인을 전제할 수는 없다. 아마도 이 단계에서는 평균적 사용자에 대해 고민하게 될 것이고, 때로는 여러사람의 동시 사용자로 야기되는 동시성 제어나 퍼포먼스 문제로 고민할 것이다. 그리고 프로그램의 크기가 커지면서 그리고 요구사항 변경이 여러 소스를 통해 빈번히 들어오게 되면서 어떻게 설계해야 하느냐는 문제로 고민할 것이다.

결어

프로그래밍 기술보다도 중요한 것은 어쩌면 현실세계의 문제를 해결하는 것 그 자체일지도 모른다(도구와 기술은 본질적 문제를 해결해 나가는 과정으로서 필요에 따라 공부하면 되겠다). 우리는 정말 사용자를 위한 프로그램을 만들어야 한다. 그리고 이 공부는 가까운 곳에서부터 출발한다.

--김창준