프로그래머로 살아가면서 10가지 지켜야할 계명이 있다면 무엇일까? 그냥 우연찮은 기회에 성서에 나오는 10계명과 유사하게 만들면 어떨까하는 생각으로 아래와 같이 정리해 보았다.
01. 방법론을 섬기지 말라.
02. 남이 만든 코드에 전적으로 의지하지 말라.
03. 특정 방법론을 따른다고 말하지 말라.
04. 빨간날은 반드시 쉬라.
05. 소스 관리시스템을 공경하라.
06. 모듈의 상하 관계를 구분하라.
07. 관련없는 모듈과 통하지 말라.
08. Copy-Paste를 남발하지 말라.
09. 나의 Bug를 남의 것이라고 말하지 말라.
10. 내 이웃의 개발자를 탐하지 말라.
좀 뻔한 이야기들이지만 이번에는 이것으로 잠시 이야기를 해보도록 하겠다. 각각의 항에 대해서 그냥 편하게 풀어나가보려고 하지만, 말솜씨가 부족해서 어려운 부분이 있다면 필자가 아직 실력이 부족한 탓이라고 해야할 것이다.
01. 방법론을 섬기지 말라.
흔히들 "우리는 어떤 방법론으로 개발하고 있어"라는 이야기들을 많이 한다. 하지만, 정작 중요한 것은 그러한 방법론이 아니라, 체질화된 습관이라고 하는 것이 더 옳을 것이다. 예나 지금이나 프로그램을 개발하는 것은 거의 비슷하며, 어떻게 하면 좀더 가시적으로 남들에게 SW프로그래머가 일하고 있다는 것을 보여줄 것이냐만 바뀌었다고 생각한다. 물론, 이렇게 이야기하면 반론을 제기할 분들이 많겠지만, 근본적인 프로그램을 개발하는 방법은 초창기와 그렇게 다르지 않다. 빨리 만들어서 빨리 보여주고, 빨리 고쳐서 언제까지 할 수 있을지 보여주자는 것등등의 방법론을 따르고 있다고 이야기 하기전에, 정말 그러한 방법론이 우리 현실과 맞는지 확인해 봐야할 것이다. 만약 잘 안맞는 옷을 억지로 입었다고 판단된다면, 그러한 방법론 보다는 현장에서 적절히 취할 수 있는 조치를 취하는 것이 옳다. 방법론은 참고할 만한 것이지 모든 문제의 정답은 아닌 것이기 때문이다. 또한, 그러한 방법론을 쓰고있다고 이야기들을 하지만, 정말 그런가? 혹은 PL만 그렇다고 믿고 있는것은 아닌지 질문을 자기자신에게 던져보기 바란다. 섬기지말고 복종하도록 만들어야 하고, 습관처럼 그냥 일상적으로 사용하는 것이어야 한다.
02. 남이 만든 코드에 전적으로 의지하지 말라.
남이 만들어 놓은 코드들을 가져다가 사용하는 경우가 아마도 10에 8~9정도는 될 것이다. 자신이 만든 제품에서 남이 만든 코드를 대부분 90%이상씩은 사용하고 있을 것이다. 물론, 완전히 처음부터 만들어나가는 과제도 있지만, 그렇지 못한 과제가 대부분이다. 프로그래머의 대부분의 일은 어쩌면 이렇게 copy하는 일일지도 모른다. 하지만, 남이 만든 코드이기 때문에 전적으로 옳다고 생각하지는 말자. 반드시 호출(call)의 결과는 확인되어야 하며, 문제가 발생할 가능성도 얼마든지 있다. 가장 좋은 코딩 습성은 자신이 코딩하지 않는 것이라는 우스개 소리가 있다. 이는 이미 만들어진 잘 동작하는 코드를 새로 개발할 필요는 없다는 것이지 그 코드가 문제가 없다는 말은 아니다. 따라서, 항상 습관적으로 어떤 함수를 호출한 후에는 반드시 호출의 결과를 확인하는 해야 한다. OS에서도 문제가 발생할 수 있으며, 3rd Party에서 제공한 코덱과 같은 곳에서도 언제든 에러가 생길 수 있다. 항상 방어적이어야 그만큼 오류도 적게 만든다. 공격적으로 코딩 속도를 가져가기도 해야하겠지만, 문제는 그냥 넘어가는 곳에 항상 숨어 있다. 모든 코드를 한줄 한줄 다 보는 것은 어렵겠지만, 최소한 하나의 함수단위로 확인하는 것은 가능하다.
03. 특정 방법론을 따른다고 말하지 말라.
사실 특정 방법론을 따른다고 이야기를 하는 사람들이 프로젝트를 망칠 확률이 더 높을 수 있다. 하지만, 더 똑똑해 보일 수는 있을 것이다. 일을 잘할 것 처럼 보이는 사람들은 이론에 밝은 사람들이다. 자신의 의견을 논리적으로 잘 표현하고, 멋진 방법론을 가져가가 장점만을 취해서 개발하고 있다고 이야기 한다. 하지만, 말과 실제는 다르다. 익은 벼일수록 고개를 숙인다는 말이 있듯이, 개발에 정말 이골이 난 사람은 방법론에 의지 하지 않는다. 오히려 프로젝트의 정확한 맥을 집어서 어디가 문제가 발생할 것같고, 어떻게 하면 그것을 해결할 수 있다는 것까지도 이미 알고 있다. 즉, 풍부한 실전 경험만큼 좋은 공부는 없다는 것이다. 물론 이론적인 토대가 없이 이루어지는 경험은 별로 오래동안 유지되지 못한다. 하지만, 무서운 것은 이론도 잘 알면서 실전경험도 잘 갖춘 사람들이다. 특정 방법론을 따른다고 말하기 보다는 "내가 생각하기에 이번에는 이런 식으로 해보면 어떨까?"라고 이야기 하면서 묵묵히 자신의 일을 해나가는 사람들이 여러분의 곁에 있기를 빈다.
04. 빨간날은 반드시 놀아라.
회사는 이익을 극대화하기 위해서 모인 조직이라는 말을 한다. 회사의 이익이 개인의 이익으로 돌아오기 위해서는 최소 6개월에서 1년이 걸린다. 즉, 보너스나 연봉계약을 해야지 개인의 이익이 된다. 빨리 이익을 조금이라도 나누어 가지고 싶다면, 빨간날도 나와서 일하라. 물론 프로젝트를 지원하는 부서의 경비가 얼마나 될지는 몰라도, 그런 사람들에게 휴일근무 수당으로 다만 얼마라도 줄 것이다. 하지만, 그렇게 일하는데 있어서 과연 능률이 오를까? 보통의 직장인이라고 한다면 주말에 나와야 할 경우, 금요일까지 해야할 일을 연장하는 경우가 많다. 토요일날 어차피 나와야 한다면 금요일날 끝을 낼 필요가 없다는 것이다. 또한, 주말에 나올경우 회사는 개인에게 수당을 줘야하며, 각종 부대시설과 식사도 준비해야 한다. 집으로 가져가는 돈도 돈이지만, 회사에서 낭비되는 돈도 많다는 것이다. 능률이 단순한 산술식으로 성과를 일한 시간으로 나눈다고 본다면, 일한 시간이 늘어나면서 성과가 보통때의 두배가 늘지 않는다면, 실제로는 일정의 일부 단축만 있을 뿐이며, 그러한 일정 단축에 든 비용이 있다는 것도 생각해야 한다. 따라서, 과감히 빨간날은 충분히 놀아라. 놀아야 일하지, 일만하다간 일을 끝내지를 못한다.
05. 소스 관리시스템을 공경하라.
소프트웨어를 개발하는 회사라면 적어도 하나 이상의 소스 관리시스템을 사용한다. 소스 관리시스템에서 유지하는 것은 소스 코드의 모든 변경 사항과 변경사유에 대한 log이다. 이렇게 좋은 기능을 두고 어떤 사람들은 소스코드 자체에 자신만의 comment를 남겨둔다. 혹은 dead code를 그냥 유지해서 코드의 가독성을 낮춘다. 소스 관리시스템이 없는 회사도 존재한다. 자신이 만든 코드를 남들이 보지 못하는 곳에 두고, 프로젝트를 진행하는 팀원들에게 library로 binary file만을 제공하기도 한다. 자신이 가진 knowhow가 대단한 것처럼 생각해서 남들과의 공유를 하지 않지만, 남들이 잘 만든 코드는 항상 자신의 것으로 만들려고 노력한다. 이는 작게보면 고립된 프로그래머로서 끝나는 것이고, 크게 보면 회사가 영속하지 못하는 이유가 된다. 단언하건데 발전하고자 한다면 공개하라. 남들의 비판이 두렵다면 회사를 그만두고 나가는 편이 낫다. 같이 일하는 팀원들을 믿지 못하고 두려워한다면 제대로 프로젝트가 될리가 없다. 항상 먼저 솔선수범해서 모든 코드를 공유하기 바란다. 관리란 꾸준히 변경이 일어난다는 말과 같다. 변경이 없는 코드는 이미 죽은 코드이다(dead code). 소스 코드 관리시스템이 없는 세계를 선호하는 사람들은 이제 이 분야에서는 없었으면 한다. 왜냐하면, 요식업에서나 가능한 일이기에...(며느리도 몰라요.)
06. 모듈의 상하 관계를 구분하라.
사람들은 그림을 그리기를 좋아한다. 그림은 실세상을 반영하는 그림도 있을 것이고, 상상의 어떤 것일수도 있다. 하지만, 그림을 그려서 어쨌든 자신의 내면을 형상화 시킬 수 있는 능력이 있다는 것이다. 실제 동작하는 프로그램을 만들려고 할 때, 이러한 추상화를 필요로 한다. 어떤 일을 처리하기 위해서 유사한 기능들은 하나로 모아서 모듈(module)로 정의하고, 어떤 것들은 그러한 모듈에서 제공되는 기능을 이용해서 다시 만들어지기도 한다. 따라서, 어떤 모듈들은 특정 모듈들로 호출이 발생하고, 호출되는 모듈들은 또 다른 모듈들로 호출이 발생하게 된다. 이렇게 호출하는 모듈들을 상위에 호출되는 모듈들을 하위로 구분하게 되면, 생각자체가 하위로 갈 수록 구체적으로 변하게 되며, 상위로 갈수록 추상화하는 경향이 생긴다. 상하 관계가 명확하지 않게되면, 호출들이 순환(cycle)을 이루는 구조가 생기게 되며, 관련된 어느 한 모듈을 수정하면, 그와 연결된 다른 부분에 대한 수정이 발생할 확률도 높아지게 된다. 일반적으로 이러한 상하 관계를 특징 직을때 Layer라고 한다. 이렇게 Layer를 만들어서 구조화 시킨 것을 Layered Architecture라고 부른다. 단순히 모듈을 쌓아나간다고 생각하지말고, 생각의 추상화를 높여나간다고 보기 바란다. 추상화가 높은 level에서 하는 활동들이 지적으로 높은 수준을 필요한다고 보는 경향이 많은데 반드시 그렇지는 않다. 시스템은 손발이 없이 머리로만 만들수는 없기 때문이다. 가장 구체적인 명령어에서부터 잘 구현되어야 탄탄한 구조를 가지기 때문이다. 마치, 높은 건물을 짓기 위해서 지하에 수없이 많은 철근들을 곶아넣는것과 같기 때문이다.
07. 관련없는 모듈과 통하지 말라.
여기서 관련이 없다는 말은 특정 모듈에서 제공하는 기능을 이용하기 위해서 억지로 끼워맞춰나가지 말라는 것이다. 만약 그렇게 접근을 해야할 일이 생긴다면, 차라리 해당 모듈에서 그 기능을 분리하는 것이 옳다고 본다. 아니면, 추상화 level을 한단계 더 올려서 상위에서 해당 모듈을 접근하도록 만드는 방법도 있다. 어쨌든 중요한 것은 모듈을 정할때 R&R(Role and Responsibility)를 명확히 하라는 것이다. 모듈의 응집성(Cohesion : 관련있는 것들로만 묶이도록 만든 정도)을 높이기 위해서, 해당 모듈의 역할과 책임범위를 명확히 하라는 것이다. 너무 많은 기능을 수행하는 모듈이라면, 여러개의 모듈로 쪼개서 단순한 역할을 하는 모듈 여러개로 나누는 것이 좋다. 만약 공통된 기능을 여러 모듈에서 똑 같이 수행한다면, 그런 기능들을 모아서 새로운 모듈로 만드는 것이 옳다. 잘 정의된 모듈은 재 사용성이 높다는 것은 어쩌면 당연한 말일 것이다. 정의된 interface로만 사용되도록 만들어졌으며, 다른 모듈간의 의존성도 최소화 시켜서 제작되었다면, 이용하는 측면에서 고려할 부분이 작다는 것이기 때문이다. 흔히든 성능상 어쩔 수 없이 이렇게 만들었다는 것으로 보통 자신들이 개발한 코드에 대해서 변명을 하는 경우가 많다. 성능이 아니면, 실제 상품화 때문에 이렇게 될 수 밖에 없었다고도 이야기 한다. 하지만, 중요한 것은 항상 기본에 있으며, 그 기본을 튼튼히 하는 활동을 게을리 했다는 것은 향후에 올 비용증대에 대해서 책임을 줄이는 것이 아님을 알아두기 바란다.
08. Copy-Paste를 남발하지 말라.
코드를 작성하다보면 흔히들 하는 일이 비슷한 것을 copy-paste하는 것이다. 필자의 경우에도 이런 경험이 있다. 즉, 비슷비슷한데 조금씩 달라지는 부분 때문에 이런 일들이 많이 발생한다. 하지만, 분명히 단언하건데 이렇게 작성된 코드는 항상 주의를 요하게 된다. 즉, copy하고, paste하고 수정하는 동안 잘못 수정된 부분이 존재할 가능성이 많기 때문이다. 다 알겠지만 이럴때의 가장 쉬운 대처방법은 비슷한 부분을 모아서 함수화 시키고, 달라지는 부분을 parameter화 시키는 방법이다. 물론, 이것도 그렇게 쉽지 않을 경우가 있는데, 이럴때는 그 부분에 대해서 더 작은 단위로 쪼개서 공통된 부분을 찾아내는 것도 가능할 것이다. 중요한 것은 copy-paste해서 사용하는 코드들을 잘 관리하라는 것이다. 오류는 코딩의 무의식적인 부주의에서 발생하므로, 이런 부분이 생길때는 더욱 주의를 기울이는 것도 버그를 줄이는 한가지 방법이 될 수 있을 것이다. 인터넷에서 가져온 코드를 copy-paste할 때는 가져온 코드의 License에 주의해야 한다. Open Source라고 해서 License가 없다고 생각해서는 안된다는 것은 이미 수년간의 개발활동에서 알고 있을 것이다. 남이 만든 코드는 남의 지적인 산물이다. 그렇다고 모든 코드를 내가 만들어야 한다는 것은 아니지만, 최소한의 코드에 대한 존경심은 발휘해야 할 것이다. 그것이 상업적인 보답이든, 혹은 그냥 단순한 문구의 삽입이든 간에 License에 대해서 항상 기억하기 바란다.
09. 나의 Bug를 남의 것이라고 말하지 말라.
프로젝트는 다양한 사람이 다양하게 나누어서 진행되는 경우가 많다. 구조화가 잘못되어 남이 한 부분과 내가한 부분이 서로 얽혀 있을수도 있고, 혹은 잘 나누어져 있다고 하더라도 한부분에서 문제가 안되는 것이 다른 부분에서는 문제가 발생할 수 있다. Bug는 의도와는 상관없이 일어나는 것이므로, 자신이 만든 코드든 남이 만든 코드든 시스템의 Bug라는 측면에서 비난할 문제가 아니라 해결할 꺼리라는 것이다. 더 중요한 것은 그것이 제품 출시전에는 반드시 수정되어야할 사항이라는 것이다. 남의 것이라고 우겨서 될 일이 아니라는 것이다. 프로젝트는 팀웤이 생명이며, 잘 잘못을 탓하는 분위기로 흘러가서는 일정지연이나 실패할 수 밖에 없다. 오히려 남의 Bug라도 자신이 해결책을 알고 있다고 하면 직접 수정해도 무방하다고 본다. 어차피 수정에 대한 것은 전부 소스 관리 시스템에 누가 했는지까지 남게되며, 되돌리기도 어렵지 않기 때문이다. 남을 탓하기 보다, 혹시 자기 자신의 실수는 없었는지 먼저 면밀히 보기 바란다.
10. 내 이웃의 개발자를 탐하지 말라.
하하하. 사실 이것은 조금 원조 십계명을 이용한 것이다. 하지만, 이런 상황은 종종 발생한다. 예를들어, 어떤 개발자를 잠시 이웃한 팀의 협조를 얻어서 부족한 부분에 대한 코딩을 맡겼는데, 상당히 실력이 좋은 개발자인 경우 그 개발과제가 끝난 후에도 같이 일하고 싶어서 높은 분들께 요청하는 경우가 많다. 하지만, 한가지 명심할 것은 그러한 개발자를 왜 자신의 개발팀에서는 키워내지 못했는지를 먼저 고민해 보도록 해라. 상품화를 담당한 팀은 항상 바빠서 거의 교육에 갈 기회가 적다. 교육을 가더라도 사내 교육일 경우에는 교육장에서 전화를 붙들고 살아야 하고, 교육후에는 다시 자신의 자리에 돌아가서 밀린 업무를 처리해야 한다. 참 피곤한 교육이 되는 것이다. 이럴바에는 다음부터 교육을 안가고 만다고 생각하는 경우도 있다. 사람은 무한정 결과를 만들어내는 존재가 아니다. 뭔가 Input을 얻어야지 Output을 생성해 낸다. 배운것이 없는데 새로운 것을 만들라고 한다면 그게 가능하겠는가? 기술은 6개월이 멀다하고 새로운 것이 나온다. 아니 3개월도 길다. 새로운 제품은 수도없이 지속적으로 만들어져 나온다. 시장일 leading하는 존재가 아니라면, 그러한 제품의 대응 제품만 만들다가 세월보내기 쉽상이다. 내 이웃에 있는 멋진 개발자를 넘겨다 보기 보다는 자신 밑에 있는 개발자를 잘 키워서 좋은 인재를 만들기를 기대해 본다.
이상으로 10가지의 덕목(?)과도 같은 이야기를 풀어 보았다. 물론 이러한 것들에 대해서 동의하지 못하는 부분도 많기는 하겠지만, 최소한 한번쯤 그런 생각을 가지고 자신을 뒤 돌아보는 것은 필요하다고 본다. 그럼 이만...
출처 -
출처 -
[출처] [ 프로그래머 10계명 ]|작성자 닉스