Source: Dev.to

비동기 작업을 받아들이고 싶다면, 회의‑중심에서 작업‑중심으로 전환하세요

서론

많은 조직이 비동기 작업을 도입하려고 시도하지만, 실제로는 여전히 회의에 의존하는 문화가 남아 있습니다. 회의‑중심 접근 방식은 팀원들의 시간을 잡아먹고, 실시간 동기화에 대한 과도한 기대를 만들며, 결국 비동기의 장점을 충분히 활용하지 못하게 합니다. 이 글에서는 회의‑중심에서 작업‑중심(task‑driven) 방식으로 전환하는 구체적인 방법을 제시합니다.

왜 회의‑중심이 문제인가?

• 시간 낭비: 짧은 회의라도 준비와 참석에 들어가는 시간이 누적됩니다.
• 정보 과부하: 회의에서 다루는 내용이 바로 실행 가능한 작업으로 연결되지 않으면, 팀원들은 다시 정보를 정리하고 이해해야 합니다.
• 동기화 비용: 모든 사람이 같은 시간에 모여야 한다는 제약은 시차가 있는 팀이나 유연 근무를 하는 사람들에게 큰 부담이 됩니다.

작업‑중심 접근 방식의 핵심 원칙

1. 명확한 목표와 결과물 정의
   • 각 작업은 무엇을 달성해야 하는지, 완료 기준이 무엇인지 명시합니다.
2. 비동기 커뮤니케이션 채널 활용
   • 슬랙, 디스코드, Notion, Confluence 등에서 스레드와 업데이트를 통해 진행 상황을 공유합니다.
3. 작업 단위로 책임 할당
   • 담당자를 지정하고, 마감일과 우선순위를 명확히 합니다.
4. 자동화와 트래킹 도구 사용
   • Jira, Asana, Trello 등에서 칸반 보드를 운영해 진행 상황을 실시간으로 시각화합니다.

회의‑중심에서 작업‑중심으로 전환하는 단계별 가이드

실전 팁

• 짧은 ‘스탠드업’ 대신 ‘스프린트 리뷰’: 15분 회의 대신 스프린트 종료 시점에 전체 진행 상황을 요약한 문서를 공유합니다.
• ‘데드라인’ 대신 ‘시간 박스’: 작업에 명확한 마감일을 두기보다 일정 시간 안에 최선의 결과를 내도록 유도합니다.
• ‘동기화 회의’ 최소화: 반드시 필요한 경우에만 시간대 겹치는 30분 이내로 제한합니다.
• ‘문서가 진실이다’ 원칙 적용: 모든 결정과 논의는 문서화하고, 링크를 통해 언제든 접근 가능하게 합니다.

결론

비동기 작업을 성공적으로 도입하려면 회의‑중심 사고방식을 버리고 작업‑중심 흐름을 구축해야 합니다. 명확한 목표 설정, 비동기 커뮤니케이션 채널 활용, 작업 보드 시각화, 그리고 지속적인 피드백 루프가 핵심 요소입니다. 이러한 변화를 단계적으로 적용하면 팀의 생산성은 물론, 개인의 업무 만족도와 워라밸도 크게 향상될 것입니다.

“회의는 언제든지 할 수 있지만, 작업은 언제든지 진행될 수 있어야 합니다.” – 비동기 작업을 실천하는 팀 리더의 조언.

Summary

• Traditional work is meeting‑driven: discussions and conclusions happen spontaneously during meetings.
• It feels easy because you just follow the schedule (even a child can do it).
• Meeting‑driven approaches don’t support asynchronous work, so a new model is needed.
• Adopt a task‑driven approach: view all work and actions as tasks, manage them through a system, and update the task pages.
• Many are already familiar with this format through GitHub Issues.

배경

우리는 비동기 작업을 원하지만 회의‑중심 문화 때문에 이를 구현하지 못하는 경우가 많습니다. 엔지니어로서 우리는 방해받지 않고, 사무실 소음이나 끊임없는 소란 없이 선호하는 환경에서 일할 수 있는 자유를 소중히 여깁니다. 가끔씩 열리는 회의는 깊이 있는 논의를 위해 가치가 있을 수 있지만, 많은 조직이 사무실 근무로 되돌아가고, 원격 근무를 주장하는 조직조차도 온라인 회의에 크게 의존합니다.

왜 우리는 동기식 작업에서 벗어날 수 없을까요? 그 원인은 작업 모델에 있습니다: 우리는 회의‑중심이기 때문입니다.

새로운 모델이 필요합니다

회의‑중심 작업은 비즈니스를 수행하기 위해 회의에 의존합니다. 주요 특징은 두 가지입니다:

1. 즉흥적 커뮤니케이션 – 토론과 의사결정이 회의 중에 즉시 이루어집니다.
2. 수동적 실행 – 작업이 캘린더 일정에 따라 진행됩니다.

이는 학교 시간표와 비슷합니다—일정에 맞춰 참석하고 진행자의 분위기에 따릅니다. 아이도 할 수 있습니다, 매우 쉬운 작업 방식이죠. 그러나 이 접근 방식은 회의에 의존하기 때문에 비동기 작업을 수용할 수 없습니다. 근본적인 사고방식 전환이 필요합니다.

작업‑중심 접근법

작업‑중심 접근법은 모든 작업을 작업으로 간주하고, 시스템을 통해 관리하며, 이를 종료하는 것을 목표로 합니다.

• 모든 작업(활동 및 행동 포함)을 작업으로 봅니다.
• 비동기 접근이 가능한 시스템(예: 워크스페이스)에서 작업을 관리합니다.
• GitHub Issues와 같은 티켓 기반 형식은 간단합니다.
• 작업은 “상태”를 가지고 있으며, 닫히면 완료된 것으로 간주됩니다.

GitHub Issues에 익숙하다면 이 개념이 자연스럽게 느껴질 것입니다—본질적으로 모든 것을 Issue로 전환하는 것과 같습니다.

작업 중심 업무에 필요한 기술

회의 중심 업무는 회의를 조정하기 위한 커뮤니케이션 및 “사회적” 기술을 강조했습니다.
반면 작업 중심 업무는 강력한 작업 관리 기술을 필요로 합니다:

• 자체 관리로 수십(또는 수백) 개의 작업을 처리할 수 있는 능력.
• 작업을 효과적으로 문서화하기 위한 읽기 및 쓰기 능력.

전 / 후

전

매니저 M의 아침 일정 (회의 중심):

• 9:00 – 채팅, 이메일 및 기타 알림 확인
• 9:30 – 프로젝트 P1 일일 회의
• 10:00 – A와 1‑on‑1
• 10:30 – 회의 1
• 11:00 – 회의 2
• 11:30 – 업무

네 개의 회의가 9:30 – 11:30 구간을 차지하며, 각각 30분 동안 즉흥적인 토론과 의사결정을 위한 시간을 제공합니다. 따라하기는 쉽지만, 일정이 경직되어 있고 회의를 잡고 참석하는 데 상당한 노력이 필요합니다.

후

작업‑중심 하루 예시:

• 9:30 – 프로젝트 P1 일일 회의

Agenda (10 분): 어제 수행한 일과 오늘 할 일을 공유합니다 (참석자: A, B, C, D).
Discussion (20 분): 주제가 제기되고, 토론되며, 결론이 도출됩니다.

작업‑중심 접근 방식에서는 같은 회의를 개별 작업으로 나눌 수 있습니다:

• 작업: “오늘 계획 게시”
• 작업: “주제 1에 대한 의견 게시”
• 작업: “주제 1에 대한 결론 도출”
• 작업: “주제 2에 대한 의견 게시”
• 작업: “주제 2에 대한 결론 도출”
• …

이러한 작업은 GitHub Issues, 위키, 노트 또는 별도의 페이지와 열림/닫힘 상태를 지원하는 모든 도구에서 관리됩니다. 제목에 체크표시를 추가하는 등 창의적인 표현도 가능합니다. 작업이 시스템에 등록되면 비동기적으로 업데이트할 수 있으며, 멘션을 통해 알림을 보낼 수 있습니다.

After 시나리오에서 작업을 완료할 수 있나요?

답변: 예.

의심이 든다면, 아직도 회의‑중심 사고방식으로 일하고 있는 것입니다. 작업‑중심 업무는 자기 관리와 문서화 능력에 달려 있습니다. “After” 워크플로우를 능숙하게 다루는 것은 필수이며, 이러한 소프트 스킬은 종종 과소평가되고, 엔지니어, 매니저, 그리고 고위 직원들 사이에서도 격차가 흔히 나타납니다.

그래서 저는 Soft Skills Engineering 를 시작했습니다.