이번엔 널리 알려져서 누구나 다 알고 있을법한 (하지만 의외로 안지키는 사람도 많은) 방법을 소개한다.
가장 많은 인자를 받는 메서드를 Master Method 로 정하고, 다른 메서드에서는 부족한 인자를 default 값으로 채워 Master Method 를 호출한다. 생성자(constructor) 구현 시에도 동일한 규칙이 적용된다.
int read(byte[] buf) { .. // tens of lines }
int read(byte[] buf, int offset, int length) { .. // tens of lines }
위에서 첫 번째 메서드는 두 번째 메서드의 특수한 형태로, offset 을 0으로, length 를 buf 의 size 로 해서 호출한 것과 완벽히 동일하게 동작한다. 따라서 첫 번빼 메서드는 아래와 같이 구현할 수 있다.
int read(byte[] buf) { return read(buf, 0, buf.size); // redirect to Master Method with appropriate parameters }
Master Method 는 코드 중복 최소화 외에도, 오버로딩된 메서드들을 가지고 있는 클래스를 상속할 때 개발자 실수를 최소화 시킬 수 있다는 장점도 있다. 예를 들어, 오버로딩된 메서드 a, b, c 를 정의하고 있는 클래스 A 가 있다. 이 때 이를 상속한 클래스 B 에서 기능을 약간 변경하고자 할 때, Master Method 가 없다면 메서드 a’, b’, c’ 를 잊지 말고 모두 정의해줘야 한다. 실수로 무엇 하나를 빼먹었다면 의도치 않은 동작을 하게될 것이고, 그 원인을 찾기는 쉽지 않을 것이다. 하지만 만약 a 가 Master Method 였다면, a’ 만 재정의하면 문제를 미연에 예방할 수 있다. 따라서 Master Method 를 정하고, 어느 메서드가 Master 인지 명시하는 것이 좋다.
또, C++ 의 경우 Google 은 default parameter 를 흉내낼 목적으로는 사용하지 말기를 권고한다[4]. 그 단점을 아래와 같이 기술하고 있으니 참조하기 바란다.
One reason to minimize function overloading is that overloading can make it hard to tell which function is being called at a particular call site. Another one is that most people are confused by the semantics of inheritance if a deriving class overrides only some of the variants of a function. Moreover, reading client code of a library may become unnecessarily hard because of all the reasons against default function parameters. If you want to overload a function, consider qualifying the name with some information about the arguments, e.g., AppendString(), AppendInt() rather than just Append().
One reason to minimize function overloading is that overloading can make it hard to tell which function is being called at a particular call site. Another one is that most people are confused by the semantics of inheritance if a deriving class overrides only some of the variants of a function. Moreover, reading client code of a library may become unnecessarily hard because of all the reasons against default function parameters.
If you want to overload a function, consider qualifying the name with some information about the arguments, e.g., AppendString(), AppendInt() rather than just Append().
계속해서 Recommended Sequence for Refactoring[1] 의 가장 첫 단계인 Remove duplications 에 적용할 수 있는 리펙토링 기법 하나를 더 소개한다. 먼저 소개한 God Method[2] 와는 얼핏 유사한 상황 같지만 분명한 차이가 있다.
Problems & Constraints
하나의 마스터 함수만 구현은 유지하고, 다른 함수들은 받은 입력의 타입만 변화시켜 마스터 메소드를 호출한다.
다음의 두 함수는 다른 입력을 받지만 목적은 같다.
toDate(long timestamp) { .. // tens of lines }
toDate(DateTime dateTime) { .. // tens of lines }
long 타입의 timestamp 를 DateTime 으로 변환시켜 (convert) Date 용 함수를 호출한다.
toDate(long timestamp) { DateTime dateTime = new DateTime(timestamp); // convert return ConvertDateTimeToServerDate(dateTime); // then, redirect // no more duplicated lines }
toDate(DateTime dateTime) // master method { .. // tens of lines (unchanged) }
지난달 포스팅한 Recommended Sequence for Refactoring[1] 의 가장 첫 단계인 Remove duplications 에 적용할 수 있는 리펙토링 기법이다.
곧 한 두개의 기법이 추가로 뒤따를 예정이다.
하나의 God Method(모든 상황에 필요한 인자의 합집합 받으며, 입력 조합에 반응하여 동작함)을 ‘내부’에 두고, 공개 메서드에서는 인자를 적절히 조합하여 이 God Method 를 호출한다.
God Method 는 하나의 기능에만 특화된 메서드에 비해 로직이 복잡하므로, 일반적인 경우에는 지양해야할 어프로치다.
‘중복량 vs. 복잡도 증가’ 를 잘 판단하여 적용 여부를 결정해야 하며, 적용하더라도 내부(private) 메서드에 한정 짓는 것이 좋다.
아래의 세 함수들은 입력 인자 중 하나만이 다르며, 그에 따라 달라지는 코드 라인수는 전체 코드 구현에서 비중이 작다. 혹은 중복 코드의 절대량이 많다.
public Object DoSomething(.. /* series of params */) { .. // tens of lines MakeSomething(.., null, null, ..); .. // tens of lines }
public Object DoSomething(Apple apple, .. /* series of params */) { .. // tens of lines MakeSomething(.., apple, null, ..); .. // tens of lines }
public Object DoSomething(Orange orange, .. /* series of params */) { .. // tens of lines MakeSomething(.., null, orange, ..); .. // tens of lines }
DoSomething 함수에 필요한 모든 인자를 받아들이니 God Method (DoAnything) 를 만들어 구현을 하나로 모은다.
private Object DoAnything(Apple apple, Orange orange, ..) // newly introduced god method { .. // tens of lines MakeSomething(.., apple, orange, ..); // bypass the given params .. // tens of lines }
public Object DoSomething(..) { // no more duplicated lines return DoAnything(null, null, ..); // invoke the god method }
public Object DoSomething(Apple apple, ..) { return DoAnything(apple, null, ..); }
public Object DoSomething(Orange orange, ..) { return DoAnything(null, orange, ..); }
그간 이 팀 저 팀에서 발간(?)한 수많은 소위 Lessons Learned 라는 것을 봐온바 있다. 과제를 진행하면서 느끼고 배운 것을 정리하여 다음 과제 진행시 참고하거나 진행중인 다른 과제에서 참고할 만한 좋은 정보들이 적혀 있다. 자신이 걸어온 길을 되돌아보는 것은 좋은 경험이고, 그 결과를 정리해 놓는 것 역시 권장할 만한 일이다.
문제는 그 시점이 항상 과제가 뿌러지는 등 완전히 종료되는 시점에 일어난다는 것이다. 많은 경우 팀 자체가 뿔뿔이 흩어지거나 축소된다. 다음에 진행할 과제도 이전 과제와 성격이 달라지기 쉽다. 얻은 것이 있어도 그것을 적용해볼 상황이 못되는 것이다.
과연 이전 과제에서 깨우친 것들이 새로운 과제 새로운 팀에서 제대로 먹혀들 수 있을까? 시행착오를 거쳐보지 않은 새 팀 멤버들이 가슴 깊이 공감하고 따라줄 것인가? 배경이 다른 사람들에게도 똑같은 처방이 여전히 유효할까? 내가 얻은 결론은 정말 더 나은 개선책인가? 아니면 단지 ‘다음엔 이렇게 해봐야지’ 정도인가? 검증되지 않았고 경험해보지도 못한 방법을 새 팀 새 과제에서 시험해볼 용기는 있는가?
위와 같은 고민들도 어느 정도 영향력이 있는 윗사람들에게 해당하는 것이지, 중간 이하의 힘없는 관리자나 실무자들은 새로운 리더가 시키는데로 그냥 따를 수 밖에 없는 것이 또 현실이다.
결국 이런 식의 Lessons Learned 는 읽을 거리나 유언장 이상의 실질적 가치를 갖지 못한다.
Retrospective 는 Lessons Learned 의 Agile 식 표현 정도로 생각하면 좋을 것이다. 하지만 많은 차이를 안고 있음을 잊어서는 안된다. Agile 이 강조하는 iterative, responsive, incremental 같은 속성을 Lessons Learned 에 부여해보자. 짧은 간격으로 주기적으로 회고하며(iterative), 현 시점에 필요한 이슈에 대한 개선안 만들어 다음 개발 주기에 적용해보아 좋은 것을 취하고 잘못된 것은 버리거나 다른 안을 찾아본다(responsive). 팀은 과제가 진행될 수록 조금씩 조금씩 더 나은 방향으로 발전해 간다(incremental).
이미 끝나버린 과거에 대한 무책임한 회상록이 아닌, 지금 살아서 꿈틀대는 과제에 대한 진중한 고민을 경험해볼 수 있다. 바로 그 시점에 팀원들 스스로가 개선이 필요하다고 느끼는 이슈들이 다뤄지고 합의된 개선책을 시행한다는 점에서 참여율이 높아지고, 높은 성공 확률은 덤으로 얻게된다. 혹 실패한다면 바로 다음 회고 때 그 원인과 또 다른 개선안을 찾게될 것이다. 시행착오를 통해 더 많은 경험을 얻게되고, 미처 고려하지 못했던 요소들이 있음을 깨닫게 된다. 넓고 세심해진 시야는 다른 문제에 직면했을 때도 좀 더 빠르게 더 효과적인 개선안을 찾게 도와준다. 반면 Lessons Learned 방식에서는 실패한 처음 안만이 남겨질 가능성이 농후하다. 회고가 거듭될 수록 팀의 생산성이 향상됨을 느낄 수 있을 것이다.
다 좋고 완벽해 보이는 회고도 무턱대고 적용하려 하면 말처럼 쉽지 않음을 깨닫게 된다. 내가 지금까지 발견한 중요 요인은 3 가지 이다.
첫째, 일정에 쫓겨서 회고에 할애할 시간적 여유가 없다.
이런 답변을 많이 들었는데, 시간적 여유가 없는 것이 아니라 회고의 효과에 대한 믿음이 부족하거나 새로운 것을 시도하는 것을 꺼리는 보수적 마인드의 팀일 가능성이 높다. 이런 경우엔 분위기 조성을 위한 물밑 작업부터 시작해야 한다. 말이 통하고 깨어있는 사람들이라면 직접적인 대화로 돌파할 수 있겠다. 뜻이 맞는 팀원이 소수라도 존재한다면 솔선수범해서 더 나아지는 모습을 직접 보여줄 수도 있을 것이다. 상황이 다양한 만큼 방법도 다양할 터이니 숙고해서 도전해보자. 단, 상대를 공격하는 것은 확실한 실패 방법이니 절대 피하길 바란다.
참고로 회고에 필요한 시간은 보통 2~4주에 1시간 정도면 충분하다. 물론 처음 시작할 때는 좀 더 많은 시간이 필요할 것이지만 두세번만 해보면 익숙해지고 소요 시간도 줄어든다.
둘째, 팀원들의 참여가 저조하다.
기껏 회고를 해보자는 허락을 받았는데, 정작 모인 사람들이 꿀먹은 벙어리 마냥 침묵으로 일관한다. 회고를 처음 시도하는 조직에서는 대부분 겪게 되는 인기 코스일 것이다. 그들이 침묵하는데에는 여러 가지 이유가 있을 것이다. 무슨 얘길 하면 되는거지? 예제 같은 거 없나? 얘기한다고 정말 개선해 주나? 말 꺼내면 나보고 꺼낸 사람이 하라고 하겠지? 불평하면 괜시리 밉보일 거야.. 등등.
이런 우려를 해소하고 적극적인 참여를 유도하려면 맛을 보여줘야 한다. 사소한 것부터라도 정말 개선되는 모습을 보여주는 것이다. 첫 회의에서 아무런 아이디어가 없을 것을 대비해 문제점과 개선안까지 몇 가지를 준비해둔다. 뜻이 맞는 사람이 한 명이라도 있다면 역할극을 해보는 것도 좋다. 혼자 북치고 장구치는 것보다 훨씬 효과적으로 분위기를 이끌어 갈 수 있을 것이다. 그리고 개선안이 없더라도 불편한 사항을 자유롭게 이야기하도록 하고, 그에 대해 반박을 하거나 방어적인 모습을 보여서는 안된다. Brain storming 방식으로 문제들을 나열하고 중요도와 시급성, 파급 효과 등을 생각해 이슈를 선별해서 개선안을 모색해보자.
셋째, 팀에 부여된 권한이 너무 작다.
열심히 분위기 잡고 멋진 개선안들도 마련했다. 그런데 그 개선안들이 우리힘으로 할 수 있는 일들이 아니라면? 운영부서는 돈 들어가는 일은 절대 허락을 안해주고, 보안 부서는 개발자 편의성은 절대악으로 규정짓고, 프로세스 팀은 표준 프로세스에 어긋난 어떠한 시도도 용납하지 않고, 기획/마케팅 부서는 자신들이 바라는 모든 기능을 역시 자신들이 정한 시한까지 완수해야 한다고 못박고, 책상 앞에 앉아 있는 시간과 개발진도는 정비례한다고 철석같이 믿고 있는 임원이 군림하고 있다면?
회고는 불평불만을 토로하고 남들 뒷담화가 남무하는 장이 되던가, 소꼽장난하듯 사소한 문제들만 다뤄지는 비중없는 시간으로 전락할 것이다. 물론 작은 개선들이 차곡히 쌓여 큰 도움을 줄 수도 있을 것이고, 공동의 적을 향한 불평불만과 뒷담화는 팀원들을 단합시켜주는 효과도 있기는 하다. ^^
모든 것을 통틀어 가장 큰 장벽으로, 딱히 뾰족한 해결책도 없다. 때마침 임원 인사가 단행되어 깨어 있는 사람으로 교체되던가, 무슨 바람이 불어서 아주 권위 있는 컨설턴트의 도움을 받을 수 있다면 큰 힘이 될 것이다. 하지만 모두 다 운에 기대는 것이고.. 리더나 팀원들이 몸소 나서서 설득하고 싸우는 적극적 쟁취 방법도 물론 있다. 하지만 생태계에서 식물 급으로 취급되는 힘없는 개발팀이 얻어낼 수 있는 것은 많지 않을 것이다.
점진적 지연이란 아주 짧은 간격으로 릴리스 날짜를 조금씩 미루는 행태를 뜻한다. 일단 릴리스를 시도해보고, 안되면 조금 (보통 1~3일) 미룬 후 다시 시도한다. 역시 잘 안되면 또 다시 미룬 후 시도한다. 이렇게 릴리스가 될 때까지 무한 반복하는 릴리스 관리 방식이다.
내가 경험해본 최악의 상황은 이러했다. 원래의 릴리스 목표일은 금요일이다. 금요일이 되어서 시도를 해보았으나, 도저히 릴리스할 만큼의 품질이 나오지 않는다. 그래서 월요일로 목표를 바꾼다. 월요일에도 역시 원하는 품질에 도달하지 못했다. 다음날 다시 한 번 시도해보기로 한다. 마찬가지로 실패했다. 이와 늦은거 금요일로 다시 미룬다. 금요일도 여전히 실패.. 토요일.. 월요일.. 수요일.. 금요일.. 월요일.. 화요일.. 토요일.. ..
이런 식으로 가장 길게는 6주간 계속 릴리스만 한 경우도 있었다. 릴리스가 이렇게 한달 가량 지연되면 당연히 다음 릴리스에 일정에 지장을 주게 된다. 새로운 기능을 추가하는데 필요한 최소 시간이 있으므로 차례차례로 전체 일정이 연기된다. 하지만 다음 릴리스 시점에 와서도 크게 다르지 않다. 역시 또 몇 주의 지연이 발생한다. 그래서 ‘릴리스가 끝나면 (다음) 릴리스 일정이 바뀐다’, ‘릴리스가 되는 날이 릴리스 날이다 (역: 릴리스 날에 릴리스를 한다)’ 라는 말까지 하게 되었다.
위의 경우는 continuous integration (CI) 도 도입되지 않은 열악한 환경에서의 상황이었고(도입을 요구했지만 관심 갖는 사람이 없었음), 그 후 CI 가 도입되면서 상황은 많이 호전되었다. 하지만 여전히 제 때 릴리스 되는 경우는 전무했고.. 심한 경우 3주가 밀리기도 했다. 금요일 릴리스를 (주말을 열심히 일해서) 그 다음주 월요일 저녁에 할 수 있다면 대단히 이례적인 성공이 케이스가 될 정도였다.
Incremental Delay 가 팀 문화처럼 정착되면서 다음과 같은 부작용들이 나타나기 시작했다.
팀원들은 윗선에서 정한 릴리스 날짜(deadline)에 큰 의미를 부여하지 않게 되었다. 한 차례도 성공적으로 릴리스한 경험이 없으며, 릴리스가 연기되어도 아무 일도 발생하지 않음이 학습되었기 때문이다. 꼭 지켜져야하는 중요한 릴리스라 강조해도 마음속으론 ‘어짜피 안될걸..’이란 생각을 자연스레 하게된다.
서브팀별 개발 일정이 꼬이기 시작한다. 팀별로 이터레이션(iteration) 주어진 일의 양이나 생산성, 예측 정확성 등의 차이가 생겨 발생하는 현상으로.. 일부 팀은 일정에 맞춰 일을 끝내놓고 다음 릴리스를 위해 할 일을 준비하고 있다. 하지만 곧 될 듯 말 듯 하면서 릴리스는 기약없이 지연된다. 처음엔 2~3일 후면 될 거라 기대하고 잠시 쉬던 것이 하루 이틀씩 밀리면서 결국 이 주 삼 주 동안 제대로 진행할 수 없게 된다. 이런 경험이 잦아지면서 일부에선 중간중간에 변경된 코드를 밀어 넣는다. 다음 릴리스를 위한 개발 코드 브랜치와 (지연중인) 릴리스 브랜치 간에 코드 격차가 심해져, 개발 브랜치에서 해결된 문제를 릴리스 브랜치에 반영하는데 한참을 씨름하기도 한다.
윗선도 계속되는 릴리스 관련회의로 시간을 낭비하기는 마찬가지다. 현황을 파악하고, 얼마나 더 지연시킬 지 정하고, 지연이 미치는 영향을 분석하고, 이왕 지연된 것 미리 구현된 간단한 기능을 포함시킬 지 논의하고.. 자료를 준비해 더 윗선이나 마케팅, 기획, 운영(예산) 팀 등과도 계속 조율을 해야 한다. 야근과 주말 근무가 늘어난다. 일주일 단위로만 지연시켜도 호흡 조절과 재충전이 가능하겠으나, 지연 단위가 보통 1~3일 정도이고, 특히나 금요일 일정은 반드시 토/일/월로 지연된다.
무엇하나 좋을 게 없는 이런 비합리적 문화가 왜 개선되지 않는 것일까?
이런 현상이 반복되고 있음은 윗선에서 과제가 어떻게 돌아가고 있는지 전혀 파악하지 못하고 있다는 확실한 반증이다. 릴리스를 하기 위해 해야할 일이 얼마만큼 남아 있는지 도통 감이 없다. 개발자들의 생산성과 문제 해결능력에 대한 어떠한 정량적/경험적 데이터도 갖춰져 있지 못하다. 개발자 각각이 지금 무슨 일들로 얼만큼의 로드가 걸려있는지도 잘 파악이 안되고 있다. 해결해야할 문제들이 얼마만큼의 노력이 들어가야 하는지도 역시 감이 없다. 아직 드러나지 않은 문제들은 또 얼마나 될 지 역시 예상하기 어렵다. 결국 위에서 할 수 있는 말은 보통 ‘언제까지 이 문제들을 해결해라’ 정도에서 그친다.
제품의 설계나 코드의 품질이 크게 떨어지거나, 다뤄야할 대상을 개발자들의 완벽하게 이해하지 못하고 있을 경우 사태는 더 심각해진다. 분석하고 수정하는데 필요한 시간을 예측하기 힘들고, 수정시 부작용(side-effect)이 따를 가능성이 높다. 동작 여부만이 아니라 코드의 품질을 챙기는 개발 문화를 조성해야 하고, 서로 간의 잦은 리뷰를 통해 다른 팀원들과 개발 패턴, 노하우 등을 공유해야 한다.
관련 개발팀간 커뮤니케이션 효율성도 큰 영향을 미친다. 심한 경우는 핵심 모듈을 전혀 다른 팀에서 관리하고 있고, 우리 과제를 지원하는 것은 그 팀의 최우선 역할이 아닐 때이다(실제로 자주 접해보았다). 유관 팀들이 지리적으로 멀리 떨어져 있고, 원격지에선 문제를 재현하기 어려울 때도 마찬가지.. 어떠한 경우건 커뮤니케이션 지연은 일의 진행 속도를 현저히 떨어뜨리는 주요 원인이 된다. 과제를 기획하고 팀을 조직할 때 그 과제와 팀이 적시에 충분한 지원을 받을 수 있도록 고려해야 한다. 필요하다면 조직 구성을 바꿔 같은 명령 계통 내로 흡수할 필요도 있다.
미흡한 인프라에 의한 불확실성도 크다. 기본적인 테스트 자동화 시스템도 갖추지 못해 매번 개발자들이 수동으로 테스트하는 것도 많이 보아왔다. 나름 도입한 continuous integration 이 기껏 빌드만 해주고 기본적인 unit test 도 수행하지 못한는 경우를 상상해보자. 내가 경험한 어떤 팀은 unit test 를 CI 에 통합해달라는 요청을 한 지 1년이 넘도록 반영하지 못했다. 다른 자동화는 물론 말할 것도 없었다. 과제 규모가 커질 수록 그에 걸맞게 인프라 효율성에도 투자를 해야한다. 발등에 떨어진 일정에만 쫒겨 제때 투자를 못하면 일을 해야할 정작 개발자들의 시간을 어먼 곳에 낭비하게 만든다.
개발 문화와 생산성 향상, 효율성, 팀웍에 대한 인식이 부족하다. 위에서 가장 중요시 하는 것은 언제 릴리스 되는가이다. 어떤 때는 그것 외에는 전혀 관심이 없는 것 같다는 인상을 받곤 한다. 일벌레인 사람들이 지배하는 조직에서 더 심한 경향이 있는 것 같다. 종종 일찍 퇴근하고 싶어하는 사람을 이해하지 못하는 듯한 발언을 듣기도 한다. 아무래도 사람은 자신의 기준에서 남을 이해하는 성향이 있으니, 어찌보면 당연한 것일 수 있다. 하지만 사람(뿐 아니라 모든 생물)은 기계와 달리 충분한 휴식 없이는 높은 집중력과 생산성을 유지할 수 없음을 주지시켜야 한다.
Noop 에 이어 구글이 또 하나의 프로그래밍 언어를 소개했다. Go 라는 이름의 언어로, 벌써 제법 성숙한 상태라, 과거 Turbo C 나 초창기 UltraEdit 로 Java 코딩하던 추억을 떠올리면 충분히 직접 사용해볼 수 있는 수준이다.
Go 언어는 크게 두 가지 관점에서 아주 마음에 든다.
현재의 것에 계속해서 군더더기를 붙여 나가다 보면 점차 비대해져 관리를 어렵게 하고 혁신을 가로막는다. 때문에 종종 처읍부터 다시 시작하는 것이 필요하다.
번외로.. 구글이나 애플과 같은 회사가 이런 일을 참 잘하는데, 최근 40살 된 e-mail 을 대체하겠다며 큰 기대를 받고 있는 Google Wave 나 이미 성숙할 대로 성숙한 핸드폰의 개념을 바꿔버린 iPhone 같은 것이 좋은 예이다.
덕분에 더 이상 필요 없거나 폐해가 더 큰 기능들을 과감히 없애 날렵해짐과 동시에 병렬 프로그래밍과 같이 새시대에 필요한 기능들을 실장하고 있다.
내가 가장 혐오하는 프로그래밍 언어인 C++. C++ 는 기능 확장이 아니라 축소를 먼저 해야 한다고 내가 몇 년 전부터 얘기하고 다녔는지 모른다. 물론 Go 가 C++ 의 직접적인 축소판은 아니지만, 같은 C 계열 (호환이 아니라 파생의 의미로) 언어로써 정말 최소한부터 다시 시작하는 언어이다. 홈페이지에서 언급한 몇몇 설계상의 결정 사항들은 정말 내 가슴을 후련하게 해준다. 포인터 연산, exception, assertion, 오버로딩 등에 대한 설명은 나의 그간 경험에 비춰 특히 공감이 된다. 수많은 개발자들.. 아무리 설명을 해줘도 계속 교체되고, 새로온 사람들에게 또 설명하고.. 그러다 지쳐 포기했던 기억이.. ^^
Go 가 잘 발전해서 C++ 의 영향력이 감소하는데 한 몫 해주길 바래본다.
소프트웨어 플랫폼 경쟁에 있어 우리 나라 기업들은 도저히 상대가 안되는게.. 애플이나 구글같은 회사는 핵심 소프트웨어 개발 역량이 정말 대단하다. 우리처럼 API 겉만 감싸는 수준이 아니라, 필요하면 언어 자체를 수정하거나(최근 GCD 를 위해 C 언어를 확장함) 심지어 만들어버리기까지 한다(Go, Objective-C). 애플은 LLVM/CLang 이라는 GCC 대체 프로젝트를 진행해 큰 성취를 보이고 있고, 구글 가상 머신을 뜯어 고쳤다(Dalvik VM). 소프트웨어 설계 자체도 참 대단하다. 이미 25년의 OS 개발 경험을 축적하고 있는 애플의 OS X 는 전신인 NextStep 시절부터 소프트웨어 설계의 바이블 격인 Design Patterns 책 저술에 지대한 영향을 미쳤다. 현재의 플랫폼도 깊이 들여다보면 ‘우와!’ 하는 감탄사가 절로 나오는 멋진 구조를 어렵지 않게 찾아볼 수 있다.
핵심 기술이 없으면 오픈 소스/커뮤니티에라도 적극 참여해 그들의 노하우를 최대한 빨리 흡수하며 기반을 쌓는 것이 큰 도움이 된다. 모토롤라의 이번 Droid 출시가 좋은 예이다. 작년, 큰 위기를 느낀 모토롤라는 진행중이던 프로젝트들을 대다수 취소하고 회사 전체를 환골탈퇴하는 모험을 감행했다. 덕분에 신규 제품이 나오지 않아 시장 점유율을 급격하게 떨어졌지만, 구글과의 밀접한 협력으로 Android 2.0 폰을 타 기업들보다 몇 개월 앞서 출시할 수 있었다. 결과는 더 지켜봐야겠지만, 구글과의 돈독한 관계뿐 아니라, Android 시장에서 적어도 당분간은 타 업체들을 선도할 수 있는 충분한 노하우를 얻었을 것이다.
허나 안타깝게도 우리 나라 기업들은 이런 방향으로의 가시적인 움직임은 보이질 않는다. 티맥스 윈도우나 삼성 바다의 예에서 보듯이, 오히려 독자적인 플랫폼을 시도하고 있다. 아직은 실체가 드러나지 않아 확언할 수는 없지만, 중학생들에게 ACM 이나 IEEE 논문을 쓰라는 격으로 보인다. 유사하거나 오히려 더 참신한 아이디어가 나올 수는 있으나, 그 깊이와 완성도는 비교할 수 없을 것이다. 유수의 석학들과 경쟁해 진정 그들을 뛰어 넘고자 한다면, 조급함을 억누르고 차근히 기초를 닦는 인내의 기간이 필요하다.
어제 삼성이 오픈한 bada 에 대한 해외의 반응들을 살펴보았다.
예상했지만.. 그리 긍정적이지는 않다.
[나쁜 팀 문화] 시리즈를 더 진행하기 앞서 이 주제를 짚고 넘어가야 할 것 같다. ‘너라고 뾰족한 수 있어?’, ‘그게 말처럼 쉽냐?’ 와 같은 공격에 대한 내 나름의 답변이 될 것이다.
팀의 문제점을 지적하고 개선안을 제시했을 때 우리가 기대할 수 있는 가장 흔한 반응들은 이렇다.
너무 자주, 그리고 공격적인 어투로 문제를 제기하면 이런 반응도 얻을 수 있다.
위 답변들의 공통점은 무엇일까? 그렇다!! 하나하나 나름의 일리가 있다는 것이다. 이렇게 갖가지 저마다의 견고한 방어책들로 무장한 사람들 모두를 단숨에 사로잡을 수 있는 화려하고 강력한 마법을 부리지 못하는한 팀은 복지부동.. 똑같은 불합리함과 불만들을 그대로 간직한 체 그냥저냥 또 시간이 흘러간다.
종종 제안이 받아들여지는 경우가 있다. 대부분 아래와 같은 케이스들이다.
종합해보면, 수동적이고 변화를 싫어하는 사람들도 쉽게 받아들일 수 있는 개선들이다. 이나마도 개선되는 것이 다행이긴 한데.. 문제는 이렇게 해결할 수 있는 이슈들은 제한적이며, 개선 속도도 느리고, 무엇보다 근본적이고 혁신적인 변화는 이끌어낼 수 없다. 그리고 근본적인 변화가 수반되지 않은 지협적 개선은 오히려 비효율을 증가시킬 수 있다. 예를 들어, 갱신된 문서 내용이 잘 공유되지 않는 문제를 해결하기 위해 Wiki 를 도입하면서 기존의 문서 관리 체제는 그대로 유지하고 있다면, 팀원들은 이중으로 정보를 업데이트하고 또 싱크를 맞춰줘야 한다. 개선의 효과를 잘 보지 못하고, 그런 경험이 쌓여갈 수록 사람들은 개선에 대한 신뢰를 잃고, 변화를 거부하게 된다.
서론이 길었는데.. 그럼 말하고자 하는 바는 무엇인가? 팀 문화를 개선하고 팀웍을 향상시키고 생산성을 높이는.. 하루 아침에 짠! 하고 모든 걸 바꿔줄 수 있는 마법 같은 것은 없다는 것이다. 긴 기간에 걸쳐 희생을 감내하고 열심히 노력해서 이겨내야 한다.
팀은 항시 더 나은 내일을 만들기 위해 공부하고 주변을 살피고 서로 논의해야 한다.
물론 리더의 역할이 가장 중요하다. 오픈된 마인드를 가지고 팀원들의 의견을 경청하고, 스스로 솔선수범해야 한다. 변화가 요구되면 장기간에 걸쳐 분위기를 조성하고, 필요하면 컨설팅이나 교육을 병행한다. 팀원들이 눈앞의 업무에만 목매에 시야가 갖혀 있지 않은지 살피자. 그리고 서로 간의 지식과 정보를 공유할 수 있는 문화를 만들고 새로운 것을 배우는 즐거움을 잃지 않도록 힘써야 한다. 업무적으로도 협력하여 개발하는 문화를 조성하자. 코드 리뷰, 페어 프로그래밍, 일일 스크럼, 서로의 테스트 케이스 제작.. 방법은 수없이 많다. 또한 잘하고 있는 것과 개선이 필요한 것은 무엇이 있는지 주기적으로 되돌아보자.
이런 일련의 작업들은 팀을 ‘주변의 자극에 능동적으로 반응하는 유기체‘로 만들어준다. 변화의 필요성이 감지되면 전체가 똘똘 뭉쳐서 함께 헤쳐나간다. 누군가 변화의 방향이 잘못되었음을 감지하면 즉시 공유되어 괘도를 바로 잡는다. 모두가 서로의 상황을 잘 파악하고 있으므로, 상대적으로 더 많은 노력과 희생이 요구되는 사람들을 충분히 배려해주고 그 결과를 보상해준다. 팀은 어떠한 환경에서도 적응하고 진화해나갈 수 있는 생명체가 된 것이다.
마법을 보여달라면, 난 이것을 마법이라 얘기하겠다. 너 따로 나 따로.. 울타리만 둘러둔 콩가루 팀에서는 상상조차 할 수 없던 변화와 활기를 몸소 체험할 수 있을 것이다.
개발자 역량을 평가하는 방식은 여러 가지가 있겠지만, 그 중 대조적인 두 가지의 방식에 대해 써볼까 한다.
마이크로소프트나 구글과 같은 회사는 면접 과정에서 난해한 문제를 내어 그 해결 과정을 직접 지켜보는 것으로 유명하다. 이들이 알아보고자 하는 것은 단순히 문제의 정답을 알고 있는가가 아니다. 주어진 상황을 정확히 이해하는가에서 시작하여 그 답을 찾기 위한 해결 과정 전반을 평가한다. 따라서 정답을 맞추지 못하더라도 높은 평가를 받고 합격되는 경우도 많다. 사람의 문제 응용/해결 능력은 시간이 지나도 쉽게 변하지 않는 특성이므로 이런 과정을 통해 뽑은 사람은 어떠한 일을 맡겨도 잘 해쳐나갈 가능성이 높다.
더불어 합격이 된다면 함께 일할 팀원들이 직접 면접에 참여하는 경우도 많다. 이는 그 팀에 잘 융화될 수 있는 사람인가를 팀원들이 직접 보고 판단하는 것이다. 좋은 팀들은 팀만의 문화가 있기 마련이다. 스포츠, 게임, 여행 등 취미를 공유한다거나, 특정 개발 방법론을 선호한다거나, 단순히 유머와 재치가 있는 사람을 원할 수도 있다.
지식 평가 방식도 일면 의미가 있으나, IT 업체에서 비중있게 활용하기에는 심각한 문제를 앉고 있다.
지식 평가 방식이 절대적인 영향력을 미치는 경우는 아직 보지 못했다. 하지만 부분적으로나마 이런 평가를 수행하고 있다는 것 자체가 소프트웨어 개발 업무의 속성을 기업이 제대로 이해하지 못하고 있다는 반증이 아닐까.
한 번은 외국 개발자에게 국내 기업의 지식 평가 문화에 대한 짧은 견해를 들을 기회가 있었는데, 참으로 이해하기 힘들다는 반응이었다. 회사가 나를 뽑았다는 것은 나의 역량을 신뢰한다는 것이 아니냐는 말을 하였다. 나의 역량을 평가할 자격이 있는 사람은 나와 동고동락하며 함께 일하고 있는 동료들이지, 획일적인 시험의 결과만을 받아보는 사람들은 절대 아니다. 직작컨데, 어렸을 때부터 습득된 잘못된 교육 문화와 관료주의의 폐단인듯한 이 문화는 하루빨리 사라졌으면 한다.
이번엔 예외 안전성(exception safety)에 대해 간략히 정리해보겠다.
좋은 플랫폼/라이브러리/모듈 등을 만드는데 꼭 고려해야할 요소들 중, exception safety 는 그 인지도가 특히 낮다고 할 수 있다. 정상적인 상황에서는 부각되지 않고, 한 번 문제가 발생하면 원인을 찾기 어렵다는 점은 thread safety 와도 비슷하다. 이러한 특성 때문에 견고한 플랫폼을 만들고자 하는 사람들은 반드시 염두해 두어야 한다.
상대적으로 가벼운 프로젝트에서라도 틈틈히 적용하여 체화시켜두면 나중에 시행착오를 줄일 수 있다. 항시 완벽하게 만들려는 것은 노력 대비 얻는 것이 적을 수도 있으니, 코드 리뷰를 하면서 종종 exception safety 관점에서 들여다보는 방식을 권해본다.
다행히도 이 주제는 이미 Wikipedia 에 잘 정리되어 있으므로[1], 한글 번역 + 약간의 부연 설명 수준에서 마무리하겠다.
특정 코드 블럭 안에서 실행중 실패(failure)가 발생해도 잘못된 작용을 일으키지 않는다면, 우리는 그 코드 블럭을 exception-safe 하다고 한다. 잘못된 작용의 예로는 메모리 누수, 변질된(garbled) 데이터/상태 저장, 잘못된 결과 반환 등이 있다. Exception safe 코드는 예외가 발생한 상황에서도 그 코드상에서의 불변성(invariant [2])을 만족시켜야 한다. 그럼 exception safety 를 레벨에 따라 몇 개로 나눠보자.
예를 들어, C++의 std::vector 나 Java 의 ArrayList 와 같은 벡터를 생각해보자. 아이템 x 를 벡터 v 에 넣으면, 벡터 v 는 x 가 내부 객체 리스트에 추가되고, 총 객체 수를 의미하는 count 값을 1 만큼 증가시켜야 한다. 또한 확보해놓은 메모리가 충분치 않다면 새로 메모리를 할당하는 작업도 필요하다. 이 메모리 할당 작업은 실패할 수 있고, 그렇다면 예외가 던져질 것이다. 마지막 이유로 벡터를 failure transparency 레벨로 구현하기란 굉장히 어렵거나 혹은 불가능할 수도 있다. 다행히 strong exception safety 정도를 제공하는 것은 그다지 어렵지 않은데, 동작에 실패하더라도 v 를 이전과 동일한 상태로만 유지하면 된다. 만약 basic exception safety 만 보장하도록 만들어진 벡터라면, v 는 x 를 포함할 수도, 아닐 수도 있다. 단, 어느 경우건 포함 여부와 count 값 사이는 일관된 상태를 유지한다. 반면 minimal exception safety 만 보장하는 벡터에서는 예외가 발생하면 v 는 잘못된 상태에 놓일 수 있다. 예를 들면, x 가 v 에 포함되지 못했음에도 count 는 증가된 상태로 남을 수도 있다. 마지막으로 no exception safe 백터는 프로그램을 크래쉬 시킬 수도 있다. 메모리 할당에 실패했음에도, 이를 확인하지 않고 잘못된 메모리 주소에 데이터를 쓰는 경우가 이에 해당한다.
일반적으로 ’최소한’ basic exception safety 는 보장해 주어야 한다. Failure transparency 가 이상적이긴 하나 구현하긴 만만치 않다. 어플리테이션에 대한 완벽한 정보게 제공되지 않는다면 라이브러리가 이를 보장하기란 대부분 불가능하다.
아무런 생각 없이 구현했다면 no exception safety 라 말하는 것이 안전하다. 비록 API 에 따라서는 더 높은 safety 를 보장하는 경우도 많이 있더라도, 전체의 safety 는 가장 낮을 레벨에 좌우될 수 밖에 없다. 물론 모든 API 를 리뷰하여 최소 safety 가 어디인지를 파악한다면, 그 이상의 safety 를 보장한다고 말할 수 있다.
메모리 관리와 null pointer 체크 정도를 신경썼다면 minimal exception safety 정도라 이야기할 수 있다. 또한 대부분의 정적 분석 툴들[3]은 resource leak 과 잘못된 메모리 접근 문제를 검출해 주므로, minimal exception safety 보장하는데 많은 도움이 된다.
Basic exception safety 수준까지 끌어 올리려면 메모리와 포인터뿐 아니라 인스턴스의 속성(property, field, or private member variable)의 변화까지 신경써야 한다. 한 함수 내에서 두 개 이상의 속성을 다루고, 뒷의 속성 조작 중 예외가 발생하더라도 invariant 조건이 만족되도록 신경써야 한다.
Commit or rollback semantics 는 어느 단계에서 예외가 발생했더라도 원상태 그대로 복구시킬 수 있어야 한다. 즉, 문제가 된 동작을 애초부터 시도하지 않은 것과 동일한 결과를 낳아야 한다. 종종 invariant 를 신경쓰는 것보다 수월하게 구현할 수도 있지만, file 이나 database 를 건드리거나 네트워크로 서버에 요청을 보내는 등의 동작이 포함된다면 결코 쉬운 작업이 아니다. 더욱이 multi thread 환경이라면 동기화까지 고려되어야 한다.
아주 특별한 경우가 아니면 Failure transparency 보장을 요하는 경우는 없으니, 자신이 mission critical 분야에 종사하고 있다고 생각하지 않는다면 잊어도 좋다.
대부분의 프로젝트에서는 아래 정도의 전략이면 충분히 만족스러운 결과를 얻을 수 있을 것이라 믿는다.
