개발자가 알아서 못해주는 이유
생존형 개발자의 생각 #84
내용 며칠 전, 어떤 대표에게 농담삼아 던진 말이 있다.
”개발자와 감정없이 대화하는 법을 글로 정리 중이야...”
그러자 대표가 말했다.
”어떻게 개발자에게 감정을 안가질 수 있지? 그게 가능해? 뭐라 말만하면 안된다고 말하거나 내가 할 일이 아니라고 말하는 데 감정이 안생기나?”
위의 반응은 대표만의 것이 아니라고 본다. 비개발자라면 개발자와 대화하다가 혈압이 상승하거나 분노감정이 증가하는 경우가 흔히 발생한다. 일단 개발자라는 직군의 특징상 “논리 오류”를 용납할 수가 없다. 오류에 대한 warning을 하거나 제거를 하지 않으면 “프로젝트가 망하는 수”가 존재하기 때문이다. 결국 “철학자들의 불쾌한 질문”과 같이 꼬리에 꼬리를 무는 질문이 발생한다.
특히 기획자나 대표 또는 고객의 말(Needs)에 촉각을 세워야 한다. 그들이 기술을 모르기에 “기획과 요구”의 맹점을 알려주지 않는다면 “결과물은 실패할 가능성이 높아진다. 그래서 개발전문 조직에서는 소프트웨어 요구서가 오면 개발자들과 기획자들의 날선 피드백 전쟁이 시작된다. “이건 가능합니다.”, “이건 불가능합니다” , “이건 Man/day가 더 추가되어야 합니다” 등등의 피드백을 jira나 칸반기반의 각종 sheet에 적어가며 협의를 한다.
그럴 때마다 무식한(개발자 입장에서는) 닝겐들이 한 둘씩 나오게 된다.
”그 것 혼자서 알아서 못해요? 수퍼개발자나 Fullstack들은 다 한다고 하던데?”
라는 말을 하며 전쟁의 서막을 울린다.
이런 실수는 업계 초보들에게 종종 보인다. IT업계에서 대표적인 실패사례가 개발을 이해하지 못하는 경우이다. 만약 개발자와 소통이 불가능한 사람이라면 다른 업종을 찾아보는 것이 좋다. 심지어 개발을 이해하지 못한 대표이사도 뼈아픈 깨달음을 얻고 업종변경하는 사례도 있다. 돈과 아이템만 가지고 마음에 드는 개발자로 교체하며 제품을 만들 수 있었다면 누구나 제품을 만들어냈을 것이다. 그러나 현실은 그렇지 못하다는 것을 알아야 한다. 개발자는 대외적으로는 ugly하지만 신뢰와 명예를 숭상하는 오크같은 면이 있기 때문이다.
만약 당신이 개발자와 협업을 해야 하는 불쌍한 존재라면 아래 내용은 숙지를 하고 있어야 고통에서 벗어날 수 있다. 말이 길어지면 본질이 흐려지게 된다. 그래서 아래에 내용으로 짧게 정리했다.
다음은 2017년도에 스타트업 대표들을 모아놓고 피칭(Pitching)했던 Google silde를 발취한 것이다.
개발자도 전문분야가 있다.
서버 개발자
클라이언트 개발자
프론트앤드 개발자
기타 전문분야 개발자
모든 전문집단은 그 안에 전문 분야가 존재한다. 정신과 의사에게 흉부외과 수술을 맡길 수 없 듯 개발자도 전문분야가 있고 그들이 해야 할 일이 따로 있다. 전문분야 개발자가 아니라면 문제가 발생한다. 아는 것과 하는 것은 다르기 때문이다. 프로젝트 경험, 최근까지 진행한 업무같은 내용이 매우 중요하다. 그런이유로 시킨다고 무조건 하는 개발자는 흔치 않다(그런 개발자는 나중에 사고칠 확률이 높다).
대부분의 기획자나 CEO들은 개발자들이 알아서 모든 것을 해줄 수 있다는 샤머니즘을 숭상한다. 그러나 개발자들은 극히 일부의 부분만 책임지는 작업자일 뿐이다. 그들이 원하는 사람은 실제로는 개발자가 아니라 PM(Project Manager)이다. 그것을 구별할 줄 모르는 사람들이 태반이다. 아직까지 이 땅에서는 PM을 재대로 이해하는 조직이 많지않다. 대기업 정도되어야 가치를 인정받는다.
프로그래밍 언어는 한 개가 아니다. 그리고 언어가 중요한 것도 아니다.
프로그래밍 언어의 종류
언어보다 중요한 개발환경
프로그래밍 언어는 개발자를 위한 도구이다. 기획자나 다른 사람들이 관여할 부분은 아니다. 가끔 기획자들이 개발자들과 소통에 오류가 생겨 특정 언어가 모든 것을 해결해 줄 것으로 오인하는 경우가 발생한다. 그러나 언어는 중요하지 않다. 개발환경이 중요하고 그에 따라 선택할 수 있는 언어가 있을 뿐이다. 그리고 그 언어의 중요성은 “개발자”들만 알 수 있다. 개발자들의 대부분의 고민은 “개발환경의 이해”이다. 이전 개발자가 어떻게 만들어놓았는 지 문서나 교육없이는 알기 힘들기 때문이다.
개발자가 만든 소스를 누구나 보고 이해할 수 있는 것은 아니다.
업무를 이해하고 있어야 한다.
히스토리를 알고 있어야 한다.
개발환경을 이해하고 있어야 한다.
개발자가 소스를 이해하는 대는 시간이 걸린다.
오픈소스가 아닌 이상 회사에서 사용하는 업무소스를 한 번에 이해하는 경우는 없다. 이전에 작업했던 담당자들에게 문서를 수령받고 업무교육을 받은 후, 실행에 문제가 없는 지 테스틀 해보아야 한다 .만약 이런 작업이 없이 담당자를 변경하면 문제가 발생한다. 프로그램에 오류가 났을 경우, 대처할 수 없는 경우가 태반이다. 그럼에도 불구하고 대기업, 중소기업 할 것 없이 개발자 업무이관교육이 원할하지 못하다.
이전에 만든 소스가 완벽할 리가 없다.
이전에 만들었던 소스 버그잡다 시간을 허비한다.
이전에 만든 소스의 뼈대를 함부로 고칠 수가 없다.
추가신규 개발을 하다보면 기존 소스를 버리고 새롭게 만들어야 하는 시점이 온다.
개발자들이나 개발팀에게 자주 듣는 내용이 위의 내용이다. 결국, 만들어놓은 소스는 꾸준히 갈아엎어 버리게 된다. 그것이 정상이다. 만들어놓은 소스의 뼈대가 십년이 넘은 것이다? 회사의 서비스가 멈추어있다는 증거이다. 길어야 7년 짧으면 2~3년안에 뼈대가 바뀐다. 그러므로 개발자들은 꾸준히 일을 해야 하고 기록을 남겨야 한다. 문제는 그렇게 일하던 개발자가 문서와 교육없이 퇴사를 해버렸을 때이다. 막장은 그 때부터 시작된다. 그리고 흔한 일상이기도 하다.
