1. 우리나라 현실에 맞는 코드 품질 향상 대안

 

최근 4개의 글에서 나는 눈에 보이는 기능에만 신경쓰고 눈에 보이지 않는 코드 품질은 무시하는

우리나라 IT 현장을 얘기했다. 이런 모습이 과거 일본이 미국과 맞짱 뜰수 있었던 막강

함대항공력의 괴멸과 다르지 않다고 얘기했다.

 

그렇다고 나는 어쩔수 없이 비용을 적게 들이는 등의 우리나라 IT 현실을 무시하고 무조건 원칙적으로

돈많은 미국 선진국처럼 프로젝트를 수행해야 한다는 것은 아니다.

 

나도 막상 과장급의 중간 관리자가 되다 보니 이런 글을 쓴적도 있다.

 

"윗 사람의 입장

일을 하면 일정은 정해져 있다. 일이 너무 많아 원하는 날까지 맞추기가 힘든때가 가끔 있다. 사실 가끔이 아니라 자주 있다. 대부분 주어진 일정대비 해야할 일이 많은 경우가 대부분이다.

 

나는 이런 경우 투덜거리면서 일한다. 나는 하고 욕먹는 스타일이다. 좀 말이 안되는 일정이라도 투덜거리면서 하긴 하는데 좋게좋게 일을 하진 않고 투덜거리면서 일한다.

 

지금 내가 윗사람이 되어 후배랑 같이 일을 하고 있다. 후배랑 업무분담을 하여 일을 한다. 나는 중간에 다른일에 투입되어 후배가 좀더 일을 더 해야 하는 상황에 놓였다. 업무분담을 하다보니 예를 들어 한 사람당 5일이 할당되어 있다면 주어진 일을 분석하니 후배는 7일 분량이다. 2일 분량이 주어진 일정보다 넘치게 되었다.

 

내가 합리적인 선배라면 일정을 더 연기해 줄 것이다. 그러나 위에서는 이 때까지 끝내주길 바란다. 나도 선배 입장이 되니 그냥 후배가 알아서 2일치를 더 일해주길 바라고 있다. 회사와 윗사람과 전체 일정에 지장을 끼치고 일정을 연기하느니 후배가 좀 더 고생하여 2일치를 애써 처리하여 이 이슈를 덮어주길 바라고 있다.

 

무심코 이런 욕심을 생각하는 나를 보며 무릎을 딱 쳤다. 아~ 윗사람의 마음이 욕심이 기본적으로 이렇구나.

 

조금 오버타임된 상황이라도 밑에 직원이 알아서 잘 해서 덮어주길 바라고 있다. 실제로는 후배가 힘들어하면 같이 십시일반하거나 일정을 내가 힘쓸만큼 연기해주고, 후배가 좀더 잘해줄수 있다면 적당히 잘 덮어주길 바랄것 같다. 지금은 상황이 바껴서 그냥 같이 고생하고 있다. 문득 윗사람의 입장이 이해가 되기도 한다."

 

 

+ 회사 입장에서 코드 품질을 확보하기 위한 대안

 

회사가 코드 품질을 확보한다는 것은 납기일을 현실적으로 늘려준다는 상황과 같다. 개발자가 합리적으로 일하도록 적당한 납기일을 주면 생각 있는 개발자는 알아서 코드 품질을 신경쓴다. 문제는 우리나라 SI 프로젝트가 납기일을 지나치게 작게 할당하기 때문에 발생한다.

 

회사 입장에서 모든 프로젝트에 코드 품질을 신경써서 납기일을 늘렸다가는 회사의 존망이 위태로울 수 있다. 회사가 살아야 코드 품질도 있는 법이다.

 

그러나 지금처럼 납기일만 너무 압박한다면, 유능한 개발자는 투덜거리다가 떠나고 엉터리 코드는 과거 일본의 항공모함처럼 폭탄 한방에도 침몰하는 대형 화재로 번질것이다.

 

회사내 작은 프로젝트, 또는 대형 프로젝트에 등급을 매겨본다.

 

1. 회사나 프로젝트에 기반이 되는 핵심 솔루션/프레임워크 개발

2. 1번과 3번이 섞인 경우

3. 기술력이 필요하지 않고 찍어내면 되는 업무 UI 개발

 

3. 기술력이 필요하지 않고 찍어내면 되는 업무 UI 개발

이 단순 반복 업무 UI 개발은 납기일을 압박하더라도 개발자가 실수로 버그를 만들더라도 코드 품질을 신경쓰지 않더라도 그렇게 큰 영향을 미치진 않는다. 이 경우는 납기일을 압박하더라도 회사 입장에서 1번 2번 처럼 큰 문제는 일어나지 않는다. 게시판을 개발하는데 연구 개발이 필요하니 2주일까지는 할당해 줄 필요는 없는 상황과 같다.

 

2. 1번과 3번이 섞인 경우

기술력이 필요하지 않고 찍어내는 업무 UI개발과 회사의 기술력의 바탕이 되는 중요한 모듈 개발이 섞인 경우이다. 대형 프로젝트이면 대부분 이런 경우일 것이다. 이런 경우 프로젝트를 1번과 3번으로 구분지어 1번은 시간을 넉넉히 주고 3번은 압박하면 투자대비 얻는 효과를 극대화 할 수 있을 것이다.

 

1. 회사나 프로젝트에 기반이 되는 핵심 솔루션/프레임워크 개발

해적선에 실린 보석처럼 회사의 값진 자산이 되는 솔루션/프레임워크 개발은 단순히 납기일 준수만 강요한다고 할수 있는 일이 아니다. 빨리 개발하는 것이 중요한것이 아니고 '잘' 개발하는 것이 중요하다.

 

잘 개발하는 것은 객체지향의 코드 품질 향상 기법을 이용하여 소프트웨어를 유연하고 확장성 있게 개발하는 것이다. 빨리 개발하는 것보다 잘 개발하는 것이 중요한 이유는 이 소프트웨어를 다른 개발자가 잘 쓰기 위해서 간결하고 편리한 API를 제공해서 개발 생산성을 높여야 하기 때문이다.

 

반복ㅇㅡ로 찍어내는 업무 UI 개발은 해당 코드를 다른 개발자가 쓸일이 거의 없지만 솔루션이나 프레임워크는 다른 개발자가 '잘' 써야 하기 때문에 파급 효과가 큰 소프트웨어 이다. 그래서 '잘'개발해서 다른 개발자에게 '잘'제공하는 것이 무엇보다 중요하다.

 

회사에서 1번의 개발같은 경우 과감하게 투자를 하는 안목도 필요하다.

 

 

+ 개발자 입장에서 코드 품질을 확보하기 위한 대안

 

개발자 스스로 생각한 바가 있어, 마치 보이지 않는 책상 뒷편의 못이 제대로 잘 박혔는지 확인했던 잡스의 아버지처럼 장인정신으로 코드를 잘 만들고 싶은데, 아무리 스스로 코드 품질을 신경쓰겠다고 다짐해도 회사가 납기일을 3/1, 2/1을 무 썰 듯 싹둑 잘라버리는 프로젝트에 들어가면 정답이 없다.

 

개발자가 코드 품질을 확보하려면 일단 코드 품질을 배려해주는, 납기일을 배려해주는 회사나 프로젝트에 들어가는 것이 중요하다.

 

코드 품질을 중요하게 생각하는 회사를 찾아야한다. 테스트 주도 개발, 애자일 개발 환경을 도입하는 개발자 문화가 고도화된 회사라면 다른 일반적인 SI 회사보다는 괜찮을것 같다. 솔루션이나 프레임워크 개발 회사는 돈이 궁해도 코드 품질을 신경 써야 회사도 도움이 된다는 것을 알기 때문에 상대적으로 납기일을 지나치게 압박하지는 못할 것이다.

 

개발자가 어느 회사든 들어가면 그때부터는 주어진 환경에 맞춰 코드 품질을 확보해야 한다. 코드 품질을 확보한다는 것은 코드를 객체지향적으로 개발한다는 뜻과 같다.

 

개발자 스스로도 자신이 개발하는 코드에 등급을 매겨본다.

 

1. 자신과 회사의 기술력 향상에 도움이 되는 핵심 솔루션/프레임워크 개발

2. 1번과 3번이 섞인 경우

3. 기술력이 필요하지 않고 찍어내면 되는 업무 UI 개발

 

3번인 경우는 패스.

 

2번인 1번과 3번이 섞인 경우 상사에게 어필을 해야 한다. 찍어내는건 빨리 개발할수 있지만 기술력이 필요한 개발은 시간을 얻어야 한다고 어필 해야 한다. 예를 들면 3번을 빨리 할테니 1번 개발에 시간을 달라고 '주고 받기' 협상을 시도한다.

 

1번 개발인 경우 회사에서 신경 써주지 않고 무조건 납기일을 압박하면 납기일 압박에 따른 코드 품질 희생의 책임은 나만 질수 없습니다~ 라고 나라면 분명히 얘기하겠다. 고생은 고생대로 하고 코드 품질 저하에 대한 책임도 본인만 질수는 없기 때문이다.

 

회사가 납기일 준수를 강조하는 이유를 전에 글에서도 얘기했지만 납기일을 넉넉히 주면 개발자들이 설렁설렁~ 일할까봐 걱정되기 때문이 크다. 회사가 코드 내부 품질을 알수 없는 이유도 있다. 그래서 납기일을 넉넉히 주면 내가 이렇게 유연하고 확장하기 쉬운 소프트웨어를 꼭 개발해서 회사의 이러이러한 혜택을 가져올수 있다고 어필하여 의심 많은 회사를 안심시키는 것도 방법이다.

 

 

나는 앉아서 공부만 한 연구 개발자도 아니고 나름 치열하고 괴로운 SI 현장에서 버틴 개발자이다. 나도 과장급이 되니 납기일을 압박해야 하는 관리자의 고충도 이해 된다.

 

나는 더도 덜도 말고 SI 할때는 평일날 저녁 9시 정도에 퇴근할 정도의 납기일 압박을 주었으면 살만하겠다. 월화수목금금금의 야근, 주말 근무 불사로 열심히 일하는 고생하는 드라마틱한 모습을 갑이 좋아하지 않고 개발자의 복지를 생각하여 개발자가 쾌적한 환경에서 개발할수 있도록 배려해줬으면 좋겠다.

 

평일 칼퇴근 하는 넉넉한 납기일이 아닌 평일 9시 정도에 퇴근할정도의 적당한 납기일 압박, 이런 정도가 외국 선진국은 아니지만 우리나라 현실에 맞는 적당한 타협점이 아닐까 생각한다.

 

 

우리나라도 세대가 바뀌고 있어 무조건 야근과 납기 준수를 강요하지 않는 회사도 생기고 있다. 좋은 소프트웨어 개발에 뜻이 있는 개발자라면 이런 좋은 회사를 찾아 입사할수도 있다. 개발자는 자신이 얻을 수 있는 정보를 모두 동원하여 테스트 주도 개발도 시도해보고 애자일 개발 환경도 구축하는 개발자 문화가 고도화된 좋은 회사에 입사하도록 노력 한다.

 

납기일 압박이 심하면 아무리 디자인 패턴을 만든 갱 오프 포의 위대한 현인이든, 스프링을 만든 창시자 로드 존슨이든 객체지향 적인 개발은 불가능하고 눈에 보이는 기능 개발에 주력해야 하기 때문이다.

 

덧 ) 이 객체지향의 탄생 원고는 제가 책으로 내려다가 일단 잘 안되었는데요. 이유는 비문이 많다. 단락내 주제가 중복된다. 어떤 상황 설명을 과장한다.등 입니다. 그래도 원고를 일단 블로그에 몽땅 풀어보고 언젠가 제대로 교정해서 다시 도전할 생각입니다. 이점을 감안해서 읽고 객체지향을 이해하는데 도움이 되셨으면 좋겠습니다. 의견도 주셨으면 좋겠습니다. 원고 조금만 교정하면 괜찮을것 같은 출판사 관계자분의 피드백도 환영합니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 산골
산골 블로그 소개 저는 하얀머리 개발자와 작가를 꿈꾸는 블로거 산골 입니다. 프로그램 개발자로서 저의 관심사는 개발자의 숨통을 트여준 아이폰 개발, 철학과 같은 깊이가 있는 객체지향 방법론입니다. 글쓰기와 수영을 좋아합니다. 블로그를 통해 관심사를 공유합니다. 제 블로그에 관심 있으시면 아래 RSS나 즐겨찾기로 편하게 구독하세요.

rss Bookmark and Share

댓글을 달아 주세요