태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

Search results for 'Domain지식'

  1. 2009/05/22 -- 악순환 vs. 선순환 (2)
  2. 2009/05/18 -- 이 바닥을 못 벗어난다. (5)

악순환 vs. 선순환

2009/05/22 12:24 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed

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

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

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

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

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

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

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

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


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

'소프트웨어이야기' 카테고리의 다른 글

살아남은 개발자들  (4) 2009/07/03
도대체 얼마나 자세히 적어 달라고?!  (4) 2009/06/29
악순환 vs. 선순환  (2) 2009/05/22
이 바닥을 못 벗어난다.  (5) 2009/05/18
나는 혼자가 아니다.  (5) 2009/05/15
이거 팔면 돈 되겠는데!  (20) 2009/04/17

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

Trackback Address: http://allofsoftware.net/trackback/123 관련글 쓰기
  1. 오픈 세미나에 와주셔서 늦은 시간까지 열강해 주신것 너무 감사드립니다. 좋은글을 잘 읽고 갑니다.

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

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

이 바닥을 못 벗어난다.

2009/05/18 23:12 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed
우리나라 소프트웨어 개발자들은 자신이 처음부터 일해온 바닥을 못 벗어나는 경향이 있습니다.

처음에 게임회사에서 일을 시작한 개발자는 계속 게임회사에서 일하고, 금융회사, 보안회사, 장비회사, SI회사 등 쉽게 그 바닥을 못 벗어나곤 합니다. 

이러다 보니 개발자가 이직 시 선택의 폭이 좁아지고, 분야가 조금만 바뀌어도 자신의 Value가 확 줄어드는 현상이 일어나곤 합니다.이런 일이 비일비재하게 일어나는 것을 보면 개발자의 전문성이란 어디에 있는 것인지 궁금하지 않을 수 없습니다.

금융에 대한 전문지식을 많이 가지고 있고, 게임에 대한 많은 지식을 가지고 있는 것을 개발자의 전문성이라고 볼 수도 있습니다. 또 그러한 Domain 지식이 없으면 개발을 할 수 없다고 단정적으로 얘기를 하는 개발자도 많습니다.

소프트웨어 엔지니어가 소프트웨어를 개발하기 위해서는 크게 2가지의 지식이 필요합니다.
그 중 하나는 이미 앞에서 언급한 Domain 지식입니다.
그리고 또 하나는 Software Engineering 지식입니다.

Domain 지식은 개발 분야가 바뀌면 거의 쓸모가 없는 산업 지식이고, Software Engineering 지식은 개발 분야가 바뀌어도 항상 사용되는 지식들입니다.

Domain 지식은 너무 광범위해서 나열을 할 수는 없습니다.
하지만 Software Engineering 지식은 무엇인지 설명할 수 있습니다.

요구분석, 설계, 구현, 테스트, 소스코드 관리, 버그 관리, 프로세스 등 소프트웨어를 개발하기 위한 일련의 지식들입니다.

물론 소프트웨어를 개발하기 위해서는 Domain 지식과 Software Engineering 지식 모두가 필요합니다. 하지만 흔히 접하는 현상을 보면 개발자들이 점점 Domain 지식이 치중하는 경향이 있습니다. Software Engineering에 대한 전문성을 떨어진 상태에서 Domain 지식만 점점 늘어가니 당장 일은 잘하고 있는 것 같아도, 동료나 후배들과 협업이 잘 안되고, 프로젝트 규모가 조금만 커져도 문제가 있고, 이직 시에는 심각한 가치 하락이 발생합니다.

그럼 어떻게 해야 할까요? 소프트웨어를 개발하면서 자연스럽게 얻게 되는 Domain 지식에만 의존해서는 안됩니다. Software Engineering 지식을 꾸준히 발전시켜서 소프트웨어 전문가가 될 수 있도록 해야 합니다. Software Engineering에 능통한 소프트웨어 전문가가 된다면, 어느 소프트웨어 회사를 가더라도, 여전히 전문가로서 높은 가치를 가지고 개발을 할 수 있습니다. 새로운 분야로 이직을 하더라도 Domain 지식은 일을 하는 과정에서 차츰 배워 나갈 수 있습니다. 

그리고 Domain 지식에 능통한 개발자에게만 의존해서 개발이 진행되는 소프트웨어 회사는 매우 큰 리스크를 안고 있는 겁니다. 그런 개발자가 한 명만 퇴사를 해도 회사는 큰 위험에 봉착합니다.  

결국, 회사를 위해서도, 개발자들을 위해서도 개발 개발자들의 머리 속에 들어 있는 Domain지식에 의존하기보다는 적절한 개발 프로세스 및 시스템을 기반으로 개발을 해야 합니다.

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

'소프트웨어이야기' 카테고리의 다른 글

도대체 얼마나 자세히 적어 달라고?!  (4) 2009/06/29
악순환 vs. 선순환  (2) 2009/05/22
이 바닥을 못 벗어난다.  (5) 2009/05/18
나는 혼자가 아니다.  (5) 2009/05/15
이거 팔면 돈 되겠는데!  (20) 2009/04/17
외주를 주면 된다고요?  (6) 2009/03/30

전규현 소프트웨어이야기 Domain지식, 소프트웨어전문가, 이직

Trackback Address: http://allofsoftware.net/trackback/122 관련글 쓰기
  1. Blog Icon

    비밀댓글입니다

  2. Blog Icon
    한세희

    절대 공감합니다. 저희회사에서 오래 다니신분들만봐도 이글에 속하는 개발자들이 수두룩한듯합니다.ㅠㅠ

  3. 한세희님 안녕하세요.
    그럴 수밖에 없는 환경도 많이 있는 것 같습니다.

  4. Blog Icon
    grayger

    회사 경영진은 도메인 지식이 쌓인 인력은 대체하기 어려운 인력, Software engineering 에 능통한 인력은 대체하기 쉬운 인력이라고 판단합니다. 도메인 지식이 풍부한 자가 설계를 하고, 개발은 외주를 주는 경향이 있죠. 특정 도메인에 전문화된 기술을 가진 회사일수록 도메인 지식이 부족하나 개발은 잘하는 사람을 핵심 인재라고 생각하지 않습니다.

  5. grayger님 안녕하세요.
    그래서 악순환의 고리가 계속되고 원인은 총체적인 문제입니다. 관련된 글을 더 올릴 계획입니다.

관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..