글쓰기와 프로그래밍 – 방법론은 있습니까?
이번 겨울계절학기에 '논리와 비판적 사고'라는 과목을 수강했다. 무려 3년 반만에 돌아온 학교와 수업들은 녹록치 않았으나 큰 신고식을 치르고 어찌어찌 종강을 했다. (어저께)
이 수업은 상당히 독특하면서 실용적이었는데, 연역논증, 귀납논증 등등의 이론적 내용은 비교적 간단하게 배우고 실제 상황에 적용하는 훈련을 많이 한 것이 인상적이었다. 강의 중반부터 이어진 '논리 문제 만들어서 발표하기', '칼포퍼식 토론회', '문제해결적 글쓰기' 3단 콤보는 지적으로 challenging 하면서도 흥미로운 경험이었다. 생활 속의 논리적, 비판적 사고를 느껴볼 수 있었다고나 할까.
기말 최종 과제는 문제해결적 글쓰기였는데, 토론회에서 다루었던 '한반도 대운하'에 대해 입장을 정리하는 것이었다. 나는 토론회 때 (가위바위보 져서) '찬성' 조에 있었기 때문에 글쓰기도 찬성 입장에서 했다. (할 수밖에 없었다.) 글을 쓰는 것도 정해진 기법에 따라서 진행하도록 설계된 과제였는데, 하나의 완성된 글을 이렇게 빨리 써본 적이 없는 것 같다.
논증구조와 개요작성이 너무나도 치밀하게 되어야만 글쓰기로 넘어갈 수 있게 설계되어 있는 글쓰기 프로세스였다. 우선 논증구조에서는 실제 글에 사용할 논증을 논리적 허점이 없도록 3, 4단계까지의 세부논증으로 탄탄하게 구성했다. 이 과정에서 비약이 생기지 않도록 연관관계를 검증하고.. 개요작성에서는 실제 문단의 순서에 맞게 어떤 포인트를 살려서 쓸 것인가를 배치하고 가다듬었다.
이렇게 준비과정이 끝나고 나니 글쓰기는 그냥 차려놓은 밥상에 있는 밥을 주워먹는 것처럼 쉬웠다. 빈칸 채워넣기 같은 느낌?
프로그래밍을 할 때도 설계가 잘 되어 있으면 실제 코딩 작업은 이렇게 빈칸 채워넣기 같은 느낌이 아닐까? 물흐르듯 글이 술술 써지는 느낌을 코딩에서도 느끼기 위해서는 결국 앞의 작업들, 설계와 분석 단계가 중요할 것이라는 생각이 든다. 물론 이러한 생각을 가지고 설계하고 코딩하려는 시도를 했던 적도 더러 있었는데, 별로 성공적인 경험은 아니었다. 돌아보건대 설계와 분석이 미흡했기 때문인 것 같다. 결국 성공했던 경험과 그렇지 못했던 경험 사이의 차이는 방법론이 아니었을까. 어떠한 방법론을 통해 문제에 접근하는가 생각 이상으로 중요하다는 생각을 한다.
- 마인드도, 방법론도 없는 상태
- 마인드는 있는데 방법론은 없는 상태
- 마인드는 없지만 방법론은 있는 상태
- 마인드도, 방법론도 있는 상태
나는 그 동안 2번에 천착되어 있었던 것 같다. 항상 새로운 것을 적용하고 보다 효율적으로 해 보고 싶은 마음가짐은 충만했지만, 적절한 방법론을 practice에 옮기고 실행해 보지는 않은 상태. 그러면서 나는 열려 있으니까, 이건 당연히 되는 걸거야, 단지 행동에만 옮기지 않은 것뿐. 이라는 자기 위안을 삼았는 지도.
클래식이라 부르기에 손색이 없는 토마스 쿤의 과학혁명의 구조에서 인상깊게 파악했던 부분이 생각난다. 이론을 보는 것이 아니라 문제를 먼저 풀라는 말. 문제 속에 이론이 있고, 문제를 해결하는 데 도움이 되지 못하는 이론은 쓸모 없는 것이라는 말.
WoC 프로젝트를 통해 새로운 방법론을 가지고 실험을 해 보려고 한다. 멋진 멘토님이 계시니 무언가 되지 않을까 하는 막연한 기분좋은 기대를 해 본다.
[이벤트] 열씨미와 게을러의 리눅스 개발 노하우 탐험기 시즌 2
임베디드 개발자로 3년을 일하면서 임베디드 리눅스에 대해 가장 먼저 접했던 책이 바로 '임베디드 리눅스'이다. jhrogue 님이 쓰신 이 책을 보고 여러 모로 도움을 많이 받았었다. 책을 쓰시는 방식도 상당히 꼼꼼해서 기억에 남았던 기억이 난다. 그 이후로는 IBM developerWorks에서의 개발자 책꽂이 column 이나 블로그를 통해 접할 수 있었다.
이번에 새로 책을 쓰셨다는 소식을 RSS를 통해 듣고는 가봤는데 이벤트를 하신단다. 책 제목은 '열씨미와 게을러의 리눅스 개발 노하우 탐험기'라고 하는데, 좀 길기는 하지만 참신한 느낌이다. 아무튼 이벤트 참여가 재밌어 보여서 죽어가던 내 블로그에 이런 식으로라도 간만에 글을;; 우선 책의 디자인이나 목차를 보고는 상당히 맘에 들었다. 우리나라에 더 있어줬으면 하는 부류의 책이겠구나 하는 생각 때문에. Well-written 책이라고 생각하는 유닉스, 리눅스 프로그래밍 필수 유틸리티' 와 약간은 비슷한 접근을 하고 있으면서도 보다 프로그래밍 흐름 자체에 초점을 맞춘 느낌이 들었다. 리눅스 환경에서 프로그래밍을 하는 데에 있어서 모르면 괴롭거나 안되는 것들, 알면 정말 도움되는 핵심 요소들을 모아 놓은 느낌이다. 타겟은 초급 혹은 초중급 개발자인 것 같다.
이 책의 후속편을 만든다면 어떤 내용을 담으면 좋을까? 우선 나의 경험을 생각해 보았다. 나의 경험에서는 오픈소스 패키지들을 내가 작업하는 시스템에 통합시키는 작업이 가장 많은 시간을 요하고 또 삽질을 유발하는 작업이었다. 시즌 1에서 기본적인 프로그래밍 환경과 툴들을 다루었다면, 시즌 2에서는 오픈소스 패키지 활용에 대한 내용을 엮으면 어떨까 하는 생각이 든다. 프로그래밍 과정도 결국에는 여타의 과학 분야처럼 뉴턴의 말마따나 '거인의 어깨 위에 서서' 하는 것이니 말이다.
독창적인 프로그램을 만드는 것만큼이나 기존에 구현되어 있는 특화된 기능 block 들을 어떻게 조립하느냐가 요즈음과 같은 모듈화와 API(Application Programming Interface) 시대에 필요한 스킬이 아닐까 싶다.
요약하면, 시즌 2에서 다루어 주었으면 하는 내용은
- 다양한 오픈소스 패키지 활용법 (웹서버, FTP, SSL, SSH 관련)
- 오픈소스 라이브러리 활용법 (내 프로그램에 integrate 하기)
- 다양한 모듈 / 패키지 통합해서 하나의 완성된 시스템 만들기
등이 되겠다. 이거 보통 일이 아니겠는데 -_-;;; 좀 더 욕심을 내면 오픈소스 개발에 참여하기라든가 커뮤니티 활동하기 등도 다루어볼 수 있지 않을까 싶다.
Joel on Software
조엘 온 소프트웨어
유쾌한 오프라인 블로그
Joel Spolsky
박재호 이해영 옮김
에이콘
참 많은 정보들이, 재미있게 구성되어 있는 책이다. 이런 것들이 가능한 것은 조엘이 가진 통찰력과 분석력이 글솜씨와 경제/경영 등의 비공대적 감성과 조화를 이루었기 때문이다. 읽으면서 이것저것 기억해 두고 싶고 더 알아보고 싶은 것들이 많아서 엄두가 안 났었는데, 드디어 읽은지 몇달이 지난 오늘에서야 이 책을 정리하게 되었다.
번역서의 장점을 최대한 살린 책이다. 번역서가 이 정도의 꼼꼼함과 퀄리티를 보여준다면 원서보다도 더 메리트가 있겠다는 생각을 했다. 책 중간중간에 실린 역자의 생각과 풍부한 배경지식은 블로그라는 환경에서 작성되었기 때문에 다분히 개인적이고 문화적 색채가 짙은 Joel on Software의 놓치기 쉬운 작은 부분까지 이해할 수 있도록 도움을 주었다.
'Advice for Computer Science College Students'라는 포스트에 소개된 7가지 항목 중 가장 와닿는 것은 '졸업 전에 미시 경제학을 공부하라는 것이다. 공대생도 경제, 경영 지식 없이는 세상을 읽는 시야가 좁아질 수밖에 없을 것이다. 요즈음 경제학에 관심이 생겼는데, 좀더 제대로 배워보고 싶어졌다. 이러한 생각을 가진 저자의 경제 관련 언급 중 기억에 남는 것은 '시장에서는 부가가치가 더해진 만큼 대가를 지불한다'는 것이다. 미국에서 극명하게 느낄 수 있었다. 수퍼마켓에서 사는 음식은 아주 싸지만 레스토랑에서의 음식은 끔찍하리만큼 비싸다. 또한 직접 운전할 때 기름값은 싸지만 택시는 엄청 비싸다. 눈에 보이는 것만큼의 가치가 아닌, 부가가치야말로 더 큰 가치를 가지고 있는데, 나는 보이는 쪽에만 너무 치중했던 것 같다.
버그 데이터베이스에 포함되어야 할 필수 요소
- 버그를 재현하기 위한 완벽한 단계
- 예상 수행 결과
- 관찰한 (버그로 간주되는) 실제 수행 결과
- 수정을 맡을 개발 책임자
- 수정했는지 여부
종이로 프로토타입을 작성하라
시간 인터럽트 관리하기
- 인터럽트 당하는 시간과 일에 복귀하는 시간을 기록하라
- 사람이 일에 몰입하기까지는 15분이 소요된다
- 보통 11분을 못 넘기고 인터럽트를 받는다
오픈소스 경제학
보완재는 특정 제품과 함께 구매하게 되는 제품이다. (컴퓨터+OS, 항공권+호텔숙박)
보완재 가격이 하락하면 제품 수요가 증가한다.
(항공권 가격이 하락하면 호텔 수요가 증가한다 / 컴퓨터 가격이 떨어지면 OS 수요가 증가한다)
똑똑한 회사는 자사 제품의 보완재를 일반 재화로 만들려고 애쓴다.
1. IBM이 오픈소스 소프트웨어 개발에 수백만 달러를 투자한다
-> IT 컨설팅 회사로 변모하려는 IBM의 입장에서 IT 컨설팅은 기업용 소프트웨어의 보완재이다.
기업용 소프트웨어를 일반재화로 만들어야 한다.
2. CPU 회사인 트랜스메타 사가 리누스를 고용해서 리눅스를 손보다
3. 썬과 HP가 지미안을 고용해 그놈을 손보다
4. 애플이 무료 소프트웨어인 iTunes를 더더욱 강화시키기 위해 투자한다
-> 하드웨어인 iPod의 수요를 늘리는 데에서 그치는 것이 아니라 iTunes와 연동되는 음악/영화/게임의 수요까지 증가시킬 수 있다. 애플로서는 iTunes에 더 투자하는 것이 일석이조의 전략이 될 것이다. 이렇게 복합적인 이익을 이끌어내는 능력을 애플이 갖추었기 때문에 승승장구하는 것이다. 맥에서도 마찬가지로 Intel 코어로 바꾸고 Bootcamp를 지원함으로써 비슷한 효과를 얻을 수 있다.
5. 썬 사는 자바를 개발한다
-> 자바의 바이트코드 시스템은 한번 작성하면 어디서나 실행이 가능하다. 얼핏 생각하면 이를 통해 운영체제가 일반 재화가 될 것 같다. 그러나 운영체제 뿐이 아니라 하드웨어 자체가 일반재화가 되어 버린다. 하드웨어 회사인 썬 사가 자바를 개발함으로써 하드웨어를 일반 재화로 만든다. 뭔가 이상하지 않은가? 하드웨어 회사가 하드웨어를 일반재화로 만드는 것은 무덤을 파는 일이다!! 또한 썬 사는 스타오피스, 리눅스, 아파치, 그놈 등 무료 소프트웨어 개발을 장려해서 소프트웨어를 일반 재화로 만든다. 이렇게 두 가지 전략으로 모든 제품을 일반 재화 가격으로 팔 수밖에 없게 될 수 있다.
소프트웨어 입장에서 하드웨어를 일반 재화로 만들기는 쉽다.
그러나 하드웨어 입장에서 소프트웨어를 일반 재화로 만들기는 어렵다.
하드디스크를 뽑아서 다른 컴퓨터에 장착하는 것은 쉽다.
그러나 익스플로러를 쓰던 사람이 파이어폭스로 옮기는 비용이 0이 아니라는 이야기이다.
API는 왜 중요한가? 사람들이 윈도우를 사용하는 이유를 생각해 보면 알 수 있다. 리눅스/맥이 아닌 윈도우가 (아직) 세상을 지배하는 건 윈도우에 응용프로그램이 훨씬 많기 때문이다. 따라서 이러한 응용프로그램의 개발을 장려하는 것이 OS 회사의 입장에서는 매우 중요하며, 이에 필수적인 API는 MS의 중요한 자산이다. API는 운영체제에게 일을 시킬 수 있는 인터페이스 집합이다. 이를 통해 손쉽게 복잡한 기능을 해당 운영체제 상에서 구현할 수 있다. 조엘은 MS가 효율성을 위해 하위호환성을 포기하면서, 또한 웹과 HTML의 시대에 맞는 API를 제공하지 못하면서 API 전쟁에서 패배할 것이라 경고하고 있다. '새 API는 HTML 입니다. 응용 프로그램 개발 시장에서 새로운 승자는 HTML을 빛내는 기업일 것입니다.'
나에게 적용할 점:
Eddy는 하드웨어를 팔아야 한다. Eddy의 보완재는 무엇인가? SDK와 API, Web Interface, Linux Library 등이다. SDK는 무료로 배포해도 상관 없다는 이야기이다. 마구 뿌려서 최대한 많은 사람이 써야 하드웨어가 많이 팔린다. DK의 가격은 더더욱 낮추고, 아니 무료로 더 주어도 될 것 같다. 손해를 보더라도. 또한 SDK의 보완에 집중해야 한다. 어쩌면 하드웨어 자체보다 더 중요할 수도 있겠다는 생각을 한다.
