P-Camp 그 두번째 만남 – 서로의 입장을 이해하고 존중하자

두번째 P-Camp 행사가 10월10일 코엑스 컨퍼런스 센터에서 개최됐다. P-Camp란 행사도 낯설고, 주로 토론으로 진행된다고 되어 있어서 토론에 서툰 나로서는 조금 망설여지기도 했지만 요즘 TDD에 관심이 많아서 과감히 신청을 했다. 선착순 300명이 정원이었는데 이미 300명이 차서 대기로 신청을 했는데 신청취소가 좀 있었서 참석할 수 있었다.
 
토론은 다음 이슈를 가지고 소그룹을 정해서 이루어졌다.
1. 웹 환경에서의 테스트
2. Agile 개발 방법론에서의 S/W 테스팅
3. 개발자와 테스터의 효율적이면서 인간적인 관계
4. 게임 산업에서의 자동화 테스팅
5. 국내 S/W 테스터들의 현재 주소와 앞으로의 위치
6. DB컨설턴트들의 경험담
7. 온라인게임에서의 테스트
8. 웹어플리케이션의 테스팅 자동화 방법
9. 임베디드시스템의 테스트
10. 테스트가 제대로 수행될 수 있는 기업 문화
11. 테스트의 중요성을 인식하고 잘 실행되고 있는 사례
12. 패키지 솔루션 기획과 테스트
13. 프로젝트 매니지먼트에서의 리스크 관리
14. 효율적인 교육과 여가활용 방안
15. Agile 개발팀에서의 테스팅의 단계와 적용사례
16. SI업체 속의 애자일문화
17. TDD로 개발을 하였을 때의 이점이 어느 정도 되는가
18. TDD의 실용 적용 방법과 그 과정의 어려운 점

난 8번 “웹어플리케이션의 테스팅 자동화 방법”을 선택했다. 18번을 선택하고 싶었지만 이게 토론인지라 TDD에 대해 아직 얘기할게 아무것도 없기에 마냥 들을 수만은 없어서 그래도 가장 많이 접하는 웹어플리케이션 관련 주제를 택했다.

사용자 삽입 이미지

우리조는 개발자와 QA 테스터 분들로 구성이 됐다. 처음에는 좀 서먹서먹 했지만 좀 지나니깐 많은 얘기들이 오고갔다. 자동화 툴이 어떤게 있으며, 각각의 장단점. 그리고, 원론적으로 자동화 툴이 왜 필요하냐 등….  역시나 서로 처한 입장이 많이 틀리고, 서로 그 입장을 이해하기 위해서는 많은 커뮤니케이션이 필요하다는 걸 다시 한번 절실하게 느꼈다.

회사에 급한일이 있어서 100분으로 예정된 토론을 마치지 못하고 중간에 나오게 되서 좀 아쉬웠다. 다음 DevNight이나 오픈마루 1st DevDay처럼 개발자가 참여하는 행사에만 참석하다가 다양한 도메인에서 일을 하는 분들을 만날수 있어서 좋았고, 처음 접한 토론 문화에 좀 어색하긴 하지만 괜찮은 경험이었다.

더 나은 프로그래밍을 위한 제언

요즘 “대한민국 개발자 희망보고서”를 읽고 있다. 현장의 얘기가 체계적으로 정리된 느낌과 함께  평소에 알고 있으면서도 실천하지 못하는 부분에 대해 내 자신을 다시 한번 일깨워 주고 있다. 그 중 코딩에 관한 가장 기본적인 얘기가 있어서 인용한다.


더 나은 프로그래밍을 위한 제언


제발 줄 좀 맞추자
프로그래밍을 잘 하는 사람과 그렇지 못한 사람의 차이는 바로 줄 간격을 맞춰서 프로그램을 짜느냐에 달려 있다고 나는 과감히 주장한다. 왜냐하면 그 동안 수많은 개발자를 보아왔지만 줄을 제대로 맞추지 않고 프로그램을 제대로 짜는 사람은 본 적이 없기 때문이다. 보기 좋은 코드가 디버깅하기 좋다. 제발 기본에 먼저 충실하자. 알고리즘과 자료구조에 대한 이해는 기본이다. 그런 다음에 기교를 발휘해도 늦지 않는다.

백문이 불여일타
“프로그래머가 되는 가장 좋은 방법은 프로그램을 작성해보고, 다른 사람이 작성한 훌륭한 프로그램을 공부하는 것이다.”
훌륭한 작가 중에서 책을 많이 읽지 않은 사람을 보았는가? 마찬가지로 좋은 프로그램을 만들기 위해서는 좋은 프로그램을 많이 보아야 한다. 무에서 만들어지는 것은 아무것도 없다. 책에 있는 소스나 공개 소스를 스스로 분석해보자. 그러나 이보다 더 좋은 방법은 직접 짜보는 것이다. 직접 짜보는 것만큼 훌륭하게 배우는 방법은 없다.

선설계 후코딩
항상 프로그래밍을 하기 전에 선설계 후코딩하는 습관을 들여야 한다. 생각하고 계획하는 프로그래밍을 하라는 말이다. 프로그래밍을 하다가 막히는 부분에 가서야 생각하는 것은 좋지 않은 습관이다. 프로그래밍 시간이 배로들뿐더러 수정에 의해 또 다른 문제가 야기될 개연성이 크다. 계획을 하되 머리속으로만 하지 말고 문서로 작성하여 기억이 유실되지 않도록 해야 한다.

친절한 주석씨
주석은 습관이다. 주석은 타인에 대한 배려다. 친절한 프로그래머가 되는 지름길은 주석을 잘 다는 것이다. 시간이 날 때 주석을 다는 것이 아니다. 주석은 프로그래밍의 일부분이라는 인식을 갖고 실천해야 한다. 주석을 달지 않으면 본인도 시간이 지나면 잘 기억이 나지 않는다.

3종 언어 세트
나의 경험으로 볼 때 프로그래밍 언어는 최소한 3가지는 익혀야 한다. 가급적이면 소프트웨어 프레임워크에 맞는 언어를 각각 익히는 것이 좋다. Client/Server, .NET, J2EE 프레임워크에 맞는 Powerbuilder, Java, C#을 예로 들 수 있다. 그렇지만 이 세가지 중에서 반드시 자신의 전공부야는 있어야 한다. 하나의 언어를 배우더라도 다른 언어에서 금세 응용할 수 있도록 충분히 이해해야 한다.

나만의 테크노트
자신만의 노하우를 반드시 정리하라. 가장 큰 재산이 된다. 일전에 프로젝트를 하면서 나만의 테크노트를 한 권씩 만들어 정리한 적이 있었는데 매우 유용했다. 그렇게 습득한 지식은 책에도 잘 나와 있지 않는다. 기록을 하지 않고 다시 복기하려면 엄청한 시간과 노력이 또 다시 요구된다. 테크 노트를 정리하는 일은 시행착오를 줄일 수 있도록 해 줄 뿐만 아니라 전문가로 가는 노하우를 하나씩 쌓아가는 기쁨도 느끼게 된다. Taeyo ASP & .NET 웹사이트가 성장한 배경을 살펴보라. 내일 당장 그대만의  테크노트를 한 권 장만하라.

코딩이 뭐길래
프로그래머는 절대 코딩만 하는 사람이 아니라고 누차 강조했다. 코딩 지상주의를 절대 경계하라. 어느 정도 코딩 실력이 올라가면 데이터베이스, 아키텍쳐 등의 유사분야의 영역에 대한 지식을 넓혀라. 때론 일반적인 지식도 필요하다. 큰 그림을 그릴 수 있어야 한다. 설상 프로그래머로 자신의 경력개발경로를 설계한다 하더라도 다른 분야에 대한 학습은 꼭 필요하다.

개발자의 길

요즘 여러가지로 고민이 많다.

나는 개발자인가? 아님 코더인가?

내 개발자의 수명은 언제까지일까? 요즘 들어 부쩍는 버그 및 개발시간.. 난 계속 개발을 할 수 있는것일까? 아님 빨리 관리자나 다른 일을 찾아봐야 하는 걸까?

나는 업무처리를 잘 하고 있는가? 항상 들어왔던 말처럼 혼자 일을 다 싸안고 있는건 아닌가?

개발자의 업무처리 스타일에 대한 글이 있길래 퍼왔다.



개발자들은 문제의 크고 작음에 상관없이 항상 컴퓨팅이 필요한 여러가지 문제에 직면해 있고, 문제를 해결하기 위한 다양한 솔루션들을 제시하고 검토하고 구현해야 한다.

그러나, 문제를 대하고 해결함에 있어 모든 개발자들이 다 동일한 방식과 태도를 가지는 것은 아니다. 주변의 몇몇 개발자분들만 봐도 실제적인 문제를 다룸에 있어 참으로 다양한 방법과 방식을 사용하고 있다는 것을 알 수 있었다.



[그림1] “몰개발”님 – 문제에 대한 지속적인 관심과 공통 이슈에 대한 현명한(?) 접근 방식의 소유자


폭주하는 정보와 요청들 속에서 자신과 관련된 문제에 대해 지속적으로 관심을 갖고 이를 재빨리 파악하여 신속히 영향도를 분석해낼 수 있는 능력은 실제 필드에서는 굉장히 유용한 방식이라고 생각한다.


대개는 자신과 관련없는 일이거니 생각하고는 놓치거나 잊어버려 뒤늦게 이를 수습하기 위해 두, 세 배 더 고생해야 하는 경우가 부지기수니까..



[그림2] “플랫폼”님 – 복잡한 문제에 대한 단순 명료(?)한 솔루션 프로바이더


복잡한 문제를 단순 명료하게 해결할 수 있는 솔루션을 찾을 수만 있다면 그것이야말로 최고의 솔루션이 아니고 무엇이겠는가?

“뛰어난 것은 단순하다”는 말은 진정 문제 해결을 위한 기본지침일 것이다. 다만, 문제를 단순화해야지…해결책만 단순화하는 우를 범해서는 OTL 이다.
(“플랫폼”님이 그렇다는 얘기는 아니고…^^;)



[그림3] “마베왕”님 – 각각의 문제를 가장 잘 처리할 수 있는 사람들을 매쉬업(?) 하라!


누군가가 특정 분야에 일가견이 있어 해당 문제에 대해 최적의 솔루션을 제시할 수 있다고 확신하면 그런 사람들을 매쉬업(?)해서 전체적인 문제를 해결하는 것도 훌륭한 방법이라고 생각한다.


얼마나 많은 개발자들이 그 알량한 자존심을 지키기 위해 다른 사람이 훨씬 더 잘 할 수 있는 일을 본인이 직접 개고생해서 구현하고는 형편없는 퀄리티에 좌절하고 깨지고 했었던가? -_ -;;;


선택과 집중.
다양하고 복잡하고 문제를 해결하기 위해서는 반드시 필요한 결정일 것이다.

최근의 개발 트렌드인 프레임워크와 라이브러리를 도입하여 개발 생산성을 높이는 방식도 결국 같은 맥락이라고 볼 수 있겠다.


다만, 매쉬업을 해야지 떠넘기기를 하면 역시 OTL…


(절대 “마베왕”님이 그렇다는 얘기는 아니다. 칼 맞을라…=_ =;;; )



[그림4] “삽질왕”군 – 문제와 해결을 위해 쌓인 스트레스…이렇게라도 풀어줘야지…


이렇게 다양한 접근 방식과 솔루션을 통해 문제를 해결했다고 하더라도… 결국 문제는 문제라는 생각이 든다.


문제는 골치 아프다. 해결됐다고 하더라도 그 사이에 쌓인 스트레스는 어쩌란 말인가?


그럴 땐 역시…궁시렁거리는 게 쵝오가 아닐까? ^^;
(실상은 쵝오가 아니라 유일한 위안거리라는 게 문제긴 하지만… 문제다, 문제야…=_ =;;;)


출처: http://www.cyworld.com/cizix/106597