태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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

2015.05.27 01:00 by 전규현


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





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


필자는 이런 현상이 벌어지는 이유 중 하나로 리뷰를 잘 안 하는 문화를 꼽고 싶다. 개발자라면 각자 생각해보자. 지금까지 얼마나 많은 리뷰를 해왔던가? 자신이 작성한 문서, 소스코드를 다른 사람이 얼마나 리뷰를 해줬고, 나는 또 다른 사람이 만든 문서와 소스코드를 얼마나 많이 리뷰를 해줬던가? 잘 생각해보자. 개발자가 10년 정도 일을 했으면 수백 건의 문서와 수만에서 수십만 라인의 코딩을 해왔을 것이다. 그 중에서 리뷰를 받은 경우는 몇 %나 될까?


개발자를 성장하게 해주는 가장 효율적인 수단은 “리뷰”다. 물론 책을 보거나 인터넷을 통해서 지식을 익히는 것도 하나의 수단이다. 하지만 리뷰를 통해서는 훨씬 더 효율적으로 배우고 책을 통해서는 도저히 알 수 없는 수많은 것을 배운다. 물론 본인도 리뷰를 통해서 다른 사람에게 나의 경험과 지식을 전달해줘야 한다.


리뷰는 요구사항을 확인하고 문제점을 찾아내고 바로 잡는 역할도 하지만 자연스럽게 개발자들의 성장을 돕는다. 물론 리뷰를 제대로 해야 한다. 수박 겉핥기 식으로 훑어보는 것은 제대로 된 리뷰가 아니다. 문서든 소스코드든 본인의 전문적인 관점으로 철저하게 수행해야 하면 여기에 많은 시간과 노력을 투자해야 한다. 리뷰를 귀찮은 절차로만 생각하고 바쁘면 생략하거나 흐지부지 사라지는 경우가 많다. 하지만 생략되거나 엉터리 리뷰 때문에 제품이 잘못되기도 하지만 장기적으로는 개발자들이 성장을 하지 못한다.


내가 경험하기로는 중소기업이나 대기업이나 리뷰를 하고 있다고 한 회사치고 진짜 리뷰를 제대로 하고 있는 회사는 매우 드물다. 대부분은 정형화된 프로세스를 따르기 위해서 형식적으로 수행하거나 리뷰를 위한 시간을 주지 않아서 개발자들이 어쩔 수 없이 리뷰를 대충하는 경우가 많다.


그럼 이렇게 꼭 필요한 리뷰가 우리나라에서 리뷰가 잘 안 되는 이유가 무엇일까?


첫 번째 이유는 바쁘다는 이유다. 바빠서 리뷰를 할 시간이 없다는 것이다. 하지만 바빠서 리뷰를 하지 않거나 소홀히 하면 점점 더 바빠질 것이다. 문제가 조금씩 더 쌓이고 개발자들이 실력이 정체되어서 개발 효율이 점점 더 떨어지기 때문이다.


두 번째 이유는 리뷰에 익숙하지 않기 때문이다. 그래서 리뷰를 거북해하는 개발자가 많다. 리뷰를 하면 지휘고하를 막론하고 자식이 작성한 스펙, 설계, 소스코드를 철저히 검토 받는다. 리뷰를 진행하면 지적을 당하기도 하고 다양한 의견 충돌이 있어서 협의, 조율해야 할 때도 있다. 물론 도움을 받는 경우도 많다. 하지만 나이별, 직급별 상하관계가 굳건한 조직이라면 아랫사람은 쉽게 반대 의견을 제시하기 어렵다. 자존심이 상하기도 하고 관계가 틀어지기도 한다. 또, 윗사람의 의견은 지시처럼 들리기 일쑤다. 이런 딱딱한 조직에서 리뷰는 쉽지 않다.


그럼 우리나라 대기업들은 어떨까? 회사마다 다르지만 보통 개발자들은 자기 분야의 보직을 바꾸지 않고 오랫동안 일을 한다. 그러다 보니 그 개발자가 일하는 것을 봐줄 사람도 별로 없고 리뷰를 하지 않아도 별 문제 없이 일이 진행되는 것처럼 보인다. 회사에서 리뷰를 강제화해도 진짜 리뷰가 잘 되는지 파악하기는 쉽지 않다. 이런 문제를 보완하고자 자꾸 프로세스와 절차를 만들어도 개발 효율만 떨어지지 리뷰가 잘 되는 것은 아니다. 이런 문제를 가지고 있는 회사가 리뷰를 잘하고 있는 회사보다 훨씬 많다.


리뷰를 제대로 안 하면 버그도 많아지고 이를 고치기 위해서 비용이 더 많이 든다. 테스트를 강화해서 해결을 하려는 노력도 많이 하지만 리뷰를 잘하는 것보다는 장기적으로 더 비싼 방법이다. 


결정적인 문제는 개발자가 성장하기 어렵다는 것이고 한가지 일에 매몰돼서 빠져 나오지 못하는 경우가 많다. 리뷰를 잘 하고 있다는 얘기는 자연스럽게 공유가 잘된다는 의미와도 같다. 말로만 공유한다고 떠들어도 리뷰를 안 하면 문서가 제대로 작성된 것인지 알 수가 없다. 하지만 리뷰를 제대로 하면 문서가 조금만 부실해도 바로 발견이 된다. 리뷰를 제대로 하면 문서가 충실하게 작성될 뿐만 아니라 그 내용이 리뷰를 통해서 동료들에게 전달된다.


리뷰를 제대로 안 하는 현상이 지속되면 특정 지식을 특정 개발자만 알고 있게 되고 이런 개발자가 많아질수록 조직의 유연성은 대단히 떨어진다. 소수의 개발자만 퇴사를 해도 회사가 휘청거리고 개발자들이 정말 바쁠 때 다른 개발자가 도와주기 어렵게 된다. 바쁜 사람은 항상 바쁘고 노는 사람은 노는 회사가 된다.


리뷰는 치열하게 해야 한다. 리뷰에 참여를 했다는 의미는 공동책임을 진다는 의미다. 고참 개발자가 될수록 다른 사람의 문서나 소스코드 리뷰를 더 많이 해줘야 한다. 그런 과정을 통해서 개발자는 계속 성장할 것이고 개발자 본인을 자유롭게 한다. 언제든지 현재 업무를 다른 사람에게 넘기고 새로운 일을 할 수 있도록 해준다.


이글은 ZDNet Korea에 기고한 칼럼입니다.


Image by http://www.lab-initio.com



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

전규현 개발문화 리뷰

  1. Blog Icon

    전 정말로 리뷰를 하고 싶은데 아무도 호응을 안 해줬었습니다. 그래서 이직한 직장에서 상사가 먼저 코드 리뷰하자고 했을 때 울뻔 했지요;

주먹구구식 개발이 통하는 이유

2012.08.27 06:46 by 전규현


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





우리나라의 많은 소프트웨어 회사들은 주먹구구식 개발에 대한 환상이 있다.

특히, 첫번째 시스템을 주먹구구식으로 개발을 해서 성공했는데 지금은 좀더 체계를 갖췄는데 더 개발이 잘 안된다면 과거 진짜 주먹구구식으로 개발할 때를 그리워하고 그 때로 돌아가고 싶어 한다.


여기 이와 관련된 과거 글이 있다. 

2012/07/26 - [소프트웨어이야기] - 옛날에는 개발을 더 잘했는데


주먹구구식으로 개발을 하다가 현재 체계를 갖추려고 노력하고 있다면 아직은 불완전할 뿐더러 반쯤은 주먹구구인 것이다. 그럼 주먹구구식 개발은 어떤 것인지 정의를 내려보자. 크게 5가지로 설명할 수 있다.


첫째, 스펙/설계 없이 개발을 하는 것이다. 또는 기능명세서, 시방서 등의 문서에 기능만 정리하여 개발하는 것이다. 이 방법은 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍처를 만들 수도 없고, 개발자들이 효과적으로 일을 나눠서 개발할 수도 없으며 프로젝트 진척상황을 거의 파악할 수 없다. 일정 지연은 일상이고 그야말로 끝나봐야 아는 것이다.


둘째, SVN, Git 등의 소스코드관리시스템과 Jira, Mantis, Redmine 등의 이슈관리시스템 없이 개발하는 것이다. 둘중 하나라도 사용하지 않으면 심각한 문제이다. 일단 쓰기만 하더라도 다행이지만 제대로 쓰는 것은 정말 어렵다. 대부분은 10% 정도의 기능밖에 사용하지 못하지만, 100% 기능을 활용해야 한다.


셋째, 혼자 북치고 장구치고 다하는 것이다. 일을 전문적으로 나눠서 하는 것이 아니고, 혼자서 기획, 분석, 설계, 코딩, 테스트, 빌드 등등 다 하는 것이고 이런 개발자가 여럿이고 서로 중복되서 일을 하기도 한다. 첫째에서도 언급했듯이 스펙이 제대로 작성되어야 일을 효과적으로 나눌 수 있는데 스펙이 없거나 부실하면 이런 현상이 벌어진다. 또, 회사의 조직이 소프트웨어 개발에 알맞게 효과적으로 구성되어 있지 않아도 이런 일이 벌어진다. 소프트웨어는 전문가들이 협업하여 개발하는 것이다.


넷째, 프로세스 없이 대충 개발하는 것이다. 흔히들 프로세스는 개발을 더 느리게 만든다고 주장하곤 한다. 그러면서 회사에서 프로세스를 만들려고 하면 반대 주장을 펼친다. 과거에 개발하던 방법을 서로 암묵적으로 알고 있다가 대충 개발을 하고 서로 이심전심으로 문제를 해결해 나간다.


다섯째, 리뷰, 공유 없이 개발하는 것이다. 가끔은 대충 기능목록 작성해서 마케팅이나 영업, 경영진과 리뷰를 하기도 하지만 제대로 된 리뷰는 아니다. 개발자를 제외하고는 지금 어떤 제품을 만드는지 정확하게 파악이 안된다. 심지어는 개발자들도 잘 모른다. 다 만들어봐야 어떤 제품을 만들었는지 알게 된다. 그러니 만들기 전에는 무슨 문제가 발생할지 몰라서 만드는 도중에 수많은 문제가 발생하고 재작업은 수시로 이루어 진다. 심지어는 80%쯤 만들었다가 아키텍처가 잘못된 것을 발견하고 다 버리고 다시 만들기도 한다.


정도의 차이는 있을 수 있다. 다섯가지 중에서 하나 이상이면 아직 주먹구구식 개발에서 완전히 벗어난 것이 아니다. 스스로도 주먹구구식으로 개발을 하고 있는지 평가를 해보자.


2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표


그럼에도 불구하고 주먹구구식 개발이 여전히 통하는 이유는 무엇일까?


첫째, Software의 크기가 아주 작다.

빌딩은 제대로 된 분석/설계 없이, 프로세스 없이 만드는 것은 불가능하다.

하지만 개집은 그런 것 필요 없다. 대충 만들어도 문제 없이 만들 수 있다. 한 사람이 머리 속으로 모든 것을 설계해서 만들 수 있는 정도의 규모라면 주먹구구식 방법도 훌륭한 방법이다.


둘째, 이직률이 극도로 낮다.

한번 개발을 해 놓으면 개발자들이 절대로 퇴사를 하지 않고 끝까지 책임져준다. 


셋째, 회사 규모가 작다.

개발자도 몇 명 안되서 서로 너무 잘 알고 모든 이슈가 더 구두로도 공유가 되고 급한 이슈는 자리에서 바로 일어나서 공유가 되고 논의할 수 있다. 가족적인 분위기에서 주먹구구식 방법이 훌륭하게 작동한다.


넷째, 소프트웨어 업그레이드가 없다.

한번 개발해 놓은 시스템이 업그레이드가 필요 없는 경우이다. 어떻게 든 첫번째 개발을 해 놓으면 문제가 없다.


그럼, 주먹구구식 개발이 앞으로도 계속 통할까?


회사가 잘되면 회사는 커지게 되어 있다. 개발자 수는 많이 늘게 되고 더 이상 자리에서 일어나 뒤로 돌아도 모든 개발자의 얼굴을 볼 수 없게 된다. 과거처럼 공유가 그렇게 잘 되지 않는다.


개발자들이 영원히 이직하지 않고 직원으로 있기를 바란다면 너무 큰 욕심이다. 개발자들은 언젠가는 이직을 하게 마련이고, 개발자들이 이직을 해도 개발은 잘 돌아가도록 되어 있어야 한다. 주먹구구식으로 계속 개발을 하게 된다면 아무리 가족적인 분위기라고 하더라도 직원이 Risk 요인이 된다.


Software 회사의 경영자라면 지금 대충 잘 굴러가는 것 같다고 해서 방심하면 안된다. 회사가 잘 되면 회사는 커지고 직원도 늘고 더 복잡해질 것이다. 문제를 모르고 방심하다가 문제가 터지고 나면 터진 댐을 막으려고 하는 것처럼 어렵다. 항상 미리 준비를 해야 하는 것이다.


물론, 처음부터 제대로 하는 것이 가장 빨리 개발하는 방법이고 좋지만 그것을 깨닫기는 매우 어렵다. 대부분은 문제가 터진 후에 우왕좌왕 한다. 주먹구구식 개발이 지금은 통할지도 모른다. 하지만 곧 주먹구구식 개발이 문제가 되는 상황이 올 것이고 이미 문제가 되고 있다면 너무 늦지 않았기만 바랄 뿐이다. 늦었다고 생각할 때가 가장 빠른 때이다.


image by Tolka Rover


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

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

전규현 개발프로세스 공유, 리뷰, 주먹구구, 프로세스

  1. Blog Icon
    RF

    소프트웨어 개발에 관심이 많은 대학생으로써 재밌게 잘 보고 갑니다.
    저런 능력을 키우고 싶은데 ... 더 공부해야겠습니다.

  2. RF님 안녕하세요.

    어치피 학교에서는 기본적인 프로그래밍과 전산 원리 등을 배우죠. 나머지는 대부분은 실제 일하면서 현실에서 배우는 겁니다. 좋은 환경을 가지 회사를 선택하는 것이 매우 중요한 요소라고 생각합니다.

  3. Blog Icon

    비밀댓글입니다

  4. 안녕하세요. 아주 작은 회사를 제외하고는 제대로 된 회사를 찾기는 어렵고 회사마다 다 다릅니다. 콕 찝어서 얘기하기는 어렵습니다.

나쁜 습관

2011.06.19 10:54 by 전규현


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







소프트웨어 회사가 프로세스를 제대로 정립하고 좋은 툴을 도입하고 개발문서도 잘 써보려고 노력하고 코딩 실력이 뛰어난 개발자들을 보유하고 있어도 넘기 힘든 벽이 있다.

우리나라 개발자들이 코딩 실력이 좋다는 것은 부정하고 싶지 않다. 처음에는 주먹구구식으로 시작을 했다가 회사가 커지고 고객이 많아지면서 문제가 있음을 깨닫고 프로세스도 만들고 기반시스템도 도입하지만 좋아지기는 하지만 기대만큼 큰 효과를 못보는 경우가 많다. 

그 이유는 개발자들의 몸에 베인 나쁜 습관들은 쉽게 고쳐지지 않기 때문이다. 나쁜 습관이 몸에 베인 개발자들도 교과서적으로는 그렇게 하면 안된다는 것을 알고 있어도 한번 몸에 베인 습관은 쉽게 고쳐지지 않는다.

나쁜 습관에 몸에 베인 것도 개발자들 탓은 아니다. 개발자들도 좋은 개발문화를 가진 회사에서 처음부터 일했다면 그런 나쁜 습관들은 경험해보지도 못했을 것이다. 

여기서 가장 중요한 개발문화는 바로 "협업"의 문화이다. "협업"을 생각하지 못하고 행동하는 하나하나가 모두 나쁜 습관들이다. 우리나라 개발자들은 협업을 해볼 기회가 별로 없다. 개발자들 스스로는 몇명씩 팀을 이뤄서 개발들을 해봤으니 "협업"을 해봤고 지금도 "협업"을 하고 있다고 말할 것이다. 하지만 그건 대부분 또하나의 주먹구구식의 일종일 뿐이다. 따라서 그런 팀은 4~5명이 한계이고 그보다 더 커지면 커지나 마나 하고 오히려 효율성이 더 떨어지는 경우도 많다.

그럼 협업의 핵심은 무엇일까요?

 첫째, 문서를 통한 협업이다.

우리는 대부분 여럿이 모여서 서로 의논하면서 개발을 하면 협업을 하는 줄 안다. 하지만 그렇게 해서는 커뮤니케이션 비용이 너무 많이 들어간다. 90%는 문서로 말하고 문서로 안되는 나머지 10% 정도만 말로 설명하면 된다. 하지만 대부분 그 반대다. 문서로 10%, 말로 90%를 커버한다. 
여기서 말하는 문서는 "SRS"(스펙문서), "설계문서", "코드"를 모두 포함한다. 또한 이슈관리시스템과 같은 시스템도 포함된다. 
스펙문서를 보고 문서 작성자 외에 다른 개발자들이 설계를 하고 구현을 할 수 없다면 아직 갈 길이 먼 것이다. 
설계문서를 보고 여러 개발자들이 일을 나줘서 흩어져서 일을 할 수 없다면 부족한 설계문서다.
코드에는 Doxygen등의 주석이 달려 있어서 해당 함수나 Class를 사용하는 동료들이 주석만 보고 사용할 수 있어야 한다. 또한 Doxygen등을 통해서 체계적으로 함수나 Class를 검색할 수 있어야 한다.
코드에 의미를 알 수 없는 숫자나 널려 있고 Public 함수들이 수시로 바뀐다면 협업을 제대로 하고 있다고 볼 수 없다. 
잘 설계가 되어서 Public interface들이 한번 정해지면 이에 대한 설명이 잘 달리고 끝까지 바뀌면 안된다.
이러한 것들이 남의 나라 얘기처럼 생각되면 아직 협업은 갈길이 멀다. 

 둘째, Peer review이다.

 Peer review를 빼고는 소프트웨어 개발을 얘기할 수 없다. Peer review하면 흔히 코드리뷰를 떠올리는데 코드리뷰는 그 중 일부이다.
Peer review에서 가장 중요한 것은 SRS(스펙) 리뷰이다. 스펙이 있어야 설계가 있고 그래야 코드리뷰도 의미가 있다.
SRS(스펙)는 프로젝트 모든 관련자가 참여하고 리뷰를 하여 완성해 나간다. SRS에는 프로젝트에 관련된 모든 내용이 들어가기 때문에 혼자서는 완성할 수 없고 리뷰를 거쳐서 모든 관련자가 검토를 해야 한다. 그리고 나면 이렇게 잘 완성된 SRS를 가지고 각자 흩어져셔 일을 할 수 있게 된다.
설계는 혼자서 하는 것보다는 여러 개발자와 리뷰를 하면서 좀더 좋은 아키텍쳐를 찾아낼 수가 있다. 개발자 개인이 가지고 있는 지식은 한계가 있어서 여러 사람과 머리를 맞대야 한다.
설계 시 다른 사람들의 다양한 의견을 받아들일 준비가 되어 있지 않다면 아직 리뷰 문화에 익숙하지 않은 것이다. SRS와 설계는 리뷰를 통해서만 완성도 있게 작성된다.
그리고 코드리뷰이다. 
이렇게 리뷰를 잘 해야만 제품의 버그나 재작업을 획기적으로 줄일 수 있다. 또한 리뷰를 통해서 서로의 지식과 경험이 공유가 되고 각 개발자들이 훨씬 빠르게 성장한다.

협업 문화가 잘 되어 있는 회사는 다른 분야의 개발자들이 입사를 해도 빠른 시간 안에 적응해서 같이 일할 수 있다.
또한 개발자 한두명이 퇴사를 해도 회사가 망할 정도로 휘청이지는 않는다. 
결정적으로 프로젝트를 더 빨리 끝낼 수 있다.

사실 문화라는 것을 말로 설명하는 것은 어렵다. 또한 말로는 다 알 것 같지만 몸에 베이지 않으면 아는 것도 아니요. 모르는 것도 아닌 어중간한 상태가 된다. 그럴 때는 회사에서 중요한 것들을 강제로 시행하는 제도도 필요하다. 물론 핵심을 모르고 무조건 강제로 하면 부작용이 더 클 수 있으므로 현재 가능하고 중요한 것부터 차근차근 해나가야 한다.

확실한 것은 이런 협업의 문화가 없이는 소프트웨어 회사가 즐겁게 일하면서 오래 살아남지 못한다는 것이다.

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

전규현 개발문화 공유, 리뷰, 협업

  1. 어떻게 보면 알박기 개발자들이 있어서 이러한 문화가 더 정착이 안되는게 아닐가도 생각을 해봅니다

    이런 문서작업을 해서 명확하게 하면
    자신의 실력이 다 드러나고, 밑천이 바닥난다고 생각을 해서 오히려 안하고 자기만 꼬옥 껴안고 있다 보니
    이런문제가 더 발생하는 걸지두요

  2. 안녕하세요. 구차니님
    알박기 개발자라... 멋진 표현입니다. ^^

내가 소스코드를 몰래 고치는 이유

2011.02.01 11:39 by 전규현


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






여러 소프트웨어 회사를 분석해보면 소스코드를 공유하는 정도에서 정말 많은 차이가 난다.
여기서 소프트웨어 회사란 소프트웨어를 개발하고 있는 회사로서 흔히 얘기하는 팩키지 소프트웨어 회사가 아니다.

SI회사, 가전회사, 산업로봇회사, 반도체장비회사, 인터넷회사, 게임회사, 금융회사 등의 다양한 회사를 모두 말한다.

이들 회사 중에서는 개발자가 소스코드를 몰래 고치고 공유도 하지 않는 회사들이 의외로 많다.

개발자가 소스코드를 몰래 고치는 이유에는 이건 것들이 있다.

 내 소스코드는 나만 알아야 회사에서 나의 파워가 유지된다.

일부 일리가 있는 이론이다. 내가 없으면 내가 작성한 소스코드를 이해하지도 고치지도 못하면 나는 절대로 짤릴 수가 없다. 문제가 있을 때마다 나에게 달려와서 이것 좀 고쳐달라고 하면 내가 좀 대단한 사람이 된 것 같은 생각도 든다. (이전에 블로그에 포스트한 글 참고)

실제로 실력이 있는 개발자들이 이런 행동을 하기도 한다. 하지만 이런 행동은 본인의 성장에 방해가 된다. 더 어렵고 가치있는 해야 할 사람이 과거의 소스코드에 발목잡혀서 휴가도 마음대로 못가게 된다. 개발자의 파워 및 가치는 과거에 있는 것이 아니고 미래에 회사에 필요한 가치에 있다는 것을 알아야 한다. 그것이 회사와 개발자의 상생의 기초이다.

 내가 작성한 소스코드의 품질이 형편없어서 보여주기 창피하다.

어떤 천재 개발자도 공유하지 않고 혼자 개발을 해서는 좋은 코드를 작성하기 어렵다. 꾸준히 공유를 하면서 다른 사람들과 의견 교환을 통해서 점점 나아진다. 혼자 개발한 코드는 이상한 코드로 가득차 있기 마련이다. 

세 사람이 걸어가면 그 중에는 꼭 스승이 있듯이 신입사원과 코드 리뷰를 해도 배울 것이 나오게 된다.

소스코드를 보여주는 것을 창피해 할 것이 아니라 자꾸 보여주고 교류를 해야 나아진다.

 엄청 어려운 것을 개발하고 있는 것처럼 행동했는데 소스코드를 보면 별 것 아니라는 것이 들통날 것 같다.

종종 접하는 문제다. 심지어는 오픈소스코드를 가져다가 동료들에게는 자기가 개발한 것 같이 자랑하는 경우도 있다. 이것은 회사입장에서 더 큰 문제가 될 수도 있다. 오픈소스 라이센스 규정을 어겨서 소송을 당할 수도 있다.

스펙을 적절하게 작성하고 설계를 하는 과정들에서 서로 리뷰를 적절하게 한다면 서로 어떤 컴포넌트를 어떤 Technology를 이용해서 개발하는지 다들 알게 된다. 어떤 것은 어렵고 어떤 모듈은 신입사원이 구현해도 될 만큼 쉬운 것인지 모두 알게 된다. 

SRS를 제대로 작성하게 된다면 모든 프로젝트 관련자가 프로젝트가 어떻게 구성되어 있고 어떻게 진행되고 있는지 훤히 할게 된다.

 너무 바빠서 공유할 시간도 없다. 

이미 불끄기 모드로 들어간 회사는 단기적인 해결책이 없다. 이런 회사에서는 서로 자기일 하기 바빠서 점점 서로 더 단절되게 된다. 또 다시 악순환이 진행된다.

시간이 좀 걸리겠지만 악순환의 고리를 끊어야 한다.

 공유를 해봤자 관심도 없다. 다들 바쁜데...

공유문화가 정착되지 않은 회사이다. 이런 회사에서 코드리뷰는 별 의미도 없다. 
시도를 해봤자 시간 낭비일 것이다. 내용을 모르는데 코드리뷰를 해도 기껏해야 Syntax 검사밖에 못할 것이다.
SRS리뷰를 먼저 시작하는 것이 좋다. SRS가 리뷰를 해야 할 것도 더 많고 SRS가 제대로 작성되어야 다음 단계인 설계, 구현이 제대로 진행되며 리뷰를 해도 내용을 알고 리뷰를 할 수 있게 된다.

이렇게 되면 "바쁜데..."라는 핑계가 조금씩 줄어들만큼 시간을 절약할 수 있게 된다.

 결론

개발자가 작성하는 모든 소스코드는 기록이 남아야 하고 남게 된다. 물론 분석, 설계도 마찬가지이다.

Baseline에 포함되는 소스코드와 문서들은 소스코드 관리시스템에 들어갈 때 설명을 적절하고 충실하게 달아야 한다. 이때 이 소스코드를 누가 리뷰했는지 기록을 남기기를 권장한다. 리뷰를 했다는 의미는 소스코드 작성자와 같이 이 소스코드에 대해서 공동책임을 진다는 의미이기도 하다. 이것이 부담스러워서 리뷰를 하지 않는다면 아무도 리뷰를 하지 않을 것이다. 서로 리뷰를 해주는 것은 모두에게 도움이 되는 것이다. 이것은 규칙으로 강요를 해서는 효과가 없고 분위기가 조성되어서 오랫동안 시행을 하여 문화로 자리를 잡아야 한다.

소스코드관리시스템에 소스코드를 올릴때는 버그ID(이슈ID)가 꼭 있어야 한다. 개발자가 원한다고 아무때나 마음대로 소스코드를 고치면 안된다. 개발자가 스스로 발견한 버그를 고칠 때도 버그관리시스템에 등록을 하고 고쳐야 한다.

이렇게 개발자가 생성한 모든 소스코드는 투명하게 모두가 볼 수 있게 한다면 이 혜택은 회사 뿐만 아니라 모든 개발자 그리고 본인에게도 돌아한다.

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

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

전규현 개발문화 SRS, 공유, 리뷰

  1. 비슷한 얘기가 생각나네요. 두 청년이 바둑의 명인이 되기위해 산으로 가서 바둑에만 전념한지 10년째, 자신감에 찬 두 청년은 산을 내려와서 다른사람들과의 대전을했는데, 매번 졌다는 얘기에요;;

    여쭙고 싶은게, 포스팅에 대부분 SRS을 강조하셔서 제 나름대로 개발진행하면서 기능과 이렇게 개발한 이유같은걸 문서로 만듭니다. 근데 혼자하다보니 이게 과연 잘 진행되는건지 의심이 가는건 어쩔수없네요.

    SRS 세미나 혹은 교육같은게 있나요? SRS의 개념을 익히고싶습니다.
    새해복 많이받으세요~

  2. 오산돌구님 안녕하세요.

    개발하면서 기능과 그 이유를 적는다고 한 것으로 봐서 문서를 개발하고 나서 적는 다는 의미 같습니다.

    문서는 원래 개발을 하기 위해서 더 빨리 개발하기 위해서 만드는 것입니다. 지금은 문서가 나중에 필요할 것 같아서 만드시는 거죠? 이런 문서는 용도가 많이 떨어집니다.

    SRS세미나나 교육이 있기는 하지만 SRS를 익히려면 직접 SRS를 직접 쓰고 프로젝트를 진행해 보는 것을 몇년 해봐야 합니다. 그러기 위해서 처음에는 좀 배워야 하는 과정이 필요합니다.

    제 책에 보면 SRS를 배우는 방법에 대해서도 소개가 되어 있습니다.

  3. Blog Icon
    bluemonk

    책을 읽어봤는데 그렇게 하면 되겠구나 라고 하는 느낌까지는 들지 않았습니다.

  4. 안녕하세요. bluemonk님

    그것이 책의 한계인 것 같습니다. 비디오 보고 골프를 배울 수 없듯이 직접 해보면서 경험하지 않으면 알 수 없는 것이 소프트웨어 공학입니다.

  5. Blog Icon
    별의파편

    지금은 좀 덜 하지만 저 같은 경우는 몰래 고치는 게 재미있어서 그런 적도 많아요. 새로운 패턴이나 프레임워크 보면 이전 소스를 고쳐보고 싶은...
    좋게 말하면 리팩토링인데 사실 코드 갖고 놀기....회사 자산 갖고....ㅡ.ㅡ;

  6. 안녕하세요. 별의파편님
    작은 회사에서는 흔히 있는 일이죠.
    회사의 소스코드의 아키텍쳐를 바꾸는 일이라면 여러 개발자와 리뷰를 많이 하면서 더 좋은 방법들을 계속 찾는 작업이 필요할 겁니다.
    소스코드가 변경되면 테스트가 많이 필요하고 코딩 작업 외에도 많은 작업이 필요합니다. 따라서 개인이 혼자서 마음대로 변경하는 것은 나중에 문제가 될 수도 있습니다.
    작은 회사 또는 작은 팀이라서 가능한 걸 겁니다.

  7. SRS가 뭔가요?

  8. 안녕하세요. 중원님
    스펙문서를 말합니다. 제 블로그에서 SRS로 검색을 해보시며 많이 나옵니다.

  9. Blog Icon

    비밀댓글입니다

  10. 감사합니다. ^^

  11. Blog Icon
    ymir

    협업에 관련된 포스트를 읽다가 이 포스트로 넘어왔네요.
    소스를 팀의 산출물로 협업을 통해 관리하는 경우에는 생각보다 투명하게 일이 진행됩니다.
    그러나 중소규모의 회사일수록 그런 경우는 많지 않으며..
    오히려 소수의 인원이 거대 모듈들을 작업하는 경우가 많고, 협업을 하는 케이스가 적습니다.
    그러다 보니.. 소스에 대한 관리 책임이 순전히 개인에게 넘어가버립니다.
    이런 경우 버그가 발생하면 결국 개인의 능력과 실력을 의심당하게 되고..
    회사에 피해를 끼치는 식으로 인식되어 버립니다.
    소위 욕먹고 깨지고 페이에도 문제가 생길수 밖에 없는 구조가 되어 버리죠.
    결국은 책임 회피를 위한 나몰라, 거짓말, 몰래 체크인, 다른 이의 계정으로 체크인 등...
    시스템과 프로세스를 무력화 시킬 수 있는 온갖 방법들이 동원되기도 합니다.
    코드를 대하는 마인드가 변하지 않는 한, 소위 이 '나쁜 습관'들은 쉽게 고쳐지지 않을 것 같습니다.

  12. 안녕하세요. ymir님
    다른 사람 계정으로 체크인은 좀 심하네요. ^^

  13. Blog Icon
    ymir

    다행(?)히도 그런 사례는 서너개의 회사를 거치는 동안 딱 한 번 봤습니다. =)

Peer review의 혜택

2009.05.13 13:44 by 전규현


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



"Peer review를 해야 하는데 바빠서 못하고 있다"라는 말을 종종 듣게 됩니다.
이 말을 들으면 Peer review를 해야 한다는 필요성을 사실은 알지 못하고 있다는 것을 알게 됩니다.
다들 Peer review를 해야 한다고 하니까 거기서 Peer review를 할 필요 없다고 하면 혼자 이상한 사람이 되니까 그냥 그렇게 얘기를 하는 것이지요.

정도는 다르지만 소프트웨어를 개발하고 있다면 기본적으로 Peer review는 꼭 필요합니다.
Peer review의 기본적인 2가지 목적은 다음과 같습니다.

1. 결함의 발견
2. 정보의 공유

Peer review를 말하면 Code review를 먼저 생각하는 사람들이 많은데, 사실 Code보다도 문서 Review가 더 필요합니다. 그 중에서도 스펙(SRS)의 리뷰가 가장 중요한 문서 중에서 하나지요. 문서가 코드보다 결함이 있을 경우 더 심각하고 나중에 고치려면 더 많은 비용이 들고, 개발 기간을 단축하고 효과적으로 일하려면 문서를 제대로 만들고 리뷰를 해야 합니다.
그럼, Peer review(스펙, 설계, 소스코드, 테스트 문서)를 하면 실제적으로 어떠한 혜택이 있는지 알아보도록 하겠습니다.

개발자
재작업 시간을 감소시켜 줍니다.
개발 생산성을 높여줍니다.
선배들로부터 많은 기술을 습득할 수 있습니다. 또 개발자간의 정보를 공유합니다.
디버깅 및 단위 테스트 시간이 줄어듭니다.

유지보수개발자
기술 지원 이슈가 감소하고, 기술지원이 손쉬워 집니다.
소프트웨어의 구조를 쉽게 파악할 수 있습니다.
유지보수가 용이해 집니다.

테스터
테스트 기간이 단축됩니다.
심각한 버그가 감소합니다.
테스트 케이스를 만들기 용이해 집니다.

분석가
잘못된 요구사항을 조기에 발견할 수 있습니다.
요구사항이 개발가능 해지고, 테스트가 가능해 집니다.

프로젝트 관리자
프로젝트 일정일 지키기가 더 용이해 집니다.
프로젝트의 리스크를 조기에 발견할 수 있습니다.
범위의 변경이 줄어듭니다.
협업이 개선됩니다.

위의 혜택 중에 더 많은 부분이 문서리뷰에서부터 비롯되며, 만약에 Peer review를 전혀 하지 않는다면, 위의 혜택들이 NOT이 되는데, 그런 프로젝트는 상상하기가 어렵네요. 
리뷰 문화가 아직 정착이 되지 않았다면, 일단 스펙을 작성할 때는 꼭 모든 관련자가 리뷰를 해야 한다는 규칙을 정해서 조금씩 리뷰에 적응하는 것이 어떨까요?

Peer review는 규칙에 의한 강제에 의해서도 자율만에 의존해서도 정착시킬 수 없습니다. Peer reivew에 필요한 기초 역량등 제반 여건이 되어 있어야 하고(이 정도도 안되면서 Peer Review를 한다고요?), 처음에는 어느정도 강제화를 하면서 점점 업무속에 파고들게 해야 합니다.


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

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

전규현 개발문화 Peer Review, 리뷰

  1. Blog Icon
    아름드리

    멀고도 먼 나라의 얘기처럼 보이네요.
    대부분은 '개발자 = 유지보수개발자 = 테스트' 공식이니깐요.

  2. 안녕하세요. 아름드리님
    '개발자 = 유지보수개발자 = 테스트' 이런 상황에서도 one man company가 아닌 이상 Peer review는 필요하죠. Peer review를 하지 않는다면 그 혜택을 모르는 것이고요. 아름드리님의 말씀처럼 많은 사람들이 먼나라 얘기처럼 느낄 겁니다. 그래서 우리나라 소프트웨어 문화가 갈길이 먼것입니다. 대부분 가내 수공업을 못벗어나고 있습니다.

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

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

UML전문가가 설계전문가?

2009.04.15 23:28 by 전규현


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




종종 "소프트웨어 설계를 잘 하려면 UML을 잘 알아야 합니까?"라는 질문을 받습니다. 

사실 넘치는 기법들이 개발자들을 더 혼란스럽게 하는 것에 종종 화가 날 때가 있습니다.
기법은 기법일 뿐입니다. 내용은 아니죠.

UML은 잘 정리된 모델링, 설계 기법이며 툴이고 많은 장점을 가지고 있다고 생각합니다.
그럼에도 불구하고 소프트웨어 설계라고 하고 UML을 떠올리는 것을 보면 UML이 본의 아니게 나쁜 일도 했다는 생각이 듭니다. 

잘 된 설계는 형식에 구애 받지 않고, 소프트웨어를 구현하기 충분하게 소프트웨어 구조를 잘 설명한 것입니다. UML이 그 중의 하나가 될 수도 있고, 전통적인 Flowchart, DFD, 수도코드나 글로 설명할 수도 있습니다. 설계는 어떠한 다이어그램을 그리고 어떤 툴을 쓰냐에 따라서 잘 되었는지 결정되는 것이 아니고 어떤 식으로 접근해서 설계를 하였고, 리뷰 하였는지가 더 중요하고, 이를 보고 구현을 담당한 개발자(본인일지라도) 충분히 구현할 수 있는 적당한 정도가 좋습니다. 그리고 미래의 비즈니스 비전에 대응할 수 있는 구조여야 합니다.

따라서 나는 설계를 시작할 때 종이와 연필 또는 화이트보드를 가지고 시작합니다. 개발자들이 토론을 하면 깔끔하게 컴포넌트를 나누는 것으로 설계를 시작합니다. 
설계 초기부터 툴을 이용해서 정리를 시작하면 감이 잘 안 오고 잦은 수정 때문에 귀찮을 수가 있습니다.

UML을 아는 것은 좋습니다. 남들이 UML로 작성해 놓은 것을 읽을 수는 있어야 하니까요.

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

전규현 프로젝트/설계 dfd, Flowchart, UML, 기법, 다이어그램, 리뷰, 설계

  1. 좋은 말씀이십니다.
    저도 설계를 최초 시작할때는 역시 볼펜과 종이를 가지고 시작합니다.

    물론 사전 요구사항 분석은 기본이지요. 그리고 나서 전체적인 시스템 구조를 어떻게 가져가야 할까를 종이로 열심히 그림으로 그리죠^^! 툴을 잘 다룬다면 좋겠지만, 꼭 잘 다뤄야만 전문가인건 아니죠^^!

  2. 돌이아버님 안녕하세요. ^^
    연필이 좋으면 글을 더 잘 쓸 수 있다는 것과 비슷합니다. 물론 좋은 연필을 사용하면 전혀 나쁠 것은 없지만, 글을 잘 쓰기위해서는 좋은 연필을 사기보다는 책을 많이 읽고 글쓰는 법도 배우고 글도 많이 써봐야죠.

  3. Blog Icon
    작은악마

    당연한 글인데 읽는 순간 많은 생각이 드네요.

    옛날 UML을 보고 감탄하고 그에 따라 볼려고 애쓰다보니.. 가장 핵심적인 면을 놓친것이 많았다 싶습니다.
    사실 적용한다고 해놓고 막상 한건 -_- 문서만 UML 형식으로 만들곤 했지만 말입니다..

  4. 작은악마님 안녕하세요. 축구 좋아하는 어린이가 멋진 축구화 보고 황홀해하고 축구화 살려고 축구는 안하고 맨날 아르바이트 하는 격이죠. 축구화 신경안쓰고 맨날 연습했으면 훨씬 잘할 것을...

  5. 다들 일정관리 어떻게 하고 있나 몇몇 회사분들게 물어보니
    "이것저것 다써봤지만 결국 비지오와 액셀 그리고 달력으로 돌아왔어 ㅎㅎㅎ"
    이렇게 결론이 나더군요.

    "툴이나 기법이 중요한게 아니고 사람이 중요하구나"
    라는걸 다시 느낀것 같습니다.

  6. 안녕하세요. 당근천국님

    저도 왠만한 프로젝트 일정관리 아직도 엑셀로 합니다. ^^ 그게 더 나아요.

이 정도도 안되면서 Peer Review를 한다고요?

2009.04.06 23:52 by 전규현


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



소프트웨어 개발의 기초도 되어 있지 않으면서 무리하게 Peer Review를 시도하다가 실패하기 십상입니다.

개발의 체계도 전혀 없이 코딩위주로 개발을 하고 있다면 Peer Review할 것도 별로 없거니와 Peer Review를 통해서 공유의 문제와 품질을 향상할 수 있을 것으로 착각하는데, 이는 Peer Review를 너무 만만하게 보는 것입니다. 피아노 기초도 안되어 있으면서 쇼팽을 치려는 것과 같고, 기초 체력도 부족하면서 축구의 고급 기술은 배워서 무엇 하겠습니까? 그래서 히딩크가 강조한 것이 기초체력이지요.

Peer Review를 정상적으로 진행하려면 최소한 소스코드관리시스템버그관리시스템은 제대로 사용하고 있어야 하며, 스펙과 설계문서를 제대로 만들어야 하며, 코딩 컨벤션을 따라서 개발을 하고 있어야 합니다. 간단하게 2줄로 설명을 했지만, 이 정도의 역량을 가지고 있는 소프트웨어 회사는 흔하지 않습니다. 즉, 대부분의 회사들이 Peer Review를 시행할 준비가 되어 있지 않고, 억지로 시행한다고 해도 그 효과를 제대로 누리기는 어렵습니다.

스펙과 설계문서를 제대로 만든다는 의미는 이미 Peer Review를 모두 포함하고 있는 것입니다. 여기서 또 많은 개발자들이 스펙과 설계문서를 제대로 만들고 있다고 착각할 수도 있겠지만, 현실은 그렇지 않습니다. 필자의 경험에 의하면 많은 회사와 개발자들이 스펙과 설계문서를 만들고 있다고 착각을 하고 있습니다. 이에 관한 얘기들은 추후에 올릴 계획입니다.

이렇게 얘기를 하면 매우 비관적인 것처럼 보이는데 비관적인 것이 사실입니다. 굳이 거짓된 희망의 메시지를 전하고 싶은 생각은 없습니다. 현실이니까요. 이렇게 된 것은 개발자들만의 탓도 아니고 회사에서 제대로 된 개발 환경 및 교육의 기회를 제공했어야 하는데, 그렇지 못했고 많은 회사들이 그냥 개별 개발자들에 의존해서 주먹구구식으로 개발해왔고 뭔가를 시도하려고 한 회사들도 그렇게 좋은 성과를 낸 회사는 별로 없습니다. 

결론을 말씀드리면 그럼에도 불구하고 Peer Review를 시행하려고 노력하는 것은 의미가 있다고 할 수 있습니다. 하지만 그와 더불어서 개발의 기초를 닦기 위한 노력도 병행해야 합니다. 이미 개발을 잘하고 있는데 기초가 부족하다고 하면 기분이 나쁠 수도 있는데, 사실이기 때문에 말을 돌려서 하고 싶지는 않습니다. 코딩도 잘하고 꽤 근사한 제품도 만들어 내지만, 효과적인 개발의 체계를 갖추고 있지 못한 것을 사실입니다. 그래서 좀더 좋은 제품을 좀더 짧은 시간에 개발할 수 있는데 그렇지 못하고 개발자들은 제대로 성장할 수 있는 기회를 갖추고 있지 못한 것입니다. 

앞으로 개발자로서 10년, 20년 후의 모습이 그려지지 않는다면 소프트웨어 회사로서 제대로 체계를 갖추고 있지 못한 것이 확실합니다. 제대로 소프트웨어를 개발하기 위해서 우선적으로 해야 할 것이 무엇인지 생각해야 합니다.

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

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

전규현 개발문화 Peer Review, 리뷰, 설계, 스펙

  1. 언제나 글 잘 읽고 있습니다. 빠른 시일 내에 효과적인 스펙 및 설계문서 제대로 만들기에 대한 내용을 볼 수 있길 바래봅니다. :)

  2. 우울한 딱따구리님 안녕하세요. 모터쇼 다녀오셨군요. 저도 항상 블로그 잘 읽고 있습니다. 처음에 블로그를 시작할 때 스펙을 첫번째 주제로 생각을 하고 있는데, 계속 주변만 서성거리고 있습니다. 블로그를 통해서 스펙을 잘 만드는 법을 습득한다는 것은 과욕이지만 해보는데까지 시도는 해봐야죠. 똑같은을 글을 가지고 1을 얻는 사람도 100을 얻는 사람도 있으니 1명의 독자라도 도움이 된다면 좋겠습니다.

  3. 용역 의뢰를 받다보면,
    특정 플랫폼을 위한 엔진을 개발하는데 고객이 너무 '배려심'이 많아서 산출물 필요없다고 하시는 경우가 있습니다. 고객 측에서도 개발진이 있으니 완료 보고서를 알아서 쓰겠다고 하는 거죠.

    문제는 설계 문서를 쓰지 않으면, '완료 보고'가 아니라 프로젝트 중간 관리 자체를 못하는 건데, 나서서 문서를 쓰겠다고 하니, 아군(?), 적군(?) 할 것 없이 쓸데 없는 짓이라고 말리더군요. 그래도 고집 피워서 겨우 기본 틀 잡아서 문서 제출하고 회의 때마다, 진도/이슈 체크 했더니 더 이상 아무 말도 없습니다.

    말씀하신게 옳은 현장의 작은 기업들이나 실무 개발자들은 SRS라던가, 진행 사항 관리를 위해 어떤 서식이 있는지도 모르는 경우가 많습니다. 가장 간단한 서식 몇개를 공개할까 생각 중입니다. 제가 최근들어 고민하는 내용을 그래도 밝혀 주셔서 감사한 마음 담아 주절 거리고 갑니다.

  4. 써니님 안녕하세요.
    고객도 산출물이 필요없다는 직원도 문서는 개발에 필요없다고 생각하고 있는 것이 문제죠. 대부분 문서에 대한 아픈 기억이 있고, 문서는 개발 시간만 늘인다고 생각하는 경우가 많습니다. 제대로 문서를 써본 경험도 전혀 없으면서 엉터리 경험을 가지고 착각을 하는 겁니다. 문서가 제대로 적히지 않으면 요구사항이 제대로 분석이 되지도 않고 서로 다른 생각을 하면 수많은 재작업을 해야 하며 프로젝트의 진척을 확인할 수도 없습니다.
    각 프로젝트 상황에 맞게 최소한의 문서를 만들어야 하는데, 쓸데없는 문서만 잔뜩 만들다가 아예 포기해버리는 경우가 대부분입니다.

    그리고 몇가지 Template을 공개하는 것은 거의 도움이 안되거나 오히려 방해만 됩니다. Template을 채우는 것을 문서를 작성하는 것으로 착각하기 때문에 그렇게 해 놓고 문서를 작성하고 있다고 할 수 있습니다.

    Template은 인터넷에 널려 있는데, 그게 없어서 문서를 작성 못하는 것은 아니고, 우선 문서 작성의 필요성을 못 느끼는 겁니다. 그리고 문서를 작성해본 경험도 거의 없으니 실력도 없는 것인데, 나름대로 문서를 작성하고 있다고 착각하기도 하고요.

    문서는 작성을 해보고 리뷰하고 또 배우고, 공부하고 작성하고 리뷰하고 프로젝트 해보면서 계속 실력을 향상시켜나가야지요. 그러면서 자연스럽게 자신의 회사에 알맞는 Template를 만들어가면 좋습니다. 표준 Template을 가지고 시작할 수도 있는데, 대부분의 표준 Template가 매우 Heavy하다데 문제가 있습니다. 또 자신의 회사와 맞지 않을 수도 있고요. 항상 의견 남겨주셔서 감사합니다.

  5. 먼저 답글 감사드립니다. 템플릿이 오히려 해가 된다는 말씀에는 깊이 공감합니다.
    ISO 9001 standard 문서 작업한다고 고생하던 기억이 떠오르네요 ^^;

    많은 SI 프로젝트 매니저들이 현실성 없는 양식들을 가지고,
    산출물 작성만을 강요하는 상황도 큰 폐해라고 생각 합니다.

    이렇게 이야기 하는 것보다 실제로 어떻게 쓰고 있는지 밝히는게 역시 낫겠네요.
    역시, 템플릿 자체 보다 중요한 건, What, Why, How 3가지 행동 지침이겠죠.
    서식을 만들면서 어떤 고민을 했고, 어떻게 적용했으며, 개선할 점들을 이야기하려고 합니다.

  6. 내제된 역량이 부족한 상황에서 문서만 만드는 것은 고역이죠. 그렇다고 실력이 느는 것도 절대로 아닙니다. 오히려 아픈 기억만 쌓입니다.

    다양한 경험을 블로그에서 소개하는 것은 매우 긍정적인 일인 것 같습니다. 자신의 경험들에 비춰봐서 도움이 될 수도 있고, 이견이 있으면 토론도 할 수 있겠죠. 어떤 글이 올라올지 기대하겠습니다. ^^

  7. Peer Review를 하기 전에 기본 역량이 되어 있어야 하겠군요
    우리 회사는 소스 코드 관리시스템은 예전부터 사용해왔고
    버그 관리시스템은 몇 번 시도하다가 최근에 다시 강력하게 시행을 하여
    현재는 안정적으로 버그 관리 시스템에 정착한 정도의 레벨입니다.
    스펙 문서와 설계 문서가 가장 취약하군요.
    현재 작성하는 문서가 전혀 없는 상태입니다.

    하지만 새로 개발하는 프로젝트가 아니라 유지보수 단계의 프로젝트라면
    어차피 처음부터 만들어 놓은 스펙과 설계 문서는 없기 때문에
    코드 리뷰만을 진행하는것도 어느 정도 의미가 있을것이라 생각합니다.

  8. 안녕하세요. 이성열님
    이제 체계적인 개발을 위한 첫발을 내디신 겁니다. 소스코드관리시스템과 버그관리시스템도 제대로 쓰려면 시간이 한참 더 걸립니다. 제 책을 보시면 조금 도움이 될 겁니다.
    현재 겪고 계시는 문제의 50% 이상은 스펙 문서의 부재에서 온다고 보면 됩니다. 유지보수 단계라고 해도 스펙 문서가 없다면 계속 악순환 밖에 될 수 없습니다.
    또 다음 제품부터 스펙을 작성하려고 마음을 먹었다고 해서 그렇게 될 가능성은 거의 Zero입니다.
    코드 리뷰로 유지해 나가는 것은 차차차선책쯤 됩니다.

  9. 답변 감사합니다.

    우선 우리회사의 사업분야 대해 간단히 설명을 드리면
    반도체 장비, LED, SolarCell 장비등의 제어 SW 개발과 머신 비전 알고리즘 ,HW 개발 등입니다.
    개발자는 저를 포함 7명이고요 . (제가 사장 )
    고객업체에서 개발하는 장비에 들어가는 프로그램믈 만들어야하는데..
    기본적으로 1인 1프로젝트 식으로 진행합니다.
    2인 1프로젝트를 하더라도 개발 단계에서 GUI, 스퀀스 제어등으로 나누어서 진행하고
    개발이 끝나면 거의 1명이 맡아서 합니다.
    다행히 어떤 장비를 하던지 기본 SW 라이브러리를 사용하고 GUI등을 비슷한 구조로 만들기 때문에
    다른 사람이 분석하는데 큰 문제는 없습니다.

    유지보수는 한사람이 다수 프로젝트를 하고 있으나 문제가 생겼을때 서로 도와 줄 수 있을 정도로
    각 프로젝트 소스에 대한 이해는 하고 공유하고 있습니다.
    장비가 납품되면 유지보수가 자주 일어나는것은 아니지만.. 거의 장비 폐기 전까지 가끔씩이라도 SW 유지보수가 진행되기 때문에 .. 오래된 개발자들은 거의 모든 프로젝트 소스를 디버깅 할 정도까지는 이해하고 있습니다.

    일단..개발시 한 프로젝트에 다수가 참여하는 일반적인 다른 업체와는 조금 성격이 다르기는 합니다.

    그리고 장비 개발하는 고객사에서 초기에 스펙을 거의 작성하지 않고 , 소프트웨어는 물론 기구 하드웨어 스펙도 정확히 없는 경도 많습니다. 당연히 소프트웨어는 어떤 기능들이 들어가야 하는지 정확한 스펙정의 과정이 전혀 없습니다.
    그렇다고 우리가 다 스펙을 작성해서 고객사에 제시하기에는 개발일정이 바로 코딩 들어가도 빡빡 일정이라도 힘들고요. 고객사도 자신들이 원하는 소프트웨어가 어떤 기능이 필요한지 대충 밖에 파악을 못합니다.

    결론적으로 고민은 고객쪽에서 요구사항, 스펙 작성 등이 전혀 안되고 있는 상황에서
    개발 문서를 어떤식으로 작성해야 하는지 고민입니다.

  10. 안녕하세요. 이성열님
    온라인소프트웨어개발역량 분석도 답장을 보냈으니 확인해보세요. ^^

    말씀하신 스펙에 관련된 내용은 전혀 특이한 상황이 아닙니다. 많은 회사들은 자신들만 이러한 상황이라고 생각하는데 그렇지 않습니다. 더 열악한 경우도 많습니다.

    이렇기 때문에 스펙을 작성하는 역량이 있어야 합니다. 지금도 스펙을 그냥 문서에 적는 행위로 생각을 하시는 것 같은데 문서에 적는 것은 결과를 기록하는 것 뿐입니다. 분석역량이 있어야 한다는 뜻입니다. 대부분은 회사는 분석역량없이 자신의 상황만을 핑계로 대는 경우가 많습니다.

    스펙은 계속 변하고 초기에는 잘 모르기 때문에 분석을 잘하고 상황에 맞게 잘 대처를 해야 합니다. 이는 스펙을 한번 제대로 적어보면 그때 이해를 할 수 있지 그전에는 100번 얘기를 해도 이해하기는 불가능합니다.

    또 한가지 위험한 것은 개발자 각각에 전적으로 의존을 하는 것입니다. 개발이 너무 쉬워서 개발자가 교체가 되어도 누구나 다 할 수 있는 것이라면 문제가 없겠죠. (이러면 경쟁력도 없겠죠? ^^) 하지만 그렇지 않다면 개별 개발자에 의존하는 것 자체가 큰 리스크입니다. 회사에서 개발자가 가장 중요한 자산이지만 특정 개발자에 의존하는 시스템은 매우 위험합니다. 개발자가 아플 수도 있고 퇴사를 할 수도 있습니다. 개발자는 팀으로서 힘을 낼 수 있어야 합니다.

    회사의 시스템과 프로세스가 80%정도를 차지하고 개발자의 Risk는 20%정도만 유지해야 합니다. 대부분의 회사는 80% 개발자에 의존하기 때문에 개발자가 1,000명이 넘는 회사나 10명이 안되는 회사나 똑같이 인적 Risk가 엄청나게 큽니다.

    이렇게 하지 않으면 개발자가 성장하기도 어려워집니다. 회사와 개발자에게 모두 손해입니다.

    스펙 작성의 힌트는 제 책을 참조하시기 바랍니다. 제일 좋은 방법은 미국 실리콘밸리의 SW회사에서 몇년 일해보는 것인데 그렇지 않다면 분석전문가와 같이 프로젝트를 하면서 실제로 스펙을 적어보는 겁니다.

    열정을 가지고 회사를 운영해나가는 모습이 매우 보기 좋습니다. 궁금한 것이 있으면 언제든지 연락주시기 바랍니다.

Peer Review의 방해꾼들

2009.04.02 23:10 by 전규현


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




Peer Review가 정말 중요하다고들 다들 생각할 것 같지만, 실상은 그렇지 않습니다.
Peer Review의 중요성을 알고 있는 사람은 정말 많은 경험과 깨달음을 얻은 사람이고 대부분은 Peer Review의 중요성을 모르거나 심지어는 노골적으로 또는 은연 중에 방해를 합니다.

Peer Review는 (이미 언급했지만), 소프트웨어의 결함을 줄이고 개발 비용과 시간을 절약하며, 개발자들 간의 정보와 지식을 공유하고, 개발자들을 성장시키며, 개발자들의 사기를 높여줍니다.

그런데, 결함을 줄이고, 비용과 시간을 절약하며, 지식을 공유하는 것을 싫어하는 개발자들이 의외로 꽤 많습니다. 공유를 통해서 자신만 알고 있는 지식이 빠져나가면 자신의 가치가 줄어들 것으로 생각하며 심각한 버그를 만들어서 자신만이 멋지게 해결하는 모습을 보고 싶어하고, 프로젝트의 일정을 항상 궁지로 몰아 넣고 자신이 이를 해결할 수 있는 유일한 사람인척 행동하는 많은 개발자들이 있습니다. 이러한 행동이 자신의 가치를 높여주고 자리를 보존해 준다고 생각합니다. 하지만 그 말로는 뻔하죠. 본인도 성장하지 못할 뿐더러 동료와 후배의 성장도 방해하고, 결국 실력은 부족한데 영향력만 유지하려고 하는 "정치꾼 개발자"로 전락하고 맙니다. 

회사들은 알고도 또는 모르고 이러한 개발자들에게 인질로 잡혀서 끌려다니곤 합니다.

Peer Review를 시행하면 이러한 개발자들의 방해에 부딪혀서 좌절하기 일쑤이며 이런 개발자들에게 동조한 관리자들도 방해자 노릇을 톡톡히 해냅니다. 프로젝트의 지연을 Peer Review의 탓으로 돌리기 일쑤이며 Peer Review의 성과를 평가절하 합니다. 또 영업부서가 고객이 Peer Review를 반대하기도 합니다.

이러한 방해꾼들을 극복할 의지가 회사에 없다면 Peer Review는 그림의 떡입니다. 즉 회사가 정말로 Peer Review의 필요성을 모르는 상태이거나 아직 이를 시행할 외적인 준비나 성숙도가 떨어진다고 볼 수 있습니다. 준비를 조금 더 해야겠죠? 

그럼 다음에는 Peer Review를 시행하기에 앞서서 준비가 되어야 할 것들에 대해서 알아보겠습니다. 

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

전규현 개발문화 Peer Review, 개발자, 공유, 리뷰, 문화, 방해, 성장

  1. Blog Icon
    ~_~

    아무런 문서화도 로직설명도 끝나지 않은채 버그리포트를 시키고 수정하라고 시키는 사람도 있다는거...

  2. 별의별 사람이 다 있죠.

  3. Blog Icon
    아름드리

    제가 있던 회사에도 자신이 만든 프로그램의 소스 코드를 암호화 수준까지 작성해서 아무도 안 보여주는 사람이 있더군요. 이런 사람 얘기는 웹을 통해서 간혹 봤지만 실제로 보니 대책이 안 서더군요.

  4. 아름드리님 반갑습니다.
    이런 개발자들을 어떻게 해야 하는지는 제 블로그의 여러 글들에서 언급을 해 놨습니다. ^^

Peer Review의 치명적인 유혹

2009.04.01 10:51 by 전규현


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



Peer Review는 익히 언급했다시피 가장 중요한 소프트웨어 개발 문화 중에 하나입니다.

그런데, Peer Review를 시행하다보면 경영층에서는 Peer Review를 평가에 이용하고 싶은 생각이 들게 마련입니다. Peer Review 시행자체를 권장하기 위해서 Peer Review 시행 여부를 관리자들의 평가 기준에 포함하는 것은 일리가 있지만, Peer Review의 내용을 평가에 반영하는 것은 자칫 부작용이 더 클 수도 있습니다.

평가에 반영 가능한 Peer Review 결과
  • Peer Review 실시가 잘 진행되고 있는지 관리자를 평가
  • 얼마나 많은 Peer Review에 참석해서 Peer Review에 기여를 했는지 개발자를 평가

평가에 반영하기 부적절한 Peer Review 결과
  • Peer Review에서 누가 결함을 많이 찾았나 평가에 긍정적으로 반영
  • Peer Review에서 발견된 결함의 수를 해당 산출물 작성자에게 부정적으로 반영
  • Peer Review 통계 데이터를 이용하여 포상 또는 제재

이처럼 Peer Review를 정착시키기 위한 활동은 좋으나, Peer Review 내용 및 그 통계를 관리의 목적이 아니고 평가와 상벌에 이용하면 통계는 왜곡되기 시작할 것이며 그 때부터는 통계도 의미가 없어지고, 직원들은 Peer Review를 피하게 될 것입니다.

Peer Review는 동료들간에 서로 같이 검토를 해 주는 것에 의의가 있습니다.

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

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

전규현 개발문화 KPI, Peer Review, 검토, 관리자, 동료, 리뷰, 상벌, 평가, 포상

  1. 문제는 대부분의 회사나 관리자가 '평가에 반영하기 부적절한 Peer Review 결과' 를 가지고 죽어라 평가항목을 만들어 대는 게 아닐까 싶습니다.
    등록한 버그 갯수 가지고 테스터 평가하려는 것처럼요...

  2. Shawn님 안녕하세요.
    KPI를 제대로 만드는 것이 얼마나 어려운 일인지 모른는 경영자나 관리자도 꽤 많습니다. 등록한 버그 수를 가지고 테스터를 평가하면 개발자와 짜고 버그를 많이 만들어내면 되겠네요. ^^ 이런 삽화도 본 적이 있습니다. 찾아낸 버그수대로 보너스를 지급하겠다고 하니 나는 오후에 스포츠카를 살 수 있다고 하더군요. ㅎㅎ

  3. 어휴, 그러게요. 생각만 해도 끔찍합니다. ㅠㅠ

  4. 반갑습니다. 최종욱님
    이런 경험이 있으신가보죠?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바