저는 지난 7년 동안 소프트웨어 개발자와 기타 프리랜서들을 고용해 왔습니다. 대부분의 코드는 직접 작성하지만, 다른 개발자를 고용하면 사업의 다른 부분에 시간을 쓸 수 있게 해 주는 엄청난 레버리지가 생깁니다.

관계를 제대로 관리하면 프리랜서와는 매우 잘 협업할 수 있지만, 일이 잘못되는 방식은 수백 가지나 됩니다. 일을 시작하는 가장 좋은 방법은 프리랜서와 클라이언트의 관계에 대해 서로 같은 이해를 갖는 것입니다.

아래 문서는 프리랜서 개발자로서 저와 함께 일할 때 어떤 방식으로 진행되는지를 설명합니다. 저는 게시하는 모든 개발자 채용 공고에 이 문서를 포함하고, 함께 일하기 시작한 뒤에는 계약자에게 꼼꼼히 읽도록 하고 그 시간도 급여로 지급합니다. 덕분에 작업 방식이 잘 맞는 지원자를 끌어올 수 있고, 채용 후 업무에 적응하는 시간도 줄어듭니다.

저는 Creative Commons BY-4.0 라이선스에 따라 이 가이드라인을 공개하므로, 자유롭게 재사용하거나 수정해서 사용하셔도 됩니다.

개요

이 문서는 제가 프리랜서 개발자와 일할 때 사용하는 절차와 관례를 설명합니다.

저와 함께 일하기 전에 이 문서를 읽고 있다면, 이런 작업 방식이 본인과 맞는지 확인하는 정도로 훑어보셔도 됩니다. 현재 저와 계약을 맺고 일하는 중이라면 꼼꼼히 읽고 그 시간은 제게 청구하세요.

황금률

저는 제가 대접받고 싶은 방식으로 여러분을 대하고 싶습니다.

커뮤니케이션

무엇보다 효과적인 커뮤니케이션을 중요하게 생각합니다.

소통은 부족하기보다 충분한 편이 낫습니다. 해결책을 공유할 때는 왜 그 방법을 선택했는지, 다른 방법은 무엇을 검토했는지도 함께 알려주면 좋습니다.

이메일은 신속하게 처리하세요

저는 주로 이메일로 소통합니다.

제 이메일 작성 방식은 Cal Newport가 ‘프로세스 중심(process-centric)’이라고 부르는 방식입니다. 간단히 말하면 이메일은 대개 하나의 작업이나 질문을 나타내며, 가능한 한 적은 횟수의 주고받기로 이를 해결하는 것이 목표입니다. 그러려면 받은 편지함에서 대화를 빨리 지우는 데 급급해 가장 빠른 답장을 보내기보다, 우리 모두 이메일을 신중하게 작성해야 합니다.

나쁜 이메일 주고받기

다음은 좋지 않은 이메일 흐름을 가상으로 보여주는 예입니다. 프리랜서는 처음부터 필요한 정보를 생각하는 데 시간을 투자하지 않고, 질문을 하나씩 조금씩 던집니다.

좋은 이메일 주고받기

반대로 다음 이메일 흐름은 같은 질문에 대해 계획적이고 효율적으로 답을 얻습니다.

이메일 응답 시간

이메일에는 영업일 기준 하루 안에 답변해 주시기를 기대합니다. 다시 말해 화요일 오후 3시에 이메일을 보냈다면 수요일 오후 3시까지 답장을 받고 싶습니다. 완전한 답을 바로 할 수 없다면, 메시지를 확인했다는 답장과 함께 전체 답변을 보낼 예상 시간을 알려주세요.

가끔 응답이 하루보다 늦어지는 것은 괜찮지만, 예외여야지 원칙이 되어서는 안 됩니다. 저에게도 같은 기준을 기대하셔도 됩니다.

회의

회의는 글로 전달하기에 비효율적이거나 불가능한 주제에 유용합니다. 하지만 회의에는 상당한 비용이 따릅니다. 집중을 방해하고 일정을 제약하기 때문입니다. 그래서 회의는 최소한으로 유지합니다.

사실을 전달할 때는 이메일을 사용하고, 주제를 상호작용하며 논의할 때는 회의를 사용합니다. 예를 들어 디자인 문서를 검토할 때 문서를 실시간으로 함께 읽을 필요는 없습니다. 미리 문서를 읽고, 회의 시간은 실시간 토론에 할애하면 됩니다.

또 한 달에 한두 번은 편하게 얼굴을 보고 이야기하는 회의도 잡습니다. 이메일로만 소통하면 관계가 비인간적이고 긴장된 느낌이 들 수 있습니다.

면접

저는 채용 결정을 내리기 위해 정식 면접을 진행하지 않습니다.

이전 작업의 예시를 보여 달라고 하거나 이메일로 몇 가지 질문을 할 수는 있지만, 제가 가장 중요하게 보는 것은 우리가 얼마나 잘 협업하는가입니다. 유력한 지원자라면 평소 작업 단가로 범위가 좁은 업무를 하나 정해 드립니다. 일반적으로 이런 방식을 ‘계약 후 채용(contract-to-hire)’이라고 부릅니다.

유급 시험 과제를 시작해 달라고 요청했다면, 이후 함께 일하지 않기로 결정하더라도 그 시간에 대해서는 비용을 지급합니다. 단, 과제에 성실하게 임하지 않은 경우는 예외입니다. 예를 들어 프로그래밍 작업에 10시간을 청구하고 코드 zero를 제출하는 경우입니다.

사전 조사

프리랜서는 자신의 작업을 감독하는 데 제가 들이는 시간을 최소화할 때 가장 큰 가치를 제공합니다. 그러려면 질문을 하기 전에 충분히 조사해야 합니다.

도움을 요청하는 것을 어려워하지 마세요. 다만 가능하다면 스스로 답을 찾아보기를 기대합니다. 문제를 해결하지 못했다면 어떤 시도를 해 보았는지 알려주세요.

근무 가능 시간

누구에게든 주 5일을 넘겨 일할 수 있기를 기대하지 않습니다. 달리 말하지 않는 한 주말에는 일하지 않는다고 생각하겠습니다.

저는 주말과 미국의 주요 공휴일에는 일하지 않습니다. 주말에 이메일을 보내셔도 되지만 다음 영업일까지는 답장하지 않습니다. 미국 동부 시간 기준 정오 전에는 이메일을 보내지 않으려고 합니다.

원하는 시간에 자유롭게 일하셔도 되지만, 제 근무 시간인 ET 오전 10시부터 오후 6시 30분까지 중 일부는 겹치기를 바랍니다.

매주 고정된 일정으로 일하기를 기대하지는 않지만, 근무 시간을 제가 더 잘 예측할 수 있을수록 여러분의 일정에 맞춰 작업과 피드백을 준비하기가 쉬워집니다.

피드백

프로젝트 진행 중이나 완료 후에 피드백을 요청하는 일이 흔합니다. 프리랜서는 프로세스나 업무 방식의 개선에 도움이 되는 소중한 아이디어를 갖고 있지만, 직접 요청받기 전에는 공유하기를 불편해하는 경우가 있습니다.

제가 주로 묻는 질문은 다음과 같습니다.

• 업무를 더 원활하거나 즐겁게 만들 변화가 있을까요?
• 더 많이 하고 싶은 업무가 있나요? 더 적게 하고 싶은 업무는요?

마감일

급하게 작업해야 하는 경우는 드물기 때문에 대체로 마감일을 직접 정하도록 합니다. 제가 상기시켜 주지 않아도 스스로 정한 마감일을 지키는 것은 여러분의 책임입니다.

마감일이 지나가도록 아무런 소식도 전하지 마세요. ET 화요일 오후 3시까지 작업을 보내겠다고 했다면, 화요일 밤까지 아무것도 받지 못할 때 저는 스트레스를 받습니다. 작업을 완전히 잊어버려 처음부터 다시 시작해야 하는 건지, 아니면 몇 시간 뒤면 거의 끝나 결과물을 보낼 수 있는 건지 알 수 없기 때문입니다.

마감일을 지키지 못할 것 같다면 알려주세요. 일정이 늦어질 가능성을 일찍 알려줄수록 좋습니다. 지연 사실을 알릴 수 있는 가장 늦은 시점은 마감일 당일입니다.

대체로 지연 자체는 큰 문제가 아닙니다. 제가 그에 맞춰 계획을 세울 수만 있다면 괜찮습니다. 마감일이 제게 중요하다면 따로 알려드리겠습니다.

마감일을 정할 때는 정확하고 모호하지 않은 시간 표현을 사용하세요.

• 꽤 좋음: 금요일 업무 종료 시각까지 보내드리겠습니다.
• 더 좋음: 12월 8일 ET 오후 5시까지 보내드리겠습니다.
• 나쁨: 며칠 안에 준비하겠습니다.
  • 너무 모호합니다.
• 최악: 준비되면 알려드리겠습니다.
  • 극도로 모호합니다.

타임박싱

함께 일하기 시작한 초기에는 주당 또는 마일스톤별 청구 가능 시간을 제한해 달라고 요청합니다. 여러분의 개발 속도와 우리가 잘 맞는지를 파악하는 동안 청구액을 관리하기 위해서입니다.

한도에 가까워졌는데 작업을 끝내지 못할 것 같다면, 지금까지 한 작업을 정리할 시간을 남겨 두세요. 완료된 부분, 완료되지 않은 부분, 남은 작업에 예상되는 시간을 설명하는 이메일과 함께 제게 보내세요.

합의한 시간 한도를 초과한 시간에 대해서는 비용을 지급하지 않습니다.

함께 일하는 시간이 늘어나면 더 많은 자율성을 드리기 위해 시간 한도를 늘리거나 없애겠습니다.

문서화

저는 문서화를 매우 중요하게 생각합니다.

프로젝트에 문서화된 프로세스나 GitHub 템플릿이 있다면 이를 따라 주세요. 문서의 지시가 잘못된 것처럼 보인다면 알려주세요. 지시가 오래되었거나 여러분에게 해당하지 않는다고 추측하지 마세요.

프로젝트에서 저와 함께 일하기 시작하면, 온보딩 문서의 새로운 관리자가 됩니다. 문서가 부실하거나 아예 없어서 막혔다면, 빈틈을 메울 수 있도록 수정 사항을 제출해 주세요.

작성하는 코드는 신중하게 문서화하세요. 코드 자체만 읽어도 이해할 수 있도록 작성하되, 코드로 표현할 수 없는 정보는 소스 코드 주석으로 남기세요. 새 코드의 주석은 주변 코드와 대략 같은 수준으로 꼼꼼하게 작성하세요.

# Number of days per week (seven)   <-- BAD comment
DAYS_PER_WEEK = 7

# This is a workaround for a bug in FooComponent, which crashes the process
# if we call it immediately after writing to disk. <-- GOOD comment
time.sleep(5)

코드 품질

저는 작업을 빨리 끝내는 것보다 품질과 유지 보수성을 중요하게 생각합니다.

작동하는 코드를 작성한 뒤에는 로직을 단순화하거나 리팩터링하고 더 직관적으로 만들 방법을 찾아보세요. 코드를 30% 더 단순하게 만드는 데 시간이 두 배 걸리더라도, 제게는 결과적으로 이득입니다.

코드 리뷰

모든 코드 변경 사항을 꼼꼼히 검토하고 자세한 피드백을 제공합니다.

제 의견은 여러분을 비판하거나 기분 나쁘게 만들려는 것이 아닙니다. 코드를 이해하고 장기적으로 제가 유지 보수할 수 있는 상태로 만들기 위해 엄격하게 검토합니다.

다음 글에서 제 코드 리뷰 프로세스를 설명합니다.

• 제가 코드를 리뷰하는 방식
• 리뷰를 위해 코드를 제출하는 방식

코드 스타일

제 프로젝트는 Google의 코드 스타일 가이드라인을 따릅니다.

• Python
• HTML/CSS
• Shell

가능한 한 자동화 도구를 사용해 스타일 규칙을 적용합니다.

Git

소스 관리는 Git을 사용합니다. 기본 기능만 이해하고 있다면 Git 전문가일 필요는 없습니다.

• 저장소 클론하기
• 브랜치 만들기
• 커밋하기
• 변경 사항 푸시하고 풀하기
• 커밋 리베이스하기(가끔)

GitHub 권한

권한은 최소 권한 원칙에 따라 부여합니다. 제 공개 저장소 중 하나에서 작업한다면 추가 권한 없이도 저장소를 포크하고 풀 리퀘스트를 만들기 시작할 수 있습니다.

저는 필요 이상으로 광범위한 권한을 요구하는 GitHub 연동 도구 두 가지를 사용합니다. CircleCI와 Reviewable입니다. 두 애플리케이션 모두 GitHub 계정의 모든 저장소에 대한 쓰기 권한을 요구합니다. 이런 권한을 허용하기 불편하다면, 저와의 작업 전용 GitHub 사용자 계정을 만들어 해당 도구에 전체 권한을 부여해야 합니다.

커밋 관리

모든 커밋이 아름답고 신성하다고 믿는 개발자도 있습니다. 저는 그렇지 않습니다.

main 브랜치에 건전한 커밋 기록이 남는 것은 제게 중요합니다. 그 밖의 브랜치에서는 원하는 방식으로 커밋하세요. 코드 리뷰 의견마다 커밋을 하나씩 만들어도 되고, 모든 의견을 하나의 커밋에서 처리해도 됩니다. 어떤 작업 흐름을 선호하든 저는 괜찮습니다. 저는 GitHub의 squash and merge 기능을 사용하므로, 모든 풀 리퀘스트는 하나의 커밋으로 합쳐집니다.

커밋이 많은 풀 리퀘스트를 제출하면 풀 리퀘스트 제목, 설명, 댓글을 읽습니다. 개별 커밋을 하나하나 살펴보지는 않습니다. 개별 커밋은 작업 중간 단계의 결과물이라고 생각하기 때문입니다. ‘좋은 Git 커밋 메시지 작성법’에서는 제가 선호하는 기여 내용 문서화 방식을 설명합니다. 다만 저는 이 방식을 개별 커밋이 아니라 풀 리퀘스트에 적용합니다.

테스트

풀 리퀘스트를 만들 때 모든 테스트가 지속적 통합 환경에서 통과하도록 하는 것은 여러분의 책임입니다. 검토를 위해 코드를 보내기 전에 빌드가 깨지는 문제를 모두 해결하세요.

기능을 추가했거나 동작을 변경했다면, 새로운 동작을 검증하도록 자동화 테스트를 업데이트하세요.

자동화 테스트가 어려운 기능을 수정했다면 새 코드를 실행해 기능을 수동으로 테스트하세요. 그렇게 할 방법을 찾지 못했다면 리뷰를 요청할 때 아직 테스트되지 않았다고 알려주세요. 이런 경우는 극히 드물어야 합니다.

청구 가능 시간

저와 함께 일하기 위해 하는 일이라면 거의 전부 청구 가능한 업무로 간주합니다.

경비

프리랜서 개발자로 일하는 데 필요한 기본 도구는 직접 준비하시기를 기대합니다. 예를 들면 컴퓨터, 인터넷 접속, 전기 등이 있습니다.

업무를 더 효율적이거나 쾌적하게 만들어 주는 소프트웨어, 서비스, 장비 비용은 기꺼이 지급하겠습니다. 다만 먼저 제게 알려 주세요.

업무와 관련된 물건을 구매해 달라고 요청한 경우에는 다음 청구서에 해당 비용을 포함해 환급하겠습니다.

모니터링

여러분이 작업 시간을 정직하게 보고할 것이라고 믿습니다. 작업 시간을 ‘증명’하라고 요구하거나 시스템에 감시 소프트웨어를 설치하라고 하는 일은 절대 없습니다.

Upwork처럼 모니터링 기능이 내장된 플랫폼을 사용한다면, 모니터링 기능은 항상 선택 사항으로 두겠습니다. 시간에 심각한 불일치가 있는 경우가 아니라면 모니터링 데이터를 확인하지 않습니다. 그런 경우에도 데이터를 살펴보기 전에 먼저 여러분과 이야기하겠습니다.

진행 상황 공유

얼마나 자주 진행 상황을 공유해야 하는지 정확히 정하기는 어렵습니다. 어느 정도 판단이 필요한 일이기 때문입니다.

범위가 명확한 작업, 예를 들어 잘 정의된 기능 작업이라면 청구 가능한 작업을 8~10시간 할 때마다 한 번씩 업데이트를 공유하세요. 버그 조사나 실험이 필요한 기능처럼 범위가 변할 수 있는 작업이라면 청구 가능한 작업 2~4시간마다 한 번씩 업데이트하는 것을 목표로 하세요. 상태 업데이트 없이 작업할 수 있는 절대적인 최대 시간은 청구 가능한 작업 기준 3일 또는 10시간 중 먼저 도달하는 시점입니다.

상태를 공유하는 가장 좋은 방법은 진행 상황을 반영하는 풀 리퀘스트를 만드는 것입니다. 이상적으로는 작업 중 완결된 하나의 부분을 떼어 내 완전한 풀 리퀘스트로 만들면 됩니다. 그렇지 않다면 풀 리퀘스트를 공유하고 아직 작업 중임을 나타내도록 ‘draft’로 표시하세요. 버그를 조사하는 동안 진행 상황을 공유할 때는 GitHub 이슈를 업데이트해 지금까지 조사한 내용과 알아낸 점을 요약하세요.

GitHub에 널리 공유하고 싶지 않은 업무 관련 메타 논의는 제게 개인 이메일로 보내도 됩니다. 하지만 가능한 한 많은 논의를 GitHub에서 진행하도록 하세요.

대금 지급

2주마다 작업 시간에 대한 청구서를 보내 주세요. 청구서를 받은 날부터 영업일 기준 5일 안에, 대개는 그보다 빨리 지급합니다.

보너스나 팁은 지급하지 않습니다. 보상이 투명하기를 바라므로, 제 재량에 따라 정해지지 않은 보수를 받을 수 있을지 걱정하지 않으셔도 됩니다.

지급 방식은 선호에 따라 PayPal, Payoneer, ACH 송금(미국만 해당), 우편 수표(미국만 해당) 중에서 선택할 수 있습니다.

계약 종료 후 업무

업무가 끝난 뒤 작업에 관해 질문하거나 무료 수정을 요청하려고 연락하는 일은 절대 없습니다. 계약 기간 안에 요청한 작업을 모두 납품받았는지 확인하는 것은 제 책임입니다.

대금을 지급한 뒤 여러분의 작업에서 문제를 발견하면, 제가 직접 수정하거나 추가 청구 가능 시간을 제안할 책임이 있습니다.

세금

한 해 동안 여러분에게 600달러를 초과해 지급하면 세금 처리를 위해 몇 가지 서류가 필요합니다.

• 미국 시민권자 및 거주자
  • W-9 양식을 제출해야 합니다. 연말에는 1099-MISC를 보내 드립니다.
• 미국 외 지역의 프리랜서
  • 미국 세금을 납부할 의무가 없음을 신고하는 W-8BEN 양식이 필요합니다.

지식재산권

제가 지식재산권을 보유하기를 원하는 프로젝트를 함께 진행한다면, 전자 서명을 위한 계약서를 보내 드립니다. 이 계약서는 여러분이 저를 위해 작성한 코드의 저작권을 제가 구매한다는 내용을 담고 있습니다.

계약은 제가 비용을 지급하고 여러분에게 제작을 맡긴 작업에만 적용되며, 저를 위해 유급으로 일하는 시간 외에 여러분이 만드는 것에는 적용되지 않습니다.

표지 그림: Loraine Yow.

클라이언트이신가요, 프리랜서이신가요? 비슷한 문서를 갖고 계시거나 다른 분들은 이 문제에 어떻게 접근하는지 알고 계시다면, 댓글로 자유롭게 공유해 주세요.