컴빅스™의 소박한 이야기

so I went for a walk to a place that I know. by Sanctu

이는 비단 프로그래밍에 갓 입문한 사람 뿐만 아니라, 다른 프로그래밍 언어를 처음 접할 때에도 적용되는 내용 같습니다.

1. 프로그래밍의 최대의 적은 Copy & Paste이다.

IT에서 일어나는 작업들은 모두 사람의 힘을 배가시키기 위함이고, 이를 위해서는 최대한 자동화를 시켜주는 것이 그 목적일 것입니다. 따라서, 프로그래밍이라는 작업 역시 일일히 모든 것들을 만들기보다는 최대한 재사용할 수 있는 것들을 활용하는게 작업 능률에 있어서 최적일 것입니다. 그 중에서 프로그래밍 작업 중에 제일 흔하게 일어나는 일이 Copy & Paste입니다. 하지만, 익숙한 프로그래밍 언어라도 Copy & Paste는 주의를 필요로 합니다. 더군다니 초보 시절의 Copy & Paste는 독이 될 수도 있으며, 결국 잘 이해되지 않은 코드의 Copy는 어떠한 문제를 일으킬지 잘 모릅니다.

Palacio de las Artes Reina Sofía C.A.C / Palace of Arts Reina Sofia C.A.C./ Palais des Arts Reina Sofia C.A.C. by Iabcstm

초보 시절은 동일한 코드라고 하더라도 직접 키보드를 통해서 입력하거나 도구를 정상적인 경로를 통해 사용해봄으로써 머리와 몸으로 코드의 원리를 체득해야 합니다. 심지어 수천라인의 XML 코드라고 하더라도 일일히 쳐보면서 그 의미를 하나하나 쫓아서 읽을 수 있어야 합니다. 무분별한 Copy & Paste는 발생하는 에러를 엉뚱한 곳에서 디버깅하게 만듭니다. 요즘에는 책을 사면 소스 코드를 다운받게 되어 있습니다. 해당 내용을 잘 알고 어느 정도 이해를 하고 있는 사람이라면 상관없겠지만, 초보자들에게는 이 역시 소스 코드를 다운받아서 실행하는 것보다는 직접 책에 있는 내용을 쳐보고 이해하는 것이 많은 도움이 됩니다. 혹 책의 내용이 이전 라이브러리들을 참고하고 있어서 지금의 환경에서 이를 적용하려면 더 많은 수고들을 거치는 경우도 발생됩니다. 이러한 과정을 거치게 되면 또 다른 지식들이 쌓이게 되니, 헛짓이나 삽질이라고 생각하시면 안됩니다.

초보 시절 저 역시 수많은 코드들을 직접 손으로 치면서 많은 것들을 이해할 수 있었고, 더 많은 연결된 부분들을 찾아볼 수 있었던 것 같습니다. 반복적인 작업이지만, 그 자체로 더 없는 많은 내용들을 얻게 될 것입니다.

2. 가이드 대로 따라하면 안된다.

프로젝트에서는 수많은 가이드들이 만들어지며, Step By Step 형식으로 나와있는 문서나 자료들도 많이 있습니다. 초보 시절에는 가이드를 보는 것 역시 중요하겠지만, 그 내용을 곧이 곧대로 믿어서도 안됩니다. 특히나 프로젝트 중후반부로 들어갈수록 초반에 만든 가이드는 잘못되거나 수정된 내용이 많아질 가능성이 많습니다. 가이드는 대략적인 내용들을 보면서 어떠한 흐름으로 프로그래밍을 하게 되는지에 대한 지식을 얻으면 됩니다. 또한, 프로그래밍은 가이드에 나타난 내용 이외에도 더 많은 지식과 기술을 필요로 합니다. 가이드는 말 그대로 안내하는 용으로만 사용해야지 가이드가 모든 것을 가르쳐준다고 생각해서는 절대 안됩니다.

Day 106 - I am a librarian by cindiann

가이드를 절대적으로 믿는 행위 중에 하나는 가이드에 표현되지 않은 것들에 대해서는 아무런 사고를 안하게 만든다는 것입니다. 예를 들어, 예상치 못한 에러나 경고 문구가 나타나도 이를 신경쓰거나 무엇이 문제인지를 찾으려는 노력을 하지 않게 만듭니다. 이는 가이드를 만들고 배포하는 측에서도 가이드만 보고 따라하라는 암묵적인 강압을 하는 태도도 일조한 결과입니다. 가이드를 맹신하지 마십시오.

3. 한가지 정답을 찾으려고 하지 마라.

우리가 학교에서 배운 것들은 모두 정답이라는 한가지 목적에만 초점을 맞추어 있습니다. 사회의 초년생들 역시도 정답이 아니면 안된다는 사고를 가진 사람들이 대부분인 것 같습니다. 정답은 늘 해당 상황에서만 정답이 될 뿐이며, 다른 상황에서는 오답이 될 가능성이 높습니다. 프로그래밍에서 어느 한가지로 해결했다고 해서 이것이 다른 프로젝트에서 똑같이 적용될 수는 없을 겁니다. 정답보다는 그 가능성에 대해서 염두해 두십시오. 가능성은 확률로도 표현이 가능하며, 가능성이 높다는 것은 다양한 전제 조건을 포함한다는 것입니다. 즉, Context라는 단어가 의미하는 바를 이해하고, 그 상황에서 다양한 전제 조건과 제약 조건들을 같이 고려하여 가능성이 제일 높은 해결책을 찾는 것이 프로그래밍을 배울 때 같이 익혀야 할 내용입니다.

현실에서는 프로그래밍으로 할 수 있는 것들이 의외로 많고, 그러한 내용들이 나타나는 프로그램은 단지 그 결과에 지나지 않습니다. 다른 사람의 정답을 참고할 수는 있겠지만, 그러한 정답이 지금의 프로젝트 내에서 반드시 정답이라는 보장을 하기 힘듭니다. 그 사람의 정답(결과)이 만들어지는 배경과 상황을 같이 이해해야 합니다.

4. 고민을 끌어안고 있지 말고, 터뜨려라.

프로그래밍의 초보 시절에는 단순한 문제라도 심각한 고민거리가 되기 쉽상입니다. 그러한 고민거리는 그 누구한테 물어보는 것조차 힘겨운 법입니다. 고민을 하는 것은 그리 나쁜 것은 아니지만, 주어진 시간과 다른 작업으로의 연결이라는 제약사항들이 있기 때문에 무한정 고민만 할 수는 없습니다. 고민을 하는 시간조차도 효율적으로 사용해야 하며, 정 고민이 해결되지 않는다면 터뜨리십시오. 누가 물어보기 전까지 고민을 안고 있다라는 것은 다른 사람으로 하여금 실력이 없다라는 충분한 오해를 받을 만한 일입니다. 본인의 실력이 드러날까봐 고민을 안고 불안한 마음에 있는 것보다는 고민을 터뜨려서 해결하는 방법을 채택하는 것이 오히려 전체적인 관점에서 더 좋은 결과가 나타날 수 있습니다.

고민을 터뜨리는 방식은 단순하게 이 부분을 모르겠다고 솔직하게 털어놓는 것도 있을 수 있지만, 좀 더 유연한 방식으로는 그동안 고민했던 내용들을 다시 정리해보고, 왜 문제가 있는지를 간략하게 설명할 필요가 있습니다. 이때 주의할 점은 본인의 입장에서만 고민을 정리하다보면 상대방이 고민에 대한 본질적인 문제보다 그 부수적인 내용이 더 이해하기 힘든 경우가 발생됩니다. 고민은 최대한 간략하고 이해할 수 있도록 정리하는 기술이 필요합니다.

5. 통용되는 정확한 용어를 사용하라.

초보 시절에는 모든 단어와 용어들이 낯설기만 합니다. 그러한 용어들은 선배들이 잘못 이해하여 사용되는 경우들도 있습니다. 용어를 들은대로만 사용하기보다는 그 뜻과 의미를 정확하게 알아보는 습관을 들이는게 좋습니다. 또한, 그러한 용어를 알아가는 과정이 전번적인 내용을 이해하는 과정이기도 하며 이는 프로그래밍에 대한 지식을 더 폭넓게 이해하게 만듭니다.

대표적인 예가 디자인 패턴의 패턴 이름인데, 이러한 패턴 이름들은 상당한 오랜 시간 동안 많은 사람들에게 사용되어 왔습니다. 단순하게 이름만을 듣고, 그에 대한 배경 지식이 없는 상태에서 프로그램된 상태만을 본다면 나중에 또 다시 잘못 사용하여 이를 듣는 사람에게 오해를 불러일으킬 수도 있을겁니다.

변수명, 클래스명, 메소드명 등 역시 정확한 (비즈니스) 용어를 사용해야 합니다. 귀찮다고 줄이거나 임의로 이해할 수 없는 용어를 만들면 다른 사람이 보기가 힘들어집니다. 예전 기술들이야 워낙에 HW 용량에 대한 문제가 커서 이름이나 용어에 대한 길이 한정 제약이 있었지만, 지금은 이러한 제약에서 훨씬 자유롭습니다. 의미있고 정확한 이름을 사용하기 바랍니다.

6. 프로그래밍의 내용은 한편의 시나리오(소설)를 보는 듯하게 만들어라.

초보 시절의 프로그래밍 습관은 상당히 중요합니다. 주석, 변수명, 메소드 호출 등에 있어서 다양한 습관들이 서로 다르게 표현될 수 있습니다. 특히, 프로그래밍의 내용은 비즈니스의 흐름과도 동일하며, 그 흐름은 마치 한편의 드라마를 보듯이 매끄럽게 이어져야 합니다. 변수 선언, 객체 생성, 리소스 획득, 메소드 호출 등이 뒤죽박죽 섞여 있어서 코드를 본다는 것 자체가 무슨 내용인지를 모르게 구성하는 경우들이 있습니다. 프로그래밍의 내용은 코드만을 보고도 어떠한 흐름으로 이어지는지를 알 수 있게 구성되어야 하며, 이는 마치 시나리오와 같습니다.

어떤 경우에는 초반에 만든 코드와 나중에 수정한 코드가 뒤범벅이 되어서 어떤 것이 실제로 사용하는지도 잘 모르게 구성되는 경우도 많습니다. 정 이전 코드를 참고하고 싶으면, 차라리 주석 처리하거나 별도의 메소드를 만들어서 구성하는 것이 더 깔끔할 겁니다. 그리고, 사용되는 것과 사용되지 않는 것들에 대한 구분 역시 필요하며, 이는 본인만 알아볼 수 있는 것이 아닌 공통적으로 누구나 알아볼 수 있는 표시를 해야 할겁니다.

코드는 실행되는 것도 중요하지만, 무엇보다 깔끔한 형태의 코드 결과도 상당히 중요합니다. 그 안에는 누구든지 해당 코드를 보고 쉽게 이해할 수 있고, 이름만 보더라도 무엇을 하는 객체인지를 알 수 있게 구성하는 것이 훨씬 중요합니다.

7. 처음부터 구조화시킬 필요는 없다.

처음에 프로그래밍 언어에 익숙해지기 시작하면서 코드에 대한 구조를 생각하게 되고, 초반부터 이해하지 못하는 구조를 만들기 시작하는 경우도 있습니다. 구조화는 코드가 동작하는 상태에서 의미가 있으며, 구조화되지 못한 코드라고 하더라도 동작한다면 크게 문제되지 않을 수 있습니다. 초반에 구조화를 시도하다가 많은 시간을 허비하는 경우도 있으며, 다양한 구조화를 시도하다가 실제 작업은 진행하지 못하는 경우도 많습니다. 또한, 초반에 너무나 많은 내용을 한꺼번에 프로그래밍을 하다보니, 테스트할 시간조차도 부족한 경우도 있습니다.

처음 객체를 만들때에는 가장 단순하고 적은 데이터만을 사용해서 전체적인 뼈대를 구성하는 것이 가장 좋습니다. 그리고, 이러한 뼈대에 차츰 살을 붙여서 완성해가는 것이 좋은 방법입니다. 뼈대가 구성되지 않은 상태에서 살을 붙일 수는 없을겁니다. 어느 정도의 구조화는 필요하겠지만, 여기에 모든 노력을 기울여 자신의 실력을 뽐낼 필요까지는 없습니다. 보여주고자 하는 데이터가 한두개 모자란다고 크게 문제되지는 않습니다. 이러한 문제들은 테스트를 통해서 수정하기만 하면 됩니다. (물론, 테스트를 할 수 있는 시간이 확보된다면 문제되지 않습니다.) 하지만, 동작하지도 않는 프로그래밍은 테스트를 하기도 어려우며, 그 결과를 예측하기도 어렵습니다.

8. 책을 쓰듯이 코드를 작성하라.

프로그래머에게는 코드 자체가 문서이자, 작업 대상이어야 합니다. 코드를 작성하는데 매번 만족할 만한 수준까지 작업하기는 힘들지만, 코드를 책을 쓰듯이 작성해야 합니다. 책을 쓴다는 것은 자신이 읽기 위함이 아닌, 다른 사람이 본다는 생각을 할 필요가 있습니다. 다른 사람이 자신이 만든 코드를 보고 이해하기 쉽게 짜임새 있게 구성되어야 하며, 각 부분들의 조각들이 맞추어져서 전체가 하나의 새로운 구성체로 조합되어야 합니다. 책을 쓴다는 것은 작성자의 signature를 포함한 내용들이 그 안에 있어야 하며, 코드에서 만큼은 본인이 구성한 의도가 충분히 포함되어야 합니다.

잘 짜여진 코드는 그 내용이 기승전결과 같은 일관된 구성으로 이루어지며, 심지어 표지나 서문과 같은 내용까지도 생각하여 다양한 데코레이션들을 코드 내에 삽입할 수 있습니다. 무엇보다 책 내용이 중요하듯이 그리고, 그 책의 구성 또한 소홀히 할 수 없듯이 코드는 그 내용을 중심으로 한권의 책을 보는 듯한 인상을 주어야 합니다.

9. 프로그램 내용을 시각적으로 표현해보라.

아무리 단순한 프로그램이라고 하더라도 최소한 몇개의 레이어나 시스템을 거쳐서 비즈니스 로직을 수행하기 때문에 전체적인 윤곽을 그려보는 것이 필요합니다. 또한 프로그램을 담고 있는 각 객체간의 관계가 어떻게 이루어지고, 무슨 작업을 수행할 때 필요한지는 파악해야 합니다. 이러한 모습들은 코드의 형태보다는 간단한 시각적인 표현 방식을 사용해서 파악하는 것이 필요합니다. 때로는 프로그램적으로 해결하기 어려운 부분들이 전체적인 구조를 파악하면 쉽게 해결되는 부분들도 있습니다.

즉, 자신이 만든 프로그램도 중요하지만, 남이 만든 프로그램 역시 전체적으로 어떠한 관계를 맺는지를 파악하는게 중요합니다. 자신이 만든 프로그램이 어떠한 용도로 사용되며, 어떠한 문제들을 일으키게 되는지도 사전에 파악하여 조치를 할 수 있어야 하며, 남이 만든 프로그램을 사용할 때 어떠한 부수 효과(side effect)가 발생할지에 대해서 알아야 합니다.

프로젝트를 혼자 모든 것을 처리하지 않는 이상, 다른 이가 만든 프로그램에 대한 영향, 내가 만든 프로그램에 대한 영향을 파악하는 시각을 키울 필요가 있습니다. 프로그램 자체가 단독으로 실행하는 것보다 서로 다른 사람들이 만들어서 같이 동작하게 만들어서 작업을 하기 때문에 상당한 노력을 필요로 하며, 이는 그리 단순하고 손쉬운 작업이 결코 아니라는 것을 인지할 필요가 있습니다.

이를 위해서는 자신이 만든 프로그램이라도 시각적으로 표현하고 이를 이해할 수 있어야 합니다.

9+1. 항상 원칙을 지키도록 노력하라.

프로젝트 현장에서는 다양한 기술과 노하우들이 펼쳐지고 난무하는 곳입니다. 이곳에서의 기술과 노하우들은 그 근본을 알 수 있는 것들도 있지만, 그렇지 못한 것들도 많이 있습니다. 원칙, 원리, 이론 등은 현장에서의 이러한 적용의 원리에 의해서 마치 구시대적이거나 학구적인 것으로 대접을 받아 상당한 무시와 천대를 받는 경우도 많습니다. 무엇이 되었든 간에 원칙은 반드시 존재해야 하며, 그러한 원칙을 기반으로 다양한 적용 원리가 나타날 수 있다는 것을 잊지 마시기 바랍니다.

원칙이라는 것이 거창하거나 복잡한 내용이 아니지만, 이를 이해하는 과정은 그리 쉬운 작업이 아닙니다. 하지만 원칙이 없는 프로그램 코드는 마치 모래 위에 성을 쌓는 것과 같습니다. 늘 환경에 의해서 흔들리고 다시 지어야하는 경우가 발생됩니다. 사소한 원칙이라도 무시하지 마시고, 그 원칙이 왜 생겨났는지를 곰곰히 생각하여 반드시 프로그래밍으로 표현할 때 같이 이해할 수 있어야 합니다.


위와 같은 내용은 어찌보면 엉뚱한 이야기인 것 같기도 하지만, 대부분이 현장에서 초보 프로그래머들과 접하면서 꼭 해주고 싶었던 이야기들입니다. 프로젝트 현장은 이와 같은 내용들을 세세하게 설명해주고 가르쳐줄 시간이 턱없이 부족하며, 똑같은 실수들을 후배들이 저지르는 것을 보는 것이 안타까울 따름입니다. 초보 시절의 습관은 경력이 쌓이더라도 쉽게 사라지지 않고 그 습관은 반드시 코드 상에 나타나게 되어 있습니다. 처음부터 힘들더라도 차근차근 실력을 쌓아가도록 노력하려는 자세가 필요합니다.

[출처: http://homo-ware.tistory.com/169]