일하는 ai

10. 의사결정 4질문

14 min read

-

AI 도구 덕분에 팀의 실행 속도는 정말 빨라졌습니다. 문제는 속도가 올라간 만큼, 실패의 모양도 바뀌었다는 점입니다. 예전에는 문법 오류나 구현 실수가 많았다면, 지금은 “전제를 잘못 잡은 결정”, “너무 넓어진 범위”, “설명되지 않는 선택” 같은 의사결정 문제가 더 자주 터집니다.

그래서 이제 팀의 경쟁력은 “얼마나 빨리 만들었는가”보다 “왜 그 결정을 했는지 끝까지 설명할 수 있는가”에서 갈립니다. 이 글은 요즘IT 원문과 OpenAI 공개 자료를 근거로, 속도를 유지하면서도 흔들림을 줄이는 4가지 질문을 실무형으로 정리한 버전입니다.

안내: 이 문서는 생성형 AI를 활용해 초안을 작성했고, 공개된 원문 자료를 교차 확인해 실무형으로 정리했습니다.

이 글의 근거 자료

핵심 요약

  • AI는 속도를 올려주지만, 판단의 품질까지 자동으로 보장해주지는 않습니다.
  • 그래서 생성 전에 질문을 먼저 세우는 팀이 장기적으로 더 강합니다.
  • 전제 확인 → 단순 대안 비교 → 범위 고정 → 종료 조건 합의 이 네 단계만 습관화해도 실패 비용이 크게 줄어듭니다.
flowchart LR
A[요청 접수] --> B[전제 확인]
B --> C[단순 대안 비교]
C --> D[이번 범위 고정]
D --> E[종료 조건 합의]
E --> F[작게 실행]
F --> G[검증/학습 누적]

🧠 칠판 치트시트

  • 결과물 속도와 결정 품질은 별개다
  • 만들기 전에 전제부터 확인한다
  • 화려한 안보다 검증 가능한 작은 안을 먼저 고른다
  • 이번에 바꿀 것과 안 바꿀 것을 분리한다
  • 끝 조건을 먼저 정해야 팀이 덜 지친다

덜 흔들리는 팀의 4가지 질문

1) Think Before Coding — 지금 확실한 전제는 무엇인가?

이 질문이 없는 팀은 결과물을 보고 나서야 “아, 그 전제였어?”를 반복하게 됩니다. AI는 애매한 요청도 그럴듯하게 채워서 내놓기 때문에, 출발점의 모호함이 뒤에서 더 큰 비용으로 돌아옵니다.

회의에서 바로 쓸 수 있는 방식은 단순합니다.

  • “확정된 사실” 3개
  • “확인 필요한 가정” 3개
  • “틀리면 치명적인 위험” 1~2개

이렇게 먼저 적고 시작하면, 구현 속도는 유지하면서도 엉뚱한 방향으로 가는 시간을 크게 줄일 수 있습니다.

현장 예시를 하나 들면, B2B 청구 화면 개선 작업에서 “사용자는 총액만 본다”는 가정이 있었는데 실제 인터뷰에서는 “근거 항목(세부 내역)“을 먼저 확인한다는 사실이 나왔습니다. 전제를 먼저 확인한 팀은 화면 구조를 초기에 바로잡았고, 확인 없이 진행한 팀은 후반에 큰 재작업을 겪었습니다.

2) Simplicity First — 더 멋진 안이 아니라 더 빨리 검증 가능한 안인가?

실무에서 자주 보이는 함정이 “미래 확장성”을 이유로 현재 문제를 지나치게 크게 푸는 것입니다. 복잡한 안은 설득, 테스트, 롤백까지 전부 비싸집니다.

팀이 흔들리지 않으려면 매번 최소 두 가지를 비교하면 됩니다.

  • 지금 당장 검증 가능한 단순안
  • 확장성을 담은 복합안

그리고 선택 이유를 짧게 남기면 됩니다. “왜 지금은 단순안을 고르는지”가 문서에 남으면, 나중에 의사결정을 되돌아볼 때 팀 신뢰가 생깁니다.

예를 들어 온보딩 개선에서 “전체 플로우 재설계” 대신 “첫 화면의 행동 유도 문구 + 다음 버튼 위치만 조정”을 먼저 테스트한 팀은 1주 내 결과를 얻고, 그다음 단계로 자연스럽게 확장할 수 있었습니다.

3) Surgical Changes — 이번에 책임질 수 있는 범위만 바꿨는가?

AI와 함께 작업하면 의도하지 않은 주변 변경이 섞이기 쉽습니다. 이때 범위 경계가 없으면 원인 추적이 어려워지고, 결국 “무엇 때문에 좋아졌거나 나빠졌는지”를 알 수 없게 됩니다.

그래서 변경 전에 한 문장만 고정해도 효과가 큽니다.

  • 이번에 바꿀 것: 무엇을, 왜 바꾸는가
  • 이번에 안 바꿀 것: 무엇은 유지하는가

이 원칙은 특히 협업에서 강력합니다. 디자이너·개발자·PM이 같은 경계를 보고 움직이기 때문에, 리뷰가 취향 싸움보다 범위 합의 중심으로 돌아갑니다.

실제 사례로, 결제 완료 페이지에서 “완료 직후 정보 우선순위”만 바꾸기로 합의한 팀은 일정 지연 없이 배포했고, 이후 문제도 빠르게 추적했습니다. 반대로 관련 없는 영역까지 한 번에 손본 팀은 버그 원인 분석에 더 많은 시간을 썼습니다.

4) Goal-Driven — 무엇을 만족하면 끝인가?

끝 조건이 없으면 팀은 계속 손보게 됩니다. 특히 AI 도구는 “조금만 더”를 쉽게 만들어 주기 때문에, 종료 기준이 없으면 피로도가 급격히 올라갑니다.

좋은 종료 기준은 대단할 필요가 없습니다. 아래 3개면 충분합니다.

  • 사용자 행동 지표 1개 (예: 첫 단계 진입률)
  • 운영 지표 1개 (예: 문의/오류 건수)
  • 품질 조건 1개 (예: 핵심 흐름 테스트 통과)

예를 들어 “온보딩 1차 개선”이라면, “첫 단계 진입률 +8%, 주요 오류 없음, 문의량 증가 없음” 같은 형태로 끝 조건을 먼저 잡아두면 팀이 훨씬 안정적으로 움직입니다.

현장에서 자주 보이는 흔들림 패턴과 정리법

패턴 A) 결과는 빠른데 설명이 안 되는 팀

  • 증상: 산출물은 많은데 회의에서 “왜 이 선택인지” 설명이 비어 있음
  • 정리법: 결과 리뷰 전에 전제/가정 메모부터 확인

패턴 B) 한 번에 너무 크게 바꾸는 팀

  • 증상: 변경 후 이슈가 나도 원인을 특정하기 어려움
  • 정리법: 변경 범위를 한 문장으로 고정하고 작은 실험부터 진행

패턴 C) 계속 고치는데 끝이 안 나는 팀

  • 증상: “조금만 더” 반복, 피로 누적
  • 정리법: 시작 전에 종료 기준 3개 합의하고, 충족 시 일단 마감

미니 사례 3가지

사례 1) SaaS 대시보드: 지표 나열에서 우선순위 화면으로

처음에는 “데이터를 더 많이 보여주자”가 방향이었지만, 실제 사용자는 “지금 무엇을 먼저 처리해야 하는지”를 원했습니다. 팀은 질문을 바꿨습니다.

  • 전제: 사용자는 분석보다 조치 우선순위를 원한다
  • 단순안: 상단에 우선 조치 카드 3개만 고정
  • 범위: 상세 리포트 구조는 이번 릴리스에서 유지
  • 종료 기준: 우선 작업 클릭률 상승 + 문의량 증가 없음

결과적으로 대규모 리뉴얼 없이도 사용성 평가가 개선됐고, 다음 분기 개선의 기준점도 명확해졌습니다.

사례 2) 커머스 결제완료: “끝 장면”만 정리했는데 만족도가 오른 팀

구매 전환율은 괜찮았지만, 구매 직후 만족도가 낮았습니다. 팀은 Peak-End 관점으로 완료 화면만 집중적으로 손봤습니다.

  • 주문번호/배송예상/문의경로를 상단에 고정
  • 추천영역은 하단으로 이동
  • 다음 행동 버튼(주문확인/배송조회)을 분리

핵심은 “완료 직후 사용자가 무엇을 기억해야 하는가”를 먼저 문장으로 정의한 점이었습니다.

사례 3) 내부 운영툴: 실패 기준을 먼저 적은 팀

운영팀이 자동화 화면을 개선하면서 기능을 계속 추가하다 일정이 밀렸습니다. 이후 팀은 시작 전에 “실패 기준”부터 적었습니다.

  • 1주 안에 배포 불가 시 범위 축소
  • 오류율이 기준 이상이면 즉시 롤백
  • 교육 문서가 없으면 릴리스 보류

이렇게 기준을 먼저 정하니, 기능 추가 압박이 있어도 팀이 합리적으로 멈출 수 있었습니다.

20분 회의에서 바로 쓰는 운영안

  • 5분: 오늘 작업의 전제/가정/위험을 칠판에 고정
  • 5분: 단순안 vs 복합안 비교 후 이번 선택 결정
  • 5분: 이번 범위(바꿀 것/안 바꿀 것) 합의
  • 5분: 종료 기준 3개 확정 후 담당자/일정 지정

짧은 회의라도 이 순서만 지키면 “속도는 빠른데 계속 흔들리는” 상태에서 벗어나기 쉽습니다.

근거 링크 모음

점검 메모

  • 전제/가정/위험을 결과물보다 먼저 확인했는가
  • 단순안과 복합안을 비교하고 선택 이유를 남겼는가
  • 이번 변경 범위를 문장으로 고정했는가
  • 종료 기준 3개를 시작 전에 합의했는가

다음 읽기

그래프 뷰

백링크