회의 중에 노트북으로 딴 짓하는 척 코드 보는 기술

01 Dec, 2025
- 일상

회의 중 노트북으로 딴 짓하는 척 코드 보는 기술: 개발자의 이중생활 가이드

프롤로그: 슬랙 알림과 함께 시작되는 악몽

월요일 오전 10시, 평화로운 개발 시간이 끝난다. 슬랙에 떴다.

“다들 회의실로 모여주세요. 분기별 로드맵 공유 회의입니다.”

심장이 철렁 내려앉는다. 로드맵 공유? 1시간은 족히 걸린다. 기획자는 항상 ‘이건 빠르게 끝낼 거예요’라고 하지만, 실제로는 파워포인트의 각 슬라이드마다 10분씩 설명한다. 그사이 서버에서는 뭔가 돌아가고 있다. 어제 배포한 API의 응답 시간이 괜찮은지, Redis 캐시가 제대로 워밍업됐는지, 에러 로그에 뭔가 쌓여있지 않은지. 회의실에 들어가는 순간, 그 모든 게 나를 부르고 있는 것 같다.

아, 그래서 우리는 이 기술을 터득했다. 회의 중에 노트북으로 딴 짓하는 척 코드 보는 기술.

7년 경력 개발자인 나도 처음엔 서툴렀다. 회의 중 슬랙을 봤다가 팀장한테 “김개발, 뭐 하냐?”라고 들었다. 기획자 앞에서 IDE 창을 켜려다가 키보드 백라이트가 반짝여서 눈에 띴다. 하지만 지금은 다르다. 이건 단순한 기술이 아니라, 생존 기술이다.

회의의 정체: 우리가 피할 수 없는 현실

먼저 인정해야 할 것이 있다. 모든 회의가 쓸모없진 않다. 그런데 우리가 참석하는 대부분의 회의는… 음, 쓸모없다.

우리 회사 달력을 보면 이해할 수 있다:

월요일 조회: “이번 주 계획을 얘기하는” 회의인데, 결국 지난주 결과를 재탕한다
수요일 동기화: “크로스펑셔널 커뮤니케이션”이라는 명목의 30명 대회의, 내가 할 말은 없다
목요일 회고: 아직도 회고가 끝나지 않았다는 게 신기하다
금요일 플래닝: 점심 때문에 자리를 비운 사람이 반 이상이다

그리고 여기 추가로, 갑자기 소집되는 기획 회의들. “개발팀이 빨리 끝낼 수 있을 것 같아서요”라는 말과 함께.

요청사항은 언제나 간단해 보인다. “그냥 이거 버튼 추가해 주시고, 데이터베이스에 컬럼 하나만 더하면 되겠네요?” 그런데 나는 안다. 그 “버튼 하나”가 얼마나 많은 것들을 건드리는지. 마이그레이션, 롤백 전략, 캐시 무효화, 테스트 케이스… 아무도 이걸 모른다.

그래서 회의 중에 나는 코드를 본다. 실제로 그 “버튼 하나”를 어디에 어떻게 붙일지 생각하면서, 동시에 기획자의 말을 들었다는 척한다. 이건 이중생활이 아니라 생존 기술이다.

기본기: 외적 완벽성의 추구

이 기술의 핵심은 한 가지다. 보이는 것이 전부다.

처음 시작할 때 실수하기 쉬운 부분부터 말하자면:

1단계: 각도 조절의 중요성

노트북 화면을 옆 사람이 볼 수 없도록 해야 한다. 각도는 약 45도가 최적이다. 정면에 가까워지면 정신을 차리고 있는 것처럼 보이고, 너무 누우면 진짜 딴짓하는 것처럼 보인다. 45도에서는 “열심히 정리하고 있는 척”하는 완벽한 각도가 된다.

내 팀의 시니어 개발자 이준호는 이걸 마스터한 사람이다. 그의 노트북은 항상 기울어져 있고, 카메라가 정면을 향하고 있으며, 그의 손은 언제나 마우스패드나 트랙패드 근처에 있다. 누군가 다가올 때면 갑자기 손을 이동시켜서 “아 이거요”라고 대응할 수 있는 준비 자세를 유지한다.

2단계: 표정과 제스처

코드를 보면서 이 표정을 지켜야 한다:

미간에 조금의 주름이 있어야 한다 (생각하는 모습)
눈은 화면에 집중하되, 2분마다 한 번씩 회의 진행자를 본다
마우스를 매 30초마다 움직인다 (살아있는 커서)
가끔 고개를 끄덕인다

이건 마치 배우가 역할을 하는 것처럼 보일 수도 있지만, 실제로는 우리 뇌의 일부가 진짜 회의를 듣고 있다. 기획자가 “이 기능의 우선순위는?”이라고 나에게 질문을 던지면, 우리의 뇌는 동시에 여러 스레드를 실행한다:

Thread 1: Redis 응답 시간 분석
Thread 2: 기획자의 말 파싱
Thread 3: "아 그거요"라는 말이 자연스러울지 판단
Thread 4: 다음 슬라이드 준비

다중 작업 처리 능력이 정말로 개발됐다.

3단계: 음성 신호

“음”, “네”, “맞아”, “그렇네” 같은 짧은 음성 신호를 정기적으로 발생시킨다. 이건 피드백이다. 아무말도 하지 않으면 이상하다. 하지만 너무 자주 말하면, 회의에 다른 사람들이 자신에게 말을 걸어야겠다는 신호가 된다. 최적의 주기는 약 1분 30초에 한 번.

회의가 진행되고 있고 누군가 발표하고 있을 때, 나는 코드 리뷰를 열어본다. 어제 PR에서 한 후배가 올린 커밋을 본다. “왜 이 부분에서 Optional을 사용했지? NPE 가능성이 있는데…”라고 생각하면서 동시에 “정확해요”라고 중얼거린다. 이건 회의에도 참여하는 것처럼 보이고, 실제로는 기술 부채를 갚고 있는 중이다.

심화 기술: 다양한 회의 상황별 가이드

모든 회의가 같지는 않다. 각 상황에 맞는 전략이 필요하다.

기획 회의 (위협 레벨: 매우 높음)

기획자가 발표하는 회의는 가장 위험하다. 자신이 준비한 것을 보여주는 상황이기 때문에, 기획자는 누가 집중하고 있는지 본능적으로 감지한다. 마치 고양이가 움직임을 감지하듯이.

이때는 깊은 참여가 필요하다. 노트북을 너무 많이 사용할 수 없다. 대신 그림을 그려야 한다. 종이에, 기획 내용을 다이어그램으로 그린다. 이건 매우 영리한 방법이다. 왜냐하면:

기획자 입장에서 보면 “오, 이 개발자는 내 말을 정말 진지하게 받아들이고 있네?”라고 생각한다
실제로는 우리는 그리면서 기술적 구현 방법을 생각하고 있다
나중에 “여기 이 부분은 기술적으로…”라고 말할 때 그림이 있으니까 권위 있어 보인다

내 노트북 옆에는 항상 A4 종이와 펜이 있다. 기획 회의 직후 휴지통에 들어가는 그 다이어그램들. 하지만 그건 훌륭한 투자다. 기획자의 신뢰를 얻고, 동시에 기술 분석까지 하는 일석이조의 효과.

스탠드업 회의 (위협 레벨: 낮음)

스탠드업은 가장 쉽다. 왜냐하면 다들 서 있기 때문이다. 앉아서 노트북을 할 수 없다. 이때는 진짜로 슬랙을 본다. 아무도 상관하지 않는다.

회고 회의 (위협 레벨: 중간)

여기는 감정이 섞여있다. 좋은 것도 있고, 개선해야 할 것도 있다. 이때 노트북을 사용하면 “저 사람 이미 다음 스프린트 생각해?”라는 인상을 줄 수 있다. 좋은 인상이다. 실제로 나는 항상 회고 회의 중에 다음 스프린트 백로그를 정리한다. 이건 회의의 목적과도 맞는다.

CEO 타운홀 (위협 레벨: 극도로 높음)

모든 직원이 참석하는 회의다. CEO가 발표한다. 이때는 절대 노트북을 켤 수 없다. 왜냐하면 회의실 전면의 스크린에 참석자 명단이 떠 있거나, 누군가가 녹화를 하고 있기 때문이다. 이때는 핸드폰을 본다. 그리고 손에는 메모지를 든다. 메모지에는 아무것도 쓰지 않는다.

CEO 발표는 항상 비슷하다. “올해는 AI 기술에 집중합니다”, “고객 만족도를 높여야 합니다”, “비용 절감을 목표로 합니다”. 우리 개발팀은 안다. 이게 뭘 의미하는지. 더 짧은 마감시간으로 더 많은 기능을 만들라는 뜻이다.

도구와 준비물: 프로 설정

이 기술을 제대로 하려면 환경 설정이 중요하다.

노트북 세팅

내 MacBook Pro는 전술적으로 배치되어 있다:

배경화면: 회사 프로젝트 이름이 있는 네이비 + 회사 로고. 너무 개인적이면 의심받는다
독(Dock): 일 관련 앱만 보이도록. Slack, IDE, 브라우저, 노션
데스크탑: 깔끔하게. 파일이 많으면 산만해 보인다
키바인딩: 빠른 전환을 위해 커맨드+탭을 마스터해야 한다

회의 5분 전에, 나는 이 루틴을 한다:

IDE 열기 → 어제 작업하던 브랜치 열기
Datadog 또는 NewRelic 열기 (서버 모니터링)
슬랙 음소거 (슬랙 핑 소리만 들으면 회의 집중력이 떨어진다)
밝기 조절 (너무 밝으면 눈에 띈다)

추가 도구

외장 마우스: 트랙패드보다 자연스럽다. 손가락으로 탭탭 거리는 것보다 마우스를 들었다 놨다 하는 게 더 “일하는 느낌”을 준다
종이와 펜: 위에서 언급했듯이, 기획 회의에서 필수
헤드폰: 회의 직후 슬랙 메시지를 받을 때 사용. 회의 중에는 안 쓴다. 회의에 참여하지 않는 것처럼 보인다
커피/물: 들었다 놨다를 반복하면 “바쁜 사람” 이미지를 준다

윤리적 경계선: 우리는 완전히 나쁘지만은 않다

여기서 중요한 걸 말해야 한다. 이 기술은 악의는 아니다.

예를 들어, 내가 어제 배포한 마이크로서비스의 응답 시간이 평소보다 300ms 높아졌다면? 나는 회의 중에 그걸 봐야 한다. 왜냐하면 사용자가 경험하는 시간이 증가하고 있기 때문이다. 이건 긴급하다. 회의보다 우선순위가 높다.

또는 후배가 올린 PR에서 심각한 SQL injection 취약점을 발견했다면? 나는 회의 중에 코멘트를 남겨야 한다. 왜냐하면 그게 프로덕션에 들어가면 회사 데이터가 위험해지기 때문이다.

그런데 그게 아니라면? 예를 들어, 회의는 진짜 중요하고, 내 의견이 필요한 상황이라면? 그럼 노트북을 덮어야 한다. 이건 기술의 올바른 사용법이다.

내 경험상, 회의의 80%는 정말로 불필요하고, 20%는 정말로 중요하다. 문제는, 시작할 때 어느 것인지 모른다는 것이다. 그래서 우리는 이 기술을 개발했다. 처음 10분은 준비 자세를 유지하다가, 정말로 불필요하다는 것을 확인한 후에 코드를 본다.

실제 상황: 회의 중 코드로 문제를 푼 날들

이 기술이 정말로 가치를 발휘한 순간들이 있다.

사건 1: 쿼리 최적화가 필요했던 날

분기 기획 회의 중이었다. 기획자가 새로운 대시보드 기능에 대해 설명하고 있었다. “사용자별 통계를 실시간으로 볼 수 있는 기능입니다.”

내 뇌는 두 가지를 동시에 생각했다:

기획 내용 파싱: “리얼타임 대시보드, 차트 표시, 필터링”
기술 부채 감지: “어제 배포한 사용자 통계 쿼리가 30초 걸렸는데…”

그래서 나는 조용히 IDE에서 그 쿼리를 열었다. 회의가 진행되는 동안, 내 손은 인덱스를 추가하고 있었다. 그리고 로컬에서 다시 실행했다. 3초.

회의가 끝났을 때, 기획자가 물었다. “김개발, 이 기능 구현 난이도는?”

나는 대답했다. “쿼리 최적화가 필요한데, 제가 이미 일부를 테스트했습니다. 내일까지 프로토타입을 만들 수 있을 것 같아요.”

기획자의 표정이 밝아졌다. 나는 “진짜로 집중하고 있었나봐”라는 인상을 주었다. 실제로는 회의 중 거의 모든 개발을 끝낸 것이다.

사건 2: 후배의 실수를 회의 중에 발견

월요일 회의에서, 지난주 배포 리뷰를 하고 있었다. 팀장이 “배포가 순조롭게 진행되었다”고 얘기했다.

나는 슬랙에서 배포 로그를 봤다. 그리고 발견했다. 후배가 올린 코드에서 트랜잭션 롤백이 제대로 설정되지 않았다. 데이터베이스 연결이 끊기면 부분 처리된 데이터가 남아있을 수 있는 상황이다.

나는 회의가 끝나고 즉시 PR을 닫고, 후배를 불러서 설명했다. “다음 배포에서 이 부분을 수정해야 해. 지금은 문제 없지만, 트래픽이 증가하면 이슈가 터질 거야.”

후배는 고마워했다. 만약 회의 중에 코드를 보지 않았다면, 이 버그는 한두 달 뒤에 프로덕션에서 터졌을 것이다.

사건 3: 기획자의 불가능한 요청을 기술적으로 거절하기

“이 기능 이번 스프린트에 가능할까요?”

기획자의 질문에, 나는 노트북으로 현재 진행 중인 작업들을 확인했다. 동시에 기획자가 설명하는 새 기능의 복잡도를 머릿속으로 계산했다.

스토리 포인트: 13 (충분히 크다) 현재 용량: 32 포인트 (이미 꽉 참) 남은 포인트: 5

“아, 이번 스프린트에는 용량이 부족할 것 같습니다. 다음 스프린트는 어떨까요?”

기획자는 동의했다. 왜냐하면 나는 “아무래도 어려울 것 같은데”가 아니라, 구체적인 포인트와 이유로 설명했기 때문이다. 회의 중에 노트북으로 정보를 수집했기에 가능했던 일이다.

주의할 점: 들킬 수도 있다

사실 이 기술에도 리스크가 있다.

리스크 1: 카메라

요즘은 온라인 회의가 많다. 화상 회의에서는 카메라가 활성화되어 있다. 내 화면이 보이지는 않지만, 내 손과 시선이 보인다. 이때는 매우 조심해야 한다. 눈이 화면을 본다면, 사람들은 내가 뭘 보고 있는지 궁금해한다.

해결책: 화상 회의 중에는 덜 한다. 또는 화면을 공유하는 사람의 스크린을 보는 척하면서 동시에 폰으로 슬랙을 본다.

리스크 2: 팀장

우리 팀장은 “이 회의 필요해?”라는 타입이다. 즉, 회의를 싫어한다. 그런데 회의는 여전히 많다. 회의 중에 내가 코드를 본다는 것을 알지만, 팀장은 나한테 뭐라고 하지 않는다. 왜냐하면 팀장도 회의 중에 이메일을 본다.

우리 회사 문화는 “정직한 불만족”을 허용한다. 일이 불가능하면 불가능하다고 말한다. 회의가 불필요하면 불필요하다고 말한다. 그 대신 권장사항은, 회의를 최대한 짧게 만드는 것이다.

리스크 3: 진짜로 필요한 의견이 필요할 때

가끔 기획자가 정말로 기술 의견이 필요한데, 나는 화면만 보고 있다. 이때 순간적인 반응 시간이 0.5초 길어진다. 이건 매우 어색해 보인다.

“어라, 왜 대답이 없지? 아, 화면 보고 있구나”

이런 생각을 하게 된다. 그래서 나는 중요한 회의는 정말로 집중한다. 처음부터 끝까지. 이건 신뢰 관계다.

더 깊은 고민: 이게 맞는 걸까?

요즘 들어 이런 생각이 든다. 정말로 회의가 필요 없는 걸까, 아니면 내가 회의 문화에 적응하지 못하는 걸까?

아니다. 회의는 정말로 필요 없다. 우리 회사는 3일마다 “동기화” 회의를 한다. 동기화? 우리는 슬랙에서 이미 동기화되어 있다. 하지만 인간관계가 필요하다고 생각한다. 그래서 회의가 있다.

인간관계를 원하면서, 동시에 “회의는 쓸모없다”고 느끼는 우리의 이중성. 이건 현대 업무 문화의 모순이다.

하지만 현실은 현실이다. 그래서 우리는 이 기술을 계속 사용할 것이다. 회의 중에 코드를 본다. 동시에 회의에 참여하는 척한다. 이건 악의 없는 생존 전략이다.

그리고 언젠가, 누군가가 “회의 시간을 50% 줄여봅시다”라고 제안할 때, 우리는 손을 들고 동의할 것이다. 하지만 그때까지는, 우리의 이중생활이 계속된다.

에필로그: 내일도 같은 방식으로

오늘 오후에도 “긴급 기획 회의”가 있다. 새로운 스타트업 파트너의 API 연동에 대한 것이다. 기획자는 “30분만 할 거예요”라고 했다.

30분. 나는 이 말을 이제 믿지 않는다.

그래서 노트북을 준비했다. IDE도, 모니터링 대시보드도, PR 리스트도 모두 준비했다. 그리고 준비했다. “이거 구현할 때 이쪽에서 이렇게 해야겠네”라는 생각을 하면서, 동시에 기획자의 말을 듣는 준비를.

이건 개발자의 숙명이다. 우리는 이런 회의들과 함께 살아간다. 그리고 우리는 이렇게 생존해왔다.

내일 또 다른 회의가 있을 것이다. 그리고 나는 또 다시 노트북으로 코드를 볼 것이다. 외적으로는 회의에 참여하면서, 내적으로는 코드와 함께.

이게 우리의 이중생활이다. 그리고 이제는 이것이 자연스럽다.

결국 회의는 피할 수 없지만, 회의 중 코드는 피할 수 있다는 게 우리의 비밀이다.