올해 들어서 카카오의 작가 플랫폼인 브런치에 글을 기고하고 있습니다.
https://brunch.co.kr/@insuk
한 10개 정도 기고했네요..
관심 있으신 분들, 오셔요.. :)
2015년 12월 29일 화요일
[독후감] 인터랙티브 디벨로퍼
인터랙티브 디벨로퍼 (김종민, 한빛미디어)
3시간 정도에 독파하였음.. 사진이 많아서 글자가 많지 않아 쉽게 쉽게 읽혔고, 밤에 쉽게 잠을 못 이루게 만들었음..
이 책은 필자의 10여년간의 행적을 스스로 돌아보면서 대한민국 개발자에게 전하고 싶은 메시지를 툭툭 던져주고 있다. 결국 꿈을 향해 한발 한발 나아가는 발걸음에 큰 박수를 보내고 싶다. 실은 깊이 강조가 되지는 않지만 본인이 좋아하는 것을 발견하고, 그 것을 잘 하는 사람들을 찾아서 멘토로 삼아 스스로의 차별성을 찾아가는 모습은 무척이나 닮고 싶은 부분이다.
책을 다 읽고 나서 나를 다시 한번 돌아 보게 되었다.
내가 지금까지 했던 것을 이렇게 멋지게 정리해 볼 수 있을까..
전형적인 B2B의 백엔드 엔지니어로서 나의 포트폴리오는 무엇인가..
누군가의 찬사를 받을 만한 일을 한 적이 있는 가.. 혹은 할 수 있는가..
올해에 지금까지 시도 하지 않았던 여러가지 시도를 해 본 한해였다.
내년에 계획대로 된다면.. 나도 나만의 포트폴리오를 하나 하나씩 만들어 갈 수 있을 듯 하다.
책을 읽으면서 인상 깊었던 구절 들이다.
실은 내가 지향하는 바와 무척 닮아있다.
내가 찾은 해결책 (44p~45p)
첫 번째로 플래시라는 특정 기술이 아닌 나만의 '내공'을 가지기 위해 노력했다. 세상엔 플래시를 잘 하는 사람은 많지만, 그 플래시를 사용해서 아름다운 작품을 만들어내는 사람은 많지 않았다. 플래시를 열심히 공부해 뛰어난 '플래시 개발자'가 되기보단, 디자인, 모션, 화면전환, 그리고 유저 인터팩션 등이 완성도 있는 결과물을 만드는 사람이 되고자 했다. 초점을 개발 언어에서 콘텐츠로 옮긴 것인데, 웹사이트의 디자인과 모션의 디테일을 높이기 위해 고민하고, 사용자가 어떻게 편하게 웹사이트를 이용할 수 있을지, 메뉴 클릭 시 나오는 모션은 어떤 게 제일 직관적인지 등을 더 연구했다. 거기엔 시장에서 요구하는 기술은 항상 빠르게 변하기 때문에 한 가지 기술에만 의존하는 사람이 되는 것은 위험한 발상이라는 생각이 있었다. 세상엔 영원한 것이 없듯이 플래시라는 기술 또한 언젠간 대체될 것이니 시대가 변해도 변하지 않는 나만의 '내공'을 가지자고 생각했다. 그렇게 쌓인 내 실력은 후에 플래시 시장이 죽고 HTML5가 대세가 되었을 때도 내가 뒤처지지 않고 계속해서 이 일을 할 수 있게 해주었다.
두 번째로는 '크게 보고 눈앞의 작은 것에 연연하지 말자'라는 것이었다. 당장 눈앞의 연봉, 직급 등에 연연해서 스트레스를 받거나 승진을 위해 윗사람에게 아부하는 데 시간을 쓰지 말고, 내가 되고자 하는 사람이 될 수 있도록 실력을 쌓고 싶었다. 즉, '이 회사에서 높은 자리에 올라가 연봉을 많이 받자' 가 목표가 아니라, 내가 스스로 성장한 모습을 목표로 삼았다. 그러기 위해서 좁은 시야로 눈앞의 작은 것을 가지기 위해 에너지를 낭비하지 말고 오직 내가 좋아하는 일에 모든 에너지를 쏟고 싶었다. 일에만 집중하자는 생각은 지금도 변함이 없는데, 평소 시계나 반지 같은 손을 움직으는 데 거추장스러운 액세서리는 하지 않고, 옷도 편하고 빨리 입을 수 있는 운동복을 즐겨 입는 이유이다. 회사에서 어떤 일을 하느냐, 혹으 내가 얼마나 성장하느냐가 중요하다....
나의 작업 철학 (132p~134p)
플래시 개발자에게서 쉽게 HTML5 개발자로 바뀔 수 있었던 것에는 내가 가진 작업 철학이 큰 도움이 되었다. 고등학교를 졸업할 당시 나의 희망직업은 영화의 미니어처 등에 쓰이는 모형을 만드는 장인이었다. 그때 내 재능에 대해 진지하게 스스로 반문을 해본 적이 있다. 모형응ㄹ 만드는 장인이 되려면 처음부터 모형을 직접 빚어내고 완성을 해야 한다고 생각했는데 나는 그러지 못했다. 내 실력은 이미 만들어진 모형을 사서 조립하고 색칠하는 수준밖에 되지 않는다는 것을 깨달았다. 즉, 취미로는 훌륭할지 몰라도 직업이라고 말하기에는 부족했다. 내가 그 분야의 진짜가 되기 위해선 본질이 되는 작업이 가능해야 한다고 생각했다. 개발의 본질은 개발코드를 사용해 구조를 설계하고 움직임을 만드는 일이다. 코드에 대한 이해가 없이 툴(Tool)이나 라이브러리(Library)만을 사용해 결과물을 만드는 것은 시중에서 모형을 사다가 조립하고 색칠만 하는 취미 정도의 수준과 다르지 않다는 생각이었다.
{중략}
라이브리리도 마찬가지 부분이다. 라이브러리는 '개발에 필요한 특정 기능을 미리 구현해둔 소스 파일'로, 잘 사용하면 개발시간을 단축할 수 있는 유용한 도구이다. 하지만 코드에 대한 이해 없이 라이브러리에만 의존하는 것은 피해야 한다. 하지 않는 것과 할 수 없는 것엔 큰 차이가 있다. 라이브러리를 사용하는 것이 문제가 되진 않는다. 문제는 라이브러리를 사용해 만들어진 결과물이 자신의 실력이라고 생각하는 경우이다. 그때 본인의 실력에 대해 거짓말을 하게 되는데, 컬렉터(Collector)가 되기 쉽다. 컬렉터란, 실력을 쌓는 데 시간을 쓰기보단 라이브러리를 수집하는 데 더 많은 시간을 보내는 사람들을 말한다. 이런 습관은 처음엔 괜찮을지 몰라도 시간이 지날수록 자신을 옭아매는 덫이 된다.
{중략}
툴이나 라이브러리는 분병 편리한 점이 많지만, 실질적인 코드에 대한 이해가 낮아지고, 툴에서 제공하는 한정된 기능만을 사용할 수 있다는 단점이 있다. 툴의 기능이 아무리 뛰어나고 그것을 100% 이해하고 사용한다고 해도 한계가 있다. 툴이나 라이브러리도 결국에는 코드로 만들어진 것들이다. 어려워도 툴의 도움 없이 개발의 본질인 코드를 이해하고 사용한다면 더 넓은 시야를 가질 수 있다.
---------------
좋은 책이다. :)
3시간 정도에 독파하였음.. 사진이 많아서 글자가 많지 않아 쉽게 쉽게 읽혔고, 밤에 쉽게 잠을 못 이루게 만들었음..
이 책은 필자의 10여년간의 행적을 스스로 돌아보면서 대한민국 개발자에게 전하고 싶은 메시지를 툭툭 던져주고 있다. 결국 꿈을 향해 한발 한발 나아가는 발걸음에 큰 박수를 보내고 싶다. 실은 깊이 강조가 되지는 않지만 본인이 좋아하는 것을 발견하고, 그 것을 잘 하는 사람들을 찾아서 멘토로 삼아 스스로의 차별성을 찾아가는 모습은 무척이나 닮고 싶은 부분이다.
책을 다 읽고 나서 나를 다시 한번 돌아 보게 되었다.
내가 지금까지 했던 것을 이렇게 멋지게 정리해 볼 수 있을까..
전형적인 B2B의 백엔드 엔지니어로서 나의 포트폴리오는 무엇인가..
누군가의 찬사를 받을 만한 일을 한 적이 있는 가.. 혹은 할 수 있는가..
올해에 지금까지 시도 하지 않았던 여러가지 시도를 해 본 한해였다.
내년에 계획대로 된다면.. 나도 나만의 포트폴리오를 하나 하나씩 만들어 갈 수 있을 듯 하다.
책을 읽으면서 인상 깊었던 구절 들이다.
실은 내가 지향하는 바와 무척 닮아있다.
내가 찾은 해결책 (44p~45p)
첫 번째로 플래시라는 특정 기술이 아닌 나만의 '내공'을 가지기 위해 노력했다. 세상엔 플래시를 잘 하는 사람은 많지만, 그 플래시를 사용해서 아름다운 작품을 만들어내는 사람은 많지 않았다. 플래시를 열심히 공부해 뛰어난 '플래시 개발자'가 되기보단, 디자인, 모션, 화면전환, 그리고 유저 인터팩션 등이 완성도 있는 결과물을 만드는 사람이 되고자 했다. 초점을 개발 언어에서 콘텐츠로 옮긴 것인데, 웹사이트의 디자인과 모션의 디테일을 높이기 위해 고민하고, 사용자가 어떻게 편하게 웹사이트를 이용할 수 있을지, 메뉴 클릭 시 나오는 모션은 어떤 게 제일 직관적인지 등을 더 연구했다. 거기엔 시장에서 요구하는 기술은 항상 빠르게 변하기 때문에 한 가지 기술에만 의존하는 사람이 되는 것은 위험한 발상이라는 생각이 있었다. 세상엔 영원한 것이 없듯이 플래시라는 기술 또한 언젠간 대체될 것이니 시대가 변해도 변하지 않는 나만의 '내공'을 가지자고 생각했다. 그렇게 쌓인 내 실력은 후에 플래시 시장이 죽고 HTML5가 대세가 되었을 때도 내가 뒤처지지 않고 계속해서 이 일을 할 수 있게 해주었다.
두 번째로는 '크게 보고 눈앞의 작은 것에 연연하지 말자'라는 것이었다. 당장 눈앞의 연봉, 직급 등에 연연해서 스트레스를 받거나 승진을 위해 윗사람에게 아부하는 데 시간을 쓰지 말고, 내가 되고자 하는 사람이 될 수 있도록 실력을 쌓고 싶었다. 즉, '이 회사에서 높은 자리에 올라가 연봉을 많이 받자' 가 목표가 아니라, 내가 스스로 성장한 모습을 목표로 삼았다. 그러기 위해서 좁은 시야로 눈앞의 작은 것을 가지기 위해 에너지를 낭비하지 말고 오직 내가 좋아하는 일에 모든 에너지를 쏟고 싶었다. 일에만 집중하자는 생각은 지금도 변함이 없는데, 평소 시계나 반지 같은 손을 움직으는 데 거추장스러운 액세서리는 하지 않고, 옷도 편하고 빨리 입을 수 있는 운동복을 즐겨 입는 이유이다. 회사에서 어떤 일을 하느냐, 혹으 내가 얼마나 성장하느냐가 중요하다....
나의 작업 철학 (132p~134p)
플래시 개발자에게서 쉽게 HTML5 개발자로 바뀔 수 있었던 것에는 내가 가진 작업 철학이 큰 도움이 되었다. 고등학교를 졸업할 당시 나의 희망직업은 영화의 미니어처 등에 쓰이는 모형을 만드는 장인이었다. 그때 내 재능에 대해 진지하게 스스로 반문을 해본 적이 있다. 모형응ㄹ 만드는 장인이 되려면 처음부터 모형을 직접 빚어내고 완성을 해야 한다고 생각했는데 나는 그러지 못했다. 내 실력은 이미 만들어진 모형을 사서 조립하고 색칠하는 수준밖에 되지 않는다는 것을 깨달았다. 즉, 취미로는 훌륭할지 몰라도 직업이라고 말하기에는 부족했다. 내가 그 분야의 진짜가 되기 위해선 본질이 되는 작업이 가능해야 한다고 생각했다. 개발의 본질은 개발코드를 사용해 구조를 설계하고 움직임을 만드는 일이다. 코드에 대한 이해가 없이 툴(Tool)이나 라이브러리(Library)만을 사용해 결과물을 만드는 것은 시중에서 모형을 사다가 조립하고 색칠만 하는 취미 정도의 수준과 다르지 않다는 생각이었다.
{중략}
라이브리리도 마찬가지 부분이다. 라이브러리는 '개발에 필요한 특정 기능을 미리 구현해둔 소스 파일'로, 잘 사용하면 개발시간을 단축할 수 있는 유용한 도구이다. 하지만 코드에 대한 이해 없이 라이브러리에만 의존하는 것은 피해야 한다. 하지 않는 것과 할 수 없는 것엔 큰 차이가 있다. 라이브러리를 사용하는 것이 문제가 되진 않는다. 문제는 라이브러리를 사용해 만들어진 결과물이 자신의 실력이라고 생각하는 경우이다. 그때 본인의 실력에 대해 거짓말을 하게 되는데, 컬렉터(Collector)가 되기 쉽다. 컬렉터란, 실력을 쌓는 데 시간을 쓰기보단 라이브러리를 수집하는 데 더 많은 시간을 보내는 사람들을 말한다. 이런 습관은 처음엔 괜찮을지 몰라도 시간이 지날수록 자신을 옭아매는 덫이 된다.
{중략}
툴이나 라이브러리는 분병 편리한 점이 많지만, 실질적인 코드에 대한 이해가 낮아지고, 툴에서 제공하는 한정된 기능만을 사용할 수 있다는 단점이 있다. 툴의 기능이 아무리 뛰어나고 그것을 100% 이해하고 사용한다고 해도 한계가 있다. 툴이나 라이브러리도 결국에는 코드로 만들어진 것들이다. 어려워도 툴의 도움 없이 개발의 본질인 코드를 이해하고 사용한다면 더 넓은 시야를 가질 수 있다.
---------------
좋은 책이다. :)
2015년 7월 3일 금요일
2015년 6월 28일 일요일
Python, R, Java, C
Python 과 R을 비교한 좋은 링크가 하나 있어 공유 드립니다.
그리고 Python 과 C 혹은 Java와의 조합 이야기도 있었는데요. 찾아 보니 내용이 조금 다르더군요.
Python 을 C 환경에서 사용할 수 있는 것이 Cython(싸이썬) 입니다.
간혹, CPython 이
보이기도 하는데요, 이건 Python 개발을 한 C 프로젝트를 말하는 겁니다. (Python 은 C로 개발되었습니다.)
Cython 은 Python을 작성한 코드를 C로 컨버팅 해주는 개념입니다.
컴파일을 하면, 마치 C 컴파일러로 컴파일 한 것과 같은 산출물이 나오는 것이죠. 여기서 LLVM 이라는 컴파일러를 활용하고 있습니다.
Java와 연계가 가능한 Jython(자이썬)은 위와 같은 개념이기 한데, 조금 더 나아가서..
Python 코드에서 Java 라이브러리를 호출하여 사용이 가능합니다.
Python 으로 코딩하면서 Java 코드를 삽입 하는 개념이죠.
이후 컴파일 하면, JVM 용
바이트코드로 변환하여, JVM 상에서 구동 됩니다.
R과 Python의 연계도 가능합니다.
rpy는 Python에서 R 함수를
호출 할 수 있는 개념입니다.
반대로도 가능합니다. R에서 Python을 콜하는 건 rPython 이라 하는 군요.
이외에도 여러 방면에서 조합이 가능합니다.
하지만 무리하게 한 프로젝트에서 여러 언어를 쓸 필요는 없겠죠? :)
>_
2015년 3월 23일 월요일
Python for Data Scientist
http://www.datacommunitydc.org/blog/2013/04/son-of-getting-started-with-python-for-data-scientists
http://www.datacommunitydc.org/blog/2013/03/getting-started-with-python-for-data-scientists
http://www.datacommunitydc.org/blog/2013/03/getting-started-with-python-for-data-scientists
2015년 3월 11일 수요일
Python 을 시작 하면서..
어떻게 Python을 시작할까 고민하다가, 책을 사서 보는 건 경험상 큰 도움이 되지 않기에, Python 개념 및 사상을 배우기 위해 인터넷을 이리저리 뒤졌다.
실은 위키피데아 내용 만 보더라도, 어느 정도 파악 하는 데는 무리가 없었다.
http://en.wikipedia.org/wiki/Python_(programming_language)
코딩의 시작은 일단 웹 사이트를 통해 시작했다.
http://www.codecademy.com/
세상 참 좋아진 듯.. 내가 경력이 그리 긴건 아니지만, 2000년 초반에 Java를 배우기 위해서는 책보고 관심 있는 사람끼리 모여서 스터디 한 것 밖에 없었던 듯.. 요즘은 코딩 배우는 싸이트도 많고, 코세라나 edx 같이 세계의 유명한 교수들의 강의를 무료로 들을 수 도 있고, 크라우드 펀딩을 통해서 개발 하면서 경쟁 할 수 도 있고.. 소스가 너무나도 많다.
Python 기초 과정을 한 40% 진행하며서 느낀 점은..
일단 쉽다. 다들 이 점을 강조 하는데, 실제로 구현 해 보니 증말 쉽다.
어떤 언어든 개발 경험이 있다면, 코딩 문법을 익히는 데 몇 일 안 걸릴 듯..
개발자가 아니더라도 어렵지 않게 배울 수 있을 듯..
세미콜론이 없는 게 얼마나 편한지,
함수 정의문이나 if-else 문을 감싸는 중괄호(())가 없는 게 얼마나 편한지,
단순히 띄워쓰기를 지킴으로써 얻을 수 있는 가독성, 생산성은 가히 놀라울 듯 하다.
변수 정의 시 미리 타입, 크기 등을 정할 필요가 없어 개발시 편하지만, 디버깅은 어려울듯..
Node.js의 JavaScript와 너무나도 비슷하다. 비동기식 이벤트 기반 코딩이 가능 한 1급 함수라는 부분도 똑같다.
상속관련해서는 JavaScript는 prototype 객체를 통해 상속 및 오버라이트는 가능하나, 클래스를 정의하여 상속 받는 개념은 없는데, Python은 완전한 클래스 생성이 가능하고 다중상속등이 가능해 보인다.
기초과정 완료 되면, 더 추가 하겠다.
To be continued..
>_
실은 위키피데아 내용 만 보더라도, 어느 정도 파악 하는 데는 무리가 없었다.
http://en.wikipedia.org/wiki/Python_(programming_language)
코딩의 시작은 일단 웹 사이트를 통해 시작했다.
http://www.codecademy.com/
세상 참 좋아진 듯.. 내가 경력이 그리 긴건 아니지만, 2000년 초반에 Java를 배우기 위해서는 책보고 관심 있는 사람끼리 모여서 스터디 한 것 밖에 없었던 듯.. 요즘은 코딩 배우는 싸이트도 많고, 코세라나 edx 같이 세계의 유명한 교수들의 강의를 무료로 들을 수 도 있고, 크라우드 펀딩을 통해서 개발 하면서 경쟁 할 수 도 있고.. 소스가 너무나도 많다.
Python 기초 과정을 한 40% 진행하며서 느낀 점은..
일단 쉽다. 다들 이 점을 강조 하는데, 실제로 구현 해 보니 증말 쉽다.
어떤 언어든 개발 경험이 있다면, 코딩 문법을 익히는 데 몇 일 안 걸릴 듯..
개발자가 아니더라도 어렵지 않게 배울 수 있을 듯..
세미콜론이 없는 게 얼마나 편한지,
함수 정의문이나 if-else 문을 감싸는 중괄호(())가 없는 게 얼마나 편한지,
단순히 띄워쓰기를 지킴으로써 얻을 수 있는 가독성, 생산성은 가히 놀라울 듯 하다.
변수 정의 시 미리 타입, 크기 등을 정할 필요가 없어 개발시 편하지만, 디버깅은 어려울듯..
Node.js의 JavaScript와 너무나도 비슷하다. 비동기식 이벤트 기반 코딩이 가능 한 1급 함수라는 부분도 똑같다.
상속관련해서는 JavaScript는 prototype 객체를 통해 상속 및 오버라이트는 가능하나, 클래스를 정의하여 상속 받는 개념은 없는데, Python은 완전한 클래스 생성이 가능하고 다중상속등이 가능해 보인다.
기초과정 완료 되면, 더 추가 하겠다.
To be continued..
>_
내가 Python을 시작하게 된 이유
그 동안 SI회사에서 다양한 필드의 엔터프라이즈급 시스템 개발을 하다가, 중공업 회사의 SW개발팀으로 옮긴 뒤, 우여곡절이 많았다.
일단, 내가 가지고 있던 'IT(Information Technology)' 기술은 중공업 분야의 플랜트 산업에 적용되고 있는 'OT(Operational Technology)' 기술과는 거리가 멀었다.
기존에는 복잡한 알고리즘 보다는 얼마나 단순하게 비즈니스 요구사항을 충족시키는 아키텍처를 설계/구현을 하고, 성능이슈 등은 불특정 다수의 사용자의 트래픽을 어떻게 하면 분산시키면서 빠르고 안정적이고 신뢰성 높은 시스템을 만들 수 있을 까를 고민하였다.
하지만 플랜트 쪽은 예전에 내가 다루던 아키텍처보다 훨씬 단순했고, 현재 최신 기술 트랜드에는 훨씬 미치지 못 하고 있었으나, 주기적으로 발생하는 플랜트의 운전 데이터를 통해 과거 데이터 학습을 통해 앞으로의 일을 예측하고, 예상하지 않았던 장애를 미리 방지 하여 플랜트의 수명을 연장 시키는 것에 초점이 맞추어져 있다. 이렇다 보니, 예전에는 잘 다루지 않았던 인공지능, 머신러닝과 관계가 깊은 알고리즘 등에 대해 깊이 이해를 할 필요가 있다. 이러한 알고리즘 등은 요즘 흔히 얘기 하는 빅 데이터 분석에서도 쉽게 사용되어지는 기술이기도 하다. (실은 BI, 인공지능, 머신러닝, 데이터 마이닝 등은 서로 관계가 있으면서도 다른 영역이다.)
헌데, 이런 알고리즘에 대해 이해를 하려면 기존에 하지 않았던 선형 대수학, 통계학 등의 쉽지 않은 지식들을 선행 학습을 반드시 해야 한다. 물론, 예전에 한번쯤은 접해봤던 것들이고, 공부를 하는 거에 대해서 큰 거부감은 없으나, 과거에 내가 해오던 일과의 괴리 때문에 잘 하던 걸 더 발전 시킬 수 없는 건 가 하는 생각도 들고, 이 일을 정말 잘 할 수 있을 까 의문점이 들게 되었다.
이런 와중에 산 호세에서 Strata+Hadoop World 2015에 참여를 하게 되었고, 빅 데이터 관련 최신 트랜드를 확인 하는 과정에 Python이 굉장히 큰 비중을 차지하고 있는 것을 보고 무척 놀랐었다. 빅 데이터 관련 기술들이 대부분 Java로 이루어져 있어, Java에만 신경을 쓰고 있었던 것은 나의 과오였었고, 웹 개발에는 Front-end, Back-end 포함한 Full-Stack JavaScript 쪽에 관심을 가지고 있었는데, 이쪽 분야를 보니 Python 커뮤니티가 굉장히 크고, Science 쪽에서는 가장 선호 하는 프로그래밍 랭귀지 라는 것을 알게 되었다.
실은 작년 말에 영국 자회사에 방문 했을 때도, 본인들이 필요한 툴들을 Python을 개발하여 업무에 활용하는 것을 보고서는 크게 감흥이 없었었다. 하지만, 지금 생각 해보니, Computer Science/Engineering 쪽에 백그라운드도 없고 경험도 없는 사람들이, 그저 본인들의 업무의 비효율성을 제거하고 생산성을 높이려는 목적으로 반복적으로 수행하던 업무를 본인들이 가장 쉽게 배울 수 있는 언어로 개선했다는 것에 조금 더 주목 했어야 하지 않았나 싶다.
해서, 개발자로서의 나의 경력을 이용하면서 수행하과 있는 과제를 진행하기 위해서는 알고리즘을 구현하는 엔지니어가 아니라, 잘 알려져 있는 알고리즘에 대한 특징, 장/단점을 파악 하고, 잘 알려져 있는 라이브러리들을 활용하여, 빠른 시간내에 구현해서 적용/테스트 하는 것이 지금 내가 할 수 있는 가장 가치 있는 일이라는 생각이 들었다. 또, 새로운 것을 배우고 싶어하는 목마름에 쉽게 다가갈 수 있는 Python은 수년전에 Node.js를 시작하면서 JavaScript 의 단순함과 자유도에 매력을 느꼈던 그때의 기분이 재현되게 해 줄 수 있을 거라는 생각이 들었다.
여기서 나는 Python 기반의 기계학습 구현이 가능한 엔지니어로 성장해보려고 한다. 그러다 보면 bottom-up으로 자연스럽게 알고리즘에 대한 이해와 필요한 기반 지식들을 익힐 수 있으리라 기대한다. 빅 데이터, 인공지능, 머신러닝, 딥러닝 등에 관심이 점점 많아지는 요즘, 나와 같이 전형적인 기업 IT 시스템을 개발 하던 많은 개발자들이 비슷한 고민을 하고 있다면, 훗날 좋은 경험담을 공유하고 싶다. :)
>_
일단, 내가 가지고 있던 'IT(Information Technology)' 기술은 중공업 분야의 플랜트 산업에 적용되고 있는 'OT(Operational Technology)' 기술과는 거리가 멀었다.
기존에는 복잡한 알고리즘 보다는 얼마나 단순하게 비즈니스 요구사항을 충족시키는 아키텍처를 설계/구현을 하고, 성능이슈 등은 불특정 다수의 사용자의 트래픽을 어떻게 하면 분산시키면서 빠르고 안정적이고 신뢰성 높은 시스템을 만들 수 있을 까를 고민하였다.
하지만 플랜트 쪽은 예전에 내가 다루던 아키텍처보다 훨씬 단순했고, 현재 최신 기술 트랜드에는 훨씬 미치지 못 하고 있었으나, 주기적으로 발생하는 플랜트의 운전 데이터를 통해 과거 데이터 학습을 통해 앞으로의 일을 예측하고, 예상하지 않았던 장애를 미리 방지 하여 플랜트의 수명을 연장 시키는 것에 초점이 맞추어져 있다. 이렇다 보니, 예전에는 잘 다루지 않았던 인공지능, 머신러닝과 관계가 깊은 알고리즘 등에 대해 깊이 이해를 할 필요가 있다. 이러한 알고리즘 등은 요즘 흔히 얘기 하는 빅 데이터 분석에서도 쉽게 사용되어지는 기술이기도 하다. (실은 BI, 인공지능, 머신러닝, 데이터 마이닝 등은 서로 관계가 있으면서도 다른 영역이다.)
헌데, 이런 알고리즘에 대해 이해를 하려면 기존에 하지 않았던 선형 대수학, 통계학 등의 쉽지 않은 지식들을 선행 학습을 반드시 해야 한다. 물론, 예전에 한번쯤은 접해봤던 것들이고, 공부를 하는 거에 대해서 큰 거부감은 없으나, 과거에 내가 해오던 일과의 괴리 때문에 잘 하던 걸 더 발전 시킬 수 없는 건 가 하는 생각도 들고, 이 일을 정말 잘 할 수 있을 까 의문점이 들게 되었다.
이런 와중에 산 호세에서 Strata+Hadoop World 2015에 참여를 하게 되었고, 빅 데이터 관련 최신 트랜드를 확인 하는 과정에 Python이 굉장히 큰 비중을 차지하고 있는 것을 보고 무척 놀랐었다. 빅 데이터 관련 기술들이 대부분 Java로 이루어져 있어, Java에만 신경을 쓰고 있었던 것은 나의 과오였었고, 웹 개발에는 Front-end, Back-end 포함한 Full-Stack JavaScript 쪽에 관심을 가지고 있었는데, 이쪽 분야를 보니 Python 커뮤니티가 굉장히 크고, Science 쪽에서는 가장 선호 하는 프로그래밍 랭귀지 라는 것을 알게 되었다.
실은 작년 말에 영국 자회사에 방문 했을 때도, 본인들이 필요한 툴들을 Python을 개발하여 업무에 활용하는 것을 보고서는 크게 감흥이 없었었다. 하지만, 지금 생각 해보니, Computer Science/Engineering 쪽에 백그라운드도 없고 경험도 없는 사람들이, 그저 본인들의 업무의 비효율성을 제거하고 생산성을 높이려는 목적으로 반복적으로 수행하던 업무를 본인들이 가장 쉽게 배울 수 있는 언어로 개선했다는 것에 조금 더 주목 했어야 하지 않았나 싶다.
해서, 개발자로서의 나의 경력을 이용하면서 수행하과 있는 과제를 진행하기 위해서는 알고리즘을 구현하는 엔지니어가 아니라, 잘 알려져 있는 알고리즘에 대한 특징, 장/단점을 파악 하고, 잘 알려져 있는 라이브러리들을 활용하여, 빠른 시간내에 구현해서 적용/테스트 하는 것이 지금 내가 할 수 있는 가장 가치 있는 일이라는 생각이 들었다. 또, 새로운 것을 배우고 싶어하는 목마름에 쉽게 다가갈 수 있는 Python은 수년전에 Node.js를 시작하면서 JavaScript 의 단순함과 자유도에 매력을 느꼈던 그때의 기분이 재현되게 해 줄 수 있을 거라는 생각이 들었다.
여기서 나는 Python 기반의 기계학습 구현이 가능한 엔지니어로 성장해보려고 한다. 그러다 보면 bottom-up으로 자연스럽게 알고리즘에 대한 이해와 필요한 기반 지식들을 익힐 수 있으리라 기대한다. 빅 데이터, 인공지능, 머신러닝, 딥러닝 등에 관심이 점점 많아지는 요즘, 나와 같이 전형적인 기업 IT 시스템을 개발 하던 많은 개발자들이 비슷한 고민을 하고 있다면, 훗날 좋은 경험담을 공유하고 싶다. :)
>_
2015년 3월 4일 수요일
Data Science with Python
출처 : "Ultimate Skills Checklist for Your First Data Analyst Job" by Udacity
Python programming language
: Python is a high level programming language with many useful packages written for it
[Python packages (“modules”)]
- NumPy
: an optimized python library for numerical analysis, specifically: large, multi-dimensional arrays and matrices. Found in Introduction to Data Science
http://www.numpy.org/
http://en.wikipedia.org/wiki/NumPy
- pandas
: an optimized python library for data analysis including dataframes inspired by R. Found in Introduction to Data Science
http://pandas.pydata.org/
http://en.wikipedia.org/wiki/Pandas_(software)
- matplotlib
: a 2D plotting library for python, includes the pyplot interface which provides a MATLAB-like interface (see ipython notebooks and seaborn below). Found in Introduction to Data Science
http://matplotlib.org/
http://en.wikipedia.org/wiki/Matplotlib
SciPy
: a library for scientific computing and technical computing. Found in Introduction to Data Science
http://www.scipy.org/
http://en.wikipedia.org/wiki/SciPy
scikit-learn
: machine learning library built on NumPy, SciPy, and matplotlib. Mentioned in Introduction to Machine Learning
http://scikit-learn.org/stable/
http://en.wikipedia.org/wiki/Scikit-learn
[optional]
iPython
: an improved interactive shell for python with introspection, rich media, additional shell syntax, tab completion, and richer history
http://ipython.org/
http://en.wikipedia.org/wiki/IPython
iPython notebooks
: a web-based interactive computational environment
http://ipython.org/notebook.html
http://en.wikipedia.org/wiki/IPython#Notebook
hosting: http://nbviewer.ipython.org/
anaconda
: a python package manager for science, math, engineering, data analysis with the intent of simplifying and maintaining compatibility between library versions. Also useful for getting started with ipython notebooks.
http://continuum.io/downloads
ggplot: and (in-progress) port of R’s ggplot2 which premised upon a grammar of graphics
http://ggplot.yhathq.com
seaborn: a Python visualization library based on matplotlib with a highlevel interface
http://web.stanford.edu/~mwaskom/software/seaborn/
Python programming language
: Python is a high level programming language with many useful packages written for it
[Python packages (“modules”)]
- NumPy
: an optimized python library for numerical analysis, specifically: large, multi-dimensional arrays and matrices. Found in Introduction to Data Science
http://www.numpy.org/
http://en.wikipedia.org/wiki/NumPy
- pandas
: an optimized python library for data analysis including dataframes inspired by R. Found in Introduction to Data Science
http://pandas.pydata.org/
http://en.wikipedia.org/wiki/Pandas_(software)
- matplotlib
: a 2D plotting library for python, includes the pyplot interface which provides a MATLAB-like interface (see ipython notebooks and seaborn below). Found in Introduction to Data Science
http://matplotlib.org/
http://en.wikipedia.org/wiki/Matplotlib
SciPy
: a library for scientific computing and technical computing. Found in Introduction to Data Science
http://www.scipy.org/
http://en.wikipedia.org/wiki/SciPy
scikit-learn
: machine learning library built on NumPy, SciPy, and matplotlib. Mentioned in Introduction to Machine Learning
http://scikit-learn.org/stable/
http://en.wikipedia.org/wiki/Scikit-learn
[optional]
iPython
: an improved interactive shell for python with introspection, rich media, additional shell syntax, tab completion, and richer history
http://ipython.org/
http://en.wikipedia.org/wiki/IPython
iPython notebooks
: a web-based interactive computational environment
http://ipython.org/notebook.html
http://en.wikipedia.org/wiki/IPython#Notebook
hosting: http://nbviewer.ipython.org/
anaconda
: a python package manager for science, math, engineering, data analysis with the intent of simplifying and maintaining compatibility between library versions. Also useful for getting started with ipython notebooks.
http://continuum.io/downloads
ggplot: and (in-progress) port of R’s ggplot2 which premised upon a grammar of graphics
http://ggplot.yhathq.com
seaborn: a Python visualization library based on matplotlib with a highlevel interface
http://web.stanford.edu/~mwaskom/software/seaborn/
Strata+Hadoop WORLD PyData 후기
http://strataconf.com/big-data-conference-ca-2015/public/schedule/full/public
PyData at Strata
PyData at Strata
- 머신러닝 라이브러리는 scikit-learn 활용
- 시계열성 시각화는 Bokeh
- 성능상 이슈가 있다면 Numba
- 데이터 로딩을 위해서는 Pandas
- 모든 작업은 iPython Notebook 으로..
- ipynb 공유를 위해서는 Jupyter로..
Description
Python has become an increasingly important part of the data engineer and analytic tool landscape. Pydata at Strata provides in-depth coverage of the tools and techniques gaining traction with the data audience, including iPython Notebook, NumPy/matplotlib for visualization, SciPy, scikit-learn, and how to scale Python performance, including how to handle large, distributed data sets. Come see how the leading lights in the Python data community are making Python ever more useful to data analysts and data engineers.
9:00am – 10:30am
Track 1 (room LL21 B):
- Machine Learning with scikit-learn
Andreas Mueller
scikit-learn has emerged as one of the most popular open source machine learning toolkits,
now widely used in academia and industry. scikit-learn provides easy-to-use interfaces to perform advanced analysis and build powerful predictive models. The tutorial will cover basic concepts of machine learning, such as supervised and unsupervised learning, cross validation and model selection. We will see how to prepare data for machine learning, and go from applying a single algorithm to building a machine learning pipeline.
now widely used in academia and industry. scikit-learn provides easy-to-use interfaces to perform advanced analysis and build powerful predictive models. The tutorial will cover basic concepts of machine learning, such as supervised and unsupervised learning, cross validation and model selection. We will see how to prepare data for machine learning, and go from applying a single algorithm to building a machine learning pipeline.
11:00am – 12:30pm
Track 1 (room LL21 B):
- Interactive Web Graphics with Bokeh
Peter Wang
Bokeh is an open-source library for building web graphics, ranging from simple interactive plots to complex dashboards with streaming data sources. This is tutorial will quickly introduce some of the basic concepts behind Bokeh and then dive into a step-by-step series of exercises which showcase how to embed interactive graphics in an IPython notebook and build more complex linked graphics. Streaming and large datasets will also be demonstrated.
1:30pm – 3:00pm
Track 1 (room LL21 B):
- Intro to Numba and Performance Python
Travis Oliphant
Numba is a just-in-time compiler for Python that can translate a wide range
of Python functions into high performance machine code at runtime. This
tutorial will give an overview of the capabilities of the Numba compiler and
walk through several examples showing how to use Numba to generate fast
implementations of numerical algorithms from pure Python. We will briefly
touch on more advanced features of Numba, such as compiling for the GPU, at
the end.
of Python functions into high performance machine code at runtime. This
tutorial will give an overview of the capabilities of the Numba compiler and
walk through several examples showing how to use Numba to generate fast
implementations of numerical algorithms from pure Python. We will briefly
touch on more advanced features of Numba, such as compiling for the GPU, at
the end.
Materials:
A basic installation of Anaconda. Example IPython notebooks will be posted to
GitHub before the tutorial.
A basic installation of Anaconda. Example IPython notebooks will be posted to
GitHub before the tutorial.
3:30pm – 5:00pm
Track 1 (room LL21 B):
- Analytics Beyond the Basics with pandas and SQL
Wes McKinney
In this tutorial, we’ll take a tour through a variety of useful, but sometimes tricky analytical tasks and show how they can be tackled with pandas or SQL. A part of the goal is to illustrate how SQL concepts map onto the pandas API and vice versa, and for the participant to learn more about advanced usage of each of the tools.
Materials will be posted at http://github.com/wesm/strata-sj-2015
2015년 3월 2일 월요일
2015년 2월 26일 목요일
Design Thinking - Post Agile:Discovery by Design
http://secure.nordstrominnovationlab.com/pages/our_process_told_as_our_team_s_timeline
2015년 2월 14일 토요일
2015년 2월 11일 수요일
SW개발자, 프레임워크로 내공쌓기 - 생보사 차세대 프로젝트
오늘은 그 토록 원하던 프레임워크팀으로 전배 한 뒤, 투입되어 5년간 진행했던 2개 대형 프로젝트 중 첫 번째 프로젝트에 대해서 애기 해보고자 한다.
2008년 말, 입사 2년차에 만 2년을 앞두고 원하던 부서로 옮긴 나는, 이제 프로젝트에 대한 욕심이 생기기 시작했다. 그때 당시에는 웬지 모르겠지만 금융권 프로젝트를 하고 싶었다. 그 동안, 국방, 공공, 대내 작은 프로젝트만 다녀서 그랬는지 모르겠지만, 웬지 금융권에서 돈과 관련된 프로젝트를 하면 돈을 만질 수 있을 거 같은 느낌이 들었을까.. 솔직히 그냥 해보고 싶었다.
마침 관계사 중 생보사 대형 차세대 프로젝트가 곧 시작될 예정이였고, 금융권에서는 거의 최초로 기존 레거시 시스템 전체를 Java로 전환하는 대규모 프로젝트였다. 난, 2주 정도 신규 팀에서 OJT를 받다가, 바로 해당 프로젝트에 투입이 되었다.
실은, 그 당시 같은 팀원 사람들을 보면 프로젝트에 투입되는 것을 그리 반기지 않았던 걸로 기억한다. 아무래도 본사 사무실에서 프레임워크 개발하는 것 보다 훨씬 업무 강도도 세고, 고객 눈치도 봐야 하고, 플젝 납기 기한도 맞춰야 되고.. 이리저리 신경 쓰이는 일이 많아서 일 것이다. 하지만, 난 그게 더 좋았다. 특히, 비즈니스에 대해서도 이해하고 싶어 했던 의지가 있었고, 젊을수록 더 고생해야 더 많이 배울 수 있을 것이라는 생각이 지배적이였다. 이런 내 생각과 의지는 앞으로 회사 생활하는 데 굉장히 많은 긍정적인 영향을 미쳤었다.
해당 프로젝트의 기존 시스템은 Cobol 기반이였고, Java로 전환하기 위해 SDS의 Java Spring 기반의 Anyframe Enterprise 기반으로 차세대 시스템을 구축하기 시작했다. Anyframe Enterprise 내의 OLTP, Batch, BTO(Center Cut)등의 제품들이 적용되었고, Anyframe Integration을 통해 대외계 연계까지도 적용을 한 프로젝트이다. 실은, 이때까지만 하더라도 Anyframe Enterprise 버전의 방향성과 로드앱에 대해서 구체적인 plan이 있지는 않았던 걸로 기억한다. 하지만, 대형 차세대 프로젝트의 도메인 지식 기반으로 해서 2년 동안 완성도가 무척 높아졌고, 이후에 대부분의 대형 프로젝트에서 러브콜이 쇄도 했었다. 팀원 모두 수 년간 무척 바쁘게 지내왔었다.
이해를 돕는 차원에서 Anyframe Enterprise에 대한 동영상 링크를 공유 한다.
http://vimeo.com/67370902
시간이 얼마 안 지났는데, 좀 유치한듯..ㅡㅡㅋ 현재는 잘 활용하지 않는 레전드임..ㅋ
내가 담당했던 업무는 BTO(Batch Type Online) 혹은 Center-Cut 이라는 이름의 프레임워크였다. 컨셉은 일반 배치 보다 비즈니스 로직이 복잡하고, 단발성 OLTP의 대량 처리를 위한 분산 병렬 처리 프레임워크라고 볼 수 있다.위 동영상의 일부를 캡쳐 해 보았다.
내가 초기에 그렸던 그림이 이렇게 변한 듯 하다.
Admin은 Center Cut의 작업을 관장하는 녀석이다. Center Cut Job을 등록 및 관리 하며, Job내의 다양한 기본 정보들을 핸들링 한다. 병렬 처리 할 쓰레드 개수라던지, 전처리/후처리 방법, 실행 시간/주기, Job간의 의존성/우선순위 등으로 볼 수 있겠다. 이렇게 정의된 Job은 구동시 각 서버에 설치되어 있는 Center Cut Engine에게 명령을 내린다. 그럼 Engine들은 자기가 할당 받은 쓰레드 개수 만큼 쓰레드를 생성시켜, 매핑되어 있는 다수의 WAS로 Online 모듈 호출을 시도 한다. 이는 가령 계좌 이체의 대량 처리인 회사 급여 이체 등의 비즈니스 로직에 적용이 가능하다.
이런 처리 기법은 기존 Cobol 대비 배치성 업무 수행 속도가 현저히 느릴 것이라는 JVM 기반의 Java가 가지는 단점을 보기 좋게 극복하는 좋은 사례가 되었으며, 기존 시스템 보다 오히려 처리 속도가 빨라졌다.
이 프레임워크를 개발 할 때, 일손이 부족하고 국내에는 기술력 놓은 인력들을 구하기 쉽지 않아서, 외주용역을 활용하였었다. 이때, 벨라루시의 한 업체와 업무를 진행하였는데, 그 당시만 하더라도 영어로 일하는 것이 다소 생소한 시기라 매주 컨퍼런스 콜이나 daily meeting 시에 알아듣기 힘든 러시아식 발음의 영어와 씨름 하기도 하였지만, 곧 적응이 되었고, 외국인 들과 일하는 것이 한편으로는 한국 개발자들과 일하는 것과의 차이가 커서 힘든 점도 많았지만, 영어 뿐만이 아니라 개발 방식에 대한 부분에서도 배울점이 무척 많았다. 그리고, 오픈 전 1년은 0.5 M/D(한명이 하루 반나절만 지원)만 계약을 하여 업무를 진행하였기 때문에, 짧은 시간에 필요한 내용들에 대해서 의논하고 대부분의 핵심 업무들은 내가 직접 진행 할 수 있어서 설계 및 개발/테스트 역량을 많이 끌어 올리는 계기가 되었다.
그리고 이 시점에 서서히 알려지고 있었던 애자일 방법론에 대해 공부하여 실 프로젝트에 적용까지 함으로써, 애자일 사상에 대해 동경하고 따르게 되는 계기가 되었었다.
해당 프로젝트는 24개월동안 많은 사람의 노력과 열정으로 완성이 되었고, 잘 마무리 되어 성공적으로 오픈하게 되었다. 이후 주변의 많은 보험사들이 해당 프로젝트 성공이후에 Java로 전환하는 프로젝트를 진행하게 되었고, 이는 훗날 SDS에서 처음이자 마지막으로 수행한 제 1금융권 차세대 프로젝트에 까지 영향을 끼쳤다고 생각한다.
2010년 11월경, SDS는 Anyframe 프레임워크 전체 제품에 대한 대외 컨퍼런스를 개최하게 되었다. 이때, Center Cut에 대한 발표를 직접 하였었고, 발표자료 링크를 공유 한다.
지금 생각해보니, 프로젝트 수행 당시 매일 야근과 휴일에 근무하기를 반복.. 연휴도 없이 지내면서 무척 힘들었지만, 가장 열심히 일해야 할 때, 좋은 프로젝트의 전체 싸이클을 경험하면서, 주요한 프레임워크 설계/개발에 깊이 참여하였고, 프로젝트내 개발자와 해외 개발자들과 협업하면서 만들어낸 산출물들이 좋은 결과로 이어진 것이 나에게는 큰 행운이 아니였나 싶다.
>_
기억에 남는 기술 : Java, Spring OLTP/Batch, WebLogic, Oracle, GWT, Apache MINA, JBoss Jgroups, Multi-Threading, Agile development
-- My Story ---------------------------------------
---------------------------------------------------
2008년 말, 입사 2년차에 만 2년을 앞두고 원하던 부서로 옮긴 나는, 이제 프로젝트에 대한 욕심이 생기기 시작했다. 그때 당시에는 웬지 모르겠지만 금융권 프로젝트를 하고 싶었다. 그 동안, 국방, 공공, 대내 작은 프로젝트만 다녀서 그랬는지 모르겠지만, 웬지 금융권에서 돈과 관련된 프로젝트를 하면 돈을 만질 수 있을 거 같은 느낌이 들었을까.. 솔직히 그냥 해보고 싶었다.
마침 관계사 중 생보사 대형 차세대 프로젝트가 곧 시작될 예정이였고, 금융권에서는 거의 최초로 기존 레거시 시스템 전체를 Java로 전환하는 대규모 프로젝트였다. 난, 2주 정도 신규 팀에서 OJT를 받다가, 바로 해당 프로젝트에 투입이 되었다.
실은, 그 당시 같은 팀원 사람들을 보면 프로젝트에 투입되는 것을 그리 반기지 않았던 걸로 기억한다. 아무래도 본사 사무실에서 프레임워크 개발하는 것 보다 훨씬 업무 강도도 세고, 고객 눈치도 봐야 하고, 플젝 납기 기한도 맞춰야 되고.. 이리저리 신경 쓰이는 일이 많아서 일 것이다. 하지만, 난 그게 더 좋았다. 특히, 비즈니스에 대해서도 이해하고 싶어 했던 의지가 있었고, 젊을수록 더 고생해야 더 많이 배울 수 있을 것이라는 생각이 지배적이였다. 이런 내 생각과 의지는 앞으로 회사 생활하는 데 굉장히 많은 긍정적인 영향을 미쳤었다.
해당 프로젝트의 기존 시스템은 Cobol 기반이였고, Java로 전환하기 위해 SDS의 Java Spring 기반의 Anyframe Enterprise 기반으로 차세대 시스템을 구축하기 시작했다. Anyframe Enterprise 내의 OLTP, Batch, BTO(Center Cut)등의 제품들이 적용되었고, Anyframe Integration을 통해 대외계 연계까지도 적용을 한 프로젝트이다. 실은, 이때까지만 하더라도 Anyframe Enterprise 버전의 방향성과 로드앱에 대해서 구체적인 plan이 있지는 않았던 걸로 기억한다. 하지만, 대형 차세대 프로젝트의 도메인 지식 기반으로 해서 2년 동안 완성도가 무척 높아졌고, 이후에 대부분의 대형 프로젝트에서 러브콜이 쇄도 했었다. 팀원 모두 수 년간 무척 바쁘게 지내왔었다.
이해를 돕는 차원에서 Anyframe Enterprise에 대한 동영상 링크를 공유 한다.
http://vimeo.com/67370902
시간이 얼마 안 지났는데, 좀 유치한듯..ㅡㅡㅋ 현재는 잘 활용하지 않는 레전드임..ㅋ
내가 담당했던 업무는 BTO(Batch Type Online) 혹은 Center-Cut 이라는 이름의 프레임워크였다. 컨셉은 일반 배치 보다 비즈니스 로직이 복잡하고, 단발성 OLTP의 대량 처리를 위한 분산 병렬 처리 프레임워크라고 볼 수 있다.위 동영상의 일부를 캡쳐 해 보았다.
내가 초기에 그렸던 그림이 이렇게 변한 듯 하다.
Admin은 Center Cut의 작업을 관장하는 녀석이다. Center Cut Job을 등록 및 관리 하며, Job내의 다양한 기본 정보들을 핸들링 한다. 병렬 처리 할 쓰레드 개수라던지, 전처리/후처리 방법, 실행 시간/주기, Job간의 의존성/우선순위 등으로 볼 수 있겠다. 이렇게 정의된 Job은 구동시 각 서버에 설치되어 있는 Center Cut Engine에게 명령을 내린다. 그럼 Engine들은 자기가 할당 받은 쓰레드 개수 만큼 쓰레드를 생성시켜, 매핑되어 있는 다수의 WAS로 Online 모듈 호출을 시도 한다. 이는 가령 계좌 이체의 대량 처리인 회사 급여 이체 등의 비즈니스 로직에 적용이 가능하다.
이런 처리 기법은 기존 Cobol 대비 배치성 업무 수행 속도가 현저히 느릴 것이라는 JVM 기반의 Java가 가지는 단점을 보기 좋게 극복하는 좋은 사례가 되었으며, 기존 시스템 보다 오히려 처리 속도가 빨라졌다.
이 프레임워크를 개발 할 때, 일손이 부족하고 국내에는 기술력 놓은 인력들을 구하기 쉽지 않아서, 외주용역을 활용하였었다. 이때, 벨라루시의 한 업체와 업무를 진행하였는데, 그 당시만 하더라도 영어로 일하는 것이 다소 생소한 시기라 매주 컨퍼런스 콜이나 daily meeting 시에 알아듣기 힘든 러시아식 발음의 영어와 씨름 하기도 하였지만, 곧 적응이 되었고, 외국인 들과 일하는 것이 한편으로는 한국 개발자들과 일하는 것과의 차이가 커서 힘든 점도 많았지만, 영어 뿐만이 아니라 개발 방식에 대한 부분에서도 배울점이 무척 많았다. 그리고, 오픈 전 1년은 0.5 M/D(한명이 하루 반나절만 지원)만 계약을 하여 업무를 진행하였기 때문에, 짧은 시간에 필요한 내용들에 대해서 의논하고 대부분의 핵심 업무들은 내가 직접 진행 할 수 있어서 설계 및 개발/테스트 역량을 많이 끌어 올리는 계기가 되었다.
그리고 이 시점에 서서히 알려지고 있었던 애자일 방법론에 대해 공부하여 실 프로젝트에 적용까지 함으로써, 애자일 사상에 대해 동경하고 따르게 되는 계기가 되었었다.
해당 프로젝트는 24개월동안 많은 사람의 노력과 열정으로 완성이 되었고, 잘 마무리 되어 성공적으로 오픈하게 되었다. 이후 주변의 많은 보험사들이 해당 프로젝트 성공이후에 Java로 전환하는 프로젝트를 진행하게 되었고, 이는 훗날 SDS에서 처음이자 마지막으로 수행한 제 1금융권 차세대 프로젝트에 까지 영향을 끼쳤다고 생각한다.
2010년 11월경, SDS는 Anyframe 프레임워크 전체 제품에 대한 대외 컨퍼런스를 개최하게 되었다. 이때, Center Cut에 대한 발표를 직접 하였었고, 발표자료 링크를 공유 한다.
지금 생각해보니, 프로젝트 수행 당시 매일 야근과 휴일에 근무하기를 반복.. 연휴도 없이 지내면서 무척 힘들었지만, 가장 열심히 일해야 할 때, 좋은 프로젝트의 전체 싸이클을 경험하면서, 주요한 프레임워크 설계/개발에 깊이 참여하였고, 프로젝트내 개발자와 해외 개발자들과 협업하면서 만들어낸 산출물들이 좋은 결과로 이어진 것이 나에게는 큰 행운이 아니였나 싶다.
>_
기억에 남는 기술 : Java, Spring OLTP/Batch, WebLogic, Oracle, GWT, Apache MINA, JBoss Jgroups, Multi-Threading, Agile development
2015년 1월 14일 수요일
2015년 1월 3일 토요일
about Predix from GE
http://www.geglobalresearch.com/innovation/predix-software-platform-industrial-internet
2014년 12월 31일 수요일
사원 SW개발자의 고군분투 적응기
오늘은 SDS에서의 사원 시절 생활을 적어보려고 한다.
방법론팀에 배정받은 나는 자연스럽게 엔지니어링 업무가 짙었던 형상관리 툴 관련 업무를 맡게 되었다. 당시에 나와 함께 배정받은 동기녀석도 같은 업무 였는데, 나는 주로 SI(System Integration)쪽을 맡았고, 그 친구는 SM(System Maintenance) 쪽을 맡았다. 군대도 줄을 잘 서야 한다는 데, 이는 향후 둘의 커리어의 방향과 직결되는 것이였다는 것을 뒤늦게 알게 되었다. 결과적으로 보았을 땐, 난 성향 자체가 SI 사업이 맞았고, 처음에는 케어(?)를 잘 받지 못 했지만, 내가 원하는 방향으로 커리어를 쌓아 갈 수 있었다.
우리 방법론이 사용하던 형상관리 툴은 Serena사의 Dimensions 라는 제품이였다. 아마, 일반 개발자들에게는 다소 생소하지 않을 까 싶다. 그 당시만 하더라도 CVS, PVCS등이 주로 쓰여지고 있었고, Subversion도 사용이 많이 되고 있던 시점이였다. 헌데 듣보잡 디멘전이라니.. 해당 툴은 다른 소스 형상관리 툴과는 다르게, 이슈 관리/트래킹이 한 제품으로 되는 솔루션이였다. 아무래도, 방법론과 함께 엮다 보니, 소스 리비전과 이슈가 관계를 맺어야 하기 때문에 이 제품이 선택 된 걸로 생각된다. 하지만, 해당 기능은 짧은 기간내에 수많은 리비전이 만들어지고 커밋/롤백이 난무한 SI 플젝에서는 그닥 어울리는 제품이 아니였다. 하지만, SM기반의 유지보수가 주인 현장에서는 자그마한 커밋도 쉽게 허용이 되지 않아야 하고, 안전성을 최우선으로 두는 경향이 짙기 때문에, 현재도 사내포탈과 연계하여 커스터마이징 한 버전이 사용되고 있다.
앞에서 언급했듯이 난 주로 대내외 SI 프로젝트를 돌아디나면서, 형상관리 툴을 세팅해주고, 개발자들을 교육시키는 일을 주로 했었다. 먼넘의 툴이 설치가 이리도 복잡하던지, 메타 데이터를 오라클 디비에 넣고, 라이센스 서버, 웹 서버 등을 따로 다 설치하고, 버전 업그레이드 되면 동일 작업을 반복하고.. 하여간 손 가는 작업이 무척 많았다. 그리고, Pessimistic Locking 정책에 따라, 소스를 수정하기 위해서 반드시 Check Out을 하여 Lock을 확보해야만 사용 가능 한것이 default 설정이였고, 많은 개발자들이 이런 부분들을 불편해 했다. 솔직히, 형상관리 툴을 교육 하는 것 자체에 대해 무슨 필요성이 있는 지 모르겠다는 개발자들이 대부분이였지만, 일반 형상관리 툴과는 다르게, 사용법이 복잡했고, 이슈까지 연계까 되다보니, 본의아니게 욕(?)을 많이 먹었던 걸로 기억한다.
프로젝트 상주기간은 case by case 였었다. 2~3일이면 끝나는 곳도 있었고, 길면 3개월씩 상주하기도 하였다. 행자부, 교육부, 법무부 등의 공공 프로젝트, 금융권 증권/보험사 프로젝트, 삼성 그룹사 SI 프로젝트, 군 프로젝트 등 전국방방곡곡을 돌아다녔던 걸로 기억한다.
사람 만나기 좋아하고, 돌아다니기 좋아했던 나에게는 새로운 환경에 적응하면서 내가 가진 기술을 알리는 작업이 즐겁기는 하였으나, 개발에 항상 목 말라 했던 나는 항상 무언가 부족함을 느끼곤 하였다. 이런 나의 솔직한 마음을 선배 및 팀장님에게 기회가 될 때 마다 이야기 하였고, 개발 거리를 찾던 중, 형상관리 솔루션과 연계하여 자그마한 자체 프로젝트를 하게 되었다.
컨셉은 간단했다. 그 당시의 개발 프로세스의 대한 상태를 그래프화하여 현실성 있는 개발 진척도를 가시화하고, 이를 플젝 전체에 공유하여 동기부여 수단으로 사용하고, 투명화하겠다는 개념이였다. 가령, 개발자가 Task를 할당 받으면 상태는 '개발중' 이고, 개발이 완료되면 소스 최종 커밋 이후 연결되어 있는 Task의 상태를 'PL검토중'으로 변경하면서 담당 PL에게 전달한다. PL은 단위테스트 완료 유무 및 자체 테스트를 통해 개발이 완료되었다고 판단이 되면 '개발완료' 로 변경하고, 그렇지 않다면 '개발중'으로 변경하여 다시 개발자에게 전달한다. 이런 과정을 실시간으로 시각화 하는 개념으로 보면 되겠다.
소스 관리 및 이슈(태스크) 관리가 디멘전 하나로 관리가 되고 있었고, 모든 메타 정보는 오라클 DB에 들어 있었으며, 친절하게도 데이터 핸들링이 가능한 Api가 있었으나, 무척 불편하고 배우기도 어려웠기에, DB의 테이블 구조를 일일히 그려나가면서 개발해 나가기 시작했다. 이미, 이런 식의 개발은 해본 경험이 있었기 때문에, 어렵지 않게 구현할 수 있었다. 단순 JSP형태로 개발한 걸로 기억한다. 껍대기는 어디서 템플릿화 되어 있는 걸 가져왔었고, WAS는 Tomcat.. 크리티컬한 시스템은 아니였기 때문에, HA구성까지는 할 필요가 없었다. 헌데, 만드는 것 까지는 쉬었는데, 해당 화면을 보는 주요 의사 결정권자들이 너무 많았던 것이 탈이였다. 처음에는 내 소속 PL의 요청에 따라 개발을 완료하고 나니, TM(Test Manager)가 다른 의견을 보여주고, 그래서 변경하면 PM(Project Manager)가 한 마디 하고, 나중에 프로젝트에 공개하니, 각 모듈 담당 PL(Project Leader)들이 또 다른 요구사항을 내기 시작하고.. 그 당시 한 달 정도면 개발 및 테스트, 배포까지 마무리할 생각으로 투입되었던 여의도 모 증권사 차세대 프로젝트에서 3개월 이상 머물렀던 걸로 기억 한다. 그리 달갑지 않은 기억이였지만, 요구공학에 대한 필요성과 정제 작업, 데이터 수집 및 효과적인 시각화 등에 대해 깊이 고민하게 해주었던 플젝이였다.
어느 정도 형상관리쪽이 익숙해지니 다른 툴에도 관심을 가지게 되었다. 그 당시 방법론을 지원하는 툴셋을 통합개발플랫폼 이라고 칭하였고, 결국 나의 업무는 '통합개발플랫폼 개선 및 확산'으로 2년 정도 수행하였다. 형상관리툴에 더해서, EA나 ERWin과 같은 설계 툴, Eclipse 같은 개발IDE(Integrated Development Environment), CI(Continuous Integration)을 위한 Ant, Maven, Hudson 등.. 개발을 위해서 필요한 대부분의 모든 툴에 대해서 경험을 하게 되었고, 서로 연계 하는 작업에도 동참하게 되었다. 정기적으로 진행했던 방법론 교육과정의 실습 환경 구성을 하기도 하였고, 후반에는 전체 툴에 대한 엔지니어링 및 기술 지원 등을 수행하였었다. 이는 SA로 성장하게 되는 좋은 밑거름이 되어주었다.
하지만, 처음부터 Framework 개발을 하고 싶었던 나에게, 솔루션을 배워서 하는 것 보다는 직접 개발에 뛰어 들어서, 대형 SI 프로젝트를 하고 싶었던 욕구가 무척 강했던 걸로 기억한다. 그리고 2년차때 소속 팀장이 이러한 내 성향을 잘 이해하고 있던 상황이였었다. 이게 개인 평가에는 도움이 되지 않았지만, 부서를 옮기는 데에는 기여를 하게 된다.
그 당시 회사에서는 엔터프라이즈급 상용 비즈니스 Framework를 개발 하겠다는 계획이 진행되고 있었고, TFT가 추진되고 있었다. 1년차때 알던 선배 한분이 해당 TFT에 있었고, 우연히 2년차 여름쯤에 진행되었던, 각 센터/TFT 추진현황 공유시 해당 TFT에서 내부인력 대상으로 인력을 모집하고 있다는 것을 보게 되었다. 내부인력이 대상인 이유는 보안상 이슈 및 내부 역량 강화가 원인이였을 것으로 본다. 그 날, 발표를 마친 선배를 지체없이 쫓아가 농담 한 마디 건넸다.
"선배님, TFT가서 저 불러주신다고 하시더니, 연락이 없으시네요? ㅋ. 잘 지내시죠?"
선배 왈, "오, 인석씨. 오랜만이에요. 안 그래도 하고 싶은 얘기가 있는데 시간 괜찮아요?"
갑자기 하늘에서 종이 울리는 기분이였다. 난, 선배와 커피숍에서 한 시간 정도 이야기를 나누었고, 선배는 같은 본부에 옆 센터에 있던 나를 후보로 선정해주었다. 이는 비공식적으로 TFT장에게 올라갔으나, 결국 공식적으로 내 이름 석자가 내부인력 충원 대상 후보 인력으로 거론되기 시작했고, 내 소속 팀장이 동의 해주면서 난 팀을 옮기게 되었다.
실은, 입사 1,2년차 된 사원이 지금 내가 하는 일은 재미가 없으니, 딴 일을 시켜달라고 하는 경우는 거의 없다고 볼 수 있겠다. 보통, 본인들이 하고 있는 일이 무엇인지 잘 모를때가 많고, 조직적으로 보았을 때는 개인 평가에 좋지 않은 영향을 끼칠 수 있기 때문이다. 하지만, 나는 다른 사원들보다 2년이라는 개발 경험을 가지고 있었으며, 하고 싶은 일에 대한 의견 개진을 주저 없이 했기 때문에, 내가 원하는 부서로 전배 갈 수 있었다. 물론, SDS에는 본인이 원한다면 TO가 있는 부서로 팀장 협의 없이 일단 시스템을 통해 신청하여 옮길 수 있는 훌륭한 제도가 있지만, 난 그런 방식은 원하지 않았다. 회사 입장에서 보았을 때, 개인이 가장 하고 싶고 잘 할 수 있는 일에 배치를 하는 것이 회사에서도, 개인에게도 득이 된다고 보기 때문이다.
많은 인력들이 입사 초년에 적응에 실패하고 회사를 떠난다. 힘든 것도 있을 것이고, 생각 했던 것과 너무나도 다른일들이 본인에게 닥치기 때문인 듯 하다. 우리나라 대기업 문화 상, 신입사원으로 뽑힌 인력이 명확히 무슨일을 해야 될지를 입사 전 부터 제시하고 지켜나가는 경우는 극히 드물다고 봐야 한다. 그리고, 갓 졸업한 대학생들 역시, 본인들이 하고 싶은 일이 무엇인지, 아니면 최소한 본인 잘 하는 일이 무엇인지 잘 알지 못 하는 경우가 허다하다.(한국식 교육이 만든 결과라고 생각한다.)
하지만, 이걸 반대로 해석한다면, 회사가 원하는 인재상은 특별한 기술을 가진 사람이 아니라, 회사에 잘 맞는 사람을 뽑는 다는 것.. 그리고 그 사람에게 많은 돈을 투자하여 키운 다는 것, 그리고 입사 이후에 본인에게 맞는 일이 주어질 수도 있고, 그렇지 않더라도 할 수 있는 일이 무지 많다는 것 등은 장점으로 적용 될 수 있지 않을 까 싶다..
다음 포스트에서는 그렇게도 원하던 프레임워크 팀으로 이동하여, 진행했던 두 개의 대형 프로젝트에 대해 얘기 해보고자 한다. 지금 생각 해도, 증말 재미있던 플젝들이다.
To be continued..
>_
관련 기술 : Dimensions CM, Subversion, ERwin, EA, Eclipse, Jenkins, JSP, Java, Oracle, Tomcat, SQL 등
-- My Story ---------------------------------------
---------------------------------------------------
관련 기술 : Dimensions CM, Subversion, ERwin, EA, Eclipse, Jenkins, JSP, Java, Oracle, Tomcat, SQL 등
2014년 12월 26일 금요일
[번역] Half a decade with Go - 고랭 5주년을 맞이하여..
고랭에 대한 관심이 많아지고 있는 가운데, 지난 달에 본 글이 기억 나서 번역 해 봅니다. 중간 중간에 링크들이 고랭의 설계 사상들을 이해하는 데 도움이 되겠네요.. 도움 되시길 바랍니다.
원문 링크 : http://blog.golang.org/5years
원문 링크 : http://blog.golang.org/5years
Go와 함께 한 5년
10 November 2014
5년전, 우리는 Go 프로젝트를 시작하였습니다. 첫번째 공식 릴리즈를 준비하고 있었던 것이 마치 어제 같군요: 우리의 웹사이트(website)는 사랑스러운 노란 빛깔이였고, 우리는 Go를 "시스템 언어"라 불렀으며, 여러분은 반드시 세미콜론으로 문장의 끝을 알려야 했고, 빌드를 하기 위해서 Makefiles를 만들어야만 했었습니다. 우리는 Go가 어떻게 받아들여질지 몰랐습니다. 사람들과 우리의 비전과 목표를 공유 할 수 있을까? 사람들이 Go가 쓸만하다고 할까?
출시하는 순간, 엄청난 기대가 우리를 기다리고 있었습니다. 구글은 새로운 프로그래밍 언어를 개발해오고 있었으며, 모두들 그게 무엇인지 확인하고 싶어 했습니다. 어떤 프로그래머들은 Go의 보수적인 기능 세트에 관심을 끊어 버리기도 했죠—처음 흘겨 보고서는 이렇게 얘기 했죠. "여기에는 아무것도 없어"—하지만 더 작은 한 그룹은 소프트웨어 엔지니어로써의 니즈에 꼭 맞는 에코 시스템의 시작을 보기도 하였습니다. 이 분들이 바로 Go 커뮤니티의 커널입니다.
Gopher illustration by Renee French
첫 릴리즈 이후, Go의 밑바탕에 깔려 있는 목적과 설계 사상에 대해 제대로 알려지게 되는 데에는 시간이 좀 걸렸죠. Rob Pike 은 2012년에 작성한 에세이 (Go at Google: Language Design in the Service of Software Engineering) 에서 이를 유창하게 설명하고 있으며, 그의 블로그(Less is exponentially more)에서도 조금더 개인적인 의견을 개진해 주었습니다. Andrew Gerrand 가 작성한 Code that grows with grace (slides) 와 Go for Gophers (slides) 는 조금 더 깊이 그리고 기술적으로 Go의 설계 철학을 기술하고 있습니다.
시간이 흐르자, 적은 인원은 점점 많아집니다. 프로젝트의 터닝 포인트는 안정적인 언어와 개발자들이 신뢰할 수 있는 표준 라이브러리를 제공하였던, 2012년 3월의 Go 1 릴리즈 때 입니다. 2014까지 프로젝트는 수백명의 핵심 조력자(contributor)들을 가지게 되었으며, 에코시스템은 수 천명의 개발자들이 관리하고 있는 셀 수 없는 라이브러리와 툴들(libraries and tools)을 지니게 되었으며, 보다 커진 커뮤니티는 "고퍼스(gophers)"라 불리오는 열정적인 구성원들이 참여하고 있습니다. 오늘날, 우리의 최근 지표에 의하면, Go 커뮤니티는 우리의 생각보다 더 빨리 커지고 있습니다.
어디서 고퍼스들을 찾을 수 있을까요? 전 세계적으로 열리고 있는 다양한 Go 이벤트에서 찾아 볼 수 있습니다. 올해에는 몇몇의 헌신적인 Go 컨퍼런스들을 볼 수 있었습니다 : 덴버와 파리에서 첫 회를 맞이한 GopherCon 와 dotGo 컨퍼런스, Go DevRoom at FOSDEM 와 도쿄에서 연 2회 열리는 GoCon 컨퍼런스 등이 있습니다. 각 이벤트에는 전 세계의 고퍼스들이 열렬하게 Go 프로젝트들을 소개해주었습니다. Go 팀에게는 수 많은 개발자들에게 우리의 비전과 흥분을 공유 할 수 있었기에, 무척이나 만족스러운 일이였습니다.
1,200명이 넘는 고퍼스들이 덴버에서의 GopherCon 과 파리에서의 dotGo에 참석하였습니다.
물론, 전 세계적으로 각 도시마다 수 십개의 커뮤니티(Go User Groups)가 운영되고 있습니다. 아직 여러분이 계신 곳의 로컬 그룹을 방문하지 않았다면, 방문해보세요. 만약에 없다면, 여러분이 시작해보는 것(start one)은 어떨까요?
오늘날, Go는 클라우드에 둥지를 틀었습니다. Go는 산업이 클라우드 컴퓨팅을 향해 구조를 변경하는 것고 발 맞추어 안착했고, 이러한 움직임의 주요한 부분을 지켜 보는 것은 무척 흥분되는 일이였입니다. Go의 단순함, 효율성, 내장된 동시성 프리미티브(built-in concurrency primitives), 그리고 모던 표준 라이브러리들은 Go가 클라우드 소프트웨어와 궁합이 잘 맞게 해줍니다(어찌됐든, Go는 이걸 위해 설계되었죠). Docker 와 Kubernetes 와 같은 특정 오픈소스 클라우드 프로젝트는 Go로 작성되어 오고 있으며, Google, CloudFlare, Canonical, Digital Ocean, GitHub, Heroku, and Microsoft 와 같은 인프라스트럭처 회사들은 지금 Go를 사용하여 주요한 업무를 수행하고 있습니다.
자, 그렇다면 앞으로 무슨 일이 벌어질까요? 우리는 2015년이 Go의 가장 최고의 해가 되리라 생각됩니다.
Go 1.4—추가 기능 및 수정 사항(new features and fixes)—는 새로운 low-latency 가비지 콜렉터를 위한 기초작업이 수반되었으며, 모바일 장치에서 돌아가는 Go를 지원합니다. '14년 12월 1일에 릴리즈 됩니다. '15년 1월 1일, 넓은 범위의 어플리케이션을 위한 Go 1.5에는 새로운 GC
를 사용 할 수 있을 거라 기대합니다. 어디에서 사람들이 Go 1.5를 받아 갈지, 기다릴 수가 없군요.
를 사용 할 수 있을 거라 기대합니다. 어디에서 사람들이 Go 1.5를 받아 갈지, 기다릴 수가 없군요.
그리고 다음과 같이 더욱 훌륭한 이벤트들이 개최 됩니다. GothamGo (뉴욕, '15년 11월),
Go DevRoom at FOSDEM(브뤼셀, '15년 1/31~2/1; get involved!), GopherCon India(방갈로, '15 2/19~21), 원조 GopherCon (덴버, '15년 7월), dotGo (파리, '15년 11월).
Go DevRoom at FOSDEM(브뤼셀, '15년 1/31~2/1; get involved!), GopherCon India(방갈로, '15 2/19~21), 원조 GopherCon (덴버, '15년 7월), dotGo (파리, '15년 11월).
Go팀은 모든 고퍼스 여러분께 감사의 말을 전합니다. 이제 다음 5년을 함께 하시죠.
Go 5주년을 축하하기 위하여, 다음달('14년 12월)에 Gopher Academy 에서 유명한 Go 사용자들의 글들이 올라올 예정입니다. Go의 행보를 확인 하고 싶다면, 블로그(their blog)를 방문해주세요!
2014년 12월 25일 목요일
사회 초년생 SW개발자의 1차 방황기 - 회사 옮기기(HIT->SDS)
사회생활 시작한 이례, 겨울 휴가를 보내는 건 처음인 듯 하다. 이를 기념하여, 지난 글(풋내기 개발자의 대기업 취업 수기) 에 이어, 첫 입사 이후 1년 동안의 행적을 돌이켜 본다.
현대정보기술(HIT)에 입사하여 처음 배정받았던 부서는 해외금융개발팀(명확하지는 않은 듯..)이였다. 중간에 이름이 한번 바뀌었고, 워낙 짧은 기간동안 근무를 해서 부서명은 기억이 잘 나지 않는다. 입사 할 당시 "현대" 그룹이 여러 그룹으로 쪼개지면서, 회사가 많이 어려워졌고, 현대 그룹 소속도 아닌 걸 알고 있었지만, 한때 가장 잘 나가던 규모있는 SI업체 였고, 주변에 입사 지원했던 동기들도 모두 능력이 훌륭했기 때문에, 또한, 베트남에 나갈 수 있다는 기대가 컸었던 걸로 기억 한다.
처음 담당했던 업무는 베트남 농업은행 시스템 유지보수 였다. 우리나라로 따지면, 농협은행과 같다고 보면 된다. 회사에 들어가면 최신 기술들을 써 볼 수 있겠지.. 하는 기대와는 정 다르게, 해당 시스템은 파워빌더6 버전에 그리 유명하지 않은 DB 기반으로 구축되어 있었던 걸로 기억한다. 곧, 차세대에 투입될 예정이라며, 기존 시스템을 조금씩 보고 있었다. 하지만, 솔직히 말하자면, 업무가 너무 없었다. 프로젝트도 국가 기반 사업이라, 국가에 돈이 있어야 되는데, 국제 기금을 빌려서 진행하는 형태라, 언제 시작 할 지도 불투명한 상태였다. 혈기왕성 했던 나는, 열심히 현장에서 굴러 내실을 다지고 싶었으나, 그렇지 못하는 상황에 대해 무척 불안해 했었다. "이래서야 성장 할 수 있을 까?" 이런 질문이 계속 머리속을 맴돌고 있었다. 게다가, 파워빌더라니.. 마음을 붙이기 어려웠다.
그 당시 함께 입사하였던 친구 중 같은 부서에 굉장히 일을 잘 하던 친구가 있었다. 나보다 한 학번 많지만 나이는 같았고, 군대는 방위산업체에서 산업요원으로 근무하면서 해결한 친구였다. 보통, 이런 경력을 가진 친구들은 다른 사람들 삽질하고 있을 때, 실제 필드에서 험하게(?) 구르기 때문에, 대부분 개발에 있어서는 다른 인력보다 무시 못하는 내공이 있기 마련이다. 나와도 무척 얘기가 잘 통했고, 나보다 훨씬 세상 물정에 대하 밝았다.
하루는 나에게 다가와 솔기한 이야기를 전한다.
"SDS에서 신입사원 뽑드라..봤냐?"
삼성맨이 되고 싶었으나, 한번 미끄러져본 경험이 있었고, 그 당시만 해도, 막 졸업한 사람만 뽑던 터라, 나는 대상이 아니라고 생각하고 있었다.
"어차피 나는 대상에 못 들어갈껄? 졸업한지 몇 년 지났는디?"
하지만 역시, 이 친구는 그냥 나에게 해 본 소리가 아니였다.
"너, 올해 전역했자나. 입사 공고 보면, 올해 혹은 내년 졸업 예정자, 아니면 올해 군 전역자던데?"
난 바로 채용공고를 확인 했고, 두말도 없이 입사 지원을 하였다.
지난번에는 삼성전자를 썼다가 떨어졌고, 솔직히 미련도 없었기 때문에, 전문 SI 업체에서 일하고 싶었던 마음을 유지하면서, 삼성SDS 에 입사 지원을 하였다.
SSAT를 잘 통과하고 면접 준비를 하기 위해, 아주 잠시 자발적인 스터디 그룹에 참여 했었다. 하지만, 개발경험도 있고, 회사에 대해 자세히 알고 있었던 나에게, 일반 대졸 예정자 학생들이 진행하던 스터디는 너무나 유치했었다. 물론, 어떤 식으로 면접이 진행 된 다는 것에는 도움이 되었으나, 그 정도는 웹사이트에서도 얻을 수 있는 정보였었던 듯.. 오히려 혼자 조용한 방 안에 앉아서 예상되는 면접 질문들을 유추해보고, 답변하는 모습을 녹화해 놓고 다시 돌려 보면서, 말하는 모습이나 자세, 억양, 눈빛 등을 연습해보고 마음속으로 계속 그려 보는 연습을 하는 것이 오히려 도움이 되지 않을 까 싶다.
면접은 4개 면접으로 진행 되었었다. 인성 면접, 그룹 면접, 영어 면접, PT 면접 이였는데, 순서는 사람들마다 조금씩 달랐던 듯.. 면접 질문들이 모두 기억 나진 않지만.. 인성 면접에서 중요한 건 솔직함 이였던 걸로 기억한다. 그리고 난 이미 직장생활을 하고 있었기 때문에, 직장생활 관련된 질문도 꽤 있었다. 왜 옮기려고 하는지, 하루 일상 생활에 대해서 설명 해보라고 하던지, 군대에서 SW개발병을 했다고 하는데, 그런 업무를 하는 사람이 군대 안에 있으면, 우리 같은 회사가 군대에서 일하기 어렵지 않겠냐 라던지.. 이런 식의 내용이였다. 그룹 면접에서는 주제를 하나 주고, 찬반을 양쪽으로 나눠서 팀을 가른 다음에 집단 토론 하는 형태로 진행 했었다. 정답을 얘기 하기 보다는 어떻게 여러 사람과 대화를 나눠 가는지, 이끌어 가는지 등을 주로 보는 듯.. 가장 중요한 건, 다른 사람의 의견을 경청하고, 답을 할 때 그에 대한 지지 혹은 반대 의견을 개진해 나가면 되었던 듯.. 영어 면접은 꼬리에 꼬리를 이어가는 식의 현지인의 질문, 가령.. 여행을 좋아 하냐, 어디로 가느냐, 거기 가면 머하냐 이런 식으로 물어보면 짧게 답을 했던 듯.. 기억 나는 것 중 하나가.. 서해 뻘에 가서 키조개를 캐는 걸 설명하려다가 낭패를..ㅡㅡㅋ 머 여튼.. 그리고 종이에 질문이 하나 적혀 있었다. 친구가 니 카페트를 더렵혔는데, 어떻게 할거냐.. 머 이런식의 질문에 대해 의견을 얘기 하는 거였다. 나야 머.. I don't care.. 식으로 넘어가면서, 친군데 머 어떻냐고 답을 했었다. 마지막 PT 질문은 지금도 기억이 난다. A, B, C사에 상용 데이터베이스 a, b, c가 있는데, 어떤 시스템을 구축하는 PM이라면 무슨 상용 데이터베이스를 선택하겠느냐 라는 것이였다. a는 오라클, b는 이름은 알려져 있지만 많이 사용하지는 않는 것.. 그리고 c는 SDS자체 솔루션이였던 듯..ㅡㅡㅋ 시스템의 크기가 그리 크기 않았고, 내 생각에는 오라클을 쓰는 것 보다는 그나마 인지도가 있고 상대적으로 저렴한 b 제품을 쓰는 것이 좋겠다.. 닭 잡는 데 소 잡는 칼 쓸 필요가 있겠느냐 라는 식으로 답을 했다.. 면접관들은 별 질문이 없었고, 끄덕 였던 듯..ㅋ
솔직히 면접 준비는 많이 하지 않았지만, 다른 입사지원자들과는 다르게 2년 반 정도의 개발 경력이 있었고, 적당히 화려한(?) 말빨 덕분에 어렵지 않게 통과 하였다. 해서, 2006년 12월, 공식적으로 삼성SDS에 입사하면서, 그렇게도 그리던 삼성맨이 되었다.
삼성 입사 확정 메일을 열었을 때의 기분, 지금도 잊을 수가 없었다. 무언가 해냈다는 느낌, 그렇게도 바라던 꿈을 이루었다는 일종의 성취감, 그리고 가족들의 축하 등 잊을 수 없었던 순간이였다.
삼성의 초반 교육은 무척 빡셌다. 입사 4주전부터 SDS인의 소양(개발능력)을 키우가 위한 교육이 진행 되고, 입사 후 4주간은 그룹 교육을 타 그룹사원들과 받는다. 이후에 2주간 다시 SDS 입문 교육을 받았다. 교육 내용을 자세히 얘기하는 건, 예의가 아닌 듯 해서 skip 하겠음.. 대신, 입사 4주전부터 받았던 교육에서 만났던 반 동기들은 지금도 매년 송년회를 할 정도로 친하게 지내고 있고, 더할 나위 없는 인생의 동반자 들이다. 같은 회사에 있건 없건..
교육이 끝나고 가장 관심이 많은 부분은 바로 부서 배치가 아닐까 싶다. 내가 입사할 당시에는 1~3지망 까지 원하는 부서를 명시하고, 교육 중 받은 평가 점수에 따라, 부서 배치를 받게 되었다. 그 당시에 SI 프로젝트에 투입되는 인력을 수백명 뽑았는데, 가장 빡센 부서라 소문이 돌아서 어떤 여사우는 눈물까지 보이는 상황이 연출되기도..ㅡㅡㅋ 나는 입사할 때 부터 프레임워크에 관심이 많았다. 그냥 맨땅에서 굴러보니 프레임워크에 대한 중요성도 알고 있었고, 훨씬 그 분야가 재미있었다. 해서 현재는 없어졌지만 생산성 혁신 본부의 IT Engineering 센터에 지원하였다. 그 당시에 TO가 3명이였는데, 부서가 자산팀, 프레임워크팀, 방법론팀 크게 3개 여서 한팀에 한명씩 뽑는 걸로 기대하고 지원해서 내부 면접을 보게 되었다.(대부분의 부서는 면접 과정이 없다.)
하지만, 면접 당일날 해당 TO는 방법론팀에게 할당 된 3개의 TO 였다. 나중에 안 사실이지만, 자산팀은 내가 입사하기 전에 인력을 할당 받았고, 정작 가고 싶었던 프레임워크 팀은 추후에 뽑을 예정이였다. 순간 머리속이 하얘졌다. 방법론? 생소했다. 방법론이 먼지, 가면 무슨 일을 하게 될지 전혀 감이 오지 않았다. 하지만, 타 본부로 가는 것 보다는 옆 팀에라도 있으면 나중에 프레임워크쪽으로 갈 수 도 있지 않을까 하는 생각이 들었다. 해서 면접시, 프레임워크 관련된 내용만 준비했던 것에 방법론 관련 내용을 살짝 추가하여 진행했었다.
물론 내용은 엉망이였겠지만, 그 당시 면접관이셨던 3분은 모두 만족해 하는 분위기였고, 특히 군대에서 표창을 받은 내용이 인상 깊었던 모양이였다. 해서 나는 방법론팀으로 조인하게 된다. 이때, TO가 3명이였지만, 면접자중에 뽑을 만한 사람이 많지 않아서, 2명만 뽑았다고 한다. 그리고 나중에 안 사실이지만, 이 센터에는 신입사원을 바로 한 해 전 부터 뽑기 시작했고, 전년도에도 2명만 뽑혔다고 한다. 그 정도로 사원의 비중이 적은 곳이였다. 지금 생각해보면 당연한 듯.. 생산성 혁신을 신입사원들이 어떻게 할 수 있을 까..ㅋ 하지만 허드렛일도 많다보니 필요해 보이기도 했다.
해서 난 방법론의 신입사원이 되었고, 처음으로 맡았던 일은 방법론 기반하에 만들어진 통합개발플랫폼의 형상관리 솔루션 적용 지원 업무를 맡게 되었고, 곧 전체 통합개발플랫폼 확산 관련 업무를 하게 된다. SDS에서의 생활은 다음 포스트에서 이어나가도록 하겠다.
지금 생각해보니, 우여곡절이 많았던 것 같기도 하고, 나름 많이 성장하게 된 계기가 된 듯.. 이런 과정을 통해 얻은 것은.. 본인이 무얼 하고 싶은지 그리고 멀 할 수 있는 지 고민하여 명확하게 해야 한다는 것.. 그리고 솔직함과 본인을 어필 할 수 있는 능력이 꼭 필요하다는 점, 그리고 꿈을 계속 쫓으면 반드시 이루어진다 라는 점.. 등 인듯 하다.
그럼 오늘은 이만..
>_
-- My Story ---------------------------------------
---------------------------------------------------
현대정보기술(HIT)에 입사하여 처음 배정받았던 부서는 해외금융개발팀(명확하지는 않은 듯..)이였다. 중간에 이름이 한번 바뀌었고, 워낙 짧은 기간동안 근무를 해서 부서명은 기억이 잘 나지 않는다. 입사 할 당시 "현대" 그룹이 여러 그룹으로 쪼개지면서, 회사가 많이 어려워졌고, 현대 그룹 소속도 아닌 걸 알고 있었지만, 한때 가장 잘 나가던 규모있는 SI업체 였고, 주변에 입사 지원했던 동기들도 모두 능력이 훌륭했기 때문에, 또한, 베트남에 나갈 수 있다는 기대가 컸었던 걸로 기억 한다.
처음 담당했던 업무는 베트남 농업은행 시스템 유지보수 였다. 우리나라로 따지면, 농협은행과 같다고 보면 된다. 회사에 들어가면 최신 기술들을 써 볼 수 있겠지.. 하는 기대와는 정 다르게, 해당 시스템은 파워빌더6 버전에 그리 유명하지 않은 DB 기반으로 구축되어 있었던 걸로 기억한다. 곧, 차세대에 투입될 예정이라며, 기존 시스템을 조금씩 보고 있었다. 하지만, 솔직히 말하자면, 업무가 너무 없었다. 프로젝트도 국가 기반 사업이라, 국가에 돈이 있어야 되는데, 국제 기금을 빌려서 진행하는 형태라, 언제 시작 할 지도 불투명한 상태였다. 혈기왕성 했던 나는, 열심히 현장에서 굴러 내실을 다지고 싶었으나, 그렇지 못하는 상황에 대해 무척 불안해 했었다. "이래서야 성장 할 수 있을 까?" 이런 질문이 계속 머리속을 맴돌고 있었다. 게다가, 파워빌더라니.. 마음을 붙이기 어려웠다.
그 당시 함께 입사하였던 친구 중 같은 부서에 굉장히 일을 잘 하던 친구가 있었다. 나보다 한 학번 많지만 나이는 같았고, 군대는 방위산업체에서 산업요원으로 근무하면서 해결한 친구였다. 보통, 이런 경력을 가진 친구들은 다른 사람들 삽질하고 있을 때, 실제 필드에서 험하게(?) 구르기 때문에, 대부분 개발에 있어서는 다른 인력보다 무시 못하는 내공이 있기 마련이다. 나와도 무척 얘기가 잘 통했고, 나보다 훨씬 세상 물정에 대하 밝았다.
하루는 나에게 다가와 솔기한 이야기를 전한다.
"SDS에서 신입사원 뽑드라..봤냐?"
삼성맨이 되고 싶었으나, 한번 미끄러져본 경험이 있었고, 그 당시만 해도, 막 졸업한 사람만 뽑던 터라, 나는 대상이 아니라고 생각하고 있었다.
"어차피 나는 대상에 못 들어갈껄? 졸업한지 몇 년 지났는디?"
하지만 역시, 이 친구는 그냥 나에게 해 본 소리가 아니였다.
"너, 올해 전역했자나. 입사 공고 보면, 올해 혹은 내년 졸업 예정자, 아니면 올해 군 전역자던데?"
난 바로 채용공고를 확인 했고, 두말도 없이 입사 지원을 하였다.
지난번에는 삼성전자를 썼다가 떨어졌고, 솔직히 미련도 없었기 때문에, 전문 SI 업체에서 일하고 싶었던 마음을 유지하면서, 삼성SDS 에 입사 지원을 하였다.
SSAT를 잘 통과하고 면접 준비를 하기 위해, 아주 잠시 자발적인 스터디 그룹에 참여 했었다. 하지만, 개발경험도 있고, 회사에 대해 자세히 알고 있었던 나에게, 일반 대졸 예정자 학생들이 진행하던 스터디는 너무나 유치했었다. 물론, 어떤 식으로 면접이 진행 된 다는 것에는 도움이 되었으나, 그 정도는 웹사이트에서도 얻을 수 있는 정보였었던 듯.. 오히려 혼자 조용한 방 안에 앉아서 예상되는 면접 질문들을 유추해보고, 답변하는 모습을 녹화해 놓고 다시 돌려 보면서, 말하는 모습이나 자세, 억양, 눈빛 등을 연습해보고 마음속으로 계속 그려 보는 연습을 하는 것이 오히려 도움이 되지 않을 까 싶다.
면접은 4개 면접으로 진행 되었었다. 인성 면접, 그룹 면접, 영어 면접, PT 면접 이였는데, 순서는 사람들마다 조금씩 달랐던 듯.. 면접 질문들이 모두 기억 나진 않지만.. 인성 면접에서 중요한 건 솔직함 이였던 걸로 기억한다. 그리고 난 이미 직장생활을 하고 있었기 때문에, 직장생활 관련된 질문도 꽤 있었다. 왜 옮기려고 하는지, 하루 일상 생활에 대해서 설명 해보라고 하던지, 군대에서 SW개발병을 했다고 하는데, 그런 업무를 하는 사람이 군대 안에 있으면, 우리 같은 회사가 군대에서 일하기 어렵지 않겠냐 라던지.. 이런 식의 내용이였다. 그룹 면접에서는 주제를 하나 주고, 찬반을 양쪽으로 나눠서 팀을 가른 다음에 집단 토론 하는 형태로 진행 했었다. 정답을 얘기 하기 보다는 어떻게 여러 사람과 대화를 나눠 가는지, 이끌어 가는지 등을 주로 보는 듯.. 가장 중요한 건, 다른 사람의 의견을 경청하고, 답을 할 때 그에 대한 지지 혹은 반대 의견을 개진해 나가면 되었던 듯.. 영어 면접은 꼬리에 꼬리를 이어가는 식의 현지인의 질문, 가령.. 여행을 좋아 하냐, 어디로 가느냐, 거기 가면 머하냐 이런 식으로 물어보면 짧게 답을 했던 듯.. 기억 나는 것 중 하나가.. 서해 뻘에 가서 키조개를 캐는 걸 설명하려다가 낭패를..ㅡㅡㅋ 머 여튼.. 그리고 종이에 질문이 하나 적혀 있었다. 친구가 니 카페트를 더렵혔는데, 어떻게 할거냐.. 머 이런식의 질문에 대해 의견을 얘기 하는 거였다. 나야 머.. I don't care.. 식으로 넘어가면서, 친군데 머 어떻냐고 답을 했었다. 마지막 PT 질문은 지금도 기억이 난다. A, B, C사에 상용 데이터베이스 a, b, c가 있는데, 어떤 시스템을 구축하는 PM이라면 무슨 상용 데이터베이스를 선택하겠느냐 라는 것이였다. a는 오라클, b는 이름은 알려져 있지만 많이 사용하지는 않는 것.. 그리고 c는 SDS자체 솔루션이였던 듯..ㅡㅡㅋ 시스템의 크기가 그리 크기 않았고, 내 생각에는 오라클을 쓰는 것 보다는 그나마 인지도가 있고 상대적으로 저렴한 b 제품을 쓰는 것이 좋겠다.. 닭 잡는 데 소 잡는 칼 쓸 필요가 있겠느냐 라는 식으로 답을 했다.. 면접관들은 별 질문이 없었고, 끄덕 였던 듯..ㅋ
솔직히 면접 준비는 많이 하지 않았지만, 다른 입사지원자들과는 다르게 2년 반 정도의 개발 경력이 있었고, 적당히 화려한(?) 말빨 덕분에 어렵지 않게 통과 하였다. 해서, 2006년 12월, 공식적으로 삼성SDS에 입사하면서, 그렇게도 그리던 삼성맨이 되었다.
삼성 입사 확정 메일을 열었을 때의 기분, 지금도 잊을 수가 없었다. 무언가 해냈다는 느낌, 그렇게도 바라던 꿈을 이루었다는 일종의 성취감, 그리고 가족들의 축하 등 잊을 수 없었던 순간이였다.
삼성의 초반 교육은 무척 빡셌다. 입사 4주전부터 SDS인의 소양(개발능력)을 키우가 위한 교육이 진행 되고, 입사 후 4주간은 그룹 교육을 타 그룹사원들과 받는다. 이후에 2주간 다시 SDS 입문 교육을 받았다. 교육 내용을 자세히 얘기하는 건, 예의가 아닌 듯 해서 skip 하겠음.. 대신, 입사 4주전부터 받았던 교육에서 만났던 반 동기들은 지금도 매년 송년회를 할 정도로 친하게 지내고 있고, 더할 나위 없는 인생의 동반자 들이다. 같은 회사에 있건 없건..
교육이 끝나고 가장 관심이 많은 부분은 바로 부서 배치가 아닐까 싶다. 내가 입사할 당시에는 1~3지망 까지 원하는 부서를 명시하고, 교육 중 받은 평가 점수에 따라, 부서 배치를 받게 되었다. 그 당시에 SI 프로젝트에 투입되는 인력을 수백명 뽑았는데, 가장 빡센 부서라 소문이 돌아서 어떤 여사우는 눈물까지 보이는 상황이 연출되기도..ㅡㅡㅋ 나는 입사할 때 부터 프레임워크에 관심이 많았다. 그냥 맨땅에서 굴러보니 프레임워크에 대한 중요성도 알고 있었고, 훨씬 그 분야가 재미있었다. 해서 현재는 없어졌지만 생산성 혁신 본부의 IT Engineering 센터에 지원하였다. 그 당시에 TO가 3명이였는데, 부서가 자산팀, 프레임워크팀, 방법론팀 크게 3개 여서 한팀에 한명씩 뽑는 걸로 기대하고 지원해서 내부 면접을 보게 되었다.(대부분의 부서는 면접 과정이 없다.)
하지만, 면접 당일날 해당 TO는 방법론팀에게 할당 된 3개의 TO 였다. 나중에 안 사실이지만, 자산팀은 내가 입사하기 전에 인력을 할당 받았고, 정작 가고 싶었던 프레임워크 팀은 추후에 뽑을 예정이였다. 순간 머리속이 하얘졌다. 방법론? 생소했다. 방법론이 먼지, 가면 무슨 일을 하게 될지 전혀 감이 오지 않았다. 하지만, 타 본부로 가는 것 보다는 옆 팀에라도 있으면 나중에 프레임워크쪽으로 갈 수 도 있지 않을까 하는 생각이 들었다. 해서 면접시, 프레임워크 관련된 내용만 준비했던 것에 방법론 관련 내용을 살짝 추가하여 진행했었다.
물론 내용은 엉망이였겠지만, 그 당시 면접관이셨던 3분은 모두 만족해 하는 분위기였고, 특히 군대에서 표창을 받은 내용이 인상 깊었던 모양이였다. 해서 나는 방법론팀으로 조인하게 된다. 이때, TO가 3명이였지만, 면접자중에 뽑을 만한 사람이 많지 않아서, 2명만 뽑았다고 한다. 그리고 나중에 안 사실이지만, 이 센터에는 신입사원을 바로 한 해 전 부터 뽑기 시작했고, 전년도에도 2명만 뽑혔다고 한다. 그 정도로 사원의 비중이 적은 곳이였다. 지금 생각해보면 당연한 듯.. 생산성 혁신을 신입사원들이 어떻게 할 수 있을 까..ㅋ 하지만 허드렛일도 많다보니 필요해 보이기도 했다.
해서 난 방법론의 신입사원이 되었고, 처음으로 맡았던 일은 방법론 기반하에 만들어진 통합개발플랫폼의 형상관리 솔루션 적용 지원 업무를 맡게 되었고, 곧 전체 통합개발플랫폼 확산 관련 업무를 하게 된다. SDS에서의 생활은 다음 포스트에서 이어나가도록 하겠다.
지금 생각해보니, 우여곡절이 많았던 것 같기도 하고, 나름 많이 성장하게 된 계기가 된 듯.. 이런 과정을 통해 얻은 것은.. 본인이 무얼 하고 싶은지 그리고 멀 할 수 있는 지 고민하여 명확하게 해야 한다는 것.. 그리고 솔직함과 본인을 어필 할 수 있는 능력이 꼭 필요하다는 점, 그리고 꿈을 계속 쫓으면 반드시 이루어진다 라는 점.. 등 인듯 하다.
그럼 오늘은 이만..
>_
2014년 12월 21일 일요일
Distributed Algorithms in NoSQL Databases
https://highlyscalable.wordpress.com/2012/09/18/distributed-algorithms-in-nosql-databases/
피드 구독하기:
글
(
Atom
)
