태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

문서가 없으면

2011.03.13 20:57 by 전규현


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





작은 프로젝트인 경우 문서를 거의 만들지 않고 개발을 하면 더 효율적이라고 생각할 수도 있다.
가끔은 그렇게 생각할 수도 있다. 너무 시간이 없다는 핑계를 대기도 한다.

하지만 이렇게 해서 모든 프로젝트에 문서가 거의 없으면 개선을 하려고 하는 회사에서 도움을 요청해도 막상 도와주기가 매우 어렵다.

문서가 거의 없어서 모든 것을 물어보면서 파악을 해야 한다. 있는 것이라고는 거의 쓸모 없는 문서와 소스코드인데 소스코드는 회사와 제품을 파악하는데 별 도움이 안된다.

문서가 제대로 있다면 80%는 문서를 보고 20%만 물어 보면 된다.

이때 개발을 하고 나서 나중에 만드는 문서는 그 효율성이 반으로 줄어든다.
나중에 만드므로 일단 충실도가 떨어지고 개발하기 전에 만들때 고려해야 할 요소들은 프로젝트가 이미 끝났기 때문에 다 생략된다. 사실 제대로 적기도 어렵다.
이런 문서라도 없는 것보다 낫기는 하지만 프로젝트만을 위한 것이라면 이런 문서는 별로 필요도 없다. 유지보수를 위해서라면 차라리 코드를 보는 것이 낫다. 들어간 시간에 비해서 효과가 별로 없다는 뜻이다.

이는 신입사원이 입사를 했을 때에도 똑같다. 개발팀에 합류하여 제대로 개발을 시작하려면 프로젝트를 파악해야 하는데 문서가 없으면 파악하기가 너무 어렵다.

선배들이 말로써 하나씩 설명을 해줘야 하는데 다들 바빠서 그렇게 할 수가 없다. "멘토" 또는 "사수"를 정해서 알려주라고 하는데 어디 사수들이 그렇게 한가한가?

그러다 보니 신입 개발자들은 제 능력을 발휘하려면 너무 오랜 시간이 걸린다. 거의 자수성가 식으로 소스코드를 보고 분석해서 하나씩 시행착오를 거쳐서 배워야 한다. 이 과정에서 버그도 많이 양산해내게 된다. 

몇 년이 지난 후에 이제 좀 개발을 할만하면 또 후배가 들어온다. 해 온 방식이 이 방식이라 후배들에게 똑같이 전수를 하게 된다.

즉 "악순환"인 것이다.

프로젝트를 진행하면서 프로젝트 기간을 단축하기 위해서 당연히 만드는 문서들은 다른 개발자들이 도와주기 쉽게 만든다. 

무슨 문서를 얼마나 자세히 만들어야 하는지는 프로젝트마다 다르다. 하지만 내가 경험한 수많은 프로젝트들은 문서가 그렇게 많이 필요하지 않았다. 설계문서까지도 필요 없는 경우도 매우 많다. 어떤 문서를 어떻게 적는 것이 가장 효율적인지는 경험에서 나온다. 경험없는 개발자들이 문서를 아예 적지 않거나 너무 많이 적는다.

너무 많이 적을 바에는 아예 문서를 적지 않는 것이 나은 경우도 많다.

문서는 딱 필요한 만큼만 적어야 한다.

그래야 다른 사람이 도와줄 수 있고 나는 더 가치 있는 일을 할 수 있다.

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

전규현 프로젝트 문서

  1. 확실히 살아있는 문서를 관리하는게 상당히 힘든걸 또 다시 깨닫고 있게 됩니다.
    그런 이유에서 doxygen과 같이 소스코드를 문서화에 포함하는 게 아닐까 싶기도 하구요 ^^

  2. 구차니님 안녕하세요.
    그래서 문서는 가능하면 적게 꼭 필요한 만큼만 만들어야 합니다.
    설계서의 일부를 Doxygen으로 대신 하는 것은 매우 좋은 방법입니다.

문서화 딜레마

2010.11.11 17:22 by 전규현


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






우리나라 소프트웨어 회사 중에서 문서를 제대로 작성하고 있는 곳을 찾기란 그리 쉬운 일이 아닙니다.

제대로 작성한다는 의미는 꼭 필요한 만큼 적절히 효과적으로 작성하는 것입니다.

대부분의 소프트웨어 회사는 변변한 문서 하나 없이 개발을 하고 있고 반대로 소수의 회사는 불필요한 문서를 잔뜩 만들어서 오히려 효율성을 떨어뜨리고 있습니다.

물론 제대로 하고 있는 회사도 있지만 그 수는 극히 적습니다.

대부분의 여러분들도 겪은 현상이거나 앞으로 겪을 것입니다. 변변한 문서하나 제대로 만들지 않고 소프트웨어를 개발하고 있는 회사는 구멍가게 이상의 규모로 성장하기 어렵습니다. 회사의 규모가 커지면서 문서가 부족하면 커뮤니케이션 비용이 기하급수로 증가하기 시작합니다. 회사가 작았을 때 숨어있던 문제들이 마구 터져 나오기 시작합니다.

이미 문제가 되기 시작한 이후에 문서를 만들어보자는 결심을 하기도 합니다. 하지만 이미 제품을 다 개발한 이후에 유지보수하는 제품의 문서를 제대로 만드는 것은 거의 불가능합니다.

문서의 주목적은 소프트웨어를 제대로 개발하기 위한 것이지 유지보수를 위한 것이 아닙니다. 유지보수 단계에서 문서를 만들면 문서에 많은 내용이 빠지게 되고 의욕도 떨어지게 됩니다.

하지만 문제는 또 다른 곳에 있습니다. 그동안 제대로 문서를 만들지 않고 개발을 해온 개발자들이 문서를 만들자고 결심만 했다고 해서 문서를 작성하는 실력이 갑자기 생기지는 않습니다.

즉, 문서를 만드는 실력이 부족하다는 겁니다.

본인들은 문서를 잘 작성할 줄 아는데 바빠서 만들지 못한다고 합니다. 그래서 시간만 있다면 문서를 언제든지 만들 수 있다고 합니다. 이렇게 말하는 것자체가 문서를 제대로 만들어 본적도 없고 문서를 만들지도 모른다는 반증입니다. 왜냐하면 바쁠 수록 문서를 적절히 잘 만들어야 프로젝트 시간이 단축되기 때문입니다.

그러다보니 제대로 된 문서도 없이 유지보수가 뒤죽박죽이 되어서 항상 고참 개발자들이 유지보수에 매달려야 해서 계속 바쁘게 되고 그러다보니 문서를 제대로 만드는 실력을 향상할 기회는 또 없게 됩니다. 새로운 프로젝트를 시작해도 또 과거의 방식으로 문서도 제대로 없이 개발을 하게 됩니다.

개발자들이 코딩을 잘하는 이유는 수년에 결쳐서 코딩을 계속 해 왔기 때문입니다. 철저히 훈련이 잘 되어 있습니다. 다들 실력차이는 나지만 코딩을 못하는 개발자는 개발자도 아니죠. 

그렇듯 문서도 계속 작성을 해봐야 잘하게 됩니다. 처음부터 기가막히게 멋진 문서를 만들 필요는 없습니다. 항상 기록을 남기는 습관을 들이는 것도 문서를 잘 작성하는 실력을 키우는데 좋은 도움이 됩니다.

물론 프로젝트에서 필요한 문서는 단순히 글을 잘 작성한다고 되는 것도 아닙니다. 하지만 글을 쓰는 습관이 출발점입니다.  그리고 프로젝트에서 필요한 문서는 원래 선배들이 제대로 작성을 해 왔다면 문서를 리뷰할 때 참석해서 문서 작성 방법을 배울 수 있습니다. 하지만 안타깝게도 선배에서 문서 작성법을 배울 수 있는 회사는 우리나라에 그렇게 많지 않습니다. 대부분은 스스로 해 나가야 합니다. 이에 관련된 책들의 도움을 받는 것도 방법 중 하나 입니다.

명심할 것은 욕심을 부리지 않는 것입니다. 너무 많은 내용을 완벽하게 적으려고 하면 오히려 금방 질려서 포기하게 됩니다. 또한 바쁘니까 나중에 몰아서 만든다는 생각도 버려야 합니다. 문서는 지금 이순간이 아니면 만들 수 없습니다.  지금 필요한 만큼만 적당히 적게 만들어야 합니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by Damon Duncan
저작자 표시 비영리 변경 금지
신고

전규현 개발문화 문서, 문화

  1. 문서화 정말 어렵더라구요. 4년차만에 처음으로 개발하기 전에 설계하면서 문서부터 만들고 있는 중인데, 이 정도밖에 안됐나 하는 자괴감이 들더라구요. 갑자기 또 속상해지네. 크크크. 10년차 되서 스펙때문에 또 좌절하면 어쩌죠. 스펙까지 익숙해지려면 보통 몇년 걸리나요? 빌 조이같은 천재들 말고요.

  2. 안녕하세요. 김재호님
    스펙은 가장 작성하기 어려운 문서입니다.
    요구사항 분석 능력이 있어야 하고, Domain도 잘 알아야 하고, 문서도 잘 작성해야 합니다.
    제대로 적는데는 기본적으로 3~4년은 걸리고 10년이 지나고 20년이 지나도 꾸준히 실력이 증가하는 소프트웨어를 개발하는데 있어서 가장 어려운 분야입니다.
    빌조이 같은 천재라고 해도 결코 처음부터 스펙을 잘 적을 수는 없습니다.
    문제는 스펙을 적는 방법을 배우기가 어려운 거죠.

  3. Blog Icon
    godway

    이에 관련된 책들의 도움을 받아야 한다고 하셨는데 혹시 좋은 책을 추천해 주시는 것은 가능하신지요?

  4. 안녕하세요. godway님
    우리나라 책중에서는 제가 쓴 "소프트웨어 개발의 모든 것"을 추천합니다. 그리고 외국책 중에서는 Requirement Engineering으로 검색을 해보시는 것이 좋겠습니다.
    책을 보는 것은 도움이 되기는 하지만 책만 보고 제대로 작성하는데는 매우 오랜 시간이 걸립니다.

  5. 소프트웨어 개발의 모든 것, CodeCraft, 조엘온 소프트웨어 등등을 읽으면서,

    "스펙 문서 만드세요."

    라는 말을 볼 때마다, 그렇지요 옳은 말씀이지요 하면서 읽었습니다.

    실제로 실천하려 하니 참으로 어렵다는 생각을 많이 해 봤습니다.



    문서를 여러개를 짧게 만들어야 하는지, 길게 하나로 만들어야 하는지...

    여기에는 이것이 들어가도 되지만, 저기에는 이것이 들어가면 안되는지...

    이것들 고민하는 것이 일이고 실력이라는 생각 역시 들었습니다.


    하지만 전에 한 번 분석 설계 구현의 순서로 만들기를 실험해 봤을 때,

    시간이 확실히 줄어들었던 기억이 있어서

    이젠 꼭 지키려고 노력합니다.


    정말

    "건강하게 살려면, 나쁜 것들 드시지 마시고, 운동 열심히 하세요"만큼이나 어려운 일이 문서화인듯 합니다.

  6. 안녕하세요. 주의사신님
    문서는 쪼개나 합치나 같은 겁니다.
    관리가 편하려면 하나의 문서로 만드는 것이 좋지만, 한 섹션이 너무 크면 문서를 나눠도 좋습니다.
    단 문서를 나눌 경우에는 문서에 Link를 걸어야 하는데 Link된 문서는 바로 열어 볼 수 있도록 회사의 문서관리시스템이나 소스코드관리시스템에 등록해서 그 Link를 추가해야 합니다.
    좋은 경험을 가지고 계시네요.
    꾸준히 계속 적어나가면 매번 실력이 늘어가는 것을 느낄 수 있을 겁니다.

  7. Blog Icon
    Jake

    안녕하세요, 전규현님 오랜만입니다.
    문서를 만들겠다고 달려드는 데서 부터 문서화 작업이 힘들어 지는 것이 아닌가 생각합니다. 요즘 인기있는 지속적 통합이나 지속적 배포같은 부분에서 말하듯이 문서화도 짧게 지속적으로 문서를 만들어 나가야 하지 않을까 생각합니다. 시스템 만들어 놓고 테스트 시작하거나, 통합을 시작하거나 하면 큰 문제가 생기니 짧게 짧게 작은 양에 대한 작업을 하자는 것처럼 문서화도 그 때 그 때 노트 형식으로 적어 놓으면서 발전 시켜 나가는 방법도 나쁘지 않은것 같습니다.

  8. 안녕하세요. Jake님
    과유불급이라고 생각합니다.
    그래도 여전히 문서 만들기를 지극히 싫어 합니다.
    그래서 최근에 Agile에서는 문서를 안만들어 되는 것으로 착각하고 혹 하기는 합니다.
    문서를 만드는 방법이 다를 뿐이죠.

  9. 문서는 만드는것보다도 계속 업데이트하는게 중요한것 같더군요..
    실제로 버전이 올라가다 보면 문서와 소스내용이 틀려 낭패보는 경우도 가끔 있구요..
    저술하신 "소프트웨어 개발의 모든것"을 봤지만 제가 말씀드린 경우의 해결책은 못 본것 같은데요..(기억을 못하는지도..)

    문서의 버전업을 어떤 형식으로 진행할 수 있는지 방안이 있으시면 조언 부탁드립니다.
    또 문서없이 wiki만 사용하는 경우 문제점이 있을까요? (요즘 문서의 버전문제때문에 wiki를 검토중이라서요..)

    언제나 좋은 글 감사합니다..

  10. 안녕하세요. 무혹님
    그래서 문서는 최대한 적게 만들어야 합니다.
    제 책에서도 문서의 업데이트에 대한 내용이 있습니다.
    책의 내용을 보면 이와 관련된 내용이 몇가지 있습니다.
    문서는 업데이트가 어렵기 때문에 꼭 필요한 문서만 만들고 SRS는 꼭 업데이트 하라고 하고 있습니다.
    또한 설계문서는 완벽하게 업데이트하기 어렵다고 설명하고 있습니다.
    설계문서는 구현을 하기 위해 필요한 것이기 때문에 나중에 변경되는 것은 모두 업데이트 하기 어렵습니다.
    그래서 Doxygen이나 JavaDoc을 잘 이용할 것을 설명하고 있습니다.

    설계에서는 그렇기 때문에 인터페이스를 최대한으로 깔끔하고 간단하게 만드는 것이 좋습니다. 너무 얽히섥히 섞인 인터페이스는 나중에 바뀌더라도 관리가 잘 안됩니다.

  11. Blog Icon
    csj

    약간 다른 이야기 이기는 합니다만..
    대체로 글 잘 쓰시는 분들이 코딩 역시 잘 하시더군요

    후배들 코딩 스타일을 글 쓰는 유형에 비교하면 다음 3가지로 간추려 지는데..
    -시인 타입: 이해하기 힘들다. 잘 돌아간다.
    -이면지 제작자: 이해하기 힘들다. 잘 안 돌아간다.
    -기자 타입: 이해하기 쉽다. 잘 돌아간다.

    요새는 코딩하기 전 과제 계획서 또는 일정표 등 문서 부터 써 보라고 합니다.
    글을 쓰는 모습을 보면 이 사람이 코딩을 어떻게 하겠다 대충 알 것 같더군요
    더불어 우리가 수학 논문을 많이 쓰기 때문에 증명 숙제 한거나, 쓴 논문을 보면 이 녀석이 위 중 어느 타입이구나 감이 오더군요.

  12. csj님 안녕하세요.
    전적으로 동감합니다. Coding도 하나의 언어잖아요. ^^

  13. 안녕하세요 ~ 좋은 글 잘 봤습니다
    저는 컴퓨터와는 전혀 관련이 없지만 말씀하신 내용은 학생부터 나이든 할아버지 할머니까지 도움이 되는 거 같아요

    뭐 개인적으로는 연구노트를 꾸준히 제 때에 쓰고, 제 때에 다시 살펴보는 게 얼마나 어려운 지 느끼고 있네욤 ㅡ _ㅡ;;

  14. 안녕하세요. Playing님
    세상만사 다 비슷한가 봅니다.

  15. 한번 작성이 아니라 계속 업데이트 해야 하고
    그걸 여러 사람과 공유/동기화 하는게 가장 힘든걸 보면
    Trac 등에서 위키로 문서화 하는 추세가 바람직 할수 밖에 없는것 같아요.

  16. 안녕하세요. 구차니님
    Word로 작성을 하던 Wiki를 이용하든지 큰 상관은 없을 것 같습니다. 중요한 것은 문서를 작성하는 것이고 그 내용이 더 중요하다고 생각합니다. 어디에 적느냐는 서로 장단점이 있는 것 같습니다.

    내용이 중요하다는 의미는 설계문서를 작성할 때 UML을 이용하느냐 Doc로 작성하느냐 노트에 연필로 작성하느냐보다는 "설계"자체를 잘 하냐가 더 중요하듯이 어차피 내용을 잘 모르면 어떠한 툴을 가져와도 의미 없는 문서가 됩니다.

    그래서 선배들이 작성한 문서를 리뷰에 참석해서 꾸준히 배워나가는 것이 문서에 무엇을 적어야 하는지 배우고 또 어떻게 적어야 하는지 어떻게 리뷰를 해야 하는지 익힐 수 있습니다.

    또, 무엇은 적을 필요가 없는지도 자연스럽게 배우게 됩니다.

    현재 그런 환경이 아니라면 누군가가 먼저 시작을 해야겠죠. 항상 선구자는 힘든 법입니다. ^^

  17. Blog Icon
    csj

    선구자는 힘들다는 말, 무척 공감이 갑니다.

    "내가 무엇을 해 보겠다" 할 때 대부분 반응은 "왜 귀찮게 그런 걸 하냐"가 대다수 더군요

    가끔은 왜 이걸 해야 하는지 설득하는게 더 힘들 때도 있습니다.

    여하튼 최근에 작은 프로젝트 팀장이 되어 이것 저것 해 보려고 하다보니 고민이 많네요.

  18. 그런 경우는 무엇을 하고 무엇은 지금은 무리인지를 판단하는게 중요합니다.
    사실 이런 판단이 가장 어려운 판단 중에서 하나입니다.
    그럴때 주변의 선배나 전문가에게 물어보는 것이 가장 좋습니다.
    본인 스스로 판단하는 능력이 생기려면 이러한 경험을 모두 해 본 후 일겁니다.
    참 힘들죠~

  19. Blog Icon
    철이

    현재 3명이 작은 프로젝트를 진행 하고 있습니다.

    문서화.. 참 힘들네요.. ㅠ

  20. 안녕하세요. 철이님
    혹시 문서화를 왜 하려고 하시나요?
    문서를 작성하면 프로젝트의 기간이 줄어든다는 것을 믿고 계시나요?
    이것을 경험을 통해서 알고 있지 않으면 문서를 만들기 정말 어렵습니다.
    대부분은 몇번 문서를 만들다가 프로젝트 시간만 더 걸리고 문서가 사장되기 일쑤입니다.
    이런 경우는 필요없는 문서를 만들거나 문서를 잘못 만들기 때문인 경우가 많습니다.
    그래서 제 책에서는 설계 문서보다더 스펙(SRS)문서를 만들라고 권하고 있습니다. 또한 뒤늦게 만드는 문서는 필요없고 프로젝트를 더 지연시키므로 만들지 말라고 하고 있습니다.
    또 중요한 것은 문서는 가능하면 적게 만드는 것이 가장 좋습니다.

개발문서를 만들기는 했는데 업데이트가 안되는 이유

2010.03.24 20:07 by 전규현


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





필자는 여러 소프트웨어 회사들의 컨설팅을 진행하면서 먼저 회사의 분석을 위해서 그 동안 소프트웨어를 개발하면서 만들어 놓은 문서를 요구합니다. 사실 문서만 봐도 회사의 개발현황을 대부분 알 수 있습니다.

그런데, 제대로 작성된 문서를 제시하는 회사는 거의 없다시피 합니다. 물론 Wiki나 Google Docs등의 온라인 문서를 포함해서 제대로 작성된 문서는 거의 없습니다. 가끔 문서를 제시하는 회사들이 있기는 하나 수년간 전혀 업데이트를 하지 않아서 쓸모가 없어진 것들 뿐입니다. 

정리를 해보면 다음과 같습니다. 

  • 문서가 아예 없거나 없다시피 한 회사
  • 몇 년동안 업데이트 안된 문서들만 있는 회사 (오늘의 주제)
  • 쓸모없는 문서들을 너무 많이 만든 회사 

야심차게 문서 한번 잘 만들어보겠다고 결심하고 개발 시에 문서를 열심히 만든 후에 소프트웨어는 계속 업그레이드가 되는데 문서는 과거에 머물러 있는 경우에 대해서 얘기를 해보겠습니다.

이런 문서는 죽은 문서입니다.

내용이 맞는지 틀리는지 확인이 안되는 문서는 혼동을 일으킬 수 있습니다.
이런 일이 발생하는 이유는 여러 가지가 있지만 대표적인 이유로는 진짜 문서가 필요해서 만들었다기 보다는 문서가 필요하다고 하니까, 또는 위해서 시켜서 만들었는데, 막상 개발에 크게 도움이 안되고, 단순히 문서를 만들었다는데 의의를 두는 경우가 있습니다. 또, 문서를 너무 잘(많이) 만들어서 소프트웨어가 업그레이드 될 때마다 문서를 갱신하려고 하니 초기 개발 때에 비하여 유지보수 시는 급하게 개발하는 요청이 많아서 미처 문서까지 갱신할 시간이 없는 경우도 있습니다.

이런 경우 모두다 "문서를 위한 문서"인 경우입니다.

문서가 진짜 필요해서 만든 경우가 아니라는 얘기입니다. 역량이 충분히 성숙되기 전에 문서 작성 문화를 정착하려면 어떻게 해야 할까요?

문서를 적게 만들어야 합니다. 

적게 만들면서도 개발에 유용해야 합니다. 그래야 문서를 만드는 일이 프로젝트에 큰 부담이 되지 않고, 추후 업데이트가 가능해집니다.

오래 되어서 쓸모 없어진 문서를 책꽂이에 잔뜩 꽂아 놓고 "옛날에는 문서를 열심히 만들었는데"하고 회상 하십니까? 지금은 그렇게 하고 있지 않다면 효과적이지 않은 방법으로 문서를 만들면서 조직 내에 정착되지 못한 겁니다. 문서 작성을 문화로 정착하려면 "작고 효율적으로 문서 만드는 법"을 익혀야 합니다.

왠만한 크기의 프로젝트도 문서는 한 두 개로 충분합니다. 스펙문서(SRS)와 경우에 따라서 설계문서 정도를 만들면 됩니다. 스펙문서는 요구사항을 분석하는 방법, 꼭 필요한 내용을 적는 방법, 리뷰하는 방법 등을 익혀야 합니다. 요즘은 스펙을 적는 방법에 있어서 다양한 시도들을 하고 있지만, 방법은 조금씩 달라도 꼭 필요한 내용을 빠짐없이 효과적으로 적어야 합니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by v.max1978
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 문서

  1. 저는 문서를 적게 만드는 것 보다는,
    doxygen이나 ea 또는 여러 툴들을 병행해서,
    문서 작업을 별도로 하지 않아도 항상 up-to-date 하게 만드는 것도 좋은 방법이라고 생각이 듭니다.

    셋팅하는게 귀찮지만 말이죠. 한번 하면 인수인계나, 관리할때 편하거든요.. :)

  2. 안녕하세요. PatternLoad님

    Doxygen이나 JavaDoc을 이용하는 것은 Low level design 문서 용도로 아주 좋은 방법이죠. 귀찮더라도 이런 규칙은 프로젝트 초기부터 정하게되면 모두 따르도록 어느정도 강제가 필요합니다. 하지만 Doxygen도 업데이트 안하는 경우도 있더군요. - -;

    스펙은 또다른 이슈입니다. 다른 방법이 별로 없습니다. 툴을 이용하는 것도 분석 작업과 업데이트를 대신해주지는 않습니다.

  3. 예 그렇죠. 스펙은 아무래도 서로 협의하고 조율해야 되는 부분이니깐요. 정말 게으름과 싸워 이기는 문제는 힘들죠.. 전 SparxSystems의 Enterprise Architect로 이러한 환경을 통합할려고 노력하고 있습니다. 툴이 대신 업데이트 해주지 않아도, 어느정도 연관성을 충분히 잡아주는것 같습니다. 물론 이런일도 꽤 번거로운건 사실이죠.. :)

  4. 저는 문서에 대한 활용도(접근성 및 검색 용이성)가 높다면 그만큼 최신 내용으로 업데이트 될 가능성이 클거라고 봅니다. 이전 회사에서는 항상 MS워드로 문서를 만들고 게시판에 등록시키도록 강요했습니다. 지식검색시스템을 구축해놓고 윗분들이 보기에 좋은 형상을 만들어 놓은거죠. 하지만 실무에서는 검색도 안되고 접근도 용이하지 않았습니다 (다운로드해서 업데이트 해서 다시 올리고..ㅡㅡ)
    전 외부 공개용 문서(메뉴얼등)를 제외하고는 쉽게 활용가능한 툴을 쓰자고 제안했었습니다. 그 방안으로 위키를 제안했었는데 묵살당했죠...ㅋㅋㅋ 로우레벨 문서는 저도 doxygen이 좋은듯..

  5. 안녕하세요. 청하님
    문서를 작성하기 어려우면 툴은 더욱 쓰기 어려운 측면이 있습니다. 결국은 어디다기 쓰느냐보다도 무엇을 어떻게 쓰느냐가 핵심입니다. 또한 몇십년전부터 이런 시스템이 없었을 때도 문서를 작성하는데 문제가 있는 것은 아니었습니다.
    저도 이런 시스템을 도입하는데는 긍정적으로 생각합니다. 다만 문서를 먼저 쓰고 리뷰하는 것을 할 줄 알아야 됩니다.

  6. 위키는 위키문법의 장벽이 무시 못하고
    그래서 fckeditor + mediawiki 혹은 fckeditor + dokuwiki로 하려고 했는데
    아무도 안하시더라구요 ㅠ.ㅠ


    언젠가 한번 doxygen을 시도해봐야할꺼 같아요..

  7. 안녕하세요. 구차니님
    그렇게 쉽게 바뀌면 정말 좋겠습니다. ^^
    사람들은 바꾸려고 하지 않는 것이 습성입니다. 일단 익숙하지 않아서 불편해하고, 바꾼다고 나아진다는 확인이 없고, 일이 더 많아지고 귀찮아질까봐 바꾸지 않습니다.
    Doxygen도 시도해보고 알아봐 놓는 것은 좋으나 혼자서 열심히 하다가는 혼자만 바쁘고 그 결실은 다 같이 나눠가지다가 금방 포기하고 맙니다. 이런 것은 회사차원에서 강제성을 가지고 추진해야합니다.

  8. Blog Icon
    koraper

    저도 작년부터 설치형 게시판, fckeditor + mediawiki 등등등 문서 정리를 위해서 많은 것을 시도해 보고 있는데 강제가 없으면 중간에 잘 안되더군요.
    그래서, 전략을 좀 수정했습니다. 우선 제가 강제 할 수있는 프로젝트 팀부터 고과에 반영한다고 엄포를 놓아서 조금씩 해보고 있습니다.^^;
    이게 성과가 잘 나오면 전사적 도입도 시도 할 수 있을 것 같아서요....
    항상 제가 고민하는 내용을 시의적절하게 포스팅해 주셔서 감사합니다.

  9. 안녕하세요. koraper님
    전사적인 시행이 어렵다면 시범프로젝트에서 성공사례를 보여주고 설득하는 것도 오래걸리기는 하지만 좋은 방법입니다.

  10. 변화되는 것은 사람의 활동이고 좀 처럼 변화되지 않는 것은 문서라고 생각해 봅니다.
    으쌰으쌰 해서 잘 된 문서를 만들었다고 해도 이 후에 누가 사용할지 ,또는 어떤 환경요소에 따라서 처음 문서제작의 의미가 살아나거나 또는 죽거나 하는것 같아요.
    경험적으론.. 대 다수의 프로젝트가 말씀하신것처럼 '문서을 위한 문서'가 대부분이었던 것 같습니다. 또는 윗선에 보여주기 위한 방편이 많았던 것이 분명했습니다.

    이를 개선해 보고자.. DDD에서 말하는 Context Map이라던지, Context Integration과 같이 시간이 지남에 따라 문맥이 흐려지는 것을 막기 위한 전략도 어느정도 타당성이 있어 보이지만..(이게 과연 현실적으로 가능할지..이론적인 것만은 아닌지 더 경험해 봐야만 하는 그런 종류의 것인것 같습니다.)
    문서작업을 대부분 싫어해서도 그렇고, 윗선에 보여주기위한 문화라던지, 아니면 문서나 소프트웨어를 인질극으로 삼으려고 하는 사람에겐.. 여간 귀찮은 장애물이 되지 않을까 합니다.

    프로젝트 진행이나 의사소통이 하도 되질 않아, 어느정도 강제적인 강압도 필요한 적도 있었습니다. 하지만만 지속적인 강압은 제일 좋지 않은 결과를 낸 것 같은 아쉬운도 많이 남았습니다.

    항상 저도 이와 같은 고민을 하고 살아요. 어떻게 하면 개선할 수 있을까? 어떻게 하면 모순을 없앨 수 있을까? 정작 중요한것은 개인의 실력일까 아니면 팀웍 콘트롤일까? 신기술이 중요할까 아니면, 타당성 있는 기술이 중요할까 등등..

    규현님 글보면 어찌 제 생각이랑 일치한지~

  11. moova님 안녕하세요.
    그래서 항상 개발 문화를 강조합니다.
    자연스럽게 무슨 일을 하던지 문서화를 하는 수준까지 되어야 합니다.
    꼭 필요한 소수의 문서를 알맞게 만드는 것이지요.
    말로 때우는 방식은 더이상 안됩니다.
    그렇게 문서를 만드는 것이 가장 빨리 개발하는 방법이라는 것을 깨달아야 합니다.

  12. SRS가 업데이트가 되지 않고 공유도 안되면서 Test Case 문서랑 매치 하려니 여간 답답한 일이 아닐 수 없지요. 뭐 제가 파견 나가 있는 삼X전자 또한 뭐 해당 문제들이 비일비재 합지요.

  13. hoya님 안녕하세요.
    그런 케이스는 거의 주먹구구 방식과 다를바 없습니다. 삼X전자에서는 뭔가 체계를 갖추고 근사하게 개발을 하고 있다고 착각할지 모르지만 실리콘밸리의 구멍가게 소프트웨어 회사보다도 못하다는 것을 아직도 깨닫고 있지 못합니다.
    그러면서 우리나라의 중소 소프트웨어 회사들의 씨를 말리고 있죠.

  14. 기존 문서에 대한 고정 관념을 좀 버렸으면 합니다.
    프로젝트를 진행 하다 보면 문서 관리에 대해서 반드시 MS의
    word나 ppt 등 특정 파일 포맷으로만 관리 하려고 합니다.
    물론 이런 포맷이 쓰이는 문서도 있지만 이틀에서 벗어나면
    문서가 아닌 것으로 생각해서 도입을 하지 않습니다.
    저런 형식적인 문서보다 차라리 사내에 허접한 게시판 하나
    를 만들어서 히스토리 관리 하는게 더 실용적이라고 생각이
    듭니다.

  15. 안녕하세요.
    맞습니다. 어디에 적느냐가 아니고 내용을 작성하는게 중요하죠.
    내용을 적을 능력이 없는 사람들은 또 어디에 적더라도 안되기는 마찬가지입니다. 그래서 안된다고 툴만 찾아다기 보다는 무엇을 어떻게 적을지 배워서 꾸준히 해보는 것이 중요합니다.

  16. Blog Icon
    토토제작

    2011년-사설토토제작 판매

    ❤직접 눈으로 확인하시고 결정하세요

    토토사이트 전용 자바 프로그래머와 전문 디자인너 로 구성되어 빠른 제작과 지속적으로 유지보수 및 서버운영까지 풀 서비스 하고 있습니다 한번 고객은 또 다른 분으로 연결되고 서버 및 유지보수에 안정된 관리로 인정받고 제 구매를 해주시는 믿음과 실력으로 인정받고 있는 작업장 입니다 *사설토토

    사용자 패이지

    고급스러운 이미지와 다양한 기능으로 유저에게 보다 신뢰 있게 다가 갈수 있도록 전문 디자인너가 충분한 상당 후 제작해 드립니다 또 요즘 무엇이 인기이고 유행인지를 꾸준히 파악하고 한발 앞서 실행과 유행을 창조하고 있다고 자부합니다
    (참고로 원하시는 사이트 디자인 100% 똑같이 도 가능합니다)


    관리자 패이지

    자동방식과, 엑셀방식. 수동방식 모두 겸비한 최신형 버전입니다
    저희가 직접 자바언어로 제작해서 판매하고 있습니다
    즉 돌고 도는 소스가 아님을 분명히 말씀 드립니다 또 직접 제작한 소스라 수정 및 유지보수가 원활합니다 기능은 너무 많아서 여기서는 생략 하겠습니다 오셔서 상담 받으시고 직접 조작해보시면 됩니다 *사설토토


    계약절차

    1번 제작사이트의 요구사항을 문서로 만들어서 주세요 ( 기능, 디자인, 로고 )
    2번 계약금 100만원 입금
    3번 서버계약 ( 일본서버,미국서버,홍콩서버 선택 )
    4번 세팅 및 디자인 작업
    5번 중도금 100만원
    6번 완성확인 후 잔금처리
    7번 유지보수 및 서버 관리 ( 선택 )


    사이트 제작비용은 총 4백입니다
    서버 관리는 원하시는 분에서만 월 소정에 관리비 받고 관리해 드립니다(도메인 등록, 서버세팅, 서버이전, 아이피 변경, 등등 24시간 관리해 드립니다)
    총 제작기간은 1주일에서 상항에 따라 2주 정도 입니다

    @소스언어는 자바입니다
    @상담시 프로그래머인 제가 통화합니다
    @직원&투자자 소개 및 동업자 연결시켜 드립니다



    msn 메신저 toto8949@hotmail.com

    msn 메신저 모르신 분
    검색창에 msn메신저 설치 검색하시고 설치하시면 됩니다.
    홍콩서버,미국서버,일본서버,사설토토제작

도대체 얼마나 자세히 적어 달라고?!

2009.06.29 23:58 by 전규현


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




소프트웨어 개발자들에게 문서 작성은 고역이 아닐 수 없습니다. 그래서 문서는 소프트웨어를 개발한 후에 후배들에게 소프트웨어에의 스펙과 구조를 설명하기 위해서 작성하곤 합니다. 이런 경우에는 문서의 효용성도 별로 없을 뿐더러 문서가 제대로 작성되었는지 알기도 어렵습니다. 또 개발자들은 기억을 더듬어서 문서를 작성하기도 어려울 뿐더러 이러한 작업은 하기 싫은 고역이 될 수 밖에 없습니다.

소프트웨어를 개발하는데 있어서 필수적인 문서의 대부분은 개발한 내용을 정리하기 위해서 만드는 것이 아니고, 소프트웨어를 개발하는데 필요한 내용을 앞 단계에서 작성하는 것입니다.

즉, 설계를 하기 전에 스펙을 작성하고
구현을 하기 전에 설계서를 작성하고
테스트를 하기 전에 테스트 계획 및 TCL(Test Case List)를 작성합니다.

하지만 현실에서는 이렇게 작성된 문서를 가지고 다음단계 작업이 잘 안 된다는 문제가 있습니다.
즉, 다른 개발자가 작성한 스펙을 가지고 설계 및 구현(코딩)을 할 수가 없는 경우가 대부분입니다.

스펙을 제대로 작성하려면 남이 설계할 수 있을 정도로 상세하게 적어야 하는데, 잘못하면 백과사전이 되고 또는 흔히 빈약한 스펙서를 작성합니다. 이렇게 되면 스펙을 작성한 사람이 또 설계자에게 계속 스펙을 설명해줘야 합니다. 

이 글을 읽고 있으면서 이것이 뭐가 문제라고 생각하신다면 이미 가내수공업식 개발에 익숙해지신 겁니다. 한 개발자가 스펙도 작성하고 설계, 구현, 테스트를 모두 다하는 이런 가내수공업식 개발은 회사는 성장의 한계에 부딪히고, 개발자는 성장하지 못하는 악순환에 빠지기 쉽습니다.

개발문서는 그 문서를 보고 다음단계의 개발자들이 충분히 일을 진행할 수 있을 정도로 상세해야 합니다.
따라서 상세화 정도는 상황에 따라서 다르다는 것을 알 수 있습니다. 설계자가 해당 제품에 대해서 빠삭하게 알고 있으면 기능스펙을 적당히 적어도 문제가 없을 것이고, 신입사원에게 일을 시키려면 좀더 자세히 적어야 할 것입니다. 

또한, 좀더 작은 양으로 이해 가능한 문서를 작성하려면 소프트웨어를 다양한 뷰에서 바라보고 적어 주는 것이 좋습니다. 따라서 스펙을 작성할 때는 소프트웨어를 인터페이스에서 바라본 모습, UI에서 바라본 모습 그리고 기능, 비기능적인 내용을 적어주면 기능에 대하여 많은 양을 설명한 것보다 더 이해하기 쉽습니다.  설계에 있어서도 소프트웨어의 아키텍처를 데이터 관점, Flow 관점, 시간의 흐름, 시스템의 상태 등 다양한 관점에서 바라본 모습을 적당히 표현해 주는 것이 하나를 자세히 적어 주는 것보다 좋습니다.

매우 추상적인 글을 적어 놓은 것 같지만, 실제 개발문서를 제대로 적기 시작하면 잘 적었는지? 못 적었는지는 명확하게 구분 됩니다. 작성된 문서를 가지고 다음 단계 개발자들이 별 무리 없기 개발을 할 수 있고, 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

그래서 이를 위해서 기법을 쫓기 보다는 실제로 필요한 것이 무엇인가 생각하고 실질적인 접근이 필요합니다. 잘못 익힌 기법은 독이 될 수 있습니다.

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

전규현 소프트웨어이야기 TCL, 문서, 설계, 소프트웨어, 스펙

  1. 문서가 실용적이어야 한다는 의미는 공감합니다만,

    > 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

    이 부분은 일반적인 이야기가 아니지 않나 생각됩니다. 코드는 문서보다 훨씬 빠르게 바뀌기 때문에 문서는 뒤쳐지게 되어있는데, 아마도 말씀하신 의미상으로는 문서를 이런 변화까지 수용하게 적어야 된다는 것이 아닐까 추측되는데, 그건 잘 작성된 기준으로 생각하기에는 적합한 기준이 아니지 않나 생각됩니다. 문서가 바뀌기 때문에 잘 작성하지 않았다는 것은...

    또한, 다음 단계(?)의 개발자가 이를 활용할 수 있는 프로젝트가 있는 반면, 그렇지 않은 프로젝트도 많이 있기도 한 것 같습니다.

  2. charlz님 안녕하세요.
    좋은 의견 감사합니다. charlz님의 댓글을 보면 "문서"라는 말을 가지고도 서로 다른 이미지를 그리고 있다는 생각이 듭니다.

    예를 들어서 스펙서를 기준으로 보면 설계단계나 구현단계에서 스펙서가 바뀌는 것은 스펙이 바뀐 것이고, 그 변경에 대한 비용을 몇곱절로 치뤄야 합니다. 하지만 개발 기간내에 스펙이 전혀 바뀌지 않는 프로젝트는 찾아보기 힘들죠. 하지만 변경을 최소화는 해야 합니다. 설계가 진행되고 코드가 진행됨에 따라서 스펙서를 바꾸지는 않죠.

    그리고 설계서의 경우에도 코드가 진행됨에 따라서 아키텍쳐나 인터페이스의 변경이 있기 전에는 설계서가 변경되지 않습니다. 문서와 코드가 같이 발전해 나가는 경우는 분석, 설계, 구현단계가 적당히 밍글된 형태일 수도 있습니다. 사실 크고 작은 많은 프로젝트가 이렇게 진행되고 성공적으로 잘 끝나기도 합니다. 하지만 이런 방법으로 계속 성장하기는 어려움이 있습니다.

    사실 문서가 잘 작성되었는지 판단하기는 대단히 어렵습니다. 그래서 그 한방법을 언급해 봤습니다.

    제가 항상 주장하는 것은 개발자들이나 개발사들의 현재 상황에 따른 전투적인 대응방법이 아니고 개발자들이 꾸준히 성장하고 실력도 향상되며 현재 프로젝트를 잘 수행해내기 위한 원론적인 방법들이 주류를 이룹니다. 그런 관점으로 읽어주세요.

    charlz님의 의견과 같은 여러 관점은 제가 많은 도움이 되네요. 감사합니다.

  3. Blog Icon
    ^^

    문서라 지긋지긋하지요.

    정말 돈받고 만드는 프로덕트로서의 문서들은 가끔 종이값과 타이핑값을 받기 위해 만드는거 아닐까 하는 생각이 들곤 합니다. 그래서 도큐멘트도 아니고 산출물이라고 하는게 아닐까 생각하죠. ^^

    SI성 프로젝트를 많이 하다보니 몇십종의 산출물들이 과연 필요나 할까 싶을떄가 많기도 하고, 왜 보지도 않고 쓸데도 없는 문서를 주구줄창 만들어야 할까 싶습니다.

    경험적으로 생각해보면 산출물은 의사전달을 위한 문서, 생각을 정리하기 위한 문서, 점검을 위한 문서 세종류가 있는 것 갑습니다. (그냥 제 기준입니다.)

    무엇을 위해서 작성을 하는지가 중요한 것 같은데.. 문서 프레임에 압도당할때가 만은데요. 잘하지는 못하지만 고객이나 내부 팀원이 쓸 수 있을 만한 표현력이 들어가면 문서의 프레임이야 얼마든지 고칠 수 있지 않나 싶네요. ㅎㅎ

    뭐 항상 만들고 나면 이것 저것 한방에 보고 싶다는 욕심에 덕지덕지 붙여넣다가
    질려서 흐지부지 되는 경향이 있어서.

    될 수 있으면 간략한게 좋지 않나 생각이 드네요.

    특히나 고객의 요구사항이 수시로 변할떄는 말이죠.

  4. 산더미같이 많은 문서를 만드는 프로젝트들은 아주 잘못된 관행입니다. 소프트웨어 개발에 대해서 잘 모르는 고객이 거대한 방법론에 있는 문서를 무작정 다 요구하곤 합니다. 그 방법론에서도 문서를 다 만들라고 하지 않는데도 잘못 적용하는 것이지요.
    하지만 개발사 입장에서 고객이 요구하는데 안만들 수는 없는 노릇이지요. 수많은 문서 중에서 실제 개발에 필요한 문서는 소수에 불과합니다. 그런 문서만 제대로 만들고 나머지 프로세스나 관리를 위한 문서들은 최소한의 노력만 들이는 것이 좋습니다.

악순환 vs. 선순환

2009.05.22 12:24 by 전규현


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




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

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

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

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

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

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

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

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


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

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

  1. 오픈 세미나에 와주셔서 늦은 시간까지 열강해 주신것 너무 감사드립니다. 좋은글을 잘 읽고 갑니다.

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

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

개발자 여러분~ 문서 만들기 싫죠?

2009.05.06 14:54 by 전규현


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



흔히들 소프트웨어를 개발하는데 문서를 만드느라고 시간이 더 오래 걸린다고 생각합니다. 문서가 필요한 것은 알고 있는데, 만들기는 싫다고들 합니다. 이러한 생각을 깨기 전에는 문서의 필요성에 대해서 이해하기가 어렵습니다. 

소프트웨어를 개발하는데 문서를 만들어서 더 오래 걸렸다면 잘못된 것입니다.

필요도 없는 문서를 잔뜩 만들고 있거나, 문서를 작성하는 실력이 없어서 낑낑대고 시간만 잡아먹는 경우 일겁니다. 두번째 경우야 그러면서 실력이 늘 수도 있지만, 필요 없는 문서를 잔뜩 만들고 있다면 정말 헛고생하고 있는 겁니다.

문서를 만드는 이유는 소프트웨어를 더 빨리 만들기 위해서 입니다.

거꾸로 문서도 안 만들고 어떻게 더 빨리 만들 수 있냐고 반문하고 싶습니다.

모든 내용을 머리 속으로 모두 기억하고 있다?
2명 이상이 개발을 할 경우 모든 정보는 대화로 공유하나?
모든 것을 혼자서 결정할 수 있나? 리뷰는 안 하나?
이런 궁금증이 생깁니다.

결론은 혼자 모든 것을 마음대로 결정해도 좋고 
협업 없이 혼자서 개발을 하고 
천재일 경우는 가능하네요.

이런 경우가 아니라면 크든 작든 문서가 필요할 것입니다.

간단한 문서만 있어도 되는데 장황하게 많은 문서를 만든다면 오히려 이것이 잘못된 것일 겁니다.
충실하고 자세한 문서가 필요한데 문서가 없거나 너무 간단하다면 개발이 더 오래 걸릴 겁니다. 
이 판단이 프로젝트마다 다르다는 겁니다.
그래서 모든 프로젝트에서 기계적으로 모든 문서를 만들어내라고 하면 비효율적이 아닐 수 없습니다. 그리고 이를 프로젝트 기간이나 투입인원에 따라서 또 기계적으로 정할 수 없는 노릇입니다. 결국 경험 있는 프로젝트 팀에서 결정할 일입니다.

프로젝트에 꼭 필요한 문서를 최소한으로 만들고 유지하는 것이 올바른 방법입니다.

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

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

전규현 개발문화 리뷰, 문서

  1. 항상 실천하는 건 아니지만 제 경우에는 오늘이 회사 다니는 마지막 날이고 내일부터는 다른 사람이 이 문서로 업무를 수행해야 한다라는 생각으로 문서작성을 하려고 노력하고 있습니다.

    물론 일정에 쫒기면서 작성한 문서일수록 대충 작성하는 경향이 강해지긴 합니다만... -_-;;

  2. 우울한 딱따구리님 안녕하세요.
    문서에 대한 생각이 바뀌는 것은 쉬운일이 아닙니다. 이게 문서만의 이슈가 아니고 소프트웨어 개발 전반 모든 것이 바뀌어야 문서의 역할이 달라지니까요.

    회사를 옮기시는 건가요?

  3. 아.. 아뇨 ^_^;;
    늘 인수인계 한다는 마음으로 꼼꼼히 문서를 작성하려고 노력은 하는데 잘 안된다 뭐 이런 이야기죠 ㅎㅎ

  4. 아 그렇군요. 오해했습니다.

  5. Blog Icon
    maddog

    누가 인도해주지 않는 이상, 이래 저래 삽질할 수 밖에 없어요...
    여전히 삽질(지금은 쓸데 있어보이는 문서 만드는)중...

  6. maddog님 안녕하세요.
    학교에서 배울 수 있는 것도 아니고, 필드에서 선배나 스승에게 배워야 하는데, 기회가 많지는 않죠.

  7. 맞습니다. 최소한의 꼭 필요한 문서만 만들어야겠죠. 하지만 그 최소한의 꼭 필요한 문서가 무엇인지 잘 모르는 조직이 대부분입니다. 그게 문제죠....

  8. C-Thinker님 안녕하세요.
    맞습니다. 그래서 안전빵으로 모든 문서 다 만들라고 하는 경우가 많죠.

  9. Blog Icon
    문제는

    문서화의 중요성은 굳이 제삼제사 설명하지 않아도 누구나 다 아는 것이겠지요. 문제는 '정치적'이라는 것이지요. 발전하는 조직에서는 코드나 문서에 대해 관리자나 경험자가 리뷰하고 잘못된 부분이나 이해가 어려운 부분을 수정하도록 권고합니다. 그러나 그렇지 않은 조직에서는 (개발자의 실수든 뭐든) 잘못된 부분을 '꼬투리'잡고 그것을 향후에 '정치적'으로 이용할 카드로 생각하지요.

  10. 그중 심각한 환경이네요. - -;

  11. Blog Icon
    bluepoet

    규현님 오랜만에 글남깁니다.^^

    이제 입사 3년차인저는 누구보다 문서화의 중요성에 공감하는바입니다. 제 목표중하나였구요. 대학교시절엔 무작정 테크니컬 라이팅카페를 개설해보기도했습니다. 물론 노력은 전혀.^^;;;

    제가일하는 곳이 외국계 인만큼 문서화는 정말 의무중의 의무라고 할수 있습니다. 심지어 프로젝트 스케줄의 압박도 무시할만큼 중요하게 여기고있죠. 하지만 현재 점점 흐려지고 나약해지는 제 문서화 스킬이 한탄스럽습니다. 외국애들이 만든 문서를 보면 기가 찹니다..심지어 아름답다고 느껴질정도네요. Visio 와World의 조화..환상입니다. 제스스로 물어보면 답이 있겠지만 역시나 큰원인은 테크니컬 Wrtiing기술의 부재네요..더구나 모든 문서가 영어로 작성해야되다보니 개발보다 더 스트레스를 받는게 사실입니다. Visio같은 유용한 툴조차도 제대로 이용못하니까요..
    그래서 규현님의 Writing스킬 노하우를 알고싶네요..

    잔뜩 두서없이 써놓고 한번 날려먹고 또 두서없이 써봤습니다.

    감사합니다.^^

  12. bluepoet님 안녕하세요.
    문서의 내용도 중요하지만, 문서를 작성하는 방법, 리뷰하는 방법등 그 과정도 중요하죠. 그런 과정은 배우지 못하고 결과만 보면 정말 배우기 어렵죠.

Track me, if you can

2009.05.04 10:16 by 전규현


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



"요구사항 추적"이라는 말을 들어 보셨을 겁니다.
요구사항, 기능, 컴포넌트(클래스), 파일, 함수들의 연관관계를 추적하여 특정 요구사항에 관련된 컴포넌트나 소스코드들을 추적하고, 거꾸로 함수가 바뀔 때 이 변경에 영향을 받는 요구사항을 알아낼 수 있습니다.

왠지 근사해 보입니다.

실제로 요구사항을 추적하려고 노력하는 회사를 종종 보게 됩니다. 하지만 요구사항을 추적할 필요도 없는 작은 소프트웨어이거나 엉터리로 하고 있는 경우가 대부분입니다. 아니 100%입니다.
요구사항 추적이라는 것이 말만 근사해 보이지, 대부분의 역량으로는 거의 불가능합니다. 또 요구사항 추적툴 없이 엑셀파일에 끄적거려서는 할 수 없는 일입니다. 

요구사항 추적은 사람의 생명을 다루는 소프트웨어이거나 엄청난 비용과 테스트가 불가능한 우주선을 만들 때나 사용하면 됩니다. 이 경우는 감히 비용대비 효과를 논하기가 어려우니까요.

우리가 접하는 대부분의 소프트웨어는 요구사항 추적이 필요 없습니다. 실제로 요구사항 추적이 대단히 어려울 뿐만 아니라 요구사항 추적을 해서 얻는 것이 별로 없습니다. 요구사항 추적을 해보신 분들은 아시겠지만, 실제로 어설픈 문서라도 만들어 놓고 써본 적도 별로 없을 겁니다. 또, 요구사항이나 컴포넌트가 변경이 되어도 요구사항 추적 문서를 갱신하는 것은 대단히 어렵습니다. 오히려 방해 요소가 됩니다.

대부분의 소프트웨어는 요구사항 추적을 하지 않아도 별 문제없을 만큼 작거나 테스트로 충분히 커버가 됩니다.

단 하나, 고객이 요구사항 추적 문서를 꼭 원할 경우 설득을 해보고 안되면, 엉터리 문서라도 만들어 주는 것이 좋겠죠. 이때는 어차피 요구사항 추적 문서를 활용하기 위한 것이 아니니 최소한으로 간단하게 만드는 것이 좋을 겁니다.

이렇게 문서를 꼭 만들어야 하는 상황이 아니라면 근사해 보인다고 괜히 요구사항을 추적해볼 필요는 없습니다. 추적한다고 추적이 되는 것이 아니니까요. 그런 노력을 테스트를 제대로 하는데 들이는 것이 훨씬 더 효율적입니다.

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

전규현 프로젝트/요구사항분석 문서, 변경, 엑셀, 요구사항, 추적

커뮤니케이션 오류

2009.04.19 23:16 by 전규현


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



소프트웨어 프로젝트를 진행하다 보면 수많은 커뮤니케이션의 오류를 발견하게 됩니다.
문서화 되지 않은 수많은 의견과 결정들에 대한 오해와 대화를 하면서 발생하는 표현의 오류는 한 두개가 아닙니다. 이는 비단 프로젝트에서 뿐만 아니라 일상생활에서도 벌어지는 현상이지만, 일상생활에서의 커뮤니케이션 오류는 그렇게 심각하지 않을 수 있지만, 프로젝트에서의 커뮤니케이션 오류는 심각한 손실을 초래하기 때문에 조심할 필요가 있습니다.

따라서 프로젝트를 진행하면서 오가는 대화나 기록은 명확해야 합니다. 미사여구보다는 직설적인 화법으로 핵심을 정확하게 말해야 합니다. 또 하나의 문장은 사실, 의견, 추축, 가정, 결정 또는 정보일 수 있습니다. 그런데, 현재 하고 있는 말이 사실인지 의견이지 명확하게 하지 않으면 수많은 오해가 발생합니다.
 
특히, 의견이나 추측을 사실처럼 얘기하면 다른 사람들은 이를 바탕으로 계획을 세울 수도 있습니다. 또 경영진은 잘못된 결정을 내려서 큰 손해를 보게 될 수도 있습니다. 그리고 가정으로 이미 확인된 사실처럼 얘기하면 프로젝트는 큰 리스크를 안게 됩니다. 

따라서 프로젝트에서는 구체적으로 가정과 종속관계를 파악하는 활동을 하게 됩니다. 프로젝트를 진행하면서 확인되지 않은 사실이나 결정해야 할 것들 및 종속되어 있는 항목을 찾아서 리스크관리를 해야 하기 때문입니다. 이러한 하나하나가 프로젝트의 리스크라는 것을 생각하지 못하면 지뢰밭을 걷는 것과 같습니다.

이러한 커뮤니케이션 오류를 제거하려면 이 문장이 사실인지 의견인지를 정확하게 구분하여 적는 것이 좋습니다. 특히 누구의 의견이라고 적을 수도 있고, 누구의 결정이라고 표현할 수도 있습니다. 그리고 가정은 언제 확인하고 해결이 될지 계획까지 적는다면 누구나 해당 내용이 확인이 필요한 가정사항이고 상황에 따라서 프로젝트의 위험 요소라는 것을 쉽게 파악할 수 있습니다. 이렇게 직설적이고 확실한 표현이 삭막하게 들릴 수는 있지만, 프로젝트를 진행하는데 있어서는 더 좋은 표현법입니다.

연인에게 이러한 표현법은 안되겠지요? 
당신을 사랑하는데 이 표현이 사실, 의견, 추측, 가정 또는 결정일까요? 이를 구분해서 말한다면 따귀맞기 십상이겠네요.

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

전규현 프로젝트/커뮤니케이션 가정, 결정, 리스크, 문서, 사실, 소프트웨어, 의견, 추측, 커뮤니케이션, 표현, 프로젝트

소프트웨어 개발의 극과 극

2009.02.18 01:31 by 전규현


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



꽤 오래 전에 TV에서 "비교체험 극과 극"이라는 프로그램을 방영한 적이 있습니다. 어떤 아이템을 정해서 가장 비싼 것과 가장 싼 것을 비교하는 프로그램이었는데 꽤 재미있게 본 기억이 납니다.

 

소프트웨어를 개발하는 현장에서도 극과 극 현상은 드물지 않게 발생합니다.

 

여러 회사를 분석해보면 완전 주먹구구이거나 또는 너무 무거운 방법론을 도입해서 오히려 부담이 되는 경우가 많습니다. 적당히 중간인 회사를 찾기가 더 어렵습니다.

 

완전 주먹구구식 가내수공업 형태의 개발방식도 문제가 있지만, 몸집과 역량에 걸맞지 않은 거대한 방법론을 무조건 따라하는 것은 더 문제가 큽니다. 그럴 바에는 차라리 주먹구구가 낫습니다.

 

그런 주먹구구회사가 문제를 깨닫고 거대 방법론들을 스스로 연구해서 도입을 하면 그 핵심은 모르고 형식만 따라하는 경우가 많습니다. 그러다보면 프로세스가 너무 복잡하고, 문서도 너무 많이 만들어야 되는 경우가 허다합니다. 이런 시도는 거의 실패한다고 보면 됩니다. 애초에 따라 할 수도 없고, 억지로 따라한다면 비용과 시간은 몇 배로 더 들고 회사는 망하기 길 밖에 남지 않습니다. 국내의 대부분의 소프트웨어 회사들은 그러한 거대 방법론은 필요하지도 않습니다. 또 그렇게 많은 문서는 만들 필요도 없습니다. 개발에 필요한 핵심문서 몇 개만 자신들이 만들고 업데이트하고 감당할 수준 정도만 만들어내야 합니다.

 

극과 극의 양쪽이 아닌 회사에 딱 필요한 수준의 중간점을 찾아서 적용해야 합니다.

 

 

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

전규현 개발프로세스 문서, 프로세스

개발자도 문서를 잘 작성할 수 있어야 한다.

2009.02.16 13:26 by 전규현


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




개발자(엔지니어)들이 문서를 잘 작성하지 못한다는 것은 익히 알려져 있는 사실입니다.
 
개발자에게 프로그래밍 실력이 더 중요하지 문서 작성 기술이 얼마나 중요하겠냐?라고 생각하는 사람이 있을 수도 있겠지만, 개발자가 성장할수록 문서 작성 능력의 중요도는 점점 더 커집니다.
 
문서를 잘 작성하지 못하는 개발자는 협업을 하는데 있어서 치명적인 결함을 가지고 있다고 할 수 있습니다.
 
그럼 문서를 잘 작성하는 것은 무엇이고? 문서를 잘 작성하지 못하는 것은 무엇일까요?
잘 작성되지 못한 문서의 특징을 한번 살펴보죠.
 
  • 문서의 내용이 쉽게 이해가 되지 않는다. 외계어로 작성된 것 같다.
  • 여백 없이 빽빽이 작성되어서 읽는데 너무 피곤하다.
  • 문법이 많이 틀려서 내용도 신뢰가 가지 않는다. 주어도 없고 문장의 앞뒤가 전혀 맞지 않는다.
  • 주변 얘기만 빙빙돌려서 하고 있고 핵심이 뭔지 잘 모르겠다.
  • 내가 관심있는 내용은 없고 작성자의 관심거리만 적혀있다.
  • 사용하고 있는 단어들이 너무 전문적이고 어렵다.
  • 분량이 너무 많아서 읽기 힘들고 주제 파악이 힘들다.
 
물론 개발자라면 개발에 필요한 핵심문서를 잘 작성할 수 있어야 합니다. 하지만, 이같이 기본적인 문서작성 기술도 없다면, 개발문서라고 해서 잘 작성할 수는 없습니다.
 
"조엘온소프트웨어"의 저자인 조엘 스폴스키는 개발자를 뽑을 때 글을 잘 쓰는 사람을 뽑는다는 원칙이 있다고 합니다. 글 쓰기 능력을 키우는 것은 프로그래밍 실력을 키우는 것보다도 더 어려울 수 있습니다. 그래서 아예 글을 잘 쓰는 사람을 뽑는 것이 더 합리적으로 보이기도 합니다.
 
개발자들은 문서를 잘 작성하지 못한다는 얘기는 어디서나 통하는 말이지만, 특히 우리나라의 개발자들은 단순 주입식 교육 환경 때문에 읽고, 외우는 것은 잘하지만 자신의 의견을 남들에게 쉽고 조리있게 전달하는데는 익숙하지 못합니다. 그렇다고 문서작성을 포기할 수는 없죠. 평생 혼자서 개발할 것이 아니라면 문서는 점점 더 필요하게 되죠. 아니 혼자서 개발을 하더라도 문서를 잘 작성하는 것이 필요합니다.
 
그럼 문서 작성 실력을 키우기 위해서 어떻게 해야 할까요? 역시 훈련이 필요합니다. 단순히 여러 번 작성해 본다고 되는 것이 아니라 제대로 작성하기 위해서 노력해야 합니다. 이제, 문서 작성 실력을 향상하기 위한 몇 가이드를 하려고 합니다. 그 출발점은 다음과 같습니다.
 
"문서작성 기술이 필수 기술이라는 것을 먼저 인식해야 합니다."
 
필요성을 못 느끼면 발전도 없습니다. 그리고 문서를 잘 작성하려면 다음과 같은 것을 고려해야 합니다.
 
  • 문서를 작성하는 목적은 내가 일기 위한 것이 아니고 남이 읽기 위한 것이다. 읽는 사람의 눈높이에 맞춰서 적절한 단어를 사용해야 한다.
  • 주제를 직설적으로 전달해야 한다. 문서를 읽는 사람은 친절하게 문서를 처음부터 끝까지 다 읽어 줄만큼 한가하지 않다. 주제를 먼저 전달함으로써 문서를 읽는 사람이 문서를 계속 읽을지 말지 결정할 수 있도록 해야 한다.
  • 필요한 내용을 쓴다. 문서 작성의 목적을 달성할 수 있도록 문서를 읽는 사람이 기대하는 내용을 충분히 적어야 하며 자신만 관심 있어 하는 필요 없는 내용은 쓰지 않는다. 이런 내용들은 문서의 양만 늘리고 문서의 가치를 떨어뜨린다.
  • 사실과 의견을 확실히 구분하여 작성한다. 사실과 의견의 혼동은 수많은 오해를 불러일으키게 된다. 심지어는 중요한 비즈니스에서 잘못된 결정을 유도할 수도 있다.
  • 쉬운 표현을 써야 한다. 복합문장은 이해하기 어려운 경우가 종종 있다. 가능하면 문장은 작게 잘라서 하나의 문장에 하나의 논리만 포함하도록 하는 것이 좋다.
  • 맞춤법이 맞아야 한다. 맞춤법이 틀리면 문서의 내용 및 문서 작성자에 대한 신뢰가 떨어질 수 있다.
  • 읽기 편하게 화면을 구성해야 한다. 화면에 적당한 여백을 두고 자간, 행간을 조절하고, 적절한 그림이나 표를 사용해서 문서를 읽는 사람이 지루해 하지 않고 문서의 내용을 빨리 파악할 수 있도록 해야 한다.
  • 화면 꾸미기에 시간을 허비 하지 않는다.
 
다시 한번 강조를 하지만 개발자는 문서를 잘 작성할 줄 알아야 합니다. 구슬이 서말이라도 꿰어야 보배이듯이 머리 속에 아무리 좋은 정보를 담고 있어도, 이를 문서로 잘 작성할 수 없다면, 고급 개발자는 될 수 없습니다. 꾸준히 문서를 작성하고 읽는 사람으로 부터 평가를 받아야 합니다. 문서를 잘 작성해야 한다고 깨닫는 것이 문서를 잘 작성하기 위한 과정의 시작입니다.

이미지출처 : Microsoft Office Online

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

전규현 사람과 기술 문서

  1. 회사에서 문서작성하라는 이야기가 저도 제일 무섭습니다.. ㅠㅠ

  2. kkommy님 안녕하세요.
    개발자들은 문서 작성하지 말고 개발하라고 하면 대부분 좋아하죠. ^^

  3. Blog Icon
    ~_~

    잘 잘성해야겠군요

  4. 들려주셔서 감사합니다.

  5. 공감합니다.
    일전에 "문서 작성 방법"에 대해 정리해서 팀원들에게 나누어 준적이 있는데,
    그때 팀원들 반응이 "너도 관리자 다 됐구나" 뭐 이런 냉소적인 반응이었지요.
    살짝 상처받았던 기억이 납니다 ^^;

  6. 헝그리맨님은 팀장이신가보죠? 팀원들이 건방지네요. ^^

  7. 제가 블로그하는 이유 중의 하나가 작문 연습이기도 하죠. 그런데 생각처럼 잘 안 되네요.

    그리고 제목에 오타 있습니다.
    잘성 -> 작성

  8. 아리새의펙촉님 안녕하세요. 오타가 있다니 쑥스럽네요. - -; 블로그에 글을 쓸 때 문법을 꼼꼼히 점검하지 못하네요.

  9. 알면서도 잘 안된다는게 문제죠. 잘 만들려고 노력하다 보면 언젠가는...

  10. 김성동님 안녕하세요.
    그래서 문서작성기술의 필요성을 인식하는 것이 가장 주요하다고 강조했습니다. 그래야 꾸준히 노력하죠.

  11. Blog Icon
    태민

    위대한 다익스트라도 학생을 뽑을 때 말하는 것. 글 쓰는 것을 보고 뽑았다고 들었습니다.

  12. 태민님 안녕하세요.
    그렇군요.

  13. 문서작성 아무리 강조해도 지나치지 않죠.
    특히나 소위 짬밥을 먹으면 먹을수록 더 중요해지는게 전체적인 그림(전체 시스템에 대한 이해라고 보시면 될듯^^)을 파악하는 능력과 함께 문서 작업 + 프리젠테이션 능력이 아닐까 합니다.
    역시 문서는? 남에게 보여주기 위한 것입니다.!

  14. 돌이아빠님 안녕하세요.
    하지만 많은 엔지니어들이 자신이 가지고 있는 정보를 감춤으로써 자신의 가치를 더 높이려하는 경향이 있습니다. 단기적으로는 그런 효과가 있을지 몰라도 결국에는 자신의 미래를 갉아먹는 짓이요.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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