혼자 어설프게 시작했던 게 벌써 2년 전인데 이제는 그래도 몇몇의 클라이언트를 거쳤다고 혼자 나름의 순서를 정해서 일을 진행해나가고 있다. 여전히 '아 이 계약은 이렇게 했어야 하는구나', '결제는 이렇게 요구하는 게 더 유리했는데', '계약 전에 이부분을 미리 확인해두면 좋았을 것을...' 등등 직접 프로젝트를 진행하면서 배워가는 부분이 많다. 최근 진행했던 2개의 프로젝트를 통해 새로 배운 내용을 정리해보려고 한다.
1. 첫 미팅, 비용 청구
 |
| 프리랜서 개발자 팁 |
1. 첫 미팅, 비용 청구
1) 첫 미팅에서 일을 따내는 법
제일 처음 클라이언트와 만나 미팅을 했던 때를 떠올려보면 사실 잘 알고 있는 내용도 아니었는데 상대방은 어차피 더 모르는 분야라 내가 아는 것들을 설명하고 뭘 아는 것처럼 다 할 수 있다고 얘기하고 돌아와서는 집에서 엄청 구글링했던 기억이 있다. 내가 잘하는 것들 중 하나가 직접 사람을 만나서 이야기하고 설득하는 것인데 아무래도 첫 미팅에서 자신감있게 아는 부분을 설명하고 내가 어떻게 다른 사람들보다 더 잘해낼 수 있는지 말과 태도로 보이면 쉽게 상대방의 신뢰를 얻을 수 있다.
2) 비용을 정하고 청구하는 법
첫 프로젝트는 비교적 간단한 웹사이트였는데 1,000불인가 1,500불 정도로 말도 안되는 적은 비용을 받고 일을 시작했다. 당시 계속 인터뷰를 보고 떨어지길 반복하던 시기이기도 했고, 일을 구하는데 시간을 소비하느니 대신 혼자 공부를 하거나 개발 관련 발룬티어 일이라도 해야겠다는 생각을 했던터라 사실 비용 자체가 중요하지는 않았다. 누군가에게 돈을 받고 개발자라는 이름으로 계약을 따냈다는 것 만으로도 기뻤기 때문.
프리랜서 2년차인 지금은 아무리 작은 프로젝트라도 어느정도 시간이 소요되고 몇 번의 미팅이 오가야되는지를 알기 때문에 너무 적은 비용의 프로젝트는 고사하는 편이다. 그리고 이제 느낀 점은 일반적으로 주니어 레벨의 개발자가 받는 시급으로 대충 계산해서 총 비용을 청구하는 건 손해라는 것. 풀타임으로 일을 한다면 일이 없을 때도 급여는 자동으로 발생한다. 보험 외 다른 혜택들도 함께 따라온다. 하지만 단기 컨트랙이라면 보험 외 다른 혜택은 없이 보통 프로젝트가 끝날 때까지 밀도 높게 일을 해야하기 때문에 처음 '이정도면 되겠다'에서 조금 더 비용을 추가해서 계산하는 것이 맞다.
이렇게 어느정도 추가로 계산해서 넣더라도 실제로 일을 해보면 클라이언트가 어느만큼 꼼꼼하고 수정을 많이 요구하느냐에 따라 결과적으로 일하는 시간이 훨씬 늘어나는 것이 부지기수이기 때문이다.
2. 견적서, 구체적인 세부 결제
사실 엄청 크고 대단한 프로젝트들을 하고 있는 건 아니라서 형식적으로만 견적서 혹은 계약서를 작성하고 있지만, 이 때 미리 클라이언트와 상의를 한 내용을 모두 넣어두는 것이 좋다. 프로젝트가 단계별로 진행될 경우에는 1차(디파짓), 2차, 3차, 혹은 3차 + 최종 결제까지 나눠서 지급받는 것이 좋은데, 디파짓만 받고 일을 진행하고 2차이자 마지막 결제로 지급을 받는다면 결제 금액이 클수록 프로젝트 도중에 불안해지기 쉽다.
계약서를 쓴다고 해도 프로젝트 도중 클라이언트가 어떻게 마음을 바꿀지도 모르고, 수정 요청이 많아 프로젝트가 길어진다면 최종 결제일도 늦어지기 때문에 미리 협의한 어느 단계가 끝나면 중간중간 결제를 받는 편이 서로 안심이다.
3. 프로젝트 진행 방법과 연락
어떻게 연락을 주고 받을지, 얼마나 자주 미팅을 할지, 평일에만 연락을 할지 주말에도 일을 한다는 것을 알릴지 등 본인이 선호하는 방식에 맞게 미리 정해두는 편이 좋다. 예를 들어, 본인은 프리랜서로 일을 해서 비교적 시간이 자유롭더라도 평일 9시에서 오후 5시 사이에만 일을 할 예정이라면 이 부분을 클라이언트에게 미리 얘기 해두고 가능한 근무시간 내에만 미팅을 잡거나 연락을 받도록 정하면 일하기 훨씬 더 편하다.
메일, 메신저, 전화통화, 줌미팅 등의 소통하는 방식도 미리 정해야 클라이언트가 매번 전화로 연락을 해 귀찮게 하지 않으므로 미리 소통방법을 정해두는 것을 기억하자.
4. 커뮤니케이션 스킬
이런저런 인간관계가 귀찮거나 혼자 일하는 편이 좋아서 무조건 프리랜서로 혼자 일하는 것이 더 편할거라는 생각은 잘못된 생각이다. 혼자 클라이언트를 상대해야하기에 본인이 개발자이지만 직접 사람을 상대해야하는 위치에 놓이며, 이 때 소프트스킬이 없다면 원만히 클라이언트와 일을 해나가기가 쉽지 않을 것이다.
혼자 일하면 흔히 boss나 manager가 없다고 생각하겠지만, 일을 주는 클라이언트들이 한명한명 다 나의 boss라고 생각하는 것이 좋다. 말도 안되는 요구도 들어주고 가끔 오랜 시간과 에너지를 쏟아부어 차근차근 설명해줘야하는 경우도 많기에 상대방이 기분 상하지 않게 거절하고 같이 협의 해나갈 수 있도록 커뮤니케이션 스킬을 향상시켜두는 편이 좋다.
5. 중간 보고 혹은 미팅
6. 데드라인
초반에 실수했던 부분이고 지금도 가끔 잊어버리고 그냥 계약을 해버리는 경우가 종종 있는데, 데드라인을 정하는 것은 정말 중요하다. 정확한 데드라인 없이 대충 완성이 되면 끝이라는 생각으로 시작을 했다가 클라이언트의 끊임없는 수정 요청을 다 들어주느라 예상했던 것보다 훨씬 프로젝트가 길어지는 경우도 간혹 있기 때문이다.
중간에 클라이언트가 바쁘거나 일이 생겼다는 이유로, 혹은 휴가나 업무 관련 출장을 간다는 이유로 확인이 늦어지면 늦어지는 만큼 해당 프로젝트의 기간도 연장이 되고, 개발자 입장에서는 언제 끝날지 모르는 늘어지는 프로젝트 때문에 스트레스를 받을 수도 있다.
7. 최종 결제
데드라인과 연관된 부분인데, 서로 정확한 프로젝트 마감일을 정하지 않으면 개발자 쪽에서 완료가 되었음에도 클라이언트의 피드백이 늦어지면서 마지막 잔금 결제도 함께 늦어지는 불상사가 발생한다. 이런 부분을 계약서를 작성할 때 정확히 기재하거나 프로젝트 시작 전에 확실히 정해두는 것이 좋다.