아는 것과 실행하는 것
2011/03/06 20:30 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
"아는데 지금은 바빠서 못한다."라고 하는 말을 종종 듣는다.
RSS Feed
"개발을 체계적으로 해야 하는데 지금은 그럴 여유가 없다."
"소프트웨어 개발을 할 때 문서를 제대로 써야 하는 것을 알고 쓸 줄도 아는데 시간이 없어서 그렇게 할 수 없다."
"Peer review를 해야 하는데 그럴 시간이 없다."
"시간이 걸리더라도 신입 개발자들에게 시켜야 하는 일이지만 너무 급해서 내가 직접 한다."
가만히 얘기를 들어보면 시간만 있으면 뭐든지 다 할 수 있을 것 같이 얘기를 한다. 그리고 또한 다 할 줄 안다고 한다.
이런 얘기를 하는 사람들의 대부분은 해본적도 없고 할 줄도 모른다는 것이다. 또한 시간이 아무리 많이 있어도 그렇게 하고 싶은 생각은 없을 것이다.
이런 것이 필요하다는 것을 알고 있다면 이미 시행하고 있을 것이다. 시간이 없어서 소프트웨어 공학을 적용하지 못한다는 것은 핑계이거나 소프트웨어 공학이 무엇인지 전혀 모르고 있는 것이다.
문제는 이런 사람들이 분위기를 흐린다는 것이다. 소프트웨어 공학이 마치 필요는 하지만 지금은 아닌 것 같은 착각을 하게 된다. 소프트웨어 공학은 1명이 개발하더라도 필요하고 10,000명이 개발하더라도 필요한 것이다. 목적은 단 한가지, "일정과 비용"을 줄이기 위한 것이다.
시간이 없어서 그렇게 못하고 있다면 소프트웨어 공학이 뭔지 잘 모르고 시행하는 방법을 모르고 있었던 것 뿐이다.
맨날 건강을 위해서 운동을 해야 하는데 지금은 바빠서 운동을 못하고 있다고 얘기하는 것과 똑같다. 이런 사람은 시간이 남아 돌아도 운동을 하지 않는다. 운동이 재미 있어야 하는 것이다.
소프트웨어 공학을 적용하여 개발을 하면 더 재미 있어진다. 경영자 입장에서는 비용이 줄어든다. 그렇지 않다고 생각하고 있는 사람이 있다면, 또는 알고는 있는데 지금은 바빠서 못한다고 생각하는 사람이 있다면, 소프트웨어 공학이 무엇인지 잘못 알고 있는 것이 아닌가 다시 한번 생각해보는 것이 좋다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
'소프트웨어이야기' 카테고리의 다른 글
| 개발자는 회사의 부품일까 두뇌일까? (10) | 2011/06/06 |
|---|---|
| 경영자가 개발자의 거짓말에 현혹되지 않는 법 (15) | 2011/03/30 |
| 아는 것과 실행하는 것 (17) | 2011/03/06 |
| 작은 회사에서 희망을 보다. (16) | 2011/03/01 |
| 어제 일도 기억하지 못하는데... (6) | 2011/02/13 |
| A/B는 뭘까? (9) | 2011/02/06 |
Trackback Address: http://allofsoftware.net/trackback/217
확실히 시간은 만드는 만큼 생기는것 같아요 ㅎ
시간이 없어서.. 라는 건 핑계이긴 하죠
후우... 언넝 운동할 시간을 만들어야 겠어요. 겨울이라서 안하고 퇴근이 늦어서 안하다 보니 벌써 겨울이 지나겠네요 ^^;
안녕하세요. 구차니님
운동을 재미있게 하는 방법을 찾으셔야 할텐데요. ^^ 운동하다가 다쳐서 더 고생하는 사람도 많이 목격했습니다.
매우 동감합니다. 점심시간에라도 운동하고, 혼자라도 유닛테스트를 집어넣어보고 있습니다.
안녕하세요. zelon님
혼자서 하기는 어려운 일이군요. 전사적으로 움직여야 할텐데요. 고생하고 계십니다.
'시간이 없어서' 라고 생각하는 순간부터 잘못된거 같아요.
말씀하신대로 시간이 있어도 예전대로 계속 되거든요~
안녕하세요. 작은아이님
마음먹기에 달린 것 같습니다.
글만 보면 "소프트웨어 공학"이 꼭 만병통치약 같군요.
글 중에서,
> 목적은 단 한가지, "일정과 비용"을 줄이기 위한 것이다.
그리고 뒤에
> 소프트웨어 공학을 적용하여 개발을 하면 더 재미 있어진다
일정과 비용을 줄이면서 재미 없는 방법이 수천 가지는 있습니다.
개발20년차님 안녕하세요.
저도 말씀하신 것과 같은 일정과 비용을 줄이면서 재미없게 일하는 방법을 많이 알고 있습니다. 하지만 이 방법들은 장기적으로 일정과 비용이 더 늘어납니다.
"조삼모사"와 같습니다. 당장 급하다고 코딩 먼저해서 일단 구현해 놓으면 테스트가 오래 걸리거나 나중에 유지보수에 더 많은 비용이 들고 후배들이 거지같은 코드 맡아서 불행해집니다.
글에서도 언급했듯이 소프트웨어 공학을 다르게 이해하고 있다면 이런 답이 나올 수 있습니다.
많은 분들이 그동안 소프트웨어 공학이랍시고 더 비효율적인 것을 많이 봐 왔습니다. 유독 인도와 우리나라에서만 소프트웨어 공학이 판을 치는데 그 때문에 소프트웨어 공학에 대한 오해가 팽배합니다.
소프트웨어 공학은 만병통치약도 아니고 교과서도 아니고 경험에 의해서 잘 개발할 수 있는 방법, 바로 그겁니다.
재미없는 방법만 찾지말고 재미있는 방법을 같이 찾아보는 것은 어떨까요?
소프트웨어 공학을 꼭 도입해야만 제대로 된 소프트웨어를 만드는 것은 아니겠지요. 그리고 제대로 된 소프트웨어만이 성공한다는 보장도 없고요. 그래서 전 이렇게 비유를 합니다. 축구에서 포지션도 없고 전술도 없어도 골은 넣을 수 있습니다. 멋있게 넣어도 한골이고 문전앞에서 밀어 넣어도 한골이죠. 하지만 선수 특징에 맞는 포지션과 잘 훈련된 전술을 구사를 하면 멋있는 골을 넣을 수 있는 가능성이 높아지겠죠.
위에 하신 말씀은 맞습니다. 시간은 만드는 것이 아니라 할당하는 것이라는 말이 있습니다. 시간이 없어서 지금은 못한다고 하면 시간이 많으면 다른 할일이 또 생겨서 못한다고 할겁니다.
Jake님 안녕하세요.
Jake님이 소프트웨어 공학을 제대로 알고 계시네요.
그게 바로 소프트웨어 공학입니다. 제대로 개발하고 있는 회사에 가면 우리는 소프트웨어 공학을 도입해서 제대로 개발한다고 하지 않습니다. 경험에 의해서 몸에 묻어 있어서 자연스럽게 하는 행동들이지 그걸 소프트웨어 공학이라고 스스로 말하지 않습니다.
회사가 커지면 이를 조금 체계화해서 전 직원이 따라 할 수 있게 할 정도입니다.
하지만 그렇지 않는 회사가 많기에 그런 방법들을 모아 놓다보니 이름도 필요하고 이를 소프트웨어 공학이라고 부릅니다. 따라서 회사마다 방법도 다르고 적용을 다르게 해야 합니다. 이렇게 모아 놓은 것은 Super set인데 이것을 다 해야 하는 것으로 착각하는 경우도 있습니다. 이를 다 따라하라고 하지도 않았는데 이를 다 따라하면 소프트웨어 하나 개발하는데 100년은 걸릴 겁니다.
그런데도 이것을 이용해서 복잡하게 만들어서 그럴듯하게 보여서 장사하는 사람들이 많습니다. 이들을 이론파라고 부릅니다. 하지만 실전파들은 이런 이론은 중요하게 생각하지 않습니다. 어차피 옛날부터 해오던 것을 더 복잡하게 만들어 놓은 것이 많거든요. 오히려 이런 이론이 더 방해가 되므로 이론은 치워버리라고 하고 실전에서 쓰는 방법을 중요시합니다.
이런 이론 상관없이 개발을 잘하고 계신분들은 모두 실전파라고 할 수 있습니다. 이런 분들은 이론을 봐도 오해를 하지 않고 우리에게 필요한 것을 딱 찝어서 도입하곤 합니다.
멋져 보이는 방법 하나 가져다 놓고 따라하라는 것은 절대로 아닙니다.
이러다 보니 잘하고 있는지 못하고 있는지 판단이 어려운데 (특히 우리나라에서) 그래서 무엇이 문제인지 잘못하고 있는지 분석이 중요합니다.
제 경험한 우리나라의 SW 회사 중에서 소프트웨어 공학을 제대로 이해하고 활용하고 있는 회사는 5%도 안됩니다.
그래서 잘하고 있는 회사들은 그냥 당연히 하고 있는 것들도 좀 체계적으로 정리를 해서 홍보할 필요가 있습니다. 그런 맥락이라고 보면 될 것 같습니다.
"당연한 것"을 안하고 있는 것들을 나열하기 시작하면 깜짝 놀라실걸요? 그 원인도 다 경험이 없고 선배들이 해오던 방법을 계속 답습하고 있기 때문이랍니다.
답글 중 "유독 인도와 우리나라에서 소프트웨어 공학이 판을 친다" 를 보니 한가지 생각 나는게 있네요. 개인적으로 두 나라의 공통점이 하나 있다고 생각합니다. 현실에는 큰 영향이 없는 공허한 이론을 갖고 토론하길 좋아한다는 것이죠.
소프트웨어 공학은 아무것도 모르는 조직에서 초기에 이런 이런 것들이 있다는 카탈로그 만으로 적당할 것 같습니다. 그 카탈로그를 이해하고나서 자신의 조직의 문화, 인력, 사업영역, 현재상황등등을 고려해서 가장 적합한 프로세스를 찾아 내는 것이 중요하다고 봅니다.
이건 개발자한테 책임을 물을 문제가 아니라 생각합니다.
제가 경력이 대단한건 아닙니다만 나름 중소기업에서는 어느정도 수익을 창출한 회사라도 경영진들이 개발자들의 투자시간을 '남는시간'으로 판단하는 경우가 많습니다.
납득할만한 보고서를 계속 올려도 말이죠..
개발자가 아무리 날고 겨봐야 일정 어처구니 없이 고정시켜 버리면 정말 '시간이 없다' 라는 말 외에 할 도리가 없습니다.
이건 어디까지나 경영자의 마인드가 조금이라도 변화해야 가능한 일 같습니다.
black_H님 안녕하세요.
동감합니다. 변화에 대한 책임의 90%는 경영자에게 있습니다. 개발자들은 그 필요성을 느껴도 단기적인 이익에 급급하고 개발자를 믿지 않는 경영자는 바뀌지 않습니다.
이러면 개발자는 항상 바쁘고 야근을 거듭해도 나아지지 않는 환경에서 일할 수 밖에 없습니다.
그래서 제 글 중에는 상당수가 경영자가 읽었으면 하는 글들입니다.
black_H님의 말씀은 맞습니다.
개발자의 책임은 아닙니다.
하지만 경영자가 변화하지 않아도 개발자들의 의지가 있다면 지금 당장은 변화하지 않겠지만 언젠가 그 변화가 있을꺼라는 희망을 가져야 한다고 봅니다.
물론 대부분의 개발자들이 그에 동의해야하고 동참해야하지만 그 변화를 이룩해낼 수 있다고 생각합니다.
실제 저희 회사의 경우 변화가 일어나고 있고 빠르지는 않지만 주변 팀들에게도 그 변화가 전달되고 있습니다.
경영자의 경영 마인드도 중요하지만 그에 못지 않게 중요한건 회사의 모든 구성원들의 마인드라고 생각합니다.
풀그리미님 안녕하세요.
직원들이 경영자를 움질일 수 있으면 아주 Happy한 경우입니다. 이미 큰 강점을 가지고 있다고 볼수 있겠네요. 이런 회사는 아주 잘 될 것 같습니다.
많은 회사들이 이렇게 되기 어렵긴 합니다.
좋은 글 잘 보고 갑니다 :-)
ozlael님 감사합니다.