나빌레라의 블로그

7. 동사 명사의 정리
지난 글에서는 사용자 시나리오에서 동사와 명사를 아무 생각없이 기계적으로 분리하는 작업만 수행했다. 이번 글에서는 그렇게 분리한 동사와 명사를 무언가 프로그래밍의 재료로 사용가능한 정도의 의미를 가질 수 있는 존재로 만들기 위한 작업을 수행하는 과정에 대해서 이야기를 해 보겠다.

계속 강조하고 언급하는 내용이지만 이 글에서 수행하는 절차는 전혀 학문적으로 검증되지 않았고 완전하지 않다. 실제 프로젝트 작업을 진행할 때는 학문으로 정리된 정식 SE적 절차를 거쳐서 작업하는 것이 더 효율적이고 효과적이다. 다만 나는 그런 SE적 절차에 대해서 제대로 지원을 받을 수 없거나 혼자하는 프로젝트에까지 그렇게 팍팍한 기준을 적용하고 싶어하지 않는 사람들을 위해서 내가 일반적으로 혼자 프로그래밍하고 놀때에 작업하는 과정에 대해서 글로 가볍게 써 나가고 있는 것임을 확실히 인지하고 이 글을 읽어주기 바란다.

먼저, 지난 글에서 분석했던 명사와 동사를 모두 모아본다.

6. 시나리오 분석
컨셉은 잡았지만 이제 프로그램을 어떻게 만들고 어떤식으로 설계해야 할지 모르겠는 사람들에게 내가 추천하는 방식이 시나리오 방식이다. 내가 만들고자 하는 프로그램이 어떤식으로 돌아가는 지를 그냥 머릿속에서 떠오르는 대로 아무런 부담도 제약도 없이 적어 놓고서 그것을 분석하면 된다. 내가 머릿속에 떠오르는대로 마구잡이로 적어놓은 시나리오는 저번에 쓴 글에 있다.

이제 그 시나리오를 하나하나 분석해 보겠다. 분석의 방법은 간단하다. 시나리오를 하나씩 읽으면서 정적객체와 동적객체를 분리해 낸다. 정적객체와 동적객체는 우리가 쓰는 언어의 명사와 동사를 생각하면 된다. 생각보다 아주 쉬운 작업이다.

1. 사용자는 서비스에 접속한다.
명사: 사용자, 서비스
동사: 접속하다.

2. 그냥 접속하면 게시판의 글을 읽을 수 있지만, 글을 쓸 수 없다.
명사: 게시판, 글
동사: 접속하다, 읽다, 쓰다, 쓸 수 없다.

5. 시나리오
기획자가 있다면 멋드러진 기획서와 스토리보드, 유저 시나리오등을 만들어서 설계자한테 보낼테고 설계자는 이를 바탕으로 유즈케이스와 객체 및 시퀀스 모델링등을 할 것이다. 그리고 상세 설계에 들어가서 자료구조와 메소스(함수) 수준의 설계가 이뤄지고 이를 바탕으로 본격 코딩 작업이 들어간다. 코딩이 어느정도 완료 되면 때로는 설계 변경을 할 때도 있고, 디버깅 및 테스트를 거친후에 릴리즈하게 된다.

4. 공부하기
다른 직업도 이런지는 모르겠지만, 개발자는 은퇴하는 그날까지 끊임없이 새로운 기술을 공부해야 하는 슬픈 운명을 타고난 직업이다. 개발자라는 직업이 이렇게 지속적으로 피곤한 직업인줄 진작 알았더라면 나는 아마 다른 직업을 택했을 것이다. 지금도 늦지 않았다는 생각은 항상하지만 배운게 도둑질이라는 옛말대로 다른 할 줄 아는 것이 별로 없어서 오늘도 이렇게 프로그래밍을 하며 공부를 하며 짬짬히 글을 쓴다.

지난 글에서 웹 프로그래밍을 하기로 결정했다. 나는 2006년 즈음에 PHP와 야후에서 만든 yui라는 자바스크립트 라이브러리를 이용해 웹 프로그래밍을 해봤다. 물론 당시 등록금을 벌기위함이었다. 이것이 내가 마지막으로 웹 프로그래밍을 했던 경험이다. 그때 이후로 웹 프로그래밍은 잘 만들어진 프레임워크를 이용해 개발하는 것이 대세가 되었다.

3. 생각하기
스쳐지나가는 모든 상황에 관심을 기울이며 무엇을 해볼까를 생각하다보면 "이건 이러해서 안될 것 같고.."하는 식으로 후보를 계속 제외시키다가 어느 순간 "이건 재미 있을 것 같다!"하는 아이템이 떠오르는 순간이 온다. 다만 "이건 이미 있는 것이라서"라는 이유로 아이템을 제외해서는 안된다.

이 글을 쓰면서 나도 뭔가 개발 아이템을 생각해 보겠다고 썼었다. 내가 새로운 프로젝트를 진행하는 과정을 글로 쓰면, 이 글을 읽는 여러분은 자신만의 힌트를 얻을 수 있을 것이라 생각했기 때문이다. 그래서 이런 저런 생각을 해봤다.

2. 관심
어떤 사람이 구글 본사에 방문해서 구글 엔지니어랑 이야기 하던 중 햇빛에 비춘 창틀 모양을 보고 구글 엔지니어가 창틀 모양의 패턴에 대해 언급하면서 프로그래밍의 패턴에 대해서 이야기 했더란 아주 오래된 글이 생각 났다. 누가 보면 참 오덕 스럽다고 말 할 수 있겠지만, 나는 그것이 관심이라고 생각한다.

돈을 벌기 위한 프로그래밍을 할 때는 사실 크게 관심가질 필요가 없다. 관심은 기획부서에서 가지면 되는 것이고, 우리는 기획부서에서 만든 기획서를 검토해서 실체화가 가능한 수준으로 요청서를 만들면 된다. 돈을 벌기 위한 프로그래밍을 할 때는 어떤 프로그램을 만들어야 하는지에 대한 관심보다는 어떻게 프로그램을 만들어야 하는지에 대한 관심이 더 필요하다.

하지만, 돈을 벌지 않아도 상관없는 개인 프로젝트를 위한 프로그래밍을 할 때는 어떤 프로그램을 만들어야 하는지에 대한 관심을 가져야 한다. 그러기 위해서는 일상 생활에서 지나치는 많은 일들을 그냥 지나가는 것이 아니라 내가 하고 싶어하는 일에 대해 연관지어 생각하는 관심이 필요하다.

1. 원칙
군대를 전역하고 복학하기 전까지 아무런 할 일 없이 놀고 있을 때가 있었다. 그 때, 나는 내 삶의 큰 원칙을 하나 세우게 된다.

[돈을 벌기 위한 프로그래밍 외에, 언제나 항상 내 개인 프로젝트를 하자.]

처음에는 삼 일짜리. 일 주일짜리로 자잘하게 하다가 어느 날 크게 마음 먹고 일년짜리를 했었다. 그 일년 동안 물론 나는 학교도 다니고 알바도 하면서 돈을 벌기위한 프로그래밍을 동시에 했다. 그리고 그때까지 개인 프로젝트는 항상 프로그래밍이었는데, 그 이후로 개인 프로젝트의 범위를 넓혀서 글을 쓰기 시작했다. 그 성과물로 나온 것이 내 첫 저작물(http://insightbook.springnote.com/pages/2780056)이다.

그리고 개인 프로젝트를 할 때는 항상 내가 할 줄 모르는 분야나 내가 할 줄 아는 분야라 하더라도 내가 해보지 못했던 기술적 요소를 꼭 집어넣어서 목표를 세웠다.

나빌레라의 프로그래밍 하기

0. 시작
나는 소프트웨어 프로그램을 만들어 돈을 받는다. 그 돈으로 전세자금 대출도 갚고, 밥도 사먹고, 데이트도 하고, 각종 공과금과 교통비등 생활비를 감당한다. 소프트웨어 프로그램을 만들어 돈을 벌어 먹고 살고 있으니 내 직업은 소프트웨어 프로그래머라고 볼 수 있다. 우리말로는 소프트웨어 개발자라고도 한다. 프로그래머와 개발자라는 두 단어 중 딱히 선호하는 단어는 없지만, 앞으로 이 글에서는 나와 같은 일을 하는 사람들을 모두 통칭해서 개발자라고 부르겠다. 앞에 소프트웨어라는 단어는 붙이지 않겠다. 이 글을 읽는 사람들은 대부분 소프트웨어 개발자일테니까.

#26. 마무리

긴 이야기가 끝났다. 이 이야기를 시작할 때 했던 내용을 모두 다 다루었던것 같다. 처음 예상은 지금까지 다루었던 이야기보다 훨씬 짧은 분량이었는데 축약하고 축약해서 정말 대충 넘어가듯 썻음에도 분량이 꽤 많아져서 무려 25회나 연재했다.

#25. 위그드라실

위그드라실은 북유럽 신화에 나오는 세상을 떠 받치고 있는 거대한 나무다. 이 거대한 나무의 세 줄기에 인간 세상, 지하의 세상, 신들의 세상으로 뻗어 있다. 소프트웨어의 세계에서 위그드라실같은 존재가 운영체제다.