여러분들에게 드리고 싶은 이야기
관리자
2018-11-05 11:36
조회 229

이력서는 자신의 경험과 능력을 문서로 표현한 글입니다. 

자신이 원하는 회사와 나를 이어주는 첫 번째 매개체라고 볼 수 있습니다. 


그렇기 때문에 이력서를 완벽히 작성하는 것은 매우 중요합니다. 

완벽한 이력서란 어떤 이력서를 말할까요? 

이력서는 두 가지 관점을 모두 충족시켜야 합니다. 


첫 번째 관점, 깔끔한 양식으로 잘 정리되어 있는가 

두 번째 관점, 자신의 경험과 능력이 잘 어필되어 있는가


이 두 가지 관점에서 본인의 이력서는 어떠한 수준인지 생각해 보시기 바랍니다. 

각 상황에 따라 필요한 조치와 비용을 아래 표로 정리하였습니다. 

깔끔한 양식으로 잘 정리되어 있는가.  
(Layout / Look&Feel / Design)
자신의 경험과 능력이 잘 어필되어 있는가 필요한 조치비용
아니다
그렇다
스태머스에 이력서 등록
무료
 그렇다그렇다스태머스에 이력서 등록 후 검증무료
그렇다
아니다이력서 컨설팅 필요유료
아니다
아니다
스태머스에 이력서 등록 후 컨설팅 필요유료



이력서를 보내주시면 3가지 종류의 이력서 양식으로 전환해서 여러분께 파일을 보내드립니다. 





관리자
2018-10-31 14:42
조회 205

이력서 등록 방법을 안내해 드리겠습니다. 

여러분이 가지고 계신 파일의 종류에 관계 없이 모든 파일을 등록하실 수 있습니다. 



첫 번째 방법, 구글 설문지 양식을 통해 업로드

STEMers 홈페이지 내에 "이력서 신청" 이라는 버튼을 누르시면 구글 설문지 양식으로 이동합니다. 

간단한 정보 기입 후 이력서 파일을 업로드 해주시면 됩니다. 



두 번째 방법, 이메일 발송

메일 발송이 편한 분들께서는 stemers@ebrain.kr 이메일 주소로 이력서 파일을 보내주시면 됩니다. 

제목은 'STEMers 이력서 서비스 신청' 이라고 해주시고 메일 내용은 적지 않으셔도 상관 없습니다. 



혹시 이력서 등록 방법에 대해 궁금하신 점이 있다면 

1. 02-6933-5070 으로 전화주시면 됩니다. (월~금, 10시~18시)

2. STEMers 홈페이지 내 '자유게시판'을 통해 문의해주시면 됩니다. 

감사합니다.

 


관리자
2019-02-22 17:33
조회 97

출처 : 신현묵 개발자님의 브런치 

원문 링크 : https://brunch.co.kr/@supims/1


이직’이라는 화두는 샐러리맨에게는 매우 무섭게 다가온다. 평생직장이라는 의미가 사라진 현대 시대에 있어서 직장생활 중에 많이 만나게 되는 단어이다. 더군다나, 소프트웨어 개발자들에게는 매우 일상적으로 발생한다. 그러니, 이직을 너무  두려워하지 말자. 오히려 평소에 이직에 필요한 스킬과 준비를 매우 당연하게 해야 한다.


개인적으로 소프트웨어 관련 학과에서는 '이직'과 관련된 커리큘럼을 하나 만들어 두거나. 아니면, 교양과목이라도 있어야 하나 가르쳐야 한다고 생각한다.


필자도 여러 기업에 입사하고 이직을 고민하는 과정을 똑같이 경험했다. 더 큰 경험으로는 기업을 창업하고 직원을 채용하고, 퇴사하는 과정도 같이 경험했다. 돌이켜 생각해 보면 직원의 입장과 중간관리자의 입장, 경영진과 최고 경영진의 입장에서의 ‘이직’을 바라보는 관점이 정말 매우 다르다.


이번 이야기에서는 이런 ‘이직’의 관점을 ‘소프트웨어 개발자’의 입장에서  이야기해보자.


이직이란 단어는 언제 만나게 될까? 이직이라는 단어를 머릿속에 떠올리게 되면서 당연하게 고민할 것이다. 더 좋은 조건을 제시하는 회사로 자리를 옮기거나, 또는. 현재 있는 직장에서 하는 일이 마음에 들지 않거나, 특정한 사람이나 환경 때문에도 이직이라는 단어는 언제나 떠올릴 수 있다.


소프트웨어 개발자들이 이직을 고민하고  생각할 때에 어떤 부분들을 고민하고 생각해야 하는지 알아보자. 물론, 이번 이야가의 내용은 전적으로 필자의 주관적인 경험을 바탕으로 만들어진 내용들이기 때문에 매우 주관적이라는 것을 먼저 이야기해야겠다.


다만, 작지 않은 경험을 적은 기업의 신입직원이었을 때부터, 벤처기업의 CEO, 중견기업의 CIO의 역할을 해보고 느낀 점 들을 몇 가지 정리하여 본 것이다.


 글을 읽는 독자들은 ‘이직 고민하는가?

혹은 이직이라는 단어에 대해서 어떻게 생각하는가?


일단, 직장은 너무 쉽게 바꾸거나, 특정한 이유에 너무 집착하여, 너무 쉽게 결정하지 않기를 바란다. 일반적으로 한 회사에서 정년퇴직한다는 전설을 만난다는 것은 이제 거의 불가능에 가깝다. ( 필자역시, 딱 한사람 만났다. )


소프트웨어 개발자들은 한 회사에 오래 근무할 수 있는 여건이 되는 사람들은 매우 극소수에 해당된다고 생각해야 한다. 대부분은 프로젝트가 종료되거나 의미가 없어지면서 이직에 대해서 고민을 시작 하게 된다. 


너무도 자주 만나게 되는 이 단어에 대해서 사람들마다 각자의 의미와 나름대로의 기준점을 잡아두는 것이 매우 좋다고 설명하겠다. 각자 자신이 걸어가야 할 로드맵이나 기본적인 원칙을 한, 두 가지쯤은 정해 두는 것이 좋다. 이 기준은 정말, 개인적인 기준들이다. 이 기준을 각자 가져야 한다.


필자의 경우에는 초보때에 세웠던 원칙이 몇 가지 있었고, 나름 경험이 많아지면서  이러한 원칙들은 조금씩 그 기준을  추가하게 된다. 필자의 사례를 들어보자


필자는 가장 먼저 사회생활 초년병의 시작을 병역특례로 시작하였다. 그래도. 나름 기준은 있었다. 그것은 앞으로 소프트웨어 개발일을 계속하기 위해서 내가 어떤 기준으로 회사를 찾아야 하는가에 대한 것이었다. 내가 세운 대원칙은 딱 하나였다. 하드웨어 작업을 병행하는 일을 한다는 것을 원칙으로 했다.


그래서, 선택한 기업에서 처음 내게 할당된 일은 Z80으로 음성보드를 만들고, 적외선 센서로 터치스크린을 만드는 파트에서 Z80과 i8051의 크로스 어셈블리로 프로그래밍하는 일이었다. 내가 세운 큰 대원칙에는 맞는 일이었고, 일 자체에 대해서도 매우 큰 매력을 가졌다.


하지만, 그 업체에서 병역특례 일을 하다가 부당한 노동현장(?)의 부조리를 맞이 하게 되면서 회사를 그만두게 됐다. 그 당시 얻은 경험 중의 하나는 ‘부조리한 노동현장’은 빨리 떠나라는 개인적인 원칙도 세웠다. 그 기준은 나중에 기업을 운영하면서도 가장 부끄러워할 경영진의 몫이라는 것을 인지하게 된 것도 가장 큰 경험이었다고 하겠다. ( 이런 경험은 차라리 초보나 신입 때에 경험하는 것이 그나마 불행 중 다행이며, 사회의 쓴맛을 제대로 보았다고 하겠다. 무료 법률상 담도 해보았고, 노무담당 문의도 해봤다. )


그 후에 경력직 프로그래머로써 제대로 된 취업을 할 때에도 나름대로 원칙을 세웠다.


병역특례 일을 하다가 그만두고 군대를 다녀왔을 당시에는 윈도우즈 애플리케이션의 개발이 매우 어렵던 시절이었기 때문에 나름 몸값을 요구할 수 있었다. 그래서, 프로그래밍을 하는 데 있어서 조금은 특이한 솔루션을 활용하는 경험을 하고 싶었고 그것을 중요한 원칙으로 삼았다.


당시에 선택할 수 있는 기업은 3곳이었다. 하나는 용산 근처의 게임 개발사. 건대 부근의 한국전력에 소프트웨어를 개발해서 판매하던 회사, 그리고. 하나는 건축 소프트웨어 개발을 하는데 Auto-Cad의 ARX아키텍처 기반의 프로그래밍과 윈도즈 개발을 하는 일이었다.


3군데의 회사에 면접이 다 통과된 이후에 고민하였다. 가장 적극적이었던 회사는 게임회사였다. 지금 기억으로도 90년대 중반에 팔레트 애니메이션을 능숙하게 조작하는 내 스킬을 보고 매우 탐을 내었던 게임업체의 사장이 기억난다. 그 먼 거리에서 인천의 집까지 나를 태워다 주면서, 같이 일하자고 차를 타고 오는 도중에 많은 이야기를 나누면서, 같이 일하자고 설득했다.


하지만, 결정적으로 그 당시에 결혼을 한 필자의 입장에서는 ‘급여’가 가장 큰 걸림돌이었다. 전혀 엉뚱하게도 ‘급여’를 가장 많이 준다는 ‘회사’를 선택했다. 바로, 건축 소프트웨어 개발회사였다. ( 당연하지만, ‘급여’는 언제나 샐러리맨에게는 최고의 선택 기준이 될 것이다. )


아마도, 필자가 그 당시에 급여는 매우 적지만, 그 게임업체에 들어갔다면 운명이 매우 많이 바뀌었을 것으로 생각한다. 당시, 병역특례를 하다가 군대를 다녀오면서 네트워크 프로그래밍에 대한 스킬까지 겸비한 필자가 게임업계로 들어갔으면 나름 재미있는 미래가  진행되지 않았을까 한다.


하지만, 그래도 그 당시에 급여도 나름 가장 많았지만. 최고의 선택 기준은 ‘독특한 기술’에 대한 호기심이었다. 더군다나, 윈도즈 개발자로서 나름 이름을 알리기 시작하던 시기였기 때문에 필자의 선택은 옳았다고 생각한다.


이때 중요한 화두는 ‘급여’와 ‘윈도즈 개발환경’, ‘독특한 콘셉트’이었다. 당시, 그 회사는 AutoCad에서 동작되는 한글 소프트웨어와 설계용 지원 유틸리티를 개발하는 업체였기 때문에, 선배 개발자들과의 경험이 매우 좋았다. 선배 개발자와 개발실장으로 계시는 분들이 20대 중반이었던 필자를 매우 아껴주었던 기억이 난다.

최소한 그 계통에서 5년 이상 일을 했던 선배들이 몇 분 계셨고,  그분들에게 생각보다 많은 것을 얻을 수 있었다. 정말, 훌륭한 선배들은 언제나 초보와 신입들에게는 큰 도움이 된다.


필자가 신입시절에 크게 결정한 것은 ‘장래성’도 아니고, 오히려 찾은 것은 ‘독특한 개발’을 경험할 수 있는 환경을 찾았고. 그것은 또 하나, 새로운 개발환경을 초기서부터 세팅하는 것도 포함되어 있었다.


‘개발자가 이직을 결정해야 할 때’는 언제 인가하고 후배들이 가끔 질문을 해오거나 자문을 구해올 때가 있다. 그렇다면, 소프트웨어 개발자가 이직을 생각하는 때에 대해서 어떤 것을 고민해야 하고, 이직을 결정하기 위하여 중요한 사항은 어떤 것이 있을까?


물론, 이직은 모든 분야에서 공통적으로 발생하는 요소이기 때문에 전부를 이야기할 수 없겠지만, 가장 좋은 이직이란 무엇인지 필자의 경험을 중심으로 이야기해보자. 다음에 나열하는 요소들은 ‘이직’을 고민하게 될 가장 큰 가능성을 가지고 있다.


첫째자신의 전문성에 대해서 고민하기 시작할 ...


보통은 자기계발에 충실한 사람의 경우에 자신이 제대로 된 전문성을 확보하고 있는지에 대해서 의문점이 생기는 시점에 '이직'을 고민하게 된다. 이 일을  계속하는 것이 미래에 ‘전문성’을 가질 수 있느냐에 대해서 의문을 가지기 시작할  때부터이다.


둘째조직원들 간에 트러블이 발생하거나말도  되는 상사의 권위에 질렸을 


이 부분은 일반 직장과 동일하다. 아무리 전문성이 보장되고, 일이 괜찮다고 하더라도. 동료들과의 문제가 발생되는 부분은 어느 직종이나 동일하다.


필자는 소프트웨어 개발일을 하면서도 벤처기업의 경영진 역할과, 중견병원그룹의 CIO생활을 하면서 다양한 직종의 사람들과 일을 해보고 인사권을 가지고 있었지만. 모두 동일하게 문제가 발생하는 것은 ‘직원들’ 간의 문제나, 중간 관리자의 전횡 등이 가장 큰 이유가 되었다.


셋째프로젝트가 종료되었을 때에


생각보다 하나의 프로젝트가 종료되면서, 소프트웨어 품질이나 개발에 대한 연속성이 제대로 이어지지 않는 경우에는 이직을 생각하게 된다.


재미있고 즐거운 개발을 필자가 주창하는 이유 중의 하나가 이러한 ‘프로젝트 종료’ 시의 이직에 대한 고민을 하지 않기 위해서이다. 하지만, 대부분의 프로젝트들은 실패하거나 어려움을 겪는 경우가 다반사이기 때문에, 프로젝트가 종료될 때에 이런 충동을 느끼게 된다.


이상 3가지의 기본적인 이슈들은 직장생활을 하면서 매번 만나게 되는 고민이고. 3가지의 고민이 모두 발생한다면, 당연하게 ‘이직’을 오히려 권해야 할 사항이 될 것이다.


자, 이직에 대해서 고민하고, ‘이직’을 결정하였다면, ‘미련’없이 ‘이직’을 준비하자.


‘이직’을 준비하는 것에 있어서 가장 중요한 것은 옮겨갈 회사를 잘 고르는 것이 가장 큰 것이다. 그리고. 퇴사를 하는 회사의 경우에는 최소한 1개월 정도의 업무 인수인계 작업은 당연하게 고려하자. 물론, 제대로 된 체계가 있는 회사는 당연하지만, 직원들의 이직 프로세스가 잘 잡혀있기 때문에 너무 걱정할 필요 없다.


대부분의 조직은 누구  사람이 나간다고 하더라도, 그 프로젝트가 잘못되는 경우는 거의 없다. 그냥, 본인의 마음이 떠난다면 ‘이직’을 진행하는 것이 맞을 것이다.


너무 걱정하지 말고 이직을 결심하고 진행하라고 조언하고 싶다.


다만, 필자는 ‘이직 시에 적합한 회사’를 찾기보다는, ‘이직 시에 안 좋은 회사’를 피하는 방법을 먼저 터득하라고 조언하고 싶다.


이직 시에  좋은 회사를 피하는 방법


개발자들이 이직을 고려하고, 이직을 결심하게 되었을 때에는 신입의 입장과는 매우 다르다. 어느 정도 경력도 생겼고, 일에 대한 경험도 풍부해지고, 나이도 한두 살 더 먹었으며, 사람들과의 스킨십이나 커뮤니케이션 능력도 좋아지기 시작하는 시기가 된다.


또한, 과거에는 ‘취업’과 ‘작은 목표’가 중요하였지만, 이제는 같이 일할 동료들에 대해서도 생각하게 되고, 일하는 회사의 비전이나 다른 부분들도 같이 고님할 것이다. 이런 어느 정도의 경험과 시야가 생겼을 때에 ‘이직 시에 좋지 않은 회사’를 골라내는 방법은 어떤 것들이 있을까?


필자의 경험으로는  다음의 사항들을 고려하여 ‘이직’하려는 회사들을 평가했다.


하나고급 개발자가 있는가?


회사의 CTO나 개발실장이 고급 개발자이며, 그 분야의 '구루'급에 해당되는 사람인가? 존재한다면,  그분들이 회사 내부에서 '존경'받으며, '대우'를 받고 있는지 확인해보라. 그 회사에서 꾸준하게 엔지니어로 성장한다면..  그분들과 같은 대우를 받을 수 있는 인사 환경을 갖추고 있는지 확인하면 된다.


대부분 허접한 회사이거나 일반 기업체에서 전산실의 역할이 부실한 경우라면 IT기술을 최고로 습득해도 계장 이상 올라갈 수 없는 곳이라면, IT기술을 중요시하는 기업이 아니라는 것이다. 이런 경우에는 '직장인'으로써의 비전만을 따지면 된다. ( 정치적인 것이 아니면, 급여, 복지일 것이다. )


'개발자'로써의 삶이나 목표, 비전과는 전혀 상관없는 기업이기 때문에 일반적인 '직장생활'에 충실한 것이 좋을 것이다. 이와 관련된 처세술이나 비교자료는 인터넷에 많으니 검색해서 참조하자.


개발자들이 오랫동안 근무한 사람들이 있는가?


회사가 성장하고 발전하는 과정에서 사람들이 들어오고 나가는 것을 반복한다. 이런 경우에 회사에 오랫동안 근무한 개발자나 엔지니어가 존재하는지 확인해보는 것이 좋다. 대부분 경력이 올라가면 '급여'가 오르게 되고, 이렇게 경험이 풍부한 사람들이 많이 존재하는 개발 조직이나 회사가 발전 가능성이나 시장을 가지고 있는 경우가 많다.


하지만, 회사는 충분하게 돈을 벌고 있지만, 회사 경력에 비해서 적은 경력의 개발자들이 2~3년 차들로 대부분 도배되어 있다면, 특정 시점에 직원들이 물갈이가 되거나, 개발자들이 죄다 못 버티고 나간 경우라는 뜻이다.


'소프트웨어 개발자'들도 대부분 '직장인'에 가깝다. 이 회사가 정말 좋은 곳이고, 계속 다닐만한 가치가 있는 회사라면. 오래된 개발자들이 많이 있을 것이다. 이런 오래된 개발자가 없는 곳이라면 분명, 인사 문제나 처우에 문제가 있는 회사이다.


사무실의 환경을 살펴라.


큰 사무실이건 작은 사무실이건 '실제 일하는 사람들'이 사용하는 '책상'이라면 사용하는 흔적들이 있다. 공간은 있지만, 빈 책상에 사용되지 않는 물품들만 있다면. 인력파견업체가 대부분일 것이고, 처우나 사무실의 환경은 그다지 좋지 않을 것이다.


대부분 팀장이고 이사이고 아웃소싱 일을 대부분 하고 있는 사람들일 것이고, 당연하지만, 근로환경도 최악이고, 월급이 때인다던 지, 프로젝트 진행이 개판이 되는 경우가 많다.


신입직원 연수나 트레이닝 프로그램이 있는지 확인하라


대부분, 이직 시에 이러한 것들을 고려하지 않는다. 하지만, 대부분의 중소기업이나 대기업들의 경우에 자체적인 솔루션이 있거나 나름 시장 지배력이 있는 회사의 경우에는 ‘사전에 교육’ 해야 할 내용들이 많아진다.


당연하지만, 신입직원들에게 짧으면 2주, 길면 4주 이상의 트레이닝 코스가 존재하게 된다. 나름 시장 지배력이 있는 회사라면 이러한 코스가 당연하게 있다. 만일 이러한 코스가 없다면, 해당 기업은 의미 있는 솔루션을 만들거나, 의미 있는 서비스를 하고 있는 회사라고 보기 어렵다.


그것은 중소기업들은 대부분 적당한 인력을 구인해서 적당하게 사용한다고 보면 된다.


이처럼 소프트웨어 개발자가 이직을 생각할 때에 이러한 조건들도 있지만, 오히려 개발 경력이 3~4년 차를 넘기는 개발자에게 필자가 가장 중요하게 질문하는 것이 있다. ‘소프트웨어 개발이 적성에 맞는가?’라고 묻는다.


굳이, 소프트웨어 개발이 아니더라도 자신의 자아실현이나 사회생활이 충분하게 실현되는 경우도 많다. 억지로, 소프트웨어 개발자의 길을  걸어가면서 주변을 괴롭히거나, 오히려. 안 좋은 중간 관리자가 되면서 IT업계의 원흉이 되는 것도 이 시기에 잘못 결정한 선배들이나 후배들도 많다.


필자가 만난 여러 후배 개발자 중에는 소프트웨어를 설계하고 만드는 일이 그다지 적성에 맞지 않는 경우도 상당수 있었다. 또는, 저 사람은 아예 소프트웨어 개발을 하지 않았으며 좋겠다는 생각을 하게 된 사람도 있었다. 그래서, 오히려 조언을 하거나 유도를 해서 다른 일을 선택하고 그 길을 잘 걸어가는 후배들도 여럿 있다.


하지만, 대한민국의 SI개발에만 있었다면 다른 직종도 가능할까?라는 질문에는 사실, 정답이 없다고  이야기한다. 갑을병정 이무기라고 불리는 먹이사슬의 과정 속에서 SI현장에서 다른 분야로 진출하는 것은 정말 어려운 일이다.


대기업이나 중소기업의 SI에 입사해서, 프로젝트 관리자의 길을 걸어가는 사람이 아니라면, 매우 어려운 자리가 될 것이다. 하지만, SI나 SM의 이직 시에도 제대로 된 선택을 하면 매우 수월하고 편안한 자리로 이직을 할 수 있다.


실제 후배들 중에는 많은 급여보다는 안정적인 자리를 원하는 도메인이 특화된 SM자리를 잘 차지하고 편안하게 일하는 개발자들도 간혹 발견할 수 있다. 하지만, 그런 환경이 아니라면 필사적으로 이직 시의 조건을 따져봐야 한다.


최소한 ‘피해야 할 회사의 조건’을 따져봤다면, 이제는 가장 현실적인 ‘조건을 나열하여 회사와 조직의 환경을 살펴보자. 다음의 조건들을 살펴봐라.


야근수당을 받는가?


2015년을 기준으로 나이 30세 초반에 연봉 3000~4000이라면 소프트웨어 개발자로서 만족하는 삶을 살 수 있을까? 하지만, 사회생활에 있어서 야근수당을 받거나 주말에 근무하면 추가 페이를 계산받는가? 냉정하게 계산하고 매일 야근과 주말근무를 하고 있다면, 실질적인 연봉은 무려 5~6000만 원을 받아야 정상이다.


필자가 중견그룹의 CIO 역할을 하던 시절에 인사팀에서 가장 많은 경고와 안내를 받았던 것 중의 하나가 '야근'근무를 가능한 하지 않도록 유도하는 안내였다. 야근을 하게 되면 자연스럽게 지출되는 야근을 위한 식사와 연장근로수당, 그리고. 주말까지 일하게 되면 2배를 넘어가는 수당의 지급은 상당히 부담스러웠던 것이기 때문에, 인사팀에서는 이러한 근무를 하지 않도록 유도하는 것이 최선의 방법이었을 것이다.


대부분 괜찮은 기업들은 '야근'근무를 유도하지 않는다.


단지근무조건이 탐나는가?


냉정하게 SI는 전문성이 매우 높은 분야인데, 대한민국에서는 그러하지 않고, 거의 막장에 가까운 환경을 가지고 있다. 매우 슬픈 일이다. 일본이나 미국과 같은 선진국에서 근무하는 SI 개발자들의 처우나 근무조건은 매우 좋은 조건들이고, 연봉 또한 매우 높다.


제대로 된 SI분야의 경우에는 대체인원이 그렇게 많지 않고, 어느 정도 경력을 가진 개발자로 성장하기 매우 어려운 분야이기 때문에 경력자와 경험자를 매우 우대한다. 하지만, 대한민국의 SI현장은 정말 열악한 환경으로 변화하였고, 그 현장은 매우 절망스러운 곳들도 많다.


대한민국의 SI가 이렇게 된 이유에 대해서는 여러 가지 이유와 근거와 설이 존재하는데, 필자가 생각하는 몇 가지 이유는 다음과 같다.


하나. 대기업의 전산실에서 분리된 IT조직의 태생적 한계

둘. 전산/IT를 제대로 전공으로 한 '선배'들이 실제 부재하다.

셋. 대정부의 SI 관련 프로젝트가 갑을병정 프로세스만으로 진행되면서 만들어진 흑역사

넷. 소프트웨어 품질을 모르는 PM/PL들이 아직 수두룩하다. ( 이론만 아는 방법론자들 투성이다. )

다섯. 책임지는 소프트웨어 개발 조직과 개발인력이 그다지 SI현장에 없다.

여섯. 소프트웨어 개발은 '자격증'과 아무 상관없고, 개발 경력과도 그다지 연관성이 없다.


그래서, 대한민국의 SI현장은 주변에 잘 수소문하여 ‘괜찮은 곳’을 찾아가는 센스를 발휘하지 못하면, 암흙의 이직을 경험할 수 있다.


물론, 이렇게 이야기하는 ‘이직’의 대부분은 ‘스타트업’이나 ‘도전적인’ 기업을 선택하는 것과는 다른 기준들이다. 대부분은 ‘조직’이라는 틀에서 움직이는 ‘작업자’들을 구인하고 그 공간이 나에게 맞는지에 대해서 잘 따져야 하는 것이다.


결국, '조직'의 틀로 생각한다면, 일반 샐러리맨의 회사 선택의 기준과 그다지 차이가 없을 것이다.


하지만, 소프트웨어 개발자의 세계에서 '이직'을 제대로 할 수 있는 방법은 말 그대로 '스카우트'을 받고 이동하는 것이다. 그런 대우를 받으려면, 제대로 평가된 ‘나의 인식’과 ‘나의 브랜드’가 있어야 가능하다는 것을 염두에 두자.


결론적으로 '이직'을 제대로 하려면, 자신의 '브랜드'를 만들 수 있어야 한다. 그것이 핵심이다.


그렇다면, 성공적인 이직을 하려면 무엇을 갖추어야 하는가? 그것은 다음의 6가지로 정리할 수 있다.


하나. 자기만의 장점을 가져야 한다.

둘. 자신만의 전문성을 가져야 한다.

셋. 절대다수는 하지 못하는 희소성을 가져야 한다.

넷. 내 경력과 전문성을 증명할 프로젝트를 가져야 한다.

다섯. 포트폴리오를 구성하라

여섯. 외부활동과 내 브랜드를 만들어라


이 6가지 중에 2~3가지만 충족한다고 하여도, 소프트웨어 개발자는 제대로 된 대우나 평가를 받으면서 즐거운 이직을 경험할 것이다. 말 그대로 헤드헌팅이나 개발자 커뮤니티에서 당신에 대한 평가가 좋을 것이다.


매우 당연한 것이지만, 준비된 사람에게는 언제나 기회가 만들어진다. 기회가 만들어지지  않는다는 것은 ‘준비가 부족하기 때문이다’라고 이야기할 수 있다.


직업 이직을 권유받았는가아니면이직을 꿈꾸는가?


그렇지만, 그렇게 브랜드나 명성을 얻기 전에 권유를 받았건, 상사가 괴롭혀서 떠나건, 이직에 대해서 고민하고 결심했다면 다음의 몇 가지를 고민하자.


후배들에게 이야기하는 몇 가지 충고의 이야기가 있다. 이것은 정말 최소한의 기준이다.

최소, 이 기준에 대해서는 고민하고 '이직'을 결심했으면 좋겠다.


하나. 소프트웨어 개발자들이거나 SI현장에 있는 개발자라면 최소한 하나의 도메인이나 전문분야를 택했다면 최소 5은 버텨야 한다.

둘. 프로젝트나 포트폴리오는 5년 이하 경력은 세상이 제대로 인지하거나 인식하지 않는다.

셋. 직장이 중요한 것이 아니라, 직업도메인이 중요하다.

넷. 경력과 브랜드는 ㅇㅇ회사의 누구가 아니라. 누가 다니는 ㅇㅇ회사가 더 좋다는 평가를 받아야 한다.


SI현장에 있건, SM현장에 있건, 대기업이나 중견기업은 파견 나온 개발자를 좋아한다. 어떤 분야이건 어떤 특수하거나 일반적인 분야이건 대부분은 교육이 필요하고, 경험이 필요하다. 그리고, 그 조직과 회사에 적응하는 기간이 필수적이다. 대부분 이러한 '비용'은 기업을 운영하는 입장에서는 어떻게든 최소화하기를 원한다.


대부분 이런 신입 비용을 어떻게 줄이느냐가 관건이기 때문에, 대부분의 회사들은 가능한 '경험'자와 '경력자'를 선호하는 것이 매우 당연하다. 특히나, 관련된 일과 조직에 익숙한 사람이라면 회사 입장에서는 신입의 교육비용이 들어가지 않는 파견된 개발자들을 선호하게 된다.


바로 업무에 투입하고 결과물을 얻을 수 있기 때문에, 이러한 파견된 개발자들을 선호할  수밖에 없다. 그래서, 보통 갑, 을의 조직들은 자신의 일을 위해서 파견 나온 SI, SM개발자들을 참 매력적으로 인식한다.


특히나, 이렇게 일하는 SI, SM 개발자들은 함께 일하고, 같은 조직에서 일하는 사람들이기 때문에 눈으로 확인한 이러한 사람들을 좋아할  수밖에 없다. 당연한 것이지만, '면접'을 통해서 사람을 뽑는 것보다 직접 함께 일한 사람을 뽑는 것이기 때문에 해당 기회비용과 교육을 위한 시간 비용들이 모두 절약된다.


그래서, 대부분은 고객 회사에서 이런 개발자들에게 먼저 이직을 권유하게 된다. 고객의 입장에서는 바로 실전에 투입할 수 있는 개발자를 얻을 수 있고, 권유를 받은 개발자 역시 중소기업이나 파견직에서 일하다가 더 높은 연봉과 복지제도를 제공하는 기업으로 옮겨갈 수 있는 기회를 얻는다.


다만, 이러한 권유를 받는 것은 '인력파견'업체를 통해서 SI현장에 나가서 일하는 경우에는 이러한 '기회'를 얻기 어렵다. 실제, 이러한 '제의'를 받는 경우는 '고객'의 기업에 직접 나가서 일하는 경우를 의미한다고 봐야 한다.


물론, 이러한 것을 중소기업 입장에서는 인력 빼가기?라고 볼 수 있다. 필자도 중소기업을 운영해봤지만, 중소기업에서 4~5년 이상 일을 하고 있는 직원이 아니라면, 이러한 이야기도 하기 힘들것이고, 실제, 중소기업의 일이라는 것이 '일을 배우고 가르치는 이유가 어느 정도 업무에 필요한 수준'까지만 가르치기 때문에, 이를 중소기업의 인력 빼가기라고 이야기하기 어렵다. 가르친 것도 없이 일만 시켰는데 무슨 ‘인력 빼가기인가?


다만, 가장 최악의 이직 회사를 피하는 방법은 정말 고려하다. 하지만, 이직을 할 때에 순간적인 선택에 의해서 정말 좋지 않은 선택을 하는 경우가 종종 있다. 하지만, 아래와 같은 회사로 이직을 하였다면, 재빠르게 '사표'를 내는 것이 가장 현명하다. 필자의 경험을 기반으로 이런 회사는 빨리 떠나야 한다고 생각한다.


하나회사의 사무실의 인테리어가  허접하다


현재의 소프트웨어 개발자들의 인테리어는 대부분 훌륭하다. 특히, 이제 막 시작한 스타트업의 경우라면 직원이 아니라, '동료'의 입장으로 참여하는 것이기 때문에 이 조건은 해당이 안될 것이다. 하지만, '직원'의 입장에서 그 회사에서 일을 하는 경우라면 '회사 인테리어'는 매우 중요하다.


그것은 초라한 사무실에 초라한 책상에 기본적으로 제공되는 도구도 깔끔하지 않다면, 정말 간단하다. 그 회사에서 직원들에 대한 처우나 근로환경은 최악이라고 보면 된다. 아마도, 입사를 한지 한 달 후에 바로 급여나 근로형태에 대해서 불만이 생길 것이다.


대부분 이런 회사의 특징은 인력파견 회사일 확률이 높다. 당연한 것이지만, 내부에 축적된 지식도, 솔루션도 없는 조직이다. 그냥, 싼 개발자를 구하고, 파견을 보낼 개발자를 구했을 것이고, 그것에 당신이 걸려들은  것뿐이다. 빨리 탈출하는 것이 현명하다.


직원들의 얼굴 표정이 매일 야근한  같다.


근무조건과 처우에 대해서는 그 회사에서 근무하는 직원들의 모습을 보면 된다, 깔끔한 복장에 자유롭고, 자신에 찬 얼굴을 하고 있는 경우라면 상관없다. 하지만, 세탁한지 며칠 된 복장에 연일 야근에 찌든 듯한 얼굴, 사무실에 난로도 제대로 안 때워서 매번 감기에 걸려있는 상태인듯한 모습이라면, 그 회사도 빨리 탈출하는 것이 현명하다.


필자는 개인적으로 소프트웨어 개발자들을 제대로 처우하는 곳이라면 키보드와 마우스, 그리고. 의자는 최대한 자신이 원하는 도구를 구해주는 곳이라고 생각한다. 그리고, 최소한의 근무환경을 구성해줄 수 있어야 한다. 다만, 같이 고생하고 같이 나눌 동료가 아니라면 이런 회사는 빨리 탈출하다.


오래된 선배 개발자의 경력이 얼마나 되는가?


좋은 조직과 좋은 회사. 그런 곳은 좋은 회사다. 고로, 당연하게 좋은 회사는 계속 다닐만한 가치가 있기 때문에 오래된 개발자들이 존재한다. 회사 업력이 10년이 넘었다면, 10년을 다닌 개발자가 있을 것이고, 5~6년 차 개발자들이 여러 명 존재해야 한다.


하지만, 회사 경력이 10년을 넘었는데도 그 회사 경력 2년 차가 팀장이고, 병특들로 모두 구성되어 있는 회사라면, '결코 좋은 회사는 아니다'.


분명하게 회사의 사장에게 문제가 있거나, 똘아이 같은 개발이사가 있거나, 막 나가는 팀장이 있을 수 있다. 또는, 처우나 급여문제 등등 문제가 분명 존재할 것이다.


가족과 같다는 이야기를 반복하는 사장의 이야기


회사는 '이익'을 위하여 존재하는 곳이고, '돈'을 벌어야 급여가 나오는 회사이다. 회사는 '가족'이 아니다. 그리고, '사장'처럼 일하라고 반복하는 '사장'들이 가끔 있다. 그럼, 이렇게 반문해보자, '사장'같이 일하면, '그 회사'를 물려줄 것인가?


아니다. 처우는 '노예'처럼 하면서 일은 '사장'처럼 하기를 원하는 것이다. 이런 회사도 떠나라. 또 이런 회사의 특징은 이렇다.


'회사 사정이 어려워서...', '요즘 경기가 안 좋아서...', '다음에...', '이거 끝나면 뭔가 있을 거야...'


부끄럽지만 필자도 이런 이야기들을 20대 후반 사장 시절에 반복했었다. 결론적으로 '지키지 못할 약속'을 그냥 반복할 뿐이다. 이런 이야기의 99%는 뻥이고, 그냥.  '립서비스'일뿐이다. 포상은 합리적이어야 하는 것이다. 또한, 엄청난 투자를 받는다고 해서  밀어붙인 일일 경우도 많다. 하지만, 언제나 '과실'중에 '이익'은 경영진만이 가지고 간다는 것을 잊지 말자.


다섯인건비는 무조건  개발자만 찾는 회사.


간단하다. 경력 10년 차 개발, 고급 개발자가 할 수 있는 일을 하거나, 품질이 높은 일이 필요 없는 일이 대부분이다. 임금이 비싸고 경력이 풍부한 사람이 비싼 이유는 당연하게 있다. 하지만, 단지 급여가 싼 사람을 찾는 이유는 간단하다.


'일'에 대한 가치를 알지도 못하고, '개발자'에게만 탓을 돌리는 사장이나 경영진일 경우에 대부분 이렇다. 경력 1년 차가 할 수 있는 일이라고만 생각하기 때문에, 경력 4~5년 차도 그에 합당한 급여를 줄 수 없는 것이다.

당연한 것이지만, 실제 일은 단순 SM이기 때문에 그런 경력을 가진 개발자가 필요 없다고 인지하기 때문이다. 이런 회사들이야말로 정말 비전이 없다.


여섯급하게 뽑는데 면접도 제대로 안보는 회사


정말 엉터리 같은 인력파견업체의 경우가 이렇다. 자신들이 면접을 보는 것이 아니라, 고객사로 보내서 면접을 본다.


만일 위에 언급한 6가지 내용 중에 한 개 이상으로 해당되는 회사나 조직에 있다면, ‘이직’을 고려하는 것이 정말 당연하다 하겠다. 하지만, 자신의 능력과 이직에 대한 준비가 되어 있지 않다면, 어쩔 수 없다. ‘샐러리맨’의 기본자세로 돌아가서, 내 능력에 합당한 현재의 자리에 만족하는 법을 배워야 할 것이고, 처세술이나 그 조직에서 버티기 위한 정치력을 발휘해야 할 것이다. 이러한 글들은 주변 서점에 널려있으니, 그런 책 한두권 읽어보기를 권장한다.


‘이직’은 소프트웨어 개발자 생활을 하면서 계속 유혹과 한계를 경험하게 할 때마다 머릿속에 떠오를 것이다. 그때에 실수하지 않고, 좋은 판단을 하기 바라며. 가장 중요한 것은 ‘후회’ 하지 않고, 이미 결정한 것은 잊어버리는 것이 속 시원하다는 것이다.


마지막으로 좋은 스타트업을 골라달라고 조언하는 경우에는 다음과 같이 답한다.


스타트업은 좋은 동료가 될 생각이 있을 때에 들어가라는 것이다. 스타트업은 초기 멤버로서 합류하면서 고생도 같이 하고, 이익도 같이 나누는 동업자가 되는 것이다. 샐러리맨으로써 직장을 택하는 것과는 정말 다른 것이다.


물론, 스타트업이 투자를 받고, 초기 멤버가 아닌 경우에는 위에서 언급한 내용과 별로 차이가 없다고 설명할 수 있다. 어느 규모나 별로 차이가 없었다.


'이직'은 소프트웨어 개발자들에게는 매번 경험하게 된다. 그리고, 그 경험을 좋은 결과로 얻기를 바란다. 그리고, 언제나 좋은 선택이  필수이며, 인생 선배나 동료에게 좋은 조언을 구해보자.

관리자
2019-02-14 14:14
조회 116

출처 : 신현묵 개발자님의 브런치 

원문 링크 : https://brunch.co.kr/@supims/1



소프트웨어 개발자들이 생각하는 ‘성공’이라는 단어와 키워드에는 어떤 것들의 의미를 포함하고 있을까? 한편으로는 단편적이고 획일적인 ‘성공’이라는 단어에 너무 많은 개발자들이 매몰되어 있는 것 아닌가 하는 생각을 해본다. 필자 스스로 실무경력 20년을 넘겨서 소프트웨어 개발을 하고 있는 경험을 바탕으로 주변의 성공한 개발자들에 대해서 혼자 생각해 보았다.


일반적으로 의미의 ‘성공’이라는 것이 무엇을 의미하는 것인가에 대한 정의는 이번 칼럼의 말미에서 이야기하도록 하자. 정말 많은지 모를 대한민국에서 성공한 개발회사나 개발된 서비스들을 살펴보는 것부터 시작을 하는 것이 정답인지는 필자도 잘 모르겠다. 성공적인 서비스나 소프트웨어, 프로그램은 세상에 선보인다는 것. 그러한 것을 만들어낸 순수한 아이디어나 원천기술로 무장한 기술로 축적되었고, 그 아이디어를  뛰어넘어, 새로운 기술이라고 할 수 있는 것을 보유한 제품이나 상품들이 얼마나 되는지에 대해서부터 냉정하게 필자는 잘 모르겠다라고 먼저 인지하고 넘어가자. 아니, 다시 말하자면, 냉정하게 국내에서 그런 것을 본적이 별로 없는  듯하다.


더욱더 삐딱하게 이야기하자면, 국내에서 성공한 개발 서비스들은 대부분 아류작이거나 남의 아이디어를 도용한 제품과 서비스들이 대부분이 아닌가라고 생각한다. 심지어는 특정 솔루션 시장은 오픈소스를 그대로 제품에 반영해 두고서는 자신의 제품인 것처럼 위장하는 사례까지 보이고 있으니, 과연 대한민국 소프트웨어 시장은 과연 얼마나 ‘성공’이라는 키워드를 그대로 사용해도 되는지에 대해서 매우 의문시된다.(물론, 필자의 삐딱한 시선에서만 그렇게 보일지도 모른다.)


대한민국의 소프트웨어 시장에서 1위를 지키고 있다고 하는 서비스와 제품들이 되려면 어떻게 해야 하는가?. 삐딱하게 이야기하자면, 오로지, 대한민국에서 성공한 개발회사나 개발자가 되려면, 창의적인 아이디어나, 독특한 아이디어로 무장하는 승부수를 던지기 보다는, 해외의 서비스 중에 알차고, 괜찮은 것들에 대해서 관심을 가지는 것이 중요하다고 생각한다. ( 그래서, 영어공부를 잘해야 하는지도 모르겠다. )


필자가, 대기업과 신규사업기획을 할 때에 작업하는 내용을 보고서는 경악을 금치 못했던 경험을 한적이 있다. 정말 상당한 컨설팅 금액( 수십억을 넘긴 비용 )을 지불해서, 대기업이 유명한 컨설팅업체를 통해서 신규사업에 대한 기획과 아이디어에 대한 컨설팅을 받는 것에 전문가의 한 사람의 참여했었다. 그런데, 그 중요한 작업의 모티브는 해외에서 이미 성공적으로 안착한 서비스에 대한 분석과, 한국에서의 서비스 시에 벌어질 일에 대해서 예측을 하는 일을 하고 있었다는 점이다. 새로운 아이디어가 아니라는 점이다.


물론, 성공한 서비스를 도입해서, 로컬 화한다는 것 또한 매우 어려운 일이라고 생각하지만, 대부분의 새로운 기획이나 신규 서비스에 대한 작업들의 대부분을 이런 식으로 진행한다는 이야기를 들었을 때에 받은 충격은 정말 놀라운 경험이었다, 물론, 지나고 나서 생각해보니, 그렇게 놀랄만한 경험도 아니었는지 모르겠다. 대부분의 대기업들이 이런 식으로 한다는 이야기를 듣고 더 놀라기는 했지만. 물론, 이렇게 로컬화 한다는 것 자체도 대단한 도전이고 어려운 점이라는 것은 인정한다고 하지만, 이런 로컬화와 아류작에 대해서 비판적인 시야를 가진 필자의 생각은 그렇다.


성공한 서비스들은 대부분 아류작들이다?


냉정하게 국내에서 성공한 대부분의 서비스들은 아류작들이고, 복제본들이고, 독창적인 아이디어보다는 해외 서비스를 대부분 국내에 안착한 서비스라고 생각한다. 심지어 독창적인 mp3 플레이어마저도, 아이팟의 생태계가 한층 더 발전적인 시장을 창출했으니, 국내에서 만들어진 디지털적인 요소들 중에 독창적인 것이 얼마나 있는가?


필자는 생각한다. 예술에 있어서 복제와 창작의 차이는 매우 크다는 것을. 물론, 소프트웨어 개발이 이런 예술에 비견될 정도의 가치를 부여해서 그런 것 만은 아니다. 소프트웨어 개발은 아이디어와 구현하고자 하는 추진력과 열정이 결합되어져서 만들어지는 최고의 가치 구현을 위한 세계이기 때문에 그렇게 생각할 뿐이다.


필자가 좋아하는 만화 중에 ‘맛의 달인’이라는 만화에 나온 표현을 그대로 옮기자면 다음과 같은 장면이 나온다. 프랑스의 유명한 요리를 그대로 일본에서 구현하지만, 그 요리에 대한 평가는 ‘프랑스의 요리를 그대로 구현한 요리이다’. ‘매우 아름답지만 최저의 요리’라는 평가를 받는다. 그러한 최저의 요리라는 평가를 받은 이유는 ‘로컬화 한다는 것은 실정에 맞게 고치고, 연구 개발한 맛이라면 완벽하겠지만. 너무도 프랑스 요리와 똑같이 만든 것은 처절한 아류라는 점이다. 지금 먹은 요리에는 프랑스 요리사의 모습이 그대로 남아있다는 점. 원형이 프랑스의 것을 그대로 답습했다는 것.


오리지널을 복사했다는 냉정한 평가는 정말 명확하다. 요즘 가장 국내에서 최근에 성공한 서비스를 이야기한다면, 카카오톡과 애니팡을 예로 들 수 있겠다. 다른 사람들은 어떻게 평가할지 모르지만, 정말 대단한 성공을 가진 것은 사실이다. 하지만, 둘 다 원형을 그대로 복사했을 뿐, 새로운 것은 아무것도 없다는 점이다. 아니, 오히려. 기존의 원형을 대한민국의 안 좋은 통신사의 서비스와 결합한 케이스라고 평가를 해야 정확하지 않을까 한다. 원형을 오히려 퇴보시킨 서비스라고 평가하고 싶다.


카카오톡은 WatsApp을 그대로 복제했다. 대표적으로 등록되어진 전화번호로 연계하는 원형의 아이디어를 그대로 받아들였다. 하지만, 카카오톡의 새로운 신규 비즈니스 모델인 게임센터는 자체적인 생태계를 만들어서 통제하려 하는 기존의 통신사의 방식과 그다지 차이가 없다고 보인다. 뭐, 돈을 벌어야 하는 기업의 입장을 반대하는 것이 아니다. 단지, 필자의 삐딱한 시선으로는 진보를 위한 선택이 아니라, 퇴보를 위한 선택이었다는 점이 불편할 뿐이다.


애니팡도 마찬가지이다. 기존의 게임방식을 그대로 복제했다. 그리고, ‘하트’라는 이름으로 무분별한 ‘스팸’을 활성화해서, 기존 통신사들이 SMS에서 얻어들이는 대량 SMS 발송을 통한 이익을, 그대로 실현한 점이다.


물론, 카카오톡이나 애니팡의 ‘이익 실현 구조’는 매우 성공적으로 국내에 론칭한 것은 사실이고, 이러한 구조로 ‘돈’을 벌어야 한다는 점이 매우 안타까울 뿐이다. 개인적으로는 ‘국내’에서는 어느 정도 ‘돈을 버는 성공은’할 수 있지만, 해외에서까지 성공적으로 론칭할 것인지는 조금 의심스럽다. ( 어차피, ‘돈’을 벌면 성공이라는 관점으로는 매우 대성공이다. )


넥슨의 카트라이더와 마리오 카드와 같이 일일이 나열하기에는 너무도 많은 사례들이 있어서 굳이 더 나열하지 않겠다.


다만. 정말 중요한 것은 복사보다는 진짜가 더 좋다는 점이다. 가령, 오리지널이 존재하는 영역이나 예술과 같은 고부가가치의 영역에서는 ‘화가나 작가가 다른 사람의 작품을 흉내내면  웃음거리밖에 되지 않는다’는 점을 이야기하고 싶다. 필자 개인적으로는 ‘그런 웃음거리를 통한 수익실현’을 그렇게 높게 평가하고 싶지 않기 때문이다.


대표적으로 통신사는 ‘스팸’과 ‘보이스 피싱’을 해결하지 못하는가? 에 대해서 필자는 그렇게 생각한다. ‘대량 SMS수입’을 포기하지 못하고, ‘전화번호를 통한 대량 통화의 수익’을 포기하지 못하는 구조적인 문제 때문에 그렇다고 생각한다.


과거에 문제가 된 iOS6로 업데이트가 되면서 SKT 아이폰4S에서 발생한 전화번호 호출의 문제, ‘112 신고가 안 되는 아이폰’이라는 기사와 사건에 대한 문제의 근본적인 원인은 SKT가 국제표준 방식을 따르지 않아서 발생한 문제라는 것을 모르는 사람들이 정말 많다. 이 문제를 더 파고들어가면, 부당한 SMS수입을 얻고 있는 국내 통신사들의 부도덕한 점도 드러난다. 2003년 이후 3G 서비스(WCDMA)가 도입되었지만, 문자 메시지 국제표준이 기존의 80 byte에서 140 byte로 늘어났지만, 정작 통신사들은 국제표준규격을 지키지 않으면서 연간 수백억의 이익을 부당하게 얻어냈다. 다만. 아이폰4s 출시 당시 KT는 140바이트를 맞추었지만, SKT는 아직도 80 byte였다는 점을 예로 들고 싶다.


국제표준을 따르거나, 해외의 서비스가 ‘돈’이 되는 것에는 빠르지만, ‘돈’이 안 되는 기준에는 미온적이고, 대처가 느린 것에 대해서는 참으로 훌룡(?)한 성공적인 방법이라고 평가를 굳이 필자와 같은 주변 사람이 할 필요가 있을까 한다. 그런 훌륭한 평가는 비싼 컨설팅 비용을 지불한 뛰어난 전문가들이 할 것이기 때문에...

내 주변에 성공한 개발자와 성공한 벤처 사업가...


성공한 개발자. 고급 승용차를 몰고, 출근하는 개발자의 모습을 본다면, 성공한 개발자의 향기를 느낄 수 있을까? 물론, 일반적으로 그럴 수 있다고 생각한다.


자본주의 사회에서 ‘돈’은 그 사람을 평가하는 가장 기본적인 ‘수단’이기 때문이다. 성공하지 못한 필자는 아니지만, 필자 주변에는 고급 승용차인 BMW나 벤츠를 직접 몰고 다니는 성공한 개발자들이 여럿 있다. 그리고, 상당히 많다. 사업을 하는 사람으로부터, 프리랜서인 사람까지 매우 다양하다.


분명, 그들은, 자신만의 서비스와 제품을 실현하였고, 시장에서도 안정적인 자신만의 브랜드를 확립하였고, 후배들로 존경을 받고 있으며, 직원들에게 비전과 꿈을 주고 있으며, 새로운 기술과 시장에 대해서 언제나 도전하고 있는 사람들이 있다.


그들은 충분히 ‘성공’한 사람들이다.


‘복제’와 ‘아류작’이 아니더라도. 독특한 자신들만의 서비스와 제품을 구현하여 성공한 개발자들이 분명 존재한다.


그들의 성공요인을 주변의 사람으로서 살펴본다면, 몇 가지의 요인이 있다고 정의할 수 있다. 그것들을 필자의 주관적인 생각으로 정리해보면, 크게 4가지 정도로 정리할 수 있다고 본다.


하나. 그들은 뛰어난 개발자는 아니었다.


그들은 아주 탁월한 능력을 소유한 개발자들은 아니었다는 점이다. 그리고, 아주 뛰어난 학벌을 가진 개발자들도 아니었다. 개발자 동호회에서 만난 친구도 있고, 직장생활이나 사회생활에서 만난 사람도 있었지만. 그들은 아주 탁월한 재능을 지녔거나, 엄청난 코딩능력, 뛰어난 직관을 지닌 사람만은 아니었다.


순수한 개발 능력만 놓고 본다면, 오히려, 뒤처지는 개발자들이었는지도 모른다. 하지만, 뛰어난 개발자들이나 아이디어를 가진 사람들과 친하게 지냈으며, 그들의 도움을 자연스럽게 얻어내는 소통의 달인은 아니었지만, 개발자 커뮤니티에 매우 즐겁게 활동을 하던 사람들이었다.


둘. 그들은 우직하지만, 묵묵하게 자신의 상품과 아이디어를 다듬었다.


그들은 하나의 아이디어가 실현되는 것을 쉽게 포기하지 않았다. 사업을 하기 전에는 그 아이디어를 실현하기 위해서 애썼고, 속한 회사가 아이디어에 대해서 낮은 평가를 하는 것에 대해서도 크게 실망하지 않았다. 오히려, 반대를 해도 해당 서비스와 제품, 기술에 대한 애정이 정말 높았으며, 그것을 실현하려고 매우 애썼다.


처음에는 언제나 소프트웨어는 단순한 것부터 시작한다.


그 단순한 것을 꾸준하게 다듬고, 소프트웨어에서 제품으로 다듬어서 시장에서 가치를 인정받을 수 있도록 수년 이상을 투자하고 노력해야만 얻어진다. 그것은 스티브 잡스도 똑같았다. iOS는 하루 이틀 만에 나온 소프트웨어가 아니기 때문이다.


심지어, 몇 년 동안 밥을 굶더라도, 자신이 생각하는 가치를 실현하기 위해서 포기하지 않고 도전했던 우직한 도전이 오히려 성공을 만들어 내었다. 분명, 훌륭한 소프트웨어는 뛰어난 기술로 만들어지는 것만은 아니다는 것을 요 근래에서야 필자도 느낀다.


필요한 가치가 적정한 가격에 구현되어진 것이 정말 필요하다는 점이다. 뛰어난 기술이 뛰어난 제품을 만드는 것이 아니라, 뛰어난 제품이 뛰어난 기술을 만든다는 것이다. 그것이 사용자들로 하여금, 또 다른 가치를 얻을 수 있는 기능을 제공한다는 것에 대해서 굳이 설명하지 않더라도, 그들은 그 아이디어와 생각을 실현하기 위해서 자신만의 길을 걸었다.


정말 우직할 정도로... 필자 주변의 그들은, 몇 년을 일 년에 몇백만 원을 벌더라도, 그 꿈을 포기하지 않았다.


셋. 시장과 세상의 시선을 그렇게 두려워하지 않았다. 자신의 ‘가치’와 ‘비전’을 실현했다.


자신의 아이디어와 자신의 서비스, 제품을 지키기 위해서 약간의 주변 사람들에게 욕을  얻어먹는 것을  두려워하지 않는다. 필자가 아는 어떤 기업은 시장에서는 냉혈안이라는 말도 듣고, 불법 복제된 제품에 대해서는 가차 없는 소송도 불사하는 어떤 기업을 알고 있다. 하지만, 그 회사와 그 사장에 대해서 필자는 비난하지 않는다. 왜냐하면, 그는 기업 내부의 직원들에게는 절대 급여를 밀리지 않고, 야근을 시키지 않는 최고의 사장이었기 때문이다.


시장과 타인에게는 가차 없지만, 자신이 생각한 비전을 실현한 회사를 만들기 위해서 언제나 최선을 다하는 사람이었을 뿐이다. 그리고, 자기 것을 지키기 위해서 애를 썼고, 직원들과의 거리도 언제나 적절하게 유지했다. 냉정하게 기업과 사업이라는 것은 자선사업이 아니라는 것을 잘 알고 있었다. 충분하게 돈을 벌고, 외제 승용차를 사장은 타고 다니지만 ( 외제 승용차를 타는 것도, 대한민국은 간단하다. 법인세를 충분하게 낼 정도로 수익이 생기면, 그 수익으로 차를 리스해서 타면 간단하다는 대한민국의 세법 구조 때문이다. ), 모든 직원들에게 그 이익을 100% 나누어주지는 않는다. 직원은 직원일 뿐이니까.


그들은 회사의 재정이 힘들어지면 소속된 직원을 힘들기 전에 내보낼 줄도 알고, 필요하다면... 해고도 그리 어렵지 않게 결정하는 사람도 있다, 영업기밀을  들고나간 직원과 소송도 불사했다. 차라리, 친구와 따로 술을  마실지언정, 직원들과의 ‘관계’는 냉정하고 쿨한 관계를 유지했다. (물론, 그렇지만. 인간관계가 깨어지는 것을 매우 괴로워하는 사람들이다. 다만, 아래 직원들에게 속시원히 이야기를 못할 뿐이다. )


넷. 필요한 기술자나 기술은 기필코 얻으려 노력했다.


그들은 자신이 부족한 점을 잘 이해하고 있었다. 부족한 것을 오히려, 더 널리, 많이 이야기를 하였다. 그리고, 그것을 커버하기 위해서 매우 많은 노력을 한다. 다 잘하고자 하는 팔방미인이 되는 것이 아니라, 자신이 부족한 점을, 자신이 가장 잘하는 것으로 커버하려 애쓴 것이다. 전문적인 기술을 소유한 사람에게 도움 요청하는 것을 부끄러워하지 않고, 도와준 사람에게 충분한 대우나 접대를 잊지 않았다. 그래서, 그들이 도와달라고 하면, 주변의 전문가들이 아낌없이 그를 도와준다.


그 이외에서 그들은 그렇게 ‘성실’하게 일하는 친구들은 아니었다. 실제, 사장이었던 그들이 직원의 입장으로 회사를 다닐 때에는 근태 문제로 지적을 받은 친구들도 꽤 많다는 점이다. 아마도, 사업이나 자신이 좋아하는 일을 하는 것과, 어떤 일이 주어진 상태에서 일을 하는 것은 분명 다른 지도 모르겠다. 직원일 때에 불성실하지만, 자신의 일을 할 때에 성실한 것은 전혀 상관관계가 없어 보인다. 한편으로는 ‘사장’이나 ‘자신의 일’을 하는 사람의 경우에는 특별하게 ‘근무시간’이라는 것 자체는 큰 의미가 없다는 점이 더 정답일 것이다. 하여간, 그들은 성공한 개발자들이고, 성공한 기업인이 되어 있었다. 자신만의 제품이나 서비스를 만들면 자연스럽게 ‘사장’이 되어버리는 것이 소프트웨어 업계의 현실인 듯하다.


그렇다면, 대한민국에서 ‘성공’이란 ‘돈’을 의미하는가?


강남의 최고급 아파트와 외제 승용차가 성공을 의미할까?


자신의 뛰어난 기술력으로 커뮤니티에서 인정받고, 유명해진 명예를 얻는 것이 성공을 의미할까? 다른 사회현상을 생각하면서 다시 한번 비교해보자.


요즘 개발자들도 오디션 프로에 영향을 받은 듯하다. 요즘 연예계 지망자들이나 배우나, 가수를 꿈꾸는 친구들이 선배나 멘토들에게 묻는 것이 언제나 똑같다고 한다.


그것은 ‘빠르게 성공’하고 ‘빠르게 명예’를 얻는 방법이 무엇이냐 묻는 것이다.


어렵고 복잡하고, 길게 걸리는 방법은 무시하고, 오디션 프로에서 1등을 해서, 빠르게 성공하는 방법만을 생각한다고 한다.


물론, 그 방법도 있을 것이다.


소프트웨어의 세계에도 똑같은 방법이 있다. 대표적인 방법이 유명대학을 가서, S 멤버쉽이 되고, 대기업에 입사해서 경력을 쌓은 다음, 해외의 서비스를 적당하게 분석하다가, 성공적으로 론칭한 서비스를 재빠르게 국내에 도입해서 성공에 이르게 하는 방법이 아마도 가장 빠른 방법일 수 있겠다.


물론, 이 방법으로 ‘성공’을 쟁취하려 하는 개발자라고 하더라도. 비난하지 않는다.


분명, 그 길은 대다수 ‘성공’이라고 부른다. 하지만, 그 길을 선택하고 집중하는 것 또한 매우 어렵고 힘든 길이다. 선택한다고 얻을 수 있는 길도 아니다.


가령, 이 글을 읽는 독자가 학생이라면. 가장 먼저 명문대학을 가는 것부터 시작해야 할 테니, 당장, 이 내용을 덮어버리고, 국영수를 공부하는 것에 몰두해야 하기 때문이다.


사실, 가장 넓게 알려진 성공으로 가는 길은 가장 가기 어려운 길인지도 모른다. 경쟁이란 정말 어렵고 힘들 것이라는 것을 잊지 말자.


본론으로 다시 돌아와 보자. 개발자로서 '성공'이란 무엇을 의미하는가? 아니, 개발자로서 비전을  갖는다는 것은 무엇을 의미하는가?  


원천적으로 개발자의 삶이란 어떻게 살아야 하나요라고 묻는다면,


이 문제는 정말 어렵고, 사람마다 다르기 때문에 최선을 다하는 것이 정답이라라는 교과서적인 답변만 늘어놔야 하는지도 모르겠다.


이점에 대해서는 이제는 폐간했지만 오랫동안 개발자들의 벗이 되었던 마이크로소프트웨어 잡지에 대해서 원망을  슬쩍해보자.


그것은, 나에게 ‘정말 대단히 큰 재미’를 선사했다는 것이 나에게 가장 처음 다가온 충격이었는지도 모른다. 처음에 가진 꿈은 그냥, ‘소프트웨어 개발’을 통해서 삶을 영유할 수 있는 것만으로 나는 행복했다는 점이다. 그래서, 이 소프트웨어의 세계로 진입하게 된 마이크로소프트웨어에 대해서 원망을 해야 하는지도 모르겠다.


하지만 필자는 소프트웨어로써 ‘개발자로서 성공’을 하기 위해서, 이 직업과 삶을 선택한 것이 아니라, ‘개발자로 살기 위해서’이 삶을 선택한 것이었다. 나이를 먹고, 무언가를 목표로 살아온 경험을  되돌아본다면, ‘돈’과 ‘명예’를 선택하지 않았을 때에, 오히려, ‘돈’과 ‘명예’를 얻지 않았는가 하다. 오히려, ‘돈’을 선택하던 시기에 ‘돈’을 더 많이 잃어버린 경험도 가지게 되었다.


이제는 주변을  되돌아보면, 필자는 꽤 넓은 스펙트럼을 가지게 되었다는 것을 느끼게 된다. 한때는 고인이 되셨지만 대통령이셨던 분부터, 수천억을 소유한 재벌 총수, 의료재단과 대학법인을 소유하신 분, 병원의 원장님들을 비롯한 분들을 비롯하여, 출판계, 영화계, 물론. 다수의 소프트웨어 개발자들까지. 매우 넓은 사람 관계를 만들어본 것 같다.


그중에 소프트웨어 개발자들은 참 착하고 바보스러운 사람들이 많은 것 같지만, 한편으로는 너무도 욕심이 많은 사람들이 존재하는 참, 신기한 동네이다.


그리고, 여러 계층을 경험해보니. 모든 계층은 똑같이 피라미드 구조를 가지고 있다는 점이다. 대부분 다 똑같았다. 하층의 사람들은 싼 가격에 노동력과 지식을 제공하고, 상위 레벨에서는 적절한 대우 이상과 재미있고 신기한 일들을 많이 한다는 점이다. 이 부분은 어느 계층이나 똑같다.


대표적으로 출판일을 경험했을 때에 자신의 이름이 들어간 편집장이 되는 사람과, 그것을 목표로 기획자로 일하는 직원의 급여 수준이나 처우, 대우는 정말 최고급 아키텍트와 SI 개발자를 비교하는 것 이상으로 그 상대 감은 소프트웨어 개발세 상의 것 이상으로 매우 컸다.


행복한 개발자라고 한다면, ‘개발이 정말 재미있고’, ‘개발도 잘하고’, ‘소프트웨어 개발 피라미드의 상층부의 일’을 하고 있다는 사람이 있다면. 그 사람은 정말 행복할 것이다. 뭐, 그런 사람은 이 글을 읽고 있지도 않을 것이다.


그러나, 개발이 재미있지 않거나, 개발을 뛰어나게 잘하지도 못하고, 소프트웨어 개발 피라미드의 하층부에서 일하고 있다면, 어떻게 생존해야 하는 가에 대해서 정말 심각하게 고민해야 한다.


이 글을 읽는 독자가 이제 개발자의 길을 시작한 사람이라면 고민해라, 소프트웨어 개발을 비롯한 모든 전문적인 직업들은 새로운 것을 배우고, 익히고, 소모하면서 계속 변화되는 것을 즐길 줄 알아야 재미있는 직업이다. 그런 것이 아니라면, 정말 힘들고, 피곤하고 어려운 것이 전문직과 같은 직업이다. 만일 그런 것이 힘들다면 다른 일을 알아보는 것이 현명하다.


소프트웨어 개발자들과 가장 비슷하게 일하는 웹디자이너들의 푸념이 있다.


‘낮은 급여에 야근은 허구한 날, 거기에. 불투명한 미래’에 대한 그들의 이야기를 들으면서, 흔히 소프트웨어 개발자들은 그 질문에 답변한다. ‘너희들은 모니터라도 크지’라고. 대부분의 프로젝트들은 ‘분석’에 의해서 ‘일정’을 만들지 않고, ‘일정’을 통해서, ‘품질’을 선택한다고 봐야 한다.


‘정말 하고 싶은 것이 무엇인가?’


개발자들에게 물어보면, 대부분 당황하는 경우가 많다. 이것은 개발자이기 때문에 답변을 못하는 것이 아니라, 자신의 비전이나 꿈에 대해서 명쾌하게 정의하지 못하고 있기 때문이다. 주변의 초보 개발자들에게 이야기하고 싶은 점은...


가끔은 수필집이나 여행기, 그리고. 다른 사람의 생각과 꿈에 대한 글을 많이 읽어보라고 권하는 것이다. 그러면, 그 비전과 꿈에 대해서 이야기해달라는 사람들이 꽤나 있고는 하다.


문제는 그 비전은 누가 정해주는 것이 아니라, 자신이 생각하거나, 자신이 발견하는 것이 옳지 않냐고 다시 이야기를 해준다. 물론, 이렇게 이야기하는 사람도 있다.


‘저는 이번 프로젝트에서 인정을 받아서, 다음 프로젝트를 수행할 때에는 팀장이 되고 싶어요!’라고 이야기할 수 있다. 하지만, 이런 ‘단기적인 비전’을 말하는 것은 아니다. 이런 ‘단기적인 비전’만을 따라가다 보면, 냉정하게 수단만 중요시 여기게 되고, 목적 자체를 잃어버린 인생의 방랑자가 될 가능성이 매우 크다.


내가 생각하는 ‘성공’이란 과연 무엇인가?


또 하나는, 그 ‘성공’의 목표를 너무 작게 가져도 문제이고, 너무 커도 문제라는 점이지만, 그래도, ‘꿈’과 ‘목표’가 있다는 것 자체가 재미있고, 신기하지 아니한가?


‘성공은 자신이 정한 것을 이루는 것’을 의미한다고.


그럼 ‘꿈’을 어떻게 정의하나요?


1. 10년, 20년, 30년 후의 자신의 모습을 상상해보고 정의해봐라.

2. 현재 내가 좋아하는 모든 것들을 적어봐라.

3. 내가 가장 잘하고 가장 인정받는 것을 적어봐라.


보통은 이렇게 끄적거리다 보면, 무언가가 조금은 구체적인 비전이 나올 수도 있지만, 아무렇지도 않은 것이 나올 수 있다. 하지만, 일단, 끄적이기 시작했다면, 다음번에는 좀 더 잘할 수 있다는 것이 중요하다. 가장 중요한 것은 ‘내가 비전에 대해서 생각하기 시작했다’는 점이다. 일단 작심 3일이라도 중요한 결정이다. 그것은, ‘결정’을 하고 ‘결심’을 하기 시작했다는 것이기 때문이다.


일단, ‘써야 한다’. ‘생각은 생각일 뿐이다’


주변의 개발자들이 가장 잘 못쓰는 말 중의 하나가 ‘머릿속에 다 있다’라는 말이고, ‘글로 쓰기에 너무 어려운 이야기’이다라는 이야기가 가장 잘못된 것이라는 것을 잘 모르는 경우가 많다.


‘머릿속에 다 있다’라는 이야기는 한번 생각은 해봤으나, 결론을 내리지 못하였다는 이야기로 들리고, ‘글로 쓰기 어렵다는 이야기’는 그만큼 정리가 안되고, 그 일에 대해서 잘 모른다는 이야기와 똑같다.


10년 20년 특정 도메인에서 일한 베테랑이라고 하는 개발자와 일을 할 때에, 자신이 하는 일은 너무도 복잡하여, 설계도나 다이어그램, 순서도, 타이밍 차트 등을 그릴 수 없다는 사람들이 있다.


그들과 이야기하고, 그 업무를 다이어그램과 설계도로 만들어 주어도, 그들은 그것 말고, 설명이 안 되는 그 무언가가 있다고 이야기를 한다. 물론, 필자는 그때에 이렇게  이야기해준다.


‘만일 그러한 것이 존재한다면. 그것은 당신만이 생각하는 경험이나 당신이 소중하게 생각하는 가치인지 모른다. 하지만, 그것은 어떤 지식이 되기에 매우 부족한 것일 수 있다. 지식은 설명하기 쉽고, 이해하기 쉬운 것이 지식이다. 설명하기 어려운 경험은 정규화되거나 전달되어지기 매우 어렵다’


더 쉽게 이야기하면. ‘쉽게 설명하거나 글자로 남기지 못한다면, 당신은 그것에 대해서 잘 알고 있지 못한 것입니다’


비전이나 목표 잡기가 너무 어려워요?!


그렇다면, 당장 휴일에 컴퓨터를 내버려두고, 아이폰이나 패드와 같은 스마트하다고 우기는 디지털기기를 집안에 던져두고 여행을 떠나는 것이 현명한 방법이겠다. 그리고, 다른 매체를 들여다보고, 개발자 이외의 사람들을 만나서 이야기해보라라고 권유해야 하는 것이 맞을  듯하다.


생각 이상으로 소프트웨어 개발자의 세계는 정말 좁다. 그리고, 단편적인 지식들과 단편적인 경험들만이 존재하는 세상인지도 모른다. 그래서, 소프트웨어 개발자들은 ‘관심의 폭을 넓히고,’ ‘자신을 확장’하는 것이 결론적으로는 더 뛰어난 개발자가 된다는 것을 나중에야 깨달을 것이다. 마지막으로 이야기한 한다면, 소프트웨어 개발자에게 ‘성공’이란 일단... 전혀 해보지 않았던 것을 도전해보는 것, 그리고. 삶은 소프트웨어 개발처럼 버전을 나누어서 설명하기 어렵다는 것을 이해하고. 무언가 계속 새로운 것에 도전한다는 것이 진정한 ‘성공’ 아닌가 한다.

관리자
2018-12-27 17:59
조회 190




* 국민대학교 소프트웨어융합대학 이민석 교수님께서 DEVIEW 2013에서 발표하신 자료 및 동영상입니다.








* 요약


- 개발은 문화적 활동과 같다. 책으로 문화를 공부할 수는 있지만 배울 수는 없다.

개발도 경험으로, 만들어 보면서 배워야 하는 것이다.

- 현대에는 오픈소스, github, google code, google play, StackOverflow 등

다양한 기회가 많으므로 잘 활용해야 한다.




관리자
2018-12-27 17:50
조회 143



어제 (2016년 7월 1일 게시) 거대한 세금이 들어간 모 국가 R&D의 의미 있는 결과물이 어쩌면 어설픈 마무리로 사장될 지도 모르겠다는 느낌이 들어서, 얼마 전에 페이스북에 적었던 소스 공개에 관한 글을 좀 더 정리한 내용입니다.

"please" 를 하는 심정으로 궁서체로 씁니다.









우선 사해동포주의적 관점에서 자신(개인, 회사)의 소프트웨어 코드 자산을 오픈 소스로 공개하는 것은 무조건 좋은 일입니다. 폴더 안에서 사장 될뻔한 그 코드가 단 한 사람의 누군가에게 유용했다면 아마도 그 결과가 지구를 구하는 일이 될 수도 있을 겁니다.

이 글을 읽으시고, 어딘가 폴더에 잠자고 있던 코드를 가지신 분, 특히 세금을 들여 개발하신 소프트웨어가 산업적으로 잘 활용되고 있지 않아서 이러지도 저러지도 못하고 계신 분들이 자신있게 소스를 공개하는 계기가 되면 좋겠습니다. 응원합니다.




일단 오픈소스를 한다는 것은 소스를 공개한다는 좁은 의미가 아니고, 포괄적으로 모든 것 (소스, 문서, 로드맵, 남아 있는 이슈, 뭔가 프로젝트에 관한 의사 결정 과정)을 공개하여 남들도 보고, 가져다 쓰고, 수정하고, 또 다른 사람도 쓸 수 있게 전달하며, 바라기는 프로젝트에 그 수정된, 개선된 내용을 거꾸로 기여하는 방식으로 참여할 수 있도록 열어 놓는다는 것이며 궁극적으로는 프로젝트가 커뮤니티에 의해 지속 가능한 발전을 할 수 있게 만든다는 것을 의합니다.

물론 그냥 소스만 공개해도 안 하는 것보다는 좋을 가능성이 높습니다.


프로젝트가 끝나서 코드를 안보게 되는 그 순간부터 그 소프트웨어는 기술 부채가 됩니다. 그 기술이 누군가에게 의미로운 것이라면 오픈하는 순간 부채에서 자산으로 바뀌어 새로운 생명을 얻게 됩니다.



공개할 때는 이 프로젝트가 시작된 동기, 해결하려는 문제, 그 기술적인 해결 방안과 함께 아마도 남아 있는 이슈(추가해야 할 기능이든 버그든)를 정리해서 같이 공개하는 것이 중요할 것입니다. 아마도 국가 R&D 결과물 또는 어떤 연구의 결과라면 동기, 문제, 해결 방안의 디테일은 당연히 제안서, 보고서 그리고 정량적 목표를 달성하기 위해 만들었던 논문, 사용자 매뉴얼 (API 문서), 특허 등등으로 이미 정리가 되어있을 거라고 생각합니다. 그걸 같이 공개하면 됩니다.


특히 아직도 진행 중인 프로젝트라면, 그 프로젝트의 소스를 공개하려는 의도는

  • 누군가 우리 프로젝트에 관심을 가지게 하고
  • 그 누군가가 자신의 일에 우리 프로젝트 결과물을 활용하게 하고
  • 외부 개발자가 우리 프로젝트에 참여하도록 유도하고
  • 동시에 커뮤니티의 리뷰를 통하여 프로젝트 결과물들의 품질을 개선하고
  • 더 산업 친화적으로 프로젝트의 방향성을 잡고
  • 우리 기술의 우수성이 세계 만방에 빨리 퍼지게 하여, 뭔가 비지니스를 도모하고
  • 프로젝트에 참여하는 개발자들이 커뮤니티에 노출되어 훌륭한 커리어를 쌓게 하고
  • 프로젝트 펀딩이 중단되도 커뮤니티에 의해 지속적으로 발전하도록 하고

등등 일 것입니다.




하여간 고맙게도 오픈을 하신다면 다음을 고려하시면 됩니다.





1. 소스는 full source를 공개하여야 합니다.


Full Source라 함은 프로젝트의 모든 소스를 의미하지 않습니다. 대개 핵심 기술 영역의 소스와 예제 소스를 build 가능한 형태로, build 방법과 함께 오픈합니다. 예제 소스(즉, use case)를 같이 제공하지 않으면 이 소스의 유용성을 알아차리기 쉽지 않기 때문입니다. Full source의 의미는 build해서 실행 가능한 소스를 의미합니다. 


* 이 장면에서 서랍에 처박혀 있던 오래 전 프로젝트들은 더 이상 build에 필요한 도구의 예전 버전을 구할 수가 없기 때문에 build가 현실적으로 불가능할 수도 있겠습니다. 



프로젝트의 모든 소스 100%를 공개할 필요는 없습니다. 언저리 소스도 나름 유용할 수도 있지만, 핵심 기술 부분을 공개하는 것이 중요합니다. 그래야 남들도 쓰겠죠. 특정 고객을 위한 모듈은 어쩌면 그 고객의 영업 비밀이 들어 있을 수도 있고, 또 고객과의 계약에 의해서 공개하지 않아야 할 수도 있겠습니다. 그런 문제가 없다면 다 공개하면 됩니다. 하지만 핵심 영역을 공개하는 것이 무엇보다 중요합니다. 커뮤니티 또는 다른 회사에서도 그 핵심 영역의 소스를 이용해서 비지니스를 할 수 있게 해야 합니다.


그럼 나는 뭐먹고 사냐고요? 핵심기술은 내가 만든 것이기 때문에 그 소스가 유용하다고 생각되면, 그 기술을 만든 나는 시장의 신뢰를 한 몸에 받습니다. 그건 꽤 짭짤한 기회로 이어지죠.




2. 핵심 기술과 관련된 문서를 같이 공개해야 합니다.


그 기술을 설명하는 논문 링크도 좋고, 그 기술을 설명하는 블로그도 좋고, 심지어 책이 있다면.. 하여간 그 기술을 설명하는 모든 리소스를 잠재적인 사용자에게 알려주어 자신이 나중에 엄한 걸로 고생하지 않겠구나 하는 생각이 들게 해야 합니다.



진행 중인 프로젝트라면, 그 프로젝트의 Architecture (전체 환경, 계층적 구조...), 응용 예 등등을 블로깅하는 것이 좋은 방법입니다. 포럼, 메일링 리스트를 열어 내부 개발자들과 커뮤니티의 개발자, 사용자들과 소통해야 합니다.



당연히 API 문서가 필요합니다. man page 수준의 대단한 것이면 좋겠으나 doxygen 등으로 생성된 것도 충분히 유용합니다. *doxygen 사용법  <-- 링크 




3. 아직도 할 일이 많은 (진행중인) 프로젝트라면


프로젝트 roadmap이 커뮤니티에 공유되어야 합니다. roadmap이 아주 세부적인 거창한 것이면 좋겠지만, 다음 릴리즈 계획 (언제, 그 안에 어떤 기능이 포함될 것인지), 장기적으로 고려하고 있는 기능들을 간략하게 정리한 것이어도 됩니다. 프로젝트를 리드하는 그룹의 고민을 이해해야 외부의 개발자들이 contribution을 할 수 있습니다. 



또 외부의 도움이 필요한 영역을 밖에 알려주면 큰 도움이 됩니다. 예를 들면, 이런 시스템에서의 test가 필요하다, 이런 환경에 build를 도와주면 좋겠다, 이런저런 feature를 만들어 주면 좋겠다, 이 문서를 여러 언어로 번역할 사람이 필요하다 등등입니다.




4. 공개하기 전에 라이선스를 정합니다.


이 쪽은 복잡한데, https://www.olis.or.kr/ossw/license/compareGuide.do  에 보시면 다양한 오픈소스 라이선스가 제시되어 있습니다. 또 세상의 모든 의미있는 오픈소스 라이선스 목록이 OSI(Open Source Initiative) 홈페이지, https://opensource.org  에 있습니다.  보통은 permissive한 (막 가져다쓰고, 수정된 부분을 공개하지 않아도 되는) 라이선스가 좋습니다. 그래야 더 많이/빨리 프로젝트를 확산시킬 수 있습니다.


제 개인적인 생각으론 MIT 라이선스가 대부분 오픈 정신에 적당합니다. 완전 교육적 비영리적 성격의 이용만을 허용하실 참이라면 GPL(copyleft) 라이선스류를 선택할 수도 있습니다. 회사에서 만든 것라면 Apache가 잘 맞는다고 하는 사람들도 많습니다. 그 차이는 앞에 언급한 설명 문서를 보시고 결정할 수 있습니다.




5. 특허가 내재되어 있다면 약간 더 생각을 합니다.


소스를 공개한다는 것은 대개, 그 소프트웨어 내재된 특허를 무상으로 사용할 권리를 같이 제공한다는 것을 의미합니다. 또 라이선스에 따라 내가 오픈한 소스를 가져다 쓴 쪽에서 다른 특허 기술을 섞어 다시 오픈 소스로 배포할 때, 그 추가된 특허 권리의 제한에 관한 조건이 있습니다. 이런 특허 관련 이슈가 소스를 오픈하지 않으려는 중대한 이유가 될 수도 있습니다.


우선 서랍 깊은 곳에서 썩고 있는 프로젝트는 그 특허가 별 가치가 없다는 것을 이미 증명하고 있는 것이므로 문제가 안 될 것입니다. 지금 active하게 개발되고 있는, 또는 최근에 마무리된 프로젝트의 특허라면 냉정한 특허 가치 평가가 먼저 있어야 하겠습니다.


또 로열티를 지급받는 방식만 기술이 돈으로 바뀌는 것이 아니라는 사실을 생각을 하시면 좋겠습니다. 기술은 그 본질적 가치, 그것을 시행할 때의 가치, 그 기술이 내게서 만들어졌다는 사실이 내포하는 가치 등 여러 면을 가지고 있습니다.




6. 어디에 공개할지 결정합니다.


당연히 github를 강력 추천합니다. 2016년 6월 현재 1,400만 명 이상의 개발자가 Github에 모여있습니다. 또, 별도의 서버를 유지할 여력이 없는데 우아한 프로젝트 안내 페이지가 필요하면 github.io 홈페이지를 이용합니다. (github.io 검색하시면 많은 도움글이 나옵니다.)

다운로드 가능한 tarball 보다 github 라파지터리에 공개하는 것이 좋은 이유는 커뮤니티와의 인터랙션을 github이 잘 지원하기 때문이며, 밖에서 볼 때 이 프로젝트에 기여를 할 수 있겠구나 하는 느낌이 들기 때문입니다. 


그리고 이 프로젝트에 참여했던/기여하는 사람들의 그 늠름한 활동들이 그대로 보여서 그들의 커리어에 큰 도움이 될 수 있기 때문입니다. 이 커리어 개발에 도움이 된다는 장면이 개발자들이 금전적 대가없이 오픈소스에 참여하는 세 번째 이유입니다.  (첫 번째 이유는 뭐냐고요? '재미'이고요. 두 번째 이유는 나도 그 멋진 프로젝트에 참여했다는 'pride' 입니다.)




7. 홍보를 합니다.


소스를 공개한 시점부터는 심하게 홍보하는 것이 중요합니다. 내 소프트웨어가 얼마나 유용할지는 결국 사용자가, 내 소스를 이용해서 더 멋진 것을 만들려는 개발자들, 내 소스를 제품/서비스에 사용하려는 훌륭하신 분들이 증명합니다.


해서 그럴 기회를 만드는 것이 결국 홍보입니다. 페이스북, 관련 커뮤니티 사이트 등등에 열나게 홍보하는 겁니다.  홍보는 기술에 대한 홍보보다는 사용 사례에 대한 홍보가 훨씬 더 효과가 있을 겁니다. 



공개된 소스는 보통 여러 개의 모듈(컴포넌트)로 구성될 텐데, 핵심적인 부분도 중요하지만, 안에 있는 주변 모듈들이 또 다른 오픈소스에 붙었을 때 어떻게 되는지 (즉 부산물의 유용성)를 보여주는 것이 효과적일 수도 있습니다. 묻어가기를 하는 거죠.



적극적인 홍보는 더 큰 도움이 됩니다. 내 프로젝트와 연관성이 있는 이미 성공한 큰 프로젝트의 컨퍼런스, 워크샵, 커뮤니티 모임에서 그 프로젝트와 내가 공개한 핵심기술과의 연관성, 내 결과물이 그 성공한 프로젝트를 얼마나 더 유용하게 만드는지, 내 프로젝트의 부산물만 써도 이런 식으로 좋다 등등의 발표를 함으로써 내 프로젝트를 다른 커뮤니티에 알리는 겁니다.


홀로 있는 내 프로젝트는 사람들이 찾아보기가 어렵습니다. 어딘가에 기대서 서 있는 것이 좋겠죠. 그 다른 프로젝트가 아주 핫한 프로젝트라면 더욱 효과가 좋겠죠. 그 핫한 프로젝트와 내 프로젝트가 연동되어 의미있는 결과룰 내주는 간단한 (따라할 수 있는) 예제 프로그램을 같이 설명하면 더 좋겠고요.



사용자 수준에서 유용한 실행파일, 라이브러리(사용자=개발자)가 제공된다면  Wikipedia의 'List of Open Source Software Packages' article에 등록하는 것도 방법입니다. Wikipedia는 누구나 수정할 수 있습니다. ID를 만들어 내가 등록하면 됩니다. (관리자, 또는 다른 리뷰어가, 내 프로젝트가 백과사전에 올라갈 만 하지는 않다고 심각하게 생각하면, 내 프로젝트가 리스트에서 삭제될 수도 있습니다.^^)




8. 공개하고, 어떤 일이 벌어지는지 봅니다.


무려 공개를 했는데도 아무 일이 안 벌어질 가능성이 높습니다. 홍보를 하지 않으면 더 그렇습니다. Github에는 3,500만개의 리파지터리가 있고 그 가운데에서도 뜨는 프로젝트는 극히 일부입니다. SourceForge에서도 그랬습니다. 대부분 동기가 부족한 프로젝트는 공개한다 해도 그렇게 잊혀집니다. 하지만 당신의 프로젝트는 당신이 믿는 중차대한 동기를 가지고 꽤 많은 세금을 들여 개발된 훌륭한 것입니다. 분명히 잘 될 겁니다.



가끔은 기대하지 않았던 반응이 기대하지 않았던 곳에서 오기도 합니다. 누군가 관심을 보인다면 참으로 친절하게 대해줍니다. 뭔가 기여를 해준다면 심심한 감사를 표해야 하고, 도와줘야 합니다.


그의 기여가 부실하여 채택하기 어렵거나 내 프로젝트의 품질을 떨어뜨리는 것이라면, 그 기여 내용이 더 개선된 모양이 될 수 있도록 기술적인 지원을 해주면 좋습니다. 나도 그런 시절이 있었다는 생각을 하셔야 합니다. 누군가 강력한 기여를 지속적으로 해온다면, 그에게 프로젝트 운영/관리에 관한 더 높은 권한을 주는 것을 고려합니다.




* 한 발 물러서서, 저자는 이 글에 대하여 법률적 책임을 지지 않습니다. 제가 변호사 변리사가가 아닌 관계로 라이선스, 특허와 관련한 이 글의 해석은 정답이 아닐 수도 있습니다. 하지만 공개하는 쪽(이용하는 쪽이 아니라)이라면 라이선스 또는 IP 위반에 관한 걱정을 거의 안 하셔도 됩니다.


또 공개를 하실 프로젝트와 관련하여 아주 특별한 뭔가가 있다면 예외적인 특수한 상황이 발생할 수 있겠습니다. 특히 모든 리스크에 민감한 큰 회사의 경우에는, 어떤 이유에서든 지켜야할 내부의 지적 자산들의 보호를 위한 작전과 고민이 먼저 있어야 할 것입니다.





이민석 교수님 블로그 - 쉽게 살 수 있을까 ?  
관리자
2018-12-27 17:39
조회 62

아이가 소프트웨어를 하겠다고 하면 아직도 많은 부모들은 걱정부터 든다. 이런 부모님들을 위해 국민대학교에서 학부모 간담회를 마련했다.

개인적으로는 이런 행사를 예전부터 가지고 싶었으나, 기회가 잘 만들기가 쉽지 않았던 차에, 국민대학교가 OSS (Open Source Software) 개발자 포럼과 방학 때마다 진행하는 청소년 소프트웨어 캠프의 부대행사로 학부모 간담회가 진행되었다.

이번 간담회는 2017년 1월 5일~8일 열린 겨울 캠프의 첫날인 1월 5일, 점심 식사와 함께 진행되었으며, 온오프믹스를 통하여 캠프 참가 학생 가운데 원하시는 부모님 뿐만 아니라 일반 학부모, 교사 등 누구나 참석 신청할 수 있도록 하였다.

결론적으로 간담회에는 총 30명 가량의 부모님들이 참석하였다. 어머니가 주로 오실 것으로 예상했으나, 아버님들도 꽤 많이 오셔서 소프트웨어 교육에 대한 높은 관심을 보여주셨다.






간담회는 입시설명회가 아니기 때문에 비교적 여유로운 분위기에서 진행되었다. 우선 내가 소프트웨어 진로 선택이 그리 나쁘지 않을 수도 있다는 설명을 다음 슬라이드로 하였다.




위 슬라이드는 [여기]에서 다운로드할 수 있다. 

(6번 슬라이드의  OECD 국가들의 평균 근로시간 그래프가 있는데, 이 그래프를 어떤 신문에서 인용했으나, 한국의 근로시간은 잘못된 값으로 확인되었습니다. 하지만 맥락을 이해하기 위하여 그냥 두었으며. 실제 OECD 평균 근로시간 통계는 [여기]에서 찾을 수 있습니다. )




설명에서는 주로, 소프트웨어 산업이 어떻게 바뀌어 왔는지, 최근에 소프트웨어에 큰 무게가 실리는 이유는 무엇인지, 그 결과 소프트웨어 교육이 왜 중요하고 무엇을 가르치려하는지, 소프트웨어 개발이라는 것이 무엇이고, 개발자가 가져야할 역량은 무엇인지를 이야기하였다.

물론 결론은, 우리의 자녀들이 소프트웨어 진로를 선택하거나, 소프트웨어 개발에 시간을 많이 쓴다해도 별로 걱정할 필요가 없다는 생각을 하셨으면 좋겠단 것이며, 오히려 자랑스러운 일이 될 것이라는 내 소박한 바램이자 믿음을 전하려고 노력하였다.


한 시간 정도의 설명이 끝나고 한 시간 반 이상 질의 응답이 이루어졌다. 어떤 부모님은 본인이 소프트웨어 개발에 종사하셨거나 지금도 개발을 하고 계시다고 하셨으며, 다른 부모님들에게 팁을 주시기도 하셨다.








다음 내용은 주요 Q&A이다. 혼자 Q&A를 했던지라.. 잘 모르거나, 확신이 없는 대답도 조금 있었음을 양해 바란다.



Q1 : 조카가 심리학을 전공하고 싶어함, 고2인 조카에게 코딩 교육에 대한 중요성을 아무리 얘기해도 이해하지 못함, 어떤 연관성으로 추천을 해야 조카에게 이해시킬 수 있을지


A : 심리학과에서는 통계적 방법론이 많이 사용되고 있음. 즉, 통계 소프트웨어 도구를 잘 이용하거나, 어떤 상황에서는 데이터를 모으고 정리하여, 유의미한 결과를 얻기 위하여 새로운 방법론이 사용되는 경우, 프로그램의 작성이 필요할 수도 있음.

심리학이나 특정 전공 분야에 관심이 있다면 그 분야의 문제를 해결하는데 사용되고 있는 소프트웨어, 또는 소프트웨어적인 방법론에 관한 자료를 인터넷에서 많이 찾을 수 있고, 그 결과를 확인하는 것은 소프트웨어 또는 코딩 교육에 대한 중요한 동기가 될 수 있음.




Q2 : 개발자가 많이 부족하다고 말했다. 해마다 매우 많은 소프트웨어 전공 졸업생이 배출되는데 언제쯤 수요와 공급이 역전될거라고 생각하는지


A : 현재 산업의 발전 방향을 보면, 개발자의 공급이 수요보다 더 많아지는 시점은 가까운 시기에는 오지 않을 것으로 예측됨. 더 많은 제품, 서비스, 산업이 점점 더 소프트웨어에 의존하고 있기 때문에 지속적으로 더 많은 개발자가 필요함.

일부 학생들은 대기업이나 이름이 알려진 소프트웨어 업체에 취업을 하려고 준비하고 있고, 대기업 취직에 실패하는 경우 휴학이나, 졸업 유예를 하는 경우가 있으나, 그런 회사들은 요즘에 신입 개발자를 거의 뽑지 않음.

부모님들에게도 이름이 잘 알려진 큰 회사에 가면 좋으나, 현실적으로는 좋은 스타트업, 중소기업에서 잘 배우는 것이 더 바람직한 경우가 많음. 이를 위해서는 학생, 학부모 모두 회사를 보는 눈을 키워야 함.




Q3 : 아이가 소프트웨어 관심이 있는데 하루에 한 시간 정도 코딩에 시간을 쓰며, 모 고등학교에서 운영하는 영재원에 다님. 개발자로서 대학을 졸업하지 않아도 기업에 갈 수 있는지


A : 아마도 학벌(대학이름)은 지금의 교육체계에서 고등학교 교육을 접하는 학생의 성실성을 확인하기 위한 것임. 이제 소프트웨어 개발자에게 대학의 이름, 특히 대졸 여부는 큰 의미가 없어지고 있음. 고졸 신입으로도 대졸 신입 연봉을 능가하는 연봉을 받는 개발자 살례도 적지 않음.

아직도 대기업과 큰 중소기업들은 이해할 수 없는 수준의 학력별 임금 편차가 존재하는 것도 사실이지만, 그런 회사도 입사 때만 그런 조건이 적용될 뿐, 1~2년 지나면, 또는 그 경력을 가지고 회사를 옮기면 평가에 따라 그에 역량에 합당하는 연봉을 받게 됨. 시장에서는 소프트웨어 개발자가 절대적으로 부족하기 때문에 회사가 저임금으로 역량있는 개발자를 묶어둘 방법이 없음.




Q4 : 중학교 1학년 여자아이인데, 진로를 찾다가 IT쪽을 해보고 싶다고 함. 아이가 특성화 고등학교를 가고 싶어 하는데 S/W 특기자 전형으로도 대학을 진학할 수 있는 비율이 어느 정도 되는지


A : 대학마다 (수시) 입시는 차이가 많아서 일반적으로 이야기하기는 어려움. 특성화고 졸업생을 위한 별도의 전형을 유지하는 대학은 줄어들고 있는 것으로 보임. 하지만 특성화고의 경우, 자신이 간절히 원하는 것을 훨씬 더 잘 할 수 있는 환경으로 수시 입시에서 유리한 측면도 많음. 국민대학교의 경우, 입학사정관 전형의 경우 특성화고 학생들의 지원이 증가하고 있으며, 실제 합격하는 경우도 많음.




Q5 : 나이가 있는 사람이 이직을 하거나 새롭게 소프트웨어 분야로 접근할 수 있는 세부 분야가 어떤 것이 있는지


A : 기술과 시장 그리고 본인의 취향을 분리하여 이야기 해야 하고 사람마다 편차도 매우 큼. 보통 기술적으로는 시스템 분야가 애플리케이션 분야보다는 어렵다들 많이 함.

프로그래밍 언어는 보편적으로 파이썬이 비교적 쉽게 배울 수 있음. 전혀 상관이 없는 전공이었다면 스크래치와 같은 도구로 과연 코딩이라는 것이 어떤 것인지 맛부터 보는 것이 필요할 수 있음.

보통 소프트웨어를 공부하는 단계는 언어를 가장 먼저 배우고, 데이터라는 것을 구조적으로 이해하는 과정, 운영체제와 라이브러리를 활용하고 그런 것들도 누군가에 의해 만들어진 소프트웨어라는 것을 이해하는 과정, 알고리즘을 바탕으로 효율적인 소프트웨어를 만들어내는 과정, 많은 데이터에서 어떤 인사이트를 얻어내는 과정을 겪으며 소프트웨어를 배우게 됨.

(이 과정은 [소프트웨어 배움의 단계]에 자세한 설명이 있음) 




Q6 : 고1 아들이 소프트웨어에 관심이 있는데 특기자 전형을 준비하려면 코딩 수준이 신입 개발자정도 되야한다고 들었는데 어느정도 수준이 되어야 특기자 전형으로 들어올 수 있는지


A : 고등학생이 소프트웨어에 시간을 쓸 수 있는 한계가 있기 때문에, 그렇게 해주면 좋겠지만, 아마도 대학에서는 대학 입시 시점에 엄청난 무언가를 만들었을 것이라고 기대하지 않음.

어떤 문제를 소프트웨어로 해결했고, 그 과정에서 어려운 점은 무엇이며, 그 해결 과정에서 무엇을 배웠는지가 중요함. 어차피 공부는 스스로 해야하는 것이기 때문에, 대학들은 잘 배우는 학생을 가장 선호함.

이를 위해서는 과제가 아닌 자기 프로젝트를 하는 것이 중요하고, 자신이 만든 결과물을 Github과 같은 곳에 공개하고 Google Play에 올리거나, 자신의 주변에라도 소개하여 피드백을 받아보는 것이 중요함.

실제 입시 전형과정에서는 면접때 아주 짧은 시간의 질의 응답만으로도 지원학생의 소프트웨어 개발 경험에 관한 열정과 진정성을 확인할 수 있음. 이 과정에서 자기소개서는 매우 중요하며 [자기소개서 쓰는 법] 글이 도움이 될 것임




Q7 : 대학을 안 갈 수는 없으니 수학 등 다른 교과목의 공부도 해야 하는데 아이는 프로젝트들을 많이 하고 싶어함. 현실적인 문제인데 어떻게 해야 하나


A : 정답은 없음. 그런데 우리가 봤던 학생들은 대부분 다 알아서 잘 함. 장기적으로 봤을 때 그냥 하고 싶은 것을 하게 놔두는게 더 좋지 않을까 싶음.

다만 쉬운 프로젝트라도 끝까지 해보는 것이 중요하며, 자신이 뭘 하고 있는지, 그 프로젝트에 얼마나 시간을 쓰고 있고, 결과를 만드는 과정에서 뭘 배웠고, 그 결과물이 무엇이면 어떻게 평가를 받고 있는지를 기록하게 하는 것이 중요함.

그 다음 그 기록을 펼쳐놓고 스스로 생각해서 과연 이것이 내가 하고 싶었던 것인지도 다시 생각해보고, 부모님과 이야기 해보면 더 효과적이면서도 효율적으로 시간을 보낼 수 있을 것으로 생각됨.




Q8 : 개발자들이 많이 모여서 소통하는 커뮤니티가 어디인지 궁금


A : 지금은 페이스북 그룹을 통해서 커뮤니티 모임이 생각보다 많이 이루어지고 있음. 국민대학교와 캠프를 같이 진행하는 OSS 개발자 포럼 이 우선 첫번째 커뮤니티가 될 수 있고, 거기에서 다양한 커뮤니티를 찾을 수 있음. 또 온오프믹스에서 주요 관심사를 키워드로 검색하면 관련 커뮤니티 모임을 어렵지 않게 찾을 수 있음.

지금은 커뮤니티가 잘 되고 있는 시기이며, 많은 사람들이 다 경험했기 때문에 처음 오는 친구들을 어떻게 대해 줘야하는지도 잘 아는 편임. 그래서 낯선 커뮤니티에 처음 간다해도 예전만큼 뻘쭘하지는 않음.




Q9 : 요즘 대학에서는 어떻게 실습을 하는지, 실습 환경이라든지, 궁금


A : 학교마다 다르겠지만, 국민대학교는 기본적으로 리눅스 환경에서 모든 수업과 실습이 진행됨




Q10 : 대학에서 필수적으로 가르치는 언어가 무엇인지


A : 시장에서는 게임 클라이언트쪽에서는 주로 C#, 서버쪽은 C++, 웹서비스는 Java, JavaScript가 많이 사용되고 있음. 또 모바일에서는 Java, Swift 등이 사용됨. 그리고 모든 분야에서 Python이 풍부한 라이브러리 덕에 많이 사용되며, 비교적 배우기도 쉬어서 전공, 비전공 구분없이 여러 대학들이 1학년때 첫번째 프로그래밍 언어로 가르치고 있음.

소프트웨어 전공학과에서는 Java, C++ 등 언어를 가르치는 수업이 한두개 더 있으며, 다른 많은 언어들은 학생들이 필요에 따라 스스로 배우게 됨. 한 가지 프로그래밍 언어에 익숙해지면, 다른 언어는 비교적 수월하게 배울 수 있으며, 실제 소프트웨어 개발자들은 프로젝트에 따라 새로운 언어를 배우는 경우가 많고 여러 프로그래밍 언어를 사용할 수 있음.




Q11 : 공학인증제도에 대한 의견


A : 공학인증 제도는 공학 교육을 성과 중심적으로 체계화하는 장점이 있으나, 학습 부담이 좀 많아서 학생들 교수들 사이에서도 찬반론이 있음. 소프트웨어 분야는 공학인증체계가 학생들에게 부담이 다소 적어지도록 구성 되어 있고, 거기에 더하여 국민대학교를 포함한 여러 학교들이 공학인증 요건을 만족하면서도 꼭 필요한 내용만을 담아내는 커리큘럼을 만들려고 노력하고 있음




Q12 : 파워포인트, 한글 등을 가르치는 것에 대한 교수님의 생각


A : 업무 생산성을 높이는 소프트웨어 도구는 배워두면 좋지만, 학원에 다니면서 ITQ 등 자격증을 따야할 필요까지는 없다고 생각함. 그런 자격증과 소프트웨어 개발 능력과는 상관 관계도 별로 없음.




Q13 : 소프트웨어 분야를 추천은 하는데 공부를 많이 해야 해서 기피도 한다. 이런 것에 대한 의견 궁금


A : 실제로 기술이 빠르게 변하기 때문에 학습을 지속적으로 해야하는 분야임. 학교에서는 높은 학점을 얻기 위한 공부가 중요한 것이 아니라, (개인) 프로젝트 때문에 힘들어야 실제로 개발자로 나가서도 재미있게 개발을 할 수 있음. 취업 후에도 업무에 재미를 느끼고, 더하기 위하여 새로운 것을 공부해야함. 한 번 배운 것 가지고 평생 써먹을 수 있는 직업이 많지도 않지만, 그런 직업 중에 직업 안정성(Job Security)이 높은 것이 있는가? 아마 소프트웨어 개발보다 더 재미있고 창의적으로 오래동안 유지할 수 있는 직업은 거의 없을 것.




Q14 : NCS와 현재 커리큘럼이 어느 정도 비슷한지, 실제 업무와 맞춰서 커리큘럼이 진행되는지


A : 소프트웨어 업계에서는 SI분야(전산화 업무를 주로하는 영역)를 제외하고는 소프트웨어 개발자를 등급으로 구분하는 NCS를 신뢰하지도 않고 그 체계에 맞춰서 교육을 하는 대학도 거의 없음. 소프트웨어 분야는 자격증이 통하지 않는 분야임. 소프트웨어 분야에서 NCS는 개발자를 등급화하여 임금을 차이를 두고자 함이 중요한 목적 가운데 하나라고 개인적으로 생각하는데, 아주 빠르게 발전하는 분야에 그런 등급화 과정이 큰 의미를 가지지 않음




Q15 : 대학의 소프트웨어 교육에 코딩 위주의 교육이 맞는건지, 소프트웨어 소양 교육도 필요하다고 생각하는지


A : 대학 수준에서는 소프트웨어 소양(Computation Thinking, 소프트웨어적 소통 능력)도 중요하지만 모든 전공에 소프트웨어 교육은 코딩 경험이 중요하다고 개인적으로 생각함. 소프트웨어가 세상의 거의 모든 문제에 대한 최고의 문제 해결도구이기 때문에, 모든 전공에서 코딩을 통한 문제 해결 경험은 향후 각 전공 영역에서 학습, 연구, 협업 등에서 큰 도움이 될 것임.







* 간담회에 참석해주신 부모님들에게 감사드린다. 더 다양한 질문에 대하여 권위 있는 답을 드릴 수 있도록 여러 전문가들을 모시는 간담회가 필요함을 느꼈다.


* 이 질의 응답 내용은 국민대학교 컴퓨터공학부의 장명규 학생이 현장에서 정리하였으며, 더 명확하게 답을 전달하기 위하여 약간의 수정과 보완을 하였다.




이민석 교수님 블로그 - 쉽게 살 수 있을까 ?
관리자
2018-12-27 17:16
조회 154
* 이 글은 조금 길다. 바쁘신 분은 아래 1번 섹션 두 번째 문단과 2번 섹션만 읽어도 된다.





학교에 입학을 위한 원서나 회사에 취직을 하고자 할 때 이력서를 제출하는 경우, 대개 자기소개서(약어로 자소서, 학업계획서, 에세이 등등으로 불리는)를 같이 요구한다. 어떤 조직은 다른 서류 없이 자기소개서만 요구하기도 한다. 이 글에서는 자기를 소개하는 자기소개서 쓰는 법을 내 맘대로 설명하고자 한다.


이 글에는 '예시'가 없다. 왜 예시가 없냐고? 자기소개서는 자기 이야기를 써야하니까 모범 답안이 있을 수 없다. 구글에 찾아보면 잘 쓴 자기소개서가 100만 개는 나온다. 자기소개서를 유료로 파는 사이트도 있다. 그 가운데 99만 9천 875개 정도는 쓰레기이다.

왜? 나랑 그 사람은 다르니까. 자서전이 아니기 때문에, 아주 잘 쓴 다른 사람의 자기소개서에서 얻어야 하는 것은 그 사람의 경험이 아니라 그 자기소개서가 어떻게 읽는 사람을 몰입시키는지에 관한 것이어야 한다.


이 글을 비판적으로 읽으시는 분들을 위한 사족: 사실 난 글쓰기 선수가 아니다. 당연히 글쓰기 강좌들 들은 적도 없고, 등단 수준은 고사하고, 학급 단위의 글 뽐내기 대회에서조차 상 받은 적 없다. 초딩 때, 그리고 2-30대 초반까지 일주일에 두어 번, 잘해야 열 줄 정도 일기 써봤고, 기사나 잡지용 글을 요청 받으면 며칠 동안 머리 쥐어짜면서 쓰고, 긴 글은 대개 민간인용이 아닌 논문 밖에 써본 적이 없다.

따라서 이 글은 자기소개서를 수려하게 쓰는 법이 아니라 기술적으로 맞게 쓰는 방식을 제시하는 글이다. 아래 내용 가운데 불편한 부분이 있다면 틀렸다 하지 마시고, 이 방법이 더 좋다고 댓글도 다시고, 기가 막힌 방법이 나열되어 있는 링크도 붙여주시고 하시면 좋겠다. 감사하다.










1. 자기소개서를 쓰는 이유와 기본 초식


자기소개서를 쓰는 이유 다시 말해 상대 조직이 내게서 자기소개서를 원하는 이유는 나를 잘 파악하기 위함이다. 어떤 조직이든 조직의 이익을 위해 잘 일할 수 있거나, 학교라면 그 조직이 제공하는 서비스에 잘 부합하는 사람을 원하기 때문에, 그 조직의 선발 인재상과 맞는지를 자기소개서를 통해 확인하고자 한다. 인재상이란 똑똑한지, 잘 배우는지, 성실한지, 자기주도적인지, 리더십이 있는지, 목표중심적인지, 착한지, 항상 행복한지 등등 수도 없이 많다.

그런 것은 이 글에서는 논외이다. 그 인재상을 확인하기 위하여 자기소개서를 요구할 때 대개 '주제'가 주어지는 경우도 많다. 특히 입시 상황에서는 더욱 그렇다. 가끔 '자유롭게' 쓰라고 하는 경우도 있지만 그것을 '우리가 원하는 인재상과 맞게 아주 잘' 이라고 읽어야 한다.

자기소개서에서 원하는 것이 무엇인지를 알지 못한다면 당연히 자기소개서를 잘 쓸 수도 없다. 조직 입장에서는 물론 자기소개서가 다는 아니고, 다른 포트폴리오를 가지고 아주 드라이하게 지원자의 기술적인 역량을 당연히 같이 평가하며, 인터뷰를 통해 자기소개서에서 확인이 안 된 부분, 미심쩍은 부분에 대한 검증을 하게 된다.


결론적으로 자기소개서는 말 그대로 자신을 소개하는, 그것도 잘 소개하는 글이어야 한다. 자기를 '잘' 드러내는 방법은 자기소개서를 읽는 사람이 '내'가 되도록 하는 것이다. 자기소개서는 읽는 사람이 반드시 끝까지 읽고, 내 경험을 같이 느끼고 감동을 해야 하는 글이다.

즉, 자기소개서를 읽는 평가자가, 나로 '빙의해서' 읽고 난 뒤, 마치 자기가 내 문제를 고민하고, 자신이 해결한 것과 같은 뿌듯함을 느낄 수 있어야 한다. 그 '빙의' 과정이 없다면, 자기소개서가 아니라 '남의 소개서'가 된다.

그 많은 소설 중에 성공적인 작품이 몇 개나 있는지 생각을 해보시라. 내 이야기면 몰라도 남의 이야기가 재미있으려면 정말 기가 막히게 써야한다. 재미없는 '남의 이야기'를 끝까지 읽는 것은 큰 고통이다.


대개 자기소개서를 작성할 때, 이전의 경험과 그 경험을 통해 얻어진 역량을 기술하게 된다. 평가자가 그 글을 읽는 과정에서 나로 '빙의'가 되려면 그 경험이 사건의 흐름이 아니라 사고(思考)의 흐름에 따라 서술되어야 한다. 자기소개서가 나를 설명하는 글이 아니라, 나를 돌아보는 글이어야 하는 것이다. 사건의 흐름에 따라 글이 적히면, 읽는 사람은 다분히 관찰자 입장이 된다.


이 장면에서 핵심 키워드는 '빙의'이다. 읽는 사람의 입장과는 완전 다른 것이다. 가끔 '손 탄' 자기소개서를 보면 다분히 읽는 사람의 입장에서 쓴 글이 많다. 읽은 사람의 입장은 그저 기술적으로 (문법적으로, 단어의 선택에 있어서) 편한 글이어야지 관점의 문제는 전혀 아니다.


사실 위에 이야기한 '빙의' 모드의 글은 글을 원래 잘 못 쓰는 사람에게는 정말 어려운 것이다. 나를 잘 모르는 다른 사람에게 내 자기소개서의 평을 받아보면 바로 '빙의' 모드가 동작했는지를 확인할 수 있다. 하필 그 다른 사람이 약간의 재능이 있다면, 내 글이 '빙의' 모드가 아닌 '관찰자' 모드가 된 이유도 이야기해 주기도 한다. (사람이 하는 모든 일은 리뷰가 중요하다)




2. 자기소개서에 경험을 기술하는 방법


어떤 활동을 자기소개서에 기술함에 있어서 다음의 내용이 기술되어야 한다. 대개 자기소개서는 글자 수의 제한이 있기 때문에 다음 내용을 짧고 강하게 써야하는데 그건 각자 알아서 하셔야 한다. 선천적인 글쓰기 재능이 있으면 좋겠지만, 대개는 여러 차례의 리뷰로 다음 내용이 잘 기술되는 짧고 강한 글로 훌륭하게 개선된다.


A. 왜 그 활동을 하게 되었는지. (아마도 자기주도적인) 그 활동을 유발한 내적동기(intrinsic motivation)가 중요하다. 내적동기의 최고봉은 '재미', '지적호기심' 되시겠다. 가끔은 외적동기도 중요하지만, 그 외적동기에서 시작된 일이 어느 순간 내적동기로 바뀐 경우도 자기소개서의 좋은 활동 아이템이 된다.

끝까지 '억지로' 했던 활동은 보통 자기소개서 주제가 아니다. 나도 동의가 안된 일로 남을 ‘빙의’시키는 것은 불가능하다. 보통 내적동기는 가슴뛰는 '열정'을 낳고, 곧 자기도 모르게 그것을 하고 있는 자신을 발견하게 만든다.


B. 앞의 왜? 에 대한 답을 채워나가는 과정과 그 과정에서 어떤 배움(깨달음)을 얻었는지가 드러나야 한다. 이 과정을 우리는 '몰입' 이라고 한다. 모든 과정이 아주 수월하게 진행되었다면 그 활동은 아마 기억에도 잘 없을 것이다. '그냥 하다보니 노벨상을 탔어요' 이런 건 없다.

중간에 발생한 문제를 해결하고, 장애물을 넘는 과정이 항상 따른다. 그저 열심히 해서 해결되는 것은 우리가 '문제', '장애물'이라고 부르지 않는다. 문제 해결에는 반드시 뭔가를 배우고 생각하고 결정을 하는 과정이 포함된다.


C. 대개의 활동은 뭔가 결과물이 있다. 당연히 그 결과물을 기술한다. 그것이 '올림픽 금메달'이나 '노벨상'이라면, 그 과정에 어떤 일이 있었을지 너무나 명확하다. 설명이 필요없다. 그런데 우리에게는 뭔가 '상'자가 붙은 결과가 없는 것이 대부분이다. 상관없다. 중요한 것은 내 활동의 결과를 다른 사람에게 보여주고, 어떤 평가를 받고, 또 내 스스로 평가를 하는 과정에서 배우고, 그 결과를 개선한 내용을 기술하는 것이다. 그 과정을 우리는 '진정성' 이라고 부른다.


D. 그리고 마지막으로 그 활동이 내 삶과 나를 둘러싼 커뮤니티에 어떤 영향을 끼쳤는지 적어야 한다. 사람은 누구나 착하게 살고 싶기 때문에 커뮤니티가 추구하는 가치에 대한 인식은 모든 읽는 사람들에게 '나도 그래, 그렇게 해야 돼' 라는 동질감을 준다.




3. 자기소개서에 쓸 만한 경험이 우리에게 있는가? 


자기소개서를 처음 쓰는 사람이 가지는 첫 번째 질문은 그런 경험이 내게 있나? 하는 것이다. 많은 사람은 첫 번째 자기소개서를 쓰는 시점에 '난 그냥 살아왔어' 라는 생각이 든다. 그런 분들은 자기소개서 쓰기 전에 지나온 날들을 차근히 정리하는 시간을 가져야 한다.

최저임금을 받으면서 했던 알바, 근로학생, 학교에서 억지로 따라 가서 했던 봉사 활동, 남들도 다들 간다기에 나도 해보자고 갔던 여행, 운이 좋아 당첨된 회사의 이벤트성 단체 활동, 얼떨결에 맡게 된 동아리 총무, 혹시나 해서 넣어봤는데 합격한 인턴, 집안에 갑자기 생긴 불행한 사건 등등이 다 그 재료이다.


하나씩 꺼내서, 위 A,B,C,D 네 가지를 억지로라도 적어보고 생각하고 수정하고 생각하고. 자고 일어나 다시보고 생각하고 수정하고 또 생각하고. 이 과정을 해보면, 신기하게도 인간이 그냥 막 살지는 않았다는 것을 발견하게 된다.

앞서 이야기하지 않았던가. '자기소개서는 나를 설명하는 글이 아니라, 나를 돌아보는 글'이라고. 거꾸로 자기소개서를 핑계로 나를 돌아보면 내가 뭔가를 할 수 있다는 자신감도 생긴다. 입학, 취업 시점이 아니라도 자기소개서를 쓰면 인생이 풍요로워지고 자신감도 생긴다.


어떤 활동에서도 앞의 A,B,C,D 네 가지 항목들을 꺼낼 수 있다.


A. 중대한 동기와 계기가 있으면 좋겠지만, 대개는 사소하거나 (예, 그냥 친구따라) 우연한 계기로 (예, 인터넷 서핑 중에 광고를 보고) 생긴 순간적인 강한 동기가 있다. 그 사소하지만 나를 움직인 강한 동기라는 것은 인간적, 사회적, 경제적, (나이가 어린 친구들에게 자주 관찰되는) 사해 동포적인 가치에 대한 추구 또는 특이하게 내 삶에서만 의미 있는 호기심을 반드시 동반한다.

또 우리나라에서 별 다른 자기주도적 선택권이 없는 청소년들의 경우, 최소한 이 활동이 앞으로 더 심화된 배움을 위한 잘 알려진 준비 과정임을 명확하게 인식하고 있다는 정도의 설명도 '동기'로서 꽤 의미롭다.


B. 활동의 결과를 평가 받는데 주요한 역할을 하는 구체적인 문제(또는 장애물, 임무, 업무 절차의 개선 필요성 등)의 사례를 들어, 어떤 방식으로 (교과 또는 교과외 공부, 조사 분석, 멘토의 가르침, 많은 준비된 토론, 깊은 성찰, ...) 배워나가 그 문제를 극복했는지를 보여준다.

사례가 중요하다. 사례가 동반되지 않는 몰입은 없다. 이 문제 사례와 그에 따른 배움에는 팀 활동에서의 리더십도 포함된다. 팀의 리더가 되었다는 것 보다는, 팀을 이끄는 리더로서의 역할과 책임(문제 인식과 결정)의 수행에 최선을 다했다는 것을 보인다. 팀장이 아니라도 팀원들 사이에서 자신이 맡은 역할을 잘하는 것도 리더십이다. 구체적인 사례는 글을 읽는 사람을 쉽게 '빙의' 상태로 이끈다. 문제가 제시되면 나라면 어떻게 했을까 하는 생각이 들기 때문이다.


C. 평가는 다소 어려운 부분이다. 권위 있고 의미 있는 대회에서의 수상도 좋지만 동료에 의한 평가만큼 중요한 것은 없다. A에서 언급된 동기 즉, 인식된 문제을 해결한 구체 사례, 호기심이 충족되어 얻은 큰 기쁨 등을 우선 기술하고 개선을 요하는 부정적인 평가를 포함한다.

내가 한 모든 활동에는 대상이 되는 사람 또는 관객이 존재한다. 그 대상은 내가 잘 아는 사람일 수도, 전혀 알지 못하는 사람일 수도 있으며, 개인이거나, 커뮤니티 일 수 있다. 또 나 자신도 그 중 하나이다. 스스로에 대한 비판적인 시선은 참 의미롭다. 내 활동의 과정에서 또는 내가 보여준 결과물에 대한 모든 부정적인 평가를 기꺼이 수용하고, 결과물을 개선한 사례를 보인다.


D. 사람은 끊임없이 배우는 존재이고, 그 사람이 속한 조직도 마찬가지이다. 내가 해결한 문제는 나와 내가 속한 커뮤니티에 늘 좋은 영향을 준다. 또 몰입과 평가의 과정을 통해서 나를 돌아보게 한다. 모든 활동은 그 활동 이후의 내 삶은 물론, 내가 속했던 조직, 커뮤니티에도 작게나마 영향을 줘서 내가 더 큰 일을 시작하게 하거나, 크던 작던 어떤 제도가 바뀌는 계기가 되거나, 많은 사람들이 참여하는 활동으로 발전한다.




4. 자기소개서에서 하면 안 되는 것


내가 경험했던 것들을 Fact 중심으로 그것도 시간 순서로 단순 나열하면 절대 안 된다. 연대기는 읽는 사람을 철저하게 관찰자로 남게 한다. 연대기적인 자기소개서를 볼 때 평가자는 사고 중심이 아니라 사건 중심의 관점을 가지기 때문에 결론을 빨리 보고 싶게된다. 그런데 그 결론이 '올림픽 금메달', '노벨상' 이 아니면 급히 실망한다.


슬라이드, 웹 페이지 형 자기소개서도 읽는 사람이 '빙의'하는 것을 철저하게 막는다. 통상적으로 이력서에 필요한 스킬셋의 나열 등과 달리, 말로 설명을 같이 할 수 없는 상황에서의 PPT 장표형 자기소개서는 정말로 잘 만들기 어럽다. 또 잘 만들었다 해도 '내가 설명할께 편하게 보세요' 라는 느낌으로 다가온다. '잠시 동안 제가 되어 같이 이 경험을 공유해 봐요' 같은 ‘빙의’ 모드와는 거리가 꽤 있다.


자기소개서를 요구한 조직의 인재상이 내 개인적인 상황(가족, 가정형편, 그 상황에서 형성된 내 성격 등)과 밀접한 관련이 없다면 '저는 유복한 가정에서 장남으로 태어나' 또는 '부모님의 이혼으로' 아니면 '아버지의 사업이 갑자기 부도가 나는 바람에' 이런 류의 내용은 일말의 도움이 안 된다.

내 성격이 드러나야 하는 포인트는 다른 모든 자기소개서 내용에 상당한 자신감이 있을 때, '저는 이렇게 놀기 때문에, 여기 계신 분들과 인간적으로도 잘 지낼 수 있어요'까지 설명하고 싶을 때이다. 내 인간성과 성격은 면접 때 단 몇 마디의 발언만으로도 드러나기 때문에 따로 쓸 필요가 없다. (다만, 내 개인적인 상황이 나를 한단계 끌어올린 어떤 큰 배움의 계기가 되었다면 그것은 아주 좋은 자기소개서 주제가 될 것이다.)



고민과 걱정만 있고 행동과 선택이 없는 경험은 자기소개서의 아이템으로 적절하지 않다. 그 고민의 깊이가 조직의 인재상과 맞닿아 있는 경우엔 문제가 없을 수도 있지만, 선택과 행동이 없으면 그 글을 읽은 사람은 지원자가 자기주도성이 부족하고 책임감이 없다고 느낀다.




5. 마지막으로


자기소개서 쓰는 것은 어렵다. 원래 누구나에게 자기소개서는 어려운 것이다.


자기소개서는 반드시 서너 번 읽고, 자기소개서를 요구한 조직의 인재상에 맞게 기술되어 있는지 확인하는 과정을 거쳐야한다. 당연히 나 말고 나를 잘 모르는 사람이 읽어주면 훨씬 좋다. 대개 어딘가에 제출하기 위해서 쓰는 자기소개서이지만, 자기소개서는 나를 돌아보고 숨어있던 내 속의 자신감과 진정성을 발견하는 훌륭한 도구라는 것을 잊지 말자.




* 참고로 이력서, 자기소개서 쓰는 법에 관한 짧은 슬라이드:


관리자
2018-12-27 15:06
조회 80

모든 학생이 음악을 배운다. 

나의 음악적 재능은 마이너스 무한대이지만, 

당연히 나도 음악을 배웠다. 



우리가 음악이 중요하다고 느끼는 이유는 

적어도 언젠가 한번은 음악을 듣고 위안을 얻었거나, 즐거움을 느꼈거나, 

주변의 사람들과의 공감을 얻었기 때문이다. 

그래서, 음악에 대하여 사람들은 다들 부채감을 가지고 있다. 

음악뿐만 아니라 다른 예술, 과학이 그렇고 또 인문학이 그렇다. 

아마도 그 부채감 때문에, 사실 역사가 그리 오래되지도 않았고 

기계적인 능력 배양이 가장 중시되는 현대적인 교육이라는 틀에도 

예술, 과학, 인문학이 들어가는 것에 대하여 사람들은 일반적으로 동의한다.



음악에 사용되는 악보라는 문서는 음악을 표현하는 멋진 도구이다. 

물론 악보를 볼 줄 몰라도 음악을 즐길 수 있다. 

다들 알고 있듯이 악보는 연주라는 행위로 

음악을 사람들에게 현실로 만들어주는 사람과, 

그 음악이 가지게 될 중대한 (그 부채감을 유발하는) 가치를 창작해내는 사람들, 

즉 작곡가와의 인터페이스이다.



한편,

소프트웨어도 우리 주변에 널려 있다. 

요즘 우리는 공기 반 소프트웨어 반으로 숨 쉰다. 

다시 말해, 소프트웨어 역시 사람들에게 예술, 과학, 인문학에 못지 않은 중요한 무언가라는 뜻이다. 

소프트웨어는 모든 방면에서 우리의 삶을 좀 더 편하고 효율적으로 만들어 주며, 

현실에서 전혀 가능하지 않은 것을 할 수 있게도 해 준다. 

문제는, 그 소프트웨어가 세상의 다른 어떤 것보다 급속하게 발전한 나머지, 

사람들이 그 가치로움에 공감하기 전에, 또 막연한 부채감을 느끼기 전에, 

예술, 과학, 그리고 인문학적 성찰을 통해서 만들어진 

많은 가치들을 현실로 구현하고 또 그 가치들을 지켜주는 아주 중대한 도구로 자리 잡았다는 것이다. 



왜 코딩을 어릴 때부터 배워야 하는지에 대하여 질문을 많이 한다.

내가 언제 악보를 처음으로 보게 되었는지 기억이 안나서 

페이스북에 요즘 학교에서 언제 악보 보는 법을 배우는지에 관한 질문을 올렸더니. 

아마도 초등학교 저학년 때 악보라는 것을 보고 음악을 배운다고 한다. 

그리고 더 많은 아이들은 초등학교 입학 전에 이미 피아노 학원에서 악보를 보게 된다고 했다.

내가 작곡가나 연주가가 되지 않아도, 또 전문적인 가수가 아니라도 악보를 대개 볼 수 있듯이, 

프로그래밍도 어쩌면 모든 사람에게 악보와 같은 것이어야 하지 않을까 한다. 



내가 전문적인 개발자가 아니라도, 지금 이 세상에 내가 살아가는 이유와 

더 나아가 내가 만들어내고자 하는 모든 가치들을 알리고 구현하는 

도구인 소프트웨어와 그것이 만들어지는 과정을 경험으로 느끼고 배우는 것은 의미롭다.



소프트웨어는 프로그래밍 언어의 구사, 즉 코딩을 통해서 구현된다. 

물론 프로그램 언어를 몰라도 소프트웨어를 사용할 수 있다. 

악보를 볼 줄 몰라도 노래를 할 수 있듯이. 

우리가 어디선가 들었던 노래를 흥얼거리고, 

또 어디선가 본 듯한 형상을 종이에 끄적거리고, 

또 우리가 만지는 모든 물건들의 과학적 배경이 있듯이, 

이제 모든 것의 뒤에는 소프트웨어가 있고, 소프트웨어를 개발한 사람들이 있다. 

소프트웨어를 이해하고 코딩을 배우는 것은, 

아직 우리 유전자에 각인되지 않은 부채감을 대하는 최소한의 예의이다.



출처: 이민석 교수님 블로그
http://hl1itj.tistory.com/125

관리자
2018-12-27 14:58
조회 90

많은 사람들이 어떻게 소프트웨어를 배워요? 어떤 기술을 어떻게 배워요? 라는 질문을 한다.

 

한 줄짜리 정답은 .. 소프트웨어를 배울 때 가장 빠른 길은, 작은 성취를 이루어가는 것이다. 

다음 감동적인 동영상을 보라. 왜 아침마다 침대를 깔끔하게 정리해야하는지를 명쾌하게 설명했다.



클릭해서 안나오면.. 동영상 링크 https://youtu.be/KgzLzbd-zT4

(자동생성 자막이 지원되며, 자동번역을 선택하면 한글로도 그럴듯한 자막이 나온다.)

 

많은 학생들은 책을 사서 진도를 다 나간 뒤에 (즉, 공부를 한 뒤에) 

뭔가를 만들겠다고 결심한다. 통하지 않는다. 

책걸이를 하고나면 책만 남을 뿐, 뭔가를 할 수 있다는 자신감이라곤 생기지 않는다.

 

그래서 정리한  소프트웨어를 배우는 방법  :

(내가 늘 사용하는 방법이며, 아마 대부분 사람에게 통할 것으로 생각되어 권하는 방법)

 


1. 책을 사기 전에 배우고 싶은 것으로 무엇을 만들까를 먼저 생각한다. (새로운 언어를 배울 때, 난 항상 Snake Bite 라는 게임을 만든다.)


 

2. Hello World를 해본다. (이는 최소한의 Tool 사용법을 익히는 과정이다) - 이 과정은 동영상 따라하기가 도움이 된다. 우리가 배워야하는 것의 대부분은 남들이 나보다 먼저 배운 것이다. 그들도 어렵게 배웠다. 그래서 고마운 분들이 따라하기 동영상을 만들었고, Youtube에 보면 Hello World 따라하기 동영상이 거의 100% 있다. - Youtube에서 "배우고싶은것이름 hello world" 를 검색하자. 이 'Hello World!' 따라하기 과정에서 작은 성취를 얻자. "아! 진짜 되는 구나", "나도 이걸 써서 간단한 메시지를 찍을 수 있게 되었구나." - 여기까지 해보니 완전 재미가 없으면.. 정말 하고 싶은 것인지 다시 생각해보자.

 

다음은


 

3. 책을 산다. 요즘엔 물리적인 책이 없거나, 인터넷의 무료 EBook도 많다. 책이 없으면 (예를 들어 무슨 API 만 잔뜩있는 그런 프레임워크를 배워야 한다면) 그 소프트웨어의 man page (모든 API가 설명되어 있는 문서 - API reference)를 찾는다.

 


4. 아주 빠른 속도로 책의 각 섹션 (각 API, man page, ..)의 제목과 앞의 몇 문장만을 정독한다. (젊은이들은 아재들과 달라서, 그 제목과 앞의 조금을 꽤 오래 기억한다). 웬만한 책은 오며가며 읽어도 하루, 이틀이면 읽을 수 있다.


 

5. 위 1번에서 만들려고 했던 것의 최소한부터 만들어본다. 1번에서 예를 들어 '페이스북 같은 것'을 만들기로 결심했다면, 아래 그림과 같이 

실제 검색은 안된다 해도, 그림만이라도, 이쁘지는 않더라도 이 부분을 비슷하게 만드는 거다. 그러면서 조그만 성취감을 느끼는 것이 중요하다.

 


6. 최소한을 만드는 과정에서 배워야 할 것이 있다는 것을 알게 되면, 다시 책 (man page, 홈페이지, eBook...)으로 돌아가서 그 배워야 할 항목 전체를 정독한다. - 선수 개발자들도 대개 뭔가를 사용하게 될 때 그 때 정독을 한다.

 


7. 6번의 과정에서 뭘 배워야할지를 알게되는 것이 중요한데.. 그래서 '최소한'을 진짜, 정말, Really, 누가 뭐래도 '최소한'으로 정해야 한다. 그랬는데도 뭘 배워야 하는지 모르겠다면. 이 장면에서 멘토가 필요하다. 롤모델이 아니라 멘토다. 롤모델은 액자에 걸려있는 사람이고, 멘토는 전화해서, 메일보내서, 만나서 질문하면 같이 답을 찾아주는 사람이다. 나보다 아주 조금만 더 잘하면 된다. 어느날 그 멘토와 내가 비슷한 수준이 되면, 멘토와 함께 우리보다 조금 더 잘하는 멘토를 찾으면 된다. 내 옆의 사람이 멘토다. 커뮤니티가 중요하다.

 


8. 그 "최소한"을 조금씩 늘려간다. 조그만 성취를 계속해나가는 것이다. 그러면서 배운다.

 


9. 여기가 제일 중요한데.. 그 조그만 성취를 자랑한다. 두려워하지말자. 누구나 다 첫번째 발걸음이 있다. 애인에게. 친구에게, 멘토에게, 부모님에게, 지나가는 사람에게, 페이스북에서, 트위터에서, 인스타그램에 공개하고 자랑하자. 누구 하나라도 '좋아요'를 눌러주면 그 '조그만' 성취를 더 크게 만들려는 의욕이 하늘을 찌르게 된다. 어느 포인트에 공개해야 하나? 그 조그만 성취를 자랑(공개)할까 말까 고민이 된다면.. 바로 그때가 자랑할 때다.

 

http://image.ajunews.com/content/image/2016/03/03/20160303155107141989.jpg

 

 

요약: 조그만 성취를 하기 위해 배우고, 자랑하자. 그것이 반복되면 자신감 충만한 배움이 쌓인다.


출처: 이민석 교수님 블로그
http://hl1itj.tistory.com/133