블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (41)
Agile Experience (22)
My Family (0)
Life Style (7)
Programming (8)
Android (2)
Total
Today
Yesterday

달력

« » 2024.3
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

최근에 올라온 글

최근에 달린 댓글

꿈? 그게 어떻게 니 꿈이야? 움직이질 않는데.
그건 별이지. 하늘에 떠있는 .. 가질수도 없는 시도조차 못하는 쳐다만 봐야하는 별
누가 지금 황당무계 별나라 얘기 하제?
니가 뭔가를 해야될 꺼 아냐. 조금이라도 부딪히고 애를 쓰고 하다못해 계획이라도 세워봐야 
거기에 네 냄새든 색깔이든 발라지는 거 아냐. 
그래야 니 꿈이다 말할 수 있는 거지.
아무거나 갇다붙이면 다 니 꿈이야? 
그렇게 쉬운거면 의사, 박사, 변호사 판사 몽땅 가져다 니 꿈하지,그래?
꿈을 이루라는 소리가 아냐. 꾸기라도 해보라는 거야.
- MBC드라마 베토벤바이러스 중에서

제 꿈은 장시간의 러닝타임에도 장애(혹은 버그) 없는 소프트웨어를 개발하는 팀을 구축하는 것입니다.
그리고 제 꿈이 머나먼 별이 아니라는 것을 증명하기 위해 매일 부딪히고 애를 쓰고 있습니다.
이 꿈이 언제 어디에서 이루어 질지는 모르겠습니다. 
하지만 중요한 것은 그 꿈을 이루기 위해 제 혼신의 노력을 다하고 있다는 것이겠죠.
당신은 어떤 꿈을 꾸고 계십니까? 혹여나 그 꿈이 머나먼 별 이야기는 아닐런지요... 같이 공유했으면 좋겠네요~^^

'Life Style' 카테고리의 다른 글

리액션 부탁드립니다.  (8) 2010.02.24
개발자와 다이어트  (6) 2009.12.26
책은 깊이 읽어야 한다. 그리고 기록해야 한다.  (8) 2009.12.23
Posted by 윤청하
, |
낡은 코드(legacy code)에 관심을 갖다

저는 최근에 낡은 코드에 관심을 갖게 되었습니다. 낡은 코드에서 효과적으로 일하기 위해서는 테스트를 만드는 것이 가장 먼저 해야 할 일입니다. 테스트가 없다면 어떤 코드도 쉽게 수정하기 어려울 것입니다. 그런데 막상 테스트를 만들려고 해보니 막막했습니다. 어디서 부터 테스트 해야 할까?

낡은 코드는 큰 것부터 테스트 하자

처음에는 막막했습니다. 뭐부터 해야할 지.. 함수단위, 라이브러리단위로 테스트 하자니 그 양이 엄청 났습니다. 또한 테스트 하기 쉽게 작성된 코드들이 아니기 때문에 더욱 어려웠습니다. 저는 블로그를 통해서 조언을 얻었습니다.(ParkPD님, 박형근님 감사합니다.) 그 첫번째가 "큰 것 부터 하라"였습니다. 그래서 먼저시스템 테스트를 만들기로 하였습니다.
다른 팀원들이 테스트를 쉽게 만들수 있게 도와주자

저는 낡은 시스템의 테스트 케이스를 검토하고 아래 그림과 같은 상상을 했습니다. 저희 회사 제품의 시스템 테스트 케이스는 시간적인 순서를 갖는 제어 메시지를 주고 받는 형태로 작성 될 수 있습니다. 저는 이것을 시나리오라고 하고 제어 메시지에 내용은 제어정보라고 정의하였습니다. 제어정보와 시나리오를 처리하는 것은 mock 클라이언트라고 정의하였습니다.

내가 상상한 시스템 테스트

개발자 혹은 테스터는 간단한 스크립트언어로 시나리오와 제어정보를 작성합니다. 독립적으로 작성된 시나리오와 제어정보를 조합하여 많은 테스트 케이스를 만들수 있습니다. 이런 것을 팀원들에게 제공한다면 테스트 케이스 작성에 큰 도움이 될 것 같았습니다. (저희 팀에는 유지보수 중인 낡은 시스템이 많습니다.^^;;)

의존성 주입 (Dependency Injection)

의존성 주입이란 객체간의 의존성을 미리 코드에 정의하는 것이 아니라 실행 시간에 주입하는 것을 의미합니다. 의존성 주입은 제어 역전(Inversion of Control)이라고도 합니다. 즉, 제어를 역전시킴으로써 바이너리를 교체하지 않고 제어를 가능하게 하는 것입니다. 이 개념은 자바의 Spring이라는 프레임워크에서 핵심 기능으로 사용되고 있습니다.
C++에서 의존성 주입을 하기 위해서는 작성된 라이브러리의 API를 동적으로 호출하고 파라미터를 실행시간에 입력하는 코드(wrapper code)를 생성해야 합니다. 즉, 이 코드(wrapper code)는 텍스트 파일에 기술된 100이라는 문자열을 정수형 변수에 넣을 수 있어야 합니다.

시스템 테스트 프레임워크

저는 절친 팀원 한분과 시스템 테스트를 위한 mock 클라이언트 작성을 도와주는 프레임워크를 만들기로 하였습니다. 물론 팀장님이 인가해주셨습니다. (매출과 관계없는 일을 싫어하는 회사 특성상 이례적인 경우일수 있습니다.) 위의 그림을 바탕으로 여러가지 시도를 해봤습니다.
  • 시도1) 시나리오 및 제어정보 스크립트 인터프리터 + 의존성 주입용 코드 생성기 + 스크립트 생성기
    시나리오와 제어정보 스크립트 언어를 정의하고 Lex와 Yacc를 이용하여 인터프리터를 만들었습니다. 의존성 주입을 위해 gccxml을 이용하여 API를 XML로 만들고 그것을 분석하여 코드 생성기를 만들었습니다. 스크립트 작성을 용이하게 할수 있도록 도와주는 스크립트 생성기도 작성하였습니다.
    문제는 의존성 주입용 코드 생성기였습니다. 생각보다 예외 상황이 많았습니다. 그리고 우리가 정의한 스크립트 언어는 점점 복잡해졌습니다. 패스~

  • 시도2) Python + Swig
    반성합니다. 시도1을 할때 충분히 조사하지 못했습니다.
    Swig는 Python과 C++을 연결시켜주는 코드 생성 라이브러리입니다. 매우 훌륭합니다.
    그러나, Python에서 API를 호출하는 것은 쉬웠지만 거꾸로 이벤트를 알려줄때 C++의 데이터가 Python 데이터로 맵핑 되는 작업이 매우 난해했습니다. 패스~

  • 시도3) 시나리오 작성용 인터페이스 및 시나리오 실행 환경 + 의존성 주입 라이브러리
    욕심을 버렸습니다. 시나리오는 C++로 작성하기로 하였습니다. 시나리오간에 의존성을 줄이고 이벤트를 알려줄 수 있는 인터페이스를 정의하였습니다. 해당 인터페이스를 구현하여(shared object or DLL) 시스템 프레임워크 월드에 주입하면 자동으로 해당 시나리오가 실행되도록 하였습니다. 제어정보와 시나리오 정보는 의존성 주입 라이브러리(Autumn Framework)를 사용하였습니다. 전체적으로 매우 심플하고 다양한 시나리오(기능 시험, 성능시험 등)를 XML로 정의할 수 있게 되었습니다. 콜!

    "시도3"의 전체 구성 그림

현재 저희는 시나리오 인터페이스를 구현하여 여러가지 테스트 케이스를 쌓고 있습니다^---^ 저희가 사용하는 인터페이스는 아래와 같습니다. 매우 간단합니다. 이 인터페이스를 구현하고 XML을 정의하면 자동으로 테스트 됩니다.
이제 남은 숙제는 지속적 통합을 위한 서버 구축(CI)입니다. C++과 리눅스 환경에서 효과적인 CI 서버 구축을 위한 방법을 알고 계신분은 조언부탁드립니다.^^ 감사합니다.

'Programming' 카테고리의 다른 글

이메일로 코드 리뷰 하기  (12) 2010.02.26
CASE STUDY : 의존성을 역전 시키자  (10) 2009.12.02
Broken Window Theory and Software  (4) 2009.11.26
Posted by 윤청하
, |

개발자와 다이어트

Life Style / 2009. 12. 26. 00:47
루저 그리고 90kg

전 루저 입니다. 키가 180이 안되죠ㅋㅋ 그런데 제가 학생일 때 몸무개가 90kg까지 올라간적이 있었습니다.
제가 대학교 신입생때 몸무개는 65kg이었습니다. 사실 제가 살찐 돼지였었다는 것을 그때 당시에는 몰랐습니다. 지금에서야 그때 사진을 보고 완전 뚱돼지였구나라고 회상하며 웃고 있습니다.ㅋㅋ

저 B형입니다.^----^ 비만이 많다네요..ㅋㅋ

각종 운동.. 그러나

살찐 돼지였던 것을 자각하지는 못했지만 살을 빼고자 하는 노력은 수없이 했었습니다. 살짝 쪘다고 생각했기 때문이죠. 학생일때는 검도 1년 반, 헬스 2년, 마라톤(10km, 하프) 참가, 농구 등등 을 했고, 회사에 입사한 후에는 수영 1년, 스쿼시 1년, 헬스 1년을 했습니다. 하지만 먹는 건 줄이지 못했습니다. 먹어야 공부도 하고 밤새서 개발도 하니까요..ㅋㅋ 당연히 술도 줄이지 못했습니다.
운동을 열심히 할때에는 살이 빠지다가도 다시 돌아오고~ 또 빠졌다가 다시 돌아오고.. 악순환의 연속..

4주간의 군사 훈련

병특 2년차에 4주 군사훈련을 논산으로 가게되었습니다. 자연히 간식먹기, 음주, 야식은 없었으며, 매일 걷고 움직였습니다. 살이 쭈욱 빠진 상태로 퇴소를 하게 되었고 얼마 안지나 와이프를 만나 연애 8개월 만에 결혼했습니다. 살이 빠진게 한몫했죠..ㅋㅋ 잼있는건 이때 빠진 살이 얼마간지속적으로 유지되었었다는 것입니다.

결혼 생활 그리고 소식(小食) 다이어트

결혼하고 1년뒤에 와이프가 임신하고 지윤이가 태어나면서 제 살은 다시 붙기 시작했습니다. 체질은 버릴수 없는 것 같습니다. 그러던중 MBC스페셜에서 소식(小食)에 관한 내용을 보았습니다. 그리고 무작정 따라 했습니다.
  • 한끼에 500kcal로 제한했습니다. 밥을 3/4공기만 먹었습니다.
  • 꼭꼭 씹어먹었습니다. 15번 이상 씹었습니다. 오래걸렸습니다.
  • 국에 말아 먹지 않았습니다. 씹지 않고 넘길수 있기 때문입니다.
  • 찌개는 국물을 먹지 않았습니다. 짜게 먹으면 칼로리가 올라가기 때문입니다.
  • 마트에서 과자등의 간식은 구매조차 하지 않았습니다.
  • 술도 안먹으려고 노력했습니다.
  • 결정적으로 따로 운동한건 없습니다. 지윤이 때문에 할 시간이 없었습니다.
그런데 살이 너무 쉽게 빠졌습니다. 5kg이 순식간에 빠졌습니다. 신기했습니다. 운동해서 뺄려면 정말 힘들었는데.. 먹는게 이렇게 큰 작용을 할지 몰랐습니다.
그러면 왜 소식을 하면 살이 찌지 않을까? 소식은 적은 식사량을 여러 번에 나누어 먹기 때문에 소화흡수가 잘되고, 규칙적으로 먹기 때문에 체내에 지방을 저장하지 않고 분해하는 작용이 활발해 비만을 예방하게 된다고 할 수 있다. 반대로 같은 양이라도 한 번에 먹는 폭식이나 아침이나 점심을 거르는 절식, 원푸드 등의 다이어트는 오히려 비만을 부르기 쉽다. 불규칙한 식사는 인체의 자기방어 기능을 자극해 같은 양이나 적은 양을 먹더라도 이를 분해하지 않고 저장하려는 성질을 나타내기 때문이다.
같이 소식(小食) 해 보아요^----^
Posted by 윤청하
, |
많이 읽을 수록 좋다?

전 얼마전까지만 해도 책은 많이 읽을 수록 좋다고 생각했습니다. 반년전 회사에서 10분거리의 집에서 1시간 10분거리의 집으로 이사하면서 하루에 책을 읽는 시간이 2~3배 증가하였습니다. 보통 하루에 2 ~ 3시간을 독서에 투자하고 있습니다. 첫 몇달간은 미친듯이 빠른 속도로 책을 읽었습니다. 아주 많은 양은 아니었지만 평소에 비해서 많은 책을 읽을 수 있었습니다. 하지만 빠르게 읽다보니 책을 읽은 후 몇주만 지나도 머리에 남는 것은 별로 없었습니다. 좀더 어려운 책을 읽을 수록 더 심각했습니다. 

깊게 읽자!

어느날 스스로 회고를 하면서 저처럼 아직 지식 수준이 깊지 않은 사람이 빨리 많이 읽는 것은 크게 도움이 되지 않는다는 것을 깨달았습니다. 그 후 지난 날 읽었던 책들을 다시 깊게 읽었습니다. 저는 지하철에서 책을 읽는 시간 만큼 읽은 내용을 사색하는 시간을 동일하게 할애하였습니다.
다시 깊게 읽은 책들은 저에게 엄청난 감동을 주었습니다.ㅠㅠ 저자의 속뜻을 이해하고 나니 "아하!"가 절로 튀어 나왔습니다. 아마도 만약에 이러한 과정을 거치지 않았다면, 켄트백의 테스트 주도 개발을 대충 읽고, "이거 code and fix 아냐?"라고 말씀하신 어느 개발자 출신 임원분의 말씀에 쉽게 동의했을지도 모릅니다.

기록 하자!

하지만 5년간 천권의 책을 읽고 천개의 서평을 쓰셨다는 파란여우님의 강연 후기를 읽고 아직 부족한 점이 있는 것을 깨달았습니다. 서평쓰기! 제가 읽는 책의 70%는 기술 서적인데, 어떻게 서평을 써야 할지 모르겠지만, 틈나는대로 정리하는 습관을 키워야 할 것 같습니다. 앞으로 블로그를 통해 기록할 생각입니다.

최근 관심사..

최근에 병렬/분산 처리에 관심을 갖게 되면서 이 책을 굉장히 깊이 읽고 있습니다. 
PARALLEL PROGRAMMING in C with MPI and OpenMP
Michael J.Quinn
McGraw Hill

단순한 라이브러리 설명이 아닌 Parallelism을 깊이 이해하기 위해 잘 알려진 문제 및 알고리즘을 병렬화하는 과정을 CASE STUDY 중심으로 설명하고 있어서 생각할 것이 매우 많아서 좋은 것 같습니다. 이야기가 딴데로 흘렀는데.. 요즘 병렬처리에 관심 있는 분들이 많은 것 같은데 같이 고민해보고 나눌 분이 있다면 연락 혹은 답글 부탁 드립니다.^---^

'Life Style' 카테고리의 다른 글

개발자와 다이어트  (6) 2009.12.26
커뮤니케이션 만족 : 당신은 묻기만 하면 된다.  (7) 2009.12.06
Carpe Diem  (6) 2009.11.11
Posted by 윤청하
, |

전의 상실 후의 스프린트

약 2달전부터 7명의 팀원중 4명이 매우 중요하고 긴박하게 준비되는 프로젝트에 투입되었습니다. 엎친데 덮친 격으로 프로젝트 예상 일정이 크게 틀어져서 프로젝트 맴버들은 야간 작업과 주말 작업에 시달려야 했습니다. 프로젝트는 어느정도 마무리되었지만 4명의 팀원들은 사기가 바닥으로 떨어졌습니다. 물론 나머지 3명의 팀원들의 사기도 좋지 못했습니다.
그 후 팀장님께서는 여기서 고삐를 늦추면 다들 마이너스 사기로 돌아설 걱정에 스프린트를 진행하셨습니다. 물론 예상 작업량도 줄였고, 휴가도 넉넉히 할당하였습니다. 그리고 어제 그 스프린트가 종료되었고, 팀내 회고를 진행하였습니다. 이번 스프린트의 결과는 처참했습니다. 제대로 끝난 스토리가 없었죠.ㅠㅠ

비난 없는 회고 : 무엇이 잘못되었을까?
  • 스프린트 준비가 없었다
    다들 사기가 저하된 상태였던지라 스프린트 백로그에 대한 준비가 미흡했습니다. 따라서 초기 예측도 크게 빗나간 스토리가 많았습니다.
  • 얼렁뚱땅 데일리 미팅
    우리는 스프린트 백로그에 대응하는 스토리와 이를 세분하여 데일리 미팅에서 사용하는 테스크로 관리합니다. 준비가 없다보니 테스크는 미리 정의 되지 못했으며, 데일리 미팅에서 테스크를 즉석으로 마련해 내는 진 풍경이 발생했습니다. 따라서 스토리의 남은 예상 시간은 갱신되지 못했으며, 번다운 챠트도 엉망이 되었습니다. 테스크 관리가 제대로 이루어 지지 않아서 협업이 어려웠고 지연되는 스토리가 대거 등장하였습니다.
  • 스토리 및 테스크의 정의 미흡
    스토리와 테스크에는 종료 조건(데모 방법, 리뷰 방법, 테스트 방법 등)이 명시되어야 하는데 대부분 대충 제목만 적는 경우가 많았습니다. 또한 테스크의 크기는 큰 경우가 많았습니다.(1일~3일 단위) 이번 스프린트에서 리뷰도 거의 이루어 지지 않았으며, 데모를 한 스토리는 없었습니다.

다음 스프린트에서 더 잘하려면 무엇을 해야 할까?

우리는 이번 스프린트를 거울 삼아 다음 스프린트에서 어떻게 하면 더 잘할 수 있을지 논의 하였습니다. 팀원들은 각자 다음 스프린트에서 꼭 했음 하는 것과 꼭 하지 말아야 할 것등을 적어서 서로 공유하였습니다. 많은 이야기가 오갔지만 우리는 예상되는 효과가 좋을것 같고 지키기 쉬울 정도로 명확한 규칙을 몇개 선정하였습니다.
  • 스토리의 남은 예상 작업일을 매일 갱신하자
    데일리 미팅에서 스스로 남은 예상 작업일을 갱신하는 작업은 긍정적인 부담감(혹은 책임감)을 제공하는 요소중에 하나입니다. 또한 정확한 번다운 챠트를 그릴수 있게 합니다.  
  • 테스크의 크기는 4시간 단위 이하로 제한한다
    테스크의 크기가 커질 경우 테스크의 정의를 대충 할 수 있다는 경험을 하였습니다. 조금 더 명확한 가이드 라인을 제시함으로써 테스크를 명확하게 나눌수 있으며, 나누어진 테스크는 협업을 쉽게 할수 있게 합니다. 단, 스프린트 미팅에서 잘게 나누어진 테스크를 산출하기 어려우므로, 준비 상태에 있는 테스크의 크기는 제한하지 않되, 테스크를 진행하기 위해서는 위의 제한을 지켜서 테스크를 산출해야 합니다.
  • 테스크에 테스트 방법을 명시하자
    테스크의 종료조건 중 테스트 방법을 명시함으로써 미리 테스트 환경을 고려하여 테스크를 진행할 수 있게 합니다. 우리팀의 업무 특성상 타 팀과의 연동이슈가 많습니다. 따라서 테스트 환경을 미리 고려하지 않는다면 테스크가 종료되더라도 정확하게 테스트되지 않을 수 있었습니다.
  • 스프린트 사이에 2일간 종료 및 준비기간을 갖자
    그동안 스프린트 사이에 여유가 없어서 데모, 회고, 준비등을 잘 할 수 없었습니다. 스프린트 종료후 하루는 데모 및 회고를 함으로써 스프린트 종료를 명확히 하고, 다음 하루는 다음 스프린트를 위한 스프린트 백로그 공유 및 테스크 산출을 함으로써 스프린트 진행에 착오가 없도록 할 것입니다.

정리

어떤 방법을 사용하던 지속적으로 신경쓰고 개선하지 않으면, 습관화 또는 형식화 되기 쉽습니다. 우리 팀은 스크럼이라는 도화지에 우리 나름의 방법을 하나씩 그리고 있습니다.
Posted by 윤청하
, |
팀장 뒷담화와 커뮤니케이션 만족도

회사 동료들과 수다를 즐길때 쉽게 등장하는 주제가 바로 팀장 뒷담화입니다. 특히 술안주로 제격이죠.
얼마전 xper 모임에서 한 팀장님께서 발표하실 때 팀원들에게 '커뮤니케이션 만족도'라는 보상을 주기 위해 고민한다고 하셨습니다. 그런데 말단 팀원의 입장으로써 생각하면 할수록 이 '커뮤니케이션 만족도'라는게 얼마나 중요한건지 새삼 느끼고 있습니다. 그 이유는 팀장 뒷담화를 통해 알수 있죠.
우리 팀장님은 위에서 나오는 얘기들을 도통 해주질 않아.. 나 그 얘기(연봉 동결) 오늘 첨들었어..
우리 팀장님은 우리랑 밥도 같이 잘 안먹어..
우리 팀장님은 구현할 기능만 설명해 주고 그 기능이 나온 과정은 설명해주질 않아.. 왜 그 기능이 필요한지 모르겠어.. 그래도 구현은 해야지..
내가 구현하는 블럭이 누구와 메시지를 주고 받는 지는 모르겠지만 하라는 데로 하고는 있어.. 물어보고 싶은데 다들 바빠보이고ㅠㅠ
뒷담화의 대부분은 커뮤니케이션에서 오는 불만족이었습니다.(여기에 제 불만은 하나도 없습니다ㅋㅋ) 알고 싶은 것은 많은데 알기 어렵다는 것이죠. 그렇다고 팀장님께 따질수 도 없죠. 말단 팀원으로써 방법은 하나 밖에 없습니다.

당신은 묻기만 하면 된다

예전에 읽은 책이 생각났습니다. 랜디 포시 교수님의 마지막 강의!
가끔씩, 당신은 그저 물어보기만 하면 된다. 나는 묻는 것에 꽤 숙달된 사람이었다. 나는 용기를 내어 컴퓨터학 분야의 세계적인 권위자 프레드 브룩스 주니어에게 연락을 했던 일을 자랑스럽게 생각한다.
....
그때 나는 이십대 후반이었고, 꼭 한번 그를 만나고 싶었다. 그래서 나는 그에게 이메일로 이렇게 물었다. "만약에 제가 버지니아에서 노스캐롤라이나까지 운전을 해서 가면, 삼십 분 정도 제게 시간을 내어지실 수 있습니까?"
그는 답했다. "만약 자네가 운전해서 여기까지 내려오겠다면, 내가 삼십분 이상의 시간이라도 내겠네." 그는 나에게 한시간 반을 할애 했고 그날 이후 내 인생의 멘토가 되었다. 수년이 지나고 그는 노스캐롤라이나대학에서 강연해줄 것을 부탁하며 나를 초대했다. 그리고 그 여행은 내 인생에서 가장 중요한 순간으로 나를 이끌었다. 그때 재이를 만난 것이다.
때때로 당신은 그저 물어보기만 하면 되고 그것이 당신이 일생 동안 품어왔던 꿈을 이루는 길로 이끌 수도 있다. 요즘의 나는 "그냥 질문하기"에 이전보다 훨씬 능숙해졌다. 살날이 얼마 남지 않았기 때문이다. 다들 아는 것처럼 검사 겨로가를 받는데 며칠씩 걸리는 경우가 종종있다. 지금에 와서는 검사 결과를 초조하게 기다리는 것으로 남은 시간을 써버리고 싶지 않다. 그래서 나는 항상 묻는다. "어떻게 하면 최대한 빨리 결과를 알 수 있을까요?" 그들은 보통 이렇게 대답한다. "아, 잘하면 한 시간 안에  준비해드릴 수도 있겠군요." "잘됐군요. 물어보기를 잘했어요!" 내가 말했다.
궁금한 것이 있다면 질문하라. 그저 묻기만 하면 된다. 당신이 기대 하는 것보다 자주 당신이 듣게 될 대답은, "물론이죠."가 될 것이다.
팀장의 리더쉽도 중요하지만 그 팀장을 따르는 팀원들도 중요하다. 커뮤니케이션이란 양방향이다. 팀장님 혼자서 만족을 주기에는 무리가 있지 않을까?^^ 일단 물어보자!

'Life Style' 카테고리의 다른 글

개발자와 다이어트  (6) 2009.12.26
책은 깊이 읽어야 한다. 그리고 기록해야 한다.  (8) 2009.12.23
Carpe Diem  (6) 2009.11.11
Posted by 윤청하
, |
새로운 업무를 받음

얼마전 오래된 시스템(legacy system)에 새로운 플랫폼의 부가(extension) 모듈을 이식하라는 업무를 할당 받았습니다. 쉽게 생각하면 새로운 플랫폼은 유연성을 크게 가질수 있도록 작성되었으니 쉽게 이식 될 수 있다고 오해 할 수 있습니다. 저는 먼저 오래된 시스템과 새로운 플랫폼의 의존성을 확인하였습니다. 오래된 시스템의 일부 코드를 수정(modification)하는 것은 일단 허용하기로 하였습니다. 하지만 새로운 플랫폼의 부가 모듈을 바로(쉽고 빠르게 수정없이) 이식하기에는 문제가 있었습니다. 

무엇이 문제였을까

새로운 플랫폼의 부가 모듈은 하위 모듈(base library)에 의존성(dependency)을 가지고 있었습니다. 일반적으로 계층 기반(layer based)으로 모듈을 작성할 때 하위 계층에서 상위 계층을 직접 참조하는 것은 원칙적으로 불허 하지만, 그 반대의 경우는 허 하는 경우가 많습니다. 간단히 생각해보면 이는 크게 문제가 되지 않을 수 있지만, 상위 모듈이 하위 모듈에 의존하기 때문에 상위 모듈의 유연성, 재사용성은 매우 떨어지게 됩니다.

해결 방법

이와 같은 상황을 해결하는 방법은 다음과 같습니다.
  1. 오래된 시스템에 하위 계층까지 모두 이식한다.
  2. 새로운 플랫폼의 부가모듈을 컴파일 옵션으로 시스템에 따라 다른 하위 레이어를 사용하도록 수정한다.
  3. 새로운 플랫폼의 부가모듈을 복사하여 오래된 시스템에 맞도록 수정한다.
  4. 새로운 플랫품의 부가모듈이 가지는 하위 계층에 대한 의존성을 제거한다.

의존성을 역전시키자

위의 문제에서 하위 계층에 대한 의존성을 제거하는 것(해결방법 4)을 객체지향 디자인에서는 의존성 역전 원칙(The Dependency Inversion Principal)이라고 합니다.
High level modules should not depend upon low level modules. Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.
이 원칙은 상위모듈은 하위 모듈의 추상 클래스(또는 인터페이스)에만 의존함으로써 구체적인 구현에 대한 의존성은 갖지 않도록 하는 것입니다. 
위의 상황에서 의존성 문제가 되는 하위 모듈 중의 하나는 타이머입니다. 만약에 해결방법 1로 해결한다면 다음과 같은 그림처럼 작업이 이루어질 것입니다. 즉, 오래된 시스템에도 TimerB가 존재하지만, TimerA까지 이식함으로써 부가 모듈을 이식 가능하게 합니다. 이는 타이머 기능의 중복을 만들게 됩니다. 때에 따라서 TimerA의 의존성 때문에 다른 모듈들이 줄줄이 딸려가는 일이 생길수도 있습니다.
해결방법 2로 하게 되면 모듈의 구현 복잡도는 증가하게 될 것이며, 해결방법 3은 새로운 소스코드 브랜치가 생기게 되어 관리에 대한 부담이 증가하게 됩니다.
마지막으로 해결방법 4로 이 문제를 해결하면 다음과 같은 그림처럼 작업이 이루어 질 것입니다.
즉, 부가모듈은 ITimer라는 인터페이스에만 의존하게 되고 새로운 플랫폼과 오래된 시스템은 각각 해당 인터페이스를 Adapter Pattern을 이용하여 TimerA, TimerB로 구현하면 됩니다. 결과적으로 부가 모듈만 깔끔하게 이식할 수 있습니다.
저는 이 문제를 해결방법 4를 이용하여 해결했습니다. 제가 정의한 추상클래스는 다음과 같습니다.
IMpTimerListener는 타이머의 이벤트를 받기 위한 추상클래스이며, IMpTimer는 타이머 등록 및 해제를 위한 추상클래스입니다.

회고(retrospective)

사실, 이 업무를 진행하면서 모든 의존성을 위와 같은 방법으로 해결하지는 못했습니다. 기존 구현에 따라 해결방법 2를 사용한 경우도 있었습니다. (Define으로 구현되어 있어서 불가피 했음) 하지만 이러한 리팩토링을 통해 위의 부가모듈의 의존성은 상당히 사라지게 되었고 재사용성은 크게 증가하게 되었습니다. (추후 재사용 요구사항이 예상되는 모듈이었습니다.) 모든 모듈에 대해서 재사용성에 포커스를 두는 것은 over-engineering의 가능성이 있습니다. 하지만 이와 같이 재사용 이슈가 예상되는 모듈에 대해서는 의존성을 철저히 관리함으로써 추후 유지보수 업무를 줄일 수 있을 것입니다.^^ 감사합니다.

Posted by 윤청하
, |
11월의 마지막날 xper 정기모임을 강남역 근처에 위치한 토즈에서 진행하였습니다. 거의 60명에 가까운 분들이 참여하신것 같습니다. 평일 모임이라 시간이 부족한 까닭에 바로 발표를 진행하셨습니다. xper(http://xper.org/wiki/xp/)에서는 매월 정기모임을 갖습니다. xper 메일링 리스트(http://groups.google.com/group/xper)에 가입하시면 자세한 공지를 받으실 수 있습니다.^^

조직관리와 스크럼 - 고성원

Dragonfly사의 Special Force 2 팀장님이신 고성원님께서 팀에 스크럼을 성공적으로 도입하고 정착할 수 있었던 '팀 조직 관리의 방향성'에 대해서 발표해주셨습니다. 고성원 팀장님은 외모에서부터 special force가 느껴졌었습니다+_+ 멋있으셨음~

얼마전에 공중파에서 방영한 영상으로 발표를 시작하셨습니다. 일본의 한 사과농부가 어떤 화학 비료도 쓰지않고 사과농사에 성공한 이야기였습니다. (사과는 자연농법으로 재배하기 가장 어려운 품종중에 하나랍니다.) 그 성공의 해답은 흙을 믿었던 것입니다. 10년동안 실패했지만 포기하지 않고 자연의 모습을 그대로 재연함으로써 사과 자연농법에 성공하였습니다. 덕분의 그분의 땅은 그 어느땅보다 기름진 흙을 가지게 되었습니다. 이는 스크럼의 가치에 아주 적절하게 비유될수 있다고 하셨습니다. 즉, 그 농부는 사람(흙)을 믿는 세계 최고의 스크럼 마스터인 것입니다.

고팀장님은 스크럼 도입 이전 4년동안 '팀 조직 관리'에 대해서 고민하셨다고 합니다. 아마 개발팀 팀장이라면 누구나 했을법한 고민인 것 같습니다. (전 아직 팀장이 아니라ㅋㅋ) 그러던 중에 스크럼 책을 접하게 되셨고, 큰 영감을 얻으셔서 팀내 스크럼 적용을 강력하게 드라이브하셨다고 합니다. 스크럼을 도입하는 중간에 큰 위기는 없으셨고(중간에 윗분이 보드를 떼라고 했던게 가장 위기였었다고..), 회사에서 IPO를 진행하면서 회사내에 발표할 기회가 있으셨는데, 그때 신임을 크게 얻으셨다고 합니다. 그리고 팀원들에게 얻은 생생한 증언이 다음과 같습니다. (몇개만 적어봤습니다.)
  • 업무 목표가 분명해진것 같습니다. 
  • 유기적, 조직적으로 일하는 것 같이 느껴집니다.
  • 일과가 명확해 진 것 같습니다.
  • 긍정적 부담의 효과로 책임감이 높아졌습니다.
  • 완성품의 잣대를 스스로 결정할 수 있게 되었습니다.(디자이너)
  • 일과 개인 생활의 균형을 잡을 수 있게 되었습니다.
너무 긍정적인 것만 있어서 쪼금 아쉬웠습니다.^^ 하지만 발표 마지막에 보여주신 사진들을 보면서 정말 다들 변화에 매우 적극적이었을 것 같다는 느낌을 받았습니다~ (팀장님과 팀원들 모두 부러웠습니다.ㅠㅠ)

고팀장님은 팀원들과 매우 능동적인 커뮤니케이션을 하신것처럼 보였습니다. (양방향 관리모델..) 가장 인상적이었던 것은 팀원들에 대한 보상 중에 커뮤니케이션 만족도라는 것이 중요하다는 것을 말씀하신 것입니다. 저는 이게 보상일까라고 상상도 못해봤는데, 듣고 보니 정말 "아하!" 였습니다. 커뮤니케이션 만족도가 높다는 것은 소외감을 느끼지 않는 것이며, 조직의 구성원으로써 인정받고 있다고 느끼고 있다는 것일 겁니다. 개인적으로 혼자 프로젝트를 맡아서 업무를 처리할 때 커뮤니케이션 만족도가 매우 떨어졌던것 같습니다. 만약, 팀에서 데일리 미팅까지 않한다면, 그 외로움은 정말 커질겁니다. (상상만해도 외롭다는..ㅠㅠ)

국내 SI시장에서의 애자일 개발 적용 - 민신현

두번째는 SI업계에서 10년이상 몸담아 오신 SK C&C의 민신현님(PM)께서 SI시장에서의 애자일 개발 적용 사례를 발표해주셨습니다. 발표의 시작은 현재 국내 SI시장의 열악한 환경과 이유에 대해서 매우 알기 쉽게 설명해주셨습니다. 몸으로 와닿는 표현으로 발표를 해주셔서 비록 SI업계 경험은 없었지만 그 아픔은 진심으로 느낄수 있었습니다. (사실 저희 회사도 SI/용역에서 크게 벗어나지 않습니다.ㅠㅠ) 아르미라는 개발 프로세스는 산출물만 150가지가 넘는데, 실제 산출 문서만 4.5m의 두께에 이르는 경우도 있었다고 합니다.

민신현님은 다음과 같은 문제점을 해결하고자 하셨습니다.
  • 기존의 방법론은 실제 눈에 보여지는 결과물이 나오기 까지 너무 올래걸립니다.
  • 현재 내 위치를 알수가 없습니다. (얼마나 더해야 끝나는지..)
  • 바보 개발자를 양산하고 있습니다. (요구사항에 없는건 신경도 안쓰는..)
  • 산더미 같은 문서를 생산합니다. (프로그램 개발이 아닌 문서 개발.. 감리를 위한 산출물)
  • 서로 이해되지 않는 말로 커뮤니케이션 합니다. (공동체 의식이 없는 팀..)
그리고 재미를 부여하고자 했습니다. (한국 개발자의 재미 = ownership + 칼퇴근..ㅋㅋㅋ) 
그럼 어떻게 해결하셨을까요?
  • 6개월, 1년의 스케쥴은 예측하기 어렵습니다. 짧게 예측하자! 2~3주 이터레이션~
  • 설계 중간중간에 테스트 케이스를 작성 합니다(class diagram, use case 단계) - 자동화 테스트
  • 자동화 테스트만 믿을 수 없습니다. 수동 유저 테스트
  • 기반 시스템 가동합니다 - CI 서버(Hudson) 운영(데일리 빌드, 테스트 자동화), Trac, Doxygen
  • 정말 필요한 문서를 만듭니다. 위키를 통한 프로젝트 진행 사항 공유~ 및 문서화(링크)
  • 개발자들에게 고객과 개발된 프로그램으로 대화하라고 주문합니다~ 
  • Wireframe 방식의 GUI prototype 방식에서 user experience가 가능한 prototype 방식으로 변경(프로그램 구매)했습니다
  • SI 특성상 매 프로젝트마다 인원이 바뀌기 때문에 프로젝트 초반에 교육에 치중하였습니다
  • 매번 이터레이션마다 개발자들을 쉬게 하였습니다. (빨리 끝내는 개발자는 칼퇴근! 추후에는 동료들을 도와준다는.. 하지만 나중에는ㅋㅋ - PM이 지고가야할 짐이라고 하십니다..멋있다ㅠㅠ)
  • 매일 아침 30분간의 티타임~ 우리가 남이 아니다라는 것을 알게됩니다.
  • 고객과의 합의를 통해 새로운 프로세스를 적용하였습니다. (고객 설득 -> 감리 설득)
궂이 애자일이라고 표현할 필요는 없을 것 같습니다. 엄청난 고민과 개선의 결과라고 생각됩니다. (실제로 매우 성공적인 프로젝트를 진행하셨다고 합니다. 참여한 개발자들이 고맙다고 인사하고 선물까지 주셨더라는...)

이와같은 변화를 통해 민신현님은 정량적 공정 결과, 현재 내 위치, 미래의 위치를 얻으셨다고 합니다. 어떤 방법을 사용하여 개선하든, 일의 본질은 변하지 않는다가 정답인것 같습니다.

개인 회고

까먹을까봐 바로 정리하고 있는데 요즘 2달된 지윤이 덕분에 잠을 잘 못자서 인지 횡설수설한것 같습니다. 잘못된 내용있으면 리플 달아주시면 정말 백만개 감사할 것 같습니다^^

좋았던 점
  • 두 리더분의 강력한 카리스마와 경험을 공유할 수 있어서 좋았습니다.^^ (그 팀에 속한 팀원들이 부러웠습니다~)
  • 정시 퇴근에 대한 환상이 현실로 조금씩 다가오고 있다는 느낌이 좋았습니다~
아쉬운 점
  • 시간 관계상 사람들과 나눌수 있는 시간이 부족했던게 아쉬웠습니다. 그래도 너무 즐거웠습니다!
  • 민신현님께서 질문에 대한 답변에서 가장 후회가 되는 선택이 개발자들을 칼퇴근 시키고 대신 자신이 남아서 야근했던일이었는데, PM이 짊어져야할 짐도 있지만 함께 나누어 가져야 할 짐도 있지 않을까 상각해봤습니다. (입원까지 하셨다는 말씀에 눈물이 날뻔..ㅠㅠ)
아하!
  • 역시 사람을 믿어야 한다~
  • 리더의 역할이 중요하다. (나중에 내가 팀장이 되면 어떤 팀장이 되어야 겠다는 상상의 나래를 펼쳐보았습니다^^)
  • 금전적인 보상도 좋지만 커뮤니케이션 만족도를 높여주는 보상도 중요하다!
  • 현재 자신의 위치를 안다는 것이 매우 중요하다. (이를 통해 여유 있는 스케쥴링이 가능할 것 같습니다. 칼퇴는 그 다음에 꺼내야할 문제인듯...)
  • 커뮤니케이션을 위한 집중된 공간이 필요하다. (두분 모두 위키를 통해 공유하셨습니다. 우리 팀도 위키를 썼으면 좋겠네요~ㅎㅎ)
  • 티타임으로 '우리'라는 공통분모를 찾자. (현재 저희 팀에 스크럼을 적용하여 진행중인데 다소 형식화 되간다는 느낌이 들었습니다. 우리팀에게 당장 필요할듯 합니다.)

정말 재미있고 유익한 시간이었습니다. ^-----^ 감사합니다!

Posted by 윤청하
, |
오늘 저녁에 얼마전 취직한 후배가 저녁을 사달라고 해서 만났다. 영동시장에서 맛있는 차돌백이 + 숙주나물을 먹고 나와서 강남대로에 있는 커피빈에 갔다. 요즘들어 술마시는 것보다 커피마시면서 조용히 수다떠는것에 더 익숙해졌다.^^ (아직 30대도 안되었는데...ㅠㅠ)

한참을 떠들고 나오다가 커피빈 화장실에 들렸다. 세면대에서 손을 씻고 페이퍼타올을 뽑아서 손을 닦고 버릴려고 하는데.. 분명히 바닥에 휴지통이 있음에도 불구하고 세면대 옆에 지져분하게 다쓴 페이퍼타올들이 수북히 쌓여있었다.

분명 처음부터 그런 상황은 아니었을 것이다. 또한 커피빈같은 점포 특성상 일정한 주기로 화장실을 청소하기 때문에 매우 오랬동안 방치되지 않았을 것이라 추측한다. 하지만 분명히 20명에 가까운 사람이 쓴듯한 페이퍼타올이 수북히 쌓여있었다. 왜그럴까?

문득 예전에 읽은 "실용주의 프로그래머"라는 책에서 읽은 "깨진 유리창 이론(broken window theory)"이 생각났다. 깨진 유리창 이론은 사소한 문제를 해결하지 않았을 경우 본격적인 문제로 발전할 수 있다는 내용이다. 커피빈의 화장실 사건은 아마 어느 누군가의 사소한 청결에 대한 무관심에서 시작되었을 것이다. 버려진 하나의 휴지는 다른 이들에게 세면대 옆에 휴지를 버릴수있도록 허용한 것이다.

소프트웨어 개발에서 깨진 유리창을 방지하는 것은 매우 중요하다. 한눈 팔다보면 이미 소프트웨어는 돌이킬수 없는 상태로 복잡하고 지져분하게 될수 있으며, 리팩토링을 위해서 매우 큰 비용을 부담해야 할수 있다. 사수가 만들어 놓은 깨진 유리창이 있는 코드에 후임이 불을 질러 놓았다고 해서 후임을 비난할 수는 없을 것이다. 소프트웨어 개발자는 정말 부지런해야 한다. 항상 자신의 코드에 깨진 유리창이 없는지 확인해야 한다. 켄트백은 말단연구원도 책임감(responsibility)을 위에서 끌어와서 자신을 다치기 쉬운 상태로 놓는것이 바람직하다고 했으며 사람다운 개발자가 되기 위해 필요하다고 했다. (매우 역설적으로 들릴수 있다.)

아주 바쁘다 보면 빠르고 쉽게 생성되는 코드들이 있다. 이들이 문제인 경우가 많다.^^;; 특히 BMT...
우리에게 책임감이 있다면 BMT 같은 상황에서 생성된 깨진 유리창들은 꼭 고쳐놔야 할 것이다.

'Programming' 카테고리의 다른 글

CASE STUDY : 의존성을 역전 시키자  (10) 2009.12.02
여러분의 소스코드는 안녕하십니까?  (7) 2009.11.24
개발언어와 개발스타일  (5) 2009.11.23
Posted by 윤청하
, |
10년 묵은 잘못된 소스코드 관리

어제 스프린트 미팅에서 있었던 일입니다. 스토리 중에 새로운 BMT에 대응하는 스토리가 있었습니다. 팀장님은 이전에 만들어진 제품에 새로 개발된 플래폼을 이식하여 해당 BMT에 대응하기를 원하셨고, 이를 위해 현재 플래폼 소스코드를 복사하여 새로운 저장소(SVN에서의 repository 또는 ClearCase에서의 Vob)를 만들라고 주문하셨습니다. 쉽게 말해서 중복된 소스코드 두개를 만드는 것입니다. 저희 회사는 제품의 특성상 시스템 장애에 굉장히 민감합니다. 따라서 어쩔수 없이 상용 사이트에 납품된 제품의 소스코드는 사이트 별로 따로 관리하고 있습니다. 하지만 진짜 문제는 복사되어 분리된 소스코드는 그 사이트에서 해당 제품을 폐기하기 전까지 유지된다는 것입니다. 즉, 사이트 별로 거의 비슷한 소스코드들이 생산되는 것입니다. 이는 다음과 같은 문제를 야기시키고 있습니다.
  1. 소스코드 관리 리소스 증가 : 새로운 기능이 개발되거나 버그가 발생했을 경우 매우 많은 저장소에 동일한 수정과 동일한 테스트를 해야합니다.
  2. 저장소별 히스토리 관리 : 저장소 별로 수정 히스토리를 따로 관리해야 합니다.
  3. 같은 문제가 번복됨 : 1번을 잘 못할경우(잘 못하고 있습니다.) 같은 버그가  여러 사이트에서 발생합니다.
즉, 유지보수에 굉장히 많은 리소스가 투입되며, 매출 증가 대비 필요한 리소스는 계속 증가하게 됩니다.
이는 10년동안 지속되온 문제입니다.ㅠㅠ

해결하기

다행히도 제가 생각하는 해결방법과 팀장님이 생각하는 해결방법은 동일했습니다. (팀장님은 이상적 방법이라는 표현을 쓰시긴했지만...) 해결 방법은 다음과 같습니다.
  1. 메인 소스코드를 버전별로 관리한다.
  2. 사이트 혹은 BMT에 대응하는 경우 현재 버전의 소스를 복사하여 작업한다. 단, 메인이 되는 소스코드와 동기화는 맞추어야 한다.
  3. 소스코드는 일정한 주기로 버전 업을 한다. (약 4주)
  4. 사이트에서 생성되는 요구사항은 일정한 주기로 버전 업 되는 메인 소스코드에 구현한다. 완료되고 적용될 때에는 기존의 복사된 소스코드를 삭제하고 새로운 버전의 소스코드를 복사하여 해당 사이트에 유지한다. (버전 업)
즉, 사이트별로 중복된 소스코드를 사용하지만, 메인 소스코드에 집중하고 잘 유지함으로써 지속적으로 동기화 될수 있는 방법입니다.

10년동안 바꾸지 못한 이유

위의 제시된 방법에서 큰 신뢰성이 요구되는 부분이 있습니다. 사이트의 소스코드를 버전업 하는 경우 기존 기능의 안정성 여부 및 타 시스템간의 호환성 유지 여부가 매우 중요하게 됩니다. 10년동안 바꾸지 못한 이유는 바로 이 점을 QA조직에서 개발팀을 신뢰하지 못하기 때문입니다.ㅠㅠ
이제 개발팀이 해야 할 일들이 눈에 보이기 시작합니다.
  1. 회귀테스트를 유지하고 관리해야 합니다. 자동화된다면 정말 좋을 겁니다. (TDD 강추..ㅠㅠ)
  2. 하위 버전 호환성 테스트를 유지하고 관리해야 합니다. API가 변경되지 않는다면 더욱 좋을 겁니다.
저는 이런 작업들이 이상적이라고 생각하지 않습니다. 당연히 개발자들이 해야 할 일들이라고 생각합니다. 물론 초반에 업무량은 더 많아 질수 있습니다. 하지만 가까운 미래에는 사람다운 개발자가 될수 있을거라 기대합니다^^

어제 회의에서 팀장님께 강력하게 요청했는데 어떻게 반응하실지는 두고봐야 겠네요..^^ 간만에 강하게 나가니까 좀 당황하신듯...ㅋㅋㅋ 10년동안 방치된 방법을 바꾸는게 쉽지는 않겠지만 이대로 간다면 살아남기 쉽지 않기 때문에 뭐라도 해야겠죠..^^

'Programming' 카테고리의 다른 글

Broken Window Theory and Software  (4) 2009.11.26
개발언어와 개발스타일  (5) 2009.11.23
Subtype Polymorphism과 성능 이슈  (4) 2009.11.17
Posted by 윤청하
, |