오늘 받았다고 연락이 와서 잠시 얘기를 했습니다.
그 친구들은 과거 나와 같이 일을 했었던 친구인데,
버클리(UC Berkeley)에서 Computer Science를 전공을 했고, 십여년간 실리콘 벨리에서 소프트웨어 개발자로 일을 하고 있는 친구입니다.
그 친구가 책을 본 소감은 다음과 같더군요.
"책의 내용이 매우 친숙하다. 미국의 개발자들이 당연히 따른 것들이다."
사실 그렇습니다. "소프트웨어개발의 모든것"이라는 책은 소프트웨어 회사라면 당연히 갖춰야할 기초를 다루는 것으로 미국에서는 당연히 되는 것들이 우리나라에서는 너무나도 낯선 것이 많더군요.
Peer Review, SCM, BugTrack, Technical Path, Technical Steering Commitee, Spec, Conding Convention, Risk Management, Branch, Merge, Baseline, Tagging, Change Control, Daily Build, Regression Test, Requirement Engineering, Alpha, Beta, Release Candidate, WBS, B/R, Interface, Non-functional Requirement
이러한 것들이 특이한 것이 아니고 소프트웨어를 개발한다면 그냥 "공기와 물"같은 것인데 말입니다.
이 책을 영어로 번역을 해서 미국에서 판다면 아마 안 팔릴 거예요. 기껏해야 경험이 부족한 대학생들이나 살지도 모르죠. 미국에서는 일단 개발자로 소프트웨어 회사에 들어가면 이 책의 내용들은 2,3년이면 누구나 익히는 것들입니다.
그래서 이런 종류의 책이 미국 또는 한국 어디에도 없나 봅니다.
미국에서는 당연한 내용이라서 없고, 한국에서는 그러한 필요를 못느끼거나 저변이 부족해서 없다고 생각합니다.
하지만 우리나라 소프트웨어 회사들을 보고 개발자들을 만나보면 대단히 뛰어난 기술력과 열정에 비해서 책에서 소개하고 있는 기초에 대해서 취약한 경우가 많습니다. 그러한 소프트웨어 엔지니어링은 학교에서 배우는 것이 아니고 회사에서 자연스럽게 일을 하면서 배우는 것인데, 회사가 기초를 갖추지 못하고 있으니 개발자도 배울 수 없고, 나중에 가르칠 것도 별로 없는 "악순환"이 계속 되는 것이죠.
이건 엔지니어의 책임이 아닙니다. 소프트웨어 회사의 책임이죠. 회사는 입사하는 소프트웨어 엔지니어를 트레이닝 시킬 의무가 있는데, 우리나라 대부분의 소프트웨어 회사는 그냥 개발자에 의존해서 개발자가 하는대로 따라가는 것이 보통의 겨우죠.
그에 비하면 인도는 처음부터 개발자들이 미국에 많이 진출을 했고, 미국의 일을 많이 받아서 해오느라고 미국의 방식대로 그대로 배우면서 소프트웨어 산업이 발전해왔죠. 인도는 정말 잘되어 있습니다. 우리와 소프트웨어 산업의 태생이 다른 인도의 행운이라고 볼 수도 있죠. 모든 업무가 전문적으로 나눠져 있고, 분석, 설계, 테스트, Tech Pub 모든 작업이 전문적으로 진행되고, 문서 작성, 시스템 사용 이런한 것들이 기본적으로 다 갖춰져 있고, Global 표준인 미국의 방식을 따르고 있죠.
솔직히 제가 소프트웨어 컨설팅을 하고 있지만, 단 시일내에 우리나라의 소프트웨어 개발 환경이 좋아지리라고 생각하지 않습니다. 하지만 꾸준한 노력이 필요하고 그 일환으로 책도 쓴 것입니다.
어차피 나를 비롯해서 수많은 소프트웨어 엔지니어들은 이 소프트웨어 바닥이 잘 되어야지 다른 뾰족한 재주가 없으니까요. 지금은 3D 직업으로 점점 인기를 잃어 가고 있지만 소프트웨어 엔지니어가 최고로 대접받는 때가 와야 하지 않겠습니까?
친구 분 이야기가 공감이 갑니다. 미국에서는 당연한 것을 왜 한국에서는 문제가 될까요...
답글삭제일단 공부도 공부이지만 무슨 일이던지 시작하기 전에 생각을 하는 습관을 가져야 하는데 우리나라 개발자들은 일단 코딩부터 시작하는 나쁜 습관이 몸에 벤 것 같습니다.
회사에서 의무적으로 시킨다고 해서 모두 따라서 하는 것도 아니고 설사 회사에서 시키지 않는다고 해서 안하는 사람은 더욱 문제고....
여튼 프로그래밍으로 밥 먹고 사는 사람은 프로이기 때문에 운동선수만 프로정신 운운할 게 아니라 개발자도 프로정신을 가져야 한다는 생각을 반드시 해야 할 것 같습니다.
저는 테스트 관련해서 일을해 오고 있습니다. 일본에 가서 교육을 받을 기회가 있었는데 일본 업체들은 우리가 다 아는 내용을 실천하고 있는 차이만 있을 뿐 새로운 건 없었습니다. 실천... 개인과 회사 모두 실천할 수 있는 문화를 어떻게 형성하면 될까요? 함께 변화하기 위하여 프로세스를 담당하는 개인으로 또는 팀이 어떤 노력을 해야하는 걸까요? 최근 제가 하고있는 업무와는 관계없이 제 머리속에 계속 맴도는 숙제입니다. ^^:
답글삭제littlehj님 안녕하세요.
답글삭제미국과 한국의 차이는 소프트웨어 역사의 차이인 것 같아요. 60년과 20년의 역사의 차이가 문화의 차이를 만든 것 같습니다. 우리나라는 20년간 우리 나름대로의 문화를 만들었고, 인도는 미국의 것을 그대로 받아 들였다고 생각합니다.
많은 사람들이 노력하고 있으니 점점 나아지겠죠.
정의의소님 안녕하세요.
답글삭제실천이 가장 어려운 것이지요. 코드리뷰 해야 한다는 것을 알면서도 막상 하는 회사는 거의 없거든요. 결국 이런 것은 제대로 아는 것이 아니고 피상적으로만 알고 그 핵심은 모르는 것이라고도 할 수 있습니다.
한두사람의 노력으로 회사와 엔지니어들이 바뀌는 것도 아니지요.
이부분은 제가 쓴 책(소프트웨어개발의 모든것)에서도 중요하게 다루고 있고, 회사가 변화하기 위한 내용들을 쉬운 것부터 설명하고 있습니다.
하지만 이 또한 책의 한계를 벗어니기는 어려울 것 입니다.
이를 위해 노력하는 사람들이 많아지고 특히 경연진등 윗사람들이 바뀌어야 좀더 빠른 시간에 회사가 바뀌어 갈 수 있을 것이라고 생각합니다.
즉, 먼저 깬 엔지니어들은 경영측을 설득할 수 있어야 가능한 일이죠.
정말 좋은 블로그를 우연히, 뒤늦게 발견했네여. 미국조직에서 프로젝트를 한 경험이 있는데 정말 미국의 소프트웨어 개발 프로세스/문화와 한국 소프트웨어 기업의 주먹구구 방식 사이에는 정말 큰 gap이 있다는 것을 느꼈습니다. 그 미국회사도 전문 software house가 아닌 ASP적인 서비스로 비지니스를 하는 회사였는데도, 프로세스는 그보다 큰 규모의 한국 소프트웨어 회사보다 훨씬 체계적이었고, 이로 인해 한국개발팀과 미국팀과의 충돌이 프로젝트의 큰 걸림돌로 작용했습니다. 지금 생각해보면 기초도 모르고 기초를 우습게 보던 한국팀은 자기가 얼마나 unprofessional 했는지 조차 몰랐던것 같습니다.
답글삭제좋은 글들 계속 많이 올려주세요!
안녕하세요. Macdaddy님 반갑습니다.
답글삭제자주 들러주세요. 의견도 많이 올려주시고요.
안녕하세요?
답글삭제얼마전에 읽었던 책의 저자님이시네요.
책의 내용은 상당히 좋았고 수긍할 수 있는 내용이었습니다.
근데 몇가지 아쉬운 부분이 있었어요. 제 생각은 우리 나라의 개발 업체 중 대부분은
자체 제품을 개발을 하지 않고 일명 계약서 상의 '을' 또는 '병'에 해당하는 업체입니다.
과연 '을'과 '병'이 프로젝트의 SRS, 일정 산정, 설계에 얼마만큼의 영향을 끼칠 수 있을까요?
대부분의 '갑'이 정해놓은 요구사항과 일정, 설계에 맞춰 구현만 하는 입장이라고 생각됩니다.
책의 내용에 따라 프로젝트를 진행하기엔 우리나라의 개발 문화가 너무 여건이 안 좋다고 생각 됩니다.
안녕하세요. Zeroday님
답글삭제id가 zeroday인것은 혹시 보안업계에 종사하시나요? ^^
책 서두에서도 언급했듯이 SI건 팩키지건 소프트웨어를 개발하는 그 원리는 크게 다르지 않습니다. 따라서 SRS, 설계, 인프라, 프로세스등에 대해서 빠삭하게 알고 경험이 있어야 하는 것은 사실입니다.
그렇다고 하더라도 SI가 열악한 것은 사실입니다. 환경이 좀더 안좋은 거죠. 그래도 여전히 책에서 언급하고 있는 것들은 효과가 있고 상황이 열악한만큼 어떻게 적용할지는 경험이 많이 필요합니다. 하지만 그런 경험없이 SI만 하고 있다면 매일 전투모드로 문제 해결만 하는 형색이 됩니다.
원래 갑은 요구사항을 주는 것이고 거기에 맞춰서 스펙을 작성하는 것이 분석작업입니다. 일정은 항상 촉박하지만, SRS를 씀으로써 일정을 단축할 수 있고, 일정이 현실적인지도 파악이 가능합니다. SRS를 쓰고 설계를 함으로써 일정과 비용이 절약된다는 것을 이해하고 있어야만 소프트웨어 개발 원리를 이해하고 있다고 할 수 있습니다.
우리나라 개발여건 및 문화가 열악한 것은 저도 동감입니다. 그리고 책에 따라서 프로젝트를 그대로 진행하는 것이 쉽지도 않습니다. 모든 프로젝트가 그러하듯이 그 성격에 맞게 알맞은 방법을 찾아서 진행해야 합니다. 책은 그 가이드를 제시할 뿐입니다. 직접 경험을 해보지 않으면 이걸 해야하는지? 하지 말아야 하는지? 방법을 좀 바꿔야 하는지 알 수 없습니다. 배우고 경험하고 단련하고 계속 해나가는 수밖에 없습니다. 이런 경험이 쌓인 고참 개발자들이 대우를 받아야죠. 그냥 코딩만 열심히 오래한 개발자들은 이런 판단을 하기가 어렵습니다.
Zeroday님도 이쪽에 관심이 많으신 것으로 봐서 멋진 선배일 것으로 생각되네요.