Younghoe.Info v3

언제부터 읽다 버려둔(?) 책을 마무리했다. 분량도 많지 않은 이 책을 읽는데, 오랜 시간이 걸렸다. 많은 사진과 컬러풀한 편집을 동원했다고 해도 5분 남짓한 짧은 시간에 맞춰 응축한 시청각 메시지를 담아내기에 종이란 적절한 매체가 아닌 듯하다. 그렇다고 해도 신문/뉴스 혐오증 탓에 몰랐던 MB 시장과 MB 정부의 위험한 정책(강북 뉴타운 사업, 의료보험민영화, 물산업지원법, 영어몰입교육 등)에 대해 조금이나마 이해하게 된 것은 소득이다.^[각주:1]

영상물로 접할 때 제맛이 나겠다 싶어 EBS의 지식채널e 사이트 코너를 찾았다. 사이트에 가입하고, vod를 둘러보았다. 책에서 본 내용을 찾아보기 어려워서 찾다가 '늙은 시인의 고백'편 4분짜리를 감상했는데 묵직하다.

읽고 나니 이렇게 메시지가 풍부하고, 서정적인 영상을 책에 고스란히 담는다면 제작진이 얼마나 서운할까 싶다. 책을 읽고 최대의 소득은 무엇보다 지식채널e란 프로를 알았다는 점이다.


그리고, 잠시지만 내 삶을 통째로 반성하게 했던 352 ~ 361쪽의 故이종욱 WTO 사무총장님 이야기는 인터넷에 동영상 링크가 있다.

유익한 책이다. 다양한 이야기를 담고 있는데 딱 두 가지 특징만 꼽아보면 이렇다.

1) '후불제 민주주의'라는 제목은 그야말로 촌철살인의 표현이다.
2) 현 정부에 대한 매우 강경한 비판을 담고 있다.

특별히 2부의 정치인의 실상에 대해 알려주는 부분이 매우 흥미로워 표시를 해두었다. 유시민 씨 책으로는 대한민국 개조론을 처음 읽었다. 언론 탓인지 '유시민 = 논쟁'이라는 한심한 이미지만 머리에 넣고 살다가 전 보건복지부 수장으로 그가 펼친 논지가 신선함을 넘어서 충격적이었다. 사실 책 내용보다는 다음 사항이 더 충격적이었다.

1) 장관이 직접 책을 내지 않으면, 신문을 통해선 정책을 알 수가 없겠다 싶은 추측
2) 적어도 내 주변의 서민층을 대상으로 보면, 정책은 전혀 전달되지 않는다는 느낌^[각주:1]

아마 비슷한 경험을 기대했는지, 헌법이야기보다는 297~304쪽에서 펼쳐지는 국회의원이야기, 324쪽의 진보정당에 대한 비판 등이 가장 인상에 남는다. 특히, 표밭인 지역구에 얼굴 비추는 일이 국회에서 자리 지키는 일보다 더 중요할 수밖에 없는 현장의 상황을 생생하게 묘사한 부분은 알지 못하던 이면의 참모습을 보여준다.

1. 자본주의 역사 바로 알기
2. 네가 어떤 삶을 살든 나는 너를 응원할 것이다
3. 교양으로 읽는 법 이야기
4. 후불제 민주주의
5. 지식 e - 시즌 3
6. 쾌도난마 한국경제
7. 지식 e - 시즌 1
8. 나는 빠리의 택시운전사

('09.3/5) 제목에 끌려서 읽었다. 하지만, 문장이 생소해서 읽는 내내 이질감을 느꼈다. 다른 책에서 인용한 주옥같은 표현 덕분에, 공지영 씨가 추천(?)한 많은 책을 구매하거나 읽을 듯하다. 100쪽을 넘길 즈음 인내력에 한계를 느껴 지하철에서 내릴 때^[각주:1]까지만 집중해서 훑어보자고 데드라인을 그었다.

반칙을 범해서 다시 출근하는 길에 마지막 일화를 읽으며 마음이 바뀌었다. 이 책은 엄마가 딸에게 보내는 편지인데, 편지에 대한 화답으로 딸이 쓴 글에 눈물이 날 뻔했기 때문이다. 고3을 보내는 딸에게 전하는 마음을 일 년을 모아뒀는데 단 몇 시간 만에 읽어 치우려고 했던 모습이 억지 같이 느껴졌다. 나도 누군가에게 매주 편지를 써볼 생각이다. 편지를 쓰기에 앞서 공지영 씨 편지 24편을 먼저 읽는 데 활용해야겠다. 24주 프로그램이구먼. (이하 '09.4/8)지키지 않던 다짐이 생각나 방금 편지 한 편 썼다. @@

위 글을 읽으면서 나 스스로 여전히 내용보다 형식에 얽매여 있음을 깨달았다. 무의식적으로 형식주의에 지나친 과민반응을 보이는 이유가 아마도 실용적인 사람을 선망하는 탓에 묻어나는 행동이 아닌가 싶다. 새로운 일을 벌일 때, 항상 무언가 사들이거나 환경부터 구축하려는 습성을 빨리 버리자.

전략사고 컴플리트북 1부 1절 요약

신대철: 응. 얼굴 보고 뽑았어. 재능이 있는 사람은 얼굴만 보면 알 수 있어. 자신감이 있거든.

<시나위 신대철 인터뷰 중에서 '김종서, 임재범, 서태지 등 다 멋있고 깔끔하잖아. 얼굴 보고 뽑았나?'는 질문에 대한 대답 발췌>

외국에 장사 되는 밴드가 많은데 우리나라에선 그렇지 않잖아. 왜 그럴까?

신대철: 어려운 질문인데, 결국 시장이 작기 때문이 아닐까. (중략) 우리도 한류 이후 시장이 좀 커지긴 했지. 동방신기 같은 친구들이 장수하는 게 그 때문이야. 관리받으면서. 그런데 록은 영혼이 자유로운 사람들이 하는 음악이야. 컨트롤 받는 걸 매우 싫어하지. 자유롭게 음악하고 싶은데 그럴 여건은 안 돼. 사회가 보수적이고 뭐랄까, '추함의 미학'을 좋아하지 않아. 왜. 우리나라 사람들은 예쁘고 귀여운 걸 좋아하잖아. 록 밴드는 거칠고 때론 반사회적인데 우리 사회가 아직 받아들이지 않는 것 같아.

현재의 방식이 아무리 비합리적이라 하더라도 그 방식이 이루어지기까지는 역사적 과정이 있다. 현장에서 뛰고 있는 대부분의 사람들이 현재의 방식에 순응하고 있다는 현실적인 문제도 존재한다. 악의는 없다고 하더라도 익숙해진 방식을 쉽게 바꾸려고 하지 않는다. 게다가 새로운 것에 대해서는 아무래도 부정적인 측면을 과도하게 염려하기 마련이다.

동료와 서로 개성에 대해 이야기하면서 블로그에 쓴 글이 잠시 떠올랐다. 나는 공격수 기질이 확연히 드러난다. 주변에서 그렇게 보인다고 하고 수긍이 간다. 공간을 만들고 기회를 창출하기 위한 창조적인 움직임이 공격수의 필수 요건인데, 그에 상응하는 활동을 할 때 희열을 느낀다. 심지어 수많은 시도가 오프사이드로 물거품이 되고, 뛰어난 상대 수비수의 벽에 막힌다고 해도 과정 자체를 즐긴다.^[각주:1]

조직에서 일을 하다 보면 공격수 기질이 약하지만, 어느 정도 분발을 해야 할 수 있고, 반대로 수비 능력은 없는데 일정 부분 요구를 한다.

혼자 이해할 수 있는 비유일 수 있어서 공유를 위해 조금 부연을 하겠다. 무엇인가 위험이 따르는 새로운 일을 맡아서 결과를 내는 일을 공격이라고 한다면, 보통 공격수에 합당한 이가 있다. 반면 이미 체계가 잡힌 일이 원활하게 돌아가게 하는 일을 수비라고 해보자. 대개는 조직이 성숙하면 공수에 합당한 기질에 맞춰서 포지션을 부여한다. 하지만, 상황에 따라 공격 혹은 수비만 할 수는 없다.

고민을 토로한 동료는 마치 견고한 수비력을 발휘하기도 어려운데 오버래핑을 요구받는 풀백과 같은 위치였다. 반대로 과거에 난 수비하지 않는 공격수임을 자각하지 못하던 때가 있었다. 지나치게 골에만 집중하면 '게으른 공격수'로 전락할 수 있고, 얼마 전 경기에서 호날두가 그랬듯이 공격하다 빼앗긴 공이 바로 실점으로 이어지는 상황도 있다.

조직 차원에서 이들을 잘 조율하는 일은 무척이나 힘든 일이다. 하지만, 개인 차원에서도 조직에서 역할에서 공격과 수비를 적절히 소화해야 한다. 현대 축구에서 기반 철할 중 하나가 토탈 사커이다. 만일 특정한 시대를 관통하는 기조가 있다면, 축구 팬이 아니더라도 관심을 기울여봄 직하다. 애자일 개발 방식을 '체계 없이' 혹은 '단순 시행착오법'으로 오인하는 사람이 꽤 있었는데, 토탈사커라고 포지션이 없는 축구가 아니다. 선수 개인의 강점은 살리면서 유기적인 조화를 통해 팀이 최상의 기량을 발휘하게 하는 방법은 놀랍게도 축구와 프로젝트 개발 방식은 물론 기업의 조직 관리 모두에서 화두가 아닌가 싶다.

다시 개인 차원으로 돌아와서 본인 내면의 기질 혹은 능력을 총체적으로 활용하려면, 그간 인지하지 못했거나 개발하지 못했던 능력까지 활용하여 토탈 자아 실현(?)할 필요가 있다.... 는 느닷없고 엉성한 생각이 어디선가 툭 주입되었다.

어제 유지보수 일을 하는 친구와 만나 이야기를 하는데, 직접 경험이 아니기에 현장이 그대로 그려지지는 않고 수긍할 수 있는 수준의 그림이 그려졌다. 유지보수 경험이 없는 내가 친구의 이야기를 이해하려면 은유(Metaphor)가 빨랐다. 그래서, 친구 이야기를 듣는 동안 머릿속에선 기억을 뒤져서 비슷한 그림을 투사하고 있었다.

친구가 혁신과 유지보수 조직 사이의 시각차를 이야기하는데 축구에서 공격수와 수비수의 관점 차이에 그대로 투영할 수 있었다. 일부 조직에서 '혁신'이란 부서는 다른 조직에선 '정보 기획'이라 불린다. 유지보수 조직은 과거 전산실에 해당한다. 조직 차원에서 기획 부서는 궁극적으론 매출 신장을 위한 일을 한다. 반드시 매출과 연계한 일을 하지는 않지만, 영업활동 관련 일을 하거나 기존에는 눈에 띄지 않았던 영역을 개척하는 일을 한다. 일의 성격상 100% 성공을 장담할 순 없지만, 여러 활동 중의 하나만 제대로 터트려도 능력을 인정받는다.

반면 유지보수 인력은 애초부터 터트릴 골(?)이 없다. 자칫 경솔하게 나섰다간 도리어 자살골(?)을 넣을 수 있다. 그래서 항시 조심하고 또 조심한다. EPL의 수비수는 개인기가 뛰어나지만, 공격수와 1:1 상황에서는 일단 걷어내고 본다. 대부분 상황에서 자신이 공격수를 제치고 전방으로 찔러주는 패스를 넣을 수 있을지 몰라도 혹시라도 잔디 사정 탓이나 바람 탓에 실수하면 그간 쌓아온 노력이 하루아침에 날아가기 때문이다. 유지보수 업무는 축구의 수비와 무척 닮았다. 그렇다 보니 유지보수 담당자는 수비수와 닮는다.

현대 축구에서는 과거 어느 때보다 플레이메이커 역할을 중요하게 생각한다. 사실 마법사 같은 선수는 혼자서 플레이를 만든다. 십 대의 호나우두나 요즘 메시를 보면 비현실적인 플레이로 상대편 수비수 여럿을 바보로 만든다. 심지어 이들이 반짝이는 순간이 있고, 90분 가까이 소득 없는 공방전이 펼쳐지는 때도 있다. 하지만, 조직력이 잘 갖춰진 강팀은 공수 유기적인 협력을 공통으로 갖추고 있다. 공격과 수비를 물 흐르듯 조율하는 미드필더 진용은 최고 수준에 달한 팀의 필수조건이다.

프랑스가 세계를 제패할 때 혹은 레알이 유럽 리그를 호령할 때 '지단-마케렐레'라인이 있었고, 아스날 전성기에는 '베르캄프-비에이라' 라인이, 첼시 전성기에는 '램파드-마케렐레(에시앙)'라인이 있었다. 더욱 발전한 최근에는 중앙에 고정한 라인이 아니라, 가운데는 물론 좌우로 펼쳐지기도 한다. 탄탄한 중앙 미드필더 위에 존재하는 바르샤의 '판타스틱4'는 실로 역동적인 공격 전개 능력을 보여주며, 박지성이 함께하는 맨유 역시 다양한 옵션을 활용하며 좌우로 휘는(?) 유연한 허리를 자랑한다.

미루어 보건대 조직의 출력을 최대로 끌어올리려면 비슷한 역할이 필요하다. 과거부터의 이력이 있어 당장은 조직 내부에서 그러한 역할을 할 수가 없다. 그래서 컨설턴트가 담당 구실을 함을 직간접적으로 경험할 수 있다.

KSUG 운영진에서 포럼을 메일링 리스트로 옮기자는 논의를 한참 해왔다. 운영진에서 어느 정도 의견을 정리하고 나서 포럼에서 회원 의견을 수렴을 시도하고 있다. 3일이 더 지났는데 여전히 4표만 표결하고 있다. 허수가 꽤 있겠지만, 1400명은 넘는 가입자를 갖은 포럼인데 말이다. 이런 정도 비율이라면 표결은 큰 의미가 없다. 사실 우리의 예상에 그대로 적중한 터라 별로 놀랍지는 않다. 일민 형이 사석에서 커뮤니티에서 활발히 활동하는 사람은 대략 1%라고 말할 기억이 있다. KSUG에서도 활발히 활동하는 회원은 14명을 넘지 않는 점을 고려하면 완전히 틀린 이야기는 아닌 듯하다.

결과를 예견하고 형식적인 의견 수렴일지도 모른다는 생각을 잠시 했었지만, 짧은 생각이었다. 커뮤니티의 힘은 커뮤니케이션 혹은 협업에서 나온다. 의미 없는 표결과 달리 전혀 예상하지 못한 값진 보석을 발견했다. bumjin님이 알려주신 링크인데 감동적인 글이다. 기계적인 번역이라 조금 어색하긴 하지만, 아래 표현을 보는 순간 바로 이거다 싶었다.


뒤이어 나오는 작성법은 일본인과 일해본 분이 한결같이 칭찬하던 바로 그것이었습니다. 마침 일민형이 순발력 있게 공감 120%의 포스트를 올렸더군요. 사무실에 함께 있던 물개 형이 굳이 포럼을 없애기보다는 새로 메일링을 만들라는 조언을 했다. kenu 형도 일민 형 블로그를 통해 비슷한 조언을 했다. 그전에 포럼에 올라왔던 의미 있는 지적도 있던 터라 그 방법도 괜찮겠다 싶었다. 일민 형은 둘 다 약해진다며 반대를 했다.

일단 하루를 보내고, 글을 쓰면서 1%를 떠올려보니 결심이 섰다. KSUG는 곧 만 3년을 맞이하고, 포럼은 만 1년을 바라본다. 그 기간에도 그리 큰 변화 없이 유지하던 1%를 반으로 나누면 커뮤니티의 강점인 커뮤니케이션은 빈약해질 수 있다. 마치 콩 한쪽도 나누는 듯한 느낌이다.

이제 와서 잘 써왔던 포럼의 가치를 무시할 생각은 없다. 이제 역할을 충분히 했다. 우리가 국내에선 보기 드문 하드코어(?) 세미나를 시도했던 초년의 추억이 1장을 장식했다면, 포럼은 KSUG의 2장이었고, 3장은 상조회 같은 형식이다. 예전에 시드니에 살던 형이 자바 사용자 그룹에 대한 인상을 '먹고 살기 위한 시장'이라고 했다. 그곳의 수장 벤 알렉스를 내가 알던 이미지와는 전혀 다르게 장삿속이 밝은 사람으로 묘사했다.

처음엔 나쁘진 않다 생각했는데 이젠 적극적으로 배워야겠다는 생각이 든다. 사회에서는 누구나 연대를 한다. 전경련, 노조, 의사협회, 변호사협회, 군인공제회, 사우회, 향우회, 동문회, ... IT 분야에서도 비슷한 모임이 속속 세를 키워가고 있다. 이런 면에서 가장 소외된 계층 중의 하나가 개발자다.

그렇다고 노동 운동 하자는 주장은 아니다. 지식 노동자 그중에서도 개발자가 서로 이익을 지키고 나누려고 해야 할 행동은 역할과 시대의 흐름에 맞아야 한다. 그에 대해 몇 가지 아이디어가 있지만, 아직 공론화하긴 이르다 생각한다. 논점이 빗나갈까봐 포럼에 국한해서 이야기하겠다. 처음 보는 아이디의 누군가가 가입 인사 후에 절박하다는 호소와 함께 두서없는 질문을 하고 그 후론 볼 수 없었고 이런 일이 반복적으로 일어나면 포럼에 애정을 가진 사람은 어떤 느낌을 받을까?

같이 운영을 하는 일민 형과 생각이 같은데 반해, 한 발 떨어져서 보는 객관적인 시각은 차이가 있는 이유를 여기서 발견할 수 있다. 스스로 포럼 자체가 아니라면, 어딘가 물어볼 곳이 있고 그곳에서 답변해준다면 당연히 좋지 않은가? 그러나 스스로 포럼이라면 항구가 되어 언제 올지 모르는 배를 무턱대고 기다려야 한다. 간혹 서글픈 노래를 부르면서 말이다.

그럴싸한 비유를 들면 현학적이라 말하는 이들이 배려해 직설적으로 이야기해보겠다. 스프링을 활용할 수 있는 넓은 영역에서 서로 다른 경험을 가진 사람과 이야기하고 조언도 구하고 싶다. 이런 일은 어느 정도 시간을 갖고 빈번하게 발생하는 교류를 통해 만들 수 있는 관계다. 그리고 함께 일할만한 개발자를 찾을 수 있거나 혹은 내가 일할 기회를 찾을 수 있다면 아마 더욱 열심히 활동할 것이다.

반대로 포럼을 만든 죄(?)로 의무감에 답변을 해주거나 그렇지 않으면 별 내용도 없는 포럼에 사용자만 늘어가는 모습을 지켜봐야 한다. 방금 전에도 포럼에서 스팸을 하나 지웠다. 이런 일을 계속하다 보면 슬슬 나는 포럼이 아니라고 발뺌을 하고 싶어질 수 있다.

* '춘계'라는 표현은 cbiscuit님이 처음으로 사용했음을 알리는 바입니다.

회사에서 흥미를 끄는 제목의 논문을 발견했다. 이단 편집의 영문으로 빽빽이 쓰인 논문을 모니터로 보는 일은 견디기 어려운 일이다. 출력을 해놓고, 집중력이 극대화할 수 있는 지하철 출퇴근 길에 읽기로 했다. 마침 저녁 약속에 가면서 펼쳐들었는데, 내용은 제목만큼 흥미롭지 않았다. 어렵고, 관심사에서 상당히 거리가 먼 내용이었다. 억지로 읽는 일은 시간 낭비란 판단을 하는 순간 막 교대를 지나고 있었다. 목적지는 사당이니까 몇 정거장 남지 않았다. 절약을 최고의 가치의 하나로 여기는 어머니를 둔 탓에 애써 출력까지 해온 논문을 대충 훑어보고 버리기가 아깝단 생각이 툭 튀어나왔다. 남은 시간 딱히 할 일도 없다. 빨리 판단을 해야 했다. 결론은 '남은 3 정거장을 지날 동안 논문에서 배울 점을 뽑아내자!'란 것이었다.

현대인은 말 그대로 정보의 홍수 속을 살아가기 때문에 필요한 내용을 빨리 찾아내서 소화하는 능력은 필수다. 그래서 종종 자투리 시간을 이처럼 소비하곤 한다. 다행스럽게 한 정거장을 남겨두고 찾았다.

논문은 Garbage Collection 메커니즘 개선을 다루고 있었는데, 메모리에서 중간 덩어리의(coarse-grain) 영역을 활용하여 접근 효율을 개선하는 이야기를 하고 있었다. 얼핏 RDBMS의 테이블 스페이스가 떠오르기도 했다. 마지막 결론에서 이러한 방식이 잠재적인 단편화(fragmentation) 이슈를 제거한다고 했다. fragmentation이란 단어를 보는 순간 퍼뜩 얼마 전 Kent 옹의 글을 읽고 머리에 담고 있던 생각이 스쳤다.

응집도(Cohesion)는 문제의 단편화(fragmentation)를 줄여준다는 사실이다.

와... 이런 찰나의 소박한 깨달음을 얻었다고 해서 당장 설계 능력이 급향상하지는 않는다. 삶을 행복하게 해줄 요인으로 보이지는 않는다. 하지만, 짧은 순간 목적한 바를 이루려고 노력하는 사이에 기대 이상을 얻어 기뻤다.그리고 이 티끌 같은 깨달음을 소중하게 생각하는 한 어느 날 불현듯 잊어버리고 살던 깨달음이 나를 찾아와 필요한 순간에 다른 깨달음을 낳게 도와준다.

대단한 일도 아닌 일로 자축하는 순간, 과거의 어느 날 나에게 도움을 주신 많은 분에 명시적으로 감사를 전하려고 한다. 먼저, 종이 한 장 아끼는 습관을 심어준 우리 엄마, 고객의 문제를 풀려고 산더미 같은 자료를 찾아가며 옆에서 고생하는 모습을 보여준 물개형^[각주:1], 며칠 전 좋은 글을 써서 생각할 기회를 만들어준 Kent 옹, 나를 낚은 살벌한 논문을 쓴 데이빗외 썬의 엔지니어들과 만족스런 생활을 영위하게 해준 우리 회사, 고객, 그리고 훌륭한 독서 공간을 제공한 지하철 공사에 감사를 드린다. :)

우발적인 장타였는데 이야기가 길어진다. 앞에 작성한 글이 주장하는 바가 불명확해 덧붙이는 글을 쓴다.

모델에서 코드를 생성하는 접근 자체에 대해 찬성과 반대 중에 한 가지 답만 하라면, 대답은 상황에 따라 다르다. 먼저 소프트웨어 공학의 미래를 위해선 이런 시도가 필요하다고 본다. 학교나 연구소에서 해야 할 실험을 프로젝트에서 시도하지만 않으면 말이다. 다음으로 모델링이나 설계를 공부하려는 개발자라면 강력 추천이다. 모델과 코드 사이에서의 추상화 수준의 차이를 이해하고, 모델링 도구와 IDE의 차이, 모델링 도구의 한계와 효용성 등을 알아야만 적절히 활용할 수 있다. 도구는 잘 알아야 잘 쓸 수 있는 법이다. 하지만 역시 공부는 개인적으로 해야지 프로젝트에서 제품을 만들면서 하는 방법은 옳지 않다. 프로젝트에서 코드 생성을 찬성할 경우는 언제일까?

아직은 행위 중심의 객체 설계가 힘든 현실을 인정한다면, ERD와 대응할 수 있는 수준의 도메인 객체의 관계를 뽑을 수 있는 프로젝트라면 모델과 코드의 연계를 권하고 싶다. 둘 중 한 쪽만 변경하고, 동기화를 하는 방법은 운영 단계에서 특히 효과를 발휘한다. 반면 운영 단계에선 모델을 쓸 생각이 없어 별도의 설계 문서를 요구한다면, 모델은 곧 현실과 마치 화석처럼 현실과 멀어질 수 있다.

Anemic model과 같이 객체가 데이터 운반이나 구조체 정도로 쓰이는 형국을 비난하는 말이 있긴 하지만, 대규모 프로젝트에서는 ERD와 대응할 수 있는 수준의 객체 모델을 만들어내는 경우는 극히 드물다. Level 1은 넘어야 다음 단계로 갈 수 있는 법이다.

컴포넌트를 채용해서 개발했고 즉, CBD이고 동시에 운영 단계에서 컴포넌트가 실제로 의미를 지니는 경우라면 컴포넌트 인터페이스는 모델과 코드 동기화를 확보하면 유용하다. 컴포넌트 인터페이스 변경은 상당한 공수를 요하기 때문에 유지보수를 맡은 개발자도 사람답게 살기 위한 절차를 마련해둘 수 있다. 필요한 시간을 보고하고, 모델을 수정해 작업 흔적을 남긴 후에 코드에 반영한다. 이 때, 자동생성하는 부분과 개발자가 작성하는 코드는 물리적으로 분리하기를 권장한다. 최근의 모델링 도구는 개발자가 작성한 코드에 덮어쓰기를 하는 일은 드물지만, 자칫 실수하면 여전히 기존 코드를 날릴 수 있기 때문이다. 또한, 모델 수준에서 의미가 있는 정보는 프로그래밍 코드 수준이 아니다. 그래서 코드에서도 추상화 정도가 높은 인터페이스 영역과 구현체를 분할하는 방법은 권장할만한 방법이기도 하다.

그러나 위와 같은 수준에 도달한 조직은 많지 않다. 아쉽게도 다음과 같은 현상을 자주 접할 수 있다.

• 프로젝트 주관사 혹은 고객사 QA 담당자가 한 가지 방법 허용한다면 표준화 하라고 한다. 내용면에서보면 강제하는 형식이 맞지 않는데도 말이다. 이런 경우는 획일화란 용어를 권장해주고 싶다.  
• 프로젝트 초기에 배운 방법이나 가이드나 나온 형식대로 방대한 UML 모델을 작성한다. 유스케이스 모델을 작성하다 보면 너무 간단한 내용을 어렵게 그리는 듯한 느낌을 받는다. 그리고 업무 별로 수 백개의 다이어그램이 거의 유사하다. 업무명이나 데이터를 담는 클래스 이름만 다르고 나머지는 거의 동일해서 모델링이 단순 작업으로 전락한다.
• 객체가 너무 많아 ERD를 역공학으로 읽어와서 객체 모델로 변경한다. 객체가 너무 잘게 쪼개져서 있어 걸핏하면 Join을 해야 하는 형국이다. 속성 이름이 대부분 약어라 도저히 알 수가 없다. 유지보수를 위해서는 엑셀로 테이블과 속성 이름을 설명하는 문서를 작성해야한다. (그렇다면 모델은 용도는 무얼까?)
• 중요한 업무 규칙은 UML 모델에 담기 어려워서 설계를 이중으로 하는 느낌이다. 그러는 가운데 개발 단계가 다가왔다. 일단 코드를 만들어야 하는데, QA 담당자가 설계를 완성하고 코드 생성을 통해서 만든 코드로만 구현을 하라고 한다.
  
• 공동작업하던 모델이 마구 꼬인다. CVS/SVN/ClearCase 등을 연계해서 써보니 충돌을 해결하는 작업이 너무 힘들다. 그냥 동시에 작업을 하지 못하게 하고 공통으로 쓰는 객체는 공통 담당자를 두어 통합하게 한다. 막판에 일이 몰리면, 통합 담당자가 죽어 나거나, 암묵적 합의에 의해 대강 알아서 해결한다. (동일한 쓰임을 갖는 객체가 다른 이름으로 여러 개 존재한다.)
  

더 길어지면 자칫 비관적인 글로 오인할 듯 해 그만둔다. 이야기가 너무 길어질 해서 이제 마무리를 해야겠다. 느닷 없긴 하지만 MDA를 소개하고자 한다. 쉽게 말해 MDA는 모델과 코드를 좀 더 유기적으로 연계하여 개발 공정을 개선하려는 시도이다.

앞서 언급했던 2003년 프로젝트에 참여할 당시 모델링 도구에 대한 환상을 가지고 있던 나에게 가장 획기적으로 보였던 도구는 MDA 툴이었다. 당시는 OMG가 MDA 판촉에 열을 올리던 때였고, 아크스타일러, 카비라가 시장 선도 업체였다. 당시 시장 선도 UML 모델링 도구였던 Rose나 2인자 Together는 선언부 정도의 코드는 모델과 코드 사이의 양방향 변환, 일명 RTE(Round-Trip-Engineering)를 지원했다. 그 수준도 조악하다 느낄 정도였는데, 여하튼 내부 구현 코드 생성은 이상에 지나지 않았다. 그러던 차에 만난 카비라 시연은 놀라웠다. UML 모델에 몇 가지 규칙을 일종의 스크립트로 입력한 후에 적용한 플랫폼 유형을 선택하고, 변환을 시도하면 해당 플랫폼에서 구동 가능한 모델(Platform Specific Model)이 나오는데 이는 바로 실행이 가능했다. 놀라움은 얼마 가지 않아 궁금함으로 바뀌었다. 가변적인 업무 규칙을 어떻게 스크립트 언어만으로 표현할 수 있고, 접속자가 많아지면 과연 그에 맞게 규모 가변성(Scalability)를 제공할까?

쉽게 답을 찾을 수 있었다. 해당 툴을 도입해서 팔려던 시도는 결국 국내에서 한 곳도 레퍼런스를 찾지 못하고 실패로 돌아갔다. 지금 보니 해당 업체도 방향을 약간 전환한 듯 하다. MDA를 위해 등장한 UML2.x는 많이 발전한 듯 보이지만, MDA는 여전히 무척 느린 행보로 진행하고 있고 얼마후 등장한 MDD는 MDA로 가기 위한 과도기 성격처럼 보인다. UML을 전문적으로 연구하는 어떤 분의 말에 따르면 유럽의 자동차 업계에서 MDA는 실적이 있다고 한다.

하지만 정보시스템/엔터프라이즈 영역에서 가변적인 요소를 체계적으로 정리해서 정형화를 단기간에 하겠다고 한다면 이는 풋내기로 볼 수 밖에 없다. 마틴 파울러가 illogic이라고 표현한 기업/조직의 역사가 만들어낸 일반화 하기 힘든 비즈니스 규칙을 수식으로 풀어내기엔 소프트웨어 공학은 아직 많이 어리다. 솔직히 내 생전에 얼마나 비슷하게라도 가능할지 의문이긴 하지만, MDA는 어찌 보면 많은 소프트웨어 공학 관계자에겐 꿈이자 실현 가능하게 보이는 지향점이다.

소프트웨어 설계를 논할 때 항상 등장하는 개념이 결합도와 응집도(coupling and cohesion)이다. 최근 Kent Beck이 Coupling and Cohesion라는 글을 썼는데, 변화에 대한 비용을 기준으로 해석했다.


너도 나도(?) 갈망하는 클래스/요소^[각주:1] 사이즈의 기준을 말해준다. 너무 작으면 변경이 필요한 경우 여러 클래스/요소 여럿을 수정해야 한다. 반대로 너무 크면 일부만 수정해야 한다. 프로그래밍 요소를 대개 클래스로 볼 대변할 수 있지만, 좀 더 세밀하게 함수 단위로 보거나 더 큰 단위를 구성하기 위한 단위를 쓸 수 있다. 너무 크거나 작으면 변경하기 어렵다. 그 중에서도 특히 너무 크면 Kent Beck 지적대로 변경할 부분을 찾는 비용과 함께, 바뀌지 않아야 할 부분은 정말로 바뀌지 않았는지 확인할 필요가 있다.

굵게 표기한 부분은 최근 JUnit 테스트를 작성할 때, 부작용이 없나 테스트하는 코드를 작성했던 관습이 떠오른다. 적절한 단위를 Single responsibility principle라는 원칙과 연결해 말할 수도 있다. 하지만 Kent Beck이 설명이 좀 더 피부에 와 닿는다.

얼마전 지인이 'TDD를 하면 설계가 필요없는 줄 알았다'고 쓴 글을 본 일이 있다. TDD가 설계/구현의 빠른 루프를 통해 유기적인 설계를 가능하게 하는 기법임에도 불구하고, 비슷한 오해를 하는 사람을 여럿 봤다. TDD 과정 중 일부인 기능 구현 후 리팩토링은 동기는 중복 제거이다. 중복 제거는 결국 변화가 발생할 때 수정할 부분을 하나로 줄여준다. 이는 Single responsibility principle를 지키기 위한 실행 방안의 하나 이며, cohesion을 높이는 방안이기도 하다.

내가 이 글을 쓸 때 쯤 토비님이 대충 끄적인 장타가 있는데 읽어 볼만하다.

앞서 UML 모델링 도구에서 코드를 생성하는 기능에 대해서 살펴보았다. 이번에는 UML 모델링 도구를 사용하는 다양한 방법에 대해서 말해보려고 한다.
 
하얀말님의 댓글에 이런 표현이 있다.

개인적으로 'UML은 걍 모델이지 프로그램 소스 같은 실물은 아니다'고 생각하고, 모델의 목적은 '아, 이렇게 개발하면 되겠구나' 하는 영감을 주는 것, 딱 그 정도라고 생각하므로, 소스 생성은 아무 것도 없어 막막할 때 템플릿 수준으로 뭔가를 만들어서 개발을 부트스트래핑할 때 정도 쓸만하다는 생각을 가지고 있습니다. 덧붙여 모델링 산출물 내놓으라고 사람 들들 볶지만 시간이 갈수록 그렇게 만든 모델과 현실이 틀려지는 현상을 많이 보기도 해서...

공감하는 내용이다. 이해/경험/역할이 다른 사람이 개발에 참여하는 소위 SI 프로젝트에서는 가장 효과적인 접근이라 생각한다. 하지만 아쉽게도 모델에 너무 많은 내용을 담아두는 관행이 팽배해 있다. 모델에 많은 내용이 담겼다는 사실을 가지고 나쁘다 할 수 없다. 오히려 그 반대다. 하지만 경제성 측면에서 실패 사례는 많은 반면, 성공 사례는 찾아보기 힘들다. 소프트웨어는 한 번 개발하고 치워버리는 일이 아니다. 보통은 처음 개발할 때보다 유지보수 비용이 더 크다.^[각주:1]

모델과 코드를 상호 동기화 하는 경우 변경 요청이 발생하면, 코드만 고치는게 아니라 모델을 수정해야 한다. 요구사항 변경을 요청한 사람은 코드 수정을 기다리고 있다. 대개는 코드 수정 이후 운영하는 시스템에 배포 하면 발 쓰인다. 그러나 모델은 코드와 달리 바로 쓰이지 않을 수 있다. 훗날 해당 시스템 유지 보수 담당자가 바뀔 때 쓰이거나 다른 사람이 해당 시스템을 확장하거나 같은 기능을 하는 새로운 시스템을 새로 개발할 때 볼 수도 있다. 그때까지 일어난 변경을 한 번에 반영하면 정보의 누락이 발생한다. 따라서, 쓸모 있는 모델을 만들기 위해서는 코드 수정 이후 혹은 그 이전에 변경 사항을 바로 반영해야 한다. 

모델은 추상적인 정보이기 때문에 코드와 1:1 대응하지 않는다. 다시 말해 코드와 관계가 단순 변환이 아니라 인간의 해석이 필요하다는 의미다. 따라서 적절하게 모델을 작성했는지 검증하는 과정이 필요하다. 모델을 작성한 본인이 검증하기 보다는 타인을 통하면 객관성을 확보하기 좋다. 설명에 드러나듯 모델과 코드를 함께 수정하려면 더 많은 사람이 필요하고, 작업의 선후 관계 등을 반영한 프로세스가 필요하다. 물론 이를 자동화 할 수 있다. 하지만 꽤 많은 돈이 든다. 이를 돕는 도구가 있기 하지만, 사용하는 조직에 맞추는 일은 도구 구매 자체만으로는 절대 해결되지 않는다. 그간 일하는 방식에 상당한 변화를 주어야 하므로, 변화에 적응할 시간도 필요하고, 필요하다면 인력 충원이나 조직이나 역할 개편이 필요할 수도 있다.

내가 하얀말님의 댓글에 동의하는 첫 번째 이유는 많은 조직이 모델과 코드 동기화를 선택할 때, 이러한 후속 조치에 대해서 감안하지 않고 성급하게 결정하는 일을 자주 보았기 때문이다. 그 결과는 급작스런 변화와 작업량 증가에 따른 갈등, 고통, 불화 혹은 사실상 아무도 보지 않는 모델을 만드는 일이다. 

한 가지 이유가 더 있다. 모델과 코드의 동기화의 전제는 양자가 모두 가치가 있을 경우다. 하지만 모델이 별 의미가 존재한다는 사실 이외에는 별 의미가 없다면 어떨까? 혹은 10% 정도의 정보만 활용을 한다면 그래도 동기화가 필요할까?

수 년간 경험한 사이트, 그리고 간접 경험한 많은 사이트에서 모델이 제 구실을 한 경우는 많지 않았다. 이유는 쉽게 찾을 수 있다. 많은 곳이 다음과 같은 시행착오를 범하고 있었다.

• 진정한 필요에 의해서가 아니라 유행이나 당위로 UML을 받아 들인 터라 객체 지향 모델링을 할 수 있는 인력이 없고, UML이나 객체 지향 모델링을 배워서 한다. 짧은 기간으로 인해 제대로 설계하기가 힘들다. 프로젝트가 다 끝날 즈음에 모델링을 왜 하는지 이해했다는 분석가/설계자가 나타난다.
  
• 자바 클래스를 만들기에 용어집 내용이 턱 없이 부족하다. 개발자가 작명 지침에 따라 한글 상태의 클래스 이름을 인터넷 영문 사전을 검색해서 급하게 영어로 바꾼다. 콩글리시나 난무하고, 개발자에 따라 동일한 어휘에 대해 다른 영문을 쓰기도 한다.
• 컴포넌트 수준에서만 모델링을 하고, 객체는 데이터베이스 테이블에서 역공학으로 추출한다. 암호수준의 약어로 만든 클래스를 바꿀 엄두가 나지 않아, 일단 개발부터 한 후에 모델을 제출하기 직전에 적당하게 바꾼다. 개발자가 몇 백명인 프로젝트에서 많이 나타나는 현상이다.
• 반드시 모델을 갱신한 후, 코드에 반영하게 했더니 엄청나게 진도가 더디다. 결국 버티다 못해 프로젝트 막판에 몰려 모델은 잠시 잊고 개발부터 제대로 한다.
  
• 형상 관리 도구를 써서 공동 작업을 하다 모델이 완전히 꼬였다. 소스 코드와 같은 텍스트 파일이 아니다 보니 모델 통합이 매일 골치 덩어리다.
  

UML 모델은 충분히 효용성이 있지만 추상화 수준을 낮춰 코드와 동기화 하는 일은 제한적으로 사용하길 권장한다. 대규모라고 할 수 있는 프로젝트라면 모델과 코드 동기화는 아예 하지 말라고 말하고 싶다. 특히 도메인 어휘의 체계 수립이 없이는 팀 작업 규모의 모델링 자체가 무리다. 용어집을 제출용으로 사용하는 프로젝트라면 UML 모델도 요식행위에 가깝다. 모델은 추상적인 정보다. 따라서 동기화를 하더라도 1:1은 답이 아니다. 모델과 코드는 존재 이유와 구성 방식이 모두 다르기 때문에 다른 체계를 통해 관리해야 한다. 아직은 이러한 체계를 확립하기에는 대부분의 조직의 모델 활용 경험이 높지 않을 것이다.

내가 주로 UML 모델링을 효율적으로 쓰는 경우는 복잡한 상태를 변화를 이해/표현하기 위해 상태도를 작성하는 경우와 핵심 클래스 사이의 관계를 포착하고 싶을 때 그리는 몇 장의 클래스 다이어그램, 솔루션 연계에서 비롯한 복잡한 상호작용이나 스펙을 구현해서 발생하는 복잡한 콜백 관계를 이해/표현하기 위해 그리는 시퀀스 다이어그램 정도다.

프로젝트를 마친 이후 조금 지치기도 하고, 블로깅 소재도 없어서 글을 자제하던 차인데 아쉬운 SoC 논쟁을 읽고 마음이 움직였다. 일부 잡음과 달리 이 글을 보고 일민형이 한 마디 해달라고 한 것은 자신은 모델링 전문가가 아니니까 잘 아는 니가 글을 써달라는 것이었는데, 귀차니즘의 늪에 빠진 터라 대충 썼더니 자극적인 표현 탓인지 결과가 이상한 방향으로 튀었다.

소란이 있었으니 SoC는 제쳐두고 내가 애증을 갖고 있는 UML 모델링 관련 부분만 글을 쓰고자 한다. 이 글의 댓글을 보면 내가 하고 싶은 말을 대신한 내용이 있다. 그래서 이를 살려내서 활용하고, 본문에서 오해의 소지가 있는 부분에 대응하여 요즘 UML 툴을 배우시는 분이 잘못 판단하지 않도록 경험을 나누고자 한다.

이 글에선 복잡도를 해결하는 도구로 코드 생성 방법을 이야기하고 있다. 코드 생성이야 오래 전부터 하던 일이니까 새로운 내용은 아니다. 저자는 이상적인 코드 생성 방법으로 UML 모델을 사용하는 방법을 제시했다.

저자의 견해는 존중하더라도 '10년차 대선배'를 동원해서 권위를 부여할 만큼 '비기'는 아니다. 일단 오래 전부터 실제 프로젝트에서 쓰여왔고, 이미 많은 시행착오를 통해서 Lessons Learned가 쌓였다. 하지만 실패 사례를 널리 공개하지는 않는 터라 모델링 실전 경험이 없는 분들에겐 정보를 접할 기회가 없을 뿐이다.

UML 등장 이전에도 모델에서 코드를 자동 생성하는 CASE 툴은 종종 쓰였다. UML 모델링 도구에 집중하면 대표 주자는 역시 Rational Rose다. 우리나라만 놓고 보면, 90년대 후반 혁신적인 툴로 Rose가 등장했다. Rational은 2003년 IBM에 인수되기 전까지 혁신적인 소프트웨어 공학 도구를 시장에 출시했다. 어디 툴 뿐인가? 여전히 우리나라 주류 방법론의 골격을 이루는 방법론인 RUP 그리고 UML도 그들이 만든 결과물이다. 내가 Rose를 처음 접한 때가 2000년 정도였나? 이미 그때도 UML 모델에서 Java/C/C++ 정도의 코드는 생성이 가능했다. 본격 코드 개발 환경과 통합하는 XDE도 있었다. Rose에서도 Script 기반의 SDK를 내장해서 제공하기도 했다. 기능의 존재만 놓고 보면, 10년 전에도 실제 프로젝트에도 EA가 제공하는 기능이 쓰였다.

다른 점이라면 수년이 지난 EA의 최신 버전이 편의성 면에서 훌륭하다는 점이다. 게다가 가격은 Rose와 비교할 수 없이 싸다. 그러니 아래와 같은 댓글은 적정한 평이라 할 수 있다. Rose는 2000년 이후 별 발전이 없었다. 그나마도 2003 버전이 마지막 메이저 버전이다.


굳이 꼬치꼬치 따진다면, EA는 Rose와 비교하기 보단 RSA(IBM Rational Software Architect)와 비교해야 적절하다.  EA는 비교적 최근에 나온 툴이니 기능성에서 비교하긴 무리가 있다. Rose에서 코드 생성 기능을 그대로 쓰기는 힘들다. '엄하다'는 표현이 경험에서 비롯되었다 추측할 수 있는데, 예전에 이런 일이 있었다.

Java 코드를 UML 모델로 변환하려고 리버스 명령을 실행시키고 멍하니 로그를 쳐다보지 않으려고 커피를 마시고 왔다. 구둣점이나 주석의 특수 문자 탓에 실패하면, 다시 처음부터 해야 해서 리버스 품질은 매우 낮았다. 코드 생성도 비슷하다. 타입 지정을 위한 클래스가 모두 모델에 로딩시켜야 코드 생성이 가능해서 무척 번거롭다. 그래서 투게더가 좋다고 주장하는 사람이 있었는데, 그렇지는 않다. 투게더는 Rose + XDE에 해당한다. XDE는 모델과 코드 동기화를 보장하는 도구였는데, 비주얼 스투디오나 WSAD와 함께 쓸 수 있었다. IBM에 합병한 후 IBM Rational Software Architect 나 IBM Rational Software Modeler 로 대치되었다.

나에게 UML 모델링 도구를 고르라면 단연 EA를 선택할 것이다. 그 이유는 가격에 비해 성능이 좋기 때문이다. 경쟁 도구가 몇 천 만원을 호가할 때 EA는 10만원 내외였다. 지금을 가격이 얼마나 하는지 모르지만, 가격은 타사에서 따라올 수가 없다.

저자는 큰 고민 없이 투게더를 추천했는데, 아마 투게더를 많이 써보진 않은 듯 하다.


아래에 인용한 댓글의 작성자 의도는 무엇일까? 얼핏 보아도 실무 흐름을 잘 아는 분인 듯하다.


내가 실전에서 투게더를 써본 경험은 두 번이다. 2003년 봄이던가? 모통신사에서 파일럿 프로젝트를 할 때였다. JCP Initiative의 Reference Implementation를 분석하는 일을 맡았는데, 하나의 요청이 대해 수 십 ~ 수 백 개의 메소드 호출로 구현되어서 파일을 따라 가면서 보는게 죽을 맛이었다. 당시에 이클립스가 있었다면 좋았을텐데... 자바에선 비주얼 스투디오같은 변변한 툴이 없었다. 그래서 역공학을 활용했다. XDE는 너무 무거워서 투게더를 썼다. 당시 최고 사양의 IBM ThinkPad에 RAM 최대로 끼워서 쓰는 경우, 밥 먹고 오면 아주 복잡한 메소드 하나의 후속 호출 관계를 나타내는 시퀀스 다이어그램 하나 정도는 그려줬다. 그 용도가 전부였다. 당시 또 다른 통신사 프로젝트에서 닷넷 기반에 투게더를 썼다가 모델이 너무 커져서 로딩을 못하는 해프닝이 벌어졌다.

왜 이런 일이 발생할까? 모델과 코드를 동기화 하려면 고작 인터페이스 수준이라 할 지라도 라이브러리/프레임워크 정보가 필요하다. 파일 형식이 차이가 있긴 하지만, 쉽게 생각하면 시스템이 사용하는 모든 jar나 dll을 올려야 한다고 생각하면 비슷하다. 투게더로 대형 사이트를 해본 경험이 없어서 겪은 어처구니 없는 시행착오였다. 어떻게 해결했을까? 전해들은 이야기로는 결국 툴 판매 업체에서 가내 수공업(?)으로 모델을 보고 나누어서 새로 그려서 해결해주었다고 한다. 추측컨데 그 후 누구도 감히 모델에 손을 데려고 하지 않았을 것이다.

기존에 구매한 터라 투게더를 쓰시는 분은 있겠지만, 최근에 투게더를 구매해서 쓰는 분은 아마 없을 듯하다.

저자가 소개한 EA나 EA의 코드 생성 기능은 훌륭하다. 특히 EA의 가격을 생각해보면 감탄하지 않을 수 없다. 이왕 정리하는 김에 모델링 도구에 대한 기존 글 링크도 달아 보았다.

- 종종 올린 EA 관련 팁
- RSA 관련 글

역공학에 대해서도 주의해서 활용하시라는 의미로 지난 글을 올려본다.

- 역공학 무용론(?)

미네르바 추천 도서라고 해서 읽었다. 출/퇴근하면서 만 읽긴 하지만, 한 달이나 걸렸다. 구분해서 인식했던 경제학과 역사를 잘도 섞었구나 싶었다. 그러나 후반부에 다다를수록 그간 이미지로만 인식하던 세상의 참모습을 보는 듯한 느낌에 영화 '매트릭스'가 떠올랐다. 현대 경제학 원리를 설명하는 후반부는 다소 지루했지만, 주변 사람에게 짜임새 있는 역사책으로도 소개해줄 법하다. 이 책은 또 나를 자본론이라는 두툼하고도 무거운 책으로 이끌었다. 과연 이 두툼살벌한 책을 몇 년 안에 읽어낼 수 있을까?

기타 메모

'더 진취적인 영주들은 예전에 황무지였던 땅을 임대해 주는 이 사업에서 커다란 성공을 거뒀고, 어떤 영주들은 자기가 보유한 미개간지에 온전한 촌락을 건설하는 데 성공해 이득을 얻었다.' 65쪽

blue ocean도 황무지 개척의 다른 이름일 뿐이다.

'역사는 변화의 기록이다.' 86쪽

'이 시대에 일어난 한 가지 중요한 변화에 주목하라. 토지는 토지에 투여한 노동량 때문에 중요해진다는 낡은 관념이 사라졌다. 상공업의 발달과 가격 혁명은 화폐를 인간보다 더 중요한 존재로 만들었다.' 139쪽

'여왕은 두 번째 원정에서 노예 무역상 호킨스에게 배를 임대해 주었다. 그 배의 이름은 예수호였다.' 204쪽

'그러므로 자본주의 체제로 향한 길을 개척하는 과정은 다름 아닌 노동자가 생산수단을 소유하지 못하게 하는 과정이다.' 206쪽

'시민 정부는 그것이 재산을 보호하기 위해 세워진 것인 한 실제로는 가난한 자들에게서 부자를, 아무 것도 가지지 못한 자들에게서 재산을 지키기 위해 세워진 것이다. (애덤 스미스의 <<국부론>>에서)' 237쪽

'그러나 통례로 볼 때 이 분쟁에서 두 당사자 중에 누가 유리한지를 예견하기는 어렵지 않다. ... 고용주들은 수가 적기 때문에 훨씬 쉽게 단결할 수 있다. 게다가 법은 고용주의 결사는 승인하거나 아니면 적어도 금지하지는 않지만, 노동자들의 결사는 금지한다. 임금을 인하하기 위한 결사를 방해하는 의회 법은 하나도 없다. 그렇지만 그것을 인상하기 위한 결사를 방해하기 위한 법은 많다. (애덤 스미스의 <<국부론>>에서)' 240쪽

'개인은 누구나 자기가 지배하는 자본을 가장 유리하게 사용하는 방법을 찾아 내려고 끊임없이 노력한다. 그가 염두에 두는 것은 진정 자기 자신의 이익이지 사회의 이익이 아니다. (애덤 스미스의 <<국부론>>에서)' 247쪽

'1870년 이후 시기는 미국에서는 트러스트의 시대였고 독일에서는 카르텔의 시대였다. 경쟁은 독점으로 대체됐다. 거물들은 조무래기들을 사업에서 몰아냈다. 대기업은 소기업을 찌그러뜨리거나 합병함으로써 거대해졌다. 어디서나 성장, 합병, 집중이 있었다. 거대 산업이 형성되고 있었고, 독점을 향해 나아가고 있었다.' 298쪽

19세기의 일만은 아니다. 재벌, 지주 회사 이런 수준 정도는 치우고서 봐도 심하다. 작은 커피숍은 거의 족적을 감췄고, 건물 하나를 차지하는 대기업의 커피 체인을 쉽게 찾아 볼 수 있다. 동네 슈퍼는 하나 둘 문을 닫는 지금, 대기업이 슈퍼 체인에 속속 참여한다. 어디 그 뿐인가.. @@

'생산이 한계에 달했기 때문이 아닙니다. 생산의 한계를 결정하는 것은 굶주린 사람의 숫자가 아니라, 구매하고 지급할 수 있는 돈주머니의 숫자이기 때문입니다. 돈 없는 사람, 이윤의 관점에서 쓸모가 없는 노동자, 그래서 구매력이 없는 노동자는 죽음의 나락으로 떨어집니다.' 321쪽

'지금까지 뉴딜 정책이 한 일 가운데 지진이 할 수 있었던 것보다 나은 일은 아무 것도 없다. 해안을 따라 1급 지진이 발생했다면 훨씬 효과적으로 물자가 부족해지고 모든 생존자가 대기업의 더 큰 영광을 위해 노동하도록 강요받았을 것이다. 뉴딜 정책보다 훨씬 더 빠르고 훨씬 더 조용하게 (스톨버그와 빈튼의 변)' 338쪽

리팩토링의 당위성
리팩토링은 분명 중요한 작업이지만, 관리자나 고객 입장에선 눈에 보이지 않는 작업이다. 구조적 개선은 가시적인 결과를 보여주기 힘들기 때문이다. 기능을 추가한다거나 버그를 수정한다면 누가 봐도 목적이 분명하다. 그러나 리팩토링의 경우는 부가적인 개선으로 보일 수 있다. 사실 기능적으로만 놓고 보면 리팩토링 전후에 차이가 없으므로 부가적이란 표현도 틀리지 않다. 사정이 그렇다 보니 리팩토링은 뒷전으로 밀릴 수 있다. 경우에 따라 코드 개선 활동으로 긴 작업 시간을 소비한다면 무능한 사람 취급할 수도 있다.

린 소프트웨어 개발(Lean Software Development)의 주요 원칙은 리팩토링의 중요성에 대해 시사하는 바가 크다. 품질을 내재화하라는 원칙을 설명하는 내용에서 다음과 같은 글을 발견할 수 있다.


그럼에도 불구하고 관리자의 인식이 다를 수 있다. 린 소프트웨어 개발에서 소개한 하버드 비즈니스 스쿨의 앨런 맥코맥(Alan MacComack)의 연구는 시사하는 바가 크다. 최적의 설계를 갖고 있었고 그렇게 만들어진 시스템이 초기 명세와 매우 가까운 ‘좋은’ 프로젝트와 개발팀이 시장의 변화를 이해하고 대응하기 위해 싸우는 동안 계속되는 변화를 겪은 ‘나쁜’ 프로젝트를 비교하는 연구인데, 놀랍게도 회사의 관리자들은 시장에 대해 계속해서 학습하고 시장을 만족시키는 제품을 만들어내는 프로젝트를 ‘나쁜’ 것으로 생각했다.

그렇지만, 무턱대고 관리자의 통념이 깨지기를 기다려서 리팩토링을 할 수는 없는 일이다. 필자가 만나본 어떤 조직에서는 새로운 기술 표준에 맞춰 대대적인 내부 솔루션 변경을 하는 경우에도 경영진을 설득하지 못해 실적으로 보고할 수도 없는 유령 작업을 하느라 고생한 일이 있다고 했다.


그림 6은 리팩토링을 통해 코드량을 줄인 성과를 도표로 나타낸 자료다. 종종 관리자와 경영진 설득을 위해 리팩토링 효과를 정량화 하는 노력이 필요하기도 하다.

전체를 최적화하라
다시 한번 린 소프트웨어 개발의 일부를 인용한다.

설계 원칙 강화에 효과적인 동료 검토
필자의 프레임워크 개발 프로젝트에서 초기에는 품질 보증 활동을 했으나, 프로젝트가 중반 이후로 접어들자 품질 보증은 점차 큰 부담이 되었다. 품질 보증 담당자가 다수의 개발자가 만드는 프레임워크 전체를 이해하고 코드가 적절한지 판단하기 힘들어졌다. 품질 검토를 누락한 부분은 이후에 고스란히 유지보수가 어려운 부분으로 남았다. 개발자가 유지보수 담당자와 같거나 같은 조직에 속하는 경우에는 덜하지만, 개발만 하고 빠지는 외주 개발에서 품질 보증이 소홀한 경우를 흔히 볼 수 있다. 예산과 납기라는 제약이 있기 때문에 어떤 프로젝트든 타협을 한다. 그렇기 때문에 품질 보증 수준과 미흡한 부분에 대한 향후 대책이 중요하다.

우리 팀은 프레임워크 배포 이후에 프레임워크를 적용하면서 새로운 요구사항에 수렴하면서 프레임워크를 진화시키는 프로젝트를 수주했다. 프로젝트 초기 우리가 가장 먼저 한 활동은 리팩토링이었다. 이미 프레임워크를 배포한 상태이므로 API 수정은 어려웠지만, 내부 개선에는 지장이 없었다. 코드가 간결해지고, 전체적으로 일관성이 높아졌다. 아쉽게도 앞선 프로젝트와 동일한 팀원으로만 구성할 수 없어서 다른 사람이 작성한 코드를 리팩토링 해야 할 때, 난이도가 높거나 별도 지식이 필요한 솔루션 연계를 다룬 경우라면 손을 대기 힘들거나 많은 시간을 요했다.

만일 타임머신을 타고 과거로 돌아간다면 프로젝트 관리자 혹은 팀장으로서 어떻게 조치할 수 있을까? 짝 프로그래밍(Pair Programming)을 시도해보고 싶다. 이전에도 시도는 했다. 그러나 10주 만에 고객에게 무언가 입증해내야 하는 부담이 있어 포기했다. 팀 문화를 바꾸는 일은 단기에 이룰 수 없다. 그렇다고 해도 짝 프로그래밍을 시도하면서 점차 팀에 어울리는 방법으로 바꿔갈 수 있을 것이다. 가령, 빈번한 동료 검토 수준으로 완화할 수도 있다. 분명한 점은 코드 수준에서라면 품질보증 담당자를 별도로 두는 방식보다는 단위 테스트 그리고 동료 검토가 효과적이란 사실이다. 협업을 강조하는 애자일, XP 진영에서는 짝 프로그래밍 이외에도 시도해 볼만한 많은 프랙티스를 제시한다.


인수인계를 활용한 체계 강화
인수인계시점은 설계 원칙 구현 정도를 점검하고, 강화할 수 있는 기회이기도 하다. 이 글은 주로 프레임워크 개발자와 유지보수 담당자 사이의 인수인계를 배경으로 하지만, 선임자와 후임자 사이에서도 크게 다르지 않다.

필자는 인수인계시점에 다음과 같은 3계층으로 우리가 만든 산출물을 분류해 인식하기로 했다.  어떤 내용은 프레임워크 사용자 수준에서 개략적인 논의를 하는데 도움이 된다. 가령, 제품 설명서 내용이나 가이드 서두의 개요 등이 여기에 해당한다. 프레임워크를 유지보수 하는 개발자나 프레임워크를 특정 상황에 맞게 수정하는 개발자라면 다른 정보를 필요로 한다. 어떤 API를 수정해야 하는지 정도는 필수 정보이고, 정상적으로 작동하도록 수정하기 위해서는 단순히 확장 지점에 대한 이해만으로 부족한 경우가 있다. 프레임워크가 구동하는 주요 메커니즘은 알아야 한다. 특정 부분 메커니즘에 대해서는 아주 세밀하게 알아야 할 수도 있다. 이를 위한 설계 방안과 구현 및 테스트 코드를 모든 기능마다 구비하고 정리해둘 수 있을까?


경제성을 고려하지 않는다면 가능하다고 하겠지만, 대개의 경우 실용적인 방법이 아니다. 우리는 먼저 코드를 논리적으로 적절히 나누어서 인수인계 일정을 수립했다. 그리고 코드 작성자가 주안점으로 삼을 사항을 기록하여 인수인계 받을 담당자에게 전달했다. 주안점을 중심으로 인수인계를 받으면서 코드를 이해하고, 향후 요구사항이 있을 경우 확장할 부분 그리고 확장 방안을 습득하게 했다. 설계 메커니즘 설명이나 확장 방안은 먼저 변수나 메소드 이름 수준에서 리팩토링을 수행해 가능한 코드 수준에서 이해할 수 있게 한다. 변수나 메소드 이름을 변경해도 난해한 부분 중에 하나 이상의 복잡한 문제를 함께 해결하려 하는 코드가 있다면 하나의 역할만 하도록 변경한다. 이쯤에서 머리도 식힐 겸 쉬운 비유를 하나 들어보겠다. 영화감상을 통해 영어공부를 하는 방식은 효과적일까? 대개는 그렇지 않은데, 그 이유는 다음 그림에서 보는 바와 같다.



시작은 영어 공부로 했어도 영화에 빠져 영어 듣기는 뒷전이 될 수 있다. 자칫 여배우의 외모에 혹해 아예 영어 공부는 안중에도 없어질 수 있다. 비유가 프레임워크와 너무 동떨어져있다고 생각하는가? 그렇다면 위 그림에 대입할 수 있는 코드 예제를 떠올려보자. 만일 XML 파일과 함께 HTTP요청을 수신하는 서버 클래스 로직을 생각해보자. 요청을 수신한 클래스^[각주:1]에서 요청 내용을 확인해 적절한 클래스로 보내는 작업을 하는데 XML 파일을 읽어 데이터를 적절한 형태로 변경하는 로직까지 담당한다면 어떨까? 엄청나게 긴 코드로 인해 해당 클래스의 역할에 대해 인지하기도 힘들고, 그에 따라 수정 역시 어려워진다. 리팩토링을 통해 하나의 클래스에 하나의 역할만 부여했다고 해도 복잡한 선택에 따라 if-else 코드를 피할 수 없는 경우가 발생한다. 이 경우는 조건에 따라 달라지는 내용에 대해 API 설명(javadoc 주석)으로 설명하게 하고, 여러 객체에 걸쳐서 설명할 부분이라면 그때 비로소 설계 가이드 혹은 확장 가이드에 설명하도록 했다. 기계적인 표준화에 따라 작성하는 경우 종종 불필요하거나 중요하지 않은 내용마저도 많은 분량의 가이드로 남는다. 종종 이는 유지보수 부담을 준다. 게다가 내용이 지나치게 많으면 중요한 내용을 찾는데 방해가 되기도 한다. 이와 같이 체계 수립은 별도의 소수의 인력 위주로 진행하기 보다는 체계를 유지해야 할 사람이 직접 참여하는 것이 효과적이다.

애플리케이션 프레임워크[footnote]여기서 ‘프레임워크’는 애플리케이션 프레임워크(Application Framework)를 지칭한다.[/footnote] 설계 원칙과 리팩토링
이 글은 애플리케이션 프레임워크 설계 원칙과 이를 확립하려는 방안, 그리고 그 목적으로 리팩토링을 이야기한다. 프레임워크를 쓰는 코드를 의인화해서 사용자로 본다면, 사용자마다 각자의 이해에 따라 프레임워크를 다르게 사용하기를 원할 수 있다. 프레임워크가 보다 유용하려면 이러한 다른 요구를 수용하면서 일관성과 유지보수 용이성을 확보해야 한다. 복잡한 요건과 잦은 변화가 필연적인 현재 업무 환경을 고려하면 설계 원칙을 유지하는 데 있어 리팩토링은 꼭 필요하다. 앞서 다른 글에서 리팩토링에 대해 많은 이야기가 있었기 때문에 현장에서 간과할 수 있는 내용을 담도록 하겠다.

애플리케이션 프레임워크설계 원칙
지인의 블로그 포스트 ‘Application Framework 개발의 원칙’을 읽은 시점은 프레임워크 개발 프로젝트를 시작해서 3개월쯤 지난 때였다. 그렇지 않아도 프레임워크의 정체성에 대해 고민하던 차였기에 시사점이 컸다. 주요 내용을 발췌하면 다음과 같다.

애플리케이션 프레임워크 개발에는 분명한 목적과 철학이 있어야 한다. 이 프레임워크의 원칙이 무엇인지, 그래서 무슨 목표를 지향하고 있고, 그러기 위해서 어떤 전략을 구사했는가를 명확하게 설명할 수 있어야 한다. 그것이 비록 맨땅에서 만들어온 것이 아니고, 일부 유명 프레임워크를 조합하고 그 위에 얇은 레이어를 하나 얹었든, 그저 사용가이드 수준의 스택-업을 했든 상관없이 말이다. 만약 프레임워크 개발자라면 자신에게 5분의 시간이 주어졌을 때 그 프레임워크의 장점이 무엇이고 무슨 철학을 가지고 있는지 명확히 설명할 수 있어야 한다. 물론 듣는 사람이 적어도 그 목적을 명확이 이해할 수 있도록 말이다.

프로젝트 발주 시점에 고객은 프레임워크 개발의 타당성을 경영진에게 입증하여 자사의 지갑을 열고, 필요한 인력을 구성하는 과정에서 분명한 목적을 제시했다. 외주 개발 형태였기 때문에 프로젝트 제안을 하면서 개발팀은 고객이 기대하는 효과를 만들어내기 위해 프레임워크가 제공할 가치를 제시했다.

    확장성 및 범용성
    고성능
    아키텍처 가변성 지원
    개발 생산성 향상
    설정 편의성
    시스템 통합 일관성
    테스트 용이성
    정책 가변성 지원

이와 같은 가치는 원칙 수준이라 할만하다. 과연 원칙수준의 추상적인 가치는 어떻게 구현할 수 있을까? 돌아보면 원칙 수준으로 정의한 프레임워크 제공 가치는 설계 과정에서 주요 체크 리스트로 쓰였다. 프레임워크의 기능, API 혹은 사용자 인터페이스를 정의하는 과정에서 설계 결정을 내려야 할 때마다 체크 리스트 역할을 했다. 한 가지 예를 들면, 금융권에서 주로 요구하는 ‘선, 후행 처리 지원’ 기능 구현을 예로 들어보자. 우리[footnote]우리라 함은 필자의 개발팀을 지칭한다.[/footnote]는 선, 후행 처리를 위해 종래 다른 프레임워크 제품과 달리 인터셉터(Interceptor)와 AOP 애스팩트(Aspect)를 활용한 방식 두 가지를 제공했다.

<aop:aspect id="beforeExample" ref="aBean">
    <aop:before
      pointcut-ref="dataAccessOperation"
      method="doAccessCheck"/>
    ...
</aop:aspect>

국내에서 흔히 쓰이는 선, 후행 처리 방식이나 기존 프레임워크 제품이 채용한 메커니즘을 개선한 근거는 위에 열거한 제공 가치였다. 정책 가변성 지원이라는 다소 모호한 내용에 대해서도 하나의 예를 들어 보겠다. 오류 로그를 남기는데 있어서 시스템 혹은 운영 조직마다 차이가 있기 마련이다. 어떤 경우는 오류 로그에 대해 간단한 데이터 형식만 정의할 수도 있다. 오류 로그를 체계적으로 관리했던 조직은 오류 로그에 대해 명확한 지침을 갖고 있기도 하다. 처음에는 오류에 대한 지침이 없다가 향후에 이를 반영하고자 할 경우도 있다. 다음 그림은 이러한 상황 모두를 배려하기 위해 각각의 사용 사례를 파악한 그림이다.


이와 같은 식으로 대응하면 프레임워크의 각각의 기능에 대해 하나 이상의 가치를 대응시킬 수 있다. 이는 그리 어려운 방법은 아니다. 그런데 만일 앞서 인용한 ‘Application Framework 개발의 원칙’에서 주장한 것처럼 듣는 사람이 분명하게 이해할 수 있도록 이를 설명할 수 있을까? 더 나아가서 프레임워크가 추구하는 가치와 설계 원칙을 한 마디로 설명할 수 있을까? 포스트를 읽을 당시 필자는 분명한 답을 내지 못했다. 사실 답을 내지 않았다는 말이 더 적절할지도 모른다. 프로젝트 착수 이후 3개월이 지난 시점이었고, 고객이 요구한 방대한 기능을 구현하는 부담은 원칙을 확고하게 하는 일보다 우선했다. 글을 쓰는 지금은 그로부터 8개월이 더 지난 시점이다. 지금은 프레임워크가 추구하는 바에 대해 설명해야 할 대상에 따라 적절한 답을 할 수 있다고 자신한다. 반면에 위에 나열한 가치가 고스란히 지켜졌는지는 의문이다. 더구나 각각을 동등하게 취급하지는 않았으며 처음에 부여한 우선순위가 지금은 변했다고 생각한다. 우리가 초기에 수립한 가치는 작업 과정에서 고객과 우리가 문제를 더 잘 이해함에 따라 정제 작업을 거치게 되었다.

설계 원칙과 코드의 일관성
프로젝트 후반에 개발팀이 작성한 코드를 살펴보니 개개인의 특성을 발견할 수 있었다. 흥미롭기는 했지만, 감상하고 넘어갈 내용은 아니다. 설계 원칙은 코드 속에 살아있어야 의미를 지닌다. 그렇지 않으면 단순히 경구에 지나지 않는다. 코드가 작성자마다 개성을 담고 있다면 원칙이 없다는 반증이다. 흔히 찾을 수 있는 개성 중에서 코딩 표준과 같은 지침으로 쉽게 개선할 수 있는 내용은 다음과 같다.

    클래스, 메소드 및 변수 작명 스타일
    코드 내 주석 작성 스타일
    단위 테스트 작성 단위

반면 아래 사항은 단순한 지침만으로는 해결이 어려운 내용이다.

    클래스, 메소드 크기 및 로직 구현 방식
    API 주석 수준 및 코드와 주석의 균형
    단위 테스트 작성 방식 및 테스트 표본 선정

작성자의 능력에 따라 차이가 발생하는 내용이다. 능력이 비슷하다고 해도 문제가 발생할 수 있다. 가령, 동일한 문제를 해결하는 설계 패턴이 두 가지라고 해보자. 개발자 A가 특정 디자인 패턴을 써서 자신의 코드를 모두 작성하여 저장소에 반영했다. 개발자 B가 다른 기능을 추가하면서 A가 만든 코드 중에 일부를 다른 디자인 패턴을 써서 바꾸었다. 단순히 코딩 스타일이라면 쉽게 드러나 일관성을 확보할 수 있지만, 여러 파일에 걸쳐 존재하는 디자인 패턴 등의 일관성 결여는 확연히 눈에 띄지 않는다.

‘닭이 먼저냐? 달걀이 먼저냐?’와 비슷하게 설계 원칙 수립이 코드 일관성을 향상시키기도 하지만, 코드 일관성을 확보하는 과정에서 설계 원칙이 분명해지기도 한다. 어떤 방법이 더 좋다라고 말하기는 어렵다. 여기서는 리팩토링을 다루고 있기 때문에 후자의 방식을 주로 설명하겠다.

블로그를 5년 이상 운영하면서 예전에 썼던 글을 종종 돌아본다. 굳이 돌아보고 싶어서가 아니라, 몇 년 전 글에 댓글을 달거나 그 일을 화두로 말을 걸어오는 사람이 있기 때문이다. 그럴 때면 파노라마처럼 지난 일과 함께 그때 내 감정과 생각이 떠오른다.

돌아보면 무척이나 부끄럽다. 아직 IT 분야 혹은 SW 분야가 초창기라 짧은 지식만으로도 아는 척할 수 있던 때 잘났다고 까불던 그때. 하긴 그런 치기가 없었더라면 열정만으로 그 시절을 견딜 수 없었을지도 모른다.

어제 토비형이 SoC에 대해 다소 어이 없는 글을 보라 했다. 한 마디 하라고 부추기는 통에 여과 없이 뱉은 글이 문제를 일으켰다. 생산적인 논쟁이면 좋겠지만, 그저 흥미를 유발하는 싸움(?)에 지나지 않았다. 댓글에 남겨져 있듯 생각보다 훨씬 감정적으로 비화되었다. 저녁 동안에 기분이 영 좋지 않았다. arload님에게는 기분을 상하게 해서 죄송하다는 말씀을 드리고 싶다.

주제 넘게 나서기나 하고, 그러는 시간에 도리어 한심하게 본래 할 일은 제대로 못했다. 나이가 들어도 악동기질과 치기는 쉽게 사라지지 않는다. 내 앞 가림이나 잘해야지. 이젠 블로그도 좀 자제할 때가 온 모양이다. 헛소리만 하고... :)

arload님이 SoC에 대한 자신의 견해를 밝히는 글을 올렸다. 무지 긴 글인데, 이전 글과 별로 다르지 않다.

핵심은 위 내용이다. SoC를 어떤 결과물로 이해하고 있다. 프로그램 구성요소를 분할해서 생기는 문제는 설계자 고유권한일 뿐이다. 나누건 나누지 않건 문제는 원래 복잡했다. 나누지 않고 해결할 수 있으면 그 문제는 하나의 Concern일 뿐이다.

대개는 사람이 여러 개의 문제를 부여 잡고 중언부언하거나 해메거나 하기 때문에 그런 경우에 SoC란 말/개념을 쓴다.