이성열

문화적으로 정착되기 전에는 스스로 필요성을 느끼기 힘듭니다. 문화적으로 정착이 되면 왜 필요한지 생각하지 않고 그냥 당연히 하게 됩니다. 그래서 문화죠.

그래서 대부분 문제가 크게 터진 다음에 필요성을 느끼게 됩니다. 작은 규모의 회사에서 가장 먼저 터지는 경우는 "개발자의 퇴사"입니다. 그리고 "회사의 성장"입니다.
둘다 "공유의 문화", "협업의 문화"가 부족해서 문제가 됩니다. 그 방법이 "문서"와 "프로세스"입니다.

물론 혼자 개발을 해도 이를 지키는 것이 더 빨리 개발할 수 있는 방법이지만 스스로 느끼기는 어렵습니다.

보통 첫번째 "공유"의 문제는 개발자 10명 쯤에 생깁니다.
그리고 "관리"의 문제라고 생각하는 이슈들이 25~30명 쯤에서 생깁니다. 하지만 이 또한 "공유", "협업" 부재의 문제에서 생겨납니다. 대부분의 개발 조직은 관리보다는 "투명한 개발"에서 저절로 관리가 되도록 되어 있기 때문입니다.

관리의 이슈가 되는 것은 100명, 400명 쯤 겪는 이슈입니다. 작은 조직일 때부터 "문화"를 잘 갖춰나간다면 이정도로 커져도 큰 문제가 없습니다. 하지만 "문화"는 엉망인데 "관리"로 해결하려고 하면 문제가 더 커집니다.

이성열님 회사도 문제가 터진 다음에는 어렵습니다. 개발자들을 설득하는 방법은 개발자들에게 "소프트웨어 공학"을 이해시키고 왜 개발자들이 체계적으로 개발을 해야만 성장을 하고 "고급개발자"가 되는지 납득시키는 겁니다. 주먹구구식으로 개발을 하면 10년을 또는 20년을 개발해도 3년차 개발자와 다를 것이 없습니다. 코딩 속도 조금 빨라진 정도입니다. 저는 그런 개발자에게는 절대 연봉을 5,000만원 이상을 주지 않을 겁니다.

연봉 1억, 2억 이상 가치의 개발자가 되려면 스펙, 설계를 잘 쓸줄 알아야 합니다. 자기가 코딩까지 다 해야만 개발을 할 수 있으면 평생 초급 개발자입니다. 개발자들에게 나아가야 할 방향을 자꾸 주지시켜서 세뇌를 시켜야 합니다. 이것이 개발자도 회사도 좋은 길입니다.

안녕하세요. whitekid님

문서화의 첫번째 이유가 자신을 위해서죠. ^^

안녕하세요. shint님

저는 문서화는 비용으로 생각하지 않습니다.
문서화를 비용으로 생각하는

1. 필요 없는 문서를 경우는 문서를 너무 많이 적거나
2. 문서를 작성하는 경험과 실력이 부족하거나
3. 프로젝트가 끝나고 적는 경우입니다.

문서는 필요한 만큼만 필요한 시기에 적어야 합니다.
프로젝트에서 가장 중요한 문서는 스펙(SRS)입니다.

구차니님 안녕하세요.
사수... 이것에 대해서도 할말이 많습니다. ^^;
기형적인 구조 떄문에 사수가 아니면 별 뾰족한 방법이 없는 것도 현실이고... 나중에 올릴께요.

안녕하세요. 김경록님
솔직하시군요. ^^
너 자신을 알라!, 아는 것이 힘이다.
즉, 자신을 아는 것이 힘이다.

hermian님 안녕하세요.
지식을 넣어 주는 기술은 300년은 지나야 나올 듯합니다.

300년 지나면 가능해지나요??
가능한 일이면 좋겠습니다.
어쨌든, Ray님의 글들에 동의 합니다..

안녕하세요. 이혜원님

그래서 저희같은 사람의 도움이 필요합니다.
외부 전무가의 힘을 빌어서 변화를 꾀하는 것이 가장 빠르고 무리없이 변화에 성공할 수 있는 방법입니다.

장호진님 안녕하세요.
열심히신군요. ^^ 책보고 스스로 뭘 해보는 것이 정말 힘들죠. 궁금하신 것이 있으면 언제든지 문의해주세요. Email은 항상 열려있습니다.

본문에서도 언급했듯이 "소프트웨어 전문가란 코딩만 잘하는 개발자가 아니고, 구축, 설계, 테스트, 형상관리, 버그 추적, 빌드, 릴리즈, 방법론 등 소프트웨어 관련 여러 분야의 지식과 경험을 두루 갖추고 있는 사람입니다."
제대로 시스템과 프로세스, 개발 문화를 갖추고 있는 회사에서 10년 이상을 개발을 해 온 개발자라면 이런 분야를 두루 섭렵할 수 있지만, 보통의 경우에는 주로 구축(코딩)과 설계만 치중하기 때문에 소프트웨어 전문가가 되기는 어렵습니다.

소프트웨어 전문가인가요 아니면 소프트웨어 엔지니어링 전문가 인가요?

본래 둘을 같은 의미로 쓰던가요?

소프트웨어 공학하면 왠지 이론적인 냄새가 많이 나서 별로 사용하기가 꺼려지지만 지식과 경험을 모두 갖추고 있어야 진짜 소프트웨어 공학이라고 할 수 있죠. 따라서 지식과 경험을 모두 가지고 있다면 소프트웨어 전문가, 소프트웨어 공학 전문가를 따로 구분할 필요는 없어 보입니다. 그래서 가끔 이론적으로만 소프트웨어 공학을 공부하고 연구한 교수를 전문가로 봐야 하는지에 대해서는 섯불리 얘기하기 어려운 측면이 있습니다. 그 분들도 분명히 이론적인 기반을 다지고 새로운 기법들을 연구하는 것에는 의미가 있으나 실제 소프트웨어에 접목할 수 있는 경험이 없고 실제로도 어렵기 때문에 여전히 이슈는 존재합니다.

안녕하세요. dkinght님
관념적으로 접근을 하는 것은 별 의미 없을 것 같고, 진짜 소프트웨어 필드에서 필요한 전문 지식 몇 경험 분야를 보려면 IEEE에서 정의한 소프트웨어 전문 영역 10가지를 보는 것도 좋을 것 같습니다. 정확한 답은 아니더라도 도움을 될 겁니다.

황상철님 안녕하세요.
열심히 하시는 모습이 보기 좋았습니다. 젊은 개발자들은 만나는 것은 언제나 즐거운 일입니다.

주제가 조금 어려워서 전달이 잘 되었을지 걱정입니다. 만약 다음에 기회가 된다면, 좀더 쥬니어들에게 직접 와닫는 주제를 한번 정해봐야겠습니다. 감사합니다.

Jake님 오랫만입니다.
실리콘밸리에서 5년이면 배우는 것이 소프트웨어를 개발하는 방법이죠. 우리나라 개발자들도 다들 소프트웨어를 개발하고 있는데 이렇게 얘기하면 이상하다고 생각하겠지만, 제 경험에 의하면 정말로 다릅니다. 일단 미국은 60년의 소프트웨어 역사를 통해서 소프트웨어를 개발하는 방법에 대해서 체계를 갖추고 있고, 개발자들은 그런 회사에서 개발하면서 자연스럽게 익히는 것을 우리나라의 개발자들은 그런 기회가 없습니다. 그냥 코딩 실력과 몇몇 지식과 기법을 통해서 개발을 하는데, 그 기초가 너무 취약합니다. 그것이 무엇이냐고 물으면 책을 몇권 써야 설명이 다 되겠지요. 물론 미국에도 엉터리로 개발하는 회사도 있고 우리나라에도 잘하는 회사들도 많죠. 하지만 그 비율이 현격하게 차이가 나는데 문제가 있습니다.

골프를 배우려고 하는데, 혼자서 책보고 비디오 보고 배우는 것과 골프를 처음 시작할 때부너 골프 코치에게 배우는 것의 차이라고 할까요? 그럼 코치에게 배우는 것은 무엇인가? 너무 많아서 한마디로 말할 수 없습니다. 또 우리나라에는 골프를 배울 수 있는 골프코치가 그리 많지 않고 미국에는 널려 있는 상황과 비슷합니다.

또, 제대로된 방법 딱 하나를 상세하게 설명해주면 그대로 따라하면 되지 않을까?라고 생각해도 골프도 그렇게 안된다는 것은 쉽게 예상할 수 있듯이 소프트웨어도 그렇게는 안되죠.

그럼 어떻게 하면 배울수 있나? 인도의 개발자들처럼 미국이나 소프트웨어 선진국에 가서 배우는 것이 가장 좋은 방법이나 어렵죠. 그리고 고참개발자들은 이미 늦은 경우도 많구요. 이글의 말미에도 적었지만, 우선 마음부터 고쳐 잡아야죠. 그래야 여러가지 기회가 있을 때 받아드릴려고 하겠죠. 그 기회는 책이나, 강연이나, 전문가를 만나거나, 컨설팅을 받거나 등등 여러가지가 될 수 있습니다. 이럴 때 마음이 닫혀 있다면 배우지 못합니다.

묘재님 안녕하세요.
SI가 나쁜 것은 아니지만, 환경은 그리 좋지 않습니다. 우리나라의 SI의 개발 형태를 보면 업무지식(Domain지식) 위주로 개발이 진행되므로 오래 개발을 할 수록 업무나 비즈니스 로직은 점점 잘 알게 되지만, 소프트웨어 개발 실력을 향상할 기회는 상대적으로 적어집니다. 솔루션을 개발해보는 것은 다양한 경험 측면과 생각의 다변화 면에서는 긍정적이네요. 하지만 솔루션을 개발하는 회사나 부서의 환경도 별차이가 없다면 결국 본인이 스스로 공부하고 찾아다니면서 익혀야 하는데, 어려운 일입니다. 묘재님도 끊임없이 공부하시는 것 같으니 잘 될겁니다. ^^

아름드리님 안녕하세요.
본인이 아는 것보다 남을 설득하는 것은 10배이상 힘듭니다. 특히 본인이 완전히 확실히 알지 못하고 같이 잘 해보자고 하는 입장이면 더욱 어렵죠. 그리고 아름드리닙도 책보고 구글보고 할 수 있는 것은 한계가 있다는 것을 느낄 수 있을 겁니다. 책보고 골프를 배우는 것과 같죠. 제가 무료 세미나도 하고 있으니 관심있으면 연락주세요. 감사합니다.

bluepoet님 안녕하세요.
개발 2년차인데 벌써 이런 경험을 하고 생각을 하고 있다는 것은 아주 긍정적입니다. 미래가 총망되네요. ^^

redef님 안녕하세요. 깨달음은 한순간에 오기도 하더군요. 아직 기회가 많이 있으니 잘하실 것 같습니다. ^^

우울한딱따구리님 안녕하세요. 경험하지 않고 깨닫거나 스스로 알아내는 것은 기적이거나 천재겠죠?

학교 다닐때 경험하고 깨닫는건 학습, 경험하지 않고도 깨닿는 걸 지능이라고 배운 것 같은데데... 개인적으로 경험하지 않고 스스로 꺠우친 것들은 그리 많지 않은 것 같습니다. ㅜ.ㅜ

지식으로 깨우칠 수 있는 것이 있고, 골프와 같이 경험 없이 지식만으로는 익힐 수 없는 것이 있습니다. 소프트웨어도 지식과 경험이 모두 필요한 분야라고 생각합니다. ^^

대부분의 회사가 그런것 같습니다. 또 개인시간이 마음대로 늘어나지 않는 것이 문제죠. 시스템이 잘 갖춰져 있어야 개발자들이 여유가 좀 생기고 좋은 생각도 하게 됩니다.

moova님 안녕하세요.
대부분의 프로세스를 시도한 회사들은 주먹구구식으로 개발하는 것보다도 못한 경우가 많습니다. 시행착오에 대한 경험을 얻는 것이 유일한 성과라고 할 수 있습니다. 스스로 조그씩 발전시켜나가거나 전문가의 도움을 받는 것이 좋으나 주변의 프로세스 전문가들이 대부분 moova님이 말씀하신 것처럼 이론 알고 있어서 실패할 가능성이 많습니다. 이렇게 얘기하고 보니까 답이 없네요. - -; 아무튼 과욕은 금물

Shawn님 안녕하세요.
대기업들은 중소기업과 다르게 무리한 프로세스도 꽤 오래 끌고 가고 직원들은 다들 피해가는 방법을 알고 있고, 그렇게 시간이 흘러서 아주 이상한 형태로 진화를 합니다. 겉보기에는 프로세스가 꽤 그럴듯 한 것 같은데 속은 전혀 아니고 오히려 생산성을 저해하는 경우입니다.
우리나라의 소프트웨어 개발 역사는 너무 짧기 때문에 아직 그런 저변이 부족합니다. 소프트웨어 선진국을 조금씩 흉내내는 것이 좋은 방법입니다.

우울한딱따구리님 안녕하세요.
우리나라 개발자들이 전세계 어느나라의 개발자보다 아이디가 넘치는 것은 저도 인정하는 바입니다. 사실 개별 개발자들의 지식수준이나 코딩 능력도 최고입니다. 그런데 회사나 사회전반의 저변이 이를 못받쳐주니 나이를 먹을수록 경력에 걸맞게 실력을 끌어올리지 못하고, 좋은 아이디어가 사장되는 경우가 너무나 많습니다. 기발팀이던, 회사던, 국가도 System으로 움직여야 하는데, 우리는 아직도 사람이 움직이고 있습니다.