쓸데없는 회의 줄이기: 개발자의 시간을 지키는 법

저는 한동안 회의가 많다는 사실을 개발자의 숙명처럼 받아들였습니다. 오전에는 일정 공유 회의가 있었고, 점심 직후에는 기획 관련 논의가 이어졌으며, 오후에는 진행 상황을 확인하는 자리가 기다리고 있었습니다. 회의 사이에 남은 30분이나 40분 동안 코드를 조금 고치려 하면 곧바로 다음 일정이 시작됐습니다. 하루 종일 바쁘게 움직였는데도 정작 중요한 기능은 거의 진척되지 않는 날이 반복됐습니다. 그때부터 회의의 개수보다 회의가 정말 필요한 상황인지부터 따져보기 시작했습니다.

회의가 많아질수록 일이 잘되는 것은 아니었다

가장 먼저 발견한 문제는 회의 참석자와 목적이 지나치게 넓다는 점이었습니다. 작은 화면 문구 하나를 정하는 자리에 개발자 네 명, 기획자 두 명, 디자이너 한 명이 모두 들어왔습니다. 처음에는 여러 사람이 함께 들으면 오해가 줄어들 것이라고 생각했지만, 실제로는 각자가 자신의 의견을 길게 설명하는 시간이 늘어났습니다. 결정권자는 명확하지 않았고, 회의가 끝난 뒤에도 누가 무엇을 정리할지 정해지지 않았습니다. 모두가 참석했지만 누구도 책임 있게 결론을 기록하지 않은 셈입니다.
한 번은 로그인 화면의 오류 메시지를 바꾸는 일을 두고 50분짜리 회의를 했습니다. 저는 간단한 문구 변경과 확인 절차만 정하면 된다고 봤지만, 회의에서는 과거에 비슷한 문제가 있었는지, 향후 다른 화면에도 같은 표현을 적용할지, 사용자 문의가 늘어날 가능성이 있는지까지 이야기가 번졌습니다. 논의 자체가 틀린 것은 아니었지만, 그 자리에서 결정해야 할 범위를 넘어선 내용이 섞였습니다. 결국 회의가 끝난 뒤에도 문구는 확정되지 않았고, 다음 회의 안건으로 다시 올라왔습니다. 저는 이 경험을 통해 회의 시간이 길다고 판단의 품질이 높아지는 것은 아니라는 점을 배웠습니다.

회의를 잡기 전에 먼저 글로 확인하기

그 뒤부터 저는 회의 초대장을 받을 때 바로 참석 여부를 누르지 않았습니다. 먼저 안건이 한 문장으로 적혀 있는지, 회의가 끝났을 때 어떤 결정을 내려야 하는지, 제 참석이 꼭 필요한지 확인했습니다. 내용이 단순히 진행 상황 공유라면 문서나 메신저에 현재 상태를 남겨달라고 요청했습니다. 질문에 답하는 것만으로 충분한 경우에는 제가 알고 있는 내용을 짧게 작성했습니다. 이렇게 하니 회의에 들어가 같은 내용을 다시 듣는 일이 조금씩 줄었습니다. 특히 선택지가 두세 개로 좁혀진 안건은 글로 의견을 먼저 남기는 편이 훨씬 빠르게 결론에 도달했습니다.
물론 처음부터 모든 회의를 거절한 것은 아닙니다. 한번은 담당자가 회의 목적을 자세히 적어주었지만, 저는 문서로 답변하면 된다고 판단해 참석하지 않았습니다. 그런데 그 자리는 단순한 의견 수렴이 아니라 일정 변경 여부를 확정하는 자리였습니다. 제가 빠진 탓에 제 담당 업무의 순서가 잘못 정해졌고, 다음 날 다시 내용을 설명해야 했습니다. 이 실패 이후 저는 회의를 줄이는 것과 무조건 불참하는 것을 구분하게 됐습니다. 결정권이 있거나 제 업무의 방향이 바뀌는 자리라면 참석하되, 사전에 쟁점과 제 의견을 정리해 회의 시간을 짧게 만드는 쪽을 선택했습니다.

짧은 회의를 만드는 세 가지 기준

제가 지금 가장 중요하게 보는 기준은 목적, 참석자, 종료 조건입니다. 목적은 무엇을 논의하는지가 아니라 무엇을 결정할지로 적습니다. 참석자는 실제로 판단을 내리거나 필요한 정보를 제공하는 사람으로 제한합니다. 종료 조건은 결론과 담당자, 완료 시점을 남기는 것으로 정합니다. 예를 들어 새로운 기능의 일정 조정 회의라면 기존 일정의 문제점, 선택 가능한 일정 두 가지, 최종 결정권자를 미리 적습니다. 이 자료가 있으면 회의 중에 배경 설명을 길게 반복하지 않아도 되고, 참석자들이 각자 다른 문제를 이야기하는 상황도 줄어듭니다.
회의 시작 후에도 저는 안건에서 벗어난 이야기가 나오면 바로 메모해두고 별도 논의로 분리하려고 합니다. 예전에는 분위기를 깨고 싶지 않아 모든 이야기를 따라갔습니다. 그러다 보니 꼭 필요한 결정을 뒤로 미루고, 회의 막판에 시간이 부족해 대충 합의하는 일이 생겼습니다. 지금은 지금 결정할 내용과 나중에 확인할 내용을 구분해서 말합니다. 이 방법이 처음에는 조금 딱딱하게 느껴졌지만, 참석자들도 목적을 다시 확인할 수 있어 오히려 편해했습니다. 회의가 60분으로 예약되어 있어도 20분 만에 결론이 나면 그대로 끝내는 습관도 중요했습니다.

회의 없는 집중 시간을 일정에 넣기

회의를 줄이는 것만으로는 부족했습니다. 비어 있는 시간마다 다른 요청이 들어오면 개발자는 결국 짧게 끊긴 작업만 반복하게 됩니다. 그래서 저는 오전 한 구간을 집중 작업 시간으로 표시하고, 그 시간에는 회의 초대를 받지 않도록 팀과 약속했습니다. 긴 기능을 처음부터 끝까지 완성하지 못하더라도, 적어도 하나의 문제를 깊게 이해하고 다음 단계까지 진행할 수 있었습니다. 특히 원인을 추적하거나 구조를 정리해야 하는 업무는 15분 단위로 나누기 어렵기 때문에, 이런 보호 시간이 업무 품질에 큰 영향을 줬습니다.
처음에는 팀원들이 제가 협업을 피한다고 오해할까 걱정했습니다. 그래서 집중 시간의 목적을 개인 편의가 아니라 업무 결과와 연결해 설명했습니다. 긴급한 장애나 일정에 직접 영향을 주는 결정은 언제든 연락을 달라고 했고, 그 외의 질문은 문서에 남겨두면 집중 시간이 끝난 뒤 순서대로 답했습니다. 한 달 정도 지나자 팀에서도 그 시간에 회의를 잡지 않는 것이 자연스러워졌습니다. 모든 회의를 없앤 것은 아니지만, 꼭 필요한 자리를 더 준비된 상태로 진행할 수 있게 됐습니다. 회의 수를 줄이는 일은 개인의 의지만으로 되지 않고, 서로의 집중 시간을 존중하는 팀 규칙으로 자리 잡아야 한다는 점을 알게 됐습니다.

회의가 끝난 뒤까지 관리해야 하는 이유

회의를 효율적으로 운영해도 결과를 남기지 않으면 같은 대화가 반복됩니다. 저는 회의가 끝난 뒤 결정 사항, 담당자, 기한, 아직 풀리지 않은 질문을 네 줄 정도로 정리합니다. 길게 기록하려고 하면 금방 지치기 때문에 누가 읽어도 다음 행동을 알 수 있는 정도로만 씁니다. 이 기록이 있으면 며칠 뒤 같은 안건이 다시 나왔을 때 처음부터 설명할 필요가 없습니다. 반대로 기록이 없던 회의는 참석자마다 결론을 다르게 기억했고, 결국 서로의 이해가 맞는지 확인하는 추가 회의가 생겼습니다.
제가 회의에 대해 가장 크게 바뀐 생각은 회의가 협업의 증거가 아니라는 점입니다. 많은 사람이 한자리에 모였다는 사실만으로 일이 앞으로 나아간 것은 아닙니다. 결정이 분명하고, 필요한 사람만 참여하며, 회의 후 다음 행동이 이어질 때 비로소 의미가 생깁니다. 이번 주에 잡힌 회의 초대장을 보며 저도 다시 묻게 됩니다. 이 자리는 꼭 만나야 하는가, 글로 먼저 해결할 수 있는가, 끝났을 때 무엇이 달라져야 하는가. 독자분들도 모든 회의를 거부하기보다 이 세 가지 질문부터 조용히 적어보셨으면 합니다. 지켜낸 한 시간은 단순한 여유가 아니라, 더 깊이 생각하고 더 정확하게 만드는 개발자의 중요한 작업 시간입니다.