요즘 저는 개발자로서 얼마나 오래, 즉 나이가 많아도 일할 수 있을지가 고민입니다. 오래 개발자를 하고 싶은 이유는 아무래도 하던 일이니 경력으로 인정받을 수 있고 나한테 맞는 일인것 같기도하고, 사실은 변화가 두려워서이기도 하겠지요. 저는 오래하려면 일단은 잘해야하지 않을까 생각합니다. 그럼 어떻게해야 잘할 수 있을까? 그게 이 질문의 핵심인것 같습니다. 전 2가지를 생각하면서 일합니다.

1. 자주 발생하는 문제들의 카테고리를 분류해서 통합하고 각 카테고리마다 범용적인 해결책을 개발한다.

2. 내가 알지못하는 문제를 해결하거나 알지못하는 지식을 갖춰야할때 가장 근본적인 부분부터 파고든다.

이 2가지 문장의 공통분모는 고민인것 같습니다. 혹은 생각이라고도 할 수 있을것 같습니다. 2가지 문장을 합친 결론은 “일할때마다 좀더 고민하고 좀더 생각하면서 일하자.”입니다. 고민이라는 단어를 넣어서 다시 적어보겠습니다.

1. 자꾸 비슷한 문제가 생기면 유사한 문제들이 다시는 발생하지않게 그냥 넘어가지말고 해결하자.

2. 뭔가 배울때는 그 내부까지 좀더 고민하고 생각해서 깊게 이해하자.

그런데 쓰다보니 더 중요한게 있는것 같습니다. 소통도 그만큼 중요할것 같습니다. 소통의 중요성은 뭐 굳이 말로할 필요가 없겠지요. 저는 소통이란 “상대방 눈을 보고 상대방이 원하는 정보를 상대방이 이해할 수 있게 전달하는 것”이라고 생각합니다.

1. 상대방을 존중하는 자세 (사실은 안존중하지만 속마음을 숨겨야할때도 있지요^^;)

2. 상대방의 필요를 이해

3. 상대방의 수준을 배려

제가 소통에서 중요시하는 3가지입니다.

이렇게 따지고보니 지식노동자는 수신뿐 아니라 제가에도 힘써야합니다. 수신은 자신을 성장시키는 것이고 제가는 주변 사람들과 어울리는 것이니까요. 그런데 수신과 제가는 이미 수천년전부터 모든 사람이 가져야할 자세라고 강조되어온 것입니다. 지식노동자라고 특별할게없이 일하면서 먹고사는 직업중 하나라는 것이 아닐까요? 그래서 저는 제가 생각하는 고민과 소통이 개발자의 태도가 아니라 모든 사람의 태도라고 생각합니다. 결론은 사람이 사는데 필요한 모든 지혜를 갖추는 것이 곧 개발자로서 성장하는 길이다.

좀더 명확하게 말하면 “좋은 사람이 곧 좋은 개발자이다”라는 주장을 하고싶습니다.

뜬금없이 이상한 글을 올린 저는 알티베이스에서 개발일을 하고있는 김기오입니다. 앞으로 간간이 개발에 관련된 글을 올리겠습니다. 하지만 개발보다 중요한게 사람이고 지식보다 중요한게 인격이라고 생각합니다. 생각만하고 정작 제 인격은 조악하지만요. 어쨌든 좋은 사람이 되고 싶은 개발자입니다.

감사합니다.

 안녕하세요.  머무는 여행입니다. 

오늘은 다음달 24일에 알티베이스가 참여하게 될 문화체육관광부가 주최하고 한국DB진흥원이 주관하는 ‘국산DBMS 경쟁력, 그들만의 DB노하우’ 세미나를 소개해드리고자 합니다.   외산 DBMS가 시장점유율의 대부분을 차지하고 있는 이 시대에 알티베이스를 비롯한 국산DBMS가 그 동안 얼마나 성장하고 발전했는지를 확인하실 수 있는 좋은 세미나라고 생각됩니다.

나중에, “지금 알고 있는 것을 그 때도 알았더라면” 하지 마시고, “아~~~ 내가 그 때 국산DBMS 선택해서 진작에 TCO절감할 걸~~~” 하지마시고^^ 이번에 국산DBMS를 더욱 잘 알아보는 계기를 마련하셨으면 합니다.

본 블로그는 하이퍼링크를 지원하지 않네요..ㅠㅡㅜ 그래서 아래의 [신청하기]에 링크되어 있는 URL을 촌스럽게 직접 적어봅니다.  좌악~~   http://www.dbguide.net/offline.db?cmd=seminar&educationFormUid=1&categoryUid=76

세미나 정보는 아래에서 확인하세요^^ (경품이 아주 굿이라는..)

 안녕하세요.  머무는여행입니다.   제가 ‘개발자 세상’ 메뉴에 글을 쓰게 되는 날도 다 있네요^^ 

저희 알티베이스 품질관리팀 김성재님의 특별 기고를 받았다고나 할까요? ㅎㅎ 사실은 다른 커뮤니티에 올리신 글을 보고 내용이 좋은 것 같아 퍼오고 싶다고 하니, 직접 새로 다듬어 주신 거랍니다.  성재님 넘 감사해요~~^^

그럼, 프로그래머의 준비물… 궁금하시죠?  이제 소개합니다.

——————————————————————————————————————————-

초등학교 시절에 연필을 안들고 가면 선생님이 늘 하던 말씀이 있다.  군인은 전쟁하는데 총을 들고 가는데 학생이 공부하는데 연필을 안들고 오면 어떡하냐?
그럼 프로그래머의 준비물은 무었일까요?  “컴파일러와 notepad 만 있으면 돼” 하는 하는 영웅들의 이야기가 아닙니다.
평범하고 우리 주변에 흔히 볼수 있는 프로그래머들을 위한 준비물을 알아 봅시다.

1장 개발 산출물 관리도구

개발시에 나오는 산출물을 관리하는 도구들을 알아봅니다.

1-1. 코드 관리툴

다른 말로는 형상관리툴이라고도 합니다.
간단하게 말하면 “우리가 작년에 코딩한 코드를 알고 있는 도구 입니다.”
코드 관리 툴을 사용하면 임요환이 마린 컨트롤 하듯이 코드를 컨트롤 할수 있습니다.

다른 사람과의 코드교환이나 코드 통합, 특정 시점에 발생한 버그 추적등을 간단히 할수 있습니다.
코드 관리툴은 간단한 코멘트를 저장할수 있지만 이것만으로는 부족하므로 다음에 설명한 버그관리툴과의 연동이 필수적입니다.

무엇을 사용할것인가? svn 추천합니다. 요즘 대부분 svn 을 사용하는듯 합니다.
또한 svn 은 커맨드 기반이므로 GUI 로 편리하게 쓸수 있는 도구를 사용합시다.
viewcc 등을 사용하면 웹에서 코드를 볼수 있는 기능을 제공합니다.

1-2. 버그 관리툴
예전에는 버그 관리툴이라고 불렀는데 요즘은 이슈관리툴이라고 합니다.

이슈는 버그보다 확장된 개념으로 기능추가나 고객이 제기한 버그가 아닌 문 제들까지 포함하는 개념입니다.
버그 관리툴에는 어떠한 논의가 있었고 어떻게 추적했으며 어떻게 수정했는지 를 기록합니다.
버그 관리툴을 도입하면 생산성을 저하시킨다라는 이유로 반발이 심합니다.
맞습니다 생산성이 저하됩니다. 하지만 버그 관리툴을 사용하면 시간이 지날 수록 빛을 발휘 합니다.
개떡이라는 단어가 있습니다. 우리 주변에서 흔히 볼수 있죠. 생각나십니까?
바로 당신이 보고 있는 코드죠.
개떡에도 삶의 이유가 있을진데 우리는 그것을 보고 같은 코드를 작성하면 안 되겠죠.
버그 관리툴은 신입교육에도 좋습니다. 신입 교육은 분명이 비용이 많이들고 그래서 경력같은 신입을 원하죠. 하지만 그런 사람은 없습니다.
경력자의 버그 추적 방법이나 수정 방법, 생각의 방식등이 버그 관리툴에 녹 아 있습니다. 신입은 그것을 읽기만해도 내공이 상승합니다.

무엇을 사용할것인가? 멘티스나 trac, 버그질라을 추천합니다.
코드 관리툴과의 연동방법을 제공하고 다양한 노하우가 녹아져 있습니다.
간단히 설명하면 svn ci -m “BUG-1000″ 을 수행하면 버그 관리툴의 BUG-1000 이란 게시물에서 제가 수정한 내용을 볼수가 있습니다.
버그의 히스토리까지 같이 볼수 있다는 장점이 있습니다.

1-3. 문서 관리툴
프로그램 개발을 하게 되면 코드와 버그만 생성해 내지 않습니다. 문서도 만 들어 내죠. 그래서 문서 관리툴이 필요합니다.
일반적으로 2가지 방법을 사용합니다.
첫째는 문서도 코드처럼 관리하는 방법입니다. 코드 관리툴에 저장을 하고 버 그 관리툴로 히스토리를 관리하는 방법입니다.
강력한 문서 편집툴을 사용할수 있는 장점이 있지만 검색이 안되고 버젼간 변 경사항을 보기 힘들다는 단점이 있습니다.
둘째는 wiki 를 이용하는 방법입니다. wiki 를 구성하여 접근성이 편리하게 문서를 생성하는 방법입니다.
wiki 문법을 익혀야 하고 편집이 강력하지 못하지만 접근성이 편리하고 문서 히스토리 관리가 편리하다는 장점이 있습니다.

2장 개발 시스템

1장에서는 개발과정에서 나오는 산출물에 대해서 설명했다면 2장은 개발하는 행위에 관한 내용입니다.

2-1. 코딩 규칙

우리 주변에서 흔히 볼수 있는 그런 프로그래머들이 이해할수 있는 산출물을 만들도록 노력해야 합니다.
그래서 규칙을 정하고 일정 시간을 들여서 규칙을 가르칩니다. 이것은 코드뿐 만이 아니라 모든 산출물에 대해서 적용되어야 합니다.
이러한 규칙을 통해서 모든 개발자들이 한눈에 산출물을 이해하고 바로 업무 에 투입한다는것은 환상에 가깝습니다.
하지만 그 기간을 충분히 단축시킬수 있습니다.

2-2. 리뷰 시스템
산출물를 수정하고 나서 다른 개발자와 검토해야 합니다. 산출물의 수정사항 을 보면서 토론을 하는것입니다.
참여자는 산출물의 수정량이나 중요도에 차등 적용하는것이 좋습니다. 코드 1 줄 고치는데 모든 팀원을 모으는것은 잘못된 것이죠 리뷰는 잘못하면 형식적으로 흐르기 쉽습니다. 관리자의 의지가 중요합니다.

2-3. 빌드 검증 시스템
개발자가 확인하고 코드를 반영해도 파일을 몇개 빼먹는다던가 하는 실수는
자주 일어납니다.
따라서 코드 관리도구에 코드가 반영될때마다 컴파일이 제대로 되었는지 확인 을 하는 시스템을 구축하면 좋습니다.
추가적으로 간결한 테스트를 자동으로 진행하면 좋습니다.
예를 들면 컴파일은 잘되었지만 실행이 안될수 있습니다. 실행은 되지만 아주 기본적인 기능이 동작하지 않을수 있습니다.
코드 관리도구의 기능을 사용하면 자동으로 컴파일하고 테스트를 수행하도록
할수 있습니다.