조금 덜 피곤해지기 위한 몸부림.
에 이어…조금 다른 관점..에서 문득 생각난 것들을 적어보려고 합니다. 유행처럼 스쳐지나갔던 XP도 떠오르고 요즘 읽고 있는 장자도 생각나고, 이전에 참 충격적으로 읽은 유목민이 본 세계사의 내용도 겹쳐지나갑니다.
지금 홍대 탐엔탐스에 앉아 있는데 옆자리에 앉은 남여(커플은 아닌듯)의 이야기도 귀에 스칩니다.(한마디로 제 정신이 아니란 이야기입니다.)
IT에 대해, 좀 더 정확히 말하면 컴퓨터 프로그래머, 혹은 그 유사 직종을 달고 일하는 그 분들 말입니다. 열악한 환경에서 밤샘을 밥먹듯이 하고, 하루종일 컴퓨터를 보면서 키보드를 두드리며 남들이 이해하지 못할 그 무언가를 만들어내며 희열에 찬 표정을 지어내는 여러분들… 그러다 보면 어느세 나이는 들어가고 체형은 ET처럼 되고 연애도 못해보고 여기서 내가 뭘 하고 있나 라는 생각을 하시는 분들.
우린 불평할 만한 것들이 많습니다. 말안 통하는 기획자, 말도 안되는 일정을 강요하는 PM, 잠깐 바꾸면 되요 라고 기껏 마춰둔 UI 뒤집는 디자이너, 야근도 벅찬데 아침일찍 출근해서 자리지키라는 사장님, 무조건 빨리 나와야 한다고 맨날와서 눈치주고 윽박지르는 마케터 등등등… 구글에서 검색하면 수십페이지 뜨는 그런 불평거리들 말고.. 조금 생각을 바꿔 이야기 해보았으면 좋겠습니다. 기왕에 컨설턴트란 직종도 달고 기분좋은 트랙백도 받고, 글도 여기까지 왔으니 여러분께 뭔가 제안해 보려고 합니다. 컨설턴트에게 제안이란게 늘 그럿듯 선택은 여러분의 몫입니다.
뭐 대단한 제안을 하나? 라고 생각하고 여기까지 부질없는 글 읽어주신 분들께 죄송하지만, 1분당 1000타 코딩할 수 있는 비법도, 프로그래밍 설계 스파르타 6주과정 같은 것도 아닙니다. 그저 조금 덜 피곤해지기 위한 몸부림(수 많은 다른 분들과 마찬가지로..)을 쳐 본 경험에서 몇가지 권고드리는 것 뿐입니다. 시간이 시간(새벽 4시 홍대는 정말 불야성을 방불케 하는군요…)이니 만큼 생각나는데로(좀 난잡하게) 몇가지 제안드리겠습니다.
1. Pair Programming을 하십시요. 작성하신 Logic이 잘 동작하지 않으십니까? 아무리 봐도 풀리지 않으십니까? 간단한 문법오류 일수도 있고, 치명적인 Logic상의 문제 일 수도 있습니다. 그런데 잘..안보이시죠?.. 부끄러워 마시고 동료분에게 같이 Code를 보자고 하십시요. 설사 여러분의 동료가 여러분보다 경력이 일천할 지라도 그렇게 해보시길 권합니다. 저는 Programming을 거의 처음 접하는 분과 서로 Code Review를 하다 제가 처음부터 잘 못 인식하고 생각했던 것들을 발견한 적이 자주 있습니다.
2. 기록을 하시고 그것을 남기십시요. 형상관리를 도입하셔도 좋고, 그냥 아이디어 스케치 수준에서 끄적거리던 것들도 좋습니다. 여러분이 작업한 것들은 모두 기록으로 남기는 습관을 가지시는 것이 좋습니다. 남들에게 나 이만큼 일했어! 하고 보여주기에도 용이하고, 어떻게 일했는가 스스로를 돌아보는데도 큰 도움이 됩니다. 사실 한번 짠 Code 다시보는 일 잘 안합니다.(맨날보는 건데 걸 왜 또 보나 하는 생각들죠!) 그런데 형상관리의 로그나 끄적거렸던 문서들은 한번 보게 됩니다. 그런 싸이클을 억지로라도 반복하다 보면 어느사이엔가 Code 작성에 대한 스스로의 생각이나 Logic을 짜는 요령등에 대해 더 생각하고 있는 스스로를 발견 하실 수 있을 겁니다.
3. 추산하십시요. 기획 회의나 프로젝트 의뢰를 받을 때나 버그 수정 지시를 받을 때나 머리속으로 대략적인 작업 범위를 정하시고 필요한 것들을 Check List화 해보시고(하시다 보면 이것도 Coding과 유사한 작업이라고 느끼실 겁니다..) 그런것들을 메모지에라도 끄적끄적 거려 봅니다. 필경 나중에 그 끄적 거린 메모가 큰 도움이 되실 겁니다. 그리고 함부로 일정이나 결과에 대해서 얼마쯤 걸리겠다라고 말하는 습관도 어느정도 줄이실 수 있으리라 생각됩니다.
4. 다같이 회의하십시요. 회의라고 해서 크게 자리 잡아놓고 관련자 전원 다 불러서 프로그램 구조에 대해서 일장연설을 하거나하는 그런 회의(다들 주무시죠..)말고, PM부터 가급적이면 같이 일하면서 부딛히게 될 모든 사람들과 같이 작업하게 될 부분들 그리고 만들어질 Software 전체에 대해서 틈틈히 이야기하고 토론하고 Fact들을 공유하십시요.(그런거 안하는 사람도 있냐구요?..있습니다..) 그리고 꼭 상대방의 이야기를 한번씩 들어주십시요. 일방적인 이야기를 할 때나 회의를 할 때 보다 상대방이 훨씬 더 이쪽의 말에 귀를 기울일 겁니다.
5. 영원한 것은 없습니다. 완벽한 기획서, 여러분이 짜놓은 완벽한 Logic, 변경되면 큰일 나는 ERD, 목숨걸고 지켜야 하는 일정. 그런건 현실속에 없습니다.(그 모든걸 강요하는 회사와 사장님 마저도 영원하지 않죠?) 사람은 실수를 하는 동물이고, 그런 사람들이 모여서 Software를 만들고 각 Process들을 진행하고 각자의 업무를 합니다. 모든것은 바뀔 수 있다 라는 것을 항상 염두에 두시고 개발 업무에 임하시면, 갑님의 말도 안되는 요구에 조금은 더 유연하게 반응 하실 수 있고, 기획자가 ‘죄송한데 이거 좀 바꿔야 될 것 같아요’라는 말이 조금 더 이해되실 수 있습니다.
몇가지 주저리주저리 이야기를 드렸지만, 잘하시는 분들은 이미 잘 하시고 계시고, 어떤 이유에서든 잘 안되시는 분들은 뭔가 잘 안되고 계십니다. 악순환의 고리는 지금 여기서 내가 하나라도 끊지 않으면 반복될 뿐입니다.
요즘 개발쪽 일하시는 분들과 이야기를 하다 보면 리펙토링이나 코드 컴플리트도 중요하지만, ‘IT인으로써 살아가기 - SI편’, 이런거라도 하나 있었으면 좋겠다 싶은 마음입니다.
자. 잘 생각해봅시다. 여러분을 힘들게 하는게 잘 풀리지 않는 Code나 귀찮은 문서화 작업인가요? 아니면 직장동료, 상사, 갑(혹은 을) 업체인가요? 전자라면 스스로 조금 더 노력하면 실마리가 보이겠지만, 후자의 경우는 어떻게 하시겠습니까? 잘 생각해보면 실 생활에서는 후자의 경우가 더 많을 것 이라고 생각합니다.(아니라구요? 그럼 좀 더 노력하셔야죠! ^^), 직업이 Programmer이다 보니 모든 문제를 Programmer의 입장에서 생각하고 해결하려는 성향이 이쪽 종사자 분들에게 있는 것 같습니다. Programmer이기 이전에 우린 ‘사람’인데 종종 망각하는 것 같습니다. Coder다 Programmer다 Architect다 하는 것들은 다른 분들께 큰 의미(그분들껜 우리가 그냥 Computer에 익숙한 날 도와주는 사람일 뿐입니다.)가 있는건 아니죠. 혹여나 스스로를 Code를 벹어내는 Machine이라고 생각하고 계신건 아니신지요?
이만 줄입니다. 편안한 밤 되십시요.