1. DDD
DDD 를 더 읽어봐야 알겠지만,
패턴화 시키고 , 분류법을 만들어주고 , 지켜야할 규칙에 대해서 공감한다.
그러나 접근법.
레베카가 주창하던 책임기반의 객체 식별 기법외에는 특별하게 다른 접근법이 없다 .
1.1. Object Design
- 책임과 역할 기반으로 객체 설계를 해야 한다는 핵심 컨셉과 해당 컨셉의 분류와 더불어 인프라 객체/클래스 를 식별하는 과정에서 인사이트를 주던 책이었따.
2. applying uml and patterns( 크레이그 라만 )
시스템의 가장 큰 행위를 식별하여 시퀀스로 접근한다.
그리고 점진적으로 d&q 한다.
여기서 우리에게 던져 주는 것이 있다.
3. RSM
시스템의 핵심 행위/목적 을 식별하고 그 행위를 통해서 Collaboration 을 도출하며
생성/사용 에 대한 객체 식별하여 Root 행위로부터 Leaf 행위까지 모델링해 나간다.
책임기반을 넘어 Collaboration 기반을 넘어서 행위 기반으로 접근한다.
아침에 걸어오면서 핵심을 관통하는 것이 있구나 라는 생각을 하면서 무릎을 탁 쳤다.
주제를 잡아서 시행착오를 거쳐야 온전히 내 것이 되겠지.
순차적으로 구현까지 흐름을 가져본 이후에 일반화 시킬수 있을 것이다.
그리고 그 일반화는 어차피 현남선배의 사상으로 갈 것 같지만, 그 사상으로의 접근법을 조금 다른 방법으로 가져갈 수 있는 내 실천법이 되길 바래본다.
오늘 생각을 출발점으로....
매일 조금씩 Top, Down 으로 전개해봐야겠다 .
그리고 스토리텔링을 구상.
모든 사람이(클래스가) 자신의 친구들이(협력자들이) 누구인지 밝히고 있는 사회에 산다고 상상해보자.
조는 매리를 알지만, 매리와 조 모두 Tim 을 모른다는 것을 알고 있다면,
조에게 알려준 정보는 매리에게는 전달될 수 있지만, Tim은 절대 알 수 없다고 가정해도 안전하다.
이제 모두가 일부의 친구만 공개하고, 다른 친구들은 비밀로 하고 있는 사회를 상상해보자 .
그런 사회에서 여러분이 조에게만 알려준 정보를 Tim도 알고 있다면,
Tim은 대체 어떤 경로로 이를 알게 되었는지 궁금해질 것이다.
여기가 재미난 부분이다. 만약 여러분이 관계를 만들어낸 ( 코딩한 ) 사람이라면,
여러분은 모든 종속성을 정확히 알고 있지만, 여러분 이후에 합류한 사람들은 모두 당황하게 될 것이다.
친구라고 선언된 사람들만이 유일한 친구도 아닐뿐더러,
여러분이 알 수 없는 비밀 경로로 정보가 전달되기 때문이다.
거짓으로 가득 찬 사회에 살게 될 것이다.
- 미스코 해브리(Misko Hevery)
전역 상태를 다룰 때 전역 상태로 객체를 다룬 다는 것은 내가 만들어 낸 관계 이외에도 여러가지의 비밀 경로가 생긴다는 말이다.
전역 상태와 public 개념을 다룰 때에 대한 훌륭한 '메타포' 인것 같아서 인용해 보았다.
(하루의 풍광)
오늘도 회사에 출근해서 먼저 에버노트를 펼쳐 봅니다.
간밤에 내가 노트했던 것, 어제 노트했던 todo list , 업무 기록 등을 보면서 오늘 할일을 체크를 하죠
그리고 Things 를 통해서 애플기기간 연동을 통해서 업무들의 우선순위를 보게 됩니다. ( 그러고 싶습니다만, 아직 애플기기는 맥북뿐이라. ㅋㅋ )
오늘은 온통 회의군요.
회의를 통해서 Action Item 이 도출되고 하루 하루 진척되어가는 것이 쌓여만 간다면,
각 구성원의 R&R 이 명확해지고 회의를 통해서 도출하고자 하는 결과만 명확하다면 더할 나위 없습니다.
회의를 할때는 항상 '회의주제'를 정하고 회의에서 의사결정되어야 할 기준이 되는 자료에 대해서 정리해서 들어가는 것은 필수입니다.
그렇게 각자 할일이 할당되고 자신의 일을 하고 다시 다른 회의를 합니다.
Action Item 에 대해서 정리 하고
이해관계자들과의 전화/메일 등의 커뮤니케이션을 진행하고
뭔가 작성할 것이 있으면 작성을 합니다.
그래도 이정도로 정리되면 깔끔하죠...
코디네이터 역할이나 관리 역할을 한다면 일방적인 지시나 앞에서 달려가는 것 보다는 위의 협력적인 방법이 조금 더 피곤하더라도 장기적으로 볼 때 구성원의 에너지 낭비를 없애고 서로 만족할 수 있는 길이 될 수 있을 것 같습니다.
연차가 되면서 ... 관리로 가는 사람들은 기술에 관심 없어서 그런줄 알았습니다.
머 그런데.. 기술 관심 가지고 계속 그 길로 가려고 해도...
성향차,
스타일,
분야에 대한 전문성,
매니저의 인력 관리 스타일,
적응력,
프로젝트에서의 빈 공간의 발생,
보충할 수 있는 인력의 성격 등....
내부/외부 요소 에 의해서 자신의 역할이 결정이 되게 되더라구요.
알게 모르게 관리적인 요소가 몸에 배어 있고 그런 역할이 나도 모르게 나에게 와 있는 것이...
'을' 에 있던 영향인건지...
아니면 위에 기술한 내/외부 요소에 의한 것인지는 아직 모르겠습니다.
어허.... 지금 그렇게 모른다는 거슨??? 머 까놓고 이야기 하면 부끄러운 거죠...
항상 ... 모자람을 느끼고 내가 진정으로 원하는 것을 하기 위해서 노력합니다.
그리고 여러가지 다른 관심들은 진정으로 원하는 것을 하기 위한 보충적인 요소들이기에... 시간 분산이 많은 것도 사실이고...
하고 싶은 일 중에 '기술 컨설팅' 을 하고 싶어요.
말 그대로 '기술' 에 관한 컨설팅.
제가 모르는 것이 더 많지만,
기술에 어떻게 접근해야 할지
해당 기술을 적용함에 있어서 어떤 절차를 지켜야 할지
그리고 조직 구성을 어떻게 해야 할지..
네 아키텍트가 해야 할 역할입니다. 근래에는 아키텍트라는 역할에 대해서 참 많은 부분에 아키텍트라는 정의를 하죠...
저는 그것보다는 더 상위 단계에서 조언 혹은 고문 역할을 하고 싶은 거죠..
희한하게 엔지니어 세상은 그게 쉽지 않아요.
잘못하면... 자존심이 이슈가 되거든요.
또한, 위에서 얘기한 기술을 기반으로 하는 그런 컨설팅 조직은 거의 없어요
우리 나라에 컨설팅 조직들은
벤더의 프리세일즈 컨설팅, PMO 컨설팅, 2000년대 초반의 CBD 에서 출발해서 변형된 컨설팅, 경영 컨설팅, 그리고 근래의 여러 업체에서 하고 있는 공학 컨설팅...
이런 성격인것 같습니다.
컨설팅은 문서화 인것 처럼 변질 되어 가고 있는 것도 없쟎아 있는 듯 하고
제랄드 와인버그의 '컨설팅의 비밀' 에서 이야기 한 것처럼 그렇게 깊숙하게 고객의 가려운데를 긁어줘야 하나 싶고..
그래서... 저는 제가 하고 싶은 일을 'IT coach' 라고 이름을 붙여 봤습니다.
실제 그런 일을 해보고 싶네요.
지금은 좀 그럴지 몰라도..
나이 지긋해 져서... 상대방을 존중하고 올려줄 수 있는 나이가 되면...
그래서 '코칭' 기법에도 관심이 많고 '프레젠테이션' 기법에도 관심이 많고 김창준님의 AC 과정에도 관심이 많고 글쓰기에도 관심이 많고 강의 기법에도 관심이 많습니다.
그러면서 실제 본업인 소프트웨어 개발분야는 꼭 봐야 하니 얼마나 관심이 분산되겠어요? 그 분야만 해도 참 많은 분야가 생기고 있고 발전이 되고 있어서 하나를 따라가기에도 쉽지 않은 시대인데요~~
그래서 선배들에게서는 항상... '넌 너무 욕심이 많아!!' 라는 말을 듣곤 합니다.
'집중과 선택'
'T자형 인재'
이런 좋은 말들이 있지만,
항상 결론은 지금의 관심사, 지금 앞에 있는 좋은 기회 였던 것 같습니다.
여기서 조건은 '지속가능해야 하고 일정 수준까지.... ' 이게 키 포인트더라구요.
왜냐면 어느 순간에 멈춰버리고 시간이 지나면 다시 refresh 되거든요. ^^
항상 무언가를 하고 있고 무언가에 관심을 가지게 되는 이유였습니다.
역시 글을 쓰다 보니 제 얘기로 귀결.
담엔 '봉도사' 님의 기를 좀 받아서 '깔떼기'를 좀 대 봐야겠어요..
희한하게.. 자꾸 '반성모드'야...
개발자들이 가져야 할 것들... 참 많습니다.
이 시대는 요구하는게 참 많아 졌고 기술의 등장 속도와 발전속도 역시 잠깐 신경 안쓰면 뒤쳐질 만한 굵직한 놈들이 많이 튀어 나옵니다. 그런 시대에서 대한민국에서 개발자로 살아가기라... 정말 하고 싶은 말이 많지만...
공통된 개발자의 자세? 정도의 주제를 가지고 굵고 짧게 세가지 정도로만 이야기 해 보고 싶습니다.
1. 자신의 Product 를 가져라.
제가 주로 했던 분야가 자바 분야 인지라 알고 있는 분들 역시 자바 또는 객체지향 분야입니다.
예전에 자바를 처음 배울때 제 뇌리에 박혔던 웹상에서 '수리바다' 라는 닉네임을 가진 분이 있었습니다.
수 많은 게시판 소스 중에 이 분의 소스는 제게 빛났습니다. 빛났던 것은 가만히 생각해 보면 자신의 로직을 가지고
자신의 게시판 소스를 통해서 새로운 라이브러리나 새로운 프레임워크가 나올때마다 적용해서 오픈 한 것이 정말 인상깊게 보였습니다. 항상 오픈을 하셨구요.
그리고 지인들의 예를 들어보면....
현재 운영되는 자바 계열의 가장 오래된 커뮤니티 okjsp 허광남씨 역시 항상 소스를 오픈하고 데이타베이스를 오픈하곤 합니다. 그리고 여러 엔지니어링+엔터테인먼트(?^^;;) 영역에서 영향력을 행사하시고 있죠.
Spring 의 스타강사 였던 javajigi 박재성씨 역시 자신이 고민한 것들을 오픈하고 같이 토론하려 애쓰는 모습을 볼 수 있습니다.
근래에 스타강사가 되신 김형준씨를 빠트릴 수 없죠. 몇년간의 삽질을 그루터 서비스에 녹여 냈고 이분 역시 자신의 책을 내시고 자신의 네임밸류 향상을 이뤘습니다. 국내 오픈소스 클라우드 구축의 선두주자 이기 위해서 매일 노력을 기울이시는 분이구요. 국내 엔지니어 모델중 새로운 모델을 만들고 있는 중이죠.
또한, 많이 알려지진 않았지만, UML2.0 책을 썼고 RSM 을 설파하고 있는 김현남씨 역시 자신이 몇년간 연구해온 모델링 기법을 꾸준히 연구하고 꾸준히 발전시켜서 '행위 형식화' 라는 기법을 만들었고 그 기법의 실천을 통해서 모델러를 꿈꾸는 사람들을 교육해 오고 있습니다.
그외에 여러 훌륭하신 분들이 자신의 Product 를 가지고 발전시켜가고 있습니다.
현업에서 볼수 있는 '소위' 재야의 고수들이라고 하는 분들 역시.. 자신들만의 솔루션을 가지고 있습니다.
고객이 원하는 패턴을 파악해서 그에 따른 솔루션들을 스스로 가지고 있다가 요구사항 정리와 함께 자신의 노하우를 담은 솔루션을 풀어 놓고 생산성에 지대한 영향을 미치곤 하죠.
이와 같이 자신이 고민한 것들을 가지고 끊임없이 자신의 솔루션을 갈고 닦은 이들은 항상 비범하게 일을 처리합니다.
마침내는 엔지니어 사회에서 명망을 떨치거나 경제적으로 혜택을 받거나 커뮤니티에서 환영을 받게 됩니다.
아니, 그것보다는... 무엇보다 자신감을 가지게 되고 리드를 할 수 있게 되는 것이 정말 좋은 일입니다.
스스로 자신의 제품을 가지고 자신이 새롭게 알게된 기술을 적용하고 있다는 것.
그것은 자신의 한계를 극복하는 일이며 고객의 돈과 시간을 테스트 베드로 삼는 것이 아닌.. 새롭게 알게된 지식을 시험할 수 있는 토양이 됩니다.
저 역시 꿈꾸고 있지만, 개발자들에게 자신을 성장할 수 있는 첫번째 길을 말한다면, '자신의 제품을 만들라' 입니다.
2. 주위와 소통하려는 노력을 소홀히 하지 말아라.
어떤 이는 말합니다. '커뮤니티 열심히 하는 사람 만나봤더니 다 똑같더라.' 또는 'xxx 별로더라'
네 맞습니다. 기존에 생각했던 선입관보다 못할 수 있습니다.
커뮤니티에서 잘 나가는 사람이 잘 하고 커뮤니티에서 잘나가보라고 말 하는 것이 아입니다.
커뮤니티 생활을 하고 어떤 사이트에서 , 블로그에서 개발자들과 소통할 수 있다는 것은 자신을 내 보이는 것이고
다른 이들과 소통할 준비가 되어 있다는 것입니다.
그런 소통을 통해서 자신이 경험하지 못한 것들, 자신이 도움받아야 할 대상들을 알게 됩니다.
10년 넘게 개발을 해 온 사람이 자신이 한 분야 외에 다른 분야를 알지도 못하고 자신의 기술력에 대해서 위기감 없이 공부도 하지 않는 다면 둘중 하나 입니다.
'천재' 이거나 '귀머거리' 이거나 .
여기서 귀머거리란 같은 업종을 하는 사람들과의 소통에서의 귀를 막고 있다는 뜻입니다.
커뮤니티 생활을 활발히 한다는 것은 양날의 검일 수 있습니다.
위에서의 사람들의 선입견(잘 할것이다... 대단할 것이다... ) 을 정리를 잘 할 수 있어야 하고,
스스로의 역량에 맞는 일을 할 수 있어야 합니다.
어쩔수 없는 것이 사람과 사람의 일이 커뮤니케이션과 정치의 영역을 배제하고는 진행될 수가 없기 때문입니다.
평소에 개발자로서 소통하고 자신의 한계가 무엇이고 다른 영역에 있는 이들의 생각에 귀 기울일 수 있으며
자신이 무엇을 더 계발해야 하는지를 알 수 있게 하는 단초는 단연, 커뮤니티라고 말하고 싶습니다.
커뮤니티를 통해 자신을 계발하고 그들과 함께 하고 따라가고 이끌어주는 재미를 한번 가져보세요.
3. 진정 자신이 하고싶은 것이 무엇인지 끊임없이 성찰해라.
우리나라 사회에서 4년차 , 5년차가 되면 요구를 받게 되는 일반적인 부분은 엔지니어로 갈 것이냐? 관리로 갈것이냐? 로 귀결됩니다.
일반적인 대기업에서는 후자로서의 요구를 받게 됩니다. ( 물론 근래에는 좀 달라졌지요. )
제 선배들 중에도 국내 3대 SI중 한 업체에서 근무하시다가 10년쯤 되었을 때 '엔지니어로서 살고싶다!' 는 출사표를 던지고 다른 회사로 옮기신 분도 있습니다.
물론, 대안은 있습니다. 포탈, 연구소, 등의 여러가지 선택지들.
그러나 우리가 먼저 고려해야 할 것이 있습니다.
자신이 소속되어 있는 조직의 성향을 파악하는 것이 중요합니다.
저 역시 얼마전 회사를 나오게 된 결정적인 계기는 제가 근무하던 조직의 성격을 스스로 정의 내려보니 어쩔수 없이 회사에서 필요한 역할을 해야 하는데 그 역할은 제가 바라던 저의 미래가 아니었다는 생각이 들어서 입니다.
기술 기반의 조직, 내가 만든 서비스가 우선이 되는 조직 이 아닌 이상
소위 '전산 자회사' 급의 회사, 기술 보다는 다른 제품 들이 중요시 되는 회사, 자신이 만든 서비스가 아닌 중요한 다른 서비스를 위한 뭔가를 해야 하는 회사... 그런 회사에서 자신이 원하는 것이 그 부분인가? 하는 생각이 중요합니다.
일반적으로 운영/SM 위주의 회사는 '서비스' 가 우선이므로 '기술', '개발능력' 등이 우선 될 수가 없지요.
스스로 자신이 있는 조직의 가치와 정체성을 정의 내려 보시기 바랍니다.
그런 이후에 '내가 이 조직에서 맡을 수 밖에 없는 역할이 진정 내가 하고 싶은 일인가?' 를 생각해 보시기 바랍니다.
개발자로서 살던, 개발의 경험을 가진 아키텍트 혹은 관리자로 살던 '내가 하고 싶은 일' 을 한다면 행복할 것입니다.
항상 자신이 하고 싶은 일이 무엇인가? 를 끊임없이 성찰하는 개발자가 되길 제안합니다.
글을 쓰고 보니 이미 식상한 얘기일 수도 있습니다만,
그럼에도 불구하고 프로그래머, 개발자, 소프트웨어 엔지니어 로서 이 사회에서 스스로 만족하면서 살아가고 싶다면 소통, 자기 성찰, 자신의 테스트 베드 는 스스로 갖출 필요가 있습니다.
소프트웨어 개발은 건축물 처럼 결과물을 만져보거나 구조를 볼수도 없고 사람들의 머릿속의 컨셉이 최종 결과로만 눈으로 보이게 되고
실제 과정은 '문서화'라는 과정을 통해서만 우리가 검증이 가능하게 됩니다.
그리고 항상 사람의 문제로 귀결됩니다.
이렇게 쉽지 않은 분야에서 우리가 어떻게 스스로를 계발할까를 고민한다면 위에서 이야기한 세가지는 우리가 이 업을 수행하고 스스로 자부심을 가지게 해 줄 무기가 될 수 있을 것이라고 생각이 됩니다.
물론, 실제 자신이 사용할 무기 ( 랭귀지, 시스템, 데이타 등 )를 갈고 닦는 것은 말할 것도 없겠죠?
여러가지 우여곡절이 많지만, 내가 도전 받는 것 만큼 부담을 느끼고 또 재밌게 학습하게 된다.
물론 볼 것이 하도 많아서 그게 어느정도 수준에 올라서려면 시간이 필요한데 많은 것들을 동시에 봐야 하는게 부담이긴 하지만, 차분히 차근 차근 쌓아나가는 것이 내 자신에겐 더 도움이 되리라는 걸 알기에 급하게 맘 먹지 않으려 한다.
매일 조금씩이라도 뭔가를 보려고 하고 새롭게 알기 위해서 노력한다.
내게 주어진 환경에서 책임을 다하기 위해서 고민하고 또 고민한다.
의도하지 않은 상황이라도 이해하고 대화하려고 시도한다.
나를 챙겨주고 백업 해주는 manager 는 없으나 외롭진 않다. 충분히 내 영역 안이다.
내 생각대로 천천히 차근 차근 쌓아가보자. 그리고 내 날개를 펼쳐보면 되지 않겠나 싶다.
혹자는 대기업 들어가서 5,6 년 있는게 너한데 더 낫지 않겠냐고 하고
어떤 이는 사업하라고 한다.
아직은 현재 내가 있는 이 자리에 어느정도 만족하며 서로의 신뢰를 쌓아가기 위해서 노력하고 있다.
해당 조직의 구성원이 아니지만, 그 조직의 구성원인 것처럼 일하기 위해서 노력한다.
SI 바닥에서 희망을 보고 있는 건 아니지만, 그렇다고 딱히 서비스에 대한 특별한 생각을 하고 있는 것은 아니다.
대 고객 서비스든, 기술 서비스든 정한 이후에 움직일 것이다.
내가 그에 필요한 모든 것을 다 알아서 카리스마를 갖추려 할 필욘 없다고 생각한다.
나는 조조와 같은 스타일은 아니다.
