노미팅 + Linear board-only 운영 모델

외주 개발을 맡겨본 경험이 있다면 이런 흐름을 한 번쯤 겪어봤을 것이다. 요구사항은 KakaoTalk으로, 수정 요청은 이메일로, 진행 현황은 Slack으로, 그리고 "어떻게 됐어요?"는 전화로. 요청 하나를 추적하려면 채널 네 개를 뒤져야 한다. 결정이 어디서 내려졌는지, 누가 뭘 동의했는지 — 기록이 흩어져 있다.

이 문제는 개인의 잘못이 아니다. 채널이 여러 개면 자연스럽게 일어나는 일이다. 중요한 결정이 KakaoTalk 채팅 흐름 속에 묻히고, 이메일 수신함의 특정 스레드를 찾지 못하면 맥락이 사라진다. 클라이언트가 "저번에 이렇게 말씀하셨잖아요"라고 해도 어느 채널의 어느 메시지였는지 찾는 데 시간이 걸린다.

Gaebari는 이 구조를 다르게 만들었다.

규칙은 단순하다

구독 시작 이후 모든 태스크 커뮤니케이션은 Linear 보드 하나에서만 이루어진다. KakaoTalk 없음. 전화 없음. 이메일 스레드 없음.

요청을 올린다 → 이슈가 생긴다 → 작업이 시작된다 → 결과물이 댓글로 달린다 → 수정 요청은 같은 이슈 안에서 처리된다. 히스토리는 이슈에 붙어 있다. 보드를 열면 현재 상태가 보인다. 따로 물어볼 필요가 없다.

채널이 하나라는 것은 기록이 하나라는 뜻이다.

Linear를 선택한 이유

개발팀이 이미 사용하는 도구들 — Jira, Notion, GitHub Issues, Trello — 중에서 Linear를 선택한 이유는 몇 가지다.

퍼포먼스. Linear는 로딩이 빠르다. Jira는 동일한 작업을 하는 데 클릭 수와 로딩 시간이 더 든다. 클라이언트가 보드를 열었을 때 느리면 사용 빈도가 줄어든다.

접근 제어. Linear 워크스페이스 구조상 고객은 자신의 팀만 볼 수 있다. 다른 클라이언트의 작업이 노출되지 않는다. Notion shared space나 GitHub 조직 레벨 접근 제어보다 설정이 단순하다.

이슈 상태 워크플로우. Backlog → In Progress → In Review → Done의 네 단계가 Gaebari 운영 사이클과 정확히 맞아 떨어진다. 커스터마이징이 필요 없다.

드래그 우선순위. 클라이언트가 이슈 순서를 드래그해서 우선순위를 직접 설정할 수 있다. "이번 주에는 이거 먼저 해주세요"를 전달하기 위해 메시지를 보낼 필요가 없다.

Brett Williams runs Designjoy — a design subscription service — using a public Trello board as the primary work surface. Clients queue requests, Williams works top to bottom, and the board is publicly visible. The service reached $3M ARR with this mechanic as the core operational model.

Gaebari는 이 메커니즘을 개발 서비스에 적용하면서 두 가지를 변경했다: Trello에서 Linear로(개발 워크플로우에 더 맞음), 그리고 클라이언트 익명화를 추가해 공개 live board를 만들었다.

클라이언트 입장에서

우선순위는 클라이언트가 직접 설정한다. Linear 보드에서 이슈 순서를 드래그하면 된다. 위에 있는 것부터 처리된다. 상태 회의가 필요 없다 — 보드를 보면 지금 무슨 작업이 In Progress인지, 무엇이 In Review를 기다리고 있는지 실시간으로 보인다.

수정 요청도 같은 이슈 안에서 댓글로 달면 된다. "이 부분 다시 해주세요"라는 댓글이 그 이슈의 히스토리에 남는다. 나중에 "어떤 맥락이었지?"를 찾아야 할 때 검색할 채널이 하나다. 이슈 번호만 알면 그 태스크와 관련된 모든 대화, 결과물 링크, 수정 이력이 한 곳에 있다.

태스크 히스토리가 온전히 Linear에 있기 때문에, 구독을 취소하거나 개발사를 바꾸게 될 때도 인수인계 비용이 낮다. 요청의 맥락, 결과물 링크, 수정 이력이 모두 이슈 안에 있다. "제가 언제 뭘 요청했는지"를 새 개발사에 정리해서 전달하는 비용이 최소화된다.

무제한 태스크는 보드에 쌓아두면 된다. 오늘 생각나는 것들을 다 올려두고 우선순위를 나중에 조정해도 된다. 각 이슈는 스펙이 명확해지면 그때 처리할 수 있다. 백로그는 단순히 할 일 목록이 아니라 제품 계획의 저장소이기도 하다.

운영자 입장에서

채널이 분산되면 context switch 비용이 커진다. KakaoTalk 알림 확인, 이메일 수신함 확인, Slack 스레드 확인 — 채널마다 상태를 들고 있어야 한다. "어디서 무슨 요청이 있었더라"를 파악하는 데 아침 30분이 소비되기도 한다.

채널이 하나면 아침 시작이 단순하다. Linear 보드를 열면 현재 상태가 전부 보인다. 어제 어디까지 했는지, 오늘 무엇부터 시작해야 하는지가 하나의 뷰에 있다.

“When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon by breaking it into two pieces each too small to do anything hard in.”

감사 추적도 단순해진다. "클라이언트가 X를 언제 요청했지?"라는 질문의 답이 하나의 장소에 있다. "저는 그렇게 말한 적 없는데요"라는 상황도 사라진다. 텍스트가 기록으로 남아 있기 때문이다. 이 명확성은 분쟁 방지뿐 아니라 일상 운영에서도 시간을 아낀다.

아침 보드 처리 — 30분 루틴

채널이 하나라는 구조는 운영 루틴도 단일화한다. Gaebari 운영자의 아침 처리 순서는 매일 동일하다.

1단계 — Backlog 스캔 (5분). Linear 보드를 열고 Backlog 컬럼에서 어제 들어온 신규 이슈와 클라이언트가 우선순위를 위로 끌어올린 이슈를 확인한다. 새 이슈는 스펙이 명확한지(작업 시작 가능한지) 1차 판단한다. 모호한 경우 댓글로 명확화 질문을 남기고 In Progress로 옮기지 않는다.

2단계 — In Progress 갱신 (10분). 어제 작업하던 이슈에 진행 상황 댓글을 단다. PR 링크, 스크린샷, 다음 단계. 이 댓글이 클라이언트가 보드를 열었을 때 보는 신호다 — "어디까지 진행됐고 다음에 뭐가 일어나는지"를 메시지 받지 않고도 확인할 수 있다.

3단계 — In Review 처리 (10분). 클라이언트가 검토 중인 이슈에 추가 코멘트가 달렸는지 확인한다. 수정 요청이 있으면 같은 이슈 안에서 답변하고 In Progress로 다시 옮긴다. 승인 댓글이면 Done으로 이동한다.

4단계 — 일일 한계 (5분). 동시 진행은 1개 슬롯당 1개 이슈만 허용한다. 이 규칙을 깨면 처리량이 늘어나는 것처럼 보이지만 평균 SLA가 망가진다. 두 번째 이슈를 시작하려는 충동이 들 때 — 첫 번째 이슈가 정말 In Review로 넘어갔는지, 아니면 마무리를 미루고 있는 것인지 점검한다.

이 루틴은 회의가 아니다. 한 명이 30분간 보드 한 곳에서 처리한다. 회의 일정 조율, 회의록 작성, 후속 액션 항목 추출 같은 단계가 없다. 보드 상태 변경 자체가 후속 액션의 기록이다.

예외: 인테이크 단계

보드 전환에도 예외는 있다. 최초 연락은 보드 밖에서 일어난다.

gaebari.com/apply 폼을 제출하면 운영자가 1 영업일 이내에 이메일 또는 SMS로 응답한다 — 슬롯 여부 확인, 온보딩 플로우 안내가 주 내용이다. 구독이 시작되면 그 이후 모든 것은 Linear 보드로 넘어온다.

인테이크 폼 → 1일 SLA 응답 → 보드 시작이라는 단일 경로다. 이메일이나 카카오로 먼저 연락한 후 보드로 옮기는 방식이 아니다.

이 예외가 필요한 이유: 보드는 구독 시작 후에 생성된다. 잠재 클라이언트는 보드 접근 권한이 없다. 따라서 첫 접점은 필연적으로 보드 밖에 있다. 다만 그 접점이 "이메일로 보내주세요" + "카카오로 연락하세요" + "전화 주세요"처럼 분산되지 않도록, 단일 폼으로 모인다.

공개 Live Board — 말 대신 증거

클라이언트가 "제대로 하고 있나요?"라는 질문을 갖는 것은 자연스럽다. 전통적인 답은 "안심시켜드리겠습니다"라는 말, 또는 통화다.

Gaebari의 답은 gaebari.com의 공개 live board다.

방문자는 현재 몇 개의 슬롯이 활성 상태인지, 태스크들의 현재 상태(Backlog / In Progress / In Review / Done)를 실시간으로 볼 수 있다. 카드 타임스탬프로 각 태스크가 얼마나 걸리고 있는지 확인할 수 있다. 지난 30일간 완료된 태스크 수도 집계된다.

Linear GraphQL API를 Next.js ISR(revalidate: 60)로 폴링한다. 약 60초 간격으로 갱신되므로 Linear에서 상태가 바뀌면 90초 이내에 반영된다. WebSocket이 아니라 폴링을 선택한 이유는 단순하다: 보드의 가치는 "작업이 진행 중이라는 것을 보여주는 것"이지 "실시간으로 움직이는 것"이 아니다. 60초 지연은 충분하고, 연결 상태 관리 비용을 없앤다.

클라이언트 익명화는 서버 단에서 처리된다. Linear API 쿼리가 title, description, assignee 필드를 요청하지 않는다 — 브라우저에 내려가기 전에 데이터가 없는 것이다. 클라이언트 입장에서는 자신의 작업이 공개 보드에 노출되지 않는다는 보장이다. 공개 보드에서 보이는 것은 태스크 상태, 타임스탬프, 시퀀스 번호뿐이다.

익명화 보장 — 서버 단 메커니즘

"클라이언트 작업이 공개 보드에 노출되지 않는다"는 약속은 운영자의 선의에 기대지 않는다. 메커니즘으로 보장된다.

1. GraphQL 쿼리 화이트리스트. Linear API 호출은 화이트리스트된 필드만 요청한다. state, createdAt, updatedAt, team.id(워크스페이스 식별용) 정도다. title, description, assignee.name, assignee.email은 요청 자체에 들어가지 않는다 — 브라우저로 내려갈 데이터가 애초에 서버에 도달하지 않는다.

2. 시퀀스 번호 매핑. 공개 보드의 카드는 Task #142처럼 일련번호로 표시된다. 이 번호는 Linear 내부 ID와 별개로 ISR 빌드 시점에 운영자 워크스페이스 기준으로 카운터가 부여된다. 외부에서 시퀀스 번호로 클라이언트나 회사를 역추적할 단서가 없다.

3. 서버 사이드 렌더링. Next.js ISR은 서버에서 페이지를 빌드해 정적 HTML로 내려보낸다. 브라우저는 Linear API에 직접 접근하지 않는다 — Linear 토큰이 클라이언트로 노출될 가능성 자체가 차단된다. 빌드 결과물에는 화이트리스트된 필드만 박혀 있다.

4. 캐시 보안 헤더. 공개 보드 페이지는 60초 캐시 + ISR revalidate 60초로 구성된다. CDN 단에서 같은 정적 응답이 모든 방문자에게 동일하게 내려간다 — 사용자별 분기가 없으므로 캐시 leakage 위험이 없다.

이 4단 구조는 "운영자가 실수로 필드를 추가해도 외부 노출되지 않는다"는 의미는 아니다. 운영자가 GraphQL 쿼리에 title을 추가하면 그 시점부터 공개 보드에 노출된다. 다만 변경이 git 커밋으로 기록되고, 코드 리뷰가 가능한 형태라는 점이다 — 사후 감사 가능한 변경 경로다. PR 리뷰 단계에서 잡히지 않으면 다음 빌드부터 노출되는 위험이 있다는 한계는 솔직히 인정한다.

트레이드오프

이 모델이 모든 클라이언트에게 맞는 건 아니다.

전화 통화로 관계감을 확인하고 싶은 클라이언트, "잠깐 통화 한 번 하면 되잖아요"가 자연스러운 운영 방식인 클라이언트에게 이 모델은 불편하다. 첫 주에 적응이 필요하다. "보드를 열면 돼요"라는 답이 처음엔 차갑게 느껴질 수 있다.

Gaebari의 판단은: observable work가 verbal reassurance보다 실질적인 신뢰 신호라는 것이다. 보드에서 In Progress 카드의 타임스탬프를 확인하는 것과 "열심히 하고 있습니다"를 통화로 전달받는 것은 다르다. 전자는 확인 가능하고, 후자는 그렇지 않다.

다른 트레이드오프: 보드 작성 부담이 있다. 태스크를 Linear 이슈로 올리는 것은 KakaoTalk으로 "이거 해주세요"를 보내는 것보다 약간 더 많은 작업이다. 스펙을 어느 정도 정리해서 이슈 설명에 쓸 수 있어야 한다. 반대로, 이 부담이 자연스러운 스펙 명확화로 이어지기도 한다 — 이슈에 쓰려고 정리하다 보면 막연했던 요구사항이 구체화된다.

"급한 건 카카오로 연락해도 되죠?"라는 질문을 받는다. 안 된다. 채널 규율이 일관된 응답 시간을 만든다. 급한 것은 보드에서 맨 위로 올리면 된다.

실무 운영 요약

One team per customer in the Linear workspace. Customer only sees their own team. Developer (operator) has admin access to all teams. One-at-a-time enforcement: only one issue moves to In Progress at a time across all customers.

All requests go through a dedicated board (Linear). No KakaoTalk, phone, or email. One channel keeps the record clean and responses fast.

FAQ

자주 묻는 질문

정말 통화가 전혀 없나요?

네. 모든 요청과 응답은 보드에 텍스트로 남습니다. 화면 설명이 필요한 경우 짧은 영상 녹화로 대체합니다. 통화 시간이 줄어드는 만큼 작업 시간이 늘어납니다.

긴급 요청은 어떻게 처리하나요?

Linear 보드에서 해당 이슈를 맨 위로 올리면 됩니다. 우선순위 조정은 클라이언트가 직접 합니다. KakaoTalk이나 전화로 연락하더라도 보드에 이슈로 올라오기 전에는 작업이 시작되지 않습니다.

Linear를 처음 써보는데 어렵지 않나요?

기본 사용법은 단순합니다. 이슈 생성, 댓글 작성, 순서 드래그 — 세 가지가 전부입니다. 구독 시작 시 온보딩 안내를 제공합니다.

보드에 올린 내용이 다른 클라이언트에게 보이나요?

보이지 않습니다. Linear 워크스페이스에서 각 클라이언트는 자신의 팀만 볼 수 있습니다. 공개 live board(gaebari.com 홈페이지)에는 태스크 상태와 타임스탬프만 노출되고, 제목이나 내용은 서버 단에서 제거됩니다.

구독을 취소하면 Linear 접근이 바로 끊기나요?

현재 결제 기간이 끝날 때 보드 접근이 제거됩니다. GitHub 레포지토리 접근은 즉시 이전됩니다. 모든 이슈 히스토리의 인수인계 문서를 작성해 드립니다.

---

슬롯 문의: gaebari.com/apply