태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

소프트웨어 공학이 뭔가?

2009.01.15 16:04 by 전규현


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



필자가 소프트웨어 공학(소프트웨어 엔지니어링)이란 용어를 안 것은 얼마 되지 않았습니다. 소프트웨어 공학이라는 용어를 접하고 그 내용을 보니 오랫동안 소프트웨어를 개발하면서 해왔던 그 방법 그대로를 적어 놓은 것에 불과했습니다. 물론 소프트웨어 공학에 포함된 전체 내용은 상당히 방대하지만 그 근본 원리와 핵심적인 내용들은 아주 익숙한 내용들이었습니다.

지금 글을 읽고 계신 분께서 소프트웨어를 아주 잘 개발하고 있다면 이들은 이미 소프트웨어 공학의 대가입니다. 단순히 머리가 좋아서 혼자서 잘 개발을 잘하는 것을 제외하고 여러 명의 팀을 이끌고 복잡한 시스템을 짧은 시간에 가장 적은 비용으로 품질 높은 제품을 이미 만들어 내고 있다면 소프트웨어 공학이란 말을 한번도 들어본 적이 없어도 이미 전문가입니다.

대부분의 뛰어는 개발자들은 소프트웨어 공학에 익숙합니다. 비록 소프트웨어 공학의 수많은 용어를 사용하지 않는 다고 하더라도 이미 잘하고 있습니다. 뛰어난 개발자란 뛰어난 프로그래머, 코더가 아닙니다. 

대학에서 소프트웨어 공학을 전공 과목으로 배웠다고 하더라도 실무에서 제대로 된 개발 방법을 경험한 개발자에 비해서는 그 이해도가 택도 없이 모자랍니다. 심지어는 대부분의 대학생들은 소프트웨어 공학에서 가르치는 대부분의 내용을 진정으로 이해하지도 못합니다.
소프트웨어 공학을 실무 경험은 없이 대학에서 가르치기만 하는 사람은 오히려 그 형식에 치중에서 전문가라고 보기 어려운 경우가 많습니다. 

그렇습니다. 현실에 적용해서 진짜로 시간과 비용을 줄일 수 없다면 진짜 소프트웨어 공학이 아닙니다. 좋은 방법론을 적용했더니, 개발시간이 더 오래 걸리고, 맨날 밤을 세야 하고, 개발자들의 사기도 떨어진다면 제대로 적절하게 적용한 것이 아닙니다.

소프트웨어 공학의 본질을 알아야 겠습니다. 근본은 바뀌지 않지만 그 방법은 소프트웨어 기술의 변화와 발전에 따라서 계속 바뀌어 나갈 것이라는 것을 쉽게 예측할 수 있습니다. 꾸준히 좋은 개발팀과 회사를 유지하려면 끊임 없는 개선이 필요합니다.



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

전규현 소프트웨어이야기 소프트웨어 공학

  1. 저도 소프트웨어 공학(테스트 부터) 이론은 업무를 진행한 후에 알았습니다. 제가 이렇게 해 보면 어떨까?해서 적용했던 방법(프로세스, TC 작성 방법, 인프라 구축)이 나중에 "아~ 이게 이거구나?"하는 것을 많이 느꼈습니다. 그 때는 좀 체계적으로 공부하고 싶다는 생각도 들곤 했습니다. 그러나 SE는 실무에서 나온 아이디어와 경험많이 당장의 개선에 도움이 된다는 확신이 섰습니다. 물론 선행 SE를 위한 노력도 해야겠지만 저하고는 잘 맞지 않은 것 같습니다. ^,.^;

  2. 정의의소님. 사실 미국에서도 개발자들이 이건 "소프트웨어 공학"에 입각하여 이렇게 하는 것이다 라고 생각하고 일하지 않죠. 그냥 다들 그렇게 하고 그렇게 하는 것이 당연하니까 하는 것들일 뿐인 경우가 대부분이죠. 어떻게 보면 그것이 당연한 것입니다.
    우리나라는 아직 너무 주먹구구식으로 개발하는 곳이 많아서 현실에서 배우기 어려우니 좀 체계적으로 따로 공부하고 경험자에게 배우고 토론하면 소프트웨어 공학을 별도록 익힐 필요가 있습니다.

  3. Software Engineer와 Engineering을 굳이 구분할 필요가 있을까요?
    뛰어난 Engineer가 뛰어난 Engineering을 한다는건 당연하겠지만
    현업에서는 둘을 다르게 보고 있는게 아쉽네요. 왜일까요?

  4. YUZI님 안녕하세요.
    현업에서는 아직 Software Engineering에 대한 인식은 별로 없는 것 같습니다.

  5. Blog Icon
    [1002]

    궁금한 점이 있습니다. 소프트웨어 공학의 원리와 바뀌지 않는 근본은 무엇인가요?

  6. [1002]님 안녕하세요.
    참 멋진 질문입니다. ^^

    세상의 어떤일이 근본과 원리를 한 문장에 설명할 수 있을까요? 예를 들어 성철 스님이 "산은 산이요, 물은 물이요"라고 세상의 원리를 한문장에 압축해서 말을 하지만, 이를 이해하는 사람은 거의 없죠. 이를 이해하는 사람은 이미 세상의 원리를 깨달은 사람이겠죠. 소프트웨어 공학의 목적은 소프트웨어를 "최소의 비용으로 최단 시간에 개발하는 것"입니다. 이것을 하나의 방법 또는 방법론으로 제시할 수 없는 이유이기도 합니다. 그리고 많은 실무 경험과 지식에 의한 깨달음이 있어야 그 근본은 알 수 있을 것입니다. 또, 자신은 어느정도 터득했다고 생각했어도 아닌 경우도 많습니다.

    제가 저술한 "소프트웨어 개발의 모든 것"이라는 책도 이런 저런 다양한 방법을 기술하기보다는 소프트웨어 공학의 근본 즉, 소프트웨어를 잘 개발하는 기본 원리에 포커스해서 기술한 책입니다. 소프트웨어 공학의 근본에 대해서 어느 정도 깨닫고 있다면 이책을 보고 거의 모든 내용을 공감하거나 오히려 자신의 의견도 피력할 수 있을 것입니다. 그리고 나면 저와 더 심도 있는 얘기를 할 수 있을 것 같습니다.

소프트웨어 공학이 왜 필요하지? 복잡하기만 한데...

2008.12.11 14:16 by 전규현


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



소프트웨어 공학 블로그를 운영하고 있으면서도 전면에는 소프트웨어 공학이라는 말을 사용하고 있지 않습니다. 그 이유는 소프트웨어 공학은 막연하고 왠지 모르게 문서도 많이 만들어야 할 거 같고, 절차도 엄격히 따라야 할 것 같아서 부담스러운 느낌을 줄 수 있기 때문입니다.

이것이 다 소프트웨어 공학에 대한 오해에서 비롯된 것 같습니다. 이미 유행이 한번 쓸고 지나간 CMMI나 외국의 유명한 방법론들을 도입했다가 실패한 경험과 소문들 때문일 겁니다. 
 
Naver 백과사전에서 소프트웨어 공학을 찾아봤습니다.
다음과 같이 설명되어 있더군요.

요약
컴퓨터 소프트웨어의 계획·개발·검사·보수·관리 등을 위한 기술과 그것을 연구하는 분야이다. 소프트웨어의 규모가 커지고 복잡해짐에 따라 공학적인 접근으로 구조화 프로그래밍을 도입한 것이다

본문
컴퓨터 시스템의 가격에서 소프트웨어가 차지하는 비율은, 컴퓨터가 생겨난 직후인 1955년경에는 20% 미만이었지만, 그 후에 급격히 높아져 80년대 후반에는 80~90%에 이르렀다. 이것은 요구되는 소프트웨어의 규모가 커짐에 따라 복잡해진 데 기인한다. 또, 요구되는 소프트웨어가 점차 복잡해진 반면, 그것에 대처할 수 있는 소프트웨어 기술(개발기술 및 관리기술)이 뒤따르지 못하기 때문이다. 그 결과, 소프트웨어는 항상 납기()에 늦어져 비용이 많이 들고 당초의 규정을 충족시키지 못하고 있으며, 신뢰성이 없고 영구히 보수해야 하고, 투명성()이 결여되고, 보수할 수가 없으며, 수정 ·개량할 수도 없다는 ‘소프트웨어 위기()’라고 불리는 징후가 나타나기 시작했다. 그 원인으로서, 모든 공학 분야에서 공통된 기본적인 설계절차를 밟지 않고 있다는 지적이 일기 시작하고, 소프트웨어의 개발에 스트럭처드 프로그래밍(structured programming:구조화 프로그래밍)과 같은 공학적 어프로치(approach)가 도입되기에 이르렀다.

소프트웨어에 소요되는 비용을, 계획에서 보수에 이르는 각 단계가 차지하는 비율로 보면, 요구하는 정의() 및 방법의 기술() 단계에 약 10%, 설계단계에 약 10%, 프로그래밍단계에 약 10%, 테스트 및 디버그 단계에 약 20%, 그리고 보수에 소요되는 비용이 약 50%를 차지한다. 검출되는 에러로는, 설계단계 및 그 이전의 것이 약 60%나 된다. 종래까지는 프로그래밍 단계가 강조되었으나, 소프트웨어의 ‘라이프사이클’을 인식하고 사태를 개선할 필요가 있다. 그러기 위해서는 과학적인 지식을 축적하고, 이를 실제적으로 응용해야 하는데, 이것들을 다루는 분야가 곧 소프트웨어 공학이다.


상당히 복잡하죠. 매우 잘 쓰여진 글이지만 한번에 딱 뭐다라고 이해하기 어려운 글입니다.
소프트웨어 공학이 무엇인지 한마디로 정의하면 다음과 같습니다.
 
"소프트웨어를 최소 비용으로 최소 시간에 개발하는 방법"
 
소프트웨어 공학의 목적 자체가 이거니까 이를 증명할 필요는 없습니다. 

방법론이나 소프트웨어 공학의 일부를 적용했더니, 시간도 더 많이 걸리고 개발자들이 더 힘들고 효율적이지 못하면 뭔가 잘못된 겁니다. 단순한 Learning curve가 아니라면 다시 생각해봐야 합니다. 어딘가 잘못된 부분이 있을 겁니다. 주변에 전문가가 있으면 의논하는것이 좋습니다.

위 정의에 대해서는 지금으로서는 믿어주기를 바랄 수 밖에 없습니다. 위의 말은 간단해도 소프트웨어 개발현장에서는 수많은 충돌이 일어납니다. 문서를 만드는 것이 더 오래걸린다고 하기도 하고, 프로세스는 거추장스럽다고 하고, 개발자와 직접 얘기를 하는 것이 더 빠르다고 합니다. 이 정도는 간단한 이슈입니다. 훨씬 복잡한 상황이 많기 때문에 일단은 믿고 시작하는 수밖에 없습니다.

위 백과사전의 설명을 보면 80년대 말에 미국에서는 다음과 같은 일들이 일어났다고 합니다.
소프트웨어는 항상 납기()에 늦어져 비용이 많이 들고 당초의 규정을 충족시키지 못하고 있으며, 신뢰성이 없고 영구히 보수해야 하고, 투명성()이 결여되고, 보수할 수가 없으며, 수정 ·개량할 수도 없다는 ‘소프트웨어 위기()’라고 불리는 징후가 나타나기 시작했다.
 
내 기억으로는 우리나라 80년대 후반은 소프트웨어 태동기였기 때문에 우리와는 거리가 먼 얘기죠.
오히려 위 문장이 지금의 소프트웨어 환경 및 현상과 많이 비슷합니다.
미국 및 소프트웨어 선진국들은 이를 해결하기 위해서 10~20년을 노력했습니다. 그래서 나온 것이 소프트웨어 공학인데, 우리도 똑같이 10~20년을 낭비할 필요는 없다고 봅니다. 모두들 노력만하면 그러한 시행착오 없이 몇 년 안에 우리도 소프트웨어 공학을 개발 현장에 자리잡도록 할 수 있습니다.
 
소프트웨어 엔지니어들… 고집 셉니다.
많은 개발자들이 자신들이 하고 있는 방법이 최선인줄 알고 있습니다. 하지만 이미 전세계의 선배들이 수십년 전부터 이미 고민했던 문제를 또 되풀이하고 있는 경우가 대부분입니다.
특별히 배운 것 없이 선배들에게 좀 배워서 하던 방식대로 개발을 하고 있다면 거의 나름대로의 개발방식으로 개발을 하고 있을 겁니다. (제가 컨설팅을 하면서 실제로 느낀 겁니다.)
"우리는 다르다"라고 하시는 분들도 매우 많습니다. "우리는 다르기 때문에 일반적인 방법을 적용할 수 없다"라고 말씀을 하십니다. 
99%의 경우 다르지 않습니다. 다르지 않으니 다행이지요. 배우고 따라할 것이 있으니까요. 
우리는 세계 소프트웨어 역사에 비해서 1/3밖에 안되는 역사를 가지고 있다는 것을 명심해야 합니다. 한마디로 배울 것이 많다는 거죠. 자신의 방식을 고집하고 있다면 마음을 열고 넓게 봐야 합니다.

소프트웨어 공학은 학교에서 배울 수 없다고 되어 있습니다. 물론 대학에 과목이 있기는 하죠. 하지만 용어들을 익히는 것이지 실제로 그것이 무엇을 뜻하는지는 대부분의 학생들은 이해를 못한다는 겁니다. 즉, 현장에서 배우는 것이 소프트웨어 공학입니다. 대학에서 배운 학생들은 더 빨리 배우기는 하겠죠. 따라서 언제라도 시작해도 늦지는 않습니다. 그동안 쌓은 경험이 도움이 될 수 있습니다. (방해가 되는 경우도 많이 봤습니다.) 그리고 쉽게 배울 수 있는 것도 아니고 그 범위도 매우 큽니다. 시간도 많이 걸리죠. 또, 그 과정에서 별 쓸데 없는 것에 매달리면서 시간 낭비하는 경우도 정말 많습니다.

이럴때 유경험자나 전문가가 주위에 있는 것이 정말 좋습니다. 머리에 지식을 넣어주기는 어려워도 서로 의견을 주고 받고 있다면 쓸모없은 것 공부하느라고 시간을 허비하는 것은 줄일 수 있습니다. 
 
앞으로 계속 연재해 나갈 소프트웨어 공학의 구체적인 내용들이 소프트웨어 공학을 이해하고 실제로 개발에 접목하는데 도움이 되기를 기대합니다. 
 
소프트웨어 개발 시의 애로점, 개발자 진로의 고민, 소프트웨어 공학에서 알고 싶은 내용은 언제든지 메일이나 방명록으로 의견을 주시면 정성껏 답을 드리고 같이 의논할 수 있도록 하겠습니다.
 
 (아래는 소프트웨어 Requirements에 관련된 재미있는 그림입니다. Document 부분의 맨땅이 인상적이네요.)
저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 소프트웨어, 소프트웨어 개발, 소프트웨어 공학

  1. 팀에서 개발경험없는 소프트웨어 공학을 전공한 석/박사님들과 충돌을 많이했습니다. 학교에서 배우지 못하는 학문이라서 그랬을까요? ^^;
    앞으로 올라올 포스팅이 기대되네요... 저도 많은 의견 올리겠습니다. ^,.^;

  2. 정의의소님 안녕하세요.
    실전을 모르고 대학에서 소프트웨어 공학을 연구하시는 분들이 계십니다. 그런 분들을 헐뜻는 것은 아니지만 그런 분들은 계속 연구쪽으로 하시는 것이 좋겠죠.
    실전은 다르니까요. 물론 그런 분중에는 실전 경험도 두루 갖추고 계신 분들이 계시죠.
    연구파와 실전파 정도로 나눌 수 있겠죠.
    미국에서도 소프트웨어 공학을 가르칠 때 "가르칠 수 없다", "배울 수 없다"라고 하고 가르친다고 합니다.
    현실 소프트웨어 개발 현장에서는 탄탄한 이론에 기초를 둔 실전파들이 필요하다고 생각합니다.

    그런 경우 그분들이 실전을 잘 몰라서 그런다고 생각하십시오. 소프트웨어 공학이 기계적으로 적용하면 된다고 생각하면 그분들이 잘못 배운 것이거나 경험없이는 안되는 것이 소프트웨어 공학인 것이지요.

    제 생각에는 소프트웨어 공학은 실전 경험이 있는 분들에게 가르치는 것이 좋을 것 같습니다. 현재 KAIST에는 경험자를 위한 소프트웨어 공학 코스가 있는 것으로 알고 있습니다. 대부분 10년 이상 경험이 있는 분들이 수강을 하는데, 그정도는 되야 가르치는 것을 이해한다고 하더군요.

  3. 제 trackback에 있어서 타고 왔더니 정말 좋은 글이 있군요;ㅁ;
    금일 다음 클릭애드클릭스 블로그 선정이 안되어서 우울했는데..
    정리의 진수를 보여주시는군요..잘보고 갑니다^0^/

  4. 열정태하님 안녕하세요.
    소프트웨어공학에 관심이 있으신 것 같아서 트랙백을 남겼습니다. 블로그 가보니 좋기만 하던데 왜 선정이 안되었을까요? 너무 뻑뻑하네요. 힘내세요.
    감사합니다.

  5. 트랙백 있길래 와봣습니다.
    참 좋은 내용은 많네용..
    흠..소프트웨어 공학..학교때 배워도.어찌보면...그때는 아하 그랫어도 실상 개발자로 살아가다보면 간과 하게되죵..역으로 다시 서적을 통해 보고 있습니다.
    잘 보고 갑니다.

  6. 쇼팬하워님 안녕하세요.
    그래서, 소프트웨어 공학에는 경험이 정말 중요한 것 같습니다. 우리가 아는 유명한 소프트웨어 공학자들도 대부분 실전파 잖아요.

  7. Blog Icon
    지나가다가

    그렇다면 '공학'이란 말을 빼야겠네요. ^^

  8. Blog Icon
    나르사스

    음...저는 학교에서 배울때 소공의 목적이 요즘은 빨리 만드는것보다는 유지보수가 용이하게 잘 만드는 추세로 간다고 들었던 것 같은데, 뭐가 맞는 걸까요? 연구실파는 아니셨는데요...ㅡ.ㅡ;;

  9. 나르사스님 안녕하세요.
    의견 감사합니다.
    저는 실전파 맞습니다. 그리고 소프트웨어 개발에 소프트웨어 공학을 적용하는 것은 프로젝트 비용 및 기간 단축과 유지보수를 용이하게 만드는 것 모두 해당합니다.

    추세를 말씀하셨네요. 갈수록 소프트웨어의 유지보수가 중요해지고 있습니다. 실제로 소프트웨어는 개발보다도 유지보수에 더 많은 비용이 듭니다. 그래서 유지보수의 비용을 줄이는 것도 매우 중요합니다.

    주먹구구식으로 개발하는 소프트웨어 프로젝트는 초기에는 빠른 것 같지만, 프로젝트가 막바지로 갈수록 뒤죽박죽이 되어갑니다. 그리고 이렇게 개발한 프로젝트가 더 빨리 끝나는 경우도 가끔 있으나 유지보수에 더 많은 비용이 드는 것이 일반적이지요.

  10. 녹차프린스님의 글부터 시작해서 트랙백을 따라서 여기까지 왔습니다.
    알찬 글들이 많이 있네요.
    잘 읽고 갑니다. 구독링크하고 자주 방문하겠습니다. ^^*

  11. 필넷님 안녕하세요.
    새해 복 많이 받으세요. 좋은 블로그를 운영중이시더군요. RSS 등록해서 볼려고 합니다. 감사합니다.

오늘도 밤을 세워야 하는 개발자 (야근 탈출)

2008.12.08 16:57 by 전규현


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



옛날부터 내려오는 경영자들이 믿고 있는 미신이 있습니다.

"개발자의 Output은 근무시간의 양에 비례한다."

말은 아니라고 하면서도 밤에 사무실이 텅 비어 있으면 개발자들이 군기가 빠졌다고 생각하고 주말에 누가 나와서 일하나 확인하러 가끔 사무실에 들르는 사람들이 경영자입니다.

실제로 근무시간에 성과가 비례하는 개발자들이 있다면 공장에서 벽돌 찍어내는 것과 다를 바가 없겠지요.
이 미신은 믿기 싫지만 자꾸 저절로 손이 가는 새우깡처럼 믿게 되고, 회사 조직에서 위로 올라갈수록 더 맹신하게 되나 봅니다.

이러한 이유로 어쩔 수 없이 또는 습관적으로 야근을 하는 개발자가 있다면 십중팔구 미혼이거나 결혼을 했어도 아이가 없겠죠.
이런 정상적이지 않은 생활을 하며 10, 20, 30년간 소프트웨어 엔지니어 일을 할 수는 없겠죠.

나는 "개발은 창의적인 작업으로 그 성과는 충분한 재충전에 나온다"고 믿고 있습니다.

그렇게 합리적인 시간에 개발을 하려면 소프트웨어 개발은 좀더 체계적이고 효과적으로 진행해야 합니다.
지금의 일반적인 경우처럼 일단 프로젝트를 시작해서 개발자들이 능력껏 그럭저럭 진행하는 방법으로는 또 개발자의 야근은 피할 수 없고, 별로 빠르게 끝나지도 제품의 품질이 좋지도 않게 됩니다.

그래서 소프트웨어 개발에 소프트웨어 공학을 적용하는 것이지요.
말은 거창한 것 같지만, 소프트웨어 공학이라는 것이 소프트웨어를 최소비용으로 최단기간에 개발하기 위한 온갖 방법들을 말하는 겁니다. 결코 교과서의 내용이 아니고 현실에서 수많은 회사들이 경험을 통해서 내려오는 방법이고 여러분들도 상당부분은 익히 알고 있는 방법들입니다. 이 블로그의 주제이기도 하고요.

다시 개발자들이 밤을 세지 않기 위한 방법으로 되돌아 와서 그 방법을 알아봅시다.

일단, 경영자의 인식이 바뀌어야 하는 것은 당연한 일인데, 어떻게 손을 델 수가 없는 일입니다.
그리고 나면 아래와 같이 개발자들과 프로젝트팀이 행할 수 있는 3가지 방법이 남습니다.

  • 정확한 일정 예측
  • 체계적인 개발 방법 
  • 합리적인 일정 복구 

첫째, 정확한 일정 예측입니다. 이는 모순된 문장입니다. 어떻게 예측을 정확하게 하나요? 하지만 예측이란 그때 상황에서 최선을 다해 정확하게 예측을 해야지요. 
당연히 프로젝트가 시작하자마자 정확한 예측은 불가능합니다. 아직 스펙이 정해지지 않았거든요.
그래서 프로젝트가 시작할 때는 대충을 일정을 가지고 시작을 하다가 스펙 작성이 완료되면 스펙을 근거로 1,2일 단위의 정확한 WBS를 작성하여 소요일정과 투입인력을 따져서 프로젝트 일정을 작성해야 합니다.
회사의 모든 관련자들은 프로젝트가 시작할 때 정해진 일정을 진짜 일정으로 봐서는 안됩니다. 스펙 완료 후 작성된 일정을 진짜 일정으로 봐야지요. 이것을 당연히 이해 할 수 있어야 얘기가 되지요.
그리고도 일정은 개발중간에 지속적으로 점검하며 일정이 틀어지면 대응을 해야 합니다. 1,2일 단위로 작성된 일정은 조금만 늦어져도 금방 문제를 파악할 수 있습니다.

둘째, 체계적인 개발 방법입니다. 
이 부분은 책 한 권을 써도 될 만큼 많은 양이고 앞으로 블로그에서 지속적으로 다룰 내용이니 간단히 소개만 하겠습니다. Stage를 따라서 개발을 하거나, Daily Build를 하고, 소스코드관리/버그관리시스템을 사용하고, 피어리뷰/코드리뷰를 하고, 모든 이슈를 투명하게 Open하고, Build를 자동화하는 등 수많은 방법들을 당연히 사용해야 할 것 입니다.

셋째, 합리적인 일정 복구입니다.
프로젝트는 어쨌든 늦어지게 마련입니다.  
다음 그림을 보면 현재 프로젝트 진척이 계획보다 늦어지고 있습니다. 이럴 때 다음 4가지의 방법이 있습니다.


A. 더 낮은 우선순위의 요구사항은 다음 버전으로 연기한다. 
B. 개발자를 추가로 투입한다. 
C. 시간외 근무를 단기간 동안 강제로 시킨다. 
D. 일정을 연기하여 추가된 기능을 수용한다. 

여기서 대부분의 회사가 C를 주로 선택하고 가끔 B를 선택합니다.
C는 단기적으로는 효과가 있지만, 이 기간이 길어지면 별로 효과도 없을 뿐더러 개발자 사기만 떨어지고 회사의 경쟁력도 잃고 개발자도 잃게 되는 방법입니다. 
B는 효과가 거의 없는 것으로 익히 잘 알려져 있습니다. 프로젝트 후반에 개발자를 투입하는 것은 기존에 열심히 개발하고 있는 다른 개발자들에게 방해만 되는 경우가 허다합니다. 기존 개발자들은 이들을 가르치느라고 시간을 허비해야 하고, 새로 투입된 개발자는 별로 성능을 발휘하지 못하며 버그도 많이 만들어내는 경우가 허다합니다.
프로젝트가 늦어지고 있는지 전혀 신경을 쓰지 않다가 프로젝트 막바지에 가서야 한참 늦어지고 있다는 보고를 받고 부랴부랴 대책을 세울 때 선택하는 방법이죠.
가장 좋은 방법은 A입니다.
여기서 중요한 점은 모든 프로젝트를 시작할 때 프로젝트가 늦어질 수 있다는 것을 미리 생각해야 한다는 것입니다.
그래서 스펙의 각 기능은 Priority(우선순위)를 정해줘야 합니다. 그래서 일정이 늦어지면 우순선위가 낮은 기능을 연기하고 프로젝트를 종료하는 것입니다. 그러기 위해서는 개발 순서도 우선순위가 높은 기능부터 개발이 진행되어야 합니다.
이러한 모든 것들이 체계적으로 합리적으로 진행이 되어야 중요한 프로젝트를 하더라도 퇴근 후에 가족과 식사를 하고 아이들과 놀 수 있는 시간이 생깁니다.

위와 같이 합리적이고 체계적인 절차에 의한 데이터를 근거로 경영층에 보가 되고 투명한 개발진행이 경영층에 신뢰를 준다면 하루 8시간 근무하는 날이 점점 늘어 날 수 있을 것입니다.

개발자 혼자서 할 수 있는 일은 결코 아니고, 회사가 조직, 프로세스, 시스템등 모든 것이 바뀌어 나가야 가능한 일입니다.

이미지출처 : Microsoft Office Online

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

전규현 프로젝트/일정 8시간근무, 소프트웨어, 소프트웨어 개발, 소프트웨어 공학, 일정

  1. Blog Icon
    붉은칼

    이상적인 환경이네요. 아웃소싱, SI 업계에서는 조건부터 잘못되서 적용이 안될거 같고, 금융 또는 IT 대기업 사내 소프트웨어 연구실 정도면 어느정도 현실화 될지도. 아마 괜찮은 회사에서는 벌써 적용될지도 몰르고. 그러나, 99% 개발자에겐 그림의 떡일듯. 불쌍한 우리회사 개발자들..--;
    실력있는 개발자 같으신데 기회가 되면 창업한번 해보세요. 다양한 경험을 통해 좀더 현실적인 답을 찾아내시길~

  2. 저희 팀이 보편적인 프로젝트라고 보기는 힘들지만, 분명 SI 업계의 아웃소싱 프로젝트에서 위 내용을 토대로 진행을 해서 야근을 없앴습니다.
    팀원 중 2명은 야간 대학원에 다니기 까지 하고 있습니다.
    중요한 일이 무엇인지 판단을 하고, 고객이 원하는 것이 무엇인지 정확하게 판단하는 것과 구현을 분리하지 않고 일하는 것, 작업을 잘게 쪼개서 예측가능하게 하려는 노력은 현실적인 답을 만들어냅니다.

  3. 영회님 안녕하세요.
    역시, 이 댓글 하나만 봐도 영회님과 그 개발팀이 어느정도의 실력과 경험이 있는지 알 수 있겠네요.
    말은 쉽지만 실제로 그렇게 실행하고 있다는 것은 이해의 단계를 넘어서 내제화를 이루고 있다고 할 수 있습니다. 감사합니다.

  4. 붉은칼님 안녕하세요.
    우선 밝혀둘 것이 있습니다. 저는 소프트웨어 개발컨설턴트로서 대한민국의 어떠한 개발자와 비교해도 부족하지 않은 개발 및 컨설팅의 지식과 경험이 있습니다. 수백만명이 쓰는 제품, 전세계인이 쓰는 제품, SI등 다양한 분야의 경험을 풍부하게 다 가지고 있습니다. 제가 쓰는 글들은 모두 경험에서 나온 글들입니다. 또한 저희 펌에서는 한국과 미국에서의 20년이상의 소프트웨어 개발에 대한 다양한 노하우를 가지고 있습니다. 그냥 단순히 보고 들은 내용을 옮기는 것으로 오해하지 마시길 바랍니다.

    제가 컨설팅을 하면서 만난 거의 모든 회사는 "우리회사는 다르다"라고 합니다. SI다, 금융이다. 이유는 많지만 사실을 다 똑같습니다. 원리는 같다는 얘기입니다. 99%의 개발자에게 그림의 떡이 아니고 99%의 개발자에게 가능하고 그래야 더 품질이 좋은 제품이 개발되고 회사의 경쟁력이 더 높아집니다.
    8시간 근무를 하는 이유도 더 개발을 잘하고 빨리 하기 위해서임을 명심해주시면 좋을 것 같습니다. 잘 이해가 안되면 붉은칼님에게는 정말 좋은 기회인 것 같습니다. 소프트웨어 엔지니어링이 가져올 좋은 개발환경에 대해서 앞으로 제 블로그를 지속적으로 관심을 가지고 봐주세요. 점점 더 구체적인 글들을 작성해 나갈 겁니다.
    감사합니다.

  5. Blog Icon
    Jake

    저도 동감합니다. 저도 지금까지 거친 회사에서 항상 개발 프로세스를 체계화 해 보려고 노력했지만 (지금도 하고 있습니다) 항상 나오는 말은 "우리는 그런거 적용 못해" 라는 겁니다. 하지만 한가지 짚고 넘어가고 싶은 부분은 Ray 님의 말씀처럼 원리는 다 같다고 할 수 있겠지만 원리와 현실의 차이는 무시할 수 없다고 생각합니다.
    따라서 원리나 원칙을 적용하고 그에 따르도록 하는 것 보다는 그 회사의 특수성을 이해하고 받아들여 그에 맞게 차용(adopt)하는 것이 가장 현실적이고 바람직하지 않을까 하는 생각입니다.
    아시다시피 미국회사라고 야근 없는 것 아니고 주말에도 일할 때도 많습니다 - 전 미국에 있습니다. 개발자란 직업의 특수성이라고 생각합니다. 제 처제는 게임회사 그래픽 디자이너인데 프로젝트 마감일 다가오면 집에도 못가고 주말에도 밤새서 일합니다. 하지만 릴리즈 후에는 2주 - 3주 정도의 휴가를 받습니다. 고생 후 그만큼의 보상이 따른다는 것이 한국과의 다른점이라고 생각이 됩니다. 이는 IT 업계뿐 아닌 사회 전반적인 문화의 차이가 아닐까 하는 생각이 되네요.

  6. Jake님 안녕하세요.
    정확한 말씀입니다. 평소에 제가 하는 말이죠.^^
    Jake님은 한번 만나뵈고 싶은 분이네요.
    앞으로 좋은 교류 지속되기 기대합니다.

  7. 미국의 개발자들은 야근을 안하는가? 하는 오해가 있을 수 있습니다. 미국의 개발자들도 야근을 많이 하기로 유명합니다. 하지만 우리와는 경우가 좀 다릅니다. 대부분 체계적으로 개발을 하는데도 야근을 많이 하는 거죠. 특히 MS는 야근을 많이하고 그만큼 많이 보상해주죠. 많이주고 많이 뽑아먹기로 유명합니다.

  8. 정말 공감이 가는 글입니다. 이 글은 경영자 필독입니다.

  9. HannaKim님 안녕하세요.
    소프트웨어 엔지니어링에 관심이 많으신 분을 만나서 반갑습니다. 앞으로 좋은 얘기 많이 주고 받으면 좋겠습니다.
    감사합니다.

  10. 좋은 말씀 잘 보고 갑니다. 선택할 위치에 있는 분들의 뿌리깊은 잘못된 사고방식이 합리적으로 바뀌었으면 좋겠는데, 개발자 출신의 관리자들도 똑같은 생각은 가지신 분들이 많으니 요원한 일로 보이기도 합니다. 하지만 점점 좋아지겠죠? ^^

  11. cozydev님 안녕하세요.
    개발자가 좀더 전문적이어야하지 않을까요? 주먹구구식으로는 경영자를 납득시키기는 어려울 것 같습니다.

  12. Blog Icon
    다른개발자

    뭐 워낙 대단한분들이 모이신거 같은데 읽다가 저도 생각을 한줄 표현할까 해서 올립니다만...
    환경이 열악한건 사실이죠..근데 환경이 언젠가는 좋아지겠지라는 생각과 그런날이 올까? 라는 생각이 주를 이루는데요...?너무 환경탓을 하기 보다는 자신에게 주어진 환경을 자기가 만들어 갈수 있다는 생각을 가지는것이 중요하다고 생각합니다. 저도 적지않은SI 경험을 가지고 있지만...SI하면서도 일빨리 끝내고 일찍가는 개발자 많고요... 일잘하면 요새는 관리자도 특별히 근태 터치 안합니다.물론 기본적 근태는 지켜줘야죠 9시 출근 6~7시 퇴근 그러다가 일주일에 한두번정도는 8~9시 퇴근 이정도면 처자식과 가정생활 하면서도 충분히 SI에서도 개발자로 생활 가능하다고 보는데요..

  13. 안녕하세요.
    잘하고 계시는 것 같습니다. ^^ 사실 SI나 팩키지나 소프트웨어 개발의 기본은 거의 같죠.

우리 개발자는 뭐든 뚝딱 잘 만들어요.

2008.12.08 11:24 by 전규현


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





소프트웨어를 개발하기 위해서는 기본적으로 갖춰야 할 인프라스트럭쳐시스템(Infrastructure System, 기반시스템)에 대해서 이미 본 블로그에 글을 올린 적이 있습니다.

그런데 여러 회사를 만나보니 이러한 시스템 중에서 일부를 직접 만들어서 사용하려는 경우를 종종 접하게 됩니다.

이런 회사를 "Tool company"라고 부릅니다.

자신들의 주력 제품이 아니고 개발하기 위해서 필요한 툴들을 만들어서 사용하려는 회사를 말합니다.
물론 워낙 특수한 형태의 툴로서 세상에 존재하지 않거나 구할 수가 없는 예외적인 경우도 있습니다.
하지만 개발 프로세스에 일반적으로 필요한 시스템들은 직접 만들어서 사용한다는 것은 큰 문제입니다.
특히, 버그관리시스템이나 프로젝트관리시스템을 만들어서 사용하거나, 만들려고 시도하는 회사가 많습니다.
그런 회사들은 이렇게 말합니다.

  • 우리회사는 다른 회사와 다르다. 우리는 임베디드 소프트웨어를 개발한다. 우리는 금융회사다. 우리는 게임회사다. 우리는 포탈이다. 이유도 많습니다.
  • 상용제품의 우리회사만의 요구사항을 만족할 수 없다.
  • 우리가 만들면 사용제품보다 더 잘 만들 수 있다. 
  • 우리 입맛에 딱 맞게 만들 수 있다. 그리고 필요할 때 언제든지 수정해서 사용할 수 있다.

특히, 개발자들이 이런 주장을 하는 경우가 흔합니다. 개발자들은 이런 것을 만드는 일을 만만하게 보는 경우가 많습니다. 경험이 적은 개발자들은 단순히 코딩해서 동작하도록 구현하는 것만 생각하는 경우가 흔합니다. 그 뒤에서 수십배의 일과 문제가 기다리고 있다는 것은 잘 모릅니다.
당장 원하는 기능의 툴을 만드는 것은 어려운 것이 아닙니다.
일단 툴을 만들어서 사용하기 시작하면 개미지옥에 빠져든 개미처럼 점점 빠져들며 헤어나오기 어려워집니다.
이렇게 만들어진 툴도 하나의 소프트웨어로서 유지보수가 필요해집니다. 기존의 버그도 잡아야겠고, 사용하다가 불편하면 계속 수정사항을 요구합니다. 
만들 때는 간단해 보였는데, 쓰면 쓸수록 손 볼일이 많아집니다.
본연의 개발업무에 집중해야 할 개발팀이 내부 툴 유지보수 하느라 시간을 낭비하고 쓸수록 기능도 만족스럽지 않다는 것을 알게 됩니다.

일단 우리회사는 다른 회사와 다르다고 생각하는 것은 좁은 시야와 경험의 부족에서 오는 착각입니다. 그리고 상용제품이 우리회사의 요구사항을 만족할 수 없는 것이 있다면 회사가 바뀌는 것이 좋습니다. 이 경우 회사의 프로세스가 잘못되어 있을 확률이 99%이상입니다. 사소하게 보아 넘기는 기능 하나하나에 깊은 의미가 있다고 생각하고, 좋은 툴이라면 거기에 맞추겠다는 생각으로 회사의 프로세스나 조직, 문화 등을 먼저 다시 생각해보는 것이 좋겠습니다.  

좋은 툴을 도입하는 것은 단순히 비용을 절약하는 것을 떠나서, 회사의 개발 프로세스까지 선진화된 형태로 바꿀 수 있는 힘이 있습니다. 반대로 말하면 이러한 툴이 없이 제대로 된 개발 프로세스로 개발을 하는 것이 불가능하다는 의미이기도 합니다.

이러한 것을 만들어서 쓰려는 "Tool Company"가 되어서는 안되고 좋은 툴을 찾아서 전사적으로 사용하면서 선진적인 개발프로세스와 문화를 받아들이는 자세가 필요합니다.

이미지출처 : Microsoft Office Online

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

전규현 기반시스템 소프트웨어 공학, 인프라스트럭쳐

우리나라에는 전지전능한 슈퍼 개발자가 있다.

2008.12.04 23:14 by 전규현


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





여러 소프트웨어 회사를 컨설팅하다보면 아주 많은 개발자들을 만나게 됩니다. 
그 중에는 전지전능한 슈퍼 개발자를 만나게 됩니다.

코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반 관리, 아키텍처 등등 엄청나게 많은 일을 하는 개발자들을 보게 됩니다.
이들은 대부분 팀장 쯤 됩니다.

어떻게 생각하시나요? 
바람직해 보입니까?
"나도 그런 전지전능한 개발자야 돼야지"라는 생각이 드십니까?
혹시 지금 이렇게 모든 분야의 일을 다 하고 계시나요?

이것은 One man company 얘기가 아닙니다. 
개발자가 100명이 넘는 회사도 이러한 경우를 여럿 봤습니다.
대부분은 회사가 성장과정에서 적당한 때에 조직을 변화시키지 못하고 그냥 달려온 경우입니다.
이런 경우 전지전능한 개발자가 대부분의 기술과 이슈를 꽤 뚫고 있어서 조직이 그럭저럭 굴러갑니다. (개발자들은 몰라도 사장님은 고민 많으실 겁니다.)
모든 길은 로마로 통하듯 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결됩니다.
이런 개발자가 나가면 회사는 망할 것만 같습니다.

이러한 상황이 정상일까요?

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능합니다. 아주 작은 회사라면 그렇게 해야지요. 다른 대안이 없으니까요.

이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 합니다. 그건 애초에 불가능합니다.
이들은 예전에는 뛰어난 개발자였습니다. 하지만, 개발 이외의 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됩니다. 그리고 각 일의 Switching cost가 만만치가 않습니다. 이일하다 저일하다하면 그냥 시간이 지나가버리지요. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했습니다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거죠.

심지어는 테스트, 고객 전화응대, 고객 지원까지 한다는 것은 100원의 돈을 받으면서 20원짜리 일을 하는 것과 같습니다. 그런 일은 싸게 고용할 수 있는 사람을 시켜야지요. 그리고 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못합니다. 

결국 이 개발자는 다른 소프트웨어 회사에 가면 별로 가치 없는 개발자가 되고 맙니다. 분야가 달라지면 Domain Knowledge에 의한 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 됩니다. 관리자로 가야 할까요? 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되고 맙니다.

회사는 이들에 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 됩니다.
이들이 등돌리면 회사는 휘청합니다. 

이것이 개발자 탓일까요? 아니면 회사 탓일까요? 
네, 회사 탓입니다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야죠.
그런데 맨땅에 개발자가 북치고 장구치고 다 하다 보니까, 어쩌다보니 그렇게 된 것이지요.

그럼 어떻게 해야 할까요?

조직이 작을 때부터 나중에 커질 때를 대비해야 합니다.
조직이 커지면 언제든지 분리하기 쉬운 업무부터 띄어낼 수 있도록 말입니다.
이렇게 하려면 갖춰야 할 것이 3가지 있습니다.

이는 "프로세스"와 "기반시스템" 그리고 "문서"입니다.

이 3가지가 있어야 개발 조직이 전문적으로 움직일 수 있습니다.
단 제대로 갖춰야지요. (제대로의 의미는 너무 많이 설명해야 하니 앞으로 계속 올리는 글에서 설명하도록 하죠, 그리고 사실 문서는 프로세스에 포함된 것입니다.)

혼자 일을 하더라도 "스펙"을 작성하고 "설계문서"도 작성하고 "Test Case"도 만들어 놓습니다. 물론 남에게 일을 시키는 것보다는 간소화 할 수 있습니다.
인도에 외주를 줄만큼 자세히 작성하는 것은 낭비죠.
그리고 적절한 개발 프로세스를 만들어서 조직이 커질 때마다 그에 알맞게 계속 발전시켜나가야 합니다.
그리고 "소스코드관리시스템""버그(이슈)관리시스템"은 무조건 제대로 갖추고 있어야 합니다.
이 모든 것은 혼자 소프트웨어 회사를 한다고 해도 갖추고 있어야 합니다.

프로세스, 문서 얘기가 나오니까 오히려 개발이 늦어질 것 같은가요?
혼자 개발을 해도 이것들은 꼭 필요합니다. 개발이 더 빨라지고, 제품의 품질도 올라가죠.

왜?

지금 이해가 가지 않는 분이라면, 여기서 납득을 시켜드릴 수는 없습니다. 
제 책(소프트웨어개발의 모든 것)을 읽어보시거나 저를 찾아오시면 친절하게 설명드리겠습니다.
각설하고..

그렇게 준비가 되고 나면 회사 커지면 직무를 하나씩 전문화시켜야 합니다.
우선 "테스트팀"을 만드십시오. 회사가 작다면 이들이 Technical Support(고객지원)도 병행할 수 있을 겁니다. 
물론 테스트 직무도 전문화를 시키십시오. Random Test가 아닌 제대로 된 절차에 의한 테스트를 할 수 있도록 훈련시켜야 합니다. 그 방법은 제 책을 포함해서 시중에 좋은 책들이 얼마든지 있습니다.

그리고 개발자가 많아지면 관리자를 나누고, 기획, 프로젝트 관리자, 빌드/릴리즈 역할을 나눠 나갈 수 있을 겁니다. 

아직 "프로세스", "기반시스템", "문서", 이런 것들을 갖추고 있지 않은 회사라면은 조직을 어떻게 바꿔도 결국 그 전지전능개발자에게 커뮤니케이션이 다 몰리고 리스크는 여전할 것입니다.

이렇게 회사를 바꾸려면 개발자나 회사나 모두 "성장통"을 감내해야 합니다.
개발자는 현재 자신이 하는 일에만 가치가 있다고 생각하면 안됩니다. 좀더 큰일을 하기 위해서 과감하게 현재의 일을 버리고 자신이 가장 잘하는 일에 집중해서 더욱 가치를 높여야 합니다.
회사는 이 과정에서 임시적을 생산성이 떨어집니다. 이 기간이 짧게는 5,6개월에서 길게는 1년이 갈 수도 있습니다. 부작용을 최소화 하기 위해서 점진적인 변화를 할 수도 있고, 전문가를 영입하여 한번에 바꾸는 방법도 있습니다.

회사 안에 있으면 경영자나 개발자나 이러한 상황을 잘 느끼지 못하는 경우가 많습니다.
개구리를 냄비 안의 찬물에 넣고 서서히 데우면 뜨거워서 견지디 못하는 순간이 될 때까지 잘 느끼지 못하는 것과 같은 거죠.
그냥 익숙해지는 겁니다.
이런 경우 외부의 전문가가 회사를 분석하는 것이 효과적일 때가 많습니다.
궁금하신 내용이 있으면 언제든지 E-mail(gracegyu@abcswcon.com)으로 연락주세요. 궁금증을 시원하게 풀어드리지요. 

장문의 글을 읽어주셔서 감사합니다.


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

전규현 개발조직 개발자, 소프트웨어 공학, 조직

  1. 마음에 와 닿는 글입니다.
    좋은글 감사합니다^^~

    전지전능한 개발자가 되려면 분배하고 대화하고 교육하는 그런 노하우도 있어야 하겠지요.
    과연 그런 사람이 얼마나 될까요?

  2. 돌이아빠님 안녕하세요.
    진짜 제대로된 전지전능 개발자면 좋겠죠. 말씀대로 이는 거의 불가능합니다.
    그냥 일만 많이 하는 그런 개발자가 회사의 큰 리스크라는 것이 문제죠.

  3. 좋은 글이네요. 일정정도 맥이 통하는 글을 쓴 것이 있어서 트랙백 달고 갑니다.

  4. 하이컨셉님 안녕하세요.
    작성하신 글은 잘 봤습니다.
    공감이 가는 글이더군요. 앞으로도 좋은 의견 많이 주고 받기를 기대합니다.
    감사합니다. ;)

  5. 전문화된 개발자가 대우 받는 여건이 빨리 형성되었으면 좋겠습니다.

    그리고 정치세력이란 이야기 정말 공감갑니다.
    스트럭쳐(구조)화 하기 좋아하는 경향들이 있어서 그런지 사람 관계도 구조화를 잘 하시는 분들이 많더라구요 ;)

    좋은 글 정말 잘 읽었습니다. ;-)

  6. jangsungjin님 안녕하세요.
    개발자의 정치라는 것은 결국 제살 깍아먹는 것 아닐까요?
    개발자가 실력이 경쟁력이 되어야지, 정치로 얼마나 오래 살아남을 수 있을까요?
    이런 개발자는 실력도 립서비스밖에 없는 개발자가 되더군요.

  7. 모든 것을 다 하려는 개발자는 어쩔수 없이 문맥전환 비용을 치러야하겠죠. 그러다보면 결국 업무 효율은 떨어지게 될 테구요. 잘 할 수 있는 일에 집중하는 것이 좋겠습니다.

    트럭 넘버라는 이야기를 어디서 들었는데요. 개발자가 트럭에 치어 일을 못하게 되는 일이 생기게 되면 프로젝트가 정상적으로 굴러갈 수 없는 일이 생기게 되는데요. 이런 사고로 개발자들의 일부가 동시에 업무를 보지 못하게 될 경우, 최대 몇 명 까지는 그래도 감내할 수 있는가 하는 질문에 대한 답이 트럭 넘버더군요.

    한 사람의 달인에게 프로젝트의 성패를 의존하게 되면, 프로젝트 불확실성은 계속 증가하게 되는 것 같습니다. 가급적 모든 사람이 프로젝트에 대해 고르게 잘 알도록 배려하는 것이 중요하겠죠.

  8. 이병준님 안녕하세요.
    트럭넘버이야기 재미있겠는데요. 블로그에 한번 올려주세요.

    소프트웨어 개발에서 특정인의 의존도를 낮추고 프로세스와 시스템에 의해서 많은 부분을 커버하는 것은 매우 중요합니다. 이것이 소프트웨어 엔지니어링의 중요한 요소이죠.
    그런 환경이어야 프로젝트의 리스크도 줄어들고 개발자에게도 전문적으로 성장할 수 있는 기회를 제공하게 됩니다.

  9. 좋은 글 감사합니다.
    또 하나의 생각은, 슈퍼 개발자는 회사의 환경만이 그 요소일까.입니다.
    즉, 회사에서 모든 것을 의존하는 것은 본디 그 개발자의
    성향에 의해서도 좌우될 것 같습니다.
    그러기에,
    슈퍼 개발자가 될 성향을 가진 사람들에 대한 정상적 멘토링과
    그들이 지속적으로 관심을 가질 요소들을 찾아서 균형적인
    성장을 할 수 있도록 배려가 필요할텐데...
    그런 방안중 하나로 Ray님의 블로그와 책을 추천하는 것도 좋겠군요
    context switching. 팀장님께 말씀드려봐야겠습니다.
    감사합니다.

  10. 오리주민님 안녕하세요.
    모든 것이 복합적인 문제라서 하나의 원인만 고를 수는 없는 것 같습니다.
    멘토링 참 중요한 이슈입니다. 아직 활성화가 많이 안되어 있고, 시행하더라도 여건과 준비가 부족하고 형식적인 경우도 많은 것 같습니다.

소프트웨어 개발 컨설팅

2008.10.07 12:52 by 전규현


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



나는 한글과컴퓨터에서 처음 소프트웨어 개발을 시작했고, 안철수연구소를 거쳐서 현재는 소프트웨어 개발 컨설턴트로 일을 하고있습니다.
누군가에게 나 자신을 소개할 때 "소프트웨어 개발 컨설턴트" 또는 "소프트웨어 엔지니어링 컨설턴트"라고 하면  무슨일을 하는지 잘 모르는 경우가 많습니다.
흔히 소프트웨어 엔지니어(개발자)와 헷갈리기도 하고 솔루션 컨설턴트나 Oracle 컨설턴트를 떠울리기도 하죠.
내가 하고 있는 일은 소프트웨어를 개발하고 있는 회사와 만나서 회사나 개발팀이 가지고 있는 문제점들을 해결하고 좀더 효율적으로 소프트웨어를 개발할 수 있도록 도와주는 것입니다.
개발의 기초라고 할 수 있는 시스템들을 갖추는 것을 도와주고 교육도 시키고, 회사의 개발 프로세스도 정립을 시키고, 소프트웨어 개발에 필요한 실제적인 활동인 요구분석, 설계, 구현 등에 대하여 좀더 효율적인 방법을 적용시키고 있습니다.
그동안 아주 작은 소기업부터 대기업까지 다양한 계층의 회사를 접하면서 많은 회사들이 소프트웨어 개발에 많은 애로를 가지고 있다는 것을 알게 되었습니다.
그래서 효율적인 소프트웨어 개발에 대해서 같이 의논하고 정보를 공유할 블로그가 있으면 좋겠다는 생각을 하게 되었다.
앞으로 많은 소프트웨어 종사자들과 이론적이 아닌 실전적인 이야기들을 나누길 기대합니다. 

신고

전규현 소프트웨어이야기 소프트웨어, 소프트웨어 개발, 소프트웨어 공학, 컨설턴트, 컨설팅

  1. 점심때 마소 기자분과 '컨설턴트'가 개발자들의 상상속에서가 아니라
    실제로 어떤 일을 하는가에 대해 기사가 만들어지면 좋겠다는 이야기를 했는데...
    음.. 그런 이야기들이 엮어지면 좋을 듯 합니다.

  2. 영회님 반갑습니다.
    국내에 저와 같이 소프트웨어 공학을 통해서 소프트웨어 개발 컨설팅을 하는 사람들은 그렇게 많지 않습니다. 그리고 컨설팅을 하다보면 수많은 에피소드들이 있는데, 그러한 것들도 블로그를 통해서 소개를 하려고 합니다. 마소 기자분이 "컨설턴트"가 하는 일에 대해서 궁금하시고 기사가 될 수 있다면 제 블로그를 한번 소개해주시는 것도 좋겠네요. :)
    감사합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바