청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법

파일럿 프로젝트와 Top-Down 방식의 리팩토링

sozu — Mon, 14 Feb 2011 09:00:00 +0900

프로젝트 초반, 그리고 설계

상위설계(High Level Design)는 일반적으로 프로젝트 초반에 작성됩니다. 상위설계는 해당 프로젝트의 결과물의 근간이 되기 때문에 매우 중요하며 크게 변하는 경우는 드뭅니다. 어디까지나 상위설계이기 때문이죠. 뜬구름 잡는 얘기일 수도 있기 때문에 기술적으로 아주 세세하게 알지 못해도 작성할수 있는 경우가 있습니다. 하지만 상세설계(Low Level Design)에 접어들게 되면 구체적으로 많은 선택을 해야합니다. 골치 아프죠.

많은 경우에 어느 수준까지 작성해야 할지 갈피를 못잡고 방황하다가 적당히 보고 수준의 문서를 작성하고 구현에 들어갑니다. 결국 구현 따로 상세설계 따로인 결과물이 탄생하게 됩니다.

유지보수와 스파게티 코드 양산

유지보수중 스파게티 코드를 양산하게 되는 경우중 하나는 소스코드만 가지고 문제 해결을 할수 밖에 없는 경우 입니다. 아마 대부분의 경우가 이러할꺼라 생각됩니다. 근본적으로 문제를 해결하고 싶지만 근본적인 원인을 찾는데 도움이 될수 있는 큰 그림을 볼 수 있는 단서가 유지보수 단계에까지 남아있는 경우가 드물죠. 결국 기존 소스를 분석하다 지쳐서 땜빵코드를 삽입할수 밖에 없는 경지에 이릅니다. 제가 아는 대부분의 개발자는 땜빵코드를 삽입하는 것에 대해 부정적이지만 어쩔수 없이 하는 경우가 많습니다. 물론 저를 포함해서..

파일럿 프로젝트로 시작하는 '동작하는' 프로젝트

앞에서도 말씀드렸지만 상세설계를 어느 수준까지 작성해야할지 고민되는 경우가 많습니다. 저는 이를 해결하기 위해 프로젝트 초반에 파일럿 프로젝트를 진행합니다. 어떤 레퍼런스를 쓰던 일단 원하는 결과물을 얻기 위해 이것 저것 시도해보며 최종적으로 해당 기능들을 간신히 수행하는(하지만 있을건 다있는) '동작하는' 소스코드를 만들어 냅니다. 그리고 이것을 통해 프로젝트를 본격적으로 시작할때부터 '동작하는' 소스코드를 가지고 시작할 수 있게 합니다. 그리고 현재 수준에서 껍데기(Front-End) 바로 아래부분(Top)부터 추상화(Abstraction)을 통한 인터페이스 추출(Interface Extraction) 작업을 시작합니다. 추출된 인터페이스를 정리하면 매우 간단한(Class가 몇개 안되는) Class Diagram과 Sequence Diagram을 그릴수 있습니다. 이것이 상세설계서의 0.01 버전이 될수 있겠습니다. 이를 바탕으로 리팩토링을 하게 되면 인터페이스 추출이 완료된 상위 클래스를 제외하고는 나머지는 뚱땡이 클래스가 되어있겠죠. 이제 시작입니다.

Top-Down으로 진행되는 리팩토링, 그리고 지속적인 설계

리팩토링을 Top-Down으로 하게 되면 소스코드의 리팩토링 단위가 커지게 되므로 보통은 추천하지 않습니다. 하지만 설계는 Top-Down으로 할수록 깔끔해집니다.(제 의견입니다.) 가장 상위(Top)부터 시작하여 단계적으로 하위(Bottom)까지 진행되는 인터페이스 추출은 리팩토링을 지속적으로 하도록 유도합니다. 그리고 리팩토링된 소스코드는 항상 '동작하는' 상태여야 합니다. 그리고 결과물인 소스코드와 UML 문서는 최소 1명의 팀원과 리뷰를 합니다. 반복하다보면 뚱땡이 클래스들이 점점 분리되여 계층적인 클래스 구조를 만들게 될겁니다. 고럼 다음과 같은 프로세스가 만들어 집니다.

주기는 짧을 수록 좋다

저는 위의 주기를 하루에 최소 한번 할수 있도록 개발 계획을 수립합니다. (작은 마일스톤으로 쪼개는 방법은 다음에 써보도록 하겠습니다.) 그나마 주기가 짧아야 리팩토링 단위와 정리해야할 UML 문서의 단위가 작아집니다.

결과적으로 얻을 수 있는건..

항상 '동작하는' 소스코드
항상 정확하게 현재 소스코드를 큰 그림으로 파악(Static and Dynamic!)할 수 있는 딸랑 2종류의 UML Diagram
새로운 기능 넣기 전에 UML Diagram 으로 검토하는 습관...
바쁜 이슈처리 상황에서 근본적으로 문제해결을 할 수 있는 여유..
객체지향적 설계 능력?ㅡㅡ;;

그런데 결국은 뭐라도 해봐야..뭐가 다른지 압니다.

우리 개발팀은 어디로 가고 있을까? (2010 NHN Deview 회고)

sozu — Tue, 14 Sep 2010 10:35:25 +0900

지난주에 현업과는 관련이 없어 보이는 NHN에서 주관하는 개발자 컨퍼런스에 참석하였습니다.

업무에 직접적인 관련이 없다보니 영감이 늦게 밀려드는가 봅니다. 이제서야 회고를 해봅니다. (발표 내용에 대한 후기는 없답니다.ㅋ)

NHN은 어디로 가고 있나?

Deview가 끝나고 난 느낌은 "NHN은 이렇게 잘 하고 있구나" 정도였습니다. 솔직히 그 이상도 이하도 아니었습니다.

후기 경품이 탐이 났지만 딱히 쓸말이 없었습니다. 싸이트 가면 동영상이 모두 공개 되어있는데 후기를 쓰자니 거시기 했습니다.

그러던중 문득 이런 생각이 들었습니다. 왜 키노트 스피치를 좀 지루할 정도로 구구절절히 길게 하였을까?

제가 추측한 이유는 NHN이 가고 있는 목표에 대해서 진심으로 구구절절히 공유하고 싶었기 때문입니다.

키노트 스피치가 끝난 후에 지인중 한분이 그러더군요. "그냥 애자일 한다고 하면 되지 않나?"

분명 NHN에서 하고 있는 활동들은 애자일스러웠습니다. 하지만 애자일이 NHN의 목표가 아니기 때문에 궂이 애자일을 한다고 할 필요가 없었던 것이라고 생각합니다.

이러한 관점으로 Deview의 강연들을 생각해보니 NHN이 가고자 하는 곳이 어디인지가 보이더군요.^^

그곳이 어디인지 제가 자세히 기술할수는 없지만 분명한건 NHN 내부 개발자만을 위한 천국은 아닐겁니다.

궂이 애자일 조직이라고 표현할 필요가 없다.

가끔 애자일을 짝 프로그래밍이나 테스트 주도개발, 스크럼등의 Best Practice로 여기시는 분들이 많습니다.

혹은 갓 입사한 회사나 팀에서 애자일을 모른다고, 애자일 팀이 아니라고 실망하는 신입 개발자분들도 있습니다.

수단과 목표가 약간 혼동되는 부분이라고 생각합니다. 애자일도 목표는 아니라고 생각합니다.

꼭 개발조직에 애자일이나 RUP, Waterfall, CMMI 등의 정체성이 명시적으로 존재해야 할까요? 그런건 정치판에서도 지겨운데...

우리가 원하는건 애자일 조직이 아니라 행복하게 개발할 수 있는 매우 효율적인 개발 조직일겁니다. (정확히 말하면 제가 원하는 것입니다^^)

물론 조직에 맞는 애자일스런 Practice를 만들어나가면 좀더 빠르게 그런 조직을 만들수 있을것입니다.

제가 말하고 싶은건 뭘 하면 애자일이고 안하면 애자일이 아니다 이런게 중요한게 아니다라는 것입니다.^^;;

개인적으로 '애자일'이란 표현보다 '실용적인'이란 표현이 더 좋습니다.ㅋ

이런 점에서 NHN의 발표에서 '애자일'이란 용어를 쓰지 않은 것은 현명한 선택이었다고 생각합니다.

기대되는 NHN의 행보

얼마전까지만 해도 NHN은 뒤뚱거리는 거대한 한국의 포털 기업으로만 생각했었습니다. 개발에 열정을 가졌던 친구가 NHN의 신입사원으로 입사한 후에 개발의 열정이 식어버린... 그냥 포털 대기업으로만 생각했었습니다.

하지만 Deview를 보면서 생각이 조금 바뀌었습니다. 열악한 한국의 개발 환경을 불평, 불만만 하는 사람들이 변화될 수 있도록 기여하는 기업이 되고 있다고 생각합니다. (우리 회사도 그런 기업이 될겁니다!^^)

스스로 바뀌어야 환경도 바뀝니다.^^

이상 짧은 회고였습니다;... 회고라기 보다는 주저리주저리 떠든;;ㅋ

NHN Deview 2010 동영상 다시 보기 및 자료 : http://deview.naver.com/2010/courses.nhn

창의적인 아이디어는 어디에서 오는가?

sozu — Sun, 12 Sep 2010 22:39:13 +0900

얼마전에 "창의적인 아이디어는 어디에서 오는가?" 라는 주제로 강연을 들은적이 있습니다.

강연자분의 결론은 다음과 같았습니다.

창의적인 아이디어는 새로운 것이 아니라 기존에 있던 것을 새롭게 보는 것이다.

창의적인 아이디어를 얻기 위해서는 내가 보고 경험한 것들을 새롭게 볼줄 알아야 하며,

다른 사람의 말과 행동을 새롭게 볼줄 알아야 한다.

강연을 듣고 저는 다음과 같은 생각을 했습니다.

항상 주위의 모든것에 호기심을 갖고 관찰하여 필요한 경우 내것으로 만들수 있어야 창조적인 인재가 될수 있다

결국 매우 상투적인(cliche) 결론이었습니다. 하지만 다시 생각해보니 개발자들에게 매우 필요한 능력일것 같다는 생각을 했습니다.

창의적인 개발자는 어떤 능력이 필요한가?

저는 다른 개발자들이 만들어 놓은 결과물을 분석하고 이해할줄 알며, 가져다 사용할 수도 있고 필요한 경우 개선될 수 있도록 기여할 수 있는 개발자가 창의적인 개발자라고 생각합니다. 혼자 모든 것을 만들어 내는 것 보다는 다수의 사람이 같이 만들어 내는 것이 더 창의적인 결과물이 될수 있기 때문입니다.

세계적인 오픈소스에 기여하지 않더라도 같은 회사내, 같은 연구소내, 같은 팀내의 다른 개발자들의 결과물들이 같이 공유하며 개선되고 성장 할 수 있다면 그 조직은 창의적인 개발 조직이라고 할수 있을 것입니다.

이러한 것들이 가능하려면 조직 내에 소스코드 오픈 문화, 개발자간의 신뢰 문화등이 밑바닥에 깔려 있어야 할 것입니다.

어렵지만 할 수 있지 않을까요? 전 애자일이 창조적인 조직을 위한 은탄환이라고 생각하지 않습니다.

하지만 시도해볼만한 것임은 확실하다고 생각합니다.^^

Two Heads Are Better Than One.

UML을 이용한 점진적 설계와 구현 (짧은 경험담)

sozu — Wed, 01 Sep 2010 08:12:55 +0900

현재 제가 속한 팀은 아직 애자일 프랙티스를 전파하기에는 이른 시기입니다.

고민 끝에 (사실 실제 고민은 몇초?;) 점진적 설계와 구현을 해보는것은 어떻겠냐고 같이 일하시는 윗분께 건의했습니다.

길지않은 토론 끝에 UML로 설계를 하고 이터레이션은 고정시키지 않는다는 전제하에 점진적 설계와 구현을 해보기로 했습니다.

제가 정한 한 이터레이션에서 해야할 일들은 다음과 같았습니다.

해당 이터레이션에서의 요구사항을 Use-case Diagram으로 작성 및 리뷰 (mandatory)
Activity Diagram 및 Collaboration Diagram은 개인적으로 작성 (optional)
섬광탄 구현 (optional)
Class Diagram 및 Sequence Diagram 작성 및 리뷰 (mandatory)
설계에 맞게 구현 (mandatory)
구현에 대한 짧은 회고 및 피드백으로 설계 수정후 구현 수정 - 반복 (mandatory)
데모 후 다음 이터레이션 (mandatory)

결과물은?

프로젝트 기한 : 예상보다 1주일 정도 먼저 끝났음
결과 바이너리 데모 : 원했던 기능 완료, 어느정도 안정화 됨
설계 문서 : Use-case Diagram 1장, Class Diagram 3장, Sequence Diagram 3장 - 소스코드와 99% 일치

회고

기존의 관행을 깨보았음 (사실 작은 프로젝트라 큰 의미는 없음)
UML 설계를 통한 설계 리뷰 및 공유는 정말 괜찮았음
이터레이션을 고정시키는 것에 대해서 반감이 있는 경우에는 살짝 빼도 무리가 없어보임
기존의 관행과의 협상에서 줄건 주고 얻어올건 얻어와야 함 (이렇게 안하면 애자일이 아니다 라는 고정관념을 버려야함
섬광탄 구현이 UML 설계에 많은 도움이 되었음

결론 : 나는야 행복한 개발자~

스크럼이 정말 도입하기 쉬운 애자일 방법 중에 하나일까?

sozu — Thu, 19 Aug 2010 08:22:04 +0900

쉬워 보이는 스크럼

작은 개발팀의 생산성과 품질에 대해서 고민해 본적이 있으신 분들이 스크럼에 대한 이야기를 들으면 적지 않은 분들이 상당한 영감을 받습니다. 그리고 바로 팀에 적용 할 수 있을 것 같은 뽐뿌를 받곤 하죠. 그중에 저도 포함되구요.

하지만 데일리 미팅이 그나마 만만할 뿐 프로덕트 백로그, 스프린트 미팅이나 회고, 백로그 추정등은 그렇게 녹록하지 않았습니다.

베스트 프랙티스 도입보다 더 중요한건 애자일 팀 만들기

스크럼의 구성요소들을 하나하나 뜯어보면 애자일 정신이 가득한 프랙티스들이 주류를 이룹니다.

즉, 애자일 개발팀이 아닌 팀에서 스크럼을 도입하려다 보면 데일리 미팅 정도야 하겠지만, 하나하나 적용시키다 보면 난관에 부딪힐때가 많습니다. 더 중요한것은 이러한 난관에 부딪힐때 해당 고민들을 팀원들과 풀려고 하는 것이 아니라 외부 모임(자신만의 세계, 개발자 친구나 개발자 포럼등)에서 풀려고 하는 것이죠. 즉, 적용하려는 리더 조차 애자일스럽지 못한 것입니다.

제 생각에는 갑작스럽게 스크럼을 바로 도입하는 것보다 애자일 개발팀이 되기 위해 하나씩 바꿔나가는 것이 좋다고 생각합니다.

애자일 개발팀으로써 살짝 자리를 잡은 뒤에 스크럼을 도입해보면 더욱 효과적일것 같습니다.

아래의 프로세스들이 팀에 살짝 정착되고 나서 스크럼을 도입한다면 더욱 효과적일것 같습니다.

지속적인 피드백을 주고 받는 설계와 구현
사용자 스토리를 이용한 요구사항 정리
업무 추정을 담당자에게 위임
빌드 자동화 / 일일 빌드

LG, 삼성이 뛰어 넘어야 하는 심히 객체지향적인 오픈플래폼, 안드로이드

sozu — Tue, 13 Jul 2010 22:58:43 +0900

심히 객체지향적인 오픈플래폼, 안드로이드

안드로이드의 소스는 심히 객체지향적으로 구현되어 있습니다. 우선 애플리케이션을 구현하는 언어가 자바로 되어 있습니다.

또한 프로세스간 통신을 지원하는 Binder, 멀티미디어 프레임웍(OpenCore and StageFright), 서비스 및 서비스 프로바이더, 오디오/디스플레이 서브 시스템(AudioFlinger, SurfaceFlinger) 등등 대부분의 코드는 매우 객체지향적인 C++로 구현되어 있습니다. OpenCore의 경우 너무 객체지향적이어서 안드로이드 2.2 Froyo에서는 좀더 간단한(?) 구조의 StageFright가 정식 릴리즈 되기도 했습니다. (GingerBread에서는 OpenCore가 없어진다는 소문과 함께..)

Why are You Still Using C?

성능이 중요한 Embedded System에서 C언어를 사용하는 것은 일반적인 관례였습니다. 우리는 C++의 Polymorphism, Virtual Table 등으로 인해 성능이 저하될 수 있다는 편견과 컴파일러에 대한 불신등으로 인해 하드웨어의 성능이 크게 개선되었음에도 불구하고 C언어를 계속 사용하고 있었습니다. 꼭 C언어가 나쁜것은 아니지만 호환성, 유지보수성 또는 확장성 측면에서 어려운 점들이 있었던것은 사실이었습니다.

객체지향과 안드로이드 그리고 휴대폰 제조사

객체지향적으로 구현한다고 해서 호환성, 확장성등이 좋아지진 않습니다. 하지만 객체지향의 몇가지 원칙만 잘 지킨다면 좀 더 개선된 결과를 얻을 수 있습니다. 안드로이드는 객체지향을 통해 오픈플래폼으로써 지녀야할 호환성 및 확장성을 구현하였습니다. 그리고 구글은 당연히 휴대폰 제조사들도 객체지향적으로 접근할 것이라 생각했나 봅니다. 하지만 휴대폰 제조사의 개발 패러다임은 아직 많은 부분에서 객체지향적이지 못한 부분들이 있었습니다. 그리고 안드로이드의 소스를 수정(modification)하였습니다. 결국 애플리케이션의 호환성, 플래폼의 안정성 등에서 적지않은 문제가 발생했습니다.

Open-Close Principle

Robert C. Martin이 제안한 객체지향의 원칙중 하나인 Open-Close Principle의 정의는 다음과 같습니다.

SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION,
BUT CLOSED FOR MODIFICATION.

휴대폰 제조사는 자신들만의 기능(feature)을 안드로이드의 소스에 확장(extension)해야 합니다. 구글에서 릴리즈한 소스를 수정(modification)해서는 안됩니다. (최소화 해야합니다.) 그래야 구글과 휴대폰 제조사가 윈-윈할 수 있습니다. 그리고 구글이 원하는 OTA(On-The-Air)도 구현할 수 있습니다.

구글은 결국 폐쇄적으로 갈것인가?

안드로이드 2.3 GingerBread에서는 구글이 휴대폰 제조사의 Built-in GUI 탑제를 제한하겠다는 소문이 돌고 있습니다. 하지만 그것이 정답은 아니라는 것을 구글도 알 것입니다. 오픈플래폼은 구글 혼자서 만들수 있는 것이 아니라는 것도 알 것입니다.

LG전자, 삼성전자가 그들의 개발 패러다임을 뛰어 넘는다면, 그들은 폐쇄적으로 갈 이유가 없습니다. (정치적인 이슈는 제외...)

개인적으로 LG전자가 뛰어넘었으면 좋겠습니다.^--------------------^

리더쉽은 자신이 선택하는 것 (Agile Gathering #2 후기)

sozu — Wed, 07 Jul 2010 23:00:02 +0900

오늘 가산에 있는 LG전자 MC연구소에서 Agile Gathering이라는 제목으로 세미나가 있었습니다.

여차저차 허락을 받고 점심도 안먹고 가산으로 넘어갔습니다.

리더쉽은 자신이 선택하는 것

첫번째 시간은 애자일 컨설팅의 김창준 대표님이 애자일 적용(혹은 반대)를 위한 조직에서의 리더쉽에 대한 내용으로 워크샾을 진행하셨습니다. 워크샾은 시뮬레이션 형태로 진행되었습니다. 참석자들중 몇분은 관찰자의 역할을 맡고 나머지는 한 회사의 구성원(사장,이사,팀장,사원)이 되어 시장(market)의 요구사항에 맞는 시제품을 개발하는 것이었습니다. 처음에는 어색했지만 나중에는 완전히 몰입해서 정말 제품을 만들어야 한다는 중압감이 생겼습니다+_+!

약 1시간 넘게 시뮬레이션을 진행한뒤에 피쉬보울 방법으로 회고를 진행하였습니다. 그중에서 가장 인상에 남았던 것은 김대표님이 말씀해주신 매니저와 리더의 다른점, 리더쉽의 본질, 리더쉽의 4가지 유형이었습니다.

매니저는 조직에서 정할 수 있지만 리더는 정해줄 수 없다. 리더는 지휘 여하를 막론(경영진에서 신입사원에 이르기까지)하고 누구나 될 수 있다. 단지 우리는 리더가 되는 것(혹은 리더쉽을 발휘하는 것)을 선택하는 것이다. 단지 안할뿐..

리더쉽은 모든 사람이 창의적으로 문제해결에 기여할 수 있게 환경을 개선하는 것이다. 이에는 4개지 유형이 있다.

motivation leadership, organization leadership, innovation-idea leadership, jig leadership...

애자일에 관심있다고 하는 사람들이 모여서 회사 제품 개발 시뮬레이션을 해도 잘 안되기는 마찬가지였습니다.

중요한건 자신이 현재 상황에서 리더쉽을 발휘할 것인지 아닌지를 선택하는 것입니다.

(다들 가만히 있는데 먼저 나서서 행동을 취하는 것도 리더쉽 입니다. (jig leadership))

짝프로그래밍, 잘하면 고효율~ 못하면 가문의 역적

두번째 시간은 LG CNS의 채수원 과장님이 짝프로그래밍에 대해서 발표해주셨습니다. driver-navigator 라는 패턴을 이용하여 짝프로그래밍 도입하는 것에 대해서 말씀해 주셨습니다. 물론 짝프로그래밍의 장단점, 사례도 말씀해 주셨습니다.

개인적으로 짝프로그래밍을 좋아하지만 사용가능한 분야 혹은 짝이 한정되어있다고 생각합니다.

정말 필요한 경우에, 고효율이 예상되는 경우에만 사용하는 것이 바람직하다고 생각합니다.

스크럼 vs 칸반

세번째 시간은 LG전자의 MC연구소에 계시는 분이(이름이 기억..안..나..요;;..ㅠㅠ) 스크럼과 칸반에 대해서 아주 이해하기 쉽게 설명해 주셨습니다. 칸반은 아주 심플하게 다음의 3가지를 만족하면 됩니다.

Visual Card : 비쥬얼은 필수!
Limit Work-In-Progress : 한 스텝에서 동시에 진행될 수 있는 백로그를 제한
Measure Lead-time : 지속적으로 리드타임을 측정하여 최소가 될수 있도록 함

특히 칸반은 수시로 인터럽트(QA, 유지보수등)가 발생하는 개발팀에서 유용하게 사용되어 어질수 있다고 생각했습니다.

즉, 스크럼과 칸반을 개발팀의 업무 특성에 따라 적절히 조합해서 사용한다면 좋을 것 같습니다.

회고

회고에 참석하지 못했습니다.ㅠㅠ 반성중..

김창준님이 진행하신 시뮬레이션에 대해서 좀더 자세한 설명이 있었으면 했습니다. (왜 손을 잡는지, 감옥의 역할은 무엇인지 등..)

색다른 경험이었고 즐거웠습니다. 근데 뭘 했다고 이렇게 졸립죠...ㅠㅠ;;

코드리뷰는 진짜로 해야 효과가 있다.

sozu — Mon, 05 Jul 2010 22:12:50 +0900

새로운 개발팀

이전 개발팀에서 이메일을 이용한 코드리뷰를 시행한 적이 있습니다. (2010/02/26 - [Programming] - 이메일로 코드 리뷰 하기)

혹시나 해서 요즘에도 잘 되고 있나 여쭤보았지만 아직은 형식적인 단계라는 답변을 들었습니다.

이직을 하고 나서 저는 변화된 환경에 적응하기 위해 애자일 프랙티스를 언급하거나 제안하지 않았습니다.

단지, 이전 업무에 대한 소개를 할 때 개발 프로세스 개선 활동에 대해 짧게 소개만 했습니다.

(다행히도 입사 4개월 만에 애자일에 관심을 보이시는 관리자 분이 계십니다!^^~~ 이번에 애자일 세미나를 같이 들으러 감~)

프로세스에 녹아든 코드리뷰

경력으로 입사하였기에 빠르게 프로젝트에 투입되었습니다. 현재 개발팀의 소스코드는 svn으로 관리됩니다. (git로 넘어가는 추세..)

그런데 특이했던 점이, 자신의 home directory에 check-out된 소스에서 직접 작업하지 않고 export된 다른 복사본(working source)에서 작업을 하는 것이었습니다. 즉, commit과 update 절차는 다음과 같이 진행되었습니다.

commit 절차 : 복사본에서 작업 => svn 소스와 diff를 통한 merge => svn commit
update 절차 : svn update => 복사본 소스와 diff를 통한 merge => 복사본에서 검증

즉, 개인 작업물에 대해서 철저하게 분리하는 형태 입니다. 어찌보면 번거로워 보일수 있는 소스관리 프로세스 였습니다.

그런데, 작업이 진행되면 될수록 소스코드가 잘 정리되었으며, 믿음직하고 든든해 졌습니다.

그것은 merge 과정에서 자신의 코드와 타인의 코드에 대해서 source code inspection이 암시적으로 행해졌기 때문입니다.

복사본에서 작업하기 때문에 개인용 테스트 로그가 svn 소스 트리에 등록되지 않은 것도 한 몫 했습니다.

프로세스(혹은 도구) 개선이 정답?

김창준님이 한국 developerWorks의 dW Column에 기고하신 "소프트웨어 관리자의 개선 우선순위"라는 글을 보면 다음과 같은 재미있는 연구 결과를볼 수 있습니다.

쉽게 말해, 도구 부분에서 상당한 개선을 이뤄내면 비용적으로 세 배 정도 개선을 얻을 수 있다. 이에 비해 관리 부분에서 상당한 개선을 이뤄내면 비용적으로 64배 정도의 개선을 얻을 수 있다는 뜻이다.

관리자들이 선호하는 개선 노력은 어떤 순서일까? 정확히 역순이다. 일단 도구 개선부터 시작한다. 자기 자신(관리)을 바꾸는 것은 맨 나중이다. 그러나 실제 효과로 보면 우선순위는 관리가 맨 처음에 온다

제 경험을 보면 마치 프로세스(혹은 도구) 덕분에 큰 효과를 본것 처럼 보입니다. 하지만 근본적인 원인은 따로 있었습니다.

내 코드가 아닌 우리 팀의 코드

개발과정에서 개발팀의 관리자 분(개발에도 참여하심)과 개발 리더분은 지속적으로 소스코드를 리뷰하고 있었습니다.

라인단위로 의미없거나 논리적이지 못한 코드가 있다면 명확하게 해명을 해야 svn 소스 트리에 남을수 있었습니다.

로직이 불분명하다면 버그가 생길만한 케이스를 분석하거나 테스트 케이스를 만들어서 알려주십니다.

우리에게 누가 문제를 해결했고 누구의 소스에서 버그가 있었다는 것은 중요하지 않았습니다.

중요한건 우리 팀의 코드가 품질이 높아야 한다는 것이지요. (물론 납기일을 만족하면서...)

코드리뷰는 진짜로 해야 효과가 있는 것 같습니다.

막사이의 추억

sozu — Mon, 26 Apr 2010 21:39:52 +0900

지난 금요일에 연구소 춘계 산행대회가 있었습니다. 산행지는 회사 바로 앞에 있는 청계산이었죠.

산행 코스는 의외로 빡쌨습니다. 거의 4시간 코스로 오르락 내리락, 높은 경사로가 수시로 우리를 괴롭혔습니다.

매봉까지 오르지 않은 것을 다행으로 여기며~ 옥녀봉에 도착했을때~ 막걸리 아저씨가 보이더군요.

우연찮게 한 모금 얻어마셨는데 무척이나 맛있었습니다. 먹고 나서 들어보니 맛있는 이유가 있었습니다.

출처를 알수 없는 저 막걸리에는 사카린이 대량 첨가되어있다고 합니다.

사카린 [saccharin]

수크로스보다 훨씬 단맛이 나는 합성 감미료이며 음료수, 사탕, 의약품, 치약 등에 사용된다.

수용액은 수크로스의 500배라는 경이적인 단맛을 지녀, 떨릴정도의 자극을 가진 뒷맛을 가졌다.

정말 경이적으로 단 첨가물이네요..ㅎㅎ

그러던 중 막사이에 대한 추억들이 언급되기 시작했습니다~

막걸리 + 사이다 (2 : 1 혼합) = 막사이

제가 혼합주류(일명 폭탄주, 좋게 말해서 칵테일)를 좋아하는 편인데~ 막사이는 처음 들어봤습니다.

그래서 산행 뒤 점심시간에 고기를 앞에 놓자마자 막사이를 말아서 먹었는게 그 맛이 일품이더군요.

소사 (소주 + 사이다 (9 : 1 혼합)) 이후로 사이다 들어간 폭탄주는 처음 마셔봅니다.

당분간 이 맛을 잊지 못하여 자주 찾게 될것 같네요.

같이 한잔 하실분?

Android SurfaceView와 SurfaceFlinger 쫌 들여다 보기

sozu — Fri, 19 Mar 2010 19:12:01 +0900

SurfaceView의 역할

Android Application에서 View의 내용은 GDI Thread를 통해 Surface에 그려지게 됩니다.

만약 View에 동영상 또는 카메라 프리뷰와 같이 그려지는 양이 매우 많거나 빠른 화면 변화를 원한다면 SurfaceView를 사용해야 합니다. SurfaceView의 내용은 GDI Thread를 통해서 Surface에 그려지지 않고 다른 Thread를 통해서 그려지기 때문입니다.

SurfaceView는 아래 그림과 같이 Window의 아래쪽에 위치하며, Window를 뚫어서(punched) 자신이 보여지게끔 합니다.

단, 해당 Window 위에 다른 View가 있는 경우 블렌딩(blended)이 되어 보여지게 됩니다.

동영상 재생과 SurfaceView

아래 그림은 동영상이 재생되는 SurfaceView를 묘사한 것입니다.

동영상 재생을 담당하는 PVPlayer (Packet Video Player)에서 SurfaceView에 연결된 Surface에 동영상을 그립니다.

그려진 Surface와 다른 내용(ex. GUI)을 담고 있는 View의 Surface들을 모두 합쳐서(composition) 하나의 화면으로 FrameBuffer에 쓰는 역활을 하는 것이 SurfaceFlinger service입니다. SurfaceFlinger service는 연산량이 많기 때문에 독립적인 process로 존재합니다. 동영상의 화면이 크고 그 위에 블랜딩 되어야 하는 GUI가 많은 경우 오버레이를 위한 하드웨어 가속기를 사용하기도 합니다.