1. 2016/04/12 08:54 http://blog.naver.com/knix008/220680983666
[ 과다 코딩 ][ 과다 코딩 ]
낙서장낙서장
소프트웨어 개발자들에게는 넘어서는 안되는 선이 있다. 즉, 필요한 이상으로 코드를 만들어서는 안된다는 것이다. 물론,
개발자들은 필요한 코드를 만들 뿐이라고 이야기 한다. 하지만, 정말 그럴까? 만약, 실행되지 않는 코드가 소스(Source)에
들어있다면 어떻게 할 것인가? 문제는 어떤 코드가 실제로 실행되는지를 모른다는 점이다. 검증한 코드들은 어떤 것들이
며, 검증되지 않은(테스트 되지 않은) 코드들은 몇 줄이나 되는지를 측정하지 않는다는 것이다. 그리고, 더 중요한 것은 만
들어진 코드가 요구사항에 명시된 것만 충분히 실행할 정도인지, 아니면 그 외의 요청받지 않은 것들을 구현하고 있는지도
확인하지 않는다. 그렇다면, 정말 우리는 필요한 만큼 코딩하고 있는 것인가에 대한 의문이 생기는 것이 당연할 것이다. 더
적은 코드를 짜는 것이 버그의 확률을 낮추고, 검증을 조금이라도 쉽게 만든다전 점에서, 우리는 얼마나 코드를 짜고 있는
지를 반드시 확인할 수 있어야 한다.
미래에 사용될지도 모르는 기능은 지금 만들 필요는 없다. 미래에 그 기능이 사용될 가능성이 있을지는 몰라도, 미래를 예
측헤서 코딩할 필요는 없다. 동일한 변경이 계속 발생하는 상황이라면, 그것에 대해서는 좀 더 변경의 범위를 축소할 수 있
는 방법을 동원해야 겠지만(디자인 패턴과 같은 것을 통해서), 일반적으로 미래를 대비해서 거창한 구조를 만들지는 않는
다. 오히려, 좀더 단순화되고 이해하기 쉬운 단선적인(분기문과 중첩된 구조를 없앤) 코드를 만들어야 한다. 이런 코드들
은 테스트도 편하다. 많은 조건이 중첩된 상황에서는 어떤 조건으로 실행해야 할지가 불분명한 경우도 있으며, 특정 조건
은 사실상 실행이 안될 가능성마져도 있다. 그리고, 실제로 발생할 가능성이 극히 드문 부분도 있으며, 이런 것들에 대한
처리도 빠짐없이 해야한다. 이런 것들을 고려하면 실제로 실행이 될 가능성이 높은 코드들은 95%이상은 되지 않을 것이
다(테스트로 확인할 수 있는 코드들). 더 높은 테스트 커버리지를 만들기 위해서 들어가는 노력이 오히려 아까울 수 있다.
중요한 것은 추측에 의해서 코딩하는 것은 올바른 선택이 아니라는 점이다.
개발자는 창조적이어야 하지만, 창조적으로 요구사항을 해석해서는 안된다. 요구사항은 고객이 필요한 것을 기술한 것이
며, 고객도 사실상 잘 모르는 것일 수도 있다. 하지만, 요구사항이 정해지면 그것은 고객과 개발자가 같이 협의한 결과물이
라는 점은 잊어선 안된다. 서로 동의한 것이기에, 그것만큼은 계약으로서 존중해야 한다. 만약, 더 좋은 생각이 있거나, 고
객에게 높은 가치를 전달해줄 것이라고 생각되는 것들이 있다면, 코딩하기 전에 고객과 협의하는 것이 좋다. 시장의 고객
을 직접 만날 수 없다면, 상품의 기획자와 논의해야할 것이다. 무턱대고 요구사항을 추가하는 것도 좋지 않지만, 그렇다고
주어진 요구사항을 자의로 해석해도 곤란하다. 코드를 많이 짜는 것이 목표가 아니라면, 무엇을 만들것인가에 좀더 집중하
는 것이 올바른 선택일 것이다. 이런 이야기를 한다고해서 개발자의 창의성을 갉아먹는 것은 결코 아니다. 주어진 문제를
해결하는 방법은 언제나 창의성을 충분히 발휘할 수 있는 공간이다. 마치, 그림을 그리기 위한 캔버스의 틀이 있다고, 모든
그림이 같게 만들어지지 않는것과 같다.
1 · [ 소프트웨어 개발자 이야기 ]

2. 코드가 길다고 코딩을 잘하는 것도 아니며, 코드를 많이 짠다고 일을 잘하는 것도 아니다. 소프트웨어 개발자의 생산성을
이야기 할 때, LOC(Line of Code)를 많이들 생각하지만, 그것에는 많은 약점이 있다. 예를 들어, 만들고 있는 소프트웨어
의 난이도, 그것을 유지보수하기 위한 비용등은 포함되지 않는다는 사실이다. 그런 것들을 고려해서 생산성을 이야기 한다
면, 일단은 기술적인 부채(Technical Debt)가 될 수 있으면 없어야 하며, 검증이 된 코드를 만들어야 한다고 요약할 수 있
다. 또한, 임베디스 시스템과 같은 경우에는 20%정도의 가산점이 필요할 수도 있다. 코드의 라인 수만을 고려한다면 가
장 생산성이 높는 코드는 UI에 관련된 코드일 것이다. 윈도우 프로그래밍의 경우 툴을 사용하지 않으면 대략 40%의 코드
가 UI를 만들기 위한 것이며, 만들기도 다른 코드보다 더 쉬운게 일반적이다(물론, 그렇다고 일 자체가 쉽다고 이야기하는
것은 아니다. 만들어지는 코드를 날짜로 나누었을 때 상대적으로 많이 나온다는 의미다). 문제를 단순화 시키는 것은 좋지
만, 그렇다고 코드의 길이로만 개발자의 코딩 역량을 측정하는 것은 옳지않다.
적당한 코드를 만들기 위해서는 범위의 틀을 만드는 것이 중요하다. 여기에 사용할 수 있는 방법은 TDD(Test Driven
Development)와 같은 것이 있다. 즉, 특정 모듈에 대한 요구사항을 미리 테스트로 만들고, 그것을 만족할 수 있을 만큼만
코딩하는 것이다. 기능을 만족한다는 것은 테스트의 통과를 의미하며, 모든 테스트를 한꺼번에 만들지는 못하기에, 점진적
으로 테스트를 추가하면서, 그것을 만족시키기 위한 코드만 작성하는 것이다. 그리고, 그렇게 작성된 코드에 중복이 발생
할 경우를 제거하기 위해서, 리팩토링(Refactoring)이라는 방법을 사용하는 것이다. 이런 식으로 코드를 작성하다면, 앞
에서보 이야기한 95%의 테스트 커버리지를 달성하는 것은 물론이고, 인터페이스를 항상 먼저 정의한 후에, 코딩에 들어
가기 때문에, 깔끔한 디자인이 만들어질 것이다. 아마도, 현재까지 나온 방법론 중에서는 이것이 그나마도 가장 탁월한
"코딩 과용"에 대한 방지책으로 쓸만하다고 생각한다. 대부분의 경우 코딩 후에 테스트를 생각하기에, 이미 작성한 코드를
줄이는 것은 어렵다. 하지만, 테스트를 먼저 생각하고 코딩에 들어간다면, 효과적인 틀을 코딩에 제공해 줄 것이다.
2 · [ 소프트웨어 개발자 이야기 ]

3. 넘치는 것은 모자란 것보다 못하다는 말이 있다. 즉, 과함을 경계하는 것이다. 과잉 코드는 검증을 어렵게 만들고, 버그의
가능성을 올려주는 효과와 더불어, 추가적인 관리노력도 필요하게 만든다. 코드가 많아질수록 일이 점점더 많아진다는 것
이다. 복제된 코드는 이미 버그의 주볌이라는 것은 익혀 알려져있다. 코딩의 과용과 부주의한 코드 관리가 그런 문제점들
을 낳고 있는 것이다. 따라서, 그런 것들을 제거하기 위해서는 코드를 과제 개발의 초기부터 검증하려는 노력과 병행되어
야 한다. 그리고, 코드의 구조를 개선하는 작업을 게을리해서도 안된다. 어떤 부분이 코드를 고약한 냄새(Bad Smell)가 나
도록 만드는지도 알아야 하며, 그런 것들을 어떻게 개선하는지도 익혀야 한다. 눈으로 확인할 수 없는 부분에 대해서는 툴
을 사용해서 알 수 있는 부분이 있으며, 일종의 부채(Debt)처럼 취급해야 할 것이다. 그런 것들은 꾸준히 갚아나가지 않으
면, 점점 늘어나는 이자로 인해서 생산적인 활동에 들어가는 노력을 갉아먹는 근본 원인이 되어버린다. 많은 코드를 만들
려는 욕심을 버리고, 제대로 요구사항을 충실히 수행하면서도 검증된, 품질이 우수한 코드를 만들어야 이유가 바로 여기에
있다. 품질은 잠시만 눈을 돌려도 쉽게 상해버리는 음식과 같다. 따라서, 코드는 필요한 만큼만 요리를 해야한다.
- 모자람은 욕구를 자극하지만, 차고 넘침은 안락함에 머물도록 만든다.-
3 · [ 소프트웨어 개발자 이야기 ]

4. 2016/04/11 11:04 http://blog.naver.com/knix008/220680139590
[ 실력있는 개발자(?) ][ 실력있는 개발자(?) ]
낙서장낙서장
정말 실력이 있다고 자부할 수 있는 개발자가 있을까? 물론, 사람은 자기 자신에 대해서는 후한 평가를 하는 경향이 있다.
하지만, 다른 사람과 비교해서 자신이 특별하게 탁월하다는 것을 자신감을 가지고 이야기 할 수 있는 사람이 있을까? 대부
분 자신에 대해서는 평가를 후하게 하더라도, 막상 다른 사람 앞에서 자신에 대한 평가를 해달라고 하면, 왠지 모르게 평범
한 것 이상은 이야기 하지 않는다. 아마도 이것은 겸손함을 표현하거나, 실제로 자신의 능력이 탁월한 수준이 아니라는 점
은 인정하는 태도일 것이다. 그렇다면, 정말 실력이 있는 개발자는 어떤 사람일까? 우린 실력을 키우기 위해서 노력한다고
생각하지만, 막상 그 목표점을 이야기하라고 하면, 정확히 떠오르는 모습이 없다. 여기서는 어떤 사람이 정말 실력이 있다
고 생각되는지를 개인적인 의견으로 적어보도록 하겠다.
실력있는 개발자는 자신의 코드를 남에게 공개한다. 여기서 말하는 "남"은 최소한 자신의 팀 내부정도로 한정할 수 있으
나, 넓은 의미에서 모든 개발자로 확대해서도 해석할 수 있다. 물론, 회사에서 정말 실력이 있다고 생각되는 개발자들은 이
런 것을 의식하지 않을수도 있다. 하지만, 자신의 코드에 대한 의견은 솔직함을 가지고 받아들이는 사람들일 것이다. 누군
가의 비판을 자신의 성장을 위한 밑거름으로 사용할 수 있는 준비가 된 사람이다. 그리고, 물론 자신의 코딩에 대한 철학도
확고하지만, 팀의 규정에 대해서 유연한 태도를 보일 것이다. 새로운 것만을 추구하는 것이 아니라, 전통이나 관례에 대해
서도 잘 따르는 사람이다. 그렇다고, 아무 이유도 없는 관습과 같은 것을 좋아하지는 않는다. 바꿔야 할 것이 있다면, 그 이
유와 미래의 가치를 두고 정당한 절차를 거쳐서 진행하려고 할 것이다. 다른 의견이 있다고 무시하는 것이 아니라, 다름을
인지하고 그것을 포괄하려고 노력할 것이다.
실력있는 개발자는 남을 돕는데 적극적일 것이다. 보통의 경우 이름이 있는(소위 잘 알려진) 실력이 있다고 생각하는 개발
자들은 남을 돕는 일을 게을리 하지 않는다. 이름이 있다는 것의 의미는 홀로 존재하지 않고 알려진 사람이다. 따라서, 자
신이 실력이 있다는 것을 남들이 먼저 인지하는 경우다. 이런 개발자들은 이른바 "네트워크"를 통해서 사람들에게 알려지
고, 그런 사람을 구하는 것이 쉽지 않다는 것도 잘 알려진 사실이다. 유명한 개발자는 자신의 분야에서 절대 헛되이 알려지
는 법이 없다. 책을 많이 쓰고 강연을 많이 한다고 유명해진다고 생각할지도 모르지만, 실제 업무를 같이한 사람들의 입소
문이 더 강하다. 그렇게 알려진 개발자들은 절대 일이 끊어지는 법이 없다. 누군가 그 사람들이 시장에 나오기를 간절히 기
대하기 때문이다. 도움을 받은 사람들은 그 도움에 상응하는 "존재감"을 부여할 것이고, 그 도움의 가치가 클수록 더 오래
동안 기억할 것이다. 단순히 자신이 일을 잘하고 있다는 느낌만으로는 실력을 가늠하기 어렵다.
실력있는 개발자는 일을 주도해서 진행하며, 자신이 가장 어려운 부분을 맡는데 주져하지 않는다. 따라서, 그런 사람들은
팀의 내부에서 개발자들의 존경을 받는다. 정말 실력이 있는 사람은 숨어 있는 개발자라고 할지도 모르겠지만, 그런 사람
들도 같이 일을 해보면 금방 드러난다. 그리고, 그런 사람들에게는 권한과 책임이 주어지는 경우가 많다. 즉, 일을 주도할
4 · [ 소프트웨어 개발자 이야기 ]

5. 수 있도록 배려해주는 것이다. 물론, 그렇게 책임과 권한을 받아들이는 것을 싫어하는 사람들도 있다. 예를 들어, 과제의
리더를 맡는 것을 주저할 수도 있다. 그런 사람들은 나름대로 잘하는 것과 즐기는 것이 있기에, 원하는 것을 맡기면 된다.
물론, 맡긴다는 의미는 권한과 책임이 주어지는 일이라는 것이다. 단순히 관리자로서만 아니라, 맡은 부분의 결과물에 대
한 권한과 책임을 가지는 것이다. 관리자가 되지 못하는 실력있는 개발자들도 많으며, 모든 사람이 관리자가 될 필요도 없
다. 관리를 좋아하는 사람은 따로 있기 마련이다.
실력있는 개발자는 스스로 자신의 능력이 탁월하다고 말로하지 않는다. 그들은 결과물의 품질로 승부하지, 이런 저런 말로
떠들어대지 않는다. 하지만, 그들에게도 자신이 만든 결과물에 대한 표현력은 필요하며, 그것이 부족하다면 옆에 있는 개
발자들이 돕는 것도 가능하다. 관리자의 시각이 반영되어 실력을 인정받는 것이 아니라, 동료들의 "인정"이 더 실력을 가
늠하기에 좋은 이유다. 옆에서 같이 일하는 동료들은 단순화된 시각보다는 실제 그 사람의 능력을 바라보는 객관적인 태도
를 유지하기 쉽다. 물론, 한 두명의 동료로는 부족할지도 모른다. 하지만, 실력이란 결국 동료들이 모인 집단에서 인정을
받아야 제대로된 검증이 되는 것이다. 단순히 자신이 잘 났다고 떠들어봐야, 들어주는 사람은 정말 친한 사람이거나, 그런
것에 대해서 별로 신경쓰지도 않는 사람일 것이다. 스스로의 실력을 검증받고 싶다는 욕구가 생긴다면, 남들의 객관적인
평가부터 들어야 한다. 그것도 가장 가까운 곳에서 일하는 사람들이 당신을 제대로 평가할 수 있을 것이다.
실력있는 개발자는 코드의 품질을 높이기 위한 방법을 잘 알고 있는 사람이다. 물론, 그 방법이라는 것의 대부분의 내용은
이미 알려진 것들일 것이다. 알려지지 않은 방법을 선택하는 것은 독특함은 있을지 몰라도, 그것이 가치를 높이는 방법은
아닐 것이다. 현재 나와있는 좋은 개발 방법들은 이미 상당부분 검증이 완료된 것들이다. 문제는 그런 것들이 지켜지지 않
5 · [ 소프트웨어 개발자 이야기 ]

6. 아서이지, 방법론이 부족한 것이 아니다. 제대로 하지 않아서이지, 제대로 했는데도 품질이 나빠지는 것은 아니다. 즉, 기
본을 지키는 개발자가 실력있는 개발자다. 누군가 과정의 생략을 말한다면, 그 과정이 생략될 수 있는 충분한 근거가 있는
지를 먼저 봐야하고, 그렇게 생략된 것들이 품질에 영향을 줄 수 있는가를 따져봐야 한다. 단순히 자신이 편해서 그렇게 하
겠다고 하는 것은 이유가 안된다. 그리고, 남들이 실력이 부족해서 이해하지 못한다고 하는 것도 이유가 안된다. 당신이 스
스로를 생각하는 것 만큼, 남들도 자신들에게는 항상 높이 평가한다. 실력은 결국 공유되는 가치를 통해서 검증되며, 그렇
게 검증되지 않은 것들은 스스로의 자만심 밖에 없다.
실력있는 개발자가 되기 위해서는 기본적인 것들을 잘해야 한다. 교과서적인 이야기라고 생각할지 모르지만, 우리가 대부
분 놓치고 있는 것들은 바로 그런 교과서에 나온 것들이다. 질서를 지키면 좋다는 것은 알지만, 질서(법, 규정등)를 지키지
않아서 남들보다 먼저 갈 수 있다고 생각한다면, 우린 서슴없이 그렇게 행동하는 것을 너무나 자주 보았다. 그렇게 해서 조
금더 빨리, 조금더 멀리 간다고 해서 달라지는 것은 없다. 긴 시간을 두고보면 기초가 튼튼한 사람이 더 오래동안 더 멀리,
그리고, 더 높은 가치를 이룰 가능성이 더 크다. 따라서, 조금 늦어지더라도 기본을 확실히 다지는 것이 정말 실력있는 개
발자가 되는 지름길이다. 아니 지름길이 아니라 "바른 길(정도)"이다. 단위 테스트를 만들고, 테스트를 위한 자동화에 힘쓰
고, 자신이 작성한 코드에 대한 코드 리뷰를 요청하고, 남들이 작성한 코드까지도 일일이 개선 사항을 지적하는 등등의 기
본기를 제대로 해야만 실력있는 개발자가 된다. 단지 팁(Tip)만을 익힌다고 실력이 향상되는 것은 아니다. 그리고, 그렇게
굳어진 실력이란 것들은 나중에 오히려 장애물로 다가설 것이다. 스스로 만든 함정에 스스로 빠져서 야근과 특근을 반복할
것이다.
실력있는 개발자가 되기 위해서는 사람을 잘 만나야 한다. 좋은 사람밑에서 배운 개발자는 안목이 다르다. 즉, 넓은 시각에
서 통찰력을 가지고 과제에 대해서 접근한다. 편협한 시각을 가진 개발자를 선배로 두는 것은 단기적인 해결방안에만 집중
한다. 처음에는 그것이 더 나아보이더라도, 조금만 시간이 지나면 오히려 구속처럼 작용한다. 만약, 자신이 현재 다루고 있
는 코드들이 복잡하고 어렵게 보인다면, 이미 그런 상황에 처한 것이 분명하다. 그렇다고, 자신의 선배를 비난할 생각은 하
지말자. 하루 하루 조금씩 향상 시켜나가는 것이 필요한 상황인 것이다. 그렇게하기 위해서는 팀내 모든 인력들이 같이 해
야한다. 일단은 구조화를 위한 관점을 공유해야하며, 코드에 공통적으로 사용할 코딩 룰을 정해야 한다. 코딩 룰에는 일반
적으로 동의되는 것들은 이미 인터넷에 충분히 있으며, 툴과 연계하고 싶다면 표준으로 정의된 것을 이용해도 된다. 공유
되는 가치를 높이는 것은 언제나 좋은 시작이다. 공부할 수 있는 분위기를 만들 수 있다면, 그것만으로도 좋다. 아무런 노
력도 하지않고 실력있는 개발자가 되는 일은 없기 때문이다. 자신이 정말 실력있다고 이야기할 수 있다면, 남들도 자신만
큼 실력이 있는 개발자가 되도록 돕는 일을 시작해야 한다. 혼자서만 잘나서는 제대로 된 경쟁이 있을 수 없다.
- "벼는 익을수록 머리를 숙인다." 그리고, 사람은 그런 벼들을 그냥 보고 있지 않는다.-
[ 참고 ] 벼들이 익기까지 기다림을 할 줄 알아야 하고, 수확해서 더 높은 가치를 실현할 수 있어야 한다.
6 · [ 소프트웨어 개발자 이야기 ]

7. 2016/04/08 08:38 http://blog.naver.com/knix008/220677575570
[ 게으름의 미학 ][ 게으름의 미학 ]
낙서장낙서장
일을 미루는 것과 일을 하지 않는 것은 다른 것이다. 일을 하지 않는 것은 일에 대해서 전혀 관심을 두지 않는 것이고, 일을
미루는 것은 그 일에 대해서 더 좋은 해결책을 찾는 것을 탐색하는 것이다. 즉, 게으름에도 차이가 있다는 말이다. 최대한
결정을 내려야 할 순간을 미루는 것은 그것이 정말 올바른 답인지를 끊이없이 검토하는 과정의 반복이며, 보이지는 않더라
도 머리속으로 다른 대안을 찾기위한 시간을 보내는 것이다. 물론, 일을 미루는 것과 일을 정말 하지않고 있는 상태는 구분
하기 힘들수도 있다. 하지만, "빨리 빨리"라는 말로 성급하게 결정해서 다시 수정하는 일이 발생하는 것보다는 최대한 늦
춰, 더 이상 미룰 수 없는 순간에 결정을 내리는 것이 재작업의 가능성을 최소화 시킬 수 있다. 한번 내려진 결정에 대해서
마치 무슨 불변의 법칙이라도 되는듯이 생각하는 것은 우스운 일이며, 내려진 결정이라고 해도 상황이 변하면 그에 맞게
수정되는 것도 필요하다. 다만, 최적의 순간을 찾는 것은 그 결정이 만들어낼 오류를 가능한 줄이는 시간이어야 할 것이다.
어떤 생각이 머리속을 떠나지 않는다는 것은 무언가 해결책을 고민하고 있는 상황이다. 그리고, 기가막힌 생각들은 간혹
뜻밖의 상황에서 떠오르곤 한다. 이런 일이 생기는 것은 우리가 의도적으로 어떤 것에 대해서 집중하는 상황에서는 좋은
해결책이 보이지 않다가도, 잠시 그 상황에서 벗어나 새로운 시각을 가지게 되는 순간, 문제를 통찰력있게 바라보고 해답
을 찾아내는 것처럼 보인다. 사실 이런 상태에 가기 위해서는 중간과정이 필요하다. 아무것도 하지 않고 이런 상태에 도달
하지는 못한다. 즉, 이 상태가 있기전에 집중력을 발휘해서 문제를 파고들어야 한다. 코딩도 마찬가지다. 특정 문제에 대해
서 집중적으로 생각하면, 나중에 자다가도 갑자기 좋은 코드가 떠오른다. 그 코드를 잊지 않기위해서 적어두기도 하고, 혹
은 핵심적인 코드만을 머리속에 다시 그려보기도 한다. 우리가 인지하지 않는 순간에도 뇌는 그 문제를 스스로 풀어나가고
있다가, 해답을 찾았을 때 알려주는 것이라고 생각할 수 있다. 즉, 잠재 의식속에 그 문제를 풀도로 요청하고, 우리는 다른
것들을 느긋이 즐기고 있는지도 모른다.
집중해서 문제에 대한 해결책을 찾으려는 노력이 선행된 후에 문제를 이해하게 되고, 다양한 시각을 통해서 문제를 분석한
후에 해결책을 찾게된다. 그냥 저절로 문제의 해결책이 나타나주는 것이 아니며, 시간을 줄이려고 급하게 풀려고해도 좋은
해결책을 마련할 수 없다는 것이다. 따라서, 우리에게 필요한 것은 "여유"이며, 그것을 통해서 다양한 시각을 갖출 수 있다
는 것이다. 게으름을 부리는 것은 그 동안에 들어갔던 노력이 선행되어야 좋은 결과를 보일 수 있다. 다양한 경험과 책을
통해서 얻을 수 있는 것들이 이와같은 시각의 차이를 만들어내는 원동력이 될 것이다. 코딩만 열심히 한다고 좋은 해결책
을 찾을 수 있는 것도 아니다. 사물은 한 가지 관점만이 존재하는 것이 아니라, 복합적으로 다양성을 가질 수 밖에 없다. 현
실에 등장하는 문제는 수학공식과 같이 완벽히 해답이 존재하는 경우가 드물며, 이런 저런 것들이 복잡하게 엮여있는 경우
가 많다. 따라서, 그런 문제들을 풀어내기 위해서는, 자신의 시각만으로 해답을 찾으려해서는 안된다. 책을 읽고 사람들과
이야기를 나누고, 그림과 음악을 통해서 여유 있는 상태가 되어야만 폭 넓은 시각이 생길 수 있는 것이다.
7 · [ 소프트웨어 개발자 이야기 ]

8. 소프트웨어의 "소프트(Soft)"란 말을 지나치게 강조하면, 모든 소프트웨어는 고치기가 쉽다는 말로 생각할 수 있다. 하지
만, 어떤 면에서는 소프트웨어는 하드웨어보다 더 "하드(Hard)"하다는 것도 알아야 한다. 100만 줄에 달하는 코드가 구조
적인 문제를 발생시킨다면, 그동안에 들어갔던 노력은 무용지물이 될 수 있다. 하드웨어는 최소한 남는 것이라도 있을지
몰라도, 소프트웨어는 한 방에 다 없어지기도 한다. 지금 빨리 만들고 나중에 수정하지라고 생각해서 급히 서둘러서는 안
된다는 말이다. 지금 결정할 수 있는 정보가 부족한 상태라면, 그 결정은 다음으로 미루는 것이 좋다. 지금 구현할 수 없는
것이라면, 구현하려고 노력해선 안된다. 차라리, 구현할 수 있도록 부족한 정보를 수집하는 것이 올바른 선택일 것이다. 모
델링을 하고 가안을 만들어서 사람들에게 보여주고 피드백을 얻는 것이 효과적일 것이다. 소프트웨어 개발이 단순히 코드
만 열심히 만들어서 끝나는 일이라면, 많은 사람을 투입해서 코드의 길이만 채우면 될 것이다. 하지만, 소프트웨어 개발은
그렇게 단순하지도 않을 뿐더러, 잘못된 결정은 생각보다 오래동안 그대로 유지될 가능성이 높다. 실수는 한 번의 과제에
서 끝나지 않는다.
코드를 작성하기 위해서 세부적인 사항에 대한 고민이 필요한 이유는, 그것을 구현하는 노력이 많이 들어서가 아니라, 그
것을 유지하는데 필요한 비용이 크기 때문이다. 세부적인 고민이 없이 만들어진 코드들은 나중에 재작업이란 비용을 지불
해야 하지만, 제대로 고민한 코드들은 상대적으로 적게든다. 물론, 완전히 재작업이 필요없는 코드를 만드는 것은 불가능
할지도 모른다. 코드는 지속적으로 개선되고 발전되어가기 때문이다. 아이러니하게도 유지보수가 많이되는 코드는 잘 작
성된 코드도 있지만, 그렇지 못한 코드들도 있다. 잘 작성된 코드들은 오래동안 사용되기 때문에 유지보수가 많이되며, 그
렇지 못한 코드는 관성때문에 계속 유지보수 된다. 따라서, 두 가지 모두 유지보수라는 과정을 겪게된다. 차이가 나는 점은
유지보수가 만들어내는 가치(Value)이다. 잘 작성된 코드는 상대적으로 기능추가가 용이하고, 변화에 대응하는 시간도 짧
게 걸린다. 그렇지 못한 코드는 상대적으로 기능추가가 더디며, 변화를 싫어하는 방향으로 굳어져간다. 따라서, 시장에서
생성해내는 상품의 가치도 점점 경쟁력 상실에 따라 줄어들게 될 것이다.
8 · [ 소프트웨어 개발자 이야기 ]

9. 시작은 비슷하지만 결과가 차이가 나는 것은 시간의 "여유"의 차이에서 나온다. 물론, 모든 과제는 충분한 시간이 주어지
지 않는다. 오히려 대부분의 과제는 시간을 단축하라는 압박을 받는 것이 사실이다. 그리고, 실제로 매일 그런 압박에 과제
담당자들은 시달린다. 하지만, 그렇다고해서 그냥 만들수는 없는 것이다. 소프트웨어 과제의 핵심은 "품질"에 달려있다.
품질을 높일 수 있는 여유를 "게으름"으로 해석해선 안된다. 코딩이 단순히 코드를 만드는 활동이 아니라, "설계->구현->
테스트->문서화"를 통합한 활동이라는 점을 알아야 한다. 쉽게 만들어진 결정은 쉽게 변경되듯이, 충분히 검토한 것들은
잦은 변경이 발생하지 않는다. 빨리 만들어서 고치는 시간을 많이 들이는 것보다는, 고민해서 만들어 고치는 횟수를 줄이
는 것이 더 나은 선택이다. 품질이 뒤받침이 되지않는 코딩은 "시간이 없다는 말"로 모든 것에 대한 변명을 만들지만, 실제
로 재작업이 발생하는 것이 사실이다. 따라서, 우린 "제대로 할 시간은 없다고 이야기하면서도, 매번 비슷한 실수를 반복
하는 것"은 이상하리 만치 당연하다고 생각한다. 그것은 당연한 것이 아니라 개선되지 않는 것이다. 아무리 급해도 결국 바
늘허리에 실을 매달수는 없다. 마음이 급해선 제대로 만들수 없으며, "생각할 시간의 여유"가 없이는 제대로된 코드도 만
들어지지 않는다.
- 급한가? 그럼 오늘은 그냥 쉬어라. 내일 할 일을 오늘 할 필요는 없다.-
9 · [ 소프트웨어 개발자 이야기 ]

10. 2016/04/06 14:24 http://blog.naver.com/knix008/220675912858
[ 반복이 답이다. ][ 반복이 답이다. ]
낙서장낙서장
힘든 일은 더 자주 하라는 말이 있다. 힘들다고 시작하지 않는다면, 절대 잘 할 수 없다. 자주 하라는 것은 습관이 되도록
만들라는 것이다. 습관처럼 하는 것들은 힘(정신적인 집중력을 포함해서)을 거의 사용하지 않는다. 처음 시작할 때는 지속
적인 집중과 물리적인 힘까지 동원해야 하지만, 반복적으로 하게되면 최소의 노력으로도 꾸준한 성능(Performance)를
유지할 수 있도록 만들어주는 것이 습관이다. 한번에 개발을 끝내려고 한다면, 모든 부분이 아주 정교하게 잘 정의되어 치
밀하게 관리되어야 한다. 초기 설계가 확고 부동하며, 거의 변경이 없을 경우에는 이런 방법이 통할 수 있다. 하지만, 사소
한 실수가 발생하더라도 이것은 곧 깨진다. 따라서, 한번에 모든 것을 이루려고 애쓰기 보다는 반복적으로 개발하는 것을
짧은 주기로 돌리는 것이 목표 지점에 조금이라도 근접하게 된다. 어차피 천리길도 한 걸음 한 걸음으로 이루어지고, 그 각
각의 반복에 최소한의 오류만 남길려고 노력한다면, 매일 매일 우리는 정확한 목표를 향해 조금씩 전진하고 있는 것이다.
우리가 만들어야 할 제품의 100가지의 기능이 있다면, 우리는 어떻게 그것을 개발할 수 있을까? 먼저 해야할 일은 방향을
설정하는 것이다. 어디로 갈지를 모르는 상태에서는 아무리 노력을 들여도, 재 작업이라는 것이 남아 있게된다. 따라서, 전
체 시스템을 어떻게 구성할 것인지에 대한 청사진 정도는 있어야 한다. 설계가 무의미하다고 생각할지는 모르지만, 설계는
의미있는 일이며 얼마나 자세할 것인가가 문제인 것이다. 너무 자세한 설계를 하기위해서 시간을 들이는 것은 의미가 없을
수도 있다. 물론, 여러번 반복해서 개발해본 경험이 있는 경우에는 이미 자세한 설계가 없이도 구현이 가능할 것이다. 기존
의 코드를 재활용하는 것은 시간의 단축만이 아니라, 검증 노력의 절감과도 이어지기 때문에, 완전히 새로운 개발보다는
항상 이득이 있다. 하지만, 기존의 것을 재활용은 하되, 조금이라도 개선할 부분을 가져가는 것도 좋다. 어쨌든, 너무 자세
한 설계보다는 시스템의 대략적인 구조를 보여주는 설계와 서브 시스템의 구성, 모듈의 구성수준까지는 결정하는 것이 좋
다. 그리고, 각 모듈들이 연결되어 동작하는 방식에 대해서 대표시나리오로 검증하는 것도 좋을 것이다.
대략적인 구조에 대한 정의가 완료되면, 이제는 각 각의 기능들에 대한 우선 순위를 조정할 차례다. 즉, 우선 순위가 가장
높은 기능을 먼저 개발하는 것이 좋다. 힘든 기능이 우선 순위가 높을수도 있고, 그렇지 않을수도 있다. 따라서, 각각의 기
능에 대해서 우선 순위와 선행성을 먼저 검토해야 할 것이다. 어떤 기능은 다른 기능에 의존할 수도 있기에, 그런 기능들은
순서가 이미 정해진 것들이다. 이때, 각각의 기능을 구현하는 것을 작은 프로젝트처럼 생각하면 어떨까? 즉, 각각의 기능
을 개발할 때, 과제의 완료조건과 유사한 것을 사용할 수 있다면, 구현된 기능에 대해서는 검증이 된 것이라고 가정할 수
있다. 이것을 확장해서 각 기능별로 소규모 과제로 가져간다면, 각각의 기능을 구현하는 것을 반복으로 볼 수 있으며, 조금
씩 안정적인 코드가 추가되는 방향으로 생각할 수 있다. 한 한가지 주의할 부분은 초반에 구현되는 기능들이 우선 순위도
높아야 하지만, 시스템의 상위 계층에서 하위 계층까지 골고루 포함할 수 있는 기능이어야 한다는 점이다. 즉, 초반에는 한
가지 기능에 대해서 깊이 방향으로 탐색을 끝낼 수 있어야 한다는 것이다. 그리고, 테스트를 위해서는 최상위 인터페이스
10 · [ 소프트웨어 개발자 이야기 ]

11. 계층의 개발이 초반에 진행되는 것이 좋다. 각각의 기능들은 어차피 사용자의 시선에서 검증이 되어야 다음 기능이 개발로
이어질 수 있다.
"T"자와 같은 구조의 개발이 초반에 이뤄진다면, 나머지 개발과정은 "T"자의 양 옆에 있는 빈 공간을 채우는 개발이 될 것
이다. 이때도 반복의 중요성은 잊어선 안된다. 각각의 기능을 작은 과제처럼 다루지 않고, 한꺼번에 많은 부분을 구현해 넣
으려고 생각한다면, 결국 복합적인 문제를 가져갈 가능성이 높다. 원인의 규명이 늦어지는 이유는 구현과 검증사이가 벌어
지기 때문이다. 따라서, 최대한 그 거리를 줄일 수 있다면, 오류의 원인도 빨리 밝혀낼 수 있게 된다. 기능의 추가가 가져오
는 효과는 코드의 반복이 있을 수 있다. 즉, 복제된 코드가 양산될 가능성이 있는 것이다. 따라서, 그런 반복을 줄이는 툴들
을 이용할 필요도 있다. 단순한 물리적인 코드의 반복만이 아니라, 지속적으로 코드의 수정이 이뤄지는 부분에 대해서는
새로운 해결책을 찾을 수 있어야 할 것이다. 에를 들어, 디자인 패턴과 같은 것을 이용해서 그런 부분들에 대한 변경을 최
소화할 수 있는 방법을 적용해도 괜찮다. 개발 과정에서 코드에 대한 리뷰와 단위 테스트를 실시하는 것은 최소한 자신이
개발한 모듈에 대한 것은 안정적으로 확인할 수 있도록 만든다. 하지만, 모듈과 모듈의 결합을 검증하기 위해서는 시스템
수준의 기능에 대한 시나리오 검증이 필요하다. 성공하는 케이스와 실패하는 케이스 등등 다양한 시나리오늘 통해서 시스
템이 안정적으로 동작하는지를 검증해야 할 것이다.
반복이 효과를 가지기 위해서는 반드시 반복의 마지막에는 검증이 이뤄져야 한다. 검증되지 않은 코드의 누적은 기존의 개
발과 다르지 않다. 결국 통합 후에 많은 버그의 양산을 가져올 뿐이다. 또한, 기존의 반복에서 검증되었던 것 까지도 포함
해서 검증되어야 한다. 이런 상황이라면 테스트의 자동화는 어쩔 수 없이 따라올 수 밖에 없다. 즉, 반복이 꾸준한 속도를
유지하기 위해서는 테스트에 들어가는 시간을 최소화하고, 빠르게 피드백을 받은 루프를 가져야 하기 때문이다. 만약, 피
드백을 받는 시간이 길어지게 된다면, 반복의 속도도 점점 느려지게 되며, 결과적으로 원래의 개발 사이클과 크게 다르지
않는 형태로 바뀔 것이다. 따라서, 테스트 자동화를 범위를 높이지 않으면, 제대로된 반복을 하기 힘들다. 이를 위해서 투
11 · [ 소프트웨어 개발자 이야기 ]

12. 자되는 시간은 반드시 과제의 시작에서 확보해야할 부분이며, 추가적인 일이 아니라 근본적으로 해야하는 일이다. 이것이
힘들다고 미뤄진다면, 결국 자동화 테스트는 물건너가고, 높은 비용의 사람을 투자하는 일이 늘어나게 된다. 당연히 이런
테스트는 재활용도 불가능한 비용일 뿐이다. 한 번만 투자할 비용이라면 상관없지만, 다른 과제를 하더라도 별반 달라지지
않을 것이다. 비용이 많이 들어가는 개발은 결과적으로 내 주머니만 비우게 되는 효과를 가져온다.
반복은 문제를 일찍 드러내게 만들고 수정할 수 있는 기회를 빨리 만들어준다. 성능상의 문제를 마지막에 발견하게 된다
면, 아무리 개선해도 15%보다 크게 개선되지는 않는다. 물론, 대규모의 구조개선 작업을 통해서 100%이상의 개선을 가
져올 가능성도 있다. 하지만, 그 개선에 필요한 노력은 생각보다 클 것이다. 구조적인 개선은 대부분의 경우 대량의 버그
발생과 관련되며, 반복을 통한 작은 단위의 구조개선이 오히려 성능문제를 빨리 개선할 수 있다. 특히, 전체 계층을 아우르
는 핵심 우선기능의 구현에서 발견된 성능문제는 그 즉시 구조의 개선으로 이어질 수 있으며, 초반의 코드 구현량은 많지
않기에 빨리 고칠 가능성도 높다. 기존의 코드를 재활용하는 개발과제의 경우에도 반복은 문제를 빨리 드러나게 만든다.
즉, 기존 코드의 약점을 핵심기능의 동작 여부를 통해서 밝혀낼 수 있기 때문이다. 이때 취할 수 있는 접근 방법은 기존의
코드를 대규모로 개선하거나, 혹은 조금씩 각각의 반복에 개선을 가져가는 것이다. 위험을 줄이기 위해서는 각 반복마다
개선해야할 부분을 미리 정하고, 큰 그림을 놓고 접근하는 것이 옳을 것이다. 변화는 어떤 식으로든 한꺼번에 많이 가져가
는 것은 실패로 이어질 가능성이 높다.
- 세상의 위대한 일들은, 작은 반복의 결과물이다.-
12 · [ 소프트웨어 개발자 이야기 ]

13. 2016/04/05 15:24 http://blog.naver.com/knix008/220674987588
[ 규정과 다양성 ][ 규정과 다양성 ]
낙서장낙서장
조직으로 일할 때는 같은 옷을 입고, 같이 움직이고, 밥을 먹는 것을 좋아한다. 하지만, 이런 것들로 인해서 개인의 다양성
이 무시된다고도 이야기 한다. 어떤 일을 할 때도 방법을 정하고 그것에 맞춰서 일하기를 좋아하는 사람이 있는 반면, 어떤
사람들은 자신의 의견을 충분히 반영해서 스스로 정한 규칙(몸에 익숙한 방법)으로 일한다. 사실 어느쪽이 더 생산성이 높
고, 더 가치가 높으냐를 따지는 것은 무의미하다. 우린 규정도 필요하고, 다양성을 보완해야지 높은 생산성과 가치를 둘 다
실현할 수 있기 때문이다. 소프트웨어의 개발도 마찬가지다. 규칙을 무시한 홀로서기는 환영받기 어려운 사람으로 만들고,
규칙만 중시하는 것은 틀에 가둔 창의성만을 북돋우기 때문이다. 우린 그런 식으로 일하지도 않거니와, 그렇게 관리되지도
않는다.
규정은 필요하다. 업무의 프로세스가 없으면, 어떤 일을 먼저하고, 누구하고 같이하고, 어떻게 완료되었는지를 확인할 수
없다. 따라서, 일의 효율이 나빠진다. 프로세스 없이는 사람들이 예상하는 바대로 움직이지 않는다는 것을 금방 알 수 있을
것이다. 지하철을 탈 때도 "표를 사고, 게이트를 표를 확인시켜서 통과시키고, 가려는 방향의 플랫폼으로 가서, 문이 열릴
때 탄다"와 같은 프로세스가 있는데, 하물며 사람들이 같이 일하는 곳에서 프로세스가 없을 수 없다. 방법론이 없다고 이야
기하는 것도 사실은 방법론을 가지고 있으면서 정확히 파악하지 못하고 있는 경우일 뿐이다. 어쨌든 우리는 일이 원활하게
돌아가기 위해서는 절차가 필요하다는 것은 모두 공감한다. 다만, 그 절차가 너무 따르기가 힘들거나, 과하다고 생각 될 때
는 반감을 가지게 되는 것이다.
창의성은 업무의 내용으로 표현된다. 즉, 업무의 틀은 유지하면서(누군가 틀에 대한 것이 제한적이라고 할지도 모르겠지
만), 그 속에서 자신의 독특함을 표현해 낼 수 있다. 창의성은 문제를 해결하는 방법에 있어서의 차이를 나타내며, 효율과
가치의 차이를 만들어 낸다. 따라서, 창의적인 태도는 권장해야 할 사항이라는 것은 이미 다 알고 있다. 하지만, 문제는 창
의성을 발위하려는 순간에 발생하는 규정과의 충돌이다. 예륻 들어, 인터넷 비지니스 모델을 개발하는 개발자들에게 보안
상의 이유로 특정 사이트를 막거나, 혹은 무선 인터넷과 같은 것을 제한한다면, 제대로된 개발이 될 수 있을까? 실제로 이
런 일을 발생한다. 회사의 입장에서는 개발보다 보안이 우선시 된다. 물론, 그런 것이 창의적인 생각을 구속한다고 보지 않
을 수도 있다. 하지만, 그런 경우를 당하면, 일단 자신의 생각을 접는 것도 사실이다.
13 · [ 소프트웨어 개발자 이야기 ]

14. 규정은 창의력이 뻣어나가는 방향에 대해서 제대로 전부 공간을 만들어 놓을 수 있을까? 이것은 마치 법이 모든 인간의 행
위에 대해서 다 정의할 수 있을까와 비슷한 성격의 문제다. 법이 그렇게 할 수 없었듯이, 규정도 마찬가지일 것이다. 하지
만, 우린 규정의 도움 없이는 일을수월하게 처리할 수 없음도 알고 있다. 따라서, 규정의 바탕위에 창의성이라는 부가가치
를 추구할 수 있는 여지를 남겨두어야 한다. 프로세스가 결과물의 품질은 규정할 수 있지만, 그 품질을 높이는 방법까지는
정의할 수는 없으며, 해결책의 구체성까지도 정할 수는 없다. 그것은 결국 개발자의 몫이며, 다양함이 존재하는 근본이기
때문이다. 개인의 차이는 어쩔 수 없지만, 마치 한 사람이 만든 것과 같은 코드를 만드는 것은 규정의 힘이다. 하지만, 겉모
양이 비슷하다고 모든 것이 동일하지 않은 것은 실무를 담당한 개발자가 발휘해야할 능력이다.
최소한의 규정으로 최대한의 품질과 가치를 만들어낼 수 있다면, 그것은 아마도 회사에서 가지고 있는 최고의 성과물이 될
수 있을 것이다. 대부분의 회사는 규정에 대해서는 힘을 싫어주지만, 개인의 창의성에 대해서는 아무런 노력을 하지 않는
다. 에를 들어, 어느날 방문하신 높으신 분이, 개발자들이 일하는 공간에 있는 파티션이 높다는 이야기를 했던 적이 있다.
조금 시간이 지나자 파티션의 높이는 앞 사람의 얼굴이 보일 정도로 낮아졌고, 가끔 서로 얼굴을 마주보는 민망함을 느껴
야 했었다. 그 사람의 궁금증을 해결하기 위해서, 수 백명의 사람들이 민망함을 겪어야 한다면, 그게 정말 옳바른 결정일
까? 물론, 그 일을 담당한 분에게는 올바른 결정일지도 모른다. 하지만, 그곳에서 일하는 사람들은 규정이라는 이상한 잣
대를 쓸모없이 사용하는 사람들만 기억속에 담았을 것이다. 별거 아닌 이야기 일지도 모르지만, 우린 힘을 가진 사람들이
얼마나 어리석은 짓을 하는지를 자주 보는게 지켭다.
규정이 재대로 힘을 발휘하기 위해서는 개발자들이 정말 필요하다고 생각되어서 하는 경우와, 규정 자체가 정당함이 충분
히 증명된 것이어야 한다. 이상한 규정은 이상한 행동과 결과만을 만들 뿐이다. 예전에 만들었기 때문에 계속 사용되어야
14 · [ 소프트웨어 개발자 이야기 ]

15. 한다는 규정들 중에서 만들어진 이유가 이미 없이진 경우도 있을 것이다. 그런 것들이 하나 둘씩 늘어나면, 결과적으로 해
야할 일보다 하지 않아도 되는 일에 시간을 더 많이 뺐긴다. 절대로 변화하지 않는 것은 없다는 말이 있듯이, 규정 또한 상
황에 맞게 변화를 해야한다. 잘 지켜지고 있는 부분에 대해서는 느슨하게 유지하는 것도 필요하며, 잘 지켜지지 않는 부분
에 대해서는 강화를 해야할 필요도 있다. 하지만, 이런 모든 행위의 결과가 권위에 의해서 강압적으로 유지되어야 한다는
것은 개발자들이 받아들이기 어려울 것이다.
- 관리란 관리되는 사람이 관리되고 있지 않다고 느낄 정도가 되어야, 제대로 관리되고 있는 것이다.-
15 · [ 소프트웨어 개발자 이야기 ]

16. 2016/04/04 10:29 http://blog.naver.com/knix008/220673697351
[ 코드 리뷰에 대한 잘못된 생각 ][ 코드 리뷰에 대한 잘못된 생각 ]
낙서장낙서장
코드 리뷰를 하는 것은 쉽고도 힘든 일이다. 어떤 이들은 코드 리뷰가 필요없다고도 이야기 한다. 혹은, 자신의 코드는 리
뷰의 대상이라고 생각하지 않고, 다른 사람의 코드만 해당한다고도 말한다. 정말 그럴까? 개인의 능력은 차이가 있는 것은
당연하다. 자료에 따르면 팀은 26배까지 역량의 차이를 보이고, 개인은 10배 정도의 차이를 보인다고 한다. 물론, 이때의
개인은 잘하는 사람은 보통보다 5배, 못하는 사람은 보통보다 5배 정도 떨어지기 때문이다. 대단한 역량을 가지고 있는 팀
원들로 구성된 조직이라면, 그들간에는 코드 리뷰에 대한 저항감이 덜할 것이다. 왜냐하면, 그들 스스로 문제를 해결하는
자기 조직적인 역량을 이미 갖추고 있기 때문이다. 하지만, 그런 사람들만으로 구성된 팀도 오히려 뒷걸음질 치는 경우도
있다. 즉, 팀으로 일할 때는 각자의 역할이 다름을 알아야 하며, 누군가는 소위말하는 귀찮은 일을 해야하기 때문이다. 그
런 이들을 무시하면 결과적으로 역행하는 결과를 낳게된다. 희생이란 모두가 잘 할 수 있는 토대를 만들기 때문이다.
코딩을 아주 잘하는 사람이 있다고 가정하자. 그 사람의 코드를 실력이 부족한 사람이 리뷰하는 일이 가치가 없을까? 만
약, 코드 리뷰를 하는 사람이 다른 과제에서 다른 일을 하고 있다면, 남의 과제에 감나라 씨나라 하는 것은 의미가 없을 수
있다. 하지만, 같은 팀에서 같이 일하는 팀원인 경우에는 다르다. 코드 리뷰는 공유를 통한 역량 향상과 버그를 찾아내는
것이지, 누군간의 자존심을 짓밟거나 비난하기 위한 자리가 아니다. 자존심이 강하고 실력이 있다고 자부하는 사람이라면
이런 자리가 못마땅할 것이다. 하지만, 자신의 코드를 통해서 남들도 역량이 향상되고, 다양한 시각에서 잘못된 점을 수정
할 수 있다면, 오히려 피드백을 통한 성장이 가능하다. 코드 리뷰의 효과에 대해서는 이미 조사한 결과가 있다. "Caper
Johnes"라는 사람이 정리한 자료에 의하면, 코드 리뷰는 비용적으로도 오히려 싸게 버그를 제거할 수 있는 방법이다. 자
신의 코드에 버그가 없다고 장담할 수 있는 사람은 없다. 코드를 이해하지 못해서 버그가 발생하는 것이 아니라, 코드를 이
해해도 버그는 존재한다. 세상의 모든 소프트웨어는 완벽할 수 없기 때문이다.
코드 리뷰를 형식적으로 하는 조직에서는 당연히 그런 효과를 기대하기는 어렵다. 대부분의 조직은 코드 리뷰를 형식적으
로 하는데 익숙하다. 자신의 일을 하기도 바쁜데 남의 일까지 간섭하는 것이 어찌보면 이상하게 보일 것이다. 하지만, 한
줄의 코드라도 많이 작성하는 것이 아니라, 한 줄의 코드라도 품질을 높이는 것이 더 중요하다. 더 나은 코드를 짜는 길은
많이 사람의 의견을 듣는 것이라는 점은 이론의 여지가 없다. 특히, 그 코드를 동료가 봐주는 것이 독단에 따른 잘못될 가
능성을 최대한 줄일 수 있다. 실력이 없는 사람이 팀원이고, 그 사람이 리뷰를 해야한다면 더 좋을 것이다. 코드 리뷰를 꾸
준히 하면 그런 사람의 역량도 곧 수준이 높아질 것이기 때문이다. 실제로도 이런 경험은 많이 할 수 있다. 조직의 역량은
전체의 시너지를 말하는 것이지, 개인의 탁월한 코딩 실력으로 승부가 나지 않는다. 앞에서 보았듯이, 26배의 차이를 보이
기 위해서는 조직적인 차원에서의 역량 개발이 필요한 이유다. 코드 리뷰는 그 어떤 방법보다도 개인의 개발역량을 직접저
으로 높일 수 있는 기회다. 자신이 그 조직에서 특출하다고 생각하고, 자신의 코드를 남에게 보여주지 않겠다면, 다른 사람
16 · [ 소프트웨어 개발자 이야기 ]

17. 의 코드도 볼 이유가 없다. 그 누군가도 자신이 직장에서 "반드시 필요하며 일을 잘하고 있다는 환상"속에 속한 95%의 인
력이기 때문이다.
실제로 대부분의 직장인들은 "자신은 능력이 높고, 회사에서 꼭 필요한 인력"이라고 생각한다. 이는 자기평가를 해보면 쉽
게 나타나는 결과다. 매년 11월 경이면 직장에서는 자기평가라는 것을 하게된다. 이때 100점을 만점으로 평가를 하라고
하면, 대부분의 사람들이 90점을 넘는 결과를 가져온다. 심지어 팀에서 가장 역량이 낮다고 생각되는 사람도 90%점 정도
를 자신에게 준다. 물론, 고과자가 이 점수를 그대로 믿는 것은 아니며, 그렇다고 생각해서 피고과자도 일부러 높이주는 경
향이 있다. 하지만, 아쉽게도 그런 평가는 무의미하다는 것을 알 수 있을 것이다. 결국 누군가의 시각으로 사람들은 고과를
부여받으며, 그 고과에 대한 불만을 표출하는 것도 매년 반복되고 있다. 어쨌든 이를 통해서 알 수 있는 것은, 우리는 우리
자신을 남의 눈으로는 절대 보지 못한다는 점이다. 코드도 마찬가지다 자신의 눈으로만 확인해서는 절대 좋은 코드를 만들
어낼 수 없다. 객관적인 시각이 결여된 상태에서는 아무리 객관적으로 보려고 해도 제대로된 형상보다는 해석된 것만 바라
볼 뿐이다. 코드 리뷰는 이런 상황을 개선할 수 있는 방법이며, 실력이 부족한 사람이라면 더욱 안목을 높일 수 있는 기회
다. 그 기회마져도 주기 싫다면, 당신은 혼자서 일하는 사람이지 팀원이 아니다.
작은 회사에서 일한다고 마음까지 작아져선 안된다. 큰 회사로 도약하기 위해서는 작은 회사때부터 제대로 해야한다. 만
약, 그런 것들이 갖춰진 상태가 아니고 비용이 많이 든다고 한다면, 비용이 안드는 방법을 생각해도 된다. 좋은 시스템으로
하지 못한다면, 오픈 소스를 이용해서 최소한이라도 해야한다. "Code Collaborator"와 같은 툴이 비싸다면,
"ReviewBoard"를 이용할 수도 있다. 발전이란 무슨 툴을 사용하는가가 문제가 아니라, 어떻게 하고 있는가가 핵심이다.
작은 회사라도 제대로만 하면 그것 자체가 역량이된다. 즉, 커나갈 수 있는 바탕이 만들어진다는 것이다. 제대로 하지않고
제대로 성장하기를 바라는 것이 오히려 이상한 것이 아닌가? 팀원들의 역량이 발전하지 않는데, 팀이 성장하기를 원하는
것은 사기일 뿐이다. 혼자서만 잘한다고 잘 된다고 생각한다면, 우물안의 개구리보다 못한 끓여지는 물속의 개구리가 될
것이다. 언제인지는 몰라도 떠날 수 있는 준비를 하는 사람으로만 다른 사람의 눈에 비칠 것이다. 그렇게 떠날 사람에게 핵
17 · [ 소프트웨어 개발자 이야기 ]

18. 심인 일을 맡기고 있다면, 그 회사는 미래가 없다. 안목이 있는 사람이라면 그런 사람을 대체할 백업(Backup)인력을 한 사
람쯤 옆에 붙여둘 것이다.
코르 리뷰도 마찬가지로 사람의 문제다. 그 사람의 문제를 소통으로 해결하려는 시도인 것이다. 소통을 제대로 하지 못하
는 조직일수록 리뷰하는 문화는 정착하지 못한다. 모든 코드를 세상에 오픈하라는 것도 아니다. 적어도 자신이 같이 일하
고 있는 사람들에게는 "상생"하는 문화를 만들어야 한다는 것이다. 지금까지 한 번도 오픈소스코드를 사용한 적이 없다고
이야기하는 사람들도, 사실은 남의 코드를 "Copy&Paste"해서 가져다 쓴 기억은 있을 것이다. 그것마져도 없다는 사람들
도 최소한 "책에 나온 예제"정도는 가져다 썼을 것이다. 그것이 오픈소스는 아닐지라도 우리는 어떤 식으로든 과거의 유산
(남들의 혜택)에서 자유로울 수 없으며, 누군가는 자신의 코드를 공유했으며 그 댓가로 살아가고 있는 것이다. 남을 돕는
마음은 크게는 세상으로 향할 수도 있지만, 최소한 팀에서 일하는 동료에게라도 향해야 할 것이다. 비록 실력이 뒤쳐지고,
게으르게 생각되는 동료라도 리뷰를 같이할 수 없을 정도는 아닐 것이다. 만약, 그런 사람이 동료라고 생각된다면, 당신이
그 자리에 있을 이유는 없다. 함께 일할 팀을 찾게될 때, 자신이 가장 역량이 낮은 사람이 될 수 있는 팀을 찾는 것이 좋다.
그런 팀이라면 성장이라는 목표를 이루기에 좀 더 유리할 수 있을 것이기 때문이다.
하지만, 이미 성장을 했다고 믿는다면, 이제는 다른 사람의 성장도 당신의 손에 달린 것이다. 단순히 혼자만 잘 먹고 잘 산
다고 세상이 좋아지는 것은 아니다. 자신의 모자란 지식이라도 조금씩 세상을 위해서, 혹은 자신이 이끌고 있는 팀을 위해
서 사용하도록 해야한다. 혼자 높은 직위로 올라간다고 좋아지는 것이 아니며, 혼자서만 높은 연봉을 받는다고 그것이 지
속되지도 않는다. 결국 같이 일하는 동료들이 성장해야하고, 그것을 통해서 당신이 진급도하고 연봉도 높일 수 있는 것이
다. 물론, 돈이 인생의 전부가 아니지만, 돈은 시간이란 비용을 아낄 수 있는 방법을 제공한다. 지금 투자하는 노력이 미래
를 좀더 빨리 달성할 수 있도록 돕는다는 것이다. 투자하는 노력을 절감할 수 있다면 그것이 돈을 버는 방법이다. 코드 리
뷰를 제대로 하는 것이 미래에 들어가야 할 비용을 줄 일 수 있다면 안할 이유가 없다. 그리고, 남들의 시각을 통해서 알지
못했던 것들도 알게된다면, 혹은 다른 사람의 역량을 조금이라도 성장시킬 수 있다면, 그것으로도 이미 훌륭한 투자를 하
고 있는 것이다. 결국 우리가 일하는 업계의 수준은 조금더 올라갈 것이고, 당신은 올라간 업계에서 조금더 높은 위치를 사
람들에게서 얻을 수 있기 때문이다. 오픈소스를 옹호하는 사람이 되라는 것이 아니라, 자신의 지식을 조금더 나은 미래를
위해서 투자하라는 말이다.
- 공부하라. 그래야만 더 넓은 시각을 가질 것이다. 세상은 아는 만큼 보이고, 보이는 만큼 자신의 영역을 가질 것이다.-
18 · [ 소프트웨어 개발자 이야기 ]

19. 2016/04/01 09:51 http://blog.naver.com/knix008/220671178715
[ 항상 사람이 문제다. ][ 항상 사람이 문제다. ]
낙서장낙서장
소프트웨어 개발에서는 풀어야 할 문제도, 그것을 풀어가는 것도 모두 사람에 관련된 것들이다. 기술이 문제가 되는 경우
는 구현이 불가능할 정도로 어렵다고 느껴지는 것들이며, 대체로 오랜 시간을 연구해야지만 풀 수 있는 것들이다. 따라서,
바로 시장으로 연결될 가능성이 낮은 것들이다. 물론, 그런 것들도 나중에는 일반화되어 그것을 사용하는 사람의 문제로
바뀔 것이다. 어쨌든 우리가 풀어야 하는 대부분의 문제들은 사람에 대한 것이며, 그것을 풀어가는 사람에 대한 것이다. 하
지만, 종종 우리는 소프트웨어 개발을 단순히 기술의 문제로 생각해 버리는 경향이 많다. 사람을 단순히 기술을 알고 있으
며, 그것을 구현하는 존재로 밖에 생각하지 않는데서 문제가 시작된다.
사람의 가치를 단순화 시키는 것은, 사람이 가지고 있는 측정할 수 없는 가치를 잊는 것이다. 측정할 수 없는 가치를 망각
하고, 단순히 언제든 바꿔끼울 수 있는 존재로 생각하는 것은, 해결해야할 문제를 푸는 사람을 제대로 가치있게 만들지 못
하기에, 결국 그 해결책 자체도 대상을 만족시키지 못하게 된다. 문제를 알아가는 과정도 중요하지만, 제대로 과정을 밟지
못하도록 만드는 것은, 이미 문제를 잘 있다는 선입견을 가지기 때문이다. 하지만, 모든 해결해야하는 문제는 나름의 독특
함을 가지고 있으며, 해결책의 수준도 천차만별임을 알아야 할 것이다. 그런 차이를 만들어내는 것이 바로 사람이다.
잘만든 프로그램과 그렇지 못한 프로그램의 차이는 당장은 드러나지 않을수도 있다. 따라서, 빨리 응답하는 사람에게 점수
를 후하게 주는 것은 당연한 일일지도 모른다. 하지만, 회사는 손을 먼저 들어서 정답을 이야기했다고 다음 문제로 넘어가
는 학교가 아니다. 문제에 대한 해답을 제시하는 것과 더불어, 나중에 그 문제를 다시 몇 번씩 되풀이해서 풀어야 한다. 되
풀이 할 때마다 조금씩 문제의 난이도는 높아지며, 점점더 복잡한 것들을 요구할 것이다. 빨리 응답하는 것도 중요하지만,
풀이의 정확도와 간단함이 요구되는 이유도 여기에 있다. 복잡한 해결책은 다음 풀이에 도움이 되지 못하며, 한번 만족했
다고 지속적으로 만족한다고도 보장하지 못한다.
사람은 1:1로 대체 가능한 자원이 아니라는 것은 HR담당자들은 잘 아는 사항이다. 하지만, 그 대우는 다르다. 언제든 대체
할 수 있는 것으로 보는 것도 HR담당자들의 시각이다. 높으신 분들도 마찬가지다. 자신의 관리대상인 사람들에 대해서 양
치기 처럼 되려고 노력한다. 자신의 방향과 다르다고 생각되는 사람들에게는 불익을 주지만, 자신의 명령을 잘 따르고 듣
기좋은 말을 하는 사람들에게는 당근을 듬뿍준다. 하지만, 개발자들은 양이 아니며, 세상은 목장처럼 좁은 곳이 아니다. 일
을 잘하고 영리한 사람일수록 떠나는데 주저함이 없다. 일을 충분히 찾을 능력이 되는 사람들은 자신의 한계로 특정짓지
않는다. 그리고, 그런 사람들은 "인정"받는 상사 밑에서 일하고자하지, 꼬투리 잡는 상사와는 함께하지 않는다.
19 · [ 소프트웨어 개발자 이야기 ]

20. 과제를 관리하는 것은 과제에 필요한 기술을 관리하는 것이 아니라, 그것을 담당한 사람을 관리하는 것이다. 과제 관리자
는 기술에 대해서 최고의 역량을 가져야하는 것이 아니라, 실무를 담당한 개발자들이 최대한 자신의 역량을 발휘하고, 키
워나갈 수 있도록 만들어주는 것이다. 따라서, 관리자가 해야할 일은 개발자들이 무엇을 원하는지를 과제의 목표와 일치시
켜나가는 것이어야 한다. 개발자들 역시 주는 것만 받아먹어야 한다는 생각을 버리고, 과제를 성공시키기 위해서 필요한
활동들을 적극적으로 추진해야 한다. 개발자는 좋은 방법이 무엇인지 이미 알고 있다. 스스로 알고 있는 그런 것들을 공식
적으로 할 수 있도록 만들어주는 것이 관리자의 몫이다. 요구사항 정리 및 리뷰, 설계 및 리뷰, 코딩 및 단위테스트와 리뷰,
자동화된 테스트의 확보 등등, 당연히 필요한 일을 당연히 할 수 있도록 만들어 주어야 한다.
과제의 일정계획을 아무리 자세히 세우더라도 일정을 맞추는 것은 거의 불가능하다. 물론, 가능한 방법도 있다. 하지만, 대
부분의 경우 불가능한 방법만을 선호한다. 이상한 일이지만 사실 과제의 시작을 그렇게 불가능한 일정과 틀을 만들어놓고
하는 경우가 많다. 예륻 들어, 필요한 시간이 1년이라고 이야기 했지만, 6개월내로 마치라는 지시를 받는 경우도 있다. 이
런 지시를 받았을 때 거부할 수 있다고 느낀다면, 정말 탁월한 역량을 가진 사람일 것이다. 기술적으로도 배포로도 밀리지
않는 사람일 것이다. 대부분의 사람들은 불만을 이야기 하지만, 결국 받아들이고 만다. 문제는 여기서 끝나는 것이 아니다.
지시를 한 사람은 나중에 그렇게 지시했다는 것을 잊어버리고, 왜 기간을 맞추지 못했는냐만 물을 것이다. 실패한 과제는
실패로 시작하는 과제들이다. 성공한 과제는 실무를 하는 사람들의 의견이 존중되는 것으로 시작된다.
팀워크는 일을 신속하게 진행하는데 중요한 역할을 한다. 이런 이야기도 많이 듣기는 하겠지만, 사실 팀워크를 키우는데는
오랜 시간이 걸린다. 가장 간단한 방법은 밥을 같이 먹는 것이다. 특정한 날을 잡아서 어디를 가서 함께하는 것도 좋지만,
매일 같이 식사를 하는 것이 가장 효과적이다. 우리는 밥을 먹을 때 밥만 먹지는 않는다. 물론, 대화를 오래동안하지도 않
지만, 그래도 이런 저런 이야기를 하면서 밥을 먹는다. 이런 이야기들 속에 개인에 대한 것들도 있고, 생각이나 유머 등등
작은 공유할 것들이 생겨나게 된다. 우리는 사람을 이해하기 위해서 많은 같이하는 시간의 중요함은 이미 알고 있다. 따라
서, 팀워크를 만들기 위해서는 작은 시간이지만, 함께 무엇을 같이한다는 느낌을 꾸준히 늘려야 한다. 식사는 비록 짧은 시
간이지만, 매일 매일 반복할 수 있는 중요한 쉼표다. 같이 함을 즐길 수 있어야 일도 잘된다.
20 · [ 소프트웨어 개발자 이야기 ]

21. 사람은 대체가 불가능하며, 키우는데도, 익숙해 지는데도 오랜 시간이 걸린다. 만약 새로운 사람으로 대체하고자 한다면,
그런 시간에 투자되었던 비용을 다시 반복해서 투자해야 한다. 그리고, 상당한 시간이 걸려야지만, 원래 있던 사람이 차지
했던 가치부분을 조금이라도 대체할 수 있을 것이다. 따라서, 돈과 시간, 그리고 기회의 손실을 온전히 이겨내야만 새로운
사람으로 갈아탈 수 있다. 그렇다고, 팀을 해치는 사람을 끌어안고 있으라는 것은 아니다. 그 사람을 끌어안고 있는 비용이
대체하는 비용보다 비싸다면, 당연히 같이할 필요는 없다. 팀원들이 한 사람때문에 힘들어 한다면, 그 한 사람을 버리는 것
이 다른 팀원들이 제대로 일을 할 수 있는 분위기로 만들어줄 것이다. 하지만, 팀이 전체적인 성과가 낮다면, 팀원을 문제
시 할 것이 아니라, 그 팀의 관리자를 교체해야 한다. 팀원들을 제대로 이끌지 못한 책임이 있기 떄문이다. 누군가를 교체
해야 한다면, 그 원인이 어디에 있었는지부터 따져물어야 할 것이다.
- 비난과 비판을 혼동하지 말아야 하며, 충고와 침묵은 지켜야할 선을 만들어줄 것이다.-
21 · [ 소프트웨어 개발자 이야기 ]

22. 2016/03/31 08:44 http://blog.naver.com/knix008/220670156893
[ 영웅본색 ][ 영웅본색 ]
낙서장낙서장
오래전에 봤던 홍콩르와르 물인 "영웅본색"이라는 영화가 있다. 출연했던 주인공들이 그 영화 한 편으로 대단한 인기스타
가 되었고, 그 후속으로도 비슷한 영화들이 이어졌었다. 하지만, 그 영화 덕분인지 홍콩 영화는 그 후로 대부분 잊혀진 기
억이 되어버리고 말았다. 영웅은 총을 맞아도 한 방에 죽는 경우는 거의 없다. 그리고, 죽을 때 조차도 멋을 잊지 않았다.
물론, 그게 그 영화의 핵심은 아니다. 배신과 복수, 형제같은 우정 등등 다양한 부분이 볼만한 작품이었다. 소프트웨어 개
발에도 영웅들이 있다. 영화처럼 화려하지는 않지만, 나름 팀에서는 소위말하는 "슈퍼급 인력"들이다. 영화처럼 우정은 없
지만, 끈끈한 팀워크로 맺어진 관계일 수도 있고, 과제의 실패가 죽음으로 연결되지는 않지만, 팀의 해체로 이어질 수는 있
다. 영웅은 영웅이 되기 위해서 태어난 것이 아니라, 영웅이 필요했기에 생겨났을 뿐이다. 그들 역시 미래에 대한 불안감을
잠재울 수 있는 특별한 역량을 가진 것은 아니기 때문이다.
영웅이 되고자 하는 것 보다는 팀원이 되어야 한다. 특출나게 보이는 능력들은 자신을 돋보이게 사용할 것이 아니라, 남을
돕는데 써야 한다. 사실 특별하게 보이는 팀원들은 다루기가 힘든다. 평범하지만 꾸준한 사람을 찾는 것도 아마 이런 이유
때문일 것이다. 그리고, 그런 평범한 사람들이 과제를 성공으로 이끄는 "진정한 영웅"일 것이다. 소프트웨어 개발과제는
갑작스럽게 잘되거나 안되는 일이 발생하면, 이미 제대로 관리되고 있지 못한 상태일 것임이 분명하다. 꾸준함은 이런 것
들을 미리 대응할 수 있는 시간을 주기에, 영웅이 필요한 것이 아니라 영웅처럼 행동하는 다수의 팀원이 필요할 뿐이다. 그
리고, 그들은 스스로가 영웅인지도 모르는 경우가 많다. 단순히 자신이 해야할 일을 정확히 스스로 판단해서 할 뿐이다. 하
지만, 그 평범하게 해야할 일을 하는 것 자체가 사실은 남들이 하지 않는 것일지도 모른다. 당연하게 받아들이면서 묵묵히
하는 것이 정말 해야할 일일지도 모른다.
단순하지만 반복적으로 꾸준하게 조금씩하는 것이 소프트웨어 개발이다. 반복된 연습은 무의식적이 반응을 만들듯이, 반
복적인 개발(물론,같은 내용을 개발하는 것이 아니라, 동일한 개발 방법을 반복하는 것)은 습관처럼 행위를 만들어낸다.
특별해 보이는 행동이 아니라, 당연한 듯이 받아들이도록 만든다. 작은 변화에 대해서도 꾸준함을 유지하는 것은 힘든 일
이다. 누구나 더 앞서 나가고 싶어하는 욕구를 가지고 있다. 하지만, 그것을 꾸준히 지탱하는 것이 중요하다. 즉, 급하게 서
두르지 않고, 하나 하나 차분하게 점검해 나가는 것이다. 작은 코드의 변화에도 검증할 수 있는 도구룰 만들고, 그것을 이
용해서 지속적으로 품질을 확인해 나가는 것이 습관화 되어야 한다. 코딩에 열중한 나머지 검증을 게을리한다면, 그 변화
의 누적에 의해서 발생되는 모든 버그는, 어떤 변경에 원인이 있는지 찾아내기가 어렵다. 따라서, 변경의 양을 최소화 시키
면서, 변경된 범위에 대해서 꾸준히 검증작업을 반복적으로 해야하는 것이다.
22 · [ 소프트웨어 개발자 이야기 ]

23. 변경의 폭은 하나의 함수(혹은, 메서드:Method)이상이 되어서는 안될 것이다. 즉, 그 정도의 단위 변경이 발생하면 검증
을 할 수 있는 방법이 필요하다. 한 라인의 변경이 발생했을 때는 영향을 미치는 함수내로 범위가 좁혀지지만, 한 함수의
변경(추가)이 발생할 경우에는, 그것을 사용하는 것과 같이 다뤄져야 한다. 모듈을 개발할 경우에는 단위 테스트를 기본으
로 가져가야 하고, 모듈 내부의 함수들의 연결에 대해서는 통합 테스트를 가져가는 것이 좋을 것이다. 모듈 범위를 벗어나
는 경우에는 기능 단위의 테스트가 필요하다. 따라서, 테스트는 변화의 범위에 맞게 어떻게 가져갈 것인가를 정해야 한다.
개발자 본인이 해야할 수준의 테스트라면, 단위 테스트와 통합 테스트 수준이 될 것이다. 이런 변경들이 꾸준히 쌓여야만
소프트웨어가 만들어진다. 각각의 변경에 대해서 안전함을 보장해야지만, 버그의 누적이 일어나지 않는다. 버그가 곱셈처
럼 기하급수적으로 늘어나는 경우는, 작은 단위의 변경이 누적된 결과다. 버그를 산술적인 덧셈 정도로만 유지할 수 있다
면, 과제의 지연은 크지 않을 것이고, 예측 범위에 들어올 가능성이 높다.
영웅적인 행동보다는 규칙과 합의에 따른 평범한 일상이 더 좋다. 영웅적인 행동으로 성공했다고 이야기하는 소프트웨어
개발과제들은 그 이후에 발생한 개발자들의 이탈이나, 혹은 유지보수 비용에 대해서는 별로 이야기를 하지 않는다. 한참
치켜세우다가도 정작 힘든 순간이 닦치면 다른 사람의 탓만한다. 소프트웨어 과제는 출시와 더불어 "유지보수"라는 것으
로 접어들게 되며, 그것에 들어가는 비용과 시간이 개발에 들어가는 비용과 시간보다 더 많다. 따라서, 영웅적으로 한번 잘
했다고 끝난는 일이 아니다. 좋은 팀원을 고르는 기준 중에 탁월한 능력도 중요하지만, 남들과의 소통 및 자신을 희생하려
는 태도도 중요하다. 그리고, 꾸준함은 항상 기본이 되어야 한다. 감정의 기복이 심하거나, 출퇴근 시간이 일정하지 않은
경우는 일단 다시 한번 고려해 보아야 한다. 습관처럼 행동하는 사람들은 자신의 에너지를 낭비하지 않고 필요한 곳에만
집중한다. 그들의 삶은 단조롭게 보일지는 몰라도, 조금씩 탄탄하게 쌓아 올라간 성은 절대 쉽게 무너지는 법이 없다.
영웅은 필요에 의해서 만들어지지만, 그런 필요가 없는 것이 오히려 더 안정적이다. 영웅은 평범한 사람들을 지키는 모습
으로 그려지지만, 그런 영웅의 이미지를 만들어내는 것은 힘이 있는 사람들이다. 그리고, 그런 사람들이 마치 안정과 평화
23 · [ 소프트웨어 개발자 이야기 ]

24. 를 가져오는 것 처럼 보여주지만, 실제로는 평범한 개인들에 의해서 앞으로 나아간다. 우리가 필요한 것은 힘있는 한 사람
이 아니라, 그 힘을 나눠가진 개인들이다. 소프트웨어 개발에서의 영웅은 야근이나 특근의 상징이 아니며, 열심히 하면 무
엇이든 할 수 있다는 굳은 신념도 아니다. 열심히하면 계속 열심히만 해야할 뿐이다. 습관화되면 열심히는 자취를 감춘다.
습관화된 "영리한" 개발자가 더 필요하다. 만들어진 영웅은 잠시 반짝일 뿐이지만, 역량이 커진 개발자들의 그룹은 지속성
을 가진다. 영화속의 영웅들은 화려하게 자신을 꾸밀지는 몰라도, 정말 중요한 것은 그런 화려함이 아니라 스스로를 낮추
는 "진정한 개발자"들이다. 해야할 일을 제때하고 코드의 품질에 대해서 항상 고민하는 모습이 화려함에 묻혀있을지라도,
그것이 소프트웨어 개발자의 진정한 모습이며, 그런 사람들이 결과적으로 성공적인 제품을 만들어낸다.
- 자신을 낮추고, 어려운 일을 습관처럼 지속하는 것이 성공적인 개발자의 모습이다.-
24 · [ 소프트웨어 개발자 이야기 ]

25. 2016/03/30 13:25 http://blog.naver.com/knix008/220669413913
[ 책을 써보자. ][ 책을 써보자. ]
낙서장낙서장
글은 사람보다 더 오래 세상에 남을 가능성이 높다. 1,000전에 만들어진 책도 아직까지 존재하고 있는 것을 보면, 세상에
남길 수 있는 가치 중에서 책이 차지하는 비중은 정말 크다. 인류가 존속할 수 이유도 지식과 경험의 전수 방법을 찾은데
기인한댜면, 책을 쓰는 일은 미래를 위해서도 좋은 선택이 될 수 있을 것이다. 물론, 좋은 책이 그렇다는 말이고, 그렇지 못
한 책들도 많은 것이 사실이다. 돈과 시간을 낭비시키는 것과 더불어, 가치까지 낮아지게 만들기도 한다. 따라서, 좋은 책
을 쓸 수 있도록 노려해야 한다. 좋은 책이란 결국 남을 더 가치있게 만드는데 도움이 되는 책이다. 그것으로 인해서 얻을
수 있는 댓가는 "이름"이라는 것이 가장 큰 부분이지만, 개인적으로는 "만족감"일 것이다. 이름은 다른 일을 하는데 도움
을 받을 수 있는 부분이며, 만족감은 그 일을 더 열심히 하도록 용기를 북돋아주기 때문이다.
매일 매일 글쓰기를 해야한다. 처음 글을 쓰기 위해서 필요한 것은 단지 시간과 쓸수 있는 공간이다. 지식은 그렇게 중요하
지 않다. 문제는 쓰기에 대한 두려움과 자신의 부족함에 대한 지나친 염려다. 글을 쓴다고해서 모든 사람들이 그 글을 보는
것도 아니며, 본 사람중에서 극히 일부만 자신의 의견을 이야기 할 뿐이다. 따라서, 대부분의 사람은 무슨 글이 올라왔는지
도 별로 관심을 가지지 않는다. 그냥 써도 상관없다는 말이다. 지식이 부족하다는 것을 알게되는 것은 좋은 경험이다. 최소
한 무엇을 해야할지를 알게되기 때문이다. 무엇이 부족하다고 생각하는 사람은 그것을 위해서 더 많은 노력을 하기 마련이
다. 무엇이 부족한지 모르는 상태보다는 무엇인가를 추구하고 있는 상태고 더 바람직하다. 물론, 어떤 방향으로 가야할지,
어떻게 가야할지는 도움을 얻어야 할 부분이지만, 일단은 글을 쓰기 위한 지식은 자신의 현재로부터 시작은 할 수 있다. 나
중에 필요한 부분을 보충해서 다시 고치면 된다. 처음부터 완벽할 필요는 없다.
책은 출판을 해야지만 의미를 가지는 것은 아니다. 요즘은 좋은 편집기와 프린터들이 집에 하나씩은 다 있다(없다면, 잉크
젯이나 저가 레이저 프린터라도 사라. 아이 때문에 필요한 때가 있다.). 편집기로 대략적인 내용을 만들고, 그것을 집에서
출력해서 가지고만 있어도 왠지 뿌듯할 것이다. 옆에 있는 사람들에게 전자책으로 공짜로 나누어줘도 된다. 왠만한 사람들
은 PDF나 EPUB로 만들어진 책은 다 읽어볼 수 있는 수준은 된다(나이드신 컴퓨터가 나오기 전의 세대는 제외하고). 자신
이 만드 책은 다시 읽었을 때 자신이 만든 것 처럼 보이지 않을 것이다. 이미 자신으로부터 분리된 나름의 생명력(혹은, 전
파력)을 가지고 있기 때문이다. 책은 나를 위해서도 그리고, 남을 위해서도 읽혀질 목적으로 만들어지며, 그 목적에 충분히
부합할 수 있다면 어떤 매체를 이용해도 상관없다. 자신의 경험과 솔직함을 남들과 나눌 수 있다면, 그것 역시 조금이라도
사회적인 경험의 축적에 도움을 주는 것이다. 경험하지 못한 사람들에게는 간접적인 경험을, 그리고, 이제막 시작한 사람
들에게는 좋은 가이드 역할을 해줄 수 있을 것이다.
25 · [ 소프트웨어 개발자 이야기 ]

26. 블로그를 유지하고 규칙적으로 글을 쓰는 것이 책을 만들 수 있는 좋은 방법이다. 에전처럼 혼자서 집에서 쓰는둥 마는둥
해서는 언제 완성될지 알 수 없다. 공개된 자리에서 글을 쓰면 좀더 객관화되고 정리된 글을 쓸 수 있다. 정기적으로 일주
일에 3편 이상의 글을 적게다고 하고, 한 편당 A4로 12 Point 2페이지 분량을 쓴다면, 일년이면 150편의 글을 완성할 수
있다. 일반적인 책의 폰트 크기가 얼마나 되는지는 알지 못하지만, 그 정도면 300페이지는 채울 수 있는 분량이 될 것이
다. 규칙적으로 쓰지 않는다면, 1년이 지나도 별로 차이가 나지 않을 것이다. 물론, 규칙을 정하면 쓰는 내용이 부실할 수
있다. 하지만, 그 부실함은 나중에 채워줄 수 있는 시간을 다시 가져도 된다. 한번에 모든 것을 하려고만 생각하지 않는다
면, 얼마든지 가능한 일이다. 블로그는 대화를 나눌 수 있는 공간이며, 그 대화의 내용을 기초로 해서 다시 글을 바꿀 수도
있다. 남의 의견을 공짜로 특별히 시간을 내지 않아도 들을 수 있다면, 자신의 글을 다듬을 수 있는 기회를 공짜로 얻는 것
이다(그렇다고 적극적으로 블로그에 댓글을 다는 사람은 많이 없지만).
출판은 어렵게 생각하지 말자. 페이스 북과 같은 곳에 책에 관련된 페이지를 만들고, 그것에서 공짜로 배포해도 된다. 자신
이 책을 쓰는 동안 들어간 노력에 대한 보상이 반드시 금전적일 필요는 없다. 우린 생각보다 글의 힘이 강한 시대를 살고
있으며, 같은 분야에서 일하는 사람들간에는 이른바 "유명세"를 하고 있는 사람들이 있다. 서로간에 직접 만난적은 없지
만, 그런 사람들 사이에는 항상 회자되고 있는 사람이 있다. 좋은 글을 쓰는 사람들은 그들 사이에서도 유명할 것이고, 글
을 읽고 직접 연락을 취하는 사람들도 있다. 글은 부가적인 활동에 대한 시작일 뿐이지, 글이 최종 목적은 아니다. 물론, 글
자체에서 느끼는 개인적인 만족감은 이미 충분히 있다는 가정하에 그렇게 말할 수 있다. 누군가 당신을 채용하기를 원하는
사람이 있다면, 블로그의 위치를 알려줄 수도 있고, 전자문서로 만들어진 책을 다운로드 받아보도록 할 수도 있다. 누군가
당신에게 도움을 청하는 사람이 있다면 도움을 줄 수도 있으며, 그것이 당신의 다음번 직업이 될 수도 있다. 좋아하는 것을
직업으로 가질수 있는 기회가 생긴다는 것이다. 아무런 준비를 하지 않는다면, 남이 원하는데로 인생을 맞춰갈 수 밖에 없
다.
글의 목적은 결국 남들에게 도움이되는 가치를 문자로 전달하는데 있다. 소설을 쓰는 것도 그것을 읽는 사람들에게 삶을
바라보는 새로운 자세와 작가가 바라보는 세계관을 전달해 준다. 메뉴얼을 만드는 것은 제품을 손쉽게 사용할 수 있도록
만들어주는 것이며, 지식 정보를 전달하는 책은 전달되는 지식을 쉽게 이해시키기 위함이다. 따라서, 모든 글의 목적은 남
26 · [ 소프트웨어 개발자 이야기 ]

27. 들에게 무엇인가를 전달하기 위한 것이며, 그것으로 인해서 얻는 이익은 전달이 완료된 후에 발생하게 된다. 즉, 변화된 세
계관과 행동으로 표현되어 나타나며, 결과적으로 동시대를 살아가는, 혹은 미래에 있을 사람들의 행동에 영향을 주게된다.
사회에서 용인되는 긍정적인 영향이라면 오래동안 유지될 것이며, 부정적이라고 해도 시대의 가치 흐름에 따라 새로운 해
석으로 받아들여질 수 있다. 가장 중요한 것은 글쓰는 사람 스스로가 느끼는 "자기 만족감"이다. 스스로에게 만족할 수 있
다면, 그것이 어떤 해석으로 남들에게 받아들여지건 상관없다. 물론, 비판은 있겠지만, 그렇다고 글쓰기가 멈춰지는 것은
아닐 것이다. 글이 후회로 남는 것은 그 글쓰기에 자신의 의도를 정확히 전달시키기 못했다는 것이 될 수 있겠지만, 그렇다
고 완전히 실패한 것은 아니다. 우리에게 다음이라는 말과 함께 미래를 기약할 수 있기 때문이다.
- 글도 많이 쓰는 사람이 결국 잘 쓰게 된다.-
27 · [ 소프트웨어 개발자 이야기 ]

28. 2016/03/29 09:45 http://blog.naver.com/knix008/220668212781
[ 코딩 룰에 대한 불편함 ][ 코딩 룰에 대한 불편함 ]
낙서장낙서장
코딩 룰을 만드는 것은 쉬운 일일 수도 있고, 모두가 불편할 수도 있다. 사실, 코딩 룰이란 크게 문제가 될만한 것은 아니
다. 문제는 사람들이 저마다 생각하는 바가 다르고, 경험과 지식이 차이가 난다는 점이다. 이를 통합하는 것은 쉬운 일은
아니며, 논의를 거듭하다보면 이상한 방향으로 흐를 수도 있다. 또한, 코딩 룰은 만들고 나면 그것이 제대로 지켜지는지도
검사해야 한다. 많은 경우 이런 것들은 툴(Tool)에 의존하게 되는데, 논의된 코딩 룰이 툴에서 지원하지 못하는 것이라면,
제대로 지켜지는지를 확인하기는 정말 어렵다. 따라서, 가장 좋은 방법은 이미 툴에서 지원하는 코딩 표준을 이용해서
On/Off와 같이 검사 옵션을 끄고켜는 방법으로 만드는 것이다. 대부분의 툴들은 업게에서 지켜야할 코딩 룰 표준을 지원
하고 있으며, 그런 것들을 확인할 것인가를 설정할 수 있도록 하고 있다. 따라서, 검사할 수 있는 방법이 있고, 반드시 지원
해야 하는 경우에만 팀의 코딩 룰로 명시하는 것이 논란을 최소화 하는 방향이다.
코딩 룰을 만들자고 하면 꼭 1~2명은 반대하는 사람들이 있다. 물론, 그들은 대부분 뛰어난 역량을 가지고 있는 사람들일
경우가 많으며, 경험치도 높은 수준일 것이다. 그리고, "내가 해봤는데, 그런거 해봐야 별로 도움이 못돼"와 같이 이야기
할지도 모른다. 맞는 말이다. 그런 거 해봐야 제대로 도움을 받았다고 생각되는 것들은 그렇게 많지 않을지도 모른다. 하지
만, 그렇게하지 않았을 때 발생했을지도 모르는 문제를 사전에 제거했다는 점에서는 옳은 이야기는 아니다. 그리고, 아마
도 그들은 자신들만의 경험에서 만들어진 코딩 룰을 암묵적으로 사용하고 있을지도 모른다. 우리가 해야 할 일은 그런 것
들을 암묵적으로 만들어서 가지고 있을 것이 아니라, 드러내도록 하는 것이다. 오랜 시간동안 같이 일해온 팀의 경우에는
모든 개발자들이 공유하는 가치를 가지고 있으며, 코딩 룰도 그 일부로 존재한다. 하지만, 팀의 유동성이 많은 큰 회사인
경우에는 그런 경험들의 공유가 느리기에, 적절한 도구와 방법을 이용해서 일치시키는 것이 필요하다. 반대는 의미있지만,
그렇다고 코딩 룰이 없는 것이 올바른 상태는 아니다.
코딩 룰은 불편하다고 생각하는 사람들도, 정작 자신의 코드에서 문제 가능성을 발견하는 것에 대해서는 감사하게 생각한
다. 물론, 처음에는 반감을 가지고 대할 것이다. 정적분석 도구로 코드를 처음 분석했을 때 부닫히는 문제는, 문제점
(Defect)으로 밝혀진 부분에 대해서 실제로는 문제가 안된다는 대답이다. 그런 대답과 한참동안 논쟁을 해야 겨우 조금 변
화된다. 그리고, 결정적인 부분은 나중에 그것이 실제로 문제가 되어 큰 문제로 발전한 이후에는 완전히 정적분석 도구를
믿기 시작한다는 것이다. 비록 시간은 걸리더라도 사람들에게는 문제에 대한 인식이 결여되어 있지는 않다. 개발자들은 자
신이 인식한 문제에 대해서는 없애려는 태도를 보인다는 것이 그나마도 다행이다. 코딩 룰도 마찬가지다. 한번에 모든 것
을 들이밀어 수정하라고 한다면 반발력이 생각보다 심할 것이다. 가장 필요한 부분은 "감시하고 교정하는 수단"으로서 코
딩 룰을 사용해서는 안된다는 것이다. 스스로 고쳐나갈 수 있는 충분한 역량이 있는 개발자들을 그렇게 대하는 것은 시간
과 비용의 낭비다. 가이드를 제공하고 꾸준히 개선할 수 있도록 예제를 제공하는 편이 오히려 그들을 안심시킬 수 있을 것
이다.
28 · [ 소프트웨어 개발자 이야기 ]

29. 코딩 룰은 전체 팀원이(혹은, 전체 회사의 구성원이) 따라야 할 코딩의 기준이다. 즉, 한 사람 한 사람이 전부 관련된 활동
이라는 점이다. 팀에서 유지하는 코딩 룰이 전체 회사에서 정한 코딩 룰과 다를 경우, 당연히 회사의 기준이 우선이다. 물
론, 이런 것들로 인해서 개발자들은 불편함을 겪을지도 모른다. 자신이 지금까지 해오던 관행을 버려야 한다는 점에서 불
편함을 겪는 것은 당연한 일일 것이다. 하지만, 그 불편함도 이내 없어지기 마련이다. 어차피 기존의 관행또한 그전에는 불
편함의 일부였을 것이기 때문이다. 따라서, 새로운 코딩 룰에 대해 거부감을 가질 필요는 없다. 사람이 변하고 조직이 바뀌
면 그에 맞는 규칙이나 규정 또한 바뀐다. 포장이 바뀐다고 내용까지 전부 바뀌는 것은 아니다. 코딩에서의 창의성은 코딩
룰과는 관련이 없는 것이다. 문제를 해결하는 방법은 고유한 것이며, 그 해결 방법을 표현하는 방법을 일반화 한다고 해서,
해결 방법의 고유함 마져 없어지는 것은 아니다. 불편하다고 해야할 일을 하지 않는 것이 오히려 이상한 것이다. 각종 표준
에서 이야기 하고 있는 모든 규칙을 다 적용할 필요는 없지만, 그래도 나름대로 많은 전문가 수준의 사람들이 검토하고 만
들어진 것들이다. 따라서, 그것을 마다할 이유도 없는 것이다.
코딩 룰이 코딩 룰이 아닌 경우도 있다. 간혹 팀에서 가지고 있는 코딩 룰이 일반적으로 코드에서 존재해서는 안되는 코딩
룰을 가지고 있는 경우도 있다. 예를 들어, "모든 객체들은 싱글톤(Singleton)으로 만들어져야 한다. 자주 사용되는 함수
들은 모아서 하나의 모듈로 만들어야 한다. STL(Standard Template Library)는 성능이 좋지 않으므로 사용하지 않는
다."와 같은 것들도 있었다. 이런 것들이 과연 코딩 룰일까? 물론, 그렇다고 생각할 수도 있겠다. 하지만, 싱글톤이 전역객
체를 만드는 것은 좋지만, 전역 변수를 대용할 목적으로 사용하는 것은 옳지 않다. 자주 사용하는 함수들을 다 모아서 관리
하는 것은 얼핏 의도는 좋아보이지만, 지나치게 큰 모듈을 만들고, 다양한 역할과 책임을 가지도록 만들기에 프로그램을
큰 덩어리로 모아버리는 효과를 낳는다. STL은 이미 검증되어 사용되는 표준 C라이브러리와 마찬가지인데 그것이 성능이
좋지 않다는 이유로 직접 구현할 필요가 있을까? 다양한 상황에 대한 에러처리 및 메모리 누수(Leak)와 같은 문제를 해결
한 것을 굳이 새로 구현할 필요가 있을까? 이런 것들은 상식 수준에서 이야기 해야할 것들이다.
29 · [ 소프트웨어 개발자 이야기 ]

30. 코딩 룰이 불편하게 다가오는 이유는 그것을 다른 목적으로 사용하려는 의도를 가지고 있다고 보기떄문이다. 즉, 개선보다
는 감시와 통제로 생각하고, 그것을 따르지 않을 경우에 발생하는 불익을 받을 수 있다는 생각 때문이다. 코딩 룰은 개선을
위한 도구일 뿐이다. 도구를 사용하는 것이 인간인데, 그것을 마다할 필요는 없다. 우리가 더 나은 경험을 할 수 있고, 불필
요한 노력의 낭비를 줄일 수 있다면, 도구는 편의를 제공하는 것이지, 나를 가두는 철창이 아니다. 불편함을 느끼는 이유는
그것이 자신에게 익숙하지 않아서이지, 특별한 이유가 있는 것도 아닐 것이다. 불편함은 자주 반복적으로 할 때 금방 익숙
함으로 바뀐다. 자주하지 않아서 불편할 따름이지 자주한다면 습관으로 바뀐다. 모든 것이 시작에 가장 많이 힘이 들지만,
학습하고 난 이후에는 의식하지 않아도 자연스럽게 행동으로 전환된다. 자동차 운전이 초반에는 끊임없는 주의를 요구하
지만, 익숙해지면 무의식중에 운전에 대한 모든 행동이 발현되듯이, 코딩 룰도 처음이 힘들 뿐이다. 들어가는 비용에 비해
서 얻는 효과는 미미하다고 생각할지도 모르지만 절대 그렇지 않다. 반복적으로 읽어야 하고, 많은 사람이 관련된 과제는
금방 그 비용을 넘어서는 이익을 거둘것이 분명하다. 목적이 선량해야 그 효과도 더 빨리 볼 수 있을 것이라는 것은 당연한
생각일 것이다.
- 당신의 무지함을 코딩 룰로 만들지 말라. 코딩 룰로 자신의 무지함을 드러내도록 하라.-
30 · [ 소프트웨어 개발자 이야기 ]

31. 2016/03/28 12:00 http://blog.naver.com/knix008/220667328602
[ +Alpha의 어려움 ][ +Alpha의 어려움 ]
낙서장낙서장
무엇인가를 개발할 때 추가되는 요구사항은 과제를 망치는 요인중에 하나이다. 알게 모르게 조금씩 추가되는 요구사항들
은 과제 책임자의 입장에서는 별것 아닌 것처럼 개별적으로 과제에 더해지지만, 나중에 그것으로 인해서 변경되거나 추가
되는 코드들은 코드의 안정성에 심가한 위해를 가하는 경우가 흔하다. "+Aplha"를 넣어서 제품이 차별점을 확보하는 것
도 중요하지만, 안정적이지 못한 제품을 만드는 것 자체는 올바른 선택이 아니다. 제품은 가능한 필요한 기능만 충실히 수
행할 수 있으면 그것으로 일단은 만족해야 한다. 기능추가가 필요하다면, 주요기능이 완료된 이후에 변경에 대한 영향을
분석부터 시작해야 할 것이다. 만약, 영향도가 큰 변경이라면 신속히 처리하기 보다는 면밀한 검토와 재검토, 논의 및 합의
과정으로 이어지는 것들을 거쳐야 한다. 그냥 단순히 과제 관리자가 "OK"했다고, 실무 개발자들이 그냥 따라야 한다는 것
은, 개발자의 생각을 무시하는 일방향의 의사전달일 뿐이다. 이는 결국 낮은 품질로 이어지게 된다.
예전에 진행했던 과제 중에서 꼭 필요할까라고 생각되던 부분이 있었다. 예를 들어, 현재 만들고 있는 장비가 있는데, 그
장비에 새로운 기능을 넣기 위해서는 전체적인 구조의 변화가 따라오고, 또한 그것으로 인해 데이터의 처리에 들어가는 노
력이 배가되며, 성능이 저하될 가능성이 농후하다고 판단되었었다. 사용자가 반드시 원하는 기능이라고 했지만, 실제로 사
용하는 사람은 그 기능을 켜놓고 계속 확인할 가능성은 없어보였다. 필요할 때는 간단히 인터넷으로 장비에 접속해서 상황
을 모니터링 정도만 할 수 있으면 된다고 생각되었고, 가격이나 구현일정 및 인력 계획에도 영향을 줄 가능성이 높았다. 그
리고, 그 기능은 과제의 핵심 요인이 아니라, 나중에 추가될 수 있는 업그레이드 성격이 강했다. 하지만, 누군가의 잘 못된
판단으로 인해서, 그 기능을 넣는데 많은 노력이 결국 들어갔으며, 성능도 원하는 만큼 나오지 않게되었다.
물론, 개발자이 구현을 잘못해서 그렇다고 이야기해도 할 말은 없다. 하지만, 제품의 기능적인 측면에서 그것이 다른 모든
기능에 최우선이었는지는 생각해 보아야 한다. 만약, 최우선되는 기능이 그것이 아니었다면, 좀더 여유를 두고 생각해 볼
수 있는 가능성이 열린다. 즉, 핵심이 되는 주요기능을 일정에 맞춰서 먼저 안정적으로 개발하고, 그 후에 추가기능을 제공
할 수도 있었다고 생각된다. 한꺼번에 모든 기능을 다 제공해야 한다는 것은 개발을 난해하게 만들기 쉽다 우선 순위가 높
은 기능들을 위주로 제공할 수 있는 일정을 정하고, 그것이 도달했을 때 다른 기능들을 추가하는 마일스톤과 같은 과제의
이정표를 만드는 것이 중요했을 거라고 생각된다. 만약, 그렇게 개발에 들어갔다면, 구현에 따른 난이도나 추가 인력문제,
인터페이스의 단일화와 같은 것들을 이뤘을지도 모른다. 급한 마음에 모든 것을 한번에 해 달라고 했던 사람들은 과제의
지연과 더불어 자신의 책임을 회피하는데 급급했던 것도 사실이다.
31 · [ 소프트웨어 개발자 이야기 ]

32. 기존의 기능을 없애는 것 역시 쉬운 일은 아니다. 새로운 기능을 추가하는 것보다 더 어려울 수 있다. 만약, 현재 개발되고
있는 코드가 있다면, 기능을 빼는 것도 시간을 필요로 한다. 대부분의 경우 구현하고 있는 기능을 다시 빼기 위해서도 코드
의 수정을 동반하기 때문이다. 따라서, 기능을 넣는 것도 빼는 것도 다 쉬운 일은 아니다. 이런 점을 이해하지 못하는 사람
들은 이상하게 생각할지도 모르지만, 모든 일은 비용을 수반다고 있다는 것은 알아야 한다. 세상에 쉬운 일이란 없다는 것.
소프트웨어는 가능한 적게 코딩하는 것이 유리하다. 같은 일을 하더라도 코드가 짧은 것이 좋다. 짧은 코드와 이해가 가지
않는 코드를 만드는 것을 같은 것이라고 생각해선 안된다. 둘은 다르다. 목표는 짧고 이해가 쉬운 코드를 만드는 것이다.
필요한 코드만 제품에 있어야 하며, 미래에 사용될 가능성이 있거나, 확장성을 위해서 남겨놓은 코드들은 제거하는 것이
옳다. 기존의 기능을 제거하는 것은 구조적인 변경을 유발할 수도 있다. 물론, 확장과 삭제가 문제가 안되도록 코드를 짤
수도 있지만, 그것 자체가 너무 심한 오버헤드가 되지 않도록 적절히 타협하는 수준에서 마무리 지어야 한다.
무엇인가를 더하기 위해서는 기존의 코드가 안정적으로 동작한다는 것이 어느 정도는 보장되어야 한다. 그냥 막무가내로
코드를 우겨넣는다면, 문제는 더 심각해질 뿐이다. 제대로 동작하지 않는 코드는 길어질 수록 비용은 기하 급수적으로 증
가하기 마련이다. 따라서, 작은 부분이라도 추가하고자 한다면, 기존의 코드에 대한 한정성을 먼저 확보하는 것이 일의 순
서다. 사실 변화를 관리하는 것이 소프트웨어의 핵심적인 부분이지만, 우린 그런 것들을 학교에서는 배우지 않는다. 변화
는 복잡함의 원천이지만, 복잡함을 일으키는 원인은 의존성이란 부분이다. 즉, 변화를 의존성이 높은 방향으로 가져간다
면, 코드는 경직(Rigid)되어가며 점차 비용을 증가시키는 방향으로 흘러가게 된다. 따라서, 될 수 있으면 의존성이 최소화
되는 방향으로 코딩이 진행되어야 한다. 의존성을 완전히 제거하는 것은 사실상 불가능하다. 프로그램의 어떤 부분은 다른
부분에 의존하기 마련이다. 하지만, 억제하는 것은 가능하다. 코드를 더하더라도 의존성이 일정 수준으로 유지될 수 있는
방안을 찾는 것이 핵심인 것이다.
32 · [ 소프트웨어 개발자 이야기 ]

33. 무언가를 할 때, 추가하는 것은 쉽지만, 제거하는 것은 어려운 경우를 종종 본다. 마치 추가되었던 것들이 "반드시 지켜져
야 할 규칙"과 같은 것으로 작용하기 때문이다. 하지만, 사실 그런 것들은 별로 없다. 없앨 수 있는 것들은 최대한 없애는
것이 좋다. 요구사항을 줄이면, 코드도 당연히 줄어들 것이고, 복잡도나 관리하는데 필요한 비용도 줄어든다. 이런 비용들
이 줄어가면 당연히 과제에 참여하는 인력도 줄어들고, 기간도 줄어든다. 급하지 않은 기능을 추가하므로 해서 많은 인력
들을 유지하고, 복잡한 코드를 다루게 만드는 것은 그만큼 해야할 일과 기간, 사람 수 등을 늘리는 효과를 가진다. 따라서,
급하지 않은 일들은 가능한 억제하면서 미뤄야 한다. 우선 순위를 나열하는 것 자체를 거부하는 사람들은 모든 것이 한번
에 해결되기를 바라지만, 그런 일은 일어나지 않는다. 아니, 일어나더라도 많은 욕을 먹고 비판을 받은 후에 지연되어 발생
할 것이다. 그럴바에는 그냥 우선순위를 명시해서 중요한 것들을 먼저 개발해 나가고, 제품을 출시한 이후에 새로운 기능
을 차근차근 넣는 것이 더 바람직해 보인다.
임베디드 시스템의 경우에는 기능추가가 어려운 경우도 있다. 하지만, 그렇다고 불가능한 일은 아니다. 예를 들어, 추가 업
데이트를 착실하게 정해진 일정에 따라 제공할 수 있다면, 고객은 특별히 문제삼지 않을 것이다. 작은 칩에 내장되어 사용
되는 소프트웨어는 출시와 더불어 고정될 가능성이 있다. 물론, 그런 코드들은 변경이 거의 발생하지 않는다고 봐야한다.
따라서, 가능한 꼭 필요한 기능만 담아야 한다. 불필요한 코드는 제거되어야 하며, 복잡한 기능은 포함하지 않는 것이 좋
다. 많은 기능을 제공한다고 물건이 많이 팔리는 것도 아니다. 될 수 있으면 최적으로 원하는 것들이 무엇인지를 찾아내고,
그것만 한정해서 구현해야 한다. 누군가 "+Alpha"를 주장한다면, 그것을 통해서 얻게되는 이익이 무엇이며, 얼마가 되는
지를 명확히 물어봐야 할 것이다. 그리고, 그렇게 만드는데 필요한 비용과 그것으로 인해서 발생하는 유지보수 비용은 또
얼마나 될지 따져야 한다. 투자한 값어치도 제대로 못하는 기능들이 우리가 사용하는 대부분의 소프트웨어에 있다는 사실
은 너무나 잘 알것이다. 그것을 만드는 사람의 노력에 대한 기대되는 수익이 너무 작다면, 그것을 만들 이유는 없는 것이
다.
- "조금만 더"라는 말은 기능에 대한 것이 아니라, 품질에 대한 욕구여야 한다.-
33 · [ 소프트웨어 개발자 이야기 ]