지난 7년간 소프트웨어 개발자를 비롯한 다양한 프리랜서를 고용해 왔습니다. 대부분의 코드는 직접 작성하지만, 다른 개발자를 고용하면 엄청난 시너지가 생겨 비즈니스의 다른 부분에 시간을 쓸 수 있습니다.

프리랜서와의 협업은 관계를 잘 관리하면 훌륭하게 작동하지만, 잘못될 수 있는 경우도 수백 가지나 됩니다. 좋은 출발을 위한 최선의 방법은 프리랜서와 클라이언트 관계에 대한 공통된 이해에 도달하는 것입니다.

아래 문서는 프리랜서 개발자로서 저와 함께 일하는 것이 어떤 것인지 설명합니다. 저는 게재하는 모든 개발자 채용 공고에 이 문서를 포함하고, 함께 일하기 시작한 뒤에는 계약자들에게 이 문서를 꼼꼼히 읽도록 하고 그 시간에 대해 비용을 지급합니다. 이를 통해 저와 맞는 업무 스타일을 가진 지원자를 끌어모으고, 채용 후 적응 기간을 단축할 수 있습니다.

이 가이드라인은 크리에이티브 커먼즈 BY 4.0 라이선스로 공개하므로 자유롭게 재사용하거나 변형해 사용하셔도 좋습니다.

개요

이 문서는 제가 프리랜서 개발자와 함께 일할 때 사용하는 프로세스와 관행에 대해 설명합니다.

저와 일하기 전에 이 문서를 읽고 있다면, 이 업무 스타일이 자신과 맞는지 가볍게 훑어보셔도 좋습니다. 이미 계약을 맺고 진행 중인 상태에서 읽고 있다면, 꼼꼼히 읽고 그 시간을 청구해 주세요.

황금률

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

소통

저는 무엇보다 효과적인 소통을 중요하게 생각합니다.

소통은 지나치다 싶을 정도로 많이 하는 편이 낫습니다. 해결책을 공유할 때는 왜 그 방법을 선택했는지, 어떤 다른 방법을 검토했는지 함께 알려주시면 도움이 됩니다.

이메일은 신속하게 마무리하기

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

제 이메일 스타일은 Cal Newport가 말하는 “프로세스 중심적(process-centric)”인 스타일입니다. 간단히 말해, 이메일 하나는 보통 하나의 작업이나 질문을 의미하며, 가능한 한 적은 왕복으로 해결하는 것을 목표로 합니다. 이를 위해서는 받은 편지함에서 스레드를 빨리 없애기 위해 가장 빠른 답변을 쏘아 보내는 대신, 서로 신중하게 이메일을 작성해야 합니다.

나쁜 이메일 예시

다음은 좋지 않은 이메일 교환의 가상 사례입니다. 필요한 정보를 미리 고민하는 데 시간을 들이는 대신, 프리랜서가 질문을 하나씩 조금씩 던집니다.

좋은 이메일 예시

반면, 다음 이메일 교환은 위와 같은 질문들을 계획적이고 효율적으로 처리합니다.

이메일 응답 시간

이메일에 대해서는 1영업일 이내에 답장을 기대합니다. 다시 말해, 화요일 오후 3시에 제가 이메일을 보내면 수요일 오후 3시까지 답장을 기대한다는 뜻입니다. 완전한 답변을 바로 줄 수 없더라도, 메시지를 확인했다는 답장과 전체 답변을 언제 줄 수 있을지 예상 시간을 알려주세요.

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

회의

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

저는 사실 전달은 이메일로, 주제에 대한 상호 토론은 회의로 합니다. 예를 들어 설계 문서를 검토할 때 굳이 함께 실시간으로 읽을 필요는 없습니다. 대신 문서를 미리 읽고 회의 시간은 실시간 토론에 쓰는 것이 좋습니다.

또한 한 달에 한두 번은 가볍게 얼굴을 보는 자리를 마련합니다. 이메일로만 소통하면 관계가 비인격적이고 긴장감 있게 느껴질 수 있기 때문입니다.

인터뷰

저는 채용 결정을 위해 정식 인터뷰를 진행하지 않습니다.

이전 작업 사례를 보여달라고 하거나 이메일로 몇 가지 질문을 드릴 수는 있지만, 가장 관심 있는 것은 우리가 얼마나 잘 함께 일할 수 있는지입니다. 유력한 후보라면, 평소 급여율로 범위가 좁게 한정된 일을 하나 맡겨드립니다. 보통 이런 방식을 “contract-to-hire”라고 부릅니다.

유급 시범 과제를 시작해 달라고 요청드렸다면, 이후에 함께 일하지 않기로 결정하더라도 해당 시간에 대한 비용은 지급합니다. 유일한 예외는 과제에 성실히 임하지 않은 경우입니다(예: 프로그래밍 작업에 10시간을 청구하고도 코드를 전혀 전달하지 않은 경우).

사전 조사

프리랜서는 제가 작업을 감독하는 데 드는 시간을 최소화할 때 가장 큰 가치를 발휘합니다. 그러려면 질문하기 전에 사전 조사를 해야 합니다.

도움이 필요하면 편하게 요청하셔도 되지만, 가능한 한 스스로 답을 찾아보시길 기대합니다. 문제를 해결하지 못했다면 어떤 시도를 해봤는지 알려주세요.

근무 가능 시간

일주일에 5일 이상 상시 대기해야 한다고 기대하지 않습니다. 별도로 말씀해 주시지 않으면 주말에는 일하지 않는 것으로 간주하겠습니다.

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

원하는 시간에 자유롭게 일하셔도 되지만, 제 근무 시간인 동부 시간 기준 오전 10시부터 오후 6시 30분까지와 어느 정도 겹치는 시간이 있으면 좋겠습니다.

매주 고정된 일정으로 일해야 한다고 기대하지는 않지만, 여러분의 근무 시간을 예측할 수 있을수록 여러분이 일할 수 있는 시간에 맞춰 작업과 피드백을 준비하기가 더 수월합니다.

피드백

저는 프로젝트 도중이나 완료 후에 피드백을 요청하는 경우가 많습니다. 프리랜서는 프로세스나 협업 방식을 개선할 수 있는 귀중한 아이디어를 가지고 있지만, 직접 물어보기 전까지는 편하게 공유하지 못하는 경우가 있기 때문입니다.

제가 주로 하는 질문은 다음과 같습니다:

• 작업을 더 원활하거나 즐겁게 만들 수 있는 변화가 있을까요?
• 더 많이 하고 싶은 일이나 덜 하고 싶은 일이 있나요?

마감일

급하게 일이 필요한 경우는 드물기 때문에, 보통 마감일은 직접 정하도록 합니다. 정한 마감일은 제가 따로 상기시키지 않아도 지키는 것은 여러분의 책임입니다.

마감일을 아무 소식 없이 넘기지 마세요. 화요일 동부 시간 오후 3시까지 작업을 기대하라고 해놓고 화요일 밤까지 아무 연락이 없으면 저는 스트레스를 받습니다. 과제를 완전히 잊어버려 처음부터 다시 시작해야 하는 건지, 거의 다 끝내서 몇 시간 안에 결과를 줄 수 있는 건지 알 수 없기 때문입니다.

마감일을 지키지 못할 것 같으면 알려주세요. 일정 지연을 미리 알릴수록 좋습니다. 지연을 알려야 하는 가장 늦은 시점은 마감일 그 자체입니다.

일반적으로 지연 자체는 제가 미리 계획을 조정할 수 있는 한 큰 문제가 되지 않습니다. 마감일이 저에게 중요하다면 미리 알려드리겠습니다.

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

• 꽤 좋음: 금요일 영업 종료(EOD)까지 보내드리겠습니다.
• 더 좋음: 12월 8일 동부 시간 오후 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 기능을 사용하므로, 모든 풀 리퀘스트는 하나의 커밋으로 합쳐집니다.

커밋이 많은 풀 리퀘스트를 제출하시면, 저는 풀 리퀘스트의 제목, 설명, 댓글을 읽습니다. 개별 커밋은 여러분의 중간 작업물이라고 생각하기 때문에 하나하나 살펴보지 않습니다. “How to Write a Git Commit Message”라는 글에서 제가 선호하는 기여 문서화 스타일을 설명하는데, 개별 커밋이 아니라 풀 리퀘스트에 적용된다는 점만 다릅니다.

테스팅

풀 리퀘스트를 만들 때, 지속적 통합에서 모든 테스트를 통과시키는 것은 여러분의 책임입니다. 검토를 위해 코드를 보내기 전에 빌드 실패를 모두 수정해 주세요.

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

자동화로 테스트하기 어려운 기능을 수정했다면, 새로운 코드를 검증하기 위해 해당 기능을 수동으로 테스트해 주세요. 그럴 방법을 찾을 수 없다면, 검토를 위해 보낼 때 테스트되지 않았다고 미리 알려주세요(이런 경우는 극히 드물어야 합니다).

청구 가능 시간

저와 함께 일하기 위해 하는 거의 모든 일을 청구 가능한 작업으로 간주합니다.

비용

프리랜서 개발자로 일하는 데 필요한 기본 도구(예: 컴퓨터, 인터넷 접속, 전기)는 직접 준비해 주시길 기대합니다.

작업을 더 효율적이거나 쾌적하게 만들어 주는 소프트웨어, 서비스 또는 장비 비용은 기꺼이 부담하겠습니다. 다만 먼저 저와 상의해 주세요.

제가 작업과 관련해 무언가를 구매해 달라고 요청하면, 다음 청구서에 해당 비용을 상환해 드리겠습니다.

모니터링

여러분이 시간을 정직하게 보고하리라 믿습니다. 시간을 “증명”해 달라고 하거나 시스템에 감시 소프트웨어를 설치하라고 요구하는 일은 절대 없습니다.

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.

클라이언트이신가요, 프리랜서이신가요? 비슷한 문서를 보거나 다른 분들이 이 문제를 어떻게 접근하는지 듣고 싶으니, 댓글로 자유롭게 공유해 주세요.