나는 이렇게 화풀이 했습니다.
개발자 일을 하다보면 정말로 짜증을 샘솟게 만드는 일이 종종 있는데요. 저만 그런건 아니고 다른 개발자들도 겪는 문제들이 있어요. 주로 기획단계에서 문제있는 기획을 짜서 아무 죄없는 개발자들만 고생하는 케이스가 대부분인데요. 외주개발일을 하다보면 이런 경우를 종종 접하게됩니다. 클라이언트쪽도 본인들이 뭘 만들고 싶은지 모르는 경우가 많아서 다 만들고 나면 기획내용이 바뀌고 사양이 바뀌는 일이 그냥 빈번하게 일어나요. 물론 외주업체라고 해서 다 그런것은 아니고 계약 내용에 따라서 이런일이 안생기는 경우도 있어요. 하지만 제가 처음 외주개발업체에서 일을 했을 때는 그렇지 않았어요. 급하다고 해서 급하게 만들어 주면 다음날 기획내용 바꼇다고 다시만들라고 하는데 이런 일도 한두번이면 이해를 하겠는데 두세번 반복되면 입에 마우스를 박아버리고 싶은 충동이 불끈불끈 일어나요. 하지만 을이 무슨 힘이 있겠어요. 그냥 클라이언트가 하라면 해야죠. 그럼 내일 다시 수정할 걸 알면서 개발을 합니다. 이게 여간 짜증나는일이 아니에요. 그리고 이 스트레스가 극도에 다다르면 건강을 해칠것도 알기에 개발자들은 각자 나름대로 스트레스 해소법도 알고 있어야 하구요. 저 역시도 이런생활을 좀 했는데 어느날 무슨 복수?를 해주고 싶다는 생각이 들더라구요. 그래서 조금씩 저만의 복수하는 법을 만들어가기 시작했습니다. 오늘 포스팅은 개발자 괴롭히는 클라이언트에게 저만의 화풀이하는 방법을 알려드리는 포스팅이에요. 참고로 지금은 아니지만 이전에 외주개발을 했을시 팀이 아닌 개인으로 모든 개발을 진행했고 클라이언트쪽도 개발에 관해서는 1도 모르는 사람들이여서 가능했던 화풀이법이에요. 팀으로 개발을 하고 있고 코드리뷰를하는 회사에서는 적용할 수 없다는점 양해부탁드립니다.
먼저 앞서 말씀 드렸다시피 클라이언트는 개발을 1도 모르는 사람들이여서 오직 결과물만으로 판단하는 사람들이고 코드리뷰도 못하는 상황이라는 전제에서 제가 했던 화풀이 방법은 코딩시에 대량의 편지를 남기는 방법입니다. 클라이언트가 정말 짜증나는 사람이라면 Html에 편지를 남기면 더욱 좋은 효과를 볼수 있어요. 이 화풀이 방법의 장점으로는 코드의 양이 길어지고 보기 어려워진다는 점. 파일의 사이즈가 늘어나서 로딩시간에 아주아주 조금의 포스팅을 줄 수 있다는 점. 참고로 html에 대해서 조금의 지식이 있는 사람이라면 아실만한 내용인데요. html에 편지를 쓰고 주석처리를 해도 누구나 나의 편지를 보게할 수 있다는 점을 들 수 있어요. 생각보다 모르시는 분들 많으시던데 html파일에 주석을 작성하면 아무도 볼수 없다고 생각하시는 분들 계시던데 아니에요. 볼수 있어요. 화면에만 안보이는 거 뿐이지 개발자 모드 켜면 이렇게 나옵니다. 물론 요즘은 SPA나 SSR이 대세이기 때문에 렌더링 과정에서 이런 주석 처리된건 렌더링이 안되기 때문에 그런 경우에는 안보이는데 그런 경우에도 베이스가 되는 html파일은 어떤 프레임워크라도 존재하기 때문에 컴포넌트가 아니라 베이스가 되는 html파일에 직접 주석을 작성하면 이렇게 개발자모드에서 읽을 수 있어요. 클라이언트 회사를 공개적으로 욕하고 싶으신 분은 이렇게 하시면 되고 대신 이렇게 코드를 적고 납품을 하면 클라이언트 서버에 다시 접속하지 않는 이상 수정할 방법이 없기 때문에 나중에 법적 문제가 생겨도 알아서 책임지셔야 합니다. 그리고 이렇게 주석에 편지를 쓰고 클라이언트에게 납품을 했는데 어떤 이유로 클라이언트에게 그 편지를 들통났을 때도 그 쪽팔림과 책임은 알아서 지셔야 하구요. 저는 걸린적 없고 절대 알아볼수 없을 곳에 편지를 썼는데 몇년이 지났는데도 아직도 제 마음이 전달되지 못한 것 같아서 내심 서운한 감정이 들 때도 있어요. 뭐 설령 제 마음이 전달됬다 하더라도 답장할 방법이 없을테니 어쩌면 클라이언트가 더 아쉬워 할 수도 있겠네요. 편지를 썼을 때도 생각했지만 우리는 절대 다시 만나서도 안되었고 이루어져서도 안되는 관계이기에 그냥 아름다운 추억으로 남겨야겠다고 생각했어요. 아마 그때 클라이언트는 이 포스팅을 볼 일이 없을거라고 생각하는데 그래도 간단히 편지를 남겨볼께요. 우리 다시는 만나지 말자!
두번째로 제가 화풀이하는 방법은 납품파일의 사이즈를 높이는 방법입니다. 아마 대부분의 개발자들이 코딩을 할때 깃으로 버젼관리를 할거에요. 근데 그거 아시나요? 깃파일의 사이즈가 생각보다 커요. 특히나 커밋을 많이 했다면 사이즈는 그와 비례해서 커져있을 거에요. 사실 납품받는 입장에서는 깃파일은 불필요하기도 하고 작업했던 모든 스토리가 들어있기 때문에 깃파일은 납품하지 않아야 하는데요. 어차피 줘도 모르는 클라이언트라면 그냥 줘버립니다. 쓸데없이 전체파일 사이즈만 높여서 저장공간 용량만 차지하게 한다는 장점이 있고 클라이언트로 하여금 파일 용량이 크면 뭔가 대단한 결과물이라는 인식을 줄 수 있다는 장점이 있어요. 하지만 클라이언트쪽에서 이를 알아채고 깃파일을 삭제라도 한다면 모든 기대가 수포로 돌아간다는 단점이 있어요. 혹시라도 궁금하신 분들을 위해 깃파일을 확인하는 방법을 알려드릴께요. 먼저 git을 사용하고 계시다면 git init을 했던 폴더까지 이동을 하고 윈도우라면 숨겨진파일 보기를 켜시고 맥이라면 커멘드 쉬프트 + .을 누르면 숨겨져있는 git폴더를 확인하실 수 있어요. 나의 지금까지의 모든 히스토리를 전달하는 친절함을 배푸실 분들이라면 참고해주세요.
세번째 저만의 화풀이 방법으로는 개발 공수를 실제보다 최소 3배 이상으로 불리는 방법입니다. 예를들면 한달이면 개발을 끝낼 수 있을거 같다면 클라이언트에게 세달에서 반년정도 걸릴거 같다고 말하는 거에요. 그게 뭐든지 말이죠. 그럼 대부분이 뭐 그리 시간이 많이 걸리냐고 반문할거에요. 예전에 개발 의뢰했을 때 비슷한 기능을 의뢰했는데 그때는 이정도까지는 아니였다… 뭐 이런식으로 말이죠. 근데 사실 시간이 오래 걸리는 이유는 만들려면 정말 많이 만들 수 있어요. 이것저것 말도 안되는 핑계를 대면 그만이에요. 이 화면에서 이 로직과 지금 새로 구현하려는 기능이 충돌을 일으킨다…그래서 일부 로직을 수정해야하는데 그 로직이 하필 DB를 건드리고 있다. 그래서 전체적인 리펙토링을 진행해야하는데 더 큰 문제는 지금 손대려는 로직이 어디까지 영향을 미치고 있는지 모르고 있다. 때문에 현재 상황을 파악하는 시간이 필요하고 재설계를 위한 시간도 필요하다. 그리고 그와 관련된 개발문서를 업데이트하고 개발을 하려면 최소한 반년은 필요하다.. 뭐 이런 식으로 말이죠. 개발에 관해서 지식이 없거나 코드를 뜯어보지 않는이상 알 수 없는 멍멍이 소리로 클라이언트를 현혹하면 됩니다. 근데 사실 이렇게 해야할 때도 있어요. 아직 기획내용이 완벽이 정해지지 않은 상황이거나 정해진 기획이 변동될 가능성이 있을 경우에는 어느정도의 버퍼를 넣는것이 상식인데 저의 경우 상대방이 상습범이면 형량의 기간을 늘려버리죠. 그리고 그 기간동안 세상일이 참 쉽지 않구나..라는 생각을 하게 만듭니다. 물론 저도 그만큼 클라이언트와 긴 시간을 보내야하니 조금 피곤하지만 피곤한건 클라이언트도 마찬가지기 때문에 막판에 가면 갈 수록 저보다 더 이 프로젝트를 끝내고 싶다는 생각이 간절해 질거에요. 근데 이게 경우에 따라서는 잘 안통하기도 하니 상대를 봐 가면서 이런 전략을 사용하실 것을 추천드려요. 또한 형량의 기간도 너무 오버해서도 안되고 적당한 수준으로 늘리셔야하구요. 혹시나 클라이언트가 아무리 그래도 개발기간이 너무 길다…줄여라… 이런 반응이라면 적당히 흥정 좀 하고 마지막에 벌레보는 듯한 눈빛으로 정말정말 마지못한 표정으로 일주일정도 줄이시면 됩니다. 자칫잘못하면 분위기 험악해질 수도 있으니 이 방법도 여러분들의 재량에 맡길게요. 저는 이 방법으로 나름 사람답게 일을 했어요.
이렇게 제가 화풀이 하는 방법 세가지를 말씀드렸는데요 그냥 재미로 봐주시고 혹시라고 이중에 어느방법이든 나도 한번 해보겠다…하시는 분이 계시다면 책임은 본인이 지시고 한가지 조언을 더 드리자면 일 하나는 확실하게 끝내서 납품을 해야한다는 점이에요. 꼬장은 꼬장대로 부리면서 일은 못한다면 그건…욕 먹어도 할말 없거든요. 그래서 이 포스팅의 결론은 화풀이 하고 싶다면 실력부터 키워라…가 되겠습니다. 사실 실력이 높다면 인격적인 모욕을 하지 않고 회사에 손실만 안입힌다면 대부분 용서아닌 용서를 해줘요. 물론 다방면에서 다 잘 한다면 그보다 더 좋을 수는 없겠지만 그런 천재가 내가 아니라면 그냥 무조건 실력을 높여야해요. 그래야 협상도 가능하고 클라이언트와 내가 서로 윈윈 할 수 있는 제안도 하기 쉽거든요. 앞서 제가 세가지 화풀이 방법을 설명 드렸지만 가장 좋은 방법은 애당초 이런 일이 일어나지 않게 하는거에요. 그게 내 힘으로 해결할 수 있는 부분이 있다면 해결하는게 가장 좋은데 이 또한 실력에서 나오게 됩니다. 이번 포스팅은 반은 재미로 봐주셨으면 하는 내용이었지만 실력을 높이는데 있어서 조금의 동기부여가 되었으면 합니다. 오늘 제가 준비한 포스팅은 여기까지 입니다. 오늘 포스팅이 재미있으셨다면 저의 youtube에 오셔서 지금 좋아요와 구독을 눌러주세요. 또한 여러분들의 댓글로 힘들어도 영상과 포스팅을 올리고 있으니 궁금한 사항도 응원의 메세지도 남겨주시면 너무나 감사하겠습니다. 그럼 좋은 하루 보내시고 저는 다음 포스팅에서 뵙겠습니다. 감사합니다.
