미국 프리랜서 개발자의 커뮤니케이션 방법

11분

2023.09.05.

프리랜서 개발자에게 커뮤니케이션은 왜 중요할까?

1) 프로젝트 생산성 제고

미국에서도 소프트웨어 개발 과정은 요구사항 수집, 프로그램 설계, 개발, 테스트, 배포, 유지 보수의 순서로 진행됩니다. 영어로 Software Development Life Cycle이라고 하며, 줄여서 간단하게 SDLC라고도 합니다.

규모가 큰 프로젝트에서는 각 단계마다 개발자(Developer), 디자이너(Designer), 기획자(Product Manager)를 포함하여, 비즈니스 분석가(Business Analyst), 솔루션 아키텍트(Solution Architect), 프로젝트 매니저(Project Manager), 서비스 매니저(Service Manager), QA 테스터(Quality Assurance Tester) 같은 다양한 전문가들이 프로젝트에 참여하게 됩니다.

이들 간에 수많은 회의와 의사결정이 이뤄지기 때문에 원활한 커뮤니케이션은 곧 프로젝트 생산성에 영향을 줍니다. 반면, 규모가 작은 프로젝트에서는 대체로 클라이언트와 함께 이 모든 단계를 진행합니다. 따라서 소규모 프로젝트에서는 클라이언트와의 커뮤니케이션이 프로젝트 생산성에 가장 큰 영향을 미치게 됩니다.

미국 프리랜서 개발자도 한국에서와 마찬가지로 큰 프로젝트에 계약직(Contractor)으로 참여하기도 하고, 소규모 프로젝트를 직접 수주하여 전체 과정을 책임지기도 합니다. 따라서 항상 프로젝트 내 다른 참여자들과의 커뮤니케이션에 신경을 써야 합니다. 특히 직접 수주한 프로젝트는 클라이언트와 어떻게 소통했는지에 따라, 전체 프로젝트의 성패가 달라지기 때문에 더욱 커뮤니케이션에 집중해야 합니다.

2) 클라이언트 신뢰 확보

커뮤니케이션은 클라이언트의 신뢰를 구축하는 기반이 됩니다. 프리랜서 개발자로서 클라이언트의 신뢰를 얻기 위해서는 요구사항을 면밀히 수집하고, 소프트웨어 개발 과정에서 오해가 생기지 않도록 정기적으로 업데이트 사항을 보고해야 합니다. 클라이언트의 신뢰를 얻으면 조금 더 장기적이고 안정적인 프리랜싱을 할 수 있습니다. 따라서 프리랜서 개발자에게 커뮤니케이션 능력은 개발 능력만큼이나 중요합니다.

프리랜서 개발자의 커뮤니케이션 실패 사례

1) 명확하지 않은 요구사항

프리랜서 개발자로 일하면서 가장 힘든 부분은 클라이언트 요구사항을 명확히 하는 것입니다. 어느 정도 체계가 있고 규모가 큰 업체의 클라이언트는 정리된 요구사항 문서(requirement documentation)와 화면 설계서(Wireframe), 기능 명세서(Functional Specification) 등을 제공해주는 편입니다. 반면, 체계가 잡혀 있지 않은 소규모 클라이언트는 그렇지 않은 경우가 많습니다. 예를 들어, 프로젝트 초반 요구사항 정리를 위한 회의에서 다음과 같은 대화가 이루어지는 식입니다.

클라이언트: We need a feature that allows users to connect with each other in a more convenient way.
사용자들이 조금 더 편리하게 서로 연결될 수 있는 기능이 필요합니다.

개발자: Could you please provide more details about that? Are we talking about a chat system, forums, or something else?
그 부분에 대해 더 자세히 말해 줄 수 있을까요? 채팅 시스템이나 포럼 같은 것을 말하는 건가요?

클라이언트: I'm not sure exactly. Just something that makes the platform more interactive.
정확히는 잘 모르겠지만, 그냥 플랫폼을 조금 더 상호작용할 수 있게 만드는 것이요.

첫 회의에서 이런 형태의 대화가 이루어지면 일단 머릿속에서 위험 신호가 울립니다. 클라이언트가 구체적인 기능이나 화면 구성을 제공하지 않는 프로젝트에서는 대체로 문제가 생기기 때문입니다. 특히 요구사항이 제대로 정리되지 않은 프로젝트는 잦은 수정 요청(change requests)으로 인해 납기를 넘기기가 일쑤였죠. 그러나 이런 경우에도 지속적인 커뮤니케이션으로 요구사항을 구체화하면 프로젝트를 무사히 끝낼 수 있습니다. 다만 그러지 못해서 프로젝트가 어려워진 경우도 많습니다.

2) 커뮤니케이션 부재로 인한 불만

프리랜싱 초창기에는 영어 커뮤니케이션에 대한 부담 때문에 별도 요청이 없으면 특별히 중간 보고를 하지 않았습니다. 결국 이런 부분에 불만을 제기한 클라이언트가 있었고, 장기적으로 끌고 갈 수 있었던 비즈니스 관계를 놓치게 됐습니다. 당시 클라이언트는 We feel left in the dark(마치 어둠 속에 있는 것 같다)라고 불만을 토로했습니다.

이처럼 프로젝트 진행 상황을 주기적으로 보고하지 않으면 클라이언트는 불안감을 느끼고, 개발자에 대한 불만으로 이어질 수 있습니다. 또한 클라이언트와 정기적인 커뮤니케이션이 없으면 합의가 필요한 부분을 임의로 개발하여, 프로젝트가 엉뚱한 방향으로 가는 경우도 있습니다.

클라이언트와 원활하게 소통하려면?

1) 요구사항 수집 및 구체화 방법

프로젝트를 올바른 방향으로 이끌기 위해서는 먼저 클라이언트가 의도하는 바를 충분히 파악해야 합니다. 특히 클라이언트가 프로젝트를 통해 달성하고자 하는 목표를 명확하게 알아내야 하죠. 이를 위해 해당 분야에 대한 공부가 어느 정도 필요하고, 업계 트렌드나 관행에 대해서도 미리 조사해야 합니다. 클라이언트의 요구사항을 수집하여 구체화하기 위해 다음과 같은 방법을 활용해 볼 수 있습니다.

컨텍스트 다이어그램(Context diagram)
기능 분해(Functional decomposition)
유스 케이스 다이어그램(Use case diagram)
시퀀스 다이어그램(Sequence diagram)
사용자 스토리(User stories)
AS-IS, TO-BE 분석 (AS-IS and TO-BE process model)

컨텍스트 다이어그램은 시스템이 외부 엔터티와 어떻게 상호작용하는지를 간략하게 나타내는 다이어그램을 말합니다. 컨텍스트 다이어그램에서는 시스템 전체를 하나의 엔티티로 보고, 외부 엔터티와의 데이터 흐름을 표시하는데요. 이는 프로젝트 초기 단계에서 내부 시스템과 외부 시스템의 경계를 정의하고, 클라이언트와 작업 범위를 협의하는데 유용합니다.

기능 분해는 복잡한 프로세스를 기능 단위로 쪼개서 정리하는 기법을 말합니다. 이 방법을 사용하면 전체 시스템의 기능을 구체적으로 정리하는 데 도움이 됩니다. 특히 클라이언트 요구사항을 분석할 때 복잡한 문제를 작은 기능 단위로 쪼개서 단순하게 만들 수 있습니다. 주로 엑셀을 사용해서 기능 분해 문서를 작성하며, 별도의 다이어그램을 제작하기도 합니다.

유스 케이스 다이어그램은 사용자와 시스템의 상호작용을 표현한 UML 다이어그램(Unified Modeling Language Diagram)을 말합니다. 유스 케이스에서는 사용자(User)와 같이 시스템 외부에 존재하는 객체를 액터(Actor)라고 하는데요. 액터와 시스템 간의 상호작용 프로세스를 시각화해 놓으면 클라이언트와 커뮤니케이션할 때 활용하기 좋습니다. 또한 개발 및 테스트 단계에서 테스트 케이스를 작성할 때도 유용하게 활용할 수 있습니다.

시퀀스 다이어그램은 객체 지향 설계에서 사용되는 UML 다이어그램입니다. 시스템 내 객체 간 상호작용을 시간 순서에 따라 시각적으로 표현하는데요 시스템의 특정 시나리오나 프로세스를 구체화할 수 있으며, 객체 간의 메시지 전달 순서와 과정을 명확하게 나타낼 수 있습니다. 시퀀스 다이어그램은 클라이언트와 복잡한 시스템의 동작을 이해하고 분석하는 데 사용되기도 합니다.

사용자 스토리(또는 유저 스토리)는 사용자가 시스템을 어떻게 이용하는지에 대한 시나리오를 정리하는 방법입니다. 시나리오를 문장으로 만들거나 다이어그램으로 시각화하기도 합니다. 사용자 스토리를 사용하면 어떤 부분에서 클라이언트 요구사항이 있는지 정리하는데 유용합니다.

AS-IS TO-BE 분석은 현재 상태(AS-IS)와 프로젝트 이후 상태(TO-BE)를 비교하여, 비즈니스 프로세스 개선과 관련된 의견을 취합하는 분석 방법입니다. AS-IS 분석에서는 기존의 시스템의 문제점과 비효율성을 식별하고, TO-BE 분석에서 개선된 프로세스와 시스템 기능을 제시합니다. 이러한 분석을 통해서 클라이언트의 요구사항을 보다 구체적으로 이끌어 낼 수 있습니다.

2) 요구사항 분석을 위해 툴 활용하기

위에서 설명한 방법을 사용하기 위한 툴로는 Star UML 같은 UML 모델링 툴이나 Visual Paradigm, Creately, Figma 같은 디자인 프로그램이 있습니다. 이런 툴을 제대로 사용하려면 학습하는데 어느 정도 시간이 필요합니다. 그러나 프로젝트 팀원 간 커뮤니케이션 뿐만 아니라, 클라이언트와의 의사소통에도 많은 도움을 주기 때문에 시간을 투자해 제대로 배울만한 가치는 충분하다고 생각합니다.

3) 정기적인 회의와 피드백

클라이언트의 신뢰를 쌓고 안정적인 비즈니스 관계를 만들기 위해서는 프로젝트 진행 상황을 정기적으로 업데이트하고, 다음 작업을 알리는 커뮤니케이션이 필요합니다. 아울러 지속적으로 피드백을 요청하여 클라이언트가 최대한 프로젝트 의사결정에 참여할 수 있도록 해야 합니다. 정기적으로 클라이언트와 소통하고 피드백을 받기 위해서는 Jira, GitLab, ClickUp 같은 이슈 트래킹 시스템(ITS)을 이용하거나, Zoom이나 Slack 같은 툴로 일간/주간 미팅을 하는 방법이 있습니다.

해외 클라이언트와 대화할 때 유용한 영어 표현

1) 회의 요청 및 일정 확인

이번에는 해외 클라이언트와 영어로 커뮤니케이션해야 하는 경우 사용할 수 있는 몇몇 유용한 표현을 알아보겠습니다. 먼저 프로젝트에서 의사 결정이 필요한 부분이 있을 때 클라이언트나 협업 개발자와 회의를 잡아야 하는데요. 이런 경우 아래와 같이 클라이언트나 협업 개발자에게 회의를 요청하고 일정을 확인할 수 있습니다.

회의 요청: Could we schedule a meeting to discuss [the project details / requirements / design]?
[프로젝트 세부사항 / 요구사항 / 디자인]을 논의하기 위한 회의를 잡을 수 있을까요?
일정 제시: I've scheduled our meeting for [date and time]. Does that work for you?
회의를 [날짜, 시간]으로 예약했습니다. 괜찮으신가요?
일정 재확인: Just confirming our meeting [date and time]. Does that still work for you?
[날짜, 시간]으로 정한 회의를 다시 확인합니다. 여전히 괜찮으시죠?

2) 작업 진행 상황 보고

앞서 클라이언트와 커뮤니케이션 방법에서 살펴봤듯이, 정기적인 커뮤니케이션은 클라이언트의 신뢰를 쌓고 장기적인 비즈니스 관계를 맺는데 중요한 역할을 합니다. 아래 영어 표현은 클라이언트에게 프로젝트 진행 상황을 보고하고, 이슈가 발생했을 때 사용하는 표현입니다. 더불어 다음 진행 작업이 무엇인지를 알리고, 피드백을 요청하는 표현도 함께 알아두면 더욱 좋습니다.

진행 상황 보고: As of today, we are on track with the project, and we have completed the [specific tasks or features].
오늘 현재까지, 프로젝트는 계획대로 진행 중이며, [특정 작업이나 기능]을 완료했습니다.
이슈 보고 및 해결책 제시: We encountered a minor issue with [specific problem], but we expect it to be resolved by [specific solution].
[특정 문제]와 관련하여 약간의 이슈가 있었지만, [특정 해결책]으로 해결될 것입니다.
다음 진행 작업 보고: Based on our current progress, the next tasks will be [specific tasks].
현재의 진행 상황을 기반으로, 다음 작업은 [특정 작업]이 될 것입니다.
피드백 요청: Could you provide feedback on [specific part] so that I can proceed?
다음 단계를 진행하기 위해서, [특정 부분]에 대해서 피드백을 주실 수 있나요?

3) 시스템 문제 발생 시 대처 (ex. 속도 저하 등)

시스템이나 애플리케이션에 문제가 발생했다면 클라이언트에게 즉각 알리고, 조치 상황과 향후 대처 방법을 안내해야 합니다. 자칫 대응을 잘못하면 클라이언트와의 신뢰가 무너질 수 있기 때문에 아래와 같은 영어 표현을 미리 준비해 두면 좋습니다.

이슈 보고: I've noticed the system [slowdown / access unavailable / security breach]. I'm investigating the cause now.
시스템 [속도 저하 / 접속 불가 / 보안 침해]를 발견했습니다. 현재 원인을 조사 중입니다.
원인 분석: The system issue appears to be related to [specific problem]. I am planning to [specific action] to resolve the issue.
시스템 이슈는 [특정 문제]와 관련이 있는 것 같습니다. 이슈를 해결하기 위해 [특정 작업]를 할 예정입니다.
조치 완료: The system issue has been resolved. The problem was due to [explanation], and I've done [specific action] to resolve the issue.
시스템 이슈가 해결되었습니다. 문제는 [설명] 때문이었고, 문제를 해결하기 위해 [특정 조치]를 수행했습니다.
테스트 요청: Please test the system and let me know if everything is running smoothly.
시스템을 테스트해보고 모든 것이 원활하게 작동하는지 알려주세요.

마치며

지금까지 제가 미국에서 프리랜서 개발자로 일하면서 겪었던 커뮤니케이션 사례와 클라이언트 요구사항 수집 방법과 툴, 그리고 유용한 영어 표현을 알아봤습니다. 사실 소프트웨어 개발 과정에서 커뮤니케이션의 중요성은 한국이든 미국이든 똑같다고 생각합니다. 커뮤니케이션의 실패는 곧 프로젝트 지연과 클라이언트의 불만을 초래할 수 있기 때문이죠. 특히 조직에 속하지 않고 한 개인으로서 일한다면 더욱 그렇습니다. 만약 여러분이 프리랜서 개발자로 일할 계획이 있다면, 효과적인 커뮤니케이션 방법을 미리 익혀두고 시작하길 바랍니다.

로그인하고 자유롭게 의견을 남겨주세요.