2017.07.19

익명 기고 | '개발자가 털어놓는' 개발자의 비밀 9가지

Anonymous | InfoWorld
개발자는 왕이다. 그리고 개발자들은 그럴 만한 자격이 있다. 그러나 개발자들과 일하다보면 생각치 못 한 일들이 발생할 수 있다. 개발자들이 말하지 않는 이면의 진실 때문이다.



기업은 애플리케이션 개발을 통해 경쟁력을 크게 강화할 수 있다. 시장을 주도하는 모바일 앱이나 사업에 활기를 불어넣는 제대로 된 맞춤형 코드를 뚝딱 만들어낼 줄 아는 마법사들에게 투자해야 할 이유는 충분하다. 그러나 사실 우리 개발자들이 늘 솔직한 것은 아니다. 우리들 사이에서만 간직하고 싶은 몇 가지 비밀이 있다.

개발자들이 모든 것을 말하지 않는다는 사실은 이해할 만하다. 상대가 상사이기 때문이다. 상사에게 모든 것을 털어 놓지는 않는다. CEO가 의사결정 내용을 이사회에 일일이 알리지 않는 것과 마찬가지다. 그러니 개발자들에게 비밀이 있다고 해서 놀랄 일은 아니다.

회사 입장에서는 모르는 것이 나을 때가 있다. 개발자들이 자바(Java) 업데이트를 숨겨둔 디렉토리는 몰라도 된다. 백업 파일들이 암호화되어 있는 한 비밀번호에는 신경 쓰지 않아도 된다. 개발자들이 쓰던 도구를 마음대로 다른 것으로 바꾸더라도 회사 측에서는 그다지 신경쓸 필요가 없을 수 있다.

그러나 그렇지 않은 예외들이 있다. 이러한 예외들은 경영진과 개발자들의 월급은 물론 회사의 운명을 좌우할 수 있다. 비즈니스에 큰 영향을 끼칠 수 있는 개발자들의 비밀 9가지를 이 글을 통해 폭로한다.

- 개발자들은 생각만큼 잘 알지 못한다
- 기술 부채가 생각보다 훨씬 많다
- 개발자들은 흥미를 잃어서 이직 기회만 노리고 있다
- 개발자들은 자신들의 코드에 심취해 있다
- 개발자들은 유행에 집착한다
- 개발자들은 회사를 발전시키에는 너무 게으르다
- 개발자들은 유지관리보다는 구축을 선호한다
- 모든 앱을 꼭 다시 작성해야 되는 것은 아니다
- 개발자들은 사업 쪽은 잘 모른다


개발자들은 생각만큼 잘 알지 못한다
개발자들은 똑똑한 사람들이다. 그 중에는 진짜 천재들도 있다. 문제는 가끔 잘 모르는 것도 다 아는 척 한다는 점이다.

물론, 프로그래밍의 기초는 훤히 알고 있다. 루프 작성이나 데이터베이스에 질의 보내기 등은 척척 해낸다. 처음 보는 언어나 코드 베이스, 개발 도구를 접해도 기초가 튼튼해서 큰 문제가 없다.

그러나 회사에서 요구하는 것은 기본적인 것이 아닌 경우가 대부분이다. 가령, 기능 흐름을 수정해 달라는 요청이 들어왔을 때, 관련 코드가 실제로 어디 있는지 개발자들이 모르는 경우가 많다. 마침 운이 좋아서 알고 있다고 해도 막상 수정 작업이 쉬울지 어려울지 알 수 없다. 코드를 다운로드하여 몇 줄 새로 써 본 후 어떻게 되나 확인한 후에나 알 수 있다. 일정이 늦어지는 것은 프로젝트 범위가 계속 늘어나기 때문만은 아니다. 애초에 개발자들이 실질적인 업무 범위를 제대로 예상하지 못하기 때문인 경우가 많다.

그렇다고 해서 회의 때 “잘 모르겠는데요?”라는 말을 하는 이는 거의 없다. 어디서부터 시작해야 할지도 모르겠다거나 어떤 도구를 써야 최선인지 감이 안 잡힌다는 말을 듣고 좋아할 상사도 없다. 그러니 개발자들로서는 아무 숫자나 해법을 일단 내놓고 맞아 떨어지기를 빌 뿐이다. 만일 빗나간다면 “플럭스 콘덴서에 과부하가 걸렸다”는 식의 뭔가 있어 보이는 핑계로 둘러댄 후 개발자들이 제일 싫어하는 설명서 공부를 해야 한다.

기술 부채가 생각보다 훨씬 많다
기존 애플리케이션을 손볼 일이 생기면 경영진의 선택은 두 가지다. 개발팀에게 응급조치를 지시하거나 아니면 프로그램 전체 재설계를 지시하는 일이다. 응급조치를 하고 나면 기분도 좋고 비용도 적게 드는 것처럼 보인다. 회사 입장에서는 문제가 즉각 해결되니 좋고 개발자들 입장에서는 회사를 만족시키니 좋다. 회사를 만족시키는 일의 대부분은 개발자들이 좋아하는 일이다.

그러나 이렇게 대충 붕대와 테이프로 감아 놓는 식의 일이 늘어나다 보면 언젠가는 문제가 터지기 마련이다. 애초에 제대로 했어야 할 일임에도 불구하고 미봉책으로 인해 미뤄지는 이런 현상을 가리켜 “기술 부채”라고 부른다.

-> 기고 | 근절이 능사가 아니다··· '기술 부채' 측정 및 관리법

물론, 정확한 용어는 아니다. 부채를 갚을 필요가 없다. 운이 좋으면 재작업을 하지 않아도 소프트웨어가 계속 실행되기도 때문이다. 그러나 결국에는 중대한 사건이 발생해서 모든 것이 고장 나버리고 좀처럼 쉽게 해결할 수 없는 상황을 맞게 된다.

이러한 일은 가까운 협력업체가 소프트웨어 패키지를 최신 버전으로 업그레이드할 때 주로 발생한다. 갑자기 우리 업체의 코드가 실행이 안된다. 갑자기 모든 것이 고장 나버리고 우리 업체의 코드가 협력업체의 코드와 더 이상 통신이 되지 않는다.

이를 불쌍히 여긴 협력업체가 구형 게이트웨이를 계속 실행시켜 주는 경우도 있지만 그러한 자비는 우리 업체가 협력업체의 매출에 도움이 되는 경우에만 기대할 수 있다. 매출에 전혀 도움이 안되거나 도움이 미미할 경우 협력업체는 가차없이 결별을 선언할 것이다. 그러면 거래도 끊긴다.

개발자들은 흥미를 잃어서 이직 기회만 노리고 있다
회사의 가장 큰 과제는 회사의 코드에 대한 모든 것을 알고 있지만 그 코드로 하는 작업에 흥미를 잃은 똑똑한 개발자의 이직을 막는 것이다. 이 개발자는 문제 해결이나 기능 개선을 뚝딱 해치울 수 있다. 신입 개발자는 머리는 좋을지 몰라도 코드 베이스에 대해서는 아무 것도 모르기 때문에 똑같은 일을 해도 시간이 10배는 더 걸린다.

개발자들이 흥미를 잃는 이유는 셀 수도 없이 많다. 코드 작성 언어가 몇 년 전에 유행이 지난 구식 언어이기 때문일 수도 있고 애초에 코드를 짜느라 고생했던 안 좋은 기억 때문일 수도 있다. 테이블 너비를 조금 늘린다든가 배경 색깔을 좀 더 파랗게 하는 것은 이제 너무 쉬워서 새로운 도전 과제를 갈망하기도 한다.

똑같은 코드 작업을 꾸역꾸역 지루하게 반복해야 하는 개발자들의 고통을 덜어줄 방법은 별로 없지만, 가장 좋은 최신 프레임워크에서 코드를 새로 작성하게 해 준다면 효과가 있을지도 모른다.

시인 에즈라 파운드(Ezra Pound)는 다시 새롭게 하는 것(maket it new)이 시인의 과업이라고 했다. 관리자의 일도 그럴지 모른다. 적어도 개발자들의 이직을 막으려면 그래야 한다.

개발자들은 자신들의 코드에 심취해 있다
‘제가 인덱스오브(indexOf) 기능을 기가 막히게 활용한 거 혹시 보셨나요? 겨우 한 줄짜리 코드지만 쿠키 스트링을 완벽하게 분석해 낸답니다. 시간이 며칠 더 있었더라면 이 엄청난 기술로 세계 기아 문제까지 해결할 뻔 했다니까요?’

이처럼 개발자들은 자신들의 프로그램 기술에 스스로 도취해 있다. 판에 박힌 편안한 일상에 적응했으며 똑같은 어법을 반복해서 사용하기를 즐긴다. 외과 의사에게 찾아가면 모든 병은 수술이 필요하고 망치를 든 목수에게는 모든 게 못 박는 일로 보인다는 우스개 소리가 있다. 개발자도 사용 언어에 관한 한 마찬가지이다. 기술 언어든 객체 지향 코드든 어셈블리 코드든 간에 자기 마음에 드는 솔루션을 편애하고 고집한다. 회사에 의미가 있는지 여부는 안중에 없다. 
CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.



2017.07.19

익명 기고 | '개발자가 털어놓는' 개발자의 비밀 9가지

Anonymous | InfoWorld
개발자는 왕이다. 그리고 개발자들은 그럴 만한 자격이 있다. 그러나 개발자들과 일하다보면 생각치 못 한 일들이 발생할 수 있다. 개발자들이 말하지 않는 이면의 진실 때문이다.



기업은 애플리케이션 개발을 통해 경쟁력을 크게 강화할 수 있다. 시장을 주도하는 모바일 앱이나 사업에 활기를 불어넣는 제대로 된 맞춤형 코드를 뚝딱 만들어낼 줄 아는 마법사들에게 투자해야 할 이유는 충분하다. 그러나 사실 우리 개발자들이 늘 솔직한 것은 아니다. 우리들 사이에서만 간직하고 싶은 몇 가지 비밀이 있다.

개발자들이 모든 것을 말하지 않는다는 사실은 이해할 만하다. 상대가 상사이기 때문이다. 상사에게 모든 것을 털어 놓지는 않는다. CEO가 의사결정 내용을 이사회에 일일이 알리지 않는 것과 마찬가지다. 그러니 개발자들에게 비밀이 있다고 해서 놀랄 일은 아니다.

회사 입장에서는 모르는 것이 나을 때가 있다. 개발자들이 자바(Java) 업데이트를 숨겨둔 디렉토리는 몰라도 된다. 백업 파일들이 암호화되어 있는 한 비밀번호에는 신경 쓰지 않아도 된다. 개발자들이 쓰던 도구를 마음대로 다른 것으로 바꾸더라도 회사 측에서는 그다지 신경쓸 필요가 없을 수 있다.

그러나 그렇지 않은 예외들이 있다. 이러한 예외들은 경영진과 개발자들의 월급은 물론 회사의 운명을 좌우할 수 있다. 비즈니스에 큰 영향을 끼칠 수 있는 개발자들의 비밀 9가지를 이 글을 통해 폭로한다.

- 개발자들은 생각만큼 잘 알지 못한다
- 기술 부채가 생각보다 훨씬 많다
- 개발자들은 흥미를 잃어서 이직 기회만 노리고 있다
- 개발자들은 자신들의 코드에 심취해 있다
- 개발자들은 유행에 집착한다
- 개발자들은 회사를 발전시키에는 너무 게으르다
- 개발자들은 유지관리보다는 구축을 선호한다
- 모든 앱을 꼭 다시 작성해야 되는 것은 아니다
- 개발자들은 사업 쪽은 잘 모른다


개발자들은 생각만큼 잘 알지 못한다
개발자들은 똑똑한 사람들이다. 그 중에는 진짜 천재들도 있다. 문제는 가끔 잘 모르는 것도 다 아는 척 한다는 점이다.

물론, 프로그래밍의 기초는 훤히 알고 있다. 루프 작성이나 데이터베이스에 질의 보내기 등은 척척 해낸다. 처음 보는 언어나 코드 베이스, 개발 도구를 접해도 기초가 튼튼해서 큰 문제가 없다.

그러나 회사에서 요구하는 것은 기본적인 것이 아닌 경우가 대부분이다. 가령, 기능 흐름을 수정해 달라는 요청이 들어왔을 때, 관련 코드가 실제로 어디 있는지 개발자들이 모르는 경우가 많다. 마침 운이 좋아서 알고 있다고 해도 막상 수정 작업이 쉬울지 어려울지 알 수 없다. 코드를 다운로드하여 몇 줄 새로 써 본 후 어떻게 되나 확인한 후에나 알 수 있다. 일정이 늦어지는 것은 프로젝트 범위가 계속 늘어나기 때문만은 아니다. 애초에 개발자들이 실질적인 업무 범위를 제대로 예상하지 못하기 때문인 경우가 많다.

그렇다고 해서 회의 때 “잘 모르겠는데요?”라는 말을 하는 이는 거의 없다. 어디서부터 시작해야 할지도 모르겠다거나 어떤 도구를 써야 최선인지 감이 안 잡힌다는 말을 듣고 좋아할 상사도 없다. 그러니 개발자들로서는 아무 숫자나 해법을 일단 내놓고 맞아 떨어지기를 빌 뿐이다. 만일 빗나간다면 “플럭스 콘덴서에 과부하가 걸렸다”는 식의 뭔가 있어 보이는 핑계로 둘러댄 후 개발자들이 제일 싫어하는 설명서 공부를 해야 한다.

기술 부채가 생각보다 훨씬 많다
기존 애플리케이션을 손볼 일이 생기면 경영진의 선택은 두 가지다. 개발팀에게 응급조치를 지시하거나 아니면 프로그램 전체 재설계를 지시하는 일이다. 응급조치를 하고 나면 기분도 좋고 비용도 적게 드는 것처럼 보인다. 회사 입장에서는 문제가 즉각 해결되니 좋고 개발자들 입장에서는 회사를 만족시키니 좋다. 회사를 만족시키는 일의 대부분은 개발자들이 좋아하는 일이다.

그러나 이렇게 대충 붕대와 테이프로 감아 놓는 식의 일이 늘어나다 보면 언젠가는 문제가 터지기 마련이다. 애초에 제대로 했어야 할 일임에도 불구하고 미봉책으로 인해 미뤄지는 이런 현상을 가리켜 “기술 부채”라고 부른다.

-> 기고 | 근절이 능사가 아니다··· '기술 부채' 측정 및 관리법

물론, 정확한 용어는 아니다. 부채를 갚을 필요가 없다. 운이 좋으면 재작업을 하지 않아도 소프트웨어가 계속 실행되기도 때문이다. 그러나 결국에는 중대한 사건이 발생해서 모든 것이 고장 나버리고 좀처럼 쉽게 해결할 수 없는 상황을 맞게 된다.

이러한 일은 가까운 협력업체가 소프트웨어 패키지를 최신 버전으로 업그레이드할 때 주로 발생한다. 갑자기 우리 업체의 코드가 실행이 안된다. 갑자기 모든 것이 고장 나버리고 우리 업체의 코드가 협력업체의 코드와 더 이상 통신이 되지 않는다.

이를 불쌍히 여긴 협력업체가 구형 게이트웨이를 계속 실행시켜 주는 경우도 있지만 그러한 자비는 우리 업체가 협력업체의 매출에 도움이 되는 경우에만 기대할 수 있다. 매출에 전혀 도움이 안되거나 도움이 미미할 경우 협력업체는 가차없이 결별을 선언할 것이다. 그러면 거래도 끊긴다.

개발자들은 흥미를 잃어서 이직 기회만 노리고 있다
회사의 가장 큰 과제는 회사의 코드에 대한 모든 것을 알고 있지만 그 코드로 하는 작업에 흥미를 잃은 똑똑한 개발자의 이직을 막는 것이다. 이 개발자는 문제 해결이나 기능 개선을 뚝딱 해치울 수 있다. 신입 개발자는 머리는 좋을지 몰라도 코드 베이스에 대해서는 아무 것도 모르기 때문에 똑같은 일을 해도 시간이 10배는 더 걸린다.

개발자들이 흥미를 잃는 이유는 셀 수도 없이 많다. 코드 작성 언어가 몇 년 전에 유행이 지난 구식 언어이기 때문일 수도 있고 애초에 코드를 짜느라 고생했던 안 좋은 기억 때문일 수도 있다. 테이블 너비를 조금 늘린다든가 배경 색깔을 좀 더 파랗게 하는 것은 이제 너무 쉬워서 새로운 도전 과제를 갈망하기도 한다.

똑같은 코드 작업을 꾸역꾸역 지루하게 반복해야 하는 개발자들의 고통을 덜어줄 방법은 별로 없지만, 가장 좋은 최신 프레임워크에서 코드를 새로 작성하게 해 준다면 효과가 있을지도 모른다.

시인 에즈라 파운드(Ezra Pound)는 다시 새롭게 하는 것(maket it new)이 시인의 과업이라고 했다. 관리자의 일도 그럴지 모른다. 적어도 개발자들의 이직을 막으려면 그래야 한다.

개발자들은 자신들의 코드에 심취해 있다
‘제가 인덱스오브(indexOf) 기능을 기가 막히게 활용한 거 혹시 보셨나요? 겨우 한 줄짜리 코드지만 쿠키 스트링을 완벽하게 분석해 낸답니다. 시간이 며칠 더 있었더라면 이 엄청난 기술로 세계 기아 문제까지 해결할 뻔 했다니까요?’

이처럼 개발자들은 자신들의 프로그램 기술에 스스로 도취해 있다. 판에 박힌 편안한 일상에 적응했으며 똑같은 어법을 반복해서 사용하기를 즐긴다. 외과 의사에게 찾아가면 모든 병은 수술이 필요하고 망치를 든 목수에게는 모든 게 못 박는 일로 보인다는 우스개 소리가 있다. 개발자도 사용 언어에 관한 한 마찬가지이다. 기술 언어든 객체 지향 코드든 어셈블리 코드든 간에 자기 마음에 드는 솔루션을 편애하고 고집한다. 회사에 의미가 있는지 여부는 안중에 없다. 
CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.

X