watist's blog ... I am interested and passionate in building software.

개발직군에는 개발자를 도와주는 TA(technical assistant)가 있습니다. 기술 도우미(?) 정도로 풀어 설명할 수 있는 것으로 개발에 있어 중요한 기술적 이슈가 발생했을 때 개발자를 도와 문제를 해결하는 역활입니다. 전 이와 비슷하게 DA(document assistant)가 있으면 좋겠다고 생각합니다. 문서 도우미로 코드를 문서로 전환해 주는 역활이죠. 프로그램은 코드로 표현됩니다. 하지만, 코드를 분석하는 것은 쉽지 않은 일이고, 프로그램의 작동을 이해하고 있어야 하는 기획자에겐 많이 어려운 일이죠. 따라서 많은 경우 문서화 작업을 진행합니다. 하지만, 아쉽게도 여러가지 이유로 문서는 적절하게 유지 되지 못하는 경우가 발생합니다. 아예 갱신이 안 되거나, 갱신이 되더라도 작성자가 바뀌고,..

네일은 낙천적 기억상실증이란 병에 걸여 있어요. 메멘토의 주인공 샘처럼 몇분에 한번씩 초기화되는 기억은 아니지만, 네일은 기억력이 그리 좋지 않고, 기억할 수 있는 것이 많지 않아요. 하지만, 네일은 잊은 게 있어도 슬프거나 걱정하지 않아요. 보통 중요한 것은 적어 두는 습관이 있고, 기억나지 않는다면 별로 중요하지 않은 거라 생각하죠. 적어 둔 기억조차 잃어버리거나, 뭔가를 적은 기억은 있지만 어디에 적었는지를 기억나지 않아도 그냥 그러려니 하죠. 중요한 거라면 잃어 버릴리가 없으니까요!! 네일은 그렇게 낙천적 기억상실증에 걸려 있어요.

세상 사람들이 같은 길을 가든, 다른 길을 가든 결국엔 모두 다른 길을 가고 있는 거야. 세상엔 세상 사람들 수만큼의 길이 존재하는 거야. 그 누구도 네일의 길을 헤치거나 방해할 수는 없는 거야. 그건 오로지 네일만의 것이니까...

요즘 공직이 개편(?)되면서 좋은 부서와 나쁜 부서로 갈라지게 된 팀원들이 옮겨갈 부서를 제비뽑기로 뽑았다는 기사에 어이없던 적이 있다. 근데 생각해 보면 이런 일은 우리 주변에서도 매일, 매일 생기고 있다. 사내 업무를 처리하는 것에 있어 담당자를 임의로 지정하거나, 간단한 업무 처리를 위해 주말 출근이 필요한 경우 제비뽑기를 한다거나 말이다. 간단한 처리이건, 아직 담당자가 제대로 배정되지 않은 업무이던 간에 이런 식의 운영은 직원들에게 업무에 대한 책임의식보다 스트레스만 준다. 정말 재수없어 걸렸다는 느낌말이다. 합리적인 이유없는 명령이나, 극단적인 제비뽑기와 같은 형태가 사라지려면 업무에 대한 보상이 있어야 한다. 업무 처리에 대한 스스로의 자부심이든, 담당자가 되었다는 책임감이든, 주말 출근에 ..

추가 개발이나 오류 수정을 위해 코드을 수정하다 보면 참 난감한 경우가 있다. 배열에 항목을 추가하는데, 개념상으론 중간에 끼워 넣어야 하지만 문제가 발생하진 않을까 싶어 마지막에 넣곤 한다. 혹시 나중에 중간이 아닌 끝에 추가한 이유가 궁금할까봐 친절하지만 불필요한 주석을 달고 말이다. 코드는 그렇게 개념상으로 정리되지 않은 코드와 불필요하고 번잡한 주석으로 지저분해 진다. 코드를 수정할 때, 코드를 정리하고 싶을 때 겪는 어려움은 이것 뿐만이 아닐 것이다. 이런 경우라도 대규모(!!) 테스트가 작업 후에 계획되어 있다면 이런 저런 시도로 소스를 정리한다. 결국 해법은, 필요한 것은 테스트이다. 전에 테스트 주도 개발(TDD) 시연을 잠시 본 적이 있다. 30분 정도의 데모에서 발표자는 요구사항에 맞는..

Case 1. 20MD의 작업이 진행된다. 오픈은 꼭 20일 후에 완료해야 하는 작업이다. 개인별로 하루중의 40%가 신규 개발에 투입된다고 판단되어 20MD를 0.4로 나눈다. 혼자 하면 50일이 걸린다는 예상. 3명이서 17일만에 완료하도록 개발자를 배정한다. Case 2. 30MD의 작업이 진행된다. 오픈은 꼭 10일 후에 완료해야 하는 작업이다. 10일 후에 완료하기 위해 작업 분량을 조절한다. 20MD가 남았다. 10일 후에 완료한다고 보고 하기 위해 개발자에게 10MD만에 하라고 명령한다.(혹은 설득한다??) --------------------------------------- Case1의 개발자는 행복하다. 일을 제시간에, 정확한 서비스로 완료하기 위해 열심히다. 하루의 60%는 시존 서비..

0. 나눠서 정복하라 - 프로젝트 관리의 첫번째 규칙 1. 프로세스 정립 - 프로젝트 관리의 두번째 규칙 2. 시나리오 작성 - 프로젝트 관리의 세번째 규칙 3. 공통 요소 정리 - 프로젝트 관리의 네번째 규칙 수정이 빈번하고, 하나의 수정이 여러 곳의 수정을 연달이 일으키는 경우, 이런 수정 작업을 지원하는 툴을 꼭 갖추고 있어야 한다. 이슈와 소스 관리, 도움말 생성 툴을 흔히 접할 수 있는 이유는 이러한 요구 사항과 소스, 그리고 도움말의 경우 수정이 빈번하고, 하나의 수정 사항이 여러 곳에 영향을 끼치기때문이다. 툴을 사용하는 것은 개발과 관리를 용이하게 하고, 작업 중의 문제 발생의 여지를 줄인다. SP의 템플릿을 일괄 변경해야하는 작업이 생겼을 때 수천개의 SP를 수동으로 처리할 것인지, 자동..

네일이 바다가에 가면 반기는 친구들이 있어요. 서해 앞바다에 일몰을 보러 갈때도, 부산에서 제주도 여행을 떠나는 중에도, 일본에서 섬과 섬 사이를 이동할 때에도 갈매기 친구들이 반갑게 맞아 줍니다. 네일은 이런 친구들에게 새우깡을 대접한답니다.

C : 고민이네요. 집에 충실하지 못 하고, 회사에서도 겉도는 것 같고 말이죠. 어느 하나에도 집중하지 못 하고, 양쪽 모두를 못 하고 있는 것은 아닌지 말이에요. J : 양쪽 다 모두 잘 한다면 가장 좋겠지만, 그렇지 못할 수도 있지. 둘 다 인생에 있어 중요하기에 양쪽의 조화와 균형이 필요하지. 하지만, 정말 둘 중의 하나를 선택해야 하는 상황이라면 이걸 생각해 보면 어때? 가정때문에 회사에 다니는지, 회사때문에 가정을 갖은 것인지 말이야. C : 흠... 그러네요. 역시 생각이 많아서 그런걸까요?? 일단 저에게 있는 선택지부터 챙겨봐야겠네요. 선택지가 얼마나 있는지 걱정이 앞서지만, 지금 상황을 타파하기 위해 당당히 맞서야겠죠? 짧게 생각하고 많이 행동해야겠어요^^ 감사합니다.

0. 나눠서 정복하라 - 프로젝트 관리의 첫번째 규칙 1. 프로세스 정립 - 프로젝트 관리의 두번째 규칙 2. 시나리오 작성 - 프로젝트 관리의 세번째 규칙 프로젝트와 관련된 모든 항목은 관리되어야 한다. 단어는 단어 사전으로 정리하고, 처리 흐름과 기능은 프로세스로 정리한다. 디자인과 소스도 정리되어 관리된다. 그리고 이 모든 요소에 대한 데이타, 메타 데이타를 생성하고, 관리한다. 메타 데이타의 1) 항목을 정리하고, 2) 정리된 요소를 통합한다. 통합은 각 영역에서 공통인 요소를 찾아 합치고, 비공통인 항목들을 최대한 공통으로 흡수하는 작업이다. 단어의 사용에서, 처리 흐름과 기능 상에, 디자인적인, 코드적인 측면에서 공통 부분을 찾아낸다. 디자인은 공통 디자인 템플릿으로, 소소도 공통인 부분을 공..