OST(OpenSpaceTechnology) 모임에 참석을 해 본 것은 두 번째가 되는 모임이었습니다.

처음은 스마트플레이스의 제2회 난상토론회였고, 이번이 2번째입니다.

개인적으로 최근에 읽고 있는 기술 서적의 대부분이 애자일 관련 내용이 많아서리 애자일 OST에 참석을 했습니다.

공지에서 게임 분야에서의 애자일 도입에 대한 언급도 있었고, 게임 회사에 재직중인 개발자들이 많은 듯 하였습니다.

현재 몸을 담고 있는 분야가 휴대폰 단말기 개발이라서 인지 동종업계에 계시는 분은 없는 거 같더군요.

현재 업무가 개발 위주로 진행되지는 않기 때문에 개발 관련된 얘기를 할 만한 거리가 많지가 않았습니다.

애자일을 도입하거나, 현재의 개발 환경에 대한 논의들은 귀담아 들을만한 부분이 많았습니다.

참여 하신 분들 중에는 관리자이시거나 관리자의 위치에 올라야 할 위치에 준하는 분들이 많더군요.

애자일 방법론에 관심을 가지시는 관리자 층이 많이 있다는 점이 무척이나 고무적이었습니다. (제가 다니는 회사에는 없지만... )

사실 안타까운 점이 더 많습니다.

좋은 방법론이나 새로운 패러다임들은 내 앞에서 같이 가자고 유혹하는데, 혼자서 이 모든 걸 개발 현장의 적용하기에는 무리가 좀 있네요.

혼자서 전체를 변화 시키기 전에 소금물에 푹 절여진 오이가 되지나 않을까 하는 우려가 커지는 하루입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

오픈 소스를 사용하는 일은 거의 없지만... 올해에는 참석을 해 볼까 합니다.

생각해 보니, 듣고 싶은 꺼리가 없네요. 아쉽게도 패쓰~~~

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

8개월 가까이 나를 괴롭히던 녀석. 사실 아직도 간간히 귀찮게 한다.

어찌됐던 출시는 했으니... 좋다고 해야 하나.

문제가 좀 있는 녀석인데... 잘 살아남기를 빈다.

[더 자세한 정보 보기]

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Part.2 포스트에 계속 이어 가겠습니다.

===========================================================================

이진행 :

프로그래밍을 할 때 예술적인 코딩을 하는 게 아닌 고객의 관점에서 고객이 원하는 코드를 작성할 줄 알아야 합니다.

매번 새로운 언어와 환경에서의 프로젝트를 참여하다 보니 연속적인 경험을 가지지는 못하였지만, 대신 새로운 환경의 프로젝트에 참여하는 일이 어렵지 않게 되었습니다.

하지만 새로운 기술을 프로젝트를 수행하는 과정에서 같은 업무 영역의 일을 하게 되니 현업에 대한 지식이 생기면서 프로젝트를 수행하는게 수월해 짐을 느꼈습니다. ( 편집자 주. 현업 : 프로그래머가 아닌 프로그래머가 만드는 업무 프로그램을 가지고 실 업무를 수행하는 사용자의 맥락으로 사용하고 있습니다. )

그 이후 마케팅의 대해서 관심을 가지고 접하게 되었는데, 마케팅을 공부하면서 프로그래밍에도 큰 도움이 된다는 생각을 가지게 되었습니다.

하이 레벨의 개발자가 굳이 비즈니스에 영역까지 커버하기 보다는 현업과 친하고, 관계를 잘 유지할 수 있는 평범한 수준의 개발자와 기술적인 능력이 뛰어난 개발자가 서로 협업을 강화해가며 서로를 보완해주는게 중요하다고 생각합니다.

개발자도 현업에 대한 관심을 가지는 게 중요하다고 생각합니다.

양수열 :

기존에 기술 개발은 많이 했지만, 그 기술을 가지고 무슨 일을 할 수 있는지에 대한 고민이 부족한 듯 합니다.

해결해야 하는 문제에 대한 인지가 부족하여, 열심히 개발 하고도 고객의 요구에 미달되는 프로그램이 되는 경우가 빈번하게 발생하고 있습니다.

언어에 대한 장벽이 큰 편입니다. 단순히 현재 하고 있는 일 뿐 아니라, opensource 프로젝트등의 참여를 통하여 개인의 역량을 키우는게 중요하다고 생각합니다.

이진행 :

항상 기회가 다가 올 때 기회를 잡을 수 있도록 미리 미리 준비하는게 필요합니다.

커뮤니티 활동이 중요하다고 생각하는데, 책을 읽어서 정보를 얻는 것보다는 지인에게 물어보거나, 커뮤니티의 뉴스레터나 게시물들을 통해서 훨씬 빠르게 정보를 얻을 수 있습니다.

커뮤니티의 적극적인 참여를 통하여 Trend대한 인지 및 성장하고자 하는 방향에 대한 도움을 얻을 수 있다고 생각합니다.

Matt Thompson :

인터넷의 언어는 영어라고 할 수 있습니다. 또한 computer science의 언어 역시 영어입니다.

그래서 영어에 대한 스킬이 상당히 중요합니다.

베트남의 경우 대학에서 수학 및 과학에 경우 영어로 강의를 합니다.

개발자로서 역량을 키우키 위해서는 언어에 대한 투자가 필요합니다. 중국어 역시 영어만큼 중요한 언어가 될 거라고 생각합니다.

커뮤니티는 강력한 학습의 도구로 활용 될 수 있다고 생각합니다. 커뮤니티를 통하여 기술지식과 업계지식을 동시에 획득하는 것이 가능합니다.

open source 프로젝트의 참여하는 것 역시 중요합니다. close source의 경우 배우기가 무척 어렵습니다.

하지만 open source를 통해서 다른 사람의 코드를 보고 빌드하고, 변경을 하는 과정에서 많은 것을 배울 수 있습니다.

리더가 되기 위해서는 끊임없이 배우고 공부를 해야합니다. 배우는 것을 멈추면 리더가 될 수가 없습니다.

커리어를 위해서 충분한 시간을 투자하세요.

방청 패널 질문 - 김창준 :

1. 개발자가 개인적으로 성장을 위해서 할 수 있는 방법은 무엇이 있나요? 그리고 빠르게 성장해 나가는 사람들의 특징은 무엇인가요?

Matt Thompson :

빠르게 성장하는 사람은 크게 2가지의 특징이 있다고 생각합니다.

첫째로, 끊임없는 호기심을 가지는 게 중요합니다. 저는 4년 동안 4차레의 승진을 해 왔습니다.

저는 업무를 지시 받으면, 매니저에게 왜 그 일을 그렇게 해야하는지 묻고는 했습니다.

그리고 2가지 이상의 다른 솔루션을 제시하고는 했습니다.

저의 상사들은 저를 별로 좋아하지 않았을 것이지만, 개발자에게 있어 호기심은 중요하다고 생각합니다.

둘째로, 내부적인 사이클이 남보다 빨리 돌아야 합니다. 즉 남보다 빠르게 일을 해야한다는 것입니다.

저의 누나의 경우 지금 의사이신데, 어린시절부터 같은 공부를 하더라도 저의 누나는 한번만 읽으면 보면 바로 이해하던 공부도 저는 3~4번을 보아야 이해를 하곤 했습니다.

그 걸 보면서 각 개인의 이해나 사고의 능력의 차이가 있다고 생각합니다.

물론 기본적으로 타고난 이해도가 빠르면 좋겠지만, 그러한 능력을 타고 나지 못했다고 해서 포기하지말고 끊임없이 노력하여 개발 속도 및 내부 사이클을 항샹 시키는 게 중요합니다.

시간을 만들어서 활용하는 게 필요하다고 생각합니다.

누군가 롤 모델이 될만한 사람을 목표로 삼고 끊임없이 노력하십시오.

(편집자 주.  이후 토론 마무리 발언이 간략하게 이루어 지고 토론이 종료 되었습니다.)
===========================================================================

토론을 들으면서 많은 생각과 공감을 하게 되었습니다.

그럼에도 불구하고 토론 참석 후 이 주 정도 지금 생각해보면 별로 실천을 하고 있는 게 없다는 생각이 듭니다.

지속적으로 성장을 해 나간다는게, 쉽지만은 않은 듯 합니다.

하지만 성장하지 않고 멈추어 있으면 언제가는 자연스럽게 이 직업을 그만 두게 될 것입니다.

그러한 시점에서 환경을 탓하고 남을 원망하지 않기 위해서 적극적인 노력이 필요한 시점입니다.

모두들 힘내서 성장을 멈추지 않으셨으면 합니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Part.1 포스트에 계속 이어 가겠습니다.

===========================================================================

방청 패널 질문 1 :

한국 고유의 Domain의 대해서 언급 하셨는데, 기존의 유행하던 CRM의 경우 현재 거의 활용이 되지 않고 있는데, 한국 상황의 적용하기 어려워 폐기된 Domain을 재활용 하는 것에 대해서 어떻게 생각 하십니까? ( 편집자. 주 - 이 부분은 정확한 질문의 요지를 전달을 못 한거 같습니다. )

양수열 :

일종의 양날의 칼이 되지 않을까요? 글로벌 솔루션이 한국에서 실패의 원인이.. , 한국적인 모델이 오히려 글로벌한 모델의 장애가 될 수 있다고 봅니다. ( 편집자. 주 - 정확하지 않습니다. )

이진행 :

trend + industry knowledge + domain 지식

사용하지 않는 domain은 퇴출퇴기 시작한 부분이라고 보면 된다고 생각합니다.

방청 패널 질문 2 :

현재 12년차의 개발자이며 PM 업무를 맡고 있습니다.

PM으로서 후배 개발자들을 어떻게 성장시켜야 하는지에 대한 고민이 많습니다.

1. 첫번째 질문입니다. 현재 근무하는 회사에서 회사 차원에서 개발자의 커리어 패스에 대한 지원을 하기 시작했지만 개발자의 역할을 평가하는 방법에 대해서 알고 있습니다. 현재는 경력/년차를 기준으로 직급을 산정합니다.

2. SI 업무를 하고 있는데, 계약을 하는 과정에 갑의 경우 developer 등급의 개발자의 경우 고객이 인건비가 비싸기 때문에 인력 투입을 꺼려하는 경향이 있습니다. 이런 경우에는 어떻게 해야 하나요?

Matt Thompson :

1. sun은 직무에 대한 등급 산정에서 근속년수, 년차, 경력은 개발자 등급 평가에서 제외 했습니다.

이제 갖 학교를 졸업한 개발자라 할지라도 많은 경력을 가지고 있는 개발자보다 개발 능력에 있어서는 뛰어 날 수 있기 때문에, 단순한 근속년수와 경력으로 승진을 시키지는 않습니다.

개발자의 승진 가능성을 결정하기 위해서 다음의 6가지의 기준을 가지고 있습니다.

mentoring, 고객 관리, 의사 소통, 팀워크, 기술 능력, XXX ( 편집자 주. 마지막 하나의 능력은 정확히 듣지를 못하였습니다. )

기술 능력의 경우 현재 직급의 업무뿐 아니라 다음 단계의 직급의 업무를 현재 수행할 수 있는 능력을 가지고 있어야 진급 대상이 됩니다.

그리고 위의 6가지 요소 중 하나라도 부족한 경우에는 진급을 하기에 무척 어렵습니다.

그리고 진급 대상이 된 직원은 현재 자신의 매니저 뿐 아니라 여러 매니저들의 공통적인 평가에도 통과가 되어야 상위 직급으로 승진이 가능합니다.

2. 기본적으로 고객의 예산이 부족하다면, 달리 해결 방법은 없습니다.

SUN이 수행하는 컨설팅 업무의 경우 참여하는 개발자의 근속년수를 기준으로 프로젝트 수주비용을 계산하지 않고, 프로젝트의 복잡도를 기준으로 산정을 합니다.

방청 패널 질문 3 :

S/W 개발에 있어서 현재의 SI 및 여러 개발에서 흔한 하도급 체계의 문제가 심각합니다. 한국에서는 하도급 체계하에서 개발자의 생계 자체가 위협 받는 경우가 많은데, 미국의 경우는 이런 문제가 있었는지 궁금합니다?

Matt Thompson :

미국의 경우 기회의 차이가 있다고 생각합니다.

미국에서는 startUp(벤쳐) 기업을 시작할 수 있는 여건이 상대적으로 많다고 생각합니다.

저 역시 여러개의 아이디어를 가지고 있고, 언제라도 startUp 기업을 시작할 수 있습니다.

양수열 :

회사에서 부당한 대우를 받을 경우, 그에 대항할 수 있는 무기 개발(아이디어)이 필요합니다.

자기 아이디어에 대한 형상화가 필요합니다.

개발자의 경력에 관한 이야기 있습니다.

1년짜리 경험을 3번한 개발자와 1년, 2년, 3년 동안 경험을 누적해 온 개발자는 차이가 납니다.

경력의 년차보다는 그 사람의 경력이 어떠한 퀄리티의 경험으로 채워져 왔는지가 더 중요한 평가 기준이 되어야 한다고 생각합니다.

업무에서 외부에서 고용된 컨설턴트가 도움을 줄 수 있지만, 해당 업무의 정통한 엔지니어라야 해결이 가능한 영역이 분명히 존재합니다.

그러한 관점에서 해당 업무의 정통한 엔지니에가 된다면 부당한 상황에 대응의 폭이 넓어질꺼라 생각합니다.

개발자의 경우 컨퍼런스에서 기술적인 부분에만 관심을 가지지 말고, 개발 경력 관리라는 측면에서의 접근도 필요하다고 생각합니다.

- To be Continue.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

이 글은 2007년 2월 24일 coex에서 개최된 제 8회 한국 자바 개발자 컨퍼런스의 토론 트랙에서 참관하여 들었던 토론된 내용을 요약 정리한 부분입니다.

개인적으로 현재 자바 개발자는 아니지만, 개발자라는 입장에서 많은 자극이 되었던 컨퍼런스이고, 차후에도 지속적인 참여할 필요성을 많이 느꼈습니다.

/*
그날 토론 내용을 기록한 내용을 기반으로 재구성 하였으면, 최대한 개인적인 의견이 반영되지 않도록 노력하였지만, 토론 패널들의 의견이 왜곡된 부분도 있을 수 있음을 알려 드립니다.

토론 내용을 하나의 포스트로 정리하기에 너무 길어서 포스트를 분리 하였습니다.
*/

주제: 개발자 어떻게 성장해 나갈 것인가?

1. 개발자 성장맵을 어떻게 구성할 것인가?
2. 개발자의 성장 단계별 필요한 능력은 무엇인가?
3. 커뮤니티 활동 등을 통한 개발자의 능력 신장 및 경력 관리

토론에 참여하시는 패널:

 + Matt Thompson (Sr. Director, Developer Outreach& Open Source Programs Office, 썬마이크로시스템)
 + 이진행(SAS Korea)
 + 양수열(한국 자바 챔피언, 전 JCO 회장)

===========================================================================

개발자의 성장맵을 이해하기 위해서 간략한 개발자의 성장 단계에 대한 정의가 필요하다고 생각하여 우선 각 패널 별로 개발자의 성장 단계에 대해서 정의하도록 하겠습니다.

이진행 :

일반적으로 한국에서는 빨간색으로 표시된 직군을 통들어 개발자라고 정의 할 수 있습니다.

각 직군별 역할에 대해서 간단히 설명 하겠습니다.

coder : 주어진 부분에 관련된 코드만 짜는 역할, 초보 개발자

programmer : 아키텍트, code 설계를 하는 역할

developer : 한국에서는 consultant가 수행하는 역할이라고 생각함. - 개발자와 협업

consultant : 비즈니스 전략을 수립하는 역할, 시장 생성자.

양수열 :

이진행 씨가 언급한 직급에서 추가적으로 modeler와 architect 두 개의 직급을 추가하고자 합니다. 수정된 직급 표는 다음과 같아 지겠죠.

coder / programmer / developer / modeler / architect / consultant / manager

modeler : 아키텍처의 철학을 구현하여 모델로 생성하는 역할

architect : 프로젝트의 전체 그림을 그리는 사람, 프로젝트의 철학을 정의하는 사람

각 직급이 완전히 수직화된 계층 구조라기보다는 역할에 따른 분류라고 생각합니다.

개발자가 성장하는 과정에서 manager가 될지 architect가 될 지 분화되는 것 같습니다. 현실적으로 대부분은 PM의 역할을 강요 받고 있습니다.

성장을 위한 전제로 환경이 무척 중요하다고 생각합니다.

개발자가 성장을 위해서는 단순히 개발자의 노력뿐 아니라 사회적인 환경의 조성이 필요합니다.

좋은 환경을 구축하기 위해서 개발자들의 고민이 따라야 한다고 생각합니다.

한국의 경우 SI를 하는 회사는 많지만 S/W Solution을 개발하는 회사가 적은 것도 이유가 될 수 있을 듯 합니다.

Matt Thompson

여러 유명한 개발자들을 예로 들어 보겠습니다.

제임스 고슬링(James Gosling)씨의 경우, 현재 Sun에서 여러 직무를 수행하고 계시지만, 코딩을 계속하시고 무척 좋아하십니다.

앤디 허츠필드(Andy Hertzfeld) 씨의 경우 학생 시절부터 코딩을 하였고, 유능한 개발자였으며, 회사를 설립하여 CEO가 되시기도 한 광범위한 경험의 소유자입니다.

이 두 분처럼 developer가 되려면 계속 노력하고, 공부하고 코딩을 계속하셔야 합니다.

Sun의 경우도 PM 혹은 개발자로 가는 커리어 패스가 있습니다.

최근 인도나 중국 등의 저가의 인력을 고용할 수 있는 지역으로 코더의 아웃소싱을 많이 하고 있습니다.

초급의 코더의 경우 저렴하게 아웃소싱이 가능하지만, 프로그래머, 디벨로퍼는 아웃소싱으로 해결하기에는 불가능합니다.

따라서 이런 인재들은 회사에서 양성을 해야지 아웃소싱을 통하여 획득할 수는 없습니다.

양수열 :

새로운 시스템을 만들어 가야 합니다. 글로벌 한 추세가 아웃소싱을 하는 방향으로 흘러가고 있습니다.

한국인이기 때문에 한국에서 사용하는 시스템에 대해 이해하고 구현하는 것은 아웃소싱보다도 유리합니다.

상대적으로 개발자 중에 자기만의 고유한 Domain을 가지는 엔지니어가 부족한 편입니다.
특정 Domain에 대한 솔루션은 깊은 지식이 필요한 영역이며, 아웃소싱으로는 해결할 수 없는 분야이기도 합니다.

또한 개발자 및 회사에서 개발자의 career path의 중요성에 대한 인식이 많이 부족한 현실입니다.

방청 패널 의견 - 김창준 :

company의 법칙 : 우리가 만든 결과물과 우리의 조직 사이에는 유사성이 존재한다.

우리의 성장은 우리가 소프트웨어를 어떤 방법으로 개발하는 방법 역시 중요합니다. 따라서 소프트웨어를 개발하는 방법 자체의 변화가 필요합니다.

개발자의 Role 모델 역시 필요합니다.

외국의 경우 훌륭한 개발자들의 role 모델이 존재하지만 한국에는 아직까지는 role 모델이 존재하지 않는 것 같습니다.

- To be Continue.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

알고리즘 트레이닝 북이라는 제목의 Programming Challenge에 있는 문제를 코딩 해 보았습니다.

책을 산지 2년이 다 돼어가지만 계속 미루다 드디어 한 문제를 풀었습니다.

문제 내용 : http://acm.uva.es/p/v1/100.html

간만에 하는 코딩이라서 좀 어렵기는 했는데, 문제 자체가 알고리즘을 따로 고민 하지 않아도 되는 난이도가 낮은 문제라서 끝을 보기는 했습니다.

하지만 이런 저런 변수와 경우를 따지다 보니까 코드가 복잡해졌네요.

뭔가 열심히 처리 했음에도 불구하고 상당부분 예외 처리가 안되어 있습니다.

정작 채점을 받기 위해서 제출은 했는데, fopen 함수 쓴다고 restricted function 처리를 받았네요. 휴. 나름 열심히 해도 문제가 발생하네요.

하지만 간만에 코딩다운 코딩을 하였기에 기분은 그닥 나쁘지 않군요. ^^

ps. 다른 분들이 문제를 해결한 걸 보았는데, 제 코드는 그냥 발로 짠 기분이 드는군요 --;;

코드 보기

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

프로그래머이며 현재 휴대폰을 개발하는 개발자로서, 개발하는 프로그램에 요구사항이 불분명하다는 것은 심각한 문제를 발생시키는 것 같다.

정확히 얘기하면 요구사항이 불분명 하다기 보다는 그 요구사항을 체계적으로 정리를 해 놓고, 그 요구사항을 구현하고 있지 않다고 얘기함이 옳다.

그래서 기능을 구현할 때 막연히 기존에 작성한 레거시 코드와 프로그램을 보고서 기능을 구현하고 있다.

이러한 불분명한 요구 사항 때문에 유사한 기능을 여러번 구현 하는 경우도 발생하고, 일정에 맞추기 위해서 If-else로 도배를 한 코드가 기하 급수적으로 늘어나게 마련이다.

핸드폰의 특성상 출시 기일을 맞추기 위해서 기존에 작성된 코드의 대부분을 그대로 사용하는 현실에서 새로운 기능이 추가될 때 마다 기존의 코드에 대한 고려 없이 무조건 if-else 문으로 추가를 하게 된다.

결국은 갈수록 유지보수와 기능 추가를 하기 힘든 코드가 증가하게  마련이다.

결국은 눈 앞에 편함을 추구하다가 더 큰 어려움에 직면하게 마련이다.

오랜 기간 반복되는 일임에도 불구하고 여전히 개선이 되기에는 멀다고 생각이 든다.

결국은 예전에 삽질을 하던 방식이 익숙하다고 해서 포크레인을 두고 삽질을 계속 하는 것이라고 생각한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

최근 들어 회사에 변화가 있다.

2명의 선임 개발자가 회사를 그만 두기로 결정 하였다.

한 명은 이미 이직을 하였고 다른 한 명은 퇴사를 위해서 인수인계를 하고 있는 중이다.

세상일이 그렇듯이 누군가가 새로 입사를 하는 만큼 누군가는 다른 환경을 찾아서 이직을 하는 것은 자연스러운 현상이라고 생각한다.

사실 나 역시 매일 회사를 그만 두고자 하는 마음이 들기에  그들의 모습에서 부러움을 느끼게 마련이다.

퇴사를 하는 동료와퇴사를 진행하는 회사의 태도를 보면서 여러 문제점을 알게 되었다.

원론적으로 얘기하자면 직원들이 부득이한 경우를 제외하고는 퇴사를 하지 않는 환경을 만드는 게 좋다고 생각한다.

그러한 환경이 되지 못한다면 최소한 퇴사자의 뒷통수를 치지는 말았으면 좋겠다.

사실 회사에 입장에서는 단지 퇴사자에게 괘씸죄가 크겠지만, 그 사람들에게 했던 일들을 남은 직원들이 모두 지켜보고 있다는 사실에 대해서는 무감한 듯 하다.

퇴사가 진행되는 과정에서 여러가지 상식 이하의 모습을 많이 보았다.

나 역시 퇴사를 하게 될 때 발생할 상황에 대해서 명백히 이해 할 수 있었다.

피해를 최소화하기 위해서 나도 내가 편한 시기에 퇴사를 할 것이고, 그만큼 회사는 더 큰 타격을 받을 것이다.

회사가 단지 눈 앞에 이익을 위해서 장기적으로 너무 많은 걸 잃고 있다고 생각한다.

회사에 경영자들이 너무 기본적이라서 중요한 사실을 놓치고 있는 거 같다.

그 무엇보다도 사람이 중요하다는 사실을 말이다.

그것도 사람 말고는 아무것도 가지고 있지 않는 IT기업이 말이다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.