스타트업을 위한 의사 결정 로그
스타트업은 매주 수백 가지 결정을 내립니다. 대부분은 Slack 스레드와 잊혀진 회의 속으로 사라집니다. 실제로 유지되는 의사 결정 로그를 만드는 방법을 알아보세요.
By Ellis Keane · 2026-03-16
1986년, 우주왕복선 챌린저호가 발사 73초 만에 공중 분해되었습니다. 이후 조사를 통해, 모튼 티오콜의 엔지니어들이 전날 밤 O링 씰에 대한 우려를 제기하며 추운 날씨에 발사는 안전하지 않다고 주장했다는 사실이 밝혀졌습니다. 관리진은 이를 무시했습니다. 결정은 전화 회의에서 내려졌고, 차트와 증언이 존재했지만 이 결정을 뒤집은 핵심 논거는 참가자들 사이에서 분산되어 있었고 지휘 체계를 통해 안정적으로 전달되지 않았습니다.
여러분의 스타트업 제품 결정을 우주왕복선 참사에 비유하는 것은 아닙니다(음, 대부분은 그렇지 않겠죠). 하지만 근본적인 실패 패턴은 제가 스타트업에서 매주 목격하는 것과 동일합니다 – 다만 더 낮은 위험 수준에서요. 결정이 내려지고, 그 배경이 누군가의 머릿속이나 곧 스크롤되어 사라질 Slack 스레드 속에 존재하다가, 3개월 후에는 왜 접근법 A 대신 B를 선택했는지 아무도 재구성하지 못합니다. 결정이 잘못되었기 때문이 아니라 – 때로는 훌륭한 결정이었더라도 – 그것을 올바르게 만들었던 맥락이 사라져버렸기 때문입니다.
"결정이 내려지고, 그 배경이 누군가의 머릿속이나 곧 스크롤되어 사라질 Slack 스레드 속에 존재하다가, 3개월 후에는 왜 접근법 A 대신 B를 선택했는지 아무도 재구성하지 못합니다." – Ellis Keane
스타트업을 위한 의사 결정 로그는 관료적인 작업이 아닙니다. "그건 시도해봤는데 안 됐어요"(유용함)와 "그거 언젠가 얘기한 것 같은데요?"(쓸모없음)의 차이입니다.
잃어버린 결정의 해부
추상적인 버전보다 구체적인 예가 더 설득력 있기 때문에, 특정 결정이 그 생애주기를 어떻게 거치는지 추적해 보겠습니다.
2월의 어느 화요일. 엔지니어링 책임자와 PM이 Slack 스레드에서 커스텀 알림 시스템을 구축할지 서드파티 서비스를 사용할지 논의 중입니다. 스레드는 47개의 메시지로 이루어져 있고(알아요, 하지만 그게 현실입니다), 38번째 메시지쯤에서 커스텀 구축은 3개의 스프린트가 필요하고 출시 기한이 두 달 후라는 이유로 서드파티 옵션으로 결론이 납니다.
PM이 Linear 이슈를 생성합니다: "알림을 위해 [서비스 X] 통합." 엔지니어가 이를 맡아 구축을 시작합니다. Slack 스레드는 기술적으로 여전히 거기 있지만, 아무도 북마크하지 않고 Linear 이슈에서 링크하지도 않습니다.
5월로 빠르게 이동합니다. 서드파티 서비스에 신뢰성 문제가 생겼습니다. 누군가 묻습니다: "왜 우리가 직접 만들지 않았을까요?" PM은 대화를 기억하지만 세부 사항은 기억하지 못합니다. 엔지니어링 책임자는 육아 휴직 중입니다. Slack 스레드는 2월의 #engineering 채널 어딘가에 있지만, 아무도 정확한 날짜를 기억하지 못하고, "notification"으로 Slack 검색을 하면 200개의 결과가 나옵니다(당연히, 모든 팀이 항상 알림에 대해 논의하니까요).
팀은 회의에서 45분을 원래의 논거를 재구성하는 데 씁니다. 결국 같은 결론에 도달합니다 – 타임라인 제약이 여전히 적용되었습니다 – 하지만 45분은 사라져버리고 의심은 남습니다. 스타트업이 매달 내리는 수십 개의 결정에 이를 곱하면, 이미 신중하게 결정된 선택들을 재심의하는 데 의미 있는 시간이 소비됩니다.
스타트업이 이것을 특히 잘 못하는 이유
대기업들은 (많은 결점에도 불구하고) 아키텍처 결정 레코드, RFC, 공식 검토 주기를 거치는 설계 문서 등 프로세스에 인코딩된 조직적 기억을 갖는 경향이 있습니다. 결정이 Confluence에 묻혀 있을 수 있지만, 최소한 찾을 수 있는 어딘가에 작성되어 있습니다.
스타트업에는 그런 인프라가 없으며, 구축하는 것은 소규모로 빠르게 움직일 때 피해야 할 종류의 부담처럼 느껴집니다. "우리는 그냥 기억할 것"이 4명에서는 효과가 있다는 합리적인 주장이 있으며, 실제로 그렇습니다 – 5번째 사람이 합류하여 왜 모든 것이 그렇게 되어 있는지에 대한 맥락이 전혀 없을 때까지는요.
스타트업의 의사 결정 추적을 특히 어렵게 만드는 또 다른 것은 도구 단편화입니다. 결정은 어디서나 일어납니다: Slack 스레드, Zoom 통화, Notion 댓글, Linear 토론, GitHub PR 검토, 그리고 (점점 더) 공유 채널에 도달하지 못하는 DM 안에서. 각 도구는 결정의 일부를 캡처하지만, 전체를 캡처하는 것은 없으며, 그들 사이의 링크는 인간의 기억에 의해 유지됩니다 – 이는 (애정을 담아 말하지만) 우리가 접근할 수 있는 가장 신뢰할 수 없는 데이터베이스입니다.
의사 결정 로그에 실제로 필요한 것
과도하게 설계하고 싶은 유혹이 있습니다. 항목당 15개의 속성이 있는 정교한 Notion 데이터베이스 – 결정 유형, 영향 수준, 검토 상태, 이해관계자, 관련 OKR – 를 구축했지만, 모든 결정에 대해 모든 필드를 채우는 부담이 인식되는 가치보다 높아서 결국 사용하지 않게 된 팀을 보았습니다.
스타트업을 위한 의사 결정 로그는 사람들이 실제로 사용할 만큼 가볍어야 합니다. 중요한 것은 다음과 같습니다:
결정 자체. 한 문장으로. "커스텀 구축 대신 알림에 서비스 X를 사용한다." 단락이 아닌 한 문장으로.
누가, 언제 결정했는지. 이름과 날짜. 이것은 명백하게 들리지만 6개월 후 누군가가 결정에 의문을 제기할 때 가장 중요한 부분입니다. 비난을 위한 것이 아니라(음, 대부분은 그렇지 않지만) – 원래의 논거를 누구에게 물어봐야 하는지 알기 위함입니다.
어떤 대안이 고려되었는지. 두세 개의 글머리 기호로. "커스텀 구축 검토(3 스프린트 추정, 마감 기한 너무 빠듯)" 및 "서비스 Y 검토(1만 사용자를 넘으면 가격이 확장되지 않음)." 이것이 재심의를 방지하는 부분입니다 – 대안과 그 트레이드오프가 문서화되어 있으면 팀은 이를 재발견할 필요가 없습니다.
논의가 어디서 일어났는지. Slack 스레드, Linear 이슈, Notion 댓글로의 링크 – 실제 토론이 이루어진 곳. 이것이 가장 과소평가된 필드입니다. 이것이 없으면 로그 항목은 증거 없는 주장이 됩니다. 이것이 있으면, 전체 맥락을 원하는 누구든 원래 대화를 읽으러 갈 수 있습니다.
무엇이 결정을 바꿀 것인지. 이것은 선택적이지만 맥락이 빠르게 변화하는 스타트업에 매우 유용합니다. "출시 기한이 4주 이상 늦어지면 재검토할 것" 또는 "월간 알림이 1만 건 미만이라고 가정한다." 정적인 기록을 살아있는 기록으로 변환합니다.
스타트업을 위한 최고의 의사 결정 로그는 팀이 실제로 작성하는 것입니다. 다섯 가지 필드, 각각 한 문장. 결정을 기록하는 데 90초 이상 걸린다면 시스템은 한 달 이내에 작동하지 않게 됩니다.
어디에 둘 것인가
세 가지 접근법을 시도하는 팀들을 보았으며, 모두 트레이드오프가 있습니다.
Notion 데이터베이스. 이것이 가장 일반적이며 비교적 잘 작동합니다. 위의 다섯 가지 필드로 데이터베이스를 만들고, 작성이 빠르도록 템플릿을 추가하고, 각 항목을 관련 프로젝트 페이지에 링크합니다. 단점: Notion은 사양이 사는 곳이지 결정이 일어나는 곳이 아니라서, 결정이 다른 곳에서 이루어진 후 누군가가 Notion으로 가야 합니다. 그 "이후" 단계가 탈락이 일어나는 곳입니다.
Slack 인라인으로. 일부 팀은 전용 #decisions 채널을 사용하고 각 결정에 대한 형식화된 메시지를 게시합니다. 이것은 마찰이 적습니다(결정은 아마 어차피 Slack에서 이루어졌을 것이므로), 하지만 Slack 검색으로는 프로젝트나 날짜 범위로 결정을 찾기 어렵고, 구조화된 필드의 부재는 시간이 지남에 따라 일관성이 저하됨을 의미합니다.
Linear 인라인으로. 결정이 특정 워크플로와 관련된 경우, 관련 Linear 이슈의 댓글로 기록하면 결정이 영향을 미치는 작업에 가깝게 유지됩니다. 단점은 여러 이슈나 프로젝트에 걸친 결정에는 자연스러운 위치가 없다는 것입니다.
솔직히 말하면, 이 중 어느 것도 훌륭하지 않습니다. 근본적인 문제는 결정이 도구 전반에 걸쳐 일어나지만 로그는 하나의 도구에 존재하므로, 간격을 메우기 위한 수동 단계가 항상 필요하다는 것입니다. 그 수동 단계가 내가 본 모든 의사 결정 로그의 단일 장애점입니다.
Sugarbug에서 구축하는 것
Sugarbug에서 취하는 접근법은 누군가에게 수동으로 기록하도록 요청하는 대신, 도구 전반에 걸쳐 결정이 일어날 때 감지하는 것입니다.
Slack 스레드가 결론에 도달할 때("OK, 서비스 X로 가죠"), Linear 이슈 토론이 해결될 때, GitHub PR 검토가 승인으로 끝날 때 – 이것들은 모두 결정이 내려졌다는 시그널입니다. Sugarbug는 이 시그널들을 수집하고, 분류하고, 지식 그래프의 관련 작업과 사람들에게 링크합니다. "의사 결정 로그"는 누군가가 유지해야 하는 별도의 데이터베이스가 아닙니다 – 기존 도구에 이미 내장된 결정들 전반에 대한 뷰입니다.
분류 정확도(결정과 단순한 대화의 차이를 파악하는 것은 들리는 것보다 더 어렵습니다)는 아직 작업 중이지만, 방향적 베팅은 결정이 실제로 일어나는 소스에서 캡처하는 것이 인간에게 별도의 시스템에 복제하도록 요청하는 것보다 더 신뢰할 수 있다는 것입니다.
이에 관심이 있다면, sugarbug.ai에 더 자세한 내용이 있습니다. 하지만 위의 수동 시스템은 팀이 충분히 커져 수동 로깅의 탈락률이 실제 문제가 될 때까지 – 우리 경험상 보통 8–12명쯤에서 – 대부분의 스타트업에 잘 작동할 것입니다.
Slack 스크롤에 결정을 잃지 마세요. Sugarbug는 실제로 결정이 일어나는 도구에서 자동으로 캡처합니다.
Q: 스타트업 의사 결정 로그에는 무엇이 포함되어야 하나요? A: 최소한: 결정 자체(한 문장), 누가 결정했는지, 언제, 어떤 대안이 고려되었는지, 그리고 토론이 어디서 일어났는지. 마지막 필드가 가장 중요합니다 – 원래 대화 링크 없이는 로그가 증거 없는 주장이 됩니다. 6개월 후 누군가가 의문을 제기할 때 기억에서 재구성하는 상황으로 돌아가게 됩니다.
Q: Sugarbug가 기존 도구에서 자동으로 의사 결정 로그를 만드나요? A: 그것이 우리가 나아가는 방향입니다. Sugarbug는 Slack, Linear, GitHub, Notion 및 기타 도구에서 시그널을 수집하여 지식 그래프로 분류합니다. 결정이 감지되면 – 승인된 PR, 해결된 Linear 토론, 명확한 다음 단계로 끝나는 Slack 스레드 – 해당 결정을 관련 작업과 사람들에게 자동으로 링크합니다. 분류 정확도("결정"과 "대화"를 구별하는 것은 진정으로 까다롭습니다)는 아직 개선 중이지만, 시그널 수집과 링크는 작동하고 있습니다.
Q: 스타트업은 얼마나 자주 의사 결정 로그를 업데이트해야 하나요? A: 이상적으로는 주간으로 일괄 처리하지 않고 결정이 내려지는 시점에 기록해야 합니다. 금요일에는 화요일 결정의 배경이 이미 흐릿해지고, "고려한 대안" 필드를 정확하게 작성할 가능성이 빠르게 떨어집니다. 수동으로 기록하는 경우 결정 직후 90초의 습관으로 만드세요. Sugarbug 같은 도구를 사용하는 경우, 목표는 결정이 실제로 일어나는 도구에서의 실시간 캡처입니다.
Q: Sugarbug가 Slack, Linear, GitHub 전반에서 결정을 추적할 수 있나요? A: Sugarbug는 세 가지 모두(Notion과 Figma 포함)에 연결하고 대화, 작업 및 코드 변경 간의 관계 지식 그래프를 유지합니다. Slack 스레드에서 결정이 나타나 Linear 이슈로 이어지고 GitHub PR을 생성하면, Sugarbug는 전체 체인을 링크하여 아무도 수동으로 링크를 만들 필요 없이 출발점에서 구현까지 결정을 추적할 수 있습니다.
Q: 의사 결정 로그와 아키텍처 결정 레코드(ADR)의 차이는 무엇인가요? A: ADR은 일반적으로 "MongoDB 대신 PostgreSQL을 사용한다"와 같은 중요한 기술적 선택을 위한 공식 문서로, 맥락, 결정 및 결과에 대한 구조화된 섹션이 있습니다. 스타트업을 위한 의사 결정 로그는 더 광범위하고 가볍습니다: ADR이 문서화하기에 너무 작다고 여길 일상적인 운영 결정(어떤 벤더, 어떤 기한, 어떤 기능을 줄일지)을 캡처합니다. 둘 다 가치 있지만, 의사 결정 로그는 공식 ADR이 필요하지 않지만 여전히 추적 가능해야 하는 결정의 95%를 커버합니다.