한빛출판네트워크

저자: 한동훈
　
시작하기전에

"프로그래밍 스타일"이라는 글로 글을 쓴지 벌써 4년째가 되었고, 글 하나에 많은 일들이 있었다. 첫번째 판이 한빛미디어에 올라왔고 많은 피드백이 있었으나 사이트 개편이후로 여러분의 소중한 의견들이 모두 소실되었다.

두번째 판은 글을 작성했지만 개인 홈페이지를 없앤 이후였고, 한빛미디어에도 올라오지 않았다. 게다가, 작업의 결과물을 모아놓은 하드 디스크의 고장으로 원본 기사를 소실했다. 다행히도 한빛미디어에서 2003년도 백업판을 구할 수 있어서 세번째 판을 작성하기로 마음먹었다. 내용을 확인해보니 서문만 2판이고, 나머지는 1판과 동일했다.

두번째 판은 첫번째 판에 대한 많은 분들의 소중한 의견을 포함해서 개정했었고, 세번째 판에서는 그 이후에 프로그래밍 스타일 뿐만 아니라 개발 환경에 대한 변화를 추가하고 싶었다. 모쪼록 이 글이 프로그래밍을 하는 데 있어 도움이 되기 바란다.

카더라 통신에 의하면 프로젝트 진행시 "코딩 스타일 지침", "프로그래밍 스타일 지침"등에 자주 활용되었더라는 이야기가 있다. :)

서문

프로그래머가 되려는 사람, 프로그래밍을 하고 있는 사람, 모두에게 있어서 긴 논쟁이 되어 왔던 많은 주제들이 있다. 어떠한 언어가 더 우수하다는 것에서부터 프로그래머가 되려면 어떤 것들을 먼저 학습해야 한다는 것에 이르기까지 정말로 많은 주제들이 있다. 그리고 그 중에 하나가 아마도 프로그래밍 스타일에 대한 것일 것이다.

프로그래밍 스타일은 다르게 말하면 함수의 명명 방법이라던가, 들여쓰기 간격, 괄호의 위치와 같이 쓸데 없는 것일 수도 있다. 조금 더 심하게 말하면 "너희는 이것을 따르라"라는 독재자의 명령일 수도 있다. 하지만 프로그래머마다 프로그래밍하는 스타일이 다르기 때문에 프로그래밍 스타일은 프로그래머 각각의 개성으로 받아들여질 수 있는 것이기도 하다. 하지만 혼자서 프로그래밍하는 것이 흔한 일은 아니기 때문에 분명히 어떠한 규칙이 있어야 한다. 그렇지 않으면 저마다 만들어내는 코드들의 모양새가 다르기 때문에 분명히 혼란스러운 모습을 보이게 마련이다. 흔히 말하길, 코드는 ‘읽기 쉬워야 하고’, ‘알기 쉽게 주석은 많이 들어가야 한다’라고 얘기하지만 프로그래밍 스타일에서 다루어야 할 진짜 핵심은 어떻게 하면 조금이라도 더 ‘버그없는 프로그램’을 만들어 낼 것인가라는 것이다. 때때로 다른 프로그래머들이 다음과 같이 말하는 것을 들을 때가 있다.

"전에 회사에서 작성한 코드를 수정해야 하는데, 후임자가 그 코드를 이해하지 못해, 코드를 작성한 자신에게 물어보기 위해 찾아왔다."

자신은 자랑스러운 일이라고 생각한 모양이다. 실제로 그가 작성한 코드에 버그가 있어서인지, 이해하기 어려운 알고리즘을 구현한 것인지, 프로그래밍적 기교를 많이 사용해서 알아보기 어려운 것인지, 그 이유는 모른다. 그러나 다른 사람이 알아볼 수 없는 코드를 작성했으므로 그는 실패한 코드를 작성한 것이 된다. 아마도 이 사람이 작성한 코드는 다른 프로그래머에 의해 보다 읽기 쉬운 코드로 재작성된 뒤에 폐기처분 될 것이다. 그리고 이에 따른 피해는 모두 회사에 돌아간다. 뛰어난 프로그래머와 함께 일한다는 것은 즐거운 일이며, 진정 뛰어난 사람은 다른 사람도 쉽게 알아볼 수 있는 코드를 작성한다.

여기서 이야기 하고자 하는 프로그래밍 스타일이란 ‘어떻게 하면 버그가 없는 프로그램을 만들어 낼 것인가!’, ‘다른 사람이 이해하기 쉬운 코드를 만들려면 어떻게 해야 하는가!’에 대한 것이다. 어떻게 보면 프로그래밍 스타일이라는 것이 독재자처럼 보일지도 모른다. 그러나 여기에 있는 모든 이야기들은 그저 이렇게 하는 것이 좋다라는 하나의 방법론일 뿐, 반드시 ‘그렇게 해야 한다’는 것은 아니다. 여러분의 프로그래밍 스타일은 여러분이 작성한 코드의 길이가 5천줄, 1만줄, 10만줄, 100만줄씩 변해감에 따라 계속해서 변해가게 될 것이다. 1만줄 미만의 코드에서는 아무 문제가 없던 프로그래밍 스타일도 10만줄에서는 문제를 일으킬 수도 있기 때문이다.

끝으로, 이 글에 대해서 ‘옳다/옳지않다’라는 소모적인 논쟁은 하지 않길 바란다. 다만 이것을 참고로 조금이라도 버그 없는 코드를 작성하는 데 도움이 되었으면 할 뿐이다. 리누스는 리처드 스톨만의 GNU 코딩 스타일을 찾아서 불 속에 던져버리라고 하였다. GNU 코딩 스타일에 대한 리처드 스톨만과 리눅스 커널을 작성한 리누스와의 코딩 스타일에 대한 논쟁처럼 소모적인 것이 되기를 바라지 않는다.

이 글을 보는 법

하나의 언어에 대한 이야기가 아니라 프로그래밍에 있어서 공통된 이야기들을 자유롭게 썼다. 독자들의 마음에 드는 부분만을 남겨두고, 마음에 들지 않는 부분은 지워버린다. 추가할 것이 있으면 스스로 추가한다. 이와 같이 하면서 끝까지 읽어간다면 여러분 또는 팀의 프로그래밍 스타일이 완성될 것이다. 이제부터 프로그래밍 스타일에 대한 이야기를 시작해보도록 하겠다.

1. 작업 환경에 대하여

프로그래머에게 작업 환경은 두 가지로 나눌 수 있다. 프로그램을 개발하기 위한 PC와 소프트웨어에 대한 것과 사람이 작업을 하는 환경에 대한 것이다. 두 가지 모두 쉬운 것은 아니지만 때론 사람과의 관계가 모든 것을 좌우하기 때문에 가중치를 둔다면 후자에 두고 싶다. 여기서는 후자의 물질적인 작업환경에 대해 살펴볼 것이다.

1.1 시간을 관리하자

UNIX 시스템에서 프로그램을 개발하여 전국에 있는 시스템 관리자들에게 배포한다는 것은 멋진 일이다. 다른 사람이 개발한 프로그램의 버그를 찾고 수정하는 것 또한 재미있는 일이다. 전산 시스템을 운용한지가 14년 정도 되었는데, 여기서 말하는 14년이란 각기 전산 시스템을 도입하거나 업그레이드 한 시기가 다르다는 것을 의미한다. 내가 개발에 사용한 UNIX 시스템 외에 다양한 시스템들이 존재한다는 것이고 데이터의 한글 처리도 시스템마다 다르다는 이야기이다. 내가 개발한 UNIX 시스템과는 전혀 다른 시스템들도 많았으며, 내 시스템에서 문제없는 프로그램들도 다른 시스템에서는 문제가 발생하기도 했다. 이로 인해 전국의 담당자들로부터 쉴 새 없이 오는 전화 문의에 응답해 주느라 내 업무에는 손도 못 댄 적이 있다. 결국, 다른 한 사람에게 전화 응대만을 전담하고, 회의실에서 하루 5시간 동안 집중적으로 일을 마쳤다. 물론, 용건이나 프로그램에 문제가 있는 경우에도 메모 하도록 한 다음에 나중에 일괄적으로 전달받는 형태를 취했다.

프로그래밍은 단순 노동이 아니라 정신을 집중해서 해야 하는 일이다. 단순히 워드 아르바이트처럼 하루 1시간씩, 하루 10페이지씩 입력하는 일이 아니다. 아주 잠깐 1분 동안 다른 곳에 정신을 팔아도, 내가 지금 어디까지 했는지, 이 부분에 무슨 코드를 넣어야 할지 다시 고민해야 하고 신경써야 한다.

프로그래머들에게 올빼미족이 많은 것은 결코 우연이 아니다. 그들은 아무에게도 간섭받지 않고 모든 것을 잊고, 오직 코드 하나에 집중해서 작업할 수 있기를 바라는 것이다. 그러나 당신이 말단 프로그래머라면 회사에서 이렇게 멋대로(?) 행동하는 것이 어려울 수도 있다. 그렇다면 당연히 윗사람을 설득시킬 수 있어야 하고 그러한 환경을 만들어야 한다.

또 다른 얘기, 당신이 팀장이라면 팀 구성원들이 작업 보고서나 다른 업무 때문에 시간을 낭비하는 일이 없도록 해야 한다. 마찬가지로 팀장이 팀 구성원들과 필요한 얘기를 할 때마다 시시때때로 불러댄다면, 그것은 팀 내의 생산성을 헤치는 일이 될 것이다. 필요한 것이 있다면 업무 시작 전에 오늘 해야 할 일에 대해서 얘기하고, 퇴근 전에 시간을 정해서 오늘 한 일과 미처 끝내지 못한 일들에 대해서 얘기하는 것이 더 나을 것이다.

과연 이것만으로 모든 것이 끝나는 것일까? 미안하게도, 큰 조직내에서 업무를 하다보면 다른 부서 사람들이나 외부 사람들의 요청에 도움을 줘야 하는 경우도 있고, 반대로 도움을 받아야 하는 경우도 있다. 그러다보면 외부 요청으로 인해 작업 시간을 모두 빼앗기는 경우도 생기게 된다. 결국, 이와 같은 외부 요청에 대해서도 ‘몇 시 이후에 처리한다’와 같은 구체적인 계획을 세워야 한다. 필자의 경우, 정말로 해야 할 일이 많을 때에는 회의실에 전화기를 뽑아버리고, 문에 "절대 들어오지 마시오"라고 써 붙이고, 문을 잠궈버린 적이 있다. 비록 짧은 5시간이었지만 내가 일주일동안 한 일 보다 그 시간에 한 일이 더 많았을 때도 있었다.

일부 조직에서는 이와 같은 문제 때문에 오전 두시간을 회의도 없고, 다른 것을 하지 않으면서 오직 업무에만 집중하는 "업무 집중 시간"을 갖는 곳도 있으며, 실제로 생산성이 높아졌다고 답하는 곳도 많다.

말단 프로그래머라면 회사에서 이렇게 멋대로 행동하는 것이 어려울 수도 있다. 그렇다면 당연히 윗사람을 설득시킬 수 있어야 한다

1.2 자기 자신을 관리하라

프로그래머에게 자기 관리는 아주 중요한 문제다. 프로그래머가 자기 관리에 실패하는 경우에 생산성이 급격히 떨어질 수 밖에 없다. 따라서, 숨막히는 갑갑한 분위기는 싫지만, 어느 정도 자기 통제를 할 수 있어야 한다.

우리가 흔히 하는 실수 중에 하나는 프로젝트 초기의 여유로움과 프로젝트 마감때의 급박함이라는 것이다. 그러나 프로젝트 초기에 할 일이 없다고 빈둥대지 않았으면 한다. 실제로 이렇게 얘기하면 초기에는 내가 해야할 일이란 아무것도 없다라고 항변할 수도 있다.

그러나 프로젝트 초기에 요구 분석을 진행함과 동시에 자신만의 설계를 생각해보는 것이 좋다. 실제로 팀장과 클라이언트와의 회의 이후에 팀장은 각각의 팀원들에게 회의의 내용과 해야할 것들에 대해서 알려줄 것이고, 자신이 해야할 것이 무엇인지에 대해서 알 수 있을 것이다. 결국, 그 이외의 남는 시간에 세밀한 설계까지 생각해 볼 필요가 있다. 그것이 실제로 쓰일지, 그렇지 않든지 간에 말이다.

프로젝트 완료 시기가 다가오게 되면, 아직도 해야할 일들이 이렇게 많은데라거나 마감 시간을 맞추고 코드를 빨리 완성해야한다는 압박감 때문에 자기 통제를 쉽게 잃게 된다. 그리고 설계보다 코드를 작성하는 것에 더 우선 순위를 두게 된다. 그러나 실제로는 마감시간보다 설계에 더 높은 우선 순위를 두어야한다. 또한 점검에 우선 순위를 두어야한다. 성급하게 코드를 작성함으로써 생기는 조잡한 실수를 막도록 주의해야한다. 실제로 전체 코드에서 성급하게 완성된 코드에서 더 많은 버그가 발생할 것이다.

1.2.1 1.2의 문제점

1.2 자기 자신을 관리하라는 글이 갖는 문제점은 프로그래머 개인에 대해서만 초점을 맞췄다는 것이다. 프로젝트 초기의 여유로움과 마감의 급박함은 각 분야별로 업무 분담이 맞지 않는다는 것을 의미한다. 결국, 전체적인 프로젝트를 진행하는 절차에 문제가 있는 경우이며, 이 경우에 말단 프로그래머로서 프로토타입을 만들거나, 업무에 필요한 라이브러리와 같은 기본 도구를 개발하는 것으로 후반의 업무 집중을 쉽게 풀어보자는 데 의미를 둔 글이다.

필자와 일한 회사중에는 이를 재치있게(?) 풀어낸 회사가 있었다. 두 곳이 있었다. 한 곳은 프로젝트의 진행 상황에 따라 디자이너, 개발자를 자유자재로 고용하며 업무를 조율해 나갔다. 이렇게 하기 위해서 디자이너를 위한 지침, 개발자를 위한 지침이 준비되어 있었다. 개발자를 위한 지침을 보자면 코딩 스타일에서부터 시작해서, 프로그래밍시에 A를 처리하기 위한 방법과 같은 하우투(HowTo)를 모아놓은 개발 가이드라인 같은 것이 있었다. 어떻게 보자면 코드북, 레퍼런스, 쿡북과 같지만 자신들의 업무 도메인에 특화되어 있었다. 때문에 2주간 일하는 사람, 4주간 일하는 사람과 같은 식으로 분화되어 있었다. 장점은 업무에 따라 인력을 손쉽게 조율하며 일할 수 있었다는 점과 인건비를 효율적으로 사용한다는 것이며, 단점은 인력 관리와 전문성 문제가 있었다.

다른 한 곳은 회사에 기획자, 디자이너, 개발자가 모두 정직원으로 있었고, 꼭 필요한 경우에만 계약직을 고용했었다. 대신, 처음부터 끝까지 모든 사람이 함께하지 않고 프로세스에 따라 투입되는 분야와 인력이 달랐다. 디자이너와 개발자가 A사의 개발을 하는 동안 기획자는 B사의 기획을 하고, A사의 개발이 끝나면 B사의 개발에 투입되고, 기획자는 다시 C사를 기획하는 형태였다.

아마도 다양한 방법이 있겠지만 실제로 이들 회사가 운영하는 방법은 인상깊었다. 하지만, 한편으로는 빡빡한 한국의 SI에서 살아남기 위한 자구책으로 이해되기도 했다.

To be continued...