Heart’s Develop Inside

# Help yourself! programmer…

포스트 내용이 구구절절 공감이 된다.

프로그래머로 사회생활을 시작한 지 1년 반 정도 되었는데, 종종 코드들을 돌아보면 엄청난 양의 중복이 존재함을 깨닫는다.
하지만 그 놈의 ‘귀차니즘’이 뭔지, 퇴근이 뭔지…
최대한 시간을 줄이기 위해 소스를 통째로 찾아서 갖다 붙이는 작업을 하게 된다.
그 때 당시에는 라이브러리로 만드는 것보다 시간이 덜 걸린다. 하지만 그걸 여러 번 반복하게 되니 이 작업 자체가 만만하지 않음을 깨닫는다.
프로그램을 모두 뒤져가면서 소스 떼어내고, 컴파일 에러 나는지 확인하고, 컴파일 에러를 고치기 위해 또 소스를 뒤져서 붙이거나 필요없는 소스를 제거하고, 또 에러 확인하고…

입사때 부터 이걸 깨닫고 조금만 고생해 두었으면 지금쯤 라이브러리 조합만으로도 엄청난 코딩을 줄일 수 있었을텐데… 내일부터 시간 날때마다 정리를 해 둬야겠다.

라이브러리와는 조금 다른 이야기이지만, 비슷한 이야기를 하나 더…

대학교 연구실 교수님께서 자주 하시는 말씀이 있다.
“매크로 작업이 있으면, 손으로 할 때 걸리는 시간과 프로그램을 만드는 시간을 예상해 보고, 손으로 하는 게 빠르면 손으로 하고, 비슷하기라도 하면 프로그램을 만들어라.”

학생 때는 나도 매크로 작업이 필요할 때는 되도록이면 간단한 유틸리티라도 작성해서 사용했는데, 입사하고 나면서 점점 귀찮아지면서 ‘손으로 하고 말지’ 라는 생각이 앞서는 것 같다.
(물론 회사 입사 이후로도 몇 가지 만들긴 했는데, 엄청 귀찮아하면서 만들었다.)

그런데 작업을 하다 보면 매크로 작업은 한 번 하면 보통 나중에도 여러 번 하게 되는 것 같다.

그래서, 교수님 말씀에 개인적인 생각을 한 가지 더 추가해야 될 것 같다.
“두 번 이상 사용할 것 같다면 프로그램을 만들어라.”

정리하자면, 자신을 위해 이런 작업은 ‘귀차니즘’을 극복하고 긴 안목을 두고 해야 되지 않을까 싶다.
(생각해보니 역으로 생각하면 ‘귀차니즘’을 위하여 해야 되는 것일 수도 있네…)

1. 라이브러리화 할 수 있는 것들은 모두 라이브러리화 하고 API 스타일의 문서를 만들자. 그리고 추가되는 클래스를 잘 분류해서 라이브러리를 자주 업데이트하자.

2. 매크로 작업을 유틸리티로 작성하자.

라이브러리야 뭐 회사에서 사용하는 언어를 따라가면 되니…
리팩토링과 클래스 디자인, 디자인 패턴, 그리고 ‘귀차니즘’을 공부해야 할 것 같다.

매크로 작업은 C/C++로 코딩하기에는 좀 비효율적인 것 같고… 스크립트 언어를 하나 공부해보면 좋을 것 같다. 미뤄두고 있는 파이썬 언어를 시간날 때 마다 공부해보아야겠다.

공부할 게 무궁무진하구나…

고객사 담당자 분(QA 파트에서 일하신다)과 자사 솔루션(형상관리)에 대해 이야기를 하다 보니, 문득 이런 방향으로 주제가 옮겨지게 됐다.

“프로그래머의 실적 관리가 가능할까?”

형상관리가 가지는 통계 기능의 최종 목표는 팀 별, 혹은 개인 별 실적 관리일 것이다. 이는 형상관리에 국한된 것이 아니라 프로그래머가 활동하는 영역이라면 모두 고민하는 문제가 아닐까 생각한다. 그렇게 생각하는 이유는, 프로그래머는 수치화할 수 있는 무언가를 만들어내는 존재가 아니기 때문이다.

마케팅은 판매 실적이 평가에 대한 수치가 된다.
하지만 프로그래머는 직접 판매 실적을 올리는 존재도 아니며, 그가 만들어 낸 산출물에 대한 실적 평가는 결국 주관적으로 내릴 수 밖에 없다.

처음에는 소스 코드 라인 생산성이나 (영향분석을 거친)함수 생산성을 통해 객관적인 실적을 추정할 수 있지 않을까 하는 생각을 했었다. 하지만 곧 굉장히 위험한 생각이라는 결론에 도달할 수 있었다.
우선 악용의 소지가 존재한다. 한 라인에 쓸 수 있는 소스를 10라인에 걸쳐 쓴다거나 하는 방법이다. 쓸데 없이 라인 별로 주석을 다는 방법도 포함…
또한 실적을 위해 테스트를 등한시하고 무조건 생산부터 하고 볼 경향이 크다. (이 단점은 차후 QA를 통해 버그가 발견될 경우 원인 제공자를 찾아 페널티를 적용하는 방법이 있을 수 있겠다. 조금 잔인하군…)

무엇보다 궁극적인 문제는, 같은 로직이면 가독성을 해치지 않는 범위 내에서 간결하게 작성하는 것이 더 좋은 방법이라는 것이다. 즉, 라인 갯수나 함수의 갯수가 단순하게 많은 게 좋은 게 아니라는 것이다.

문서화로 평가하는 것 또한 소스 코드에 의한 평가와 같은 문제를 야기할 수 있다.

업무 처리 능력으로 평가하는 것은 평가자에 따라 다분히 주관적일 수 있다. 자신이 추정하는 필요 시간과 상사 혹은 매니저가 추정하는 필요 시간이 다를 것이기 때문이다. 자신이 경력이 모자라서 추정 능력이 떨어질 수도 있겠지만, 둘의 생산성에 대한 이념이 다름에 따를 수도 있다. 이럴 때는 상사의 추정이 무조건 옳다고는 할 수 없을 것이다.

이야기하면 이야기할 수록 우리의 생각은 ‘불가능하다’에 수렴하고 있었다.
어떻게 보면 업무 관련으로 시작한 이야기였지만 ‘결국 나의 생산성 평가는 상사 혹은 매니저 몫이군’ 이라고 생각하니 조금은 씁쓸하다.
객관적인 평가를 내릴 수 있는 참신한 방법이 개발되어, 프로그래머가 자신의 능력에 대한, 또는 성실성에 대한 제대로 된 대우를 받을 수 있기를 고대한다.

+ 현대카드 CF 패러디한 개발자 라이프 카툰

우습게도 내가 처음으로 이 만화를 접한 경로는 비개발자 지인을 통해서이다.
넥X에서 마케팅 하는 분인데, 이걸 메신저로 보내 주면서 ‘아~ 불쌍하다~’ 이러면서 놀린다. 어이상실.

내용은 얼추 맞는 것 같은데… 국내에서만…-_-
물론 모든 회사가 그렇지는 않을테니 난 그런 회사 찾아 들어가야겠다.

뭐? 그런데는 없다구?? 없으면 한국 뜨지 뭐… 영어공부부터 시작해야겠다.

ps. 이런 내용에 공감하는 프로그래머가 다수라는 것 자체가 국내 IT 개발자 시스템이 잘못되어도 한참 잘못된 것이리라.