태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

Search results for '소프트웨어공학'

아는 것과 실행하는 것

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님 감사합니다.

소프트웨어 개발자를 위한 소통의 장

2010.07.08 14:16 by 전규현


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





그동안 블로그에 글을 쓰면서 여러 개발자분들의 의견을 듣는데 많은 불편함을 느껴왔습니다.
블로그의 글에 댓글을 남기면 약간 소통이 되기는 해도 주로 일방적인 전달을 벗어나지 못했습니다.
그렇게 해서는 많은 의견을 주고 받을 수도 없고, 소프트웨어를 개발하면서 생기는 수많은 문제들을 해결하는데 실질적인 도움을 주기 어려웠었습니다.

그래서, 소통을 좀더 강화하고자 allofsoftware 메일링리스트를 만들었습니다.

메일링리스트가 어떤것인지 다들 잘 알고 계시겠지만 간단히 설명하자면 allofsoftware 메일링리스트에 가입을 하시면 allofsoftware@googlegroups.com으로 보내는 모든 메일을 수신하실 수 있습니다. 거꾸로 내가 allofsoftware@googlegroups.com으로 메일을 보내면 모든 가입자가 메일을 받아 봅니다.

소프트웨어 공학에 대해서 궁금한 것이나 실제로 소프트웨어를 개발하면서 닥치는 문제들을 allofsoftware@googlegroups.com으로 메일을 보내면 모든 가입자들이 내용을 보고 서로 답장을 보내면서 토론을 이어갈 수 있습니다. 이를 통해서 댓글을 통해서만 간단한 질문을 할 수 있는 것을 넘어서 현실적인 문제를 많은 개발자와 즉시 의논할 수 있을 것으로 기대합니다. 저 또한 열심히 답변을 보내도록 하겠습니다.

가입방법은 블로그 오른쪽 사이드바에 아래와 같은 위젯이 있습니다. 여기에 Email주소를 입력하면 됩니다. 간단하죠?





많은 성원 부탁합니다. 

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

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

전규현 소프트웨어이야기 allofsoftware, google groups, mailing list, 소프트웨어공학

  1. 아이폰 개인 개발자입니다.
    구글 그룹 메일에 가입해 봅니다. ^^

  2. 반갑습니다. 민원기님
    언제든지 토론 주제를 던져주세요.

  3. 그룹스 가입했습니다. 많은 소통 이루어지길 희망합니다.

나는 혼자가 아니다.

2009.05.15 23:18 by 전규현


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



지금 내가 생각하고 행동하는 것은 나 스스로의 힘이 아닙니다. 과거의 수많은 대가들이 이룩해 놓은 지식, 경험과 지혜를 간접적으로 배우면서 자라온 내가 있고 그 바탕 위에 내가 존재 합니다.
이런 성현들의 지식이 없다면 지금의 내가 존재 할 수 있을까요? 원시인과 별 차이 없는 내가 있겠죠.

소프트웨어를 개발하다 보면 수많은 문제에 부딪히는데 그 대부분은 이미 과거에 소프트웨어 개발의 대가들이 다 겪은 후에 그 해결책을 다 만들어 좋은 것들입니다. 그렇지 않고 소프트웨어 역사상 처음 발생하는 이슈는 거의 없습니다.

그런데 많은 개발자들의 개발 행태를 보면 마치 최초의 선구자 같이 행동을 합니다. 과거에서 배우지 않고 자신의 지식과 경험 테두리 안에서 별 희안한 방법들을 생각해 냅니다.

피아노를 배우려고 하는데, 모짜르트도 모르고 그냥 혼자 피아노를 연습하는 것 같습니다. 지금의 피아노 연주 기술은 과거의 수많은 음악가들이 없었다면 존재 할 수 없죠. 또 그 기술은 혼자서 인터넷 보고 익힐 수 있는 것이 아니고 스승에게 배우고, 혼자서 또 부지런히 연습을 해야 합니다.

문서를 왜 써야 하는지? 
Peer review를 왜 해야 하는지? 
소스코드를 어떻게 관리해야 하는지? 
빌드는 어떻게 해야 하는지? 
고객이 요구사항을 자주 바꾸는데 어떻게 해야 하는지?
테스트는 어떻게 해야 하는지?
Internationalization은 어떻게 해야 하는지?
버그 관리는 어떻게 해야 하는지?
개발 시간을 어떻게 단축할 수 있는지?

이외에도 수천가지 소프트웨어 개발 이슈들은 이미 과거의 대가들이 다 고민하고 방법들을 제시해 놓은 것들입니다. 하지만 이를 배울 스승이 부족하고, 책만 보고 배우기는 어렵기 때문에 나름대로의 방법들을 사용하고 있습니다. 그래서 결국에는 한계에 부딪히게 됩니다.

이러한 지식들을 총칭해서 소프트웨어 공학이라고 합니다. 과거의 대가들에게서 간접적인 도움을 받으면서 소프트웨어를 효과적으로 제대로 개발을 하려면 소프트웨어 공학에 관심을 가져야 합니다. 책을 보면서 간접 경험을 하고 전문가나 스승을 만날 기회가 있다면 최대한 많이 배우려고 노력하고, 가장 좋은 방법은 그런 대가들이 바글바글한 회사에 취직해서 직접적인 경험을 하는 것이지요. 

이미지출처 : Microsoft Office Online

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

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

  1. 개발자의 자존심이 남이 이미 겪은 문제일것이다라는 걸 생각도 못하게 가끔은 막더군요
    그래도 아주 드문 문제들은 구글신의 힘을 빌어도 안나오니(어쩌면 키워드 문제일지도..)
    이럴때 만큼은 자존심을 발동해도 되려나요 ^^

    그래도 남이 걸은 길을 걷는 것보다는, 자기가 스스로 길을 찾아 가며(비록 남이 길을 만들어 놨더라도) 한걸음씩 성숙하는게 더 좋지 않을까 생각을 해봅니다.

  2. 구차니님 안녕하세요.
    시행착오를 줄이면서 스스로 길을 찾는 것도 좋은 방법이라고 생각합니다. 뭐든지 적절히 조절하는 것이 좋겠지요.

  3. "가장 좋은 방법은 그런 대가들이 바글바글한 회사에 취직해서 직접적인 경험을 하는 것이지요. "
    -> 이 말이 너무 와닿는군요. 서브버전이 scm의 한 종류라는 것도 모르는 9년차 선배가 있는 회사를 다니는 중 입니다...

  4. 두렁청해님 안녕하세요.
    우리나라 대부분의 소프트웨어 회사의 현실이 그러니 크게 실망하지 마세요. 회사가 아니더라도 경험할 곳은 많으니 두렁청해님이 한번 lead 해 보세요.

  5. 수습도 안끝난 신입이라 힘이 하나도 없네요
    말은 좋은거 있으면 같이 배우자~ 좋은 안 내봐라~ 이러면서 막상 자기가 하던 방식 아니면 할려고 안하더군요~
    물론 설명해드렸지요~^^
    서브버전 쓰면서 커밋, 체크아웃, 업데이트 3가지만 잘 사용해도 희망을 가질텐데 서브버전 서버를 ftp처럼 쓸려고 하더군요.ㅠㅠ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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