태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

한국의 개발자는 쓸데없이 바쁘다

2014.10.14 09:45 by 전규현


잠시 후 Google blogger로 이동됩니다.







한국의 개발자들은 항상 바쁘다. 소프트웨어 개발을 하느라고 바쁜 것이 아니라 쓸데없는 일에 바쁜 것이 문제다. 회사마다 차이는 있지만 많은 회사에서 개발자들은 본연의 개발 업무보다 불필요한 다른 일에 바빠서 정작 본연의 임무인 개발에 투자하는 시간이 얼마 안되는 경우가 많다. 여기서 개발이라 함은 코딩뿐만 아니라, 분석, 설계, 리뷰 등 개발에 필요한 일련의 활동을 모두 말한다.

 

한국 회사들의 소프트웨어 개발 생산성이 상대적으로 선진 소프트웨어 회사보다 낮은 이유 중 하나는 개발자들이 개발에 전념하지 못하는 환경 때문이다. 

 

개발자는 고참이 될수록 개발에 집중하지 못하고 다른 일 때문에 바빠진다. 어느 회사의 고참 개발자들은 낮 시간에는 코딩을 한 줄도 못하고 남들 퇴근 후에 개발 일을 한다. 낮에는 이 회의, 저 회의 많이 끌려 다니기 때문에 집중해서 개발 관련 일을 할 수 없어 낮시간은 아예 포기하고 밤에 개발을 한다는 것이다.

 

코딩, 분석, 설계 관련된 모든 일은 대단히 집중력이 필요하기 때문에 중간에 다른 일로 방해를 받으면 다시 집중하기 매우 어렵다. 하루 종일 방해 받지 않고 집중해서 일할 수 있는 환경은 매우 중요하다. 

 

하지만 경영자들은 개발자도 시장을 잘 알아야 한다고 말하며 고객을 직접 만나게 하고, 시장 관련 회의에 참석하게 한다. 여러 경영 회의, 전략 회의에도 개발자들을 끌고 다닌다. 그러다보니 개발자들은 보고서도 작성해야 하고 보고 회의도 참석해야 한다.

 

고참 개발자일수록 이런 회의에 더 많이 불려 다니게 된다. 어쩔 때는 회의에서 꿔다 놓은 보릿자루 마냥 앉아 있기만 하면서 “왜 이런 회의를 참석해야 하나” 한탄을 하지만 회사 요구 때문에 빠지기도 눈치가 보여서 그냥 참석을 하는 경우가 많다. 물론 개발자도 시장, 고객, 경영 등 여러 분야에 대해 알아야 한다. 아키텍트나 팀장인 경우 더 잘 알아야 한다. 문제는 시간의 효율적인 활용이다. 이런 회의에 다 불려 다닌다고 더 잘아는 것은 아니다. 문서로 공유해도 되는 내용을 장시간 회의에 앉아서 시간을 허비하는 경우가 많다.

 

개발자들은 평가, 교육 활동으로도 많은 시간을 빼앗긴다.  필요한 일들이기는 하지만 너무 많은 시간을 빼앗기는 것이 문제다. 회사 교육담당자는 개발자들에게 교육을 많이 시켜서 도움을 주고 싶어하지만 일괄교육, 집체교육, 의무교육은 개발자들의 개발업무를 방해하는 요소다. 리더 교육을 열심히 한다고 팀장이 뛰어난 리더가 되는 건 아니다. 필요 없는 교육은 아니지만 얼마나 효율적인지는 생각해봐야 한다. 기업에서는 교육보다 실무 자체로 배우는 것이 더 중요하다. 

 

회의를 많이 하는 회사일수록 커뮤니케이션이 잘 안되고 누가 뭘 하는지 잘 모르는 경우가 많다. 회의가 과도하게 많다는 것은 공유와 협업이 잘 안되고 있다는 반증이기도 하다. 대기업에서 개발자가 더 일하기 힘든 이유가 여기에 있다. 대기업은 회사마다 다르지만 기본적으로 회의도 많고 프로세스도 복잡하다. 정작 진짜 개발하는 시간은 몇시간 안된다. 

 

그럼에도 대기업이 돌아가는 이유는 우수한 인력과 여유 인력, 자본이 풍부하기 때문이다. 50% 퍼포먼스만 발휘해도 회사는 굴러간다. 이런 비효율이 회사가 잘 될 때는 문제가 안되지만, 어려울때는 큰 약점이 된다. 
그런데 중견기업 중에는 이런 대기업 형태를 따라하는 회사들이 꽤 많다. 회사가 커지다보니 관리의 필요성이 증가해 개발자들의 시간을 점점 빼앗는 것이다. 그러다보면 대기업의 장점인 관리 부문에도 만족하지 못하고 기존의 민첩하고 효율적인 개발 방식도 점점 잃게 된다. 

 

기본적으로 이렇게 회사에서 개발자들이 개발에 집중하지 못하게 방해를 하는 이유는 개발자를 믿지 못하기 때문이다. 심지어는 초등학생 취급하는 경우도 있다. 개발자들이 알아서 자율적으로 제대로 일할 것이라고 믿지 못하기 때문에 결과는 점점 효율성이 떨어지는 것이다. 

 

원칙적으로는 개발자는 거의 개발만 해야 한다. 숫자로 얘기를 하면 95% 이상의 시간은 개발에 전념할 수 있도록 해야 한다. 분석, 설계, 리뷰, 코딩 등 개발 활동에 쏟아야 한다. 중간에 방해를 하지 않도록 프로세스, 시스템이 최대한 뒷받침을 해야한다. 

 

대부분의 회사에서 회의는 10분의 1 정도로 줄여야 한다. 조금이라도 관련이 있는 사람은 잔뜩 불러서 하는 대규모 회의는 특히 삼가 해야 한다. 괜히 일상적으로 모여서 하는 대규모 회의도 줄여야 한다. 필요한 사람 몇명만 불러서 사안 별로 회의를 하면 된다.그렇다고 개발자가 고객, 시장, 전략을 몰라도 된다는 것은 아니다. 시간을 최대한 효율적으로 활용해서 최소 시간을 투자해서 공유를 할 수 있어야 한다. 개발자의 시간은 비싸다. 

 

실제로 개발자가 하루에 개발에 몇시간을 사용하는지 조사를 해보자. 80% 미만이면 심각하게 생각해야 한다. 그런 개발자는 개발을 포기하고 전문 관리자가 되는 것이 낫다. 그렇지 않다면 무엇인 문제인지 찾아서 문제를 제거하고 개발자들이 개발에 집중할 수 있도록 해줘야 한다. 이슈관리시스템을 제대로 활용하면 불필요한 회의는 많이 줄일 수 있고, 회의를 하더라도 시간을 단축할 수 있다. 회의를 줄이고 효율적으로 하는 방법은 여러가지가 있지만 다음과 같은 원칙을 지키는 것이 좋다. 

 

대규모 회의보다는 소규모 회의를 하고, 공유는 시스템으로 하고 의사결정이 필요할 때만 회의를 한다. 회의 전에 내용을 미리 공유해서 짧은 시간에 의사결정을 해야 한다. 회의 내용은 관련자 모두에게 즉각 공유해야 한다. 

 

소프트웨어 개발 경쟁력에서 핵심은 개발자다. 개발자가 많은 시간 개발에 집중할 수 있도록 하는 것은 소프트웨어 경쟁력 향상에서 가장 중요한 일이다. 이렇게 하면서도 공유, 커뮤니케이션에 문제가 없을 수 있도록 하는 것이 개발 문화, 프로세스, 기반 시스템의 역할이다.


이 글은 ZDNet Korea에 기고한 칼럼입니다.

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발문화, 기반시스템, 집중, 프로세스

  1. 안녕하세요? 정성들여 쓰신 글 잘 보았습니다. 저도 IT와 관련하여 블로그를 개설해보고 싶습니다. 초대해주시면 안될까요? :)

  2. 제가 초대해드려요?

  3. Blog Icon

    비밀댓글입니다

  4. Blog Icon
    윤남기

    글 잘 보고 있습니다. 최근에 많이 읽게 됐는데 이렇게 좋은 글 올려주셔서 감사합니다.

개발자에게 재택 근무가 필요한 이유

2014.06.17 22:51 by 전규현


잠시 후 Google blogger로 이동됩니다.







과거 서울 남부의 경기도에서 소프트웨어 개발자를 채용할 때였다. 서울에서 별로 멀리 떨어져 있지 않은 경기도에 있는 곳인데도 많은 지원자들이 거리상의 문제로 지원을 포기 했고, 특히 서울 북부에 사는 사람들은 인터뷰 시에도 출퇴근의 어려움에 대한 걱정을 토로했다. 

 

얼마 전 한 소프트웨어 회사는 서울에서 판교로 사옥을 이전했다. 그런데 서울 북부나 일산 등지에 사는 직원들을 주축으로 많은 개발자들이 회사 이전과 동시에 퇴사를 했다. 특히 몇몇 핵심 개발자들의 퇴사는 회사의 큰 손해가 아닐 수 없었다. 

 

아직도 우리나라 소프트웨어 회사의 근무형태는 농업사회에서 보여주는 전통적인 근면 성실을 강조하는 근무 시스템에서 크게 벗어나지 못하고 있다. 시간에 맞춰서 출퇴근을 하고 야근까지 하면서 상사에게 오랜 시간 열심히 땅을 파는 모습을 보여줘야 ‘열심히 일을 하고 있구나’ 하며 안심을 한다. 이런 현상을 보면 소프트웨어 개발이 지식 산업이 아닌 노동집약적 산업이라고 오해하고 있다는 생각이 든다. 

 

이렇게 시간 딱딱 맞춰서 사무실 자리에 앉아서 일을 해야 하는 시스템은 많은 한계를 가지고 있다. 대한민국이 아니라 미국이라면 어떨까? 거리의 제약은 수십배로 커진다. 많은 개발자들은 회사 근처로 이사를 하기도 하지만 재택 근무 형태로 일하는 개발자도 많다. 

 

재택 근무가 가능하면 회사에 꼭 필요한 개발자를 거리의 제약 없이 채용 할 수 있다. 같은 재택근무라도 상황에 따라서 근무 조건은 매우 다양하다. 일주일에 한번씩 출근을 하기도 하고 아예 원격으로 일하는 개발자들도 있다.

 

우리나라에서는 직장이 너무 멀어서 출퇴근에 2, 3시간씩 걸려도 아이들 학교 문제도 있고 직장을 옮길 때마다 이사를 하기는 쉽지가 않다. 그래서 개발자 채용에 거리 제약이 있고 회사에 꼭 필요한 개발자인데도 채용하기 어려운 경우도 많다. 

 

재택근무가 일반적이지 않은 이유는 옆에 앉아 같이 일하지 않으면 일이 제대로 진행되지도 않고 어떻게 일을 하고 있는지 알 수도 믿을 수도 없기 때문이다. 같이 모여서 일하지 않으면 일이 제대로 진행되지 않는다. 

 

필자는 여러 회사에서 강연이나 세미나를 할 때 종종 “여러분이 모두 회사에 나오지 않고 집에서 원격으로 일하면 어떻게 됩니까?”라는 질문을 한다. 100%의 회사들이 일이 전혀 제대로 진행되지 않을 것이라고 얘기를 한다. 개발자들은 허무맹랑한 질문이라는 표현을 하기도 한다. 이는 단지 재택근무가 가능한지 불가능한지 문제는 아니다. 

 

재택근무가 불가능한 회사는 문화적으로 프로세스적으로 개선할 점이 많은 회사다. 회사가 개발에 필요한 시스템을 잘 갖추고 있고 공유와 문서화가 잘 되어 있으면 재택근무는 그렇게 어려운 일이 아니다. 오히려 집에서 일하는 것이 더 효율적인 경우가 많다. 

 

재택근무가 불가능한 회사에서는 개발자들이 수시로 물어보고 의논을 하고 회의도 해야 한다고 한다. 이런 환경을 보면 회의가 너무 많고 공유와 문서화가 잘 안되어 있다는 것을 단적으로 알 수 있다. 문서나 시스템으로 대부분의 내용은 공유하고 대부분의 커뮤니케이션은 시스템을 통해서 해야 한다. 회의도 스카이프등을 이용해서 원격으로 할 수 있다. 

 

꼭 대면회의가 필요한 경우에 회사를 나오면 된다. 이런 환경이 갖춰지면 재택근무가 가능하다.

 

재택근무를 하면 개발자들이 열심히 일하는지 알 수 없어서 그렇게 할 수 없다는 회사 관계자도 만난 적이 있다. 하지만 회사에 있으면 열심히 일하는지 알 수 있는가? 시스템, 문화와 프로세스가 제대로 되어 있으면 개발 성과와 결과물이 시스템에 제대로 남고 동료 검토를 통해서 동료들이 서로 누가 어떻게 일하는지 다 알고 있다. 

 

옆에서 일하나 멀리서 일하나 다 알 수 있다. 하지만 그렇지 않으면 옆에서 일해도 커뮤니케이션이 어렵고 누가 열심히 일하고 누가 놀고 있는지 잘 알지 못하는 경우가 많다. 

 

지금 당장 이런 성숙된 문화와 효율적인 프로세스와 시스템을 갖추지 않고 재택근무를 추진한다면 어떻게 될까? 우려하고 있는 모든 문제가 드러날 것이다. 재택근무는 거리의 제약을 뛰어넘어 뛰어난 개발자를 채용할 수 있게도 할 뿐만 아니라 가정에 사정이 있는 개발자도 회사를 그만두지 않아도 된다. 

 

가정 사정상 아이를 돌보기 위해서 회사에 10시부터 3시까지 밖에 있지 못하는 뛰어난 개발자가 있다고 하자. 이렇게 일하는 것을 어떻게 허용할 것인가? 누구는 일주일에 이틀밖에 회사에 나올 수 없다고 하자. 이런 개발자가 회사에 꼭 필요한 사람이라면 채용해서 활용할 수 있을 것인가? 

 

재택근무는 그 자체로도 필요하고 회사의 문화나 프로세스의 성숙도를 가늠할 수 있는 지표로 볼 수도 있다. 필자는 회사에서는 야근을 별로 하지 않고 야간과 주말을 가리지 않고 회사의 시스템에 붙어서 이슈를 확인하고 의논을 하며 코드리뷰를 하는 등스스로 찾아서 일을 하는 것이 일상화 되어 있다. 가족이 나를 필요로 할 때 가족과 지낼 수 있으며 언제 어디서나 일할 준비가 되어 있고 일을 할 수 있다. 주말에도 굳이 회사에 나가지 않아도 원격으로 쉽게 일할 수 있다. 시간, 공간적인 제약은 별 문제가 되지 않는다. 

 

우리 회사는 개발자들의 재택근무가 가능하지 생각해보자. 현재는 어렵다는 생각이 든다면 그 이유가 회사에서 모여서 일할 때도 비슷한 문제를 가지고 있을 가능성이 높다. 어떻게 고쳐나가야 하는지 생각해보자. 재택근무가 가능한 시스템이 회사의 개발 문화 성숙도를 한층 높여줄 것이다.


이글은 ZDNet Korea에 기고한 글입니다.

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발문화, 시스템, 재택근무, 프로세스

  1. Blog Icon
    김한준

    항상 좋은 글 잘 읽고 있습니다. 특히 공유와 문서화의 힘이 언급될 때 많이 공감합니다.

  2. Blog Icon
    박경호

    좋은 글 잘 읽었습니다. 나름 제 상황과 비교하면서 읽게 되네요.

    글 처음부터 끝까지 읽으면서 계속 남아있던 한가지 질문은 '어떻게 믿지'입니다.
    물론 이 질문도 받아보셨겠지만 신뢰에 대한 얘기도 해주셨으면 합니다.

    지방 중소기업은 인력 구하기가 힘듭니다. 좋은 인재와 같이 일한다면 좋지요.
    허나 그 사람의 실력이 어떻든간에 멀리 떨어져 있는 사람을 재택근무로 채용한다는건 쉬운 일이 아닙니다.

    나름 깊은 고민입니다. 글쓴이님의 글에 해답이 있었으면 하는 바람입니다.

  3. 단순히 믿음의 문제는 아니고 시스템, 프로세스, 문화가 뒷받침이 되어야 합니다.
    일하는 시간으로 일하는 것을 측정하는 것이 아니고 해야할 일이 명확하고 결과로 측정되며 해야할 일은 시스템에 모두 기록되고 모든 사람이 온라인으로 일하는 것을 지켜봅니다. 이런 형태의 업무가 자연스러워지려면 상당한 시간 투자와 의식의 변화가 필요합니다.

  4. Blog Icon
    jYou

    맞는 말입니다..
    다만 사무실에 나오면 열심히 일하는지 안하는지 알 수 있는 방법이 있습니다.
    바로 자리에 엉덩이 깔고 잘 있고 윗사람의 되도 않는 질문에 굽신대면 일을 잘 열심히 한다고 생각들 하죠 ㅎㅎ
    이런 좀 안좋은 문화가 바뀌고 문서화와 공유라는 문화가 정착되기 전까지는 진짜 어려울 것 같다는 생각이 듭니다.. 그런 이유의 끝에는 고용주가 고용한 사람을 그저 나의 이득을 위해 부리는 사람이라는 인식만 갖고 있지 같이 달려나간다는 공동체(?)의식 같은게 없는 상명하복의 갑질 마인드가 제일 근본이라고 생각됩니다 : )

  5. 좋은 글 잘보고 갑니다.^^

  6. 좋은 글 잘 봤습니다. 개발자 입장에서, 사실 재택근무도 근무지만, 탄력 근무제가 먼저 자리를 잡았으면 좋겠습니다. 시스템이나 프로세스의 정립이 어느 정도 이루어질 것이며 또, 시간이 아닌 TASK로 관리되는 초석이 될 수도 있다고 생각합니다. 하지만 그래도 우리나라를 봤을 때 회의적인 것은, 특히 SI/SM의 을 관계일때에는...어느 고객사가 좋아할것이며 어느 고객이 이해할것인지... 휴.

  7. Blog Icon
    csh7963

    기본적으로 재택근무에 관한 필요성은 이해합니다. 다만 회사의 관점에서 보면 재택근무는 재택근무자에 의해서 저작된 회사 자산에 관한 보안 취약성에 관한 문제가 있습니다. 이러한 부분에 대한 대안을 어떻게 생각하시는지 궁금합니다. 재택근무와 관련해서 기업 측이 가장 중요하게 생각하는 문제가 그것인데 여기에 대한 언급은 없네요.

  8. Blog Icon
    지젝

    정확히 기억은 안나지만, 김익환님의 글로벌 소프트웨어를 말하다에 보면 이런 말이 있더군요. 기본적으로 실리콘밸리는 정보 유출에 대한 법이 엄청나게 강하기 때문에, 개인이 정보유출을 할 생각을 하지도 않는다구요. 우리나라도 그런 기반 법제화가 필요할 것 같습니다.

    그리고 우리나라 소스코드는 보안에 힘 쓸 정도로..대단하지도 않다고 하는 이야기도 하시더군요 ㅋㅋ 어느정도 동감합니다.

  9. Blog Icon
    csh7963

    소스 코드가 보안에 힘쓸 정도로 대단한지...에 관한 이야기는 보안이라는 주제와는 다른 주제입니다. 이 부분은 별도로 다루는 것으로 하고... 기업의 보안 및 자산관리에 관한 시스템화 대책은 재택 근무 이전에 반드시 해결되어야 합니다.

  10. 보안은 별도의 광범위한 주제라서 간단히 얘기할 주제는 아니라고 생각합니다. 단적으로 국방부 프로젝트를 회사는 관련 자료를 집에도 가져갈 수도 없고 집에서 인터넷으로 관련 정보에 접근할 수도 없어서 재택근무를 할 수도 없고 해서도 안됩니다.

    매우 개방적인 회사도 보안은 철저해야 합니다. 소스코드야 그렇다 쳐도 회사의 전략이나 수많은 문서들은 대부분이 공개되어서는 안됩니다. 시스템적으로 VPN을 사용하거나 철저한 회사는 요즘 가상화 솔루션을 쓰기도 하지만 시스템으로 모두 해결하는 것은 불가능하고 보안 및 저작권에 대한 교육도 철저히 해야 합니다. 자칫하면 형사 사건이 되는데 그 심각성을 잘 인식시켜야 합니다.

    회사마다 필요한 보안의 수준이 달라서 획일적으로 얘기할 수는 없고 회사에 알맞게 잘 대비를 해야겠습니다.

  11. Blog Icon
    csh7963

    글세요. 일부 답변의 접근 방식은 좀 잘못된게 아닌지 싶네요. 재택근무라는 주제의 논의가 진행되는한 보안이라는 키워드는 별도의 주제가 아닌 재택근무의 전제조건이 되어야 한다고 생각합니다. 국방 분야고 어떤 분야고를 떠나서... 어떠한 기업주가 되었건, 자신이 급여를 지급해서 개발한 산출물이 직원들의 재택에 있는 개인 PC에 저장되고 있는 상황을 과연 기업주가 원할까요? 기업 보안의 수준이 어떠하든 간에 해당 기업주는 같은 요구를 할 것입니다. 회사 직원이 아닌 프리렌서라면 다른 조건의 계약을 하겠지만, 회사에 고용된 직원이 보안을 무시하면서까지 재택근무를 논한다는 것 자체가 어불 성설입니다.

개발 프로세스 관료화의 함정

2014.01.18 09:38 by 전규현


잠시 후 Google blogger로 이동됩니다.





소프트웨어를 효율적으로 개발하는 비법 아닌 비법은 개발 프로세스와 개발 문화의 적절한 균형에 있다. 김치를 담그는 레시피처럼 확실한 비율을 정하기는 어렵다. 개발 프로세스는 양날의 칼이다. 적절히 사용하면 개발 효율은 올라가지만 조금만 잘못 써도 개발 생산성이 떨어질 뿐만 아니라 개발자 성장까지 저해하여 회사와 개발자 모두의 미래를 어둡게 만든다.

 

다른 산업 분야에서는 외국에서 몇백년동안 쌓아온 것을 우리는 몇십년만에 따라 잡은 분야가 꽤 있다. 하지만 소프트웨어는 기껏해야 60년 역사인데 따라잡기가 훨씬 어렵다. 개별 개발자들의 프로그래밍 실력은 결코 뒤진다고 볼 수는 없다. 하지만 전반적인 개발문화의 차이가 격차를 좁히지 못하는 원인 중 하나다. 

 

소프트웨어 분야에 대한 투자는 개발자 인원수 늘리기와 프로세스 강화에 많이 치우친 경향이 있다. 소프트웨어도 시그마6 등과 같은 기법을 따와서 프로세스를 강화하면 좋은 성과를 낼 수 있을 것으로 착각했기 때문이다.

 

이렇게 프로세스에 집중하면 '파킨슨의 법칙'처럼 프로세스 관료화의 함정에 빠지기 쉽다. 프로세스는 회사의 변화에 따라 끊임없이 효율적으로 개선이 되어야 하는데 관료화된 조직은 프로세스가 점점 복잡해지지 단순해지지는 않는다. 프로세스가 단순해지고 효율적으로 바뀌면 일이 없어지는 사람이 있기 때문에 점점 복잡하게 만들려는 경향이 있다. 

 

물론 모든 기업이 그런 것은 아니다. 이런 함정에 빠지지 않은 기업도 있고, 이 단계를 극복해 나가는 기업이 있다는 것을 알고 있다. 하지만 많은 기업들이 이미 프로세스 관료화의 함정에 빠져서 허우적대거나 관료화의 길로 달려가고 있다. 이를 경계하자는 것이다.

 

그럼 개발 프로세스가 빠지기 쉬운 함정에는 어떤 것이 있는지 알아보자. 

 

첫째, 현실성이 부족한 프로세스다. 

 

실제 개발 현장에서는 벌어지지 않는 교과서에나 나오는 것을 실제 개발에 적용하려는 것이다. 가장 광범위하게 벌어지고 있는 현상 중 하나다. 인터넷에서 돌아다니는 지식이나 책을 보고 따라 하거나 소프트웨어 공학을 전공했지만 실전 경험이 부족한 경우 자주 벌어진다. 개발 단계별로 너무 많은 문서를 요구하거나 승인을 필요로 하는 프로세스가 있다. 

 

원자력 발전소를 만들 때나 필요함직한 문서들을 일반 소프트웨어에서 요구하기도 한다. 이런 문서는 개발할 때도 도움이 안되고 개발 후 유지보수 때도 별로 쓸모가 없게 된다. 마켓요구사항과 기능, 모듈을 추적하기 위해서 추적 매트릭스를 의무적으로 요구하는 프로세스도 있다. 

 

교과서에서 본적이 있을지는 몰라도 대부분의 소프트웨어에서는 필요도 없고 오히려 방해만 되는 프로세스다. 이렇듯 현실성이 부족한 프로세스는 너무나 흔하다. 개발자들은 어쩔 수 없이 따르는 척은 하지만 대부분 피해가는 요령만 늘게 되고 개발 경험이 쌓이면서 자연스럽게 역량이 성장하는 것을 방해하게 된다. 

 

개발 프로세스는 성숙된 개발환경에서 수십년 실전 경험이 풍부한 CTO급 개발자가 이끌어야 현실성 있고 효율적으로 만들 수 있다. 

 

둘째, 너무 상세하고 획일화된 프로세스다. 

 

프로세스팀이 너무 일을 열심히 하려고 할 때 발생한다. 프로세스는 모든 개발절차를 상세히 정의하기 보다 문제가 될 수 있는 핵심적인 요소를 잘 집어내는 것이 중요하다. 법률에도 비슷한 현상이 있다. 할 수 있는 것을 정의해서 법에 정한 것만 할 수 있게 하거나 하면 안되는 것을 정의해서 그 외에는 모두 할 수 있게 하는 방법이 있다.

 

모든 절차를 너무 상세하게 정의하면 개발자의 창의성을 저해하고 비효율적으로 흐를 수 있다. 오타 하나를 수정한 경우에도 작성해야 할 문서가 몇 개나 되고 절차도 일주일 이상 걸린다는 하소연을 들은 적이 있다. 개발자에게 자유도가 없이 몇 가지 경우로 획일화된 프로세스에서는 효율적으로 개발을 하기가 어렵다. 

 

개발자를 믿지 못하기 때문에 개발자에게 자유도를 주지 않는 경우이다. 

 

최근에 한 기업의 프로세스팀 리더를 만난 적이 있는데 설계문서를 매우 상세하게 작성을 해야 하며 꼭 UML로 작성을 해야 한다고 했다. UML을 이용하지 않고 개발자가 제각각 작성하면 서로 의미가 통하지 않을 수 있다고 한다. 나는 그럴 필요가 없고 개발자가 가장 편하게 작성할 수 있는 방법이면 되고 꼭 UML을 쓸 필요도 없다고 했다. 

 

화이트보드나 종이에 끄적거리고 토론하다가 사진을 찍어서 문서에 첨부해도 된다고 했다. 물론 이 부분은 논란이 있을 수 있다. 스펙과 설계의 경계에 대한 생각이 다르고 설계를 상세하게 작성해야 개발자들이 코딩을 잘 할 수 있다고 획일적으로 생각하는 것도 문제다. 

 

설계란 상황에 따라서 필요한 만큼 자유롭게 적절히 하는 것이 중요하고 형식보다는 창의력이 더 필요하다. 
셋째, 잘못된 관행을 그대로 담은 프로세스다.

 

프로세스팀의 힘이 약한 경우에 발생한다. 개발 프로세스를 정의할 때는 현재의 문제점을 고치고 개발역량을 미래지향적으로 향상시킬 수 있는 방법을 녹여내야 한다. 하지만 현재의 관행적인 절차를 체계화하고 문서화해서 기존의 문제점을 그대로 유지한다면 그야말로 최악이다. 

 

절차화 되면서 기존에 개발자들이 자유도를 가지고 적절하게 판단하던 효율성도 사라졌고, 미래지향적이지도 않다. 기존의 문제가 점점 고착화 되어 갈 뿐이다. 

 

개발자들의 의견을 너무 존중해서 민주적인 다수결로 프로세스를 결정하는 것도 문제다. 변화를 싫어하는 것은 동서고금 똑같아서 대중의 의견을 따르면 프로세스는 대부분 실패한다. 

 

넷째, 벌칙만 잔뜩 담은 프로세스다.

 

프로세스는 잘못하면 벌을 주려는 형법과는 다른 것이다. 목적 자체가 다르다. 프로세스는 효율적인 개발을 하기 위한 최소한의 절차다. 그리고 프로세스를 따라서 꾸준히 개발을 하면 개발팀의 역량도 향상 되어야 한다. 따라서 적절한 독려와 벌칙이 있을 수는 있다. 하지만 벌칙만 잔뜩 존재한다면 벌칙을 피해 다니는데 집중하게 된다. 물론 치명적인 잘못에 대해서는 벌칙이 있을 수 있다. 치명적인 잘못에는 다음과 같은 것들이 있다. 

 

-소스코드를 빌드가안되는브로큰 트리(Broken tree)를 만든 경우 
-백업 담당자가 백업을 소홀히 한 경우 
-소스코드를 소스코드관리시스템에 등록하지 않은 경우 
-핵심 프로세스를 따르지 않아서 큰 장애를 만들어 낸 경우 

 

여기서 버그를 만든 경우는 벌을 받아야 할 만큼 큰 잘못은 아니다. 그런데 버그를 카운트해서 불이익을 주거나 프로세스의 모든 사소한 사항까지 벌칙과 연계를 하면 숨막혀서 개발하기가 쉽지 않다. 

 

다섯째, 점점 복잡해지는 프로세스다. 

 

회사는 계속 바뀌고 제품 및 개발팀도 계속 성장한다. 그러면서 프로세스도 계속 진화를 한다. 그런데 매번 프로세스가 점점 복잡해지는 회사들이 많다. 무슨 문제가 있을 때마다 원인을 분석하고 대책을 수립한다고 하면서 확인 절차를 더 추가하고 문서를 더 만들어 내는 것이다. 

 

이렇게 문제가 있을 때마다 대책을 수립한다고 하면 초 단기적인 대책밖에는 만들어 낼 수 없다. 예를 들어서 근본 원인이 '공유의 문화'가 부족해서라고 해도 수년 걸리는 '공유의 문화' 개선보다는 당장 눈에 보이는 형식적인 절차를 끼워 넣을 수 밖에 없다. 

 

냄비 안의 개구리는 점점 따뜻해져 오는 물을 느끼지 못하지만 나중에 밖에서 프로세스를 보게 되면 괴상망측하게 변화된 것을 알 수 있다. 프로세스는 역량과 문화 수준이 향상됨에 따라서 점차 간소하게 바뀌어야 한다. 기존에는 프로세스로 강제화하던 것이 몸에 베이게 되면 간단하게 바꿔야 더 효율적이다. 

 

여섯째, 관료화된 프로세스다.

 

관료화된 조직에서 흔히 벌어지는 일이다. 개발 문제를 해결하기 위해서 프로세스를 강조하다 보면 프로세스 자체가 목적이 되기도 한다. 효율적인 방법이 눈에 뻔히 보이는 경우에도 프로세스가 그러하니 따라야 한다고 하게 된다. 개발 생산성 향상이라는 목표는 저 멀리 떠나 보내고 각자 팀의 이익을 쫓다 보면 프로세스가 점점 관료화로 치닫게 된다. 

 

가끔은 없어도 되는 절차를 일부러 만들기도 한다. 개발자들은 이를 피해가는 요령만 늘게 된다. 

 

물론 열심히 노력하고 잘하는 프로세스팀이 더 많지만 그 중에는 개발 효율성보다는 스스로의 일거리를 늘리고 힘을 키우기 위해서 프로세스를 더 복잡하게 만들고 개발에 끼어드는 경우가 있다. 프로세스팀이 모든 개발 절차를 감시하고 산출물을 검토하고 승인에 끼어드는 경우 관료화게 빠지기 쉽다. 도와주는 역할을 넘어서 스스로 권력화가 되는 것이다. 

 

결론은 개발 프로세스는 현실적이며 자율적이어야 하고 개발 문화와 균형을 이뤄야 한다. 아직 자율에 맡기기에는 불안하다고 하면 프로세스를 너무 복잡하게 하지 말고 핵심적인 것부터 조금씩 적용하는 것이 좋다. 
개발자가 즐겁게 일할 수 있는 환경이 가장 생산성이 높은 환경이다. 개발 프로세스를 엄격하게 강화하여 소프트웨어 개발 문제를 해결 할 수 있다는 생각부터 잘못된 것이다. 적절한 개발 문화가 뒷받침되지 않는 프로세스는 오히려 짐이 될 뿐이다. 

 

눈에 보이는 프로세스에는 투자를 하기가 쉬워도 눈에 잘 안 보이는 개발문화는 어떻게 투자를 해야 할지 막막하다. 자칫 잘못하면 사무실 환경이나 슬로건만 흉내를 내는 꼴이 될 수도 있다. 

 

문화가 바뀌려면 생각이 먼저 바뀌어야 행동이 바뀐다. 하지만 생각은 그렇게 쉽게 바뀌지 않는다. 힘이 있는 선구자가 끊임없이 생각의 변화를 이끌어야 한다. 프로세스가 관료화에 빠지지 않으려면 CTO급의 특급 개발자가 실전 개발 기법을 프로세스에 적용하고 개발문화 향상을 꾸준히 이끌 수 있도록 해야 한다. 

 

미신과 같은 이론 전문가들의 말과 인터넷에 떠도는 소문에 현혹되지 말고 진짜 전문가인 개발 전문가들을 보호하고 힘을 실어줄 때가 변화의 시작 시점일 것이다.


이글은 ZDNet Korea에 기고한 칼럼입니다.

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발문화, 관료화, 프로세스

주먹구구식 개발이 통하는 이유

2012.08.27 06:46 by 전규현


잠시 후 Google blogger로 이동됩니다.





우리나라의 많은 소프트웨어 회사들은 주먹구구식 개발에 대한 환상이 있다.

특히, 첫번째 시스템을 주먹구구식으로 개발을 해서 성공했는데 지금은 좀더 체계를 갖췄는데 더 개발이 잘 안된다면 과거 진짜 주먹구구식으로 개발할 때를 그리워하고 그 때로 돌아가고 싶어 한다.


여기 이와 관련된 과거 글이 있다. 

2012/07/26 - [소프트웨어이야기] - 옛날에는 개발을 더 잘했는데


주먹구구식으로 개발을 하다가 현재 체계를 갖추려고 노력하고 있다면 아직은 불완전할 뿐더러 반쯤은 주먹구구인 것이다. 그럼 주먹구구식 개발은 어떤 것인지 정의를 내려보자. 크게 5가지로 설명할 수 있다.


첫째, 스펙/설계 없이 개발을 하는 것이다. 또는 기능명세서, 시방서 등의 문서에 기능만 정리하여 개발하는 것이다. 이 방법은 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍처를 만들 수도 없고, 개발자들이 효과적으로 일을 나눠서 개발할 수도 없으며 프로젝트 진척상황을 거의 파악할 수 없다. 일정 지연은 일상이고 그야말로 끝나봐야 아는 것이다.


둘째, SVN, Git 등의 소스코드관리시스템과 Jira, Mantis, Redmine 등의 이슈관리시스템 없이 개발하는 것이다. 둘중 하나라도 사용하지 않으면 심각한 문제이다. 일단 쓰기만 하더라도 다행이지만 제대로 쓰는 것은 정말 어렵다. 대부분은 10% 정도의 기능밖에 사용하지 못하지만, 100% 기능을 활용해야 한다.


셋째, 혼자 북치고 장구치고 다하는 것이다. 일을 전문적으로 나눠서 하는 것이 아니고, 혼자서 기획, 분석, 설계, 코딩, 테스트, 빌드 등등 다 하는 것이고 이런 개발자가 여럿이고 서로 중복되서 일을 하기도 한다. 첫째에서도 언급했듯이 스펙이 제대로 작성되어야 일을 효과적으로 나눌 수 있는데 스펙이 없거나 부실하면 이런 현상이 벌어진다. 또, 회사의 조직이 소프트웨어 개발에 알맞게 효과적으로 구성되어 있지 않아도 이런 일이 벌어진다. 소프트웨어는 전문가들이 협업하여 개발하는 것이다.


넷째, 프로세스 없이 대충 개발하는 것이다. 흔히들 프로세스는 개발을 더 느리게 만든다고 주장하곤 한다. 그러면서 회사에서 프로세스를 만들려고 하면 반대 주장을 펼친다. 과거에 개발하던 방법을 서로 암묵적으로 알고 있다가 대충 개발을 하고 서로 이심전심으로 문제를 해결해 나간다.


다섯째, 리뷰, 공유 없이 개발하는 것이다. 가끔은 대충 기능목록 작성해서 마케팅이나 영업, 경영진과 리뷰를 하기도 하지만 제대로 된 리뷰는 아니다. 개발자를 제외하고는 지금 어떤 제품을 만드는지 정확하게 파악이 안된다. 심지어는 개발자들도 잘 모른다. 다 만들어봐야 어떤 제품을 만들었는지 알게 된다. 그러니 만들기 전에는 무슨 문제가 발생할지 몰라서 만드는 도중에 수많은 문제가 발생하고 재작업은 수시로 이루어 진다. 심지어는 80%쯤 만들었다가 아키텍처가 잘못된 것을 발견하고 다 버리고 다시 만들기도 한다.


정도의 차이는 있을 수 있다. 다섯가지 중에서 하나 이상이면 아직 주먹구구식 개발에서 완전히 벗어난 것이 아니다. 스스로도 주먹구구식으로 개발을 하고 있는지 평가를 해보자.


2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표


그럼에도 불구하고 주먹구구식 개발이 여전히 통하는 이유는 무엇일까?


첫째, Software의 크기가 아주 작다.

빌딩은 제대로 된 분석/설계 없이, 프로세스 없이 만드는 것은 불가능하다.

하지만 개집은 그런 것 필요 없다. 대충 만들어도 문제 없이 만들 수 있다. 한 사람이 머리 속으로 모든 것을 설계해서 만들 수 있는 정도의 규모라면 주먹구구식 방법도 훌륭한 방법이다.


둘째, 이직률이 극도로 낮다.

한번 개발을 해 놓으면 개발자들이 절대로 퇴사를 하지 않고 끝까지 책임져준다. 


셋째, 회사 규모가 작다.

개발자도 몇 명 안되서 서로 너무 잘 알고 모든 이슈가 더 구두로도 공유가 되고 급한 이슈는 자리에서 바로 일어나서 공유가 되고 논의할 수 있다. 가족적인 분위기에서 주먹구구식 방법이 훌륭하게 작동한다.


넷째, 소프트웨어 업그레이드가 없다.

한번 개발해 놓은 시스템이 업그레이드가 필요 없는 경우이다. 어떻게 든 첫번째 개발을 해 놓으면 문제가 없다.


그럼, 주먹구구식 개발이 앞으로도 계속 통할까?


회사가 잘되면 회사는 커지게 되어 있다. 개발자 수는 많이 늘게 되고 더 이상 자리에서 일어나 뒤로 돌아도 모든 개발자의 얼굴을 볼 수 없게 된다. 과거처럼 공유가 그렇게 잘 되지 않는다.


개발자들이 영원히 이직하지 않고 직원으로 있기를 바란다면 너무 큰 욕심이다. 개발자들은 언젠가는 이직을 하게 마련이고, 개발자들이 이직을 해도 개발은 잘 돌아가도록 되어 있어야 한다. 주먹구구식으로 계속 개발을 하게 된다면 아무리 가족적인 분위기라고 하더라도 직원이 Risk 요인이 된다.


Software 회사의 경영자라면 지금 대충 잘 굴러가는 것 같다고 해서 방심하면 안된다. 회사가 잘 되면 회사는 커지고 직원도 늘고 더 복잡해질 것이다. 문제를 모르고 방심하다가 문제가 터지고 나면 터진 댐을 막으려고 하는 것처럼 어렵다. 항상 미리 준비를 해야 하는 것이다.


물론, 처음부터 제대로 하는 것이 가장 빨리 개발하는 방법이고 좋지만 그것을 깨닫기는 매우 어렵다. 대부분은 문제가 터진 후에 우왕좌왕 한다. 주먹구구식 개발이 지금은 통할지도 모른다. 하지만 곧 주먹구구식 개발이 문제가 되는 상황이 올 것이고 이미 문제가 되고 있다면 너무 늦지 않았기만 바랄 뿐이다. 늦었다고 생각할 때가 가장 빠른 때이다.


image by Tolka Rover


* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 

저작자 표시 비영리 변경 금지
신고

전규현 개발프로세스 공유, 리뷰, 주먹구구, 프로세스

  1. Blog Icon
    RF

    소프트웨어 개발에 관심이 많은 대학생으로써 재밌게 잘 보고 갑니다.
    저런 능력을 키우고 싶은데 ... 더 공부해야겠습니다.

  2. RF님 안녕하세요.

    어치피 학교에서는 기본적인 프로그래밍과 전산 원리 등을 배우죠. 나머지는 대부분은 실제 일하면서 현실에서 배우는 겁니다. 좋은 환경을 가지 회사를 선택하는 것이 매우 중요한 요소라고 생각합니다.

  3. Blog Icon

    비밀댓글입니다

  4. 안녕하세요. 아주 작은 회사를 제외하고는 제대로 된 회사를 찾기는 어렵고 회사마다 다 다릅니다. 콕 찝어서 얘기하기는 어렵습니다.

한 SI회사의 프로세스에 대한 오해

2012.07.16 09:45 by 전규현


잠시 후 Google blogger로 이동됩니다.







필자는 업계의 여러 사람과 얘기할 기회가 많다.


최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다.


SI회사의 오랜 바람 중의 하나가 "공정분리"이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다.

"공정분리"가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다.


"공정분리"는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다.


최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다.


그래서 진행한 것이 해외에서 "분석/설계"를 잘 해서 넘겨주면 국내에서는 개발자들은 그대로 "구현"만 하면 되도록 하는 프로세스를 만든 것이다.


실제로 이 프로세스는 잘 작동하지 않고 있다고 한다. 그동안 해오던 방법과 역량이 분석/설계를 해도 "구현"은 이와 상관없이 알아서 진행하고 모르면 분석가에게 물어가면서 코딩하던 수준이었다. 이런 상황에서 이 프로세스가 잘 작동할리가 만무하다.


이렇게 공정을 분리하려면 "분석/설계" vs "구현" 보다는 "분석" vs "설계/구현"이 더 낫다.


설계가 구현에 좀더 가깝고, 잘된 분석서를 가지고 충분히 "설계/구현"을 할 수 있기 때문이다.


여기서 또 오해가 있는 것이 설계를 잘해서 넘겨주면 그대로 코딩만 하면 될 줄 아는 것이다. 현실에서는 이렇게 잘 진행되지 않는다. 이렇게 하기 위해서는 설계를 너무 자세히 적어야 하고 실제 구현시 많은 문제를 발견하게 된다.


더 좋은 방법은 설계는 꼭 필요한 만큼만하고 구현에 적당한 자유도를 주는 것이다. 


이렇게 제대로 "공정분리"를 하기 위해서 대전제가 하나 있다. 


바로 "분석"역량이 뛰어나야 한다는 것이다. 뛰어난 분석가를 많이 보유하고 있어야 한다.

현재의 분석역량은 기껏해야 "기능"분석과 약간의 "비기능"을 분석하는데 그치고 있다. 분석이 무엇인지 짧은 글에 일일이 설명하기는 어렵지만 분석은 이보다 훨씬 크고 어려운 일이다. 비즈니스전략도 포함해야 하고, 설계도 일부 포함한다. 


필자의 생각으로는 이 SI회사는 당분간 프로세스의 시행착오를 좀더 겪을 것으로 생각된다. 잘못된 프로세스를 바로 잡는데 시간이 걸릴 것이고, 분석역량을 끌어 올리는 일에 시간이 좀더 걸릴 것이다.


시행착오를 겪는 시간은 짧을수록 좋다.


image by Greg McMullin 




 

저작자 표시 비영리 변경 금지
신고

전규현 개발프로세스 SI회사, 분석, 설계, 프로세스

  1. 요즘 써주신 글 중에서 가장 좋은 글인 것 같습니다. ^^
    보석 같은 키워드들이 많네요. - 자유도, 분석의 중요성 등
    분석이 참 중요하죠.
    초기 방향을 잘못 잡으면, 팀원이 아무리 열심히 해도 엉뚱한 방향으로 가는구나 하는 느낌이 듭니다.
    그나저나 SI는 워낙 넓은 분야를 커버하다 보니,
    깊이 있는 분석이란 참 뛰어난 분들의 영역인 것 같고요~

    고맙습니다.

  2. 제임스님 안녕하세요.

    SI회사의 분석가들은 분석역량보다는 도메인지식이 뛰어난 사람이 많습니다. 고객의 업무를 고객보다 잘 아는 경우가 많지만 업무지식을 쌓아가는 방식으로 성장하다보니 분석 역량이 떨어져서 고객의 요구사항 파악이 부족하고 스펙관리가 떨어지고 설계/개발자에게 스펙 전달이 잘 안됩니다. 결국에 분석가가 구현단계까지 도움을 많이 줘야 하는 경우가 많습니다.

    이러다보니 세계적인 방법론을 도입해서 문서만 수십가지를 만들어도 별로 나아지는 것은 없이 문서를 많이 만들려고 고생만 합니다.

    세계적인 방법론보다는 제대로된 분석 역량을 익히는 것이 더 중요합니다. 결론은 전문가에게 배우는 거죠. ^^

  3. Blog Icon
    LInE.

    설계자와 개발자의 롤이 명확한(철저히 분리된..) 프로젝트를 한 적이 있는데, 설계단계 진행시 설계자 설득하느라 바쁘고 개발단계 진행 시 개발자와 설계자 커뮤니케이션 문제 때문에 아주 골머리 썩었었습니다.-_ㅜ

    개발자들은 투입되자마자 설계문서를 파악하고 코딩에 들어가야 하는데, 작성가이드를 해 준 설계문서의 항목이 너무 많고 자세하다고 설계자들이 반발.. 하지만 아무리 생각해 봐도 그정도의 설계항목이 본문에 말씀하신 "꼭 필요한 만큼" 이라고 생각이 되어 개발자들이 코딩하려면 그정도는 설계를 해 줘야 코딩들어갈 수 있다고 설득하느라 한참 시간 보내고,

    또 막상 개발자들이 코딩 들어가니 왠걸 진짜 "설계문서에 있는 기능만" 구현을 해 놓더라구요. 예를 들면 단위테스트 진행 시 기본적인 유효성검사도 되어 있지 않아 개발자에게 말을하면 "설계문서에 없었다."... 설계자들은 어떻게 그런것 까지 문서화 하냐, 필수입력이라고 해 놓았으면 당연히 유효성체크 해놔야 하는거 아니냐고 서로 싸우고...

    본문의 내용이 너무나도 공감가서 한마디 적고 갑니다...

    좋은 글 항상 잘보고 있습니다. 항상 감사합니다. ^^

  4. 안녕하세요. LInE. 님

    항상 시행착오를 통해서 배우지만, 시행착오를 가장 적게 겪는 것이 중요한 것 같습니다. 시행착오를 겪다가 너무 오랜 시간이 지나기도 하죠. ^^

  5. Blog Icon
    manwal

    제가 고민하던 내용을 정확하게 짚어 정리해주시니 너무 공감됩니다. 이런 경험들을 기록해두는 것이 매우 중요하다는 생각이 듭니다.

  6. 감사합니다. Manwal님

  7. Blog Icon
    GF

    최근 다른 회사와 프로젝트를 진행하게 되었는데, 그 회사에서는 약 3년을 끌어온 개발건이 있었습니다. 전규현님의 글들에 늘 나오는 대로 스펙과 설계 등의 문서는 아예 없고, 개발팀장이 교체될때마다 주먹구구식으로 진행이 되어왔기에 1년을 예상하고 시작한 프로젝트가 3년이 되어도 완결이 안되고 있더군요.
    이러한 상황에서, SI회사 혹은 컨설턴트를 통해 분석/설계 부터 다시해서 새로 시작하는 것이 나을지요?
    내부에 개발자를 채용해서 진행을 하는 것은 많이 지친듯 보입니다. 사람도 요새는 더 뽑기도 어렵구요...

  8. 안녕하세요. GF님

    이미 망쳐 놓은 경우가 가장 어려운 경우입니다.
    제가 SI회사도 컨설팅을 하고 교육을 하기 때문에 꽤 아는데 SI회사도 분석/설계 역량이 별로 없습니다.

    일단 이대로 진행해서 어떻게든 마무리 하는 방법과 다시 분석/설계를 진행하는 방법을 비교해 봐야 하는데 현재 진행상황이 어느 정도 인지 파악을 먼저 해야 합니다.

    분석/설계를 다시 진행하려면 직접 하시던지, 저희회사에 의뢰를 하는 것이 좋을 것 같습니다. 직접 하시면 시행착오를 겪을 수는 있지만 그래도 내용을 잘 아실 것이기 때문에 가능할 수도 있습니다.

    혹시 진행하시다가 궁금한 점이 있으면 메일로 문의해주세요. 진짜 답답하시면 제 사무실로 한번 찾아오시면 자세히 설명 드리겠습니다. ^^

획일화된 프로세스의 함정

2011.04.03 11:11 by 전규현


잠시 후 Google blogger로 이동됩니다.






SW를 개발하는데 있어서 체계화된 프로세스가 필요하다는 것은 당연하다.

대부분의 SW회사가 최소한의 프로세스도 없이 주먹구구식으로 SW를 개발한다. 작은 회사들은 문제가 안되는 것처럼 보이지만 회사가 조금만 커져도 여기저기서 문제가 발생하다.

이런 문제에 시달리다보면 프로세스와 문서화가 이 문제를 해결해 줄것이라고 너무 믿게 된다.
그래서 엄격한 프로세스를 만들고 각 프로세스마다 문서를 꼭 만들게 하고 검사를 하기도 한다. 물론 프로젝트의 종류에 따라서 만드는 필수문서를 다르게 하기도 하지만, 이러한 규정은 개발자들이 요리조리 프로세스를 피해가는데 활용이 되곤 한다.

프로젝트에서 꼭 필요한 문서를 획일적으로 정하는 것은 매우 어렵다. 프로젝트 팀에서 결정하고 이를 존중하는 것이 좋다. 하지만 아직 개발팀의 역량이 부족하고 문화가 부족하다면 개발팀의 결정을 따르기도 어렵다.

가장 좋은 방법은 회사가 작을 때부터 체계적으로 개발하는 방법을 익히고 스펙과 설계를 적절하게 작성해가면서 개발문화를 키워나가고 개발자들의 역량이 같이 커져가는 것이다. 그렇게 되면 회사가 커져도 좀더 복잡한 프로세를 자율적으로 운영할 수 있게 된다.

하지만 대부분이 회사는 이러한 기회를 놓치게 된다.

그래서 택하는 것이 획일화된 프로세스이다. 이 고통스러운 프로세스를 거쳐서 이겨내면 점점 자율적인 프로세스로 바뀌게 되지만 이를 극복하지 못하면 점점 더 복잡하고 엄격한 프로세스를 만들게 된다.

가장 좋은 방법은 회사가 성장함에 따라서 문제가 생기기 이전에 미리 체계를 갖추고 개발자들의 역량을 키우는 것이고, 이미 문제가 발생했다면 최소한의 프로세스만을 만들고 지금이라고 개발자들이 분석, 설계 역량을 키울 수 있도록 회사에서 지원하는 것이다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
 
저작자 표시 비영리 변경 금지
신고

전규현 개발프로세스 프로세스

  1. 문서 없이도 대부분의 프로젝트들이 별 문제없이 잘 진행되고 있는 상황이기 때문에 개발자들이 필요성을 못느끼고 있는것 같습니다.
    개발자들이 무엇인가를 하게 하려면.. 그것이 필요한 이유에 대한 공감대를 먼저 공유하는것이 중요하다고 봅니다.
    문서화의 필요성을 느끼게 해 줄 수 있는 방법이 있다면.. 문서 작성을 거부감 없이 회사에 전체에 적용 할 수 있겠지요.

    회사가 조금만 커져도 문제가 된다고 하셨는데.. 개발자가 몇 명 정도 되었을때 이런 문서와 프로세스의 부재로 인한 문제가 생긴다고 보시는지요?
    사실 회사를 경영하는 사람 입장에서는 문제가 생기기 직전의 규모까지는 문서와 프로세스를 진행하지 않다가 문제가 생길 만한 규모가 될 정도부터 관심을 가지는것이 가장 합리적인 선택이라고 봅니다.

  2. 이성열

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

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

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

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

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

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

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

  3. 저는 문서화를 제가 기억못하기 때문에 합니다.

    기억하고 있다면 대화가 가장 커뮤니케이션이 효율이 좋고..
    기억하지 못한다면 그때 얼른 적습니다.
    그리고 기억하지도 못하고, 문서화도 없다... 그건 무조건 폐기하는 대상입니다.
    너무 단순하죠?

  4. 안녕하세요. whitekid님

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

  5. 돈과 시간이 그 실행의 기준이 될것 같습니다.
    문서화에는 비용이 드니까요.

    저의 생각으로는
    만들어지는 모든 함수를 사전처럼 만들어서 사람들이 공유할 수 있게 된다면
    문서화'도 되고 재사용도 되고' 개발비용과 불필요한 노력도 줄어 들 수 있을것 같습니다.

    더. 나아가. 이 문서화된 데이터가 함수이면서도 UI 에 쓰여질 수 있다면. 엄청난 도구가 될듯합니다.

  6. 안녕하세요. shint님

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

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

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

소프트웨어 관료화

2009.08.31 22:25 by 전규현


잠시 후 Google blogger로 이동됩니다.




"공무원 수는 해야 할 일의 경중이나 업무 유무에 관계없이 일정한 비율로 증가한다", "공무원은 서로를 위하여 서로 일을 만들어 낸다", "유능하지 못한 사람은 공무원이 된다."
이는 그 유명한 파킨슨의 법칙입니다.

소프트웨어를 개발할 때도 이와 같은 함정이 도사리고 있습니다.
주먹구구식으로 소프트웨어를 개발하다가 체계적으로 개발하고 싶은 요구가 생길 때 프로세스팀을 구축하고 개발 프로세스를 정립하다 보면 파킨슨의 법칙에 빠지기 쉽습니다. 

프로세스팀의 구성원들은 진짜 소프트웨어 전문가로 구성되는 경우가 드믑니다. 여기서 말하는 소프트웨어 전문가란 코딩만 잘하는 개발자가 아니고, 구축, 설계, 테스트, 형상관리, 버그 추적, 빌드, 릴리즈, 방법론 등 소프트웨어 관련 여러 분야의 지식과 경험을 두루 갖추고 있는 사람입니다.

이런 비전문가로 구성된 프로세스 팀은 소프트웨어 개발의 내용을 속속들이 잘 모르고 너무 형식에 치우칠 수 있고, 끊임없이 프로세스팀이 할 일을 만들어 내기 위해서 프로세스를 점점 복잡하게 만들곤 합니다. 이들은 어떤 것이 정확하게 올바른 방법인지 잘 몰라서 그렇게 하기도 하고, 자신들의 밥줄을 견고하게 하기 위해서 여기저기 승인 절차를 많이 추가해서 프로세스팀이 소프트웨어 개발 프로세스의 중요한 역할을 하고자 한다.

프로세스팀은 소프트웨어를 효율적으로 개발하기 위한 방법들을 연구하지만 소프트웨어 개발 프로세스 중간에 직접 끼어들어서 간섭하는 프로세스를 만드는 것은 바람직하지 않다. 소프트웨어를 개발하는데 있어서 여기저기 승인 절차를 잔뜩 집어 넣어 놓는 것도 그리 좋지 않습니다. 승인 절차가 소프트웨어의 무결성을 보장해주진 않습니다. 오히려 관료화된 승인 절차는 아무런 도움이 되지 않는 경우가 많습니다. 소프트웨어는 각 분야의 전문가들이 자율적으로 효과적으로 움직였을 때 가장 효율적으로 개발됩니다. 명시적인 승인 절차가 없더라 승인절차를 거친 것과 같이 모두가 진행상황을 훤히 알 수 있게 됩니다. 이렇게 개발되는 방식이 오히려 소프트웨어 무결성에 더 도움이 됩니다. 승인 절차는 형식적인 승인이 되기 쉽지만, 각 단계의 전문가들이 리뷰를 하고 Unit 테스트를 하고 시스템 테스트를 하고 빌드전문가가 확인을 하고 이러한 전 과정을 통해서 문제가 되는 것들은 발견이 되고 개발도 효율적으로 진행됩니다.

소프트웨어 개발 경험이 부족한 프로세스 팀은 철저한 승인 절차가 아니면 안전한 소프트웨어를 개발하기 어려울 것 같이 생각되지만, 이는 경험 부족에서 오는 착각이거나 관료화의 조짐입니다.

또 소프트웨어 개발에 대한 이해가 부족한 경영자들은 이들이 주장하는 프로세스가 그럴듯해 보이지만 사실은 소프트웨어 개발에 상당부분 걸림돌이 되고 있다는 것을 눈치채기 어렵습니다.

진짜 소프트웨어 전문가로 프로세스팀을 만들 것이 아니면 내부에서 진행하는 여러 개선 시도들이 시간 낭비인 경우 많고, 시행착오 없이 6개월이면 갖출 수 있는 경쟁력을 먼 거리를 돌아서 수년이 걸리거나 영영 경쟁력을 갖추지 못하는 경우도 많습니다. 프로세스팀을 갖추려면 소프트웨어 전문가로 구성을 하거나 내부에 전문가가 없다면 외부에서 도움을 받는 것이 좋습니다.

회사 내에서 소프트웨어 개발을 잘 하는 개발자가 소프트웨어 전문가라고 생각하지는 마세요. 공을 잘 차는 축구 선수일 뿐입니다.  

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 개발프로세스 관료화, 파킨슨의법칙, 프로세스

  1. 우리나라 공무원은 엘리트라서 말이죠 ㅋㅋ
    저런 이유에서 사수가 있는건 참 좋은것 같습니다
    (사수없이 3년 ㅠ.ㅠ)

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

  3. Blog Icon
    김경록

    프로세스팀의 구성원들은 진짜 소프트웨어 전문가로 구성되는 경우가 드물다는 말...

    상당히 찔리고 공감이 가네요 ^^;;;

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

  5. Blog Icon
    hermian

    해결책은 없겠죠.
    철통 밥그릇이 그렇듯...
    전문가가 아닌 사람의 머리를 쪼개서 지식을 넣어 줄 수도 없고...
    참으로 난형난재입니다.

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

  7. Blog Icon
    이혜원

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

  8. 안녕하세요. 이혜원님

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

  9. Blog Icon
    장호진

    제가 유일하게 RSS등록해두고 잘 보고있는 블로그인데 처음 글 남깁니다.
    7년 동안 사수없이 고군분투해오다 보니 남는게 별로 없네요....
    그래서, 요즘 전규현님 책과 블로그의 도움을 받아서 흔히 얘기하는 시스템과 프로세스를 구축하고 있습니다.
    앞으로도 좋은 글 부탁드립니다.
    가끔 글도 남길께요^^

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

악순환 vs. 선순환

2009.05.22 12:24 by 전규현


잠시 후 Google blogger로 이동됩니다.




지난번 글 (이 바닥을 못 벗어 난다.)의 추가 글입니다.
회사가 Risk가 큼에도 불구하고 Domain 지식이 점점 더 매달릴 수 밖에 없는 이유와 선순환을 하려면 어떻게 해야 하는지 좀더 현실감 있는 예를 보여주려고 합니다.
회사마다 상황이 모두 다르기 때문에 각자의 상황과 1:1로 다 일치하지는 않지만 참고하실 수는 있을 겁니다.
그럼 악순환과 선순환에 대해서 알아보죠.

Domain 지식에 점점 매달리게 되는 악순환의 고리

  • 주먹구구식 개발
  • 개발자에 의존한 코딩 중심의 개발 주도
  • 없거나 빈약한 개발 프로세스 및 개발 문서
  • 회사의 지식은 개발자 머리 속에 보관
  • 개발자 간 지식의 공유가 어려움
  • 후배 개발자들에게 지식 전달이 잘 안됨
  • 프로젝트가 커질수록 협업이 점점 어려워짐
  • 점점 더 경험 많은 개발자에 의존하게 됨
  • 경험 많은 개발자는 계속 더 바빠짐
  • 경험 많은 개발자들도 체계적인 개발은 꿈도 못 꾸고 매일 밑바닥 개발에 매달림
  • 개발자들이 Domain 지식은 점점 늘어가는데 소프트웨어 공학지식은 잘 늘지 않음
  • 회사에서는 신규 직원을 뽑아도 같이 협업이 잘 안되므로, 동일 Domain의 경험이 많은 개발자를 선호하게 됨
  • 경험 많은 개발자들이 퇴사를 해서 회사가 큰 타격을 입기도 함
  • 또 고참 개발자들이 퇴사할 까봐 전전긍긍하게 됨
  • 회사에서는 개발자들의 머리 속에 있는 지식을 공유하고 체계적으로 개발하고 싶으나 방법을 모름
  • 이에 대한 개혁을 해보려고 해도 번번히 고참 개발자들의 방해로 무산됨
  • 점점 더 경험 많고 Domain 지식이 풍부한 개발자들에게 의존하게 됨
  • 규모 있는 개발을 못하고 인원수에 의존한 개발을 하게 됨
  • 회사는 성장을 못하고 정체하게 됨
  • 고참 개발자들은 성장을 못하고 매일 밑바닥 코딩과 문제 해결에 매달리게 됨
  • 또 주먹구구식, 가내 수공업식 개발을 반복하게 됨

프로세스 중심의 선순환의 고리
  • 회사가 소프트웨어 개발에 필요한 적절한 프로세스와 인프라스트럭처 시스템을 갖추고 있다.
  • 개발자들은 프로세스 중심으로 개발이 되도록 잘 훈련 되어 있다.
  • 프로젝트 진행 시 꼭 필요한 스펙 문서와 설계 문서를 적절하게 만든다.
  • 문서와 코드에 대해서 적절히 Peer review가 이루어져서 지식의 전달이 잘 되고 결함이 사전에 제거된다.
  • 고참 개발자들은 코딩 보다는 주로 아키텍처와 비즈니스에 대해서 고민하고 해결한다.
  • 잘 작성된 스펙 문서와 설계 문서를 보고 후배 개발자들이 코딩하고 테스트 팀이 테스트를 진행한다.
  • 고참 개발자들은 오랜 개발 경력으로 Domain 지식도 풍부하지만 소프트웨어 공학 지식 및 경험도 풍부하다.
  • 후배 개발자들은 Domain 지식은 부족하지만, 설계 문서를 보고 인프라스트럭처 시스템을 활용해서 프로세스에 따라 개발하는데 별 문제가 없다.
  • 신규 개발자를 뽑아도 교육이 용이하고 바로 실무에 투입하기가 쉽다.
  • 고참 개발자들이 퇴사를 해도 상당히 많은 지식이 문서화 되고 이미 후배들에게 전파가 되어 있으므로 회사의 타격이 상대적으로 적다.
  • 퇴사한 고참 개발자들은 이직이 용이하고 더 높은 연봉으로 타 회사로 옮길 수 있다.
  • 회사에서는 Domain 지식이 너무 매달리지 않고, 실제로 Software 공학 지식이 뛰어나고 Software 개발 자체를 잘하는 인재를 선호하게 된다.
  • 회사가 성장하고 개발 규모가 커져도 문제 없이 대응할 수 있다.

그럼 악순환에서 선순환으로 바뀌는 방법에 대해서 의문을 가질 수 밖에 없습니다.
이는 참 어려운 숙제입니다. 
운동을 안한다. -> 몸이 무거워진다. -> 운동을 더 안한다. -> 몸이 더 무거워진다.
이런 악순환의 고리를 끝는 것은 무엇을 까요? 일단 운동을 시작한다? 99%는 실패할 겁니다.
운동은 습관도 안들어 있고, 제대로 운동하는 방법도 모르고, 또 귀찮아지면 언제든지 포기하고, 잘못된 운동 방법으로 다칠 수도 있습니다. 그러면 운동에 대한 나쁜 기억만 쌓이고 다음번에는 더욱더 운동을 시도하지 않게 될 겁니다.

그래서 악순환의 고리를 끝는 것을 쉽게 얘기를 할 수 있어도 현실적으로 가능한 방법을 제시하는 것은 쉽지 않습니다. 물론 가장 적절한 방법도 회사마다 다릅니다.

하지만, 악순환의 고리를 끝는 방법 중에서 필수 요소는 경영자의 의지입니다. 경영자가 이러한 상황을 전혀 이해 못하고 있거나 의지가 없다면 그냥 계속 악순환의 고리를 돌면서 영업이나 잘하는 수 밖에 없습니다.
개발자들이 으쌰으쌰해서 점진적으로 개혁을 해보려는 시도는 매우 더딜뿐만 아니라 다양한 도전 및 방해로 무산될 가능성이 큽니다. 그래도 그런 과정에서 개발자들이 본인 스스로 공부는 될 수 있겠네요.

경영자가 의지만 있다면, 조직, 시스템, 프로세스적인 다양한 측면에서 효과적이고 적절한 개혁을 시도하여 회사를 바꿔나가서 점점 선순환의 고리로 옮겨 갈 수 있습니다. 


이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 
저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 Domain지식, 문서, 소프트웨어 개발, 프로세스

  1. 오픈 세미나에 와주셔서 늦은 시간까지 열강해 주신것 너무 감사드립니다. 좋은글을 잘 읽고 갑니다.

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

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

거만한 속빈 강정

2009.04.09 21:58 by 전규현


잠시 후 Google blogger로 이동됩니다.



소프트웨어 개발 경험도 개발자가 미국 실리콘밸리의 소프트웨어 회사에 입사해서 5년이면 배울 수 있는 것(소프트웨어를 개발하는 방법)을 우리나라에서는 10년, 20년 아니 30년을 소프트웨어만 개발해도 배우지 못합니다.

오히려 이런 경험 많은 고참 개발자들은 배울 수 있는 기회가 눈앞에 와도 배울 수가 없게 됩니다.
책을 하나 봐도 대부분 아는 내용이라고 저자를 평가 절하하지만 아는 수준이라는 것이 용어 한번 들어보고 샘플 좀 사용해 본 정도인 경우가 대부분입니다.

예를 들어 소스코드관리시스템에 대한 내용을 봐도 내가 대형SI회사에서 10년 넘게 개발을 했는데, 이런 것을 모를까봐?라고 생각하지만 고작 소스코드 백업 받듯이 저장하고 태깅 좀 한 정도 가지고 소스코드 관리를 제대로 하고 있다고 착각합니다. 

오히려 이러한 개발자들은 온갖 화려한 기술과 온갖 툴 및 기법에 능숙해서 UML의 도사이고 자신은 아키텍트라고 하면서도 진짜 설계는 할 줄도 모릅니다. 이런 고참 개발자들은 아무것도 모르는 신참 개발자보다 제대로 배우기는 훨씬 어렵습니다. 신참 개발자들은 책이나 강연을 통해서 배움이 기회가 왔을 때 자신은 잘 모르고 부족하다고 생각을 하기 때문에 받아드리려는 마음이 있으나 이런 고참 개발자들은 자신들이 잘 알고 개발을 잘하고 있다고 착각하기 때문에 즉 자신의 무지를 모르기 때문에 배움을 받아드리려고 하지 않습니다. 또 자신이 해왔던 방식이 나름대로 편하다고 생각해서 바꾸기를 싫어하고 괜히 바꿨다가 회사에서 자신의 위상이 흔들리면 어떡할까 하는 걱정도 하곤 합니다.

2,3년 된 신참 개발자들은 회사에서 제대로 된 개발 환경 및 교육의 기회만 주어진다면 4,5년 안에 이런 고참 개발자들보다 훨씬 뛰어난 실력을 갖는 것은 그리 어려운 일이 아닙니다. 또 배우려고 하지 않는 고참개발자들은 세계 최고의 소프트웨어 대가가 와도 이들을 가르칠 수는 없습니다. 그냥 그렇게 회사에서 정치나 하면서 연명을 하는 수밖에 없습니다. 다른 회사로 이직을 하면 자신의 위상이 확 떨어지니 회사에 꼭 붙어 있어야겠지요. 물론 은퇴 전에 회사가 망하면 큰 일지만 말입니다. 

그런 일을 당하지 않으려면 마음을 바꿔 먹어야 합니다. 물론 정말 실력이 뛰어난 개발자들도 많이 있지만, 자신이 소프트웨어 개발을 잘하고 있다고 착각하는 고참개발자들은 늦었지만, 바뀌어야 합니다. 

자신이 정말로 뛰어난 개발자인지? 뛰어나다고 착각하는 것인지? 어떻게 아냐고요?

  • 후배 개발자들이 많이 있는데 아직도 주로 코딩에만 매달리면서 자신이 코딩을 하지 않으면 개발이 잘 안될 것 같습니까? 
  • 문서를 만들면서 개발을 하는 것보다 코딩부터 개발을 하고 문서는 불필요하다고 생각하시나요?
  • 문서를 만들어도 다른 개발자들이 이해를 잘 못하나요? 
  • 자신은 개발을 정말 잘하는데 후배 개발자들은 정말 실력이 떨어진다고 생각이 드나요?
  • 후배들이 실력이 딸려서 같이 일하기 정말 힘듭니까?
  • 후배들에게 잘 설명해줘도 원하는대로 개발이 진행이 잘 안됩니까?
  • 개발은 기가 막히게 하는데 회사의 비즈니스 상황은 잘 모르나요?
  • 개발에만 집중하고 소프트웨어 기획, 테스트, 배포 등의 전반의 내용은 잘 모르나요?
  • 해당 Domain 지식(업무지식)에 대해서 도사급이라 다른 업계로 이직은 싫은가요?
  • 소스코드관리, 버그관리는 기초기능만 사용하나요? (기초의 기준이 뭔지 알기 어렵겠군요.)
  • 개발프로세스는 불필요하거나 불편한 것이라고 생각하시나요?
  • 경영자들에게 기술이나 아이디어를 설명해도 경영자들이 이해를 잘 못하나요?

너무 많아서 다 나열할 수가 없네요. 

이중에 몇 가지만 해당해도 착각하고 있는 것일 가능성이 대단히 높습니다. 착각에서 빨리 벗어나는 것이 자신의 미래를 위해서 이롭습니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  

저작자 표시 비영리 변경 금지
신고

전규현 사람과 기술 UML, 강연, 개발자, 고참, 소프트웨어 개발, 신참, 실리콘밸리, 프로세스

  1. Blog Icon
    Jake

    안녕하세요 레이님.
    속빈강정같은 고참 개발자를 가려내는 방법이나 착각에서 벗어나라는 조언 보다는 실리콘밸리에서 5년이면 배우는 것이 무엇이며 한국에서는 왜 10년 20, 30년을 해도 그것들을 못배우는지, 그리고 어떻게하면 5년이면 그런 것들을 배울수 있게 하는지를 조언해주셨으면 더 좋았을것 같습니다.

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

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

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

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

  3. 요즘 저도 느끼는 거지만 SI를 7년 했더니 더이상 실력 향상이 안되는거 같습니다.
    좀더 심화 있는 개발을 하고 싶은데 매일 하는게 업무만 틀리고 거기서 거기인 느낌입니다.
    솔루션쪽으로 가고 싶지만 국내 솔루션은 열악한 환경이라 먹고 살려니 계속 SI에 남아 있게
    되네요.

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

  5. Blog Icon
    아름드리

    저 같은 경우 대부분 혼자 일하면서 어떻게 해서든 실력을 키우고 싶어 책을 보고 구글을 했습니다. 그제야 문서화, 소스 관리, 빌드 시스템, 테스트 등 제가 반드시 알아야 하는 것들이 있다는 것 알았습니다.
    주위 개발자들에게 개발 프로세스를 적용해 보자고 해도 다들 무관심이네요. 저라도 성과를 얻으면 조금이라도 관심을 보일까 생각해 열심히 노력하고 있습니다.

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

  7. Blog Icon
    bluepoet

    Ray 님 안녕하세요. 항상 글 잘보고있습니다.
    저도 2년차 소프트웨어 개발자인데. 전 외국계 대기업회사에 근무하고있습니다. 처음에는 제가 배웠던 소프트웨어 프로세스대로 철저하게 지켜지는게 너무나 대단해보였습니다. 2년차가 되니까 이것저것 생각이 많아졌나봅니다. Qa team, Release team, Dev Team,Arch Team간에 Customer 가있는 Project의 경우 Process를 가지고 상당한 논의가 되곤합니다..이런 모습을 보면서 꼭 Process를 지켜야되는것이 올바른 길은 아니라는생각도 해보게 되었습니다. 외국계지만 여전히 지적해주신 사항들을 숙지못하고 Process에 관심이없는 엔지니어들도 많답니다..

    저도 좀더 포괄적으로 이해할수있는 능력을 길러야겠습니다.
    ^^

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

  9. 글을 읽고 오전내내 괴로웠습니다. 그동안 정말 뭘 한건지 그리고 앞으로는 또 어떻게 해야할지... 더욱더 마음이 무거워지네요...좋은글 감사합니다.

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

  11. 우물 안 개구리는 누가 우물밖으로 개구리를 꺼내주기 전까지는 자기가 어디에 있는지 모르는것과 마찬가지이듯, 시스템으로 돌아가는 대기업이나 몇몇 업체를 제외한 대부분의 중소기업에서는 회사가 개인의 이런 경력발전을 위한 지원을 해주지 않거나 기회를 주지 않으면 개발자 스스로 이러한 걸 깨우치기는 어려운 것도 사실입니다.

    실상은 지적하신바와 같이 막상 이런 흔치 않은 기회가 와도 개발자 스스로가 그걸 거부하거나 준비가 되어 있지 않아 그 기회를 잡지 못하는 경우도 많다라는 것이 문제죠. 특히 초급 개발자나 프리랜서/소규모 회사를 너무 오래 다닌 개발자 중에는 '난 코딩만 할꺼야' 라는 마인드를 갖고 있는 것도 문제이고요.

    사내 정치라는 것에 대해서 개인적인 의견은, 이건 정말 2명 이상 모인 집단에서는 어디서나 발생하는 현상이라는 겁니다. 기본적으로 정치가들이 워낙 부정적인 의미라 나쁘게 들리긴 합니다만... 아무튼 문제는 기본적으로 개발자/공대출신 사람들이 이 정치력이 별로 없다라는 거겠죠. -_-;;

    글 잘 읽고 갑니다. :)

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

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

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

프로세스가 창의성을 저해한다고?

2009.04.08 22:08 by 전규현


잠시 후 Google blogger로 이동됩니다.




개발 프로세스가 창의성을 저해한다고 싫어하는 개발자, 관리자, 경영자를 종종 만나게 됩니다.
이들이 프로세스를 싫어하는 이유는 과거에 개발 프로세스 도입에 대한 실패의 경험이 있거나 그런 얘기를 종종 전해 듣기 때문입니다.

이렇게 개발 프로세스 도입에 실패하는 이유는 현실성이 없는 이론적인 프로세스를 도입하거나 회사의 역량 수준에 맞지 않는 프로세스를 시도한 경우가 많습니다. 또 인터넷이나 책을 통해서 배우게 된 프로세스를 따라 하다 보면 그 Context를 다 알지 못하고 형태만 비슷하게 흉내 내다가 실패하기도 합니다.

그럼, 그렇다고 프로세스가 없다면 창의성이 샘솟을까요?
개발프로세스가 제대로 갖춰지지 않은 회사는 대부분 각 개발자들의 개인 역량에 따라서 적절히 개발이 이루어지며 개발자들은 역할의 구분 없이 만물박사 식으로 온갖 업무를 처리합니다. 이러다 보면 항상 바쁘고 새로운 기술을 조사한다거나 참신한 생각을 할 틈이 별로 없습니다. 또, 멋진 아이디어가 떠올라도 마땅하게 Follow up할 방법이 없어서 아이디어를 떠올린 개발자가 북치고 장구치고, 경영층도 설득하고, 프로토타입도 만들어보고 시장 조사도 해보고 해야 합니다. 안 그래도 바쁜 마당에서 짬을 내서 또 새로운 아이디어를 Follow up하기는 정말 어렵습니다. 누가 무슨 일을 얼마나 하고 있는지 잘 파악이 안되므로 또 이런 일을 벌여서 괜히 성과도 없이 평가만 안 좋아 질까봐 포기하기 십상입니다. 또 아이디어 낸 사람이 총대를 매야 하기 때문에 그렇다고 기존의 업무가 줄어들지 않기 때문에 공식적으로 이런 활동을 안하려고 합니다.

하지만, 개발 프로세스를 잘 갖추고 있는 회사는 아이디어를 내기만 하면 일단 회사의 System이 이를 Follow up합니다. 일단 아이디어는 수면 위로 떠올라서 여러 사람과의 Review를 통해서 더욱 Refine되고 정식 절차를 통해서 Prototype을 만들고 마케터는 시장 조사를 하고 영업은 고객들의 의견을 수집해 옵니다. 관리자는 해당 개발자가 아이디어를 발전시킬 수 있도록 정식으로 업무를 할당해서 시간을 빼줍니다. 한마디로 개발자는 기술적인 것만 Follow up해도 됩니다. 물론 모든 아이디어가 제품화 되는 것은 아니지만, 이런 아이디어들이 10개 100개 모여서 성공하는 제품이 나옵니다.

결국 프로세스가 창의성을 저해한다는 생각은 무지의 산물이거나 잘못된 경험의 결과입니다.

문제는 회사의 몸에 딱 맞는 개발프로세스를 갖추는 것이 어렵다는 것입니다. 현재 개발을 어떻게 하고 있는지 조사를 해보면 제각각 일겁니다. 이것부터 통일해 나가면서 조금씩 바꿔가는 것이 스스로 해볼 수 있는 최선의 방법입니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  

저작자 표시 비영리 변경 금지
신고

전규현 개발프로세스 Follo up, prototype, Refine, review, System, 마케터, 아이디어, 역량, 제품화, 창의성, 프로세스

  1. Blog Icon
    ~_~

    제가 일하고 있는 곳은 새로운 아이디어가 있다면 알아서 적용시키고 실현 시킨뒤에나 검토가 됩니다. 따라서 회사의 요구대로 아이디어 따위는 일체 생각도 하지 않고 있습니다. 음... 개인시간을 좀더 늘려서 혼자만의 아이디어 스캐치를 해보는게 좋을듯 싶네요

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

  3. 회사에 맞게 딱 맞는 프로세스를 도입한다는 것이 정말 힘든 일인줄 압니다.
    이론적인 프로세스를 도입하고 그것에 맞춰서 따라간다는 것은 마치 적응하지 못한 간난아기보고 걸어달라고 하는 것과 마찬가지인것 같습니다. 이론적인 프로세스를 도입한다 하더라도 조직에 맞게 변형해서 수년간 틀을 마련한다면야..되겠지만.말이죠..

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

  5. 창의성을 저해하는 것은 프로세스를 위한 프로세스를 무작정 도입하기 때문인 것 같습니다. 어디서 누가 좋다고 하니까 필요없는 돈을 발라가면서 열심히 도입을 하고, 일단 도입은 해 놨으니 그게 옳건 그르건 무조건적인 준수를 강요합니다. 뭔가 좀 문제가 있다 싶으면 그걸 해결한답시고 또 다른 프로세스를 도입하기를 반복하죠. (순수 IT 회사보다는 제조로 시작한 회사가 그런 경향이 강한 것 같습니다.) 나중에는 프로세스 따라 다니다가 지쳐버리죠.
    회사의 몸에 딱 맞는 개발프로세스를 갖출 수만 있다면 정말 좋을텐데요...

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

  7. "멋진 아이디어가 떠올라도 마땅하게 Follow up할 방법이 없어서" 라는 부분에 격하게 공감합니다. :)

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

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바