또다시 혼란에 빠졌습니다.

1. 프로그래밍을 처음 시작했을때에는 그저 실행만 잘 되면 좋았고,
2. 조금 경력을 쌓다보니 각종 개발방법론들에 열광하다가,
3. 이제는 현실의 상황과 저의 무식함을 깨닫고는 각종 개발방법론에 회의를 느끼는 단계에 접어 들었습니다.

갈수록 실용주의프로그래머 라던가, XP나 애자일 등이 종종 귀에 들리는것도 대부분 실무 개발자들이 비슷한 생각을 가져서 인지도 모르겠습니다.

뭐 하여간 그동안 신봉해왔던 (혹은 남들도 신봉해왔기 때문에 협업시 표준을 지킬수 밖에 없는) 기존 개발방법론들이 다시 생각되어지고 있다는건 좋은데, 그렇다고 해서 또 다른 개발방법론들이 대안으로 쏟아져 나오는것도 맘에 안든다 이겁니다.

따라서 몇년 안된 경험이지만 그동안 일하면서 생각해왔던 여러가지 룰을 정리하고 제 나름의 개발(?)방법론으로 정리해보고자 합니다.

* 참고로 웹개발쪽을 주로 참여했으므로 국내 웹개발 시장에서 발생하는 SI 혹은 SM에서만 해당되지 않을까 생각되네요..


1. IT를 모르는 사람과는 일하지 말아라.
그동안 여러 프로젝트에 참여하면서 나름대로 성공적이었다고 느껴진 프로젝트는 전부 고객 혹은 고객사의 컨텍포인트가 IT에 대해 잘 아는 사람들이었습니다. 잘 알기에 환경과 현실에 맞게 요구사항도 정확했고 업무의 끝맺음도 명확했으니까요. 거기다 고급기술 등에 대한 비용처리도 명확하다는거죠. 반대로 잘 모르는 사람과 일했을 경우 개발초기 요구사항 자체가 뜬구름인 경우가 많으며, 개발이 완료되고 실제 운영이 한참 지난 후에서야 결과물이 이렇게 돌아가는지 느끼고는 수정사항을 제시하기 일쑤였습니다. 게다가 고급기술에 대한 비용을 인정해 주지도 않죠. 모르니까....

2. 업무 진행 내용을 고객에게 매일 같이 알려라.
이건 제 성격상 거의 항상 고객과 다이다이 붙어서 일을 진행하는데, 눈만 마주치면 개발하면서 발생한 여러가지 이슈들을 거침없이 얘기합니다. 물론 그 사람들은 100%이해는 못하지만 뉘앙스에서 대충 일이 몇% 진행되었고 여러가지 개발적인 이슈들을 함께 점검할 수 있습니다. 실제로 이런방식으로 일해온 프로젝트가 결과물적으로 다 성공적이거나 한 건 아니었지만, 고객본인은 스스로 개발에 참여했다는 느낌이 있어서인지 만족도 자체는 높은편이었고, 개인적인 친분관계로도 인맥을 쌓는 계기도 되었습니다. 여태까지 이건 개인적인 성격때문에 생긴 장점이 아닌가 했지만, 오픈마루의 애자일 경험에 대해 설명한 포스트 중 "짝프로그래밍"에 대한 내용이 있는데, 이걸 보는순간 함께 일한다는 것에 대한 장점은 누구나 느끼는 것이라는 확신이 들더군요...

3. 히스토리를 관리하라.
업무에 참여한 시작부터 모든 히스토리를 기록하세요. 기록해야할 정보는 되도록이면 많은것을 기록하되, 가장 우선할것은 고객과 주고받은 대화나 데이터를 모두 기록하는 것입니다. 여러가지가 있겠지만 개인적으로 겪어본 경험중 히스토리의 장점은 비지니스 혹은 개발 이슈 때문에 어떤부분이 심하게 복잡해지거나 꼬이게 되는 경우가 많은데, 이 원인을 몇 년 후에도 쉽게 찾아 볼 수 있어 삽질의 반복을 줄일 수 있다는 점입니다. 어느정도 규모의 SI나 에이전시라면 보통 고객용 프로젝트 사이트는 운영하고 있으며, 요즘엔 trac이나 sharepoint등도 많이 사용하고 있는데.. 개인적으론 sourceforge나 codeplex, googlecode 등의 프로젝트 관리 사이트 카피본을 설치해 쓰면 이슈트래킹과 버전관리도 함께 할 수 있어서 좋다고 생각되네요.

4. 경영과 운영을 고려하여 개발하라.
시스템이 우선인 소프트웨어는 거의 없습니다. 비지니스 룰의 변화는 시스템 환경을 고려하지 않습니다. 고객의 요구는 언제나 빠르게 적용되길 바라며, 코드의 난잡함에는 관심이 없습니다. 개발자의 불만은 항상 여기서 터져 나오지만, 우리 개발자들은 현실을 직시해야합니다. "우리는 영원히 [갑]이 되지 못한다는 걸" 
따라서 우리는 스파게티 코드와 짬뽕 데이터에 대한 해결책을 스스로 떠안고 해결책을 생각해내야만 합니다. 여기에 대한 해결책으로 하위분류를 해보겠습니다.

4-1. ERD 특히 논리ERD는 무조건 그리되, 확장성을 제1순위로 고려하라.
비지니스 룰을 분석하고 데이터의 흐름을 따라 가는데 있어서, 논리ERD만큼 명쾌한 문서가 없습니다. 뭐 문서라면야 있으면 좋은 문서들이 수도 없이 많지만 가장 코드에 가까우면서도 고객과 의견교환을 할 수 있는 문서는 역시 ERD만한게 없죠. 그리고 설계시에 "절대 변하지 않는 테이블"은 절대 없다는 것을 명심하고 항상 확장성을 염두에 두고 설계하라는 겁니다. 4번에 경영과 운영을 고려하여 개발해야 하니 비지니스 룰이 밥먹듯이 변화하고, 이에 따라 데이터의 변화는 필수불가결하기 때문이죠.

4-2. IT시장에 가장 많은 인력이 관리 할 수 있는 수준으로, 확장성을 고려하여 시스템을 구축하라.
사실 대부분 개발자들이 자신이 보유한 기술의 자부심이 대단해서, 온갖 화려한 기술들을 실무에 적용하고자 하는 일종의 장인정신(?)이 있습니다. 게다가 IT쪽 인력시장이 이직이 매우 높아서, 한 프로젝트에 각자 한가닥 하시는 분들이 소스에 화려한 실력들을 자랑해 놓은것을 보고 경악해본 경험이 모두 한번쯤은 있을 겁니다. 그리고는 또 이직의 반복... 역시 경영과 운영 측면에선 손해가 극심합니다. 실례로 제가 예전에 포스트한 웹2.0에 대한글에 보면 이베이의 사례가 있는데, 기술력의 선구자라 해도 경영논리에 의해 짤리는 현실을 느꼈던 사례였습니다. 예전에 볼랜드 투게더 세미나에 갔을 때도 KAIST교수가 MDA에 대해 설명하면서 80%정도의 코드퀄리티지만 누구나 개발에 참여할 수 있어 경영적은 측면에서 도움이 된다는 강연을 듣고 "이제 개발자 몸값 떨어지겠구나 ㅠㅠ"라고 생각한 적도 있었습니다. 뭐 여기에 대해 부가로 하고 싶은 말이 많지만 지면상(?)생략 하도록하고.. 하여간 개인적으론 전산과 갓 졸업한 신입사원이 1달정도 놀면서 공부해서 실무개발 할 수 있어야 한다는게 개인적인 생각입니다.

4-3. 코드나 데이터의 일관성을 유지하라.
상당히 많은 의미로 해석될 수 있는데, 네이밍룰이나 개발방식 등을 항상 일관성 있게 유지하라는 뜻입니다. 초기에 잡은 네이밍룰이나 설계가 틀렸더라도 일단 일관성 있게 개발해왔다면 언제든지 일괄작업으로 한번에 변경 가능하기 때문입니다. 그리고 가독성 측면에서도 일관성이 유지된 데이터가 훨씬 좋다는건 뭐 말할필요도 없겠죠.

생각나는건 많은데 정작 정리된건 거의 없었네요.

경험적 측면에서 적어본 글인 만큼 이 포스트도 앞으로 더 경험해 나가며 업데이트 해나가야 될것 같습니다.
역시나... 고객(나)의 요구는 상수가 아니라 항상 변수니까요...