opinion

동료 아키텍트들과 고객들께 고하는 짧은 소견

http://www.popit.kr/진짜-아키텍트가-없는-ea-시장-잠재력을-알리는-글/ 로 대체합니다.

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’를 쓰는 일은 어떤 말로 비난해도 과하지 않다고 생각합니다. 그런 일은 일을 가장한 일 코스프레라도 말하고 싶을 정도로 말이죠.

opinion

인공지능 때문에 개발자들 일자리도 줄어드는가?

별로 관심을 두지 않아도 이세돌과 알파고의 대국은 마치 내 삶을 포위한 듯했다. 가장 가까운 지인들이 끊임없이 소식을 전했고, 자기 의견을 보탰다. 실제로 나는 미디어를 통해서가 아니라 지인들의 입과 페이스북 글을 통해 승패는 물론 그에 대한 다양한 생각까지 접했다. 그럼에도 불구하고 내 생각을 보태지 않았고, 그냥 평소와 같은 삶을 살았다. 그런데, 아내가 생각하지 않을 수 없게 만드는 질문을 날렸다.

바로 알파고가 3연승을 했을 때, 아내 말은 이제 개발자들 일도 줄어드는거 아니냐는 것이다. 글쎄… 하며 마지못해 생각을 시작했지만, 그 자리에서는 부정적인 입장을 취했을 뿐 명확한 생각을 내뱉지 못했다. 다음 날인가 이동하는 지하철에서  읽은 지인의 페이스북이 나를 다시 생각하게 만들었다.

주변 사람 몇분이 알파고 같은 인공지능 나오면 개발자 직업이 사라지는 것 아니냐고 물어보는데,
매우 어렵다고 본다. Input과 Output이 아주 모호한 영역에서 컴퓨터도 알아먹을 때까지 수없이 반복하는 작업이 개발이다. 즉 개발의 70%은 대화이자 관계이다.

이날 점심을 이 친구와 먹으며, 이렇게 말했던 것으로 기억한다.

워터폴 개발 방식과 애자일을 단순히 요구사항 분석, 설계, 개발, 테스트를 단번에 하느냐 혹은 반복적으로 하느냐는 형태 차이로만 보는 사람에게 그 차이를 설명하느라 애먹은 일이 있다. 아내 질문과 당신 글을 보면서 그때 했어야 할 답을 찾았다. 그건 바로 요구사항 분석이라는 것이 개발과 선 긋기 하듯이 명확하게 구분되는 일이 아니란 점이다. 아무리 유능한 설계자를 두어도 마지막 2%는 반드시 개발자가 채울 수 밖에 없는 것이 현실이다.

집에 돌아와 아내와 점심 때 했던 이야기를 꺼냈다. 그랬더니 아내가 이번에는 베터코드도 할 일이 사라지는 것 아니냐고 다시 의견을 제시했다. 베터코드(Better Code)란 내가 Kent Beck 글의 영향을 받아 앞으로 하고자 하는 컨설팅 영역에 대해 붙인 이름이다. 흥미로운 질문으로 인해 내 얼굴에 자연스럽게 미소가 지어졌다. 그리고 나는 이렇게 답한 것으로 기억한다.

더 나은 코드(Better Code)를 만드는 일에서 알고리즘을 제대로 구사하는 일이라면 당신 말이 맞다. 그런데 알고리즘을 고민하기 이전에 먼저 무엇을 어떻게 만들 것인가 명확하게 규정하는 일이 선행되어야 하는데, 그 일을 알파고에 맡기기엔 많은 시간이 필요할 것 같다.

생각이 이 정도 나아간 상태로 또 하루쯤 지나 어제 김창준님의 글정재승 교수님의 기사를 비슷한 시간이 함께 보게 되었다. 먼저 창준님의 글 중에 눈길이 가는 대목은 여기다.

흥미로운 부분은 이렇다. 컴퓨터 프로그래머는 컴퓨터로 대체될 확률이 0.48이나 된다. 반면 애플리케이션 개발자(O*NET에 따르면 프로그래머와의 큰 차이가 소프트웨어를 뭘 만들지 고안하고 설계하는 것을 포함 — 이에 반해 프로그래머는 소프트웨어 개발자가 준 스펙대로 개발하는 것을 주 업무로 설명하고 있다)는 0.042밖에 되지 않는다.

개발자가 이세돌이 되어 알파고와 붙게 되는 지점은 바로 개발할 대상이 바둑판처럼 명료해지는 시점이다. 만일 그렇게 되면 그것은 개발보다는 연산 경쟁에 가까워지고, 도올선생 말마따나 인류는 알파고는 커녕 손바닥만한 계산기에게도 진다는 사실을 환기할 필요가 있다.

그렇다면, 우리(개발자)에게 주는 시사점은 무얼까? 앞으로 우리가 노력할 일은 어쩌면 개발할 대상을 바둑판처럼 명료하게 하는 훈련을 하는 것일지도 모른다. 개발자의 자리를 뺏는 적(?)이 있다면 그는 알파고 자체가 아니라 알파고를 이용하는 새로운 타입의 개발자에 가깝다. 거시적인 셈법이긴 하지만 그들이 인공지능을 활용해 더 많은 개발을 수행할 수 있다면, 개발할 일의 총량은 줄어들테니 경쟁에서 뒤떨어지는 개발자의 자리는 사라질 것 아닌가?

이런 논리가 옳다고 쳐도 오늘 당장 인공지능 서적을 읽을 필요는 없다. 개발자에게 인공지능이란 말 자체보다 중요한 점은 바로 요구사항 혹은 개발대상을 바둑판처럼 만드는 일에 대한 자기 나름의 방법을 익히는 것일 테니까.

마지막으로 정재승 교수님 기사 일부를 인용한다.

인간의 영역은 어떤 일이 남을까?
기자를 예로 들자. 기사 쓰는 로봇의 등장으로 기자가 사라질 거라는 식으로 말하는 건 단편적이다. 기자가 하는 일은 기사를 쓰는 것만이 아니라, 의제를 찾고, 발로 뛰면서 취재를 하고, 그래서 해야 할 이야기를 설정하고 이런 거잖나? 의제 설정이나 취재를 인공지능이 하게 될 시기는 꽤 멀 것 같다. 그렇게 생산된 자료를 갖고 기사를 쓰는 거야 인공지능도 할 수 있겠지만.

과제 설정 자체를 업으로 삼으란 말인가?
그렇다. 인간의 뇌가 어떻게 과제 설정과 관련된 일을 하는지 아직 잘 모른다. 모르니까 학습하라고 넣어주기도 힘들다. 인공지능이 스스로 판단을 하고, 대답해야 할 질문을 스스로 찾고, 그런 건 또 다른 차원이다. 그런 날은 올지 안 올지도 아직 알 수 없다.

opinion

융통성과 지식의 깊이

저녁에 지인과 이야기를 하다가 ‘융통성이 없는 사람과 깊이가 없는 사람에게 비슷한 인상을 받았다’는 말을 했다. 그랬더니, 지인 왈, ‘융통성 없는 것이나 깊이가 없는 것은 같다. 융통성은 다양한 상황에 응용하기 위한 적응과정에서 만들어진다. 깊이가 없다는 것은 그러한 적응 경험이 없다는 말이기 때문이다.’

아침에 본 June Kim님 글이 생각났다. 나는 #RUP 혹은 (방법론으로써의) #CBD 전문가로 일한 경험이 있다. (2003년 ~ 2007년) 그때, 내가 해결을 못한 아쉬운 문제는 본질을 무시하고 형태만 강조하는 사람들과의 마찰이었다.

반면 그 덕에 #FFF (Form Follows Function)이라는 공학원리에 대해서는 쉽게 그 의미를 알 수 있었다. (몸으로 익힌 것을 이론에 대응시키는 일만 필요해서)

우리가 살아가는 모습은 비슷해서, #Scrum(혹은 #Agile) 적용 과정에서도 비슷한 현상이 벌어진다. 사실, 나 역시 2008년부터는 모든 프로젝트에 상황에 맞게 애자일을 적용했다. 그리고, 대부분의 경우에 함께 일하는 사람들이 애자일에 대해 형식(Form without Function)만 가지고 옳다 그르다 논하는 모습을 많이 보아왔다. 솔직히 고백하면, 애자일 적용 초기에는 나 역시도 형식(도구나 기법)에 치우쳐서 낭비한 시간들이 많기도 했다.

event, opinion, Uncategorized

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

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

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

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

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

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

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

20151215_201527.jpg

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

opinion, Uncategorized

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

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

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

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

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

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

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

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