태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

아는 것과 실행하는 것

2011.03.06 20:30 by 전규현


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





"아는데 지금은 바빠서 못한다."라고 하는 말을 종종 듣는다.

"개발을 체계적으로 해야 하는데 지금은 그럴 여유가 없다."

"소프트웨어 개발을 할 때 문서를 제대로 써야 하는 것을 알고 쓸 줄도 아는데 시간이 없어서 그렇게 할 수 없다."

"Peer review를 해야 하는데 그럴 시간이 없다."

"시간이 걸리더라도 신입 개발자들에게 시켜야 하는 일이지만 너무 급해서 내가 직접 한다."

가만히 얘기를 들어보면 시간만 있으면 뭐든지 다 할 수 있을 것 같이 얘기를 한다. 그리고 또한 다 할 줄 안다고 한다.

이런 얘기를 하는 사람들의 대부분은 해본적도 없고 할 줄도 모른다는 것이다. 또한 시간이 아무리 많이 있어도 그렇게 하고 싶은 생각은 없을 것이다.

이런 것이 필요하다는 것을 알고 있다면 이미 시행하고 있을 것이다. 시간이 없어서 소프트웨어 공학을 적용하지 못한다는 것은 핑계이거나 소프트웨어 공학이 무엇인지 전혀 모르고 있는 것이다.

문제는 이런 사람들이 분위기를 흐린다는 것이다. 소프트웨어 공학이 마치 필요는 하지만 지금은 아닌 것 같은 착각을 하게 된다. 소프트웨어 공학은 1명이 개발하더라도 필요하고 10,000명이 개발하더라도 필요한 것이다. 목적은 단 한가지, "일정과 비용"을 줄이기 위한 것이다. 

시간이 없어서 그렇게 못하고 있다면 소프트웨어 공학이 뭔지 잘 모르고 시행하는 방법을 모르고 있었던 것 뿐이다.

맨날 건강을 위해서 운동을 해야 하는데 지금은 바빠서 운동을 못하고 있다고 얘기하는 것과 똑같다. 이런 사람은 시간이 남아 돌아도 운동을 하지 않는다. 운동이 재미 있어야 하는 것이다. 

소프트웨어 공학을 적용하여 개발을 하면 더 재미 있어진다. 경영자 입장에서는 비용이 줄어든다. 그렇지 않다고 생각하고 있는 사람이 있다면, 또는 알고는 있는데 지금은 바빠서 못한다고 생각하는 사람이 있다면, 소프트웨어 공학이 무엇인지 잘못 알고 있는 것이 아닌가 다시 한번 생각해보는 것이 좋다.

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

전규현 소프트웨어이야기 ,

  1. 확실히 시간은 만드는 만큼 생기는것 같아요 ㅎ
    시간이 없어서.. 라는 건 핑계이긴 하죠

    후우... 언넝 운동할 시간을 만들어야 겠어요. 겨울이라서 안하고 퇴근이 늦어서 안하다 보니 벌써 겨울이 지나겠네요 ^^;

  2. 안녕하세요. 구차니님
    운동을 재미있게 하는 방법을 찾으셔야 할텐데요. ^^ 운동하다가 다쳐서 더 고생하는 사람도 많이 목격했습니다.

  3. 매우 동감합니다. 점심시간에라도 운동하고, 혼자라도 유닛테스트를 집어넣어보고 있습니다. :)

  4. 안녕하세요. zelon님
    혼자서 하기는 어려운 일이군요. 전사적으로 움직여야 할텐데요. 고생하고 계십니다.

  5. '시간이 없어서' 라고 생각하는 순간부터 잘못된거 같아요.
    말씀하신대로 시간이 있어도 예전대로 계속 되거든요~

  6. 안녕하세요. 작은아이님
    마음먹기에 달린 것 같습니다.

  7. Blog Icon
    개발20년차

    글만 보면 "소프트웨어 공학"이 꼭 만병통치약 같군요.

    글 중에서,

    > 목적은 단 한가지, "일정과 비용"을 줄이기 위한 것이다.

    그리고 뒤에

    > 소프트웨어 공학을 적용하여 개발을 하면 더 재미 있어진다

    일정과 비용을 줄이면서 재미 없는 방법이 수천 가지는 있습니다.

  8. 개발20년차님 안녕하세요.

    저도 말씀하신 것과 같은 일정과 비용을 줄이면서 재미없게 일하는 방법을 많이 알고 있습니다. 하지만 이 방법들은 장기적으로 일정과 비용이 더 늘어납니다.

    "조삼모사"와 같습니다. 당장 급하다고 코딩 먼저해서 일단 구현해 놓으면 테스트가 오래 걸리거나 나중에 유지보수에 더 많은 비용이 들고 후배들이 거지같은 코드 맡아서 불행해집니다.

    글에서도 언급했듯이 소프트웨어 공학을 다르게 이해하고 있다면 이런 답이 나올 수 있습니다.

    많은 분들이 그동안 소프트웨어 공학이랍시고 더 비효율적인 것을 많이 봐 왔습니다. 유독 인도와 우리나라에서만 소프트웨어 공학이 판을 치는데 그 때문에 소프트웨어 공학에 대한 오해가 팽배합니다.

    소프트웨어 공학은 만병통치약도 아니고 교과서도 아니고 경험에 의해서 잘 개발할 수 있는 방법, 바로 그겁니다.

    재미없는 방법만 찾지말고 재미있는 방법을 같이 찾아보는 것은 어떨까요?

  9. Blog Icon
    Jake

    소프트웨어 공학을 꼭 도입해야만 제대로 된 소프트웨어를 만드는 것은 아니겠지요. 그리고 제대로 된 소프트웨어만이 성공한다는 보장도 없고요. 그래서 전 이렇게 비유를 합니다. 축구에서 포지션도 없고 전술도 없어도 골은 넣을 수 있습니다. 멋있게 넣어도 한골이고 문전앞에서 밀어 넣어도 한골이죠. 하지만 선수 특징에 맞는 포지션과 잘 훈련된 전술을 구사를 하면 멋있는 골을 넣을 수 있는 가능성이 높아지겠죠.

    위에 하신 말씀은 맞습니다. 시간은 만드는 것이 아니라 할당하는 것이라는 말이 있습니다. 시간이 없어서 지금은 못한다고 하면 시간이 많으면 다른 할일이 또 생겨서 못한다고 할겁니다.

  10. Jake님 안녕하세요.

    Jake님이 소프트웨어 공학을 제대로 알고 계시네요.

    그게 바로 소프트웨어 공학입니다. 제대로 개발하고 있는 회사에 가면 우리는 소프트웨어 공학을 도입해서 제대로 개발한다고 하지 않습니다. 경험에 의해서 몸에 묻어 있어서 자연스럽게 하는 행동들이지 그걸 소프트웨어 공학이라고 스스로 말하지 않습니다.

    회사가 커지면 이를 조금 체계화해서 전 직원이 따라 할 수 있게 할 정도입니다.

    하지만 그렇지 않는 회사가 많기에 그런 방법들을 모아 놓다보니 이름도 필요하고 이를 소프트웨어 공학이라고 부릅니다. 따라서 회사마다 방법도 다르고 적용을 다르게 해야 합니다. 이렇게 모아 놓은 것은 Super set인데 이것을 다 해야 하는 것으로 착각하는 경우도 있습니다. 이를 다 따라하라고 하지도 않았는데 이를 다 따라하면 소프트웨어 하나 개발하는데 100년은 걸릴 겁니다.

    그런데도 이것을 이용해서 복잡하게 만들어서 그럴듯하게 보여서 장사하는 사람들이 많습니다. 이들을 이론파라고 부릅니다. 하지만 실전파들은 이런 이론은 중요하게 생각하지 않습니다. 어차피 옛날부터 해오던 것을 더 복잡하게 만들어 놓은 것이 많거든요. 오히려 이런 이론이 더 방해가 되므로 이론은 치워버리라고 하고 실전에서 쓰는 방법을 중요시합니다.

    이런 이론 상관없이 개발을 잘하고 계신분들은 모두 실전파라고 할 수 있습니다. 이런 분들은 이론을 봐도 오해를 하지 않고 우리에게 필요한 것을 딱 찝어서 도입하곤 합니다.

    멋져 보이는 방법 하나 가져다 놓고 따라하라는 것은 절대로 아닙니다.

    이러다 보니 잘하고 있는지 못하고 있는지 판단이 어려운데 (특히 우리나라에서) 그래서 무엇이 문제인지 잘못하고 있는지 분석이 중요합니다.

    제 경험한 우리나라의 SW 회사 중에서 소프트웨어 공학을 제대로 이해하고 활용하고 있는 회사는 5%도 안됩니다.

    그래서 잘하고 있는 회사들은 그냥 당연히 하고 있는 것들도 좀 체계적으로 정리를 해서 홍보할 필요가 있습니다. 그런 맥락이라고 보면 될 것 같습니다.

    "당연한 것"을 안하고 있는 것들을 나열하기 시작하면 깜짝 놀라실걸요? 그 원인도 다 경험이 없고 선배들이 해오던 방법을 계속 답습하고 있기 때문이랍니다.

  11. Blog Icon
    Jake

    답글 중 "유독 인도와 우리나라에서 소프트웨어 공학이 판을 친다" 를 보니 한가지 생각 나는게 있네요. 개인적으로 두 나라의 공통점이 하나 있다고 생각합니다. 현실에는 큰 영향이 없는 공허한 이론을 갖고 토론하길 좋아한다는 것이죠.

    소프트웨어 공학은 아무것도 모르는 조직에서 초기에 이런 이런 것들이 있다는 카탈로그 만으로 적당할 것 같습니다. 그 카탈로그를 이해하고나서 자신의 조직의 문화, 인력, 사업영역, 현재상황등등을 고려해서 가장 적합한 프로세스를 찾아 내는 것이 중요하다고 봅니다.

  12. 이건 개발자한테 책임을 물을 문제가 아니라 생각합니다.
    제가 경력이 대단한건 아닙니다만 나름 중소기업에서는 어느정도 수익을 창출한 회사라도 경영진들이 개발자들의 투자시간을 '남는시간'으로 판단하는 경우가 많습니다.
    납득할만한 보고서를 계속 올려도 말이죠..
    개발자가 아무리 날고 겨봐야 일정 어처구니 없이 고정시켜 버리면 정말 '시간이 없다' 라는 말 외에 할 도리가 없습니다.
    이건 어디까지나 경영자의 마인드가 조금이라도 변화해야 가능한 일 같습니다.

  13. black_H님 안녕하세요.

    동감합니다. 변화에 대한 책임의 90%는 경영자에게 있습니다. 개발자들은 그 필요성을 느껴도 단기적인 이익에 급급하고 개발자를 믿지 않는 경영자는 바뀌지 않습니다.
    이러면 개발자는 항상 바쁘고 야근을 거듭해도 나아지지 않는 환경에서 일할 수 밖에 없습니다.
    그래서 제 글 중에는 상당수가 경영자가 읽었으면 하는 글들입니다.

  14. Blog Icon
    풀그리미

    black_H님의 말씀은 맞습니다.
    개발자의 책임은 아닙니다.
    하지만 경영자가 변화하지 않아도 개발자들의 의지가 있다면 지금 당장은 변화하지 않겠지만 언젠가 그 변화가 있을꺼라는 희망을 가져야 한다고 봅니다.
    물론 대부분의 개발자들이 그에 동의해야하고 동참해야하지만 그 변화를 이룩해낼 수 있다고 생각합니다.
    실제 저희 회사의 경우 변화가 일어나고 있고 빠르지는 않지만 주변 팀들에게도 그 변화가 전달되고 있습니다.

    경영자의 경영 마인드도 중요하지만 그에 못지 않게 중요한건 회사의 모든 구성원들의 마인드라고 생각합니다.

  15. 풀그리미님 안녕하세요.
    직원들이 경영자를 움질일 수 있으면 아주 Happy한 경우입니다. 이미 큰 강점을 가지고 있다고 볼수 있겠네요. 이런 회사는 아주 잘 될 것 같습니다.
    많은 회사들이 이렇게 되기 어렵긴 합니다.

  16. 좋은 글 잘 보고 갑니다 :-)

  17. ozlael님 감사합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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