우리는 창의력과 혁신을 강조하는 시대에 살고 있다. 소프트웨어 개발도 당연히 그 중심에 서 있다. 하지만 우리의 소프트웨어 개발 문화는 창의력을 심히 제한하는 방식으로 굳어져 있다.
일반적으로 우수한 편에 속하는 지적 능력을 가지고 있고, 새로운 것을 만들어내는 것을 즐기는 소프트웨어 개발자들. 그들은 회사에서 어떤 대우를 받고 있나. 조직이 조금만 커져도 기획은 별도의 부서에서 진행하고, 소프트웨어 개발은 몇몇 관리자들이 이끌게 된다. 소프트웨어 개발자들은 창의력을 발휘하기 보다는 시키는 일만 열심히 해야 하는 위치에 놓이게 된다. 코드를 찍어내고 타의에의해 변경된 요구사항들 때문에 수정/테스트를 반복하는 나날을 보내며 발언권은 점점 작아진다.
기술 개발을 중시하는 몇몇 소수 기업을 제외하고는 대부분(대기업)의 윗사람들은 아직까지 소프트웨어 개발자들을 단순 노동자 취급하고 있다. 이를 빗대어 나는 ‘소프트웨어 제조업’ 에 종사하고 있다고 얘기하곤 한다.
반면, 개발자들의 능력을 믿고 그들에게 스스로 혁신을 일으킬 수 있도록 지원해주는 대표적인 기업들로 Google, Apple, Rally Software 등을 들 수 있다.
Google 은 20% 제도로 유명하다[1]. 자신에게 주어진 시간 중 20% 정도를 주업무가 아닌 다른 일에 할애하도록 권장하는 제도로, 다양한 형태로 응용 가능하다. 매일매일 20%의 시간을 다른 일에 투자하는 것은 대부분의 경우는 현실적이지 않다. 프로젝트 마감이 코앞인데 다른 일에 정신 팔기도 힘들고, 하루 1~2시간씩 해서는 진도도 나가지 않기 때문이다. 대신 그들은 1주일에 하루, 1달에 1주, 혹은 6개월에 1달, workaholic 이라면 주말을 이용 등등.. 자유롭게 변형해서 일한다. 과제가 바쁠때는 열심히 그 일에 매달렸다가 한가할 타임에 그동안 못 쓴 20%를 쓰는 식이다.
20%의 시간에는 어떤 일을 할까? 이것도 아주 자유롭다. 전혀 새로운 과제를 수행할 수도 있고, 관심있는 다른 팀 과제를 지원할 수도 있고, 자신의 주 과제를 진행하면서 불편했던 부분을 자동화하거나 유용한 유틸리티를 만들거나, 최적화/리펙토링을 할 수도 있고, gmail/chrome browser 등에 유용한 플러그인을 만들어넣을 수도 있다. 공부를 할 수도 있다.
이렇게 해서 나온 결과들은 팀의 개발 생산성을 향상시키고, 제품의 품질을 좋게하고, 새로운 것을 배우게 만들고, 운이 좋으면 구글의 미래를 이끌어갈 제품으로 거듭날 수도 있다. Gmail, Google News, Google Talk, Orkut, Google Sky [2], Go programming language [3] 등은 모두 20% 시간에 시작된 프로젝트들이다.
Apple 의 경우 1년에 1달 가량 자신이 원하는 일을 할 수 있게 해준다지만.. 자세한 내용은 잘 알려지지 않았다[4].
마지막으로 Rally 의 경우 8주의 개발 사이클 중 마지막 1주는 회사의 미션과 관련된 일이라면 어떤 것이든 할 수 있는 권한이 주어진다[5]. 기간이 일정하게 주어져 있기 때문에 융통성이 조금 부족하지 않을까 우려되긴 하지만 한 숨을 돌리며 자신들의 과거를 뒤돌아볼 수 있다는 점만으로도 확실한 장점이 될 것이다.
다시 암울한 우리의 이야기로 돌아와보자.
나는 현 회사의 윗사람으로부터 ‘관지자가 할 일은 개발자가 놀지 않게 하는 것’ 이란 얘기를 들었다. 여기서 논다는 것은 ‘주업무와 직접적으로 관련 없는 모든 일’을 지칭한다. 내게는 ‘공장 가동을 멈추지 말 것’ 정도로 들렸다. 공식적인 주업무 외에는 회사에 기여하지 못하는 것으로 여겨기기 때문에 일거리를 만들어서라도 주지 않으면 능력 없는 관리자가 되는 것이다.
개발자 입장에서도 마찬가지다. 좋은 아이디어가 있더라도 side job 은 업적으로 인정받기 어렵다. 놀고 있는 것으로 받아들여지므로 드러내놓고 할 수도 없다. 결국 몰래 하거나 개인 시간을 희생해서 짬짬이 하게 되고, 인정받지 못하기 때문에 의욕이 생길리 만무하다.
고급 인력인 개발자들의 좋은 두뇌를 활용하지 못하고, 반대로 창의성을 저하시키는 이런 문화는 하루 빨리 고쳐져야 한다. 말로만 소프트웨어가 중요하다고 하지 말고, 소프트웨어 개발의 특성과 개발자들을 이해하려는 노력이 절실하다.
두서 없지만 이 글은 이쯤에서 마무리하기로 하고, 유사 주제로 작성하고 있는 글이 있으니 그 쪽에서 정리를 시도해보기로 하겠다. ^^
한 4년쯤 전에 정리를 시작했던 주제로, 지인 몇 명과 논문으로 써볼까 기고를 할까 고민하다 제 때 빛을 보지 못했다. 실례를 찾아 보강하는 것이 가장 큰 숙제였는데, 불행히도 그 후 테스트 관련 업무를 접할 기회가 없었어서 기고까지는 하지 못했다.
In other to make software testable, designer should follow some rules. If you are interested in software design, some of them must be familiar to you. That’s because they are rules for improving software ‘design‘ in testability perspective. Lets look into the rules one by one.
Software which satisfies these rules can be called testable. However, it is very hard to measure quantitatively how well the rules are reflected. I’ll remain this issue for other dedicated articles.
(in Korean)
테스트 가능한 소프트웨어를 만들기 위해서는, 설계자는 몇 가지 규칙을 따라야 한다. 소프트웨어 설계에 관심있는 사람이라면, 친숙한 이름의 규칙들을 찾을 수 있을 것이다. 이유인 즉, 이 규칙들은 테스트의 관점에서 소프트웨어의 ‘설계‘를 향상시키기 위한 지침이기 때문이다. 그럼 그 규칙들을 하나씩 살펴보도록 하자.
이상의 규칙들이 충족된 소프트웨어라면 ‘테스트할 수 있다’고 얘기할 수 있을 것이다. 단, 이런 규칙들이 얼마나 잘 반영되었는지를 정량적으로 측정하는데는 분명한 한계가 있다. 측정 이슈는 주제의 범위를 벗어나므로 본 글에서는 더 자세히 다루지 않을 것이다.
(Read the full article)
Spring Framework 관련 한글책[1]을 보다가 Dependency Injection(DI)의 번역에 대한 역자주에서 생각해볼 만한 것이 있어 보충 설명 겸, 잠시 끄적여본다. DI의 개념이 아직 모호한 사람이라면 이 글을 먼저 읽어본 후 참조한 wikipedia[2]의 글을 보면 전체적인 윤곽을 잡는데 도움이 될 것이다.
역자주: 종속객체 주입, 즉 DI(dependency injection)는 스프링에서 가장 기본이 되면서도 매우 중요한 의미를 갖는다. 기존에 가장 많이 쓰이던 번역은 ‘의존성 주입’이었다. 그러나 역자가 보기에 이 번역은 ‘없는 의존성을 만들어 주입한다’는 오해를 일으키고, 이 때문에 DI의 이해가 어려웠다고 생각한다. DI는 없는 의존성을 주입하는 것이 아니라 의존성은 이미 존재하되, 실제 객체가 필요로 하는 종속객체를 주입하는 것을 의미한다. 따라서 ‘의존성 주입’보다 뜻이 명확하도록 ‘종속객체 주입’이라고 번역했다. .. (후략)
일단.. 이 역자가 잘 봤다고 말하고 싶다. DI에서 dependency를 의존성으로 번역한 것은 확실히 잘못된 것이다. UML, OOAD 등 지금까지 IT 기술 관련 대부분의 상황에서는 모듈 간 관계를 명시하기 위해 dependency라는 용어를 사용해왔기 때문에 여기서도 습관적으로 의존성이라는 단어를 선택했으리라 생각한다. 하지만 단어는 문맥에 따라 여러 가지 의미를 가지고 있음을 잊어서는 안 된다.
DI를 직역하더라도 의존성 주입은 아니다. 오히려 위 역자가 사용한 종속객체 주입이 더욱 적절하다. 약간 아쉬운 게 있다면 DI는 object 세상에 국한되지 않기 때문에 ‘객체’라는 말은 여전히 논란의 소지가 있다는 점 정도. 범위를 제한하지 않으려면 module 정도의 추상적인 용어를 사용할 수 있겠지만, object라는 용어도 꼭 OOP에서 말하는 object로 제한되는 것은 아니니 상관없을 듯하다.
그럼 다시.. 왜 직역을 했는데도 의존성은 틀린 것일까? 이는 DI 패턴의 구조[2]를 살펴보면 쉽게 이해가 된다. DI 패턴은 세 개의 요소로 구성된다. 적절한 한글 대용어를 찾기 어려워 대강 번역해보면 이렇다.
이 패턴은 최소 3개의 구성 요소로 이루어진다: dependent와 그의 dependencies, 그리고 injector (혹은 provider, container). Dependent 는 컴퓨터 프로그램에서 작업(task)을 수행해야 할 소비자(consumer)다. 작업 완료를 위해선 특정 부작업들(sub-tasks)을 수행하는 다양한 서비스(dependencies)들을 활용해야 한다. 마지막으로 Injector는 dependent와 그에 필요한 dependency들을 조합해서 작업을 수행할 준비를 갖추는 컴포넌트로써, 이 객체들의 전반적인 라이프 사이클을 관리하기도 한다.
위 설명에서와 같이 DI의 dependency는 객체 간의 관계 속성을 의미하는 것이 아니라 서비스를 제공해주는 ‘실체’를 가리킨다. 그 실체를 (의미 그대로) dependent에서 주입시켜주는 것이다. 위 역자의 용어에 맞추어보면 대략 이렇게 되지 않을까 싶다.
이 용어들을 적용해 다시 번역해보면 아래처럼 되겠다. 깔끔하려나.. ^^
이 패턴은 최소 3개의 구성 요소로 이루어진다: 의존 객체(dependent)와 그의 종속 객체들(dependencies), 그리고 주입자(injector, provider, or container). 의존 객체는 컴퓨터 프로그램에서 작업을 수행해야 할 소비자다. 작업 완료를 위해선 특정 부작업들을 수행하는 다양한 서비스(종속객체)들을 활용해야 한다. 마지막으로 주입자는 의존객체와 그에 필요한 종속객체들을 조합해서 작업을 수행할 준비를 갖추는 컴포넌트로써, 이 객체들의 전반적인 라이프 사이클을 관리하기도 한다.
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 논문을 쓰라는 격으로 보인다. 유사하거나 오히려 더 참신한 아이디어가 나올 수는 있으나, 그 깊이와 완성도는 비교할 수 없을 것이다. 유수의 석학들과 경쟁해 진정 그들을 뛰어 넘고자 한다면, 조급함을 억누르고 차근히 기초를 닦는 인내의 기간이 필요하다.
이번엔 예외 안전성(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 분야에 종사하고 있다고 생각하지 않는다면 잊어도 좋다.
대부분의 프로젝트에서는 아래 정도의 전략이면 충분히 만족스러운 결과를 얻을 수 있을 것이라 믿는다.
최근 다른 사람이 작성한 소스를 리뷰하면서 리팩토링할 일이 있었다. 깊이 있는 리팩토링까지는 해보지 못했으나, 남의 코드 리팩토링은 오랫만이라 간단히 노하우를 정리해본다.
정체를 알 수 없는 임의의 소스 덩어리를 받게 된다면, 대략 아래와 같은 순서로 리팩토링하는 것이 효율적이다.
1. Make duplications
리팩토링의 첫 단계에서는 중복 코드를 생산해낸다. 헐~! 이게 뭔 소린가? 중복 코드를 만드는 데는 조건이 있다. 로직의 상당 부분이 동일 혹은 유사해야 한다.
코드를 살펴보면, 결국 똑같은 혹은 유사한 일을 하면서 따로 노는 모습을 심심치 않게 발견할 수 있다. 각 파트별 담당 개발자가 선호하는 방식이 달라서일 수도 있고, 같은 개발자더라도 나중에 더 나은 API를 찾거나 더 간소한 알고리즘이 떠올랐을 수도 있다. 혹은 전에 짰던 부분과 흡사하다는 걸 떠올리지 못한체 처음부터 다시 짤 경우도 같은 결과가 나타난다.
코드가 척 보기에도 너무 다르다면 눈썰미가 본좌급이거나 운이 좋아야 발견할 수 있다. 따라서 누구나 기계적으로 할 수 있는 방법을 알아보자. 바로 이미 유사한 코드를 찾아서, 동일한 로직으로 만들 수 있는지 보는 것이다. 시장에는 중복 코드를 찾아주는 툴들이 이미 많이 나와있다. 이들 중 더 발전된 것은 유사 코드를 찾아주기도 한다. Java 라면 PMD 나 CheckStyle 같은 툴을 기본으로 사용하고 있으리라 믿는다. 이들 툴의 여러 기능중 duplicated code 검출 기능도 있으니 이를 활용하자. C/C++ 의 경우 언어 한계상 지원 툴이 상당히 빈약한데.. 다행히 위의 PMD 가 C++ 역시 지원해준다. 사용법은 여기를 참조하기 바라며.. 본인도 이를 이용해 작업을 진행하였다. 버그는 좀 보이지만, 간단히 사용하기에는 부족하지 않다.
결과: 같은 일을 처리하는 코드는 모두 동일하게 작성되었다.
2. Remove duplications
다음 단계가 바로 1단계에서 만들어 놓은 (혹은 그 전부터 존재하던) 중복 코드 제거이다. 코드가 중복되어 있다면 리팩토링도 중복으로 해야하고, 각각의 리팩토링 과정을 완전히 동일하게 하기는 상당히 말처럼 쉽지 않다. 중복 코드를 개별적으로 수정하면, 중복된 코드라는 것 자체를 인지하기 어려워진다. 각 코드 블럭의 리팩토링 순간 사이에 시간적 격차가 있으므로, 같은 로직을 보더라도 다르게 리팩토링할 가능성이 생긴다(기계가 아닌 사람인지라). 논리적으로 똑같이 하려해도 human error 가 발생할 여지도 다분하다.
중복 코드 식별 역시 ‘다행히도’ 사람이 하기엔 너무나 벅찬 일이다. 그래서 툴이 필요한데, 1단계에서 사용한 툴들이 바로 그들이다.
결과: 모든 코드는 unique 하다.
(곧 별도의 글을 통해 중복 코드 제거를 위한 몇 가지 패턴은 선보이도록 하겠다.)
3. Remove unused code (variable, code block, method, class, etc)
사용되지 않는 코드는 분석 중 논리 흐름을 방해하며, 자칫 의미 없는 코드를 리팩토링하며 시간을 낭비하게 된다.
대부분 범용 언어는 툴이 잘 지원해주고 있으나, 검출 범위와 사용성은 편차가 좀 있는 편이니 자신의 환경에 접목 가능한 툴들을 한 번 쯤 조사해보는 것을 추천한다.
결과: 모든 코드는 의미를 갖는다.
4. Reformat and rename
코드의 기초 가독성을 높이는 작업이다. 맞춤법에 맞게 코드를 수정하고(reformating), 의미가 명확히 통하는 용어를 사용하게 한다(renaming). Renaming 의 대상은 변수명, (내부) 메서드/클래스명 등이다.
결과: 코드는 의미가 명확한 단위 요소로 구성된다.
5. Refine logic (including extract/inline method)
코드의 논리 흐름을 가다듬는 단계이다. 작문에 비유해보자. 쉬운 용어들을 사용하더라도 산만하거나 애매모호한 글에선 핵심을 찾기 어렵다. 반면 논리 정연한 글은 하고자 하는 바를 쉽게 이해할 수 있다. 따라서 그 논리에 결점이 있다면 바로 파악하여 수정할 수 있고, 논리를 수정하거나, 설명을 보강하는데도 용이하다.
이 과정에서는 이어진 긴 문장을 의미가 분명한 적절한 단위로 나누거나, 큰 문단을 통채로 하나의 추상적 문장으로 교체(extract method)하고, if/else/switch 등으로 복잡해진 흐름을 같은 의미의 더 간결한 논리로 수정하는 등의 작업이 이루어진다. 최종 목표는 주석 없이도 글을 읽듯이 코드를 술술 읽을 수 있도록 하는 것이다.
결과: 코드를 자연스럽게 읽을 수 있다.
Refactoring Home Page 에 가면 수많은 리팩토링 기법들을 찾을 수 있다. 관리자인 Martin Fowler 도 양해를 구하고 있듯이, 설명과 관리에 그리 많은 신경을 쓰고 있진 않지만, 틈틈히 살펴보면 제법 도움이 될 것이다. 내 나름의 기법과 함께 위의 각 단계에서 많이 쓰임직한 것들을 묶어서 정리해보는 것도 재미있을 듯하니, 나중에 시간이 나면 한 번 시도해봐야겠다.
(특히) 팀으로써 소프트웨어를 개발하다보면 주석을 잘 달라는 이야기를 자주 듣는다. 하지만 반대로 주석이 필요없는 코드를 짜라는 이야기 역시 심심치 않게 들려온다. 얼핏 생각하기엔 서로 모순되는 주장 같기도 한 두 가이드들에 대해 정확히 이해해보고, 또 좋은 주석을 달기 위한 팁과 고려 사항들까지 일부 정리해보도록 하겠다.
이야기를 시작하기 전에 주석에는 어떤 종류가 있는지부터 명확히 해야 하는데, 주석의 역사에서 시작하는 것이 자연스러울듯 하다.
놀랍게도(?) 태초의 소프트웨어 코드에는 주석이란 개념이 아얘 없었다. 그도 그럴 것이 종이카드에 0011000 구멍 뚫어서 프로그램하던 시절에 주석을 삽입한다는 것은 사치일뿐 아니라 기술적인 도적이었다. ^^ 이 시절 펜으로 종이 위에 이것저것 적어놓던 것이 주석의 시작이라고 보면 된다. (사실 이 부분은 직접 경험해보진 않아서 추측성임)
컴파일러(사실 전처리기)가 주석을 인식하기 시작한 것은 당연히 소스 코드를 디지털화시킨 이후이다. 이마저도 처음엔 지금과 같은 형태는 아니었다. 초창기 언어들은 주로 line by line 으로 해석되었기 때문에 주석 역시 single-line 형태가 먼저 등장했다. 복잡한 인터페이스 설명이나 알고리즘 설명 같은 것보다는 영역/블록 구분과 간단한 커맨트 중심이어서 그리 불편하지 않았다. 그 후 등장한 multi-line 주석은 편집 편의성 증대를 위한 욕구 해결 정도여서 전혀 신선하지도 혁신적이지도 않았다.
Java가 등장하면서 (최초인지는 모름) API 문서 생성 ‘표준’ 툴(Javadoc)을 SDK 가 내장하기 시작하였고, 이는 주석의 개념을 한 단개 발전(not 혁신)시키는 계기가 되었다. Javadoc 의 특징이라면 ‘스펙 기술용 주석‘과 ‘구현 설명용 주석‘을 명백히 구분하기 시작한 것이다. 물론 그 전부터 주석을 구분해 사용하고는 있었지만, 언어의 표준적인 방식으로 도입했다는 것이 큰 의미가 있다.
이를 계기로 주석에 대한 인식은 한층 개선하였고, 그 후 등장하는 대부분의 언어들도 같은 어프로치를 취하게 되었다. 하지만 아직까지 컴파일러는 스펙/구현 가리지 않고 모든 주석을 무시하였고, 스펙을 얻어내려면 별도의 툴을 돌려야만 하였다. 이는 ‘스펙 기술’ 이라는 오늘날에 있어 아주 중대한 개념을 ‘주석’ 이라는 사소한 범주에 함께 묶는 한계에서 아직 벗어나지 못했음을 의미한다.
이에 대한 개선은 최근 Noop 언어 프로젝트를 통해 가시화되고 있다. Noop 의 여러 특징 중 ‘Executable documentation that’s never out-of-date’ 는 주석을 프로그래밍 언어 스펙에 포함시키고 컴파일러가 컴파일 워닝/에러와 같은 수준에서 직접 핸들링한다는 의미이다. 형식적으로는 거의 변화가 없지만, 주석의 위상은 거의 코드 수준까지 격상되게 된다.
나아가 annotation 이라는 개념이 추가된다. Annotation 을 주석으로 한데 묶는데는 의 아해할 사람들이 있을 수 있겠으나, 수행 코드가 아니라는 점에서 주석의 범주에 속한다. 더구나 annotation 의 한글 해석 자체가 ‘주석( 달기)’이다. ^^ (Noop 에서 annotation 을 어떻게 처리할 지는 명시적인 언급은 없다.)
주석의 중요성이 점차 커지는 것은 소프트웨어 산업의 변화 과정을 봤을 때 아주 자연스러운 결과이다. 개인이 다룰 수 있던 작은 소프트웨어에서, 이제는 수백 수천명이 수년에 걸쳐 만들고, 완전히 없어지기까지 또 수년이 더 필요한 수준까지 변화하였기 때문에, 공간과 시간을 초월한 개발자간의 커뮤니케이션이 그만큼 중요해진 것이다.
이쯤에서 현재 우리가 주석이라 부를 수 있는 것들에는 어떠한 것들이 있는지 다시 정리해보자.
이처럼 현재까지는 크게 3 가지의 대표적인 주석이 있으며, 소프트웨어 산업이 변화하면서 앞으로도 기존 주석이 변화/갈라지거나 새로운 형태의 주석이 추가될 것이다.
“상세한 주석이 좋다.” – 주로 문서화 주석에 해당하는 지침이다. 제공하는 소프트웨어 모듈의 동작 명세는 가능한 모든 케이스에 대해 명확하게 설명해 주는 것이 좋다.
“주석이 필요 없도록 코딩하라.” – 주로 구현 주석에 해당하는 지침이다. 구현 주석이 있다는 것은 코드만으론 의미 전달이 불충분하다는 반증이므로, 가능한 코드를 명확히 작성하여 구현 주석 없이 읽고 이해할 수 있게 하는 것이 좋다.
보통은 위와 같이 받아들이면 되지만, 반대의 경우도 얼마든지 있다.
“문서화 주석이 최소화 되도록 코딩하라.” – 이는 문서화 주석을 생략하라는 의미보다, ‘문서화 주석에서 군더더기 설명이 필요 없도록 API 를 명확하게 만들라’ 정도로 이해해야 한다. 문서 없이 API 만 봤을 때 오해의 소지가 있다거나, 다양한 예외 상황이 존재하거나, 한 API 를 너무 다목적으로 사용할 수 있다거나, pre/post 조건을 주렁주렁 달고 있는 API 들은 이 가이드를 제대로 지키지 못한 예들이다.
“상세한 구현 주석이 좋다” – 어쩔 수 없이 구현 주석이 필요할 시에는 명확하고 상세한 설명을 달라는 의미이다. 최적화를 위해 어쩔 수 없이 복잡한 코드를 작성했다거나, 컨트롤 밖에 있는 외부 종속성 때문에 비효율적인 구조를 가져갈 수 밖에 없었다거나, 일정 등의 이유로 임시 코드를 넣어놨거나 일부 기능을 구현해놓지 않은 상황에서는 상세한 주석을 달아주어야 한다. (이 주석을 보게될 사람이 자신뿐이라는 가정은 절대 하지 말라.)
좋은 주석 작성을 위한 팁
좋은 주석 작성 팁까지 집대성 해놓으면 최고의 글이 되겠지만.. 이 글의 범주에서는 제외하도록 하겠다. (다른 누군가 집대성 해주시거나, 이미 잘 되어 있는 좋은 링크들을 보내주시면 해피할텐데 ㅎ)
주석을 주석으로만 취급하는 시대는 끝났다(끝내야 한다^^). 하지만 아직도 대부분의 개발자들 주석에 대한 인식은 가볍기만 하고, 진정한 가치와 중요성을 제대로 교육/훈련시키는 모습은 찾아보기 쉽지 않다.
이제부터라도 주석과 관련한 명확한 개념 정리와, 용도별 좋은 주석 작성을 위한 가이드를 정리해 소프트웨어 입문 초기부터 익히고 생활화할 수 있도록 지도해야 한다. 지금과 같은 소셜 개발 시대에서 훌륭한 개발자가 되려면 시공간을 넘나드는 4차원적인 커뮤니케이션 능력도 갖춰야 한다.
내가 지금까지 접해본 여러 이론/실천법 들을 통틀어 가장 맘에 드는 것들을 세 가지 고르라면 TDD, Refactoring, Scrum, 이렇게 세 가지를 뽑겠다. (우리 조직에선 이 중 단 하나도 하지 않고 있어서 참으로 답답하고 안타깝다.) 다른 사람들과는 좀 다른 관점일 수 있겠는데, 이들에 애착이 생기는 내 나름의 이유는 간략히 정리해본다.
Refactoring – Refactoring은 현재의 잘못된 점이나 부족한 부분을 식별하여 더 나은 형태로 개선하는 작업이다. 따라서 Refactoring 은 일종의 회고이며, 그 주된 관점은 설계/코드의 효율성, 가독성, 명확성 등이다. 사람이나 조직이 회고를 통해 교훈을 얻고 성장하듯, 개발자도 Refactoring 을 통해 역량을 키워나간다. 여건이 되지 않으면 혼자서라도 틈틈히 수행해야 하며, 다행히 지도해줄 경험 많은 동료가 함께한다면 그 효과는 배가된다. 팀의 리더라면 팀원간의 이런 교류가 자연스레 일어날 수 있도록 이끌어 주어야 한다.
Refactoring은 개발 기간 내내 리듬을 가지고 정기적으로 수행되어야 한다. 리펙토링 문화가 충분히 자리잡지 못했다면 프로세스에 명시해두는 것이 좋다. 시점은 매 반복 주기(iteration/milestone)가 끝나고 다음 주기가 시작되는 시점이다. 새로운 기능을 넣기 전에 기반을 단단히 다진다거나, 구조적 문제를 조기에 다잡아 추후 대규모 수정을 예방한다는 점도 물론 중요하지만, 사람(개발자)의 역량 성장 측면에서도 반드시 요구되는 프로세스이다.
배우고 경험하고 배우고 경험하고.. 두 과정이 주기적으로 반복되어야 머리로 익힌 것이 체화되고, 그것이 실생활에서 어떤 가치가 있는지 진정한 의미를 깨닫게 된다. 처음에 좋아보였던 것도 생각지 못했던 숨은 이슈나 과소 평가했던 측면 때문에 실제로는 역효과가 더 큰 경우도 많다. 또한 체험 없이 계속해서 머리로만 익히다 보면 모든 것이 쉽고 단순해 보이는 경향이 있다. 이렇게 해서 다음 리펙토링을 수행할 때에는 이전 수행 시보다 향상된 시각으로 구조를 바라볼 수 있게 된다. 설계와 코드를 보는 눈이 향상되고, 시행착오가 줄어들고, 다양한 경험을 통해 확신을 가질 수 있다. 주기적인 Refactoring은 프로젝트가 진행될 수록 Refactoring의 품질과 그것을 수행하는 개발자 역량을 함께 성장시킬 수 있는 멋진 제도적 장치가 될 것이다.
Refactoring 시 주의점
리펙토링 시 가장 신경써야할 부분은 역시 side effect 다. 때문에 전문 툴 활용과 풍부한 테스트 케이스가 준비가 큰 도움을 준다. 툴의 Refactoring 지원 정도는 언어별로 편차가 심하다. Small Talk, Java 언어는 Refactoring 이 지원되지 않는 툴은 오래전에 자취를 감췄을 정도로 대중화되어 있고, C#, Visual Basic 등은 중간 정도.. C/C++ 계열은 아직 많이 부족하며 발전 속도도 더디다.
툴이 해주는 일은 다양한 리펙토링 기법들을 마우스 클릭 몇 번으로 관련된 모든 코드를 자동 변경해주는 편리함과, 이 때 발생할 수 있는 구조적 충돌을 사전 검증하여 side effect 을 최소화시켜주는 효과가 있다. 소프트웨어 규모가 커지면 수십명이 일주일 동안 해야할 변경량을 한 사람이 반나절 만에 처리할 정도로 극적인 효과를 볼 수도 있다.
툴이 구조적인 side effect를 예방해준다면, 테스트 케이스는 기능적인 side effect 를 예방해준다. 테스트 케이스가 충분치 않다면 변경의 잘못된 영향을 먼 훗날에야 발견하게 되고, 무엇이 그 원인이었는지 파악하기 어렵게 된다.
Refactoring 과 TDD 테스트의 대표 주자는 역시 TDD 이다. 현실적으로 거의 불가능하지만, TDD 를 100% 잘 따랐다면 작성된 코드 중 테스트 케이스가 커버하지 못하는 영역은 존재하지 않는다. 따라서 Refactoring 을 가장 안전하게 하기 위한 좋은 지침은 TDD 를 잘 따르는 것이다. 역으로 TDD 의 과정에서 새로운 테스트 케이스(요구사항)가 추가되면, 그 케이스를 만족시키기 위해 기존 코드를 Refactoring 해야한다. 이렇든 이 둘은 거의 바늘과 실 관계이다. 다만 Refactoring 없는 TDD 는 그 효과가 급감하지만, TDD 없이도 테스트 케이스는 작성할 수 있으므로 Refactoring 은 독자적으로도 충분한 가치가 있다.
평소 기술 동향에 관심이 많아 Parallel Programming 을 빨리 익혀둬야겠다 생각한 지는 벌써 1년도 훨씬 지난 것 같은데, 마땅한 기회를 잡지 못해서 자료만 모으고 있었다. 그러다 마침 Snow Leopard 에서 Grand Central Dispatch (이하 GCD)라는 멋진 기술을 제공한 것을 계기로 몇 일 동안 이러저런 자료들을 살펴보았다. 처음엔 기본적인 개념 정리까지 해볼까 하였으나, 현재로썬 단순 번역 정도에서 그칠 듯 싶어 마음을 바꿔먹었다. 오늘은 운을 띄우는 정도에서 몇 자 적어보고.. 더 깊이 있는 지식과 경험을 쌓으면 보다 전문적인 글을 적어보겠다.
CPU 가 클럭 경쟁에서 멀티코어 형태로 그 진화 방향이 변화하였고, GPU 의 성능이 CPU 를 능가하기 시작하면서, 그 막강한 프로세싱 파워를 그래픽 외적인 목적으로도 활용코자 하는 노력도 몇 년 전부터 꾸준히 진행되어 왔다. 멀티 코어 CPU 와 GPU 의 공통적인 특징은 바로 복수의 프로세싱 엔진(코어)를 갖음으로써 여러 개의 서로 다른 연산을 병렬로 처리할 수 있다는 점이다. Parallel Programming 은 이런 다중 코어 환경에서 코어들을 최대한으로 활용하여 프로그램의 성능을 향상시키고자 하는 프로그래밍 기법을 일컷는다.
서버 분야에서는 멀티 코어 이전부터 멀티 프로세서 환경이 일반화 되어 있기 때문에 Parallel Programming 의 역사는 상당히 깊다. 자연히 GCD 는 갑자기 혜성처럼 나타난 별천지 기술은 아니다. 그리고 기존 상식을 뛰어넘는 혁신적인 아이디어도 보이진 않는다. 다만 서버 분야에서부터 적어도 십수년간 쌓아온 노하우를 애플 식으로 OS X 플랫폼에 멋지게 녹여낸 것이다. 그럼 애플 외의 다른 경쟁 데스크탑 플랫폼에서의 상황은 어떠할까?
.NET 은 곧 등장할 Windows 7 부터 4.0 으로 버전업되며, .NET 4.0 의 큰 특징 중 하나로 Task Parallel Library (TPL) 탑재가 있다. MS 도 바보가 아닌 이상 병렬화라는 시대 흐름을 놓칠 리 없고, 애플과 비슷한 시기에 비슷한 문제를 해결하려는 나름의 솔루션을 내놓는 것이다. Java 역시 곧 등장할 JDK 7 에 Fork/Join Framework 을 포함한 JSR166y 를 추가하여 병렬 환경 지원을 강화하고 있다.
이렇듯 Parallel Programming은 이제 거스를 수 없는 시대의 흐름이고, 어플리케이션이 이를 얼마나 잘 활용하느냐에 따라 수십배의 성능 차이를 보이는 날이 곧 도래할 것이다.
다시 애플의 GCD 로 돌아가보자. 내가 아직 전문 지식이 부족한 관계로 정확한 평가는 불가능하지만, 현재의 얕은 지식만을 바탕으로 봤을 때 GCD 의 큰 장점은 아래 정도이다.
이 글은 관련 자료 중 쓸만한 링크들을 남겨놓는 것으로 마무리 하겠다. 나중에 직접 작성해볼 기회가 생기면 코드 수준에서의 간단한 설명과 성능 테스트 결과 정도를 포스팅할 생각이다.
TDD (Test Driven Development) – 보통 언급은 되지만 크게 부각되지 않는 장점. 종종 설명에서 아예 빠지기도 한지만, 내가 가장 높게 쳐주는 TDD의 장점은 바로 ‘개발자들의 설계 능력의 향상’이다. 테스트는 곧 사용자의 사용 패턴을 시뮬레이션 한 것으로, 쉽게 테스트하기 위한 고민은 바로 쉽게 사용하기 위한 인터페이스를 고민하는 것이다. 이 과정을 몇 개월만 반복하더라도 테스트하기 쉬운 설계(testable design)와 그 반대의 케이스의 대표적인 사례(testable design anti-patterns)들을 한 다발 발견해낼 수 있을 것이다. 디자인 공부한답시고 UML 다이어그램 책이나 디자인 패턴 책을 열심히 파는 것보다, 자신이 개발중인 코드를 보고 테스트를 어떻게 할까를 고민해보는 것이 훨씬 효과만점이라고 자신있게 주장할 수 있다.
업계에선 이 부분이 잘 수행되지 않고 있는데, ‘테스트 == 설계’ 라는 관계가 잘 부각되지 않기 때문으로 보인다. (아쉽게도 팀원의 역량 향상을 등한시하는 매니저도 제법 있다.) 설계는 중요시하면서도 테스트는 등한시 하는 것이다. 개발자에게 설계를 잘 하라면서도 테스트는 외부 인력에 의존하는 경우가 너무 많다. 테스터들도 자신이 설계를 검증해야 한다는 것을 자각하지 못하고 있고, 혹 있다손 치더라도 설계에 대해 이러쿵 저러쿵 하는 것을 개발팀에서 그리 달가워하지 않는 경우도 종종 있다. 그리고 테스트를 너무 늦게 시작해 설계 문제가 드러나도 일정상 수정하지 못하는 안타까운 상황도 흔히 발생한다.
기본적인 테스트(유닛, 인티그레이션)는 가능한 모두 개발자들 스스로 수행하도록 하고, 외부 인력은 신뢰성, 고가용성, 보안, 스레드 안정성 등 전문 분야에 대해서 검증을 수행해 주는 것이 효율적이다. 개발자 테스트 단계에서도 단순 기능 검증이 아닌 테스트 용이성에 큰 비중을 주도록 꼭! 주지시켜야 한다.
이렇게 훈련된 개발자들은 나중에 혹 테스트 케이스를 작성할 시간이 부족하더라도 처음부터 상대적으로 수준 높은 설계를 만들어낸다. 신입사원들에게 별 쓸모 없는 프로세스나 테크닉 교육은 대폭 줄이고 TDD 나 한 두 달 시켜주면 현업에 훨씬 도움이 될 것이다. 대학과 확원에서도 이론과 테크닉에만 치우지지 말고 이런 실질적인 교육과 훈련에 좀 더 투자를 해야 한다.
다시 한 번 강조하는 것은 ‘개발자‘의 역량 향상이다. 그 효과는 영구적이고 사기 증진에도 많은 도움이 된다. 제품의 설계 향상 같은 단기적인 이점은 그에 비해 훨씬 가치가 적다.
TDD 에 관심이 있는 사람이라면 BDD (Behavior Driven Development – Click Here) 도 한 번쯤 꼭 참고해보도록 하자. TDD 의 발전 형태로 볼 수 있는데, 무엇을 어떤 식으로 테스트해야할 지에 대한 좋은 가이드라인을 제시해준다. 개념을 확실히 인지하고 있다면 전용 툴 지원 없이 전통적인 Unit Test Framework 만으로도 BDD 를 활용할 수 있다.
단순 API 테스트라면 boundary value analysis (Click Here) 와 equivalence partitioning (Click Here) 정도는 확실히 알아두자. 이 둘을 조합하면 많은 경우에 있어 기계적으로 test case 들을 뽑아낼 수 있다. SE, SQA, 혹은 전문 테스터로서 역량을 원한다면 이곳 (Click Here) 도 좋은 레퍼런스가 될 것이다.
