Uncategorized

Popit 으로 이사합니다

이미 팝잇에 글을 올린지는 시간이 좀 지났는데…

한동안 이곳은 그저 방치해두었습니다.

이제라도 반성하고 중복을 제거하고 위키 정원관리 습성 응용 일환으로 여기 글을 모두 팝잇으로 옮기고자 합니다.

그런 연휴에 과거 제 온라인 정체성이있던 이곳(영회인포의 후신)을 어찌할지 결정하고 실행하겠습니다.

Advertisements
opinion, Uncategorized

MDD는 과연 무엇이고 어떤 용도로 사용할 것인가?

요즘 중국에 체류 중이어서 블로깅을 할 수 없었다. 내 글이 누군가에게 가치가 있느냐를 떠나 그냥 하고 싶은 말이 있어 쓰고 싶던 차에 한국에 귀국한 김에 짧은 생각을 기록한다.

MDD(Model-Driven-Development)를 다룬 글이 있어 토론하듯 의견을 달고자 한다. 먼저 MDD가 ‘최근 주목받고 있다‘는 사실에 대해서는 의구심이 있다. 내가 MDD에 관심을 갖은 것은 10년도 넘은 일이다. MDA(Model-Driven-Architecture)가 특정 영역(자동차 분야 등의 일부 임베디드 SW 영역)을 제외하고는 보편적인 보급에 실패한 후에 MDD가 등장했다. 2004년 즈음에 처음 영어로 된 기사들을 본 듯하다. 당시 IBM이 이클립스 재단을 설립하고 오픈소스인 탓에 MDD를 위한 기반으로 쓰이며 다양한 산물들이 등장했다. 하지만, 구체적인 실천 방법은 볼 수 없었다. 오히려 DDD(Domain Driven Design)에서 제시한 개념과 실천법이 훨씬 더 현실적이고 자동화 도구로 연결하지 않았을 뿐 사회적인 파급효과가 커졌다. 일례로 지금은 많은 언어나 라이브러리 혹은 인터넷 서비스에서 리포지토리(Repository)나 애그리케이트(Aggregate)라는 개념이 쓰인다. 말로만 쓰이는 것이 아니라 해당 개념을 구현한 다양한 솔루션들을 쉽게 찾을 수 있을 정도다.

 

MDD라는 개념은 너무나 포괄적이라 맥락을 분명히 하지 않으면 의사소통은 커녕 오해만 부를 수 있다. 추측하기에 블로그의 소유 주체인 L모사에서 말하는 MDD는 ‘자동화 도구와 UML 표기법을 활용한 명세 작성’에 초점이 맞춰진 것이 아닐까 싶다. 필자가 사회 초년생 시절(2000년 초반)에 UML 강의와 UML 명세 결과를 구현으로 이어가는 객체지향 분석설계 멘토링을 주업이었다. 그런 경험 때문에 대형 SI 업체의 관점을 나름 소화해서 추정한 결과다. L모사의 교육 기관에서 MDD 교육을 하고 있다는 사실도 하나의 근거라 하겠다.

 

하지만, 아쉽게도 아직 우리(나라)의 소프트웨어 역량이 구현을 해보지 않고 명세를 작성할 높은 수준에 올라서지는 못했다. 솔직해지자. 물론, 반도체 분야와 같이 글로벌 우위를 점한 영역이라면 얘기가 다르지만 그쪽에 대해 나는 문외한이다. 최소한 비즈니스 소프트웨어에 대해서는 일반화 할 수 있는 역량을 개개인의 노하우로 갖고 있다는 것이 15년 경험으로 확신하는 바다. 그걸 해당 도메인 지식으로 쌓아가는 작업-생각만해도 지난한 인내가 필요한 활동을 우리나라 SW 산업에서 해왔는가? 내가 본 결과물 중에 인정할만한 산물은 ‘생활코딩‘ 정도다. 우리의 조상들이 발로 뛰며 대동여지도를 그리고 조선왕조실록이라는 위대한 기록물을 만들었지만, 대한민국에서는 그러한 업적을 이룬 바가 없다. 그런데 ‘(구현을 통한 확인 후 설계를 하는)시행착오법’을 피해서 소프트웨어 설계를 ‘제대로’ 하겠다는 발상은 빨리 버려야 한다.

 

업계 동지들에게 이야기하고 싶은 마무리는 우리 좀 솔직해지자는 것이다. 우리 부모님들이 전쟁의 폐허속에서 또 강대국의 견제속에서도 경제를 일으킨 기적을 만들어낸 것이 우리 민족의 저력이다. 고맙게도 그건 타고난 것이다. 그러니 제발 용기를 갖고 우리도 해보자. 이미 SW로 성공한 선배들도 있지만, 서구의 방법을 답습하거나 당장의 돈벌이만을 위해 솔직하지 않은 주장을 버리자. 진지하게 끈질기게 타고난 부지런함을 활용하면 언젠가는 우리도 무언가를 쌓을 수 있을 것이다. 그 주체가 내가 아니라도 우리라 믿고…

 

그런 점에서 MDD 채택과 실효성을 논하기 전에 우리가(혹은 여러분 개인이) 말하는 MDD는 무엇인지 자신의 행동 관점에서 구체화 해보고 정확하게 기대하는 것이 무엇인지 명확히 이해한 후에 문제를 다루자. 그리고, 제발 부탁인데 이런 고민을 외주로 줄 생각따위는 하지 말자. 전문가 도움은 받더라도 일의 주인이 되어서 자기 손과 머리로 답을 내보자.

opinion, Uncategorized

기능 점수(Function Point) 유감

2005년의 일입니다. 군사업에서 당시 업계 표준이었던 EJB 대신에 Spring이라는 오픈소스를 도입해서 (EJB 악몽을 피해) 프로젝트 성공을 경험한 일이 있습니다. 아직 주니어(엔지니어)였던 저를 사장님이자 총괄 아키텍트였던 제 첫 직업적 멘토님께서 니가 원하는대로 하라고 기회를 주셔서 당시 저를 위협하던 선배 개발자와 엔지니어들의 탄압(?)을 이겨내고 모두가 행복한(다시 말해 야근이 거의 없는) 프로젝트로 마칠 수 있었습니다. 성공 요인을 말하자면, 길게 써야하지만 이 글의 주제와는 동떨어져서 이 정도로 각설하죠. 아무튼 성공적인 프로젝트를 했는데, 문제가 하나 발생했죠.

 

그것은 바로 세금을 쓰고, 국가 안보가 걸린 군사업 특성상 엄격한 검수를 거치는데 사전에 EJB 기준으로 산정한 결과물의 양 다시말해 코드 라인수가 Spring 탓에 순수 자바 객체(Pojo)를 쓰느라 턱없이 줄어든 것입니다. 라인 수가 줄었다는 것은 생산성은 물론 유지보수가 용이한 이점이 있지만, 당시 검수하는 시각에서는 계획 대비 실적이 저조한 것으로 해석되었습니다. 그래서, 당시 일시적으로 검수기간에는 코드량을 늘리는 일을 했던 추억의 에피소드가 있습니다.

 

10년의 세월이 흐른 지금은 그런 일을 다시 겪을 수 없었습니다. 그런데, 몇 일전 술자리에서 잊혀진 단어인 Function Point(기능 점수) 때문에 유사한 해프닝을 겪는 이야기를 들었습니다. 무려 2016년에 말이죠. 주인이 없는 회사인 공공사업은 세금을 써야 하니 말이 되지 않아도 객관적인 기준이 필요합니다. 그래서, 기능 점수가 좋은 도구는 아니지만 (마지못해) 필요성을 인정합니다. 하지만, 제 경험에서는 5~6년 전에 통용되던 ‘말이 안되는 객관적인 기준’이 바로 Function Point입니다. 그런데, 그것을 공공사업도 아닌 민간기업에서 아직도 쓰고 있다니 안타까웠습니다. 그것은 회사의 주인 즉, 오너도 주주도 손해만 볼 뿐인 도구이고, 시스템 사용자에게도 아무런 도움을 주지 않는 무미건조한 기준일 뿐이니까요. 더군다나 그걸 기준으로 기획과 구매 등의 집행을 해야 하는 분은 정말 답이 없는 일에 답을 내는 고통스런 업무를 맡게 되거든요.

 

그래서, 하고 싶은 말은… 제발 그런 도구는 검토해주시면 좋겠습니다. 공공사업이라면 제가 그 사정을 몰라 잘 모르겠지만, 적어도 주인이 있는 회사 즉, 민간기업에서 ‘기능 점수’나 ‘Function Point’를 쓰는 일은 어떤 말로 비난해도 과하지 않다고 생각합니다. 그런 일은 일을 가장한 일 코스프레라도 말하고 싶을 정도로 말이죠.

event, opinion, Uncategorized

개발자 경력개발 세미나 주최 후기

온오프믹스를 통해서 두 차례나 했던 세미나 후기를 씁니다.

처음에는 페북 지인이 필요한 내용을 전달하려고 했으나, 우리네 인생이 늘 그렇듯이 생각과 다르게 흘러 갔죠.

암튼 주변에 용기를 주는 분들이 있어 일단 지르고 시작했습니다. KSUG 를 만들던 때와 마찬가지죠.

그래서 보름을 정신없이 준비했습니다. 마침 휴직 중이라 게을리 할 핑계도 없었죠. 그래서, 열심히 준비했습니다. 그럭저럭 나쁘지 않은 분위기로 12월 1일 발표를 했습니다. 그리고, 제가 좋아하던 친구들이 오픈때문에 못 왔다고 해서 강남에서 앵콜을 했죠.

앵콜은 재방송으로 할 수는 없어서 (전 살아 있는 인간이니까요.. ^^) 연극 분위기로 했더니 더 호응이 좋았습니다.

그래서, 결국 제가 왜 퇴사를 했고 지향하는 삶이 무언가를 배울 수 있었습니다. 그 장소에 와주신 분들 덕에 제가 많이 배웠습니다.

20151215_201527.jpg

늘 그렇듯이 배우고자 하면 결국은 가르쳐야 (혹은 나눠줘야) 한다는 사실을 배웠습니다.

opinion, Uncategorized

SLiPP 스터디 세미나를 다녀와서

지인인 박재성님의 활동을 응원하는 사람으로써 주말에 모처럼 아내 허락을 구해 SLiPP 스터디의 연말 세미나에 참석했다. 메모한 내용을 정리하려고 노트북을 열었는데 써둘 곳이 마땅치 않아 감상문을 더해 블로그에 글을 쓴다.

먼저, 자신있게 SLiPP 스터디를 소개하는 박재성님의 목소리에서 (그룹) 스터디가 진정 그의 삶의 중요한 일부로 자리한 것을 느꼈다. 많은 이들이 무얼 좀 배워볼까 하는 마음에 스터디를 찾거나 만드는데 반해 가정과 직장과는 다른 모임을 인생의 일부로 구사(?)하는 그를 확인할 수 있었다.

그래서, 새로운 언어/기술 소개가 많았던 발표를 들으며 스터디 참여자들이 생소한 것들을 배우게 용기를 주고, 퇴근 후에 피곤한 몸을 이끌고 움직이게 자극하고 두꺼운 책을 읽어내는 힘을 확인할 수 있었다. 스터디가 아닌 발표 자체로 좁혀서 듣는 이에게 생소할 수 있는 새로운 기술을  소개할 때는 사실 자체가 아닌 경험에서 우러나는 발표자의 평가가 몰입을 유도했다.

그리고, 세미나 자체가 아니라 육아를 막 시작한 위치에서 이런 행사에 주말에 참여하는 첫 경험으로 배운 바도 있다. 일단, 아내가 허락해서 왔으나 시작 후 4시간이 넘어가니 체력은 바닥이 났다. 반면에 주말에 자리를 비운 부담감은 높아졌다. 주최측에서는 하이라이트로 여기는 듯 보이는 마지막 세션을 들을 것이냐 말 것이냐 고민을 하게 되었다. 집중력이 떨어진 상태에서 기대감 높은 세션을 혹시라도 흘려 듣고 있는 나를 깨닫는다면, 아마 집을 비운 마음의 미안함은 더 켜질 것이란 결론을 내려 함께 듣던 지인들, 그리고 좋은 자리를 만든 박재성님에게 인사를 하고 자리를 떴다.

누구에게나 스터디를 참여하는 것이나 다른 사람이 준비한 세미나에 참여하는 것은 소중한 시간의 일부다. 그 시간에 진정으로 ‘깨어있기’만 하다면, 몰입한 시간만큼 만족감을 얻는다. 반대로 몰입할 수 없다면, 무언가 행동을 해야 한다.

개인적으로 내용면에서 인상 깊었던 세션은 정진수님의 ‘아주 평범한 서버 개발자 관점에서의 최근 개발 트렌드와 소소한 이야기’였고, 이 글의 동기가 된 메모도 그 시간에 쓴 것이다. 메모는 별도 설명없이 그대로 써둔다.

  • 자사의 개발 문화
    • Lean Startup 방법론 기반
    • 서비스를 빨리 만들어 고객 데이터 수집하고, 다시 만드는데 집중
    • 서비스가 성공한 후에 플랫폼 고민
  • RubyOnRails 개발 문화에선
    • Scala의 Play 하위호환성 없는 문제가 아무렇지 않음
    • 개발이 재미있으면(개발편의성 혹은 Time to market) 하위호환성 없음에 따른 번거로움은 자연스럽게 수용
event, Uncategorized

개발자 경력 개발 세미나 앵콜 안내

12월 1일에 있었던 개발자 경력 개발 세미나에 참여하지 못했던 분들의 요청이 있어 12월 15일 다시 세미나를 합니다. 1일날 배운 바를 추가하긴 했지만, 기본적으로는 1일 내용의 재방송이라고 할 수 있습니다. 갑작스럽게 장소를 구하기 어려웠는데, ‘무료 행사’를 조건으로 ‘자바카페’ 커뮤니티에서 지원해주셨습니다.

스크린샷 2015-12-10 18.15.56

[세미나 참가 신청]은 오오프믹스를 통해 합니다.

  • 길벗 출판사에서 책을 보내주셔서 참석자에게 배부합니다
  • 지난 번에는 만원을 참가비로 받았으나 장소 대여비 등의 행사 비용으로 이후 행사에서 사용할 예정입니다.