Enterprise Digital Workspace Platform: 대기업 IT 계열사 오피스 플랫폼 구축 및 고도화 프로젝트

SI 협력사 UXUI 기획자의 제약 속 사고·판단 여정

📌 프로젝트 개요

이 프로젝트는 제가 SI 협력사 UXUI 기획자로 참여한 첫 대기업 프로젝트였습니다. 프로젝트 기간 동안 원격 근무 환경에서, 데이터 접근도, 최종 의사결정권도 없는 상태로 일했습니다.

하지만 바로 그 제약 속에서 “기획자가 정말 해야 할 일이 무엇인가”를 배웠습니다. 완벽한 환경이 아니어도, 주어진 조건에서 문제를 정의하고 해결책을 찾아가는 과정. 그것이 이 프로젝트를 통해 얻은 진짜 가치였습니다.

나의 역할

• 서비스 기획 40%
  → 요구사항 정리, 서비스 구조 설계
• UXUI 디자인 75%
  → 화면 설계, 와이어프레임, 상세 디자인
  (*고객사 기획자가 UI 작업 불가로 와이어프레임부터 상세 디자인까지 전 과정 담당)
• 품질 검수 35%
  → 기능 테스트, 검토

최종 성과

• 협력 업체 평가 최고 등급 달성 (5단계 중 1등급)
• 고객사로부터 “안정적이고 사용성 개선됨” 긍정 평가

---

Part 1: 프로젝트 제약 조건 – 내가 할 수 있었던 것과 없었던 것

많은 사람들이 대기업 프로젝트라고 하면 “좋은 환경에서 일했겠네”라고 생각합니다. 하지만 SI 협력사 소속 기획자의 현실은 달랐습니다.

먼저 제가 할 수 없었던 것과 할 수 있었던 것을 솔직하게 정리해보겠습니다. 이 제약 조건들이 오히려 문제 해결 능력을 단련시켰습니다.

SI 협력사 원격 근무자의 현실

근무 방식

• VPN 원격 모드로 전체 프로젝트 참여
• 고객사 사무실 방문 불가
• 모든 커뮤니케이션: 전화 + 온라인 미팅

내가 할 수 없었던 것

❌ 데이터 접근

• 사용자 사용 로그 데이터 없음
• 예약 건수, 이탈률, 사용 패턴 등 모든 정량 데이터 접근 불가
• 고객사 내부 자료 열람 제한

❌ 최종 의사결정

• 우선순위는 이미 고객사 이해관계자들이 결정
• 중간에 계획 변경되어도 따를 수밖에 없음
• “왜 이 기능이 필요한가” 질문할 권한 제한적

❌ 사용자 직접 접촉

• 실제 사용자 인터뷰 불가
• 사용성 테스트 직접 진행 불가
• 피드백은 고객사 기획자를 통해서만 간접 전달

❌ 시스템 직접 사용

• 실제 운영 환경 접근 제한적
• 기존 시스템 사용 경험 제한적
• 개발 서버로만 테스트 가능

내가 할 수 있었던 것

✅ 고객사 기획자와의 1:1 협업

• 주 4-5회 온라인 미팅 (각 1-2시간)
• 요구사항 문서 기반 논의
• 화면 구성 방향 협의

✅ UX/UI 설계 전담

• 고객사 기획자가 UI 작업 불가로 단독 수행
• 와이어프레임, 화면 설계, 컴포넌트 제작
• Figma 프로토타입 기반 개선안 제시

✅ 정책 문서 분석 및 정리

• 고객사 제공 정책 문서 반복 숙독
• 흩어진 조항들을 시각화
• 충돌 지점 발견 시 질문

✅ 퍼블리셔/개발팀과 협업

• 주간 스크럼 참여
• 기획 의도 전달 및 구현 가능 여부 확인
• QC 및 이슈 리포트 작성

나의 위치

---

Part 2: 문제 정의 – 요구사항 문서 속에서 진짜 문제 찾기

프로젝트가 시작되고 가장 먼저 받은 건 여기저기 흩어져 있는 방대한 문서 내용이였습니다. 요구사항 정의서, 정책 문서, 기존 시스템 화면 캡처 등과 함께 개선 사항을 요청받았습니다.

‘무엇을’ 개선하라는 건지, ‘왜’ 개선이 필요한지조차 명확하지 않았습니다. 이 모호함을 구체적인 문제로 바꾸는 것, 그것이 첫 번째 과제였습니다.

🔍 초기 상황: 방대한 정책 문서

프로젝트 시작 시 받은 것

• 여러 곳에 분산되어 있는 요구사항 정의서
• 정책 관련 문서들 (방대한 분량)
• 기존 시스템 화면 캡처 다수
• “이거 개선해주세요”

문제

📋 Step 1: 요구사항 문서 분해

내가 한 일

요구사항을 정리하고 나니 더 큰 문제가 보였습니다. 여러 부서에서 다양한 방식으로 작성한 정책 문서들이 서로 다른 기준으로 만들어져 있었고, 심지어 일부는 상충했습니다.

이대로는 화면을 설계할 수 없었습니다. 그래서 이 혼란을 하나의 기준으로 통합하는 작업이 필요했습니다.

📊 Step 2: 정책 문서 매트릭스화

발견한 문제

→ 같은 시스템에 대한 규정임에도 불구하고 통합되지 않음

내가 한 일

매트릭스 표 작성으로 통합 정리
*구체적 정책, 규칙 및 권한 구분이 주된 내용으로 비공개

구성 요소

• 사용자 유형별 분류
• 예약 종류별 분류
• 주요 제약 조건
• 승인 필요 여부

고객사 기획자에게 공유

“이 표가 맞나요? 틀린 부분 있으면 수정 부탁드립니다”

결과

• 여러 차례 수정 후 승인
• 이후 모든 화면 설계의 기준이 됨
• 개발팀도 이 표를 기반으로 로직 구현

💡 문제 ‘재정의’ 결과

[문제 1] 방문 예약: 승인 프로세스 복잡

• 현상: 여러 단계를 거쳐야 함
• 불편: 긴급 상황 시 지연 발생
• 영향: 외부 고객 대응 지연

[문제 2] 회의실 예약: 기능 부족

• 현상: 반복 예약 불가, 시각화 부족
• 불편: 사용자가 매번 수동 처리
• 영향: 업무 비효율

[문제 3] 좌석 예약: 낮은 UX 직관성

• 현상: 예약 전/후 동일한 화면
• 불편: “지금 무엇을 해야 하나?” 혼란
• 영향: 사용자 오류 발생

[문제 4] Back Office: 설정 난이도 높음

• 현상: 관리자 설정 UI 복잡
• 불편: 설정 변경에 어려움
• 영향: 운영 비효율

---

Part 3: 우선순위 – 이미 정해진 것과 내가 판단한 것

⚖️ 제약 조건

프로젝트 우선순위

• 고객사 이해관계자들이 이미 결정
• 계획이 자주 변경되기도 함
• 나는 결정할 수 없고, 따라야 함

예시 (실제 발생)

• 초기 계획대로 진행 중
• 중간에 우선순위 변경 요청
• 이유: 고객사 내부 사정 (자세한 배경 공유 안 됨)
• 대응: 작업 중인 내용 조정, 새로운 우선순위로 재진행

🎲 내가 할 수 있었던 우선순위 판단

문제를 정의했다고 끝이 아니었습니다. “무엇을 먼저 해야 하는가?”라는 질문이 남았습니다.

하지만 SI 협력사 기획자인 저는 우선순위를 결정할 권한이 없었습니다. 고객사 이해관계자들이 이미 정해놓은 순서를 따라야 했고, 중간에 계획이 바뀌기도 했습니다.

그렇다면 제가 할 수 있는 일은 무엇이었을까요? 비록 전체 우선순위는 결정하지 못 해도, 주어진 기능 내에서는 판단이 가능했습니다.

예시: 기능 개선

고객사 요구: “회의실 예약 사용성 개선”

실제 포트폴리오에 있는 개선 사항들

1. 예약 유형별 맞춤 설계
2. 처리 로직 명확화
3. 동적 화면 구성
4. 시간별 가시성 강화

내가 한 일

개발팀에게 각 개선사항의 개발 난이도 질문

개발 리드와 협의:

• 각 기능별 예상 소요 시간 파악
• 기술적 제약 사항 확인
• 우선순위 제안을 위한 기초 자료 수집

고객사 기획자와 협의:

“전체 일정 내에서 가능한 범위를 판단했습니다.
이런 조합들이 가능한데 어떤 방향이 좋을까요?”

여러 실행 가능 조합 제시:

• 각 조합의 예상 효과
• 리스크 요인
• 일정상 현실성

💡 우선순위 결정에서 배운 것

1. 전체 우선순위는 못 정해도, 부분 우선순위는 가능

• 주어진 기능 내에서 “어떻게 구현할지”는 제안 가능
• 개발 난이도 파악 → 조합 제시 → 의사결정 지원

2. 프로토타입은 가장 강력한 설득 도구

• “이렇게 하면 좋을 것 같습니다” (약함)
• “A로 만들어봤는데 어떤가요?” (강함)
• 짧은 시간의 프로토타입을 통한 판단이 긴 회의보다 효과적

3. 개발팀과의 협업이 핵심

• 혼자 추정한 난이도는 신뢰도 낮음
• 개발 리드와 각 기능 검토 필수
• “이거 얼마나 걸리나요?” 질문을 두려워하지 말 것

---

Part 4: 실행 관리 – 원격 환경에서 협업하기

계획은 세웠지만, 실행은 또 다른 문제였습니다. VPN으로만 접속하는 원격 환경에서, 모든 커뮤니케이션이 화상회의와 전화로만 이루어졌습니다.

“잠깐 물어볼게요”라는 말 한마디도 미팅 약속을 잡아야 했습니다. 이런 환경에서 어떻게 효과적으로 협업할 수 있었을까요?

🎭 이해관계자 구조

나의 위치

• 고객사 이해관계자 직접 소통 불가
• 모든 커뮤니케이션은 고객사 기획자 경유
• VPN 원격 근무로 퍼블리셔/개발팀과도 온라인만

🔄 실제 업무 프로세스

주간 루틴

📞 고객사 기획자와의 협업 방식

Challenge: UI 작업 불가능한 기획자

• 고객사 기획자는 기획 문서만 작성 가능
• UI 디자인 툴 사용 불가
• 화면 구성은 전적으로 나의 담당

초기 시행착오

프로세스

1. 고객사 요구사항 문서 받기
2. Figma로 화면 초안 제작 (1-2시간)
3. Figma 화면 링크 공유
4. 온라인 미팅에서 함께 화면 보며 논의
   → “A를 클릭하면 A-1이 됩니다” 설명

효과

• 고객사: “이제 명확하게 이해됩니다”
• 수정 요청도 구체적으로 가능
  예: “A 화면의 버튼 위치를 조정해주세요”
• 미팅 시간 단축

원격 협업의 루틴이 자리 잡혔다고 생각할 무렵, 예상치 못한 변수가 찾아왔습니다. 이미 진행 중인 작업에 갑자기 새로운 기능 추가 요청이 들어온 것입니다.

이유에 대한 구체적인 설명도 없었고, 일정은 촉박했습니다. 이런 상황에서 어떻게 대응해야 했을까요?

🔧 중간 계획 변경 대응

실제 사례: 갑작스런 기능 추가

상황

• 특정 화면 개발 진행 중
• 고객사: “추가 기능 필요합니다”
• 기존 계획에 없던 요구
• 일정: 단기간 내 완료 요청

문제

• 이미 진행 중인 작업과 충돌
• UI 구조 조정 필요
• 개발팀: “일정 영향 있습니다”

대응

1단계: 영향 범위 파악 (즉시)
→ 영향받는 화면 파악
→ 개발 공수 개발팀에게 확인
→ 현실적 일정 검토

2단계: 실행 가능 옵션 제시 (당일)
→ 고객사에게 여러 옵션 제시

3단계: Figma 프로토타입 제작
→ 선택 가능한 옵션 시각화
→ “이 정도면 가능합니다” 시연

4단계: 고객사 결정
→ 특정 옵션 선택
→ 이유: 일정과 기능의 균형

결과

• 선택된 방향으로 완료
• 일정 영향 최소화
• 차기 개선 계획에 반영

💡 실행 관리에서 배운 것

1. 원격 협업은 “과잉 커뮤니케이션”이 답

• 오프라인이었다면 “잠깐 물어볼게요” 가능
• 원격은 모든 게 약속 필요
• 그래서 문서화, 시각화가 더 중요

2. 프로토타입은 공통 언어

• 고객사 기획자: 기획 문서만 가능
• 나: Figma 가능
• 퍼블리셔/개발팀: 코드
• Figma가 모두가 이해하는 중간 언어

3. 갑작스런 변경은 막을 수 없지만 대응은 가능

• 변경 요구 자체는 거부 불가
• 하지만 “어떻게 변경할지”는 제안 가능
• 옵션 제시 + 트레이드오프 명확히 = 합리적 의사결정 지원

---

Part 5: 데이터 없이 판단하기 – 대안적 검증 방법

기획자라면 누구나 데이터 기반 의사결정을 하고 싶어 합니다. 사용자 수, 클릭률, 이탈률 등. 하지만 SI 협력사인 저에게는 그 어떤 데이터도 주어지지 않았습니다.

“데이터 없이 어떻게 판단을 해야 할까?” 이 질문을 매순간 끊임없이 되뇌었습니다. 완벽한 데이터는 없었지만, 판단을 멈출 수는 없었습니다.

그래서 찾은 대안들이 있습니다.

🚫 데이터 접근 불가의 현실

내가 알 수 없었던 것:

모든 정량 데이터가 차단되어 있었습니다.
그렇다면 어떻게 기능 필요성을 판단했을까요?

📊 대안 1: 경쟁 서비스 벤치마크

[가설] 특정 기능이 필요할 것이다

검증 방법: 유사 서비스 분석

분석 대상:

• 업무 툴 회의실 예약 시스템들
• 공간 예약 서비스들

분석 내용:

• 어떤 기능들이 표준으로 제공되는가
• 사용자 흐름은 어떻게 구성되어 있는가
• 어떤 정보를 우선 보여주는가

결론:

→ 여러 서비스에서 공통으로 제공하는 기능 = 산업 표준
→ 우리 서비스에도 필요할 가능성 높음

📱 대안 2: Figma 프로토타입 기반 검증

🎯 목적 1: 작업 효율성 개선 (플로우 최적화)

[가설] 특정 UI 구조로 작업 단계를 줄일 수 있다

검증 방법:

1. 기존 화면 캡처 및 요구사항 문서로 현재 플로우 파악
→ “예약 완료까지 7단계 필요”

2. Figma로 개선안 프로토타입 제작
→ “이렇게 하면 4단계로 줄일 수 있겠다”

3. 단계 비교 및 효과 추정
→ “7단계 → 4단계 = 43% 축소”
→ “단계 줄어들면 시간도 절약될 것”

🎯 목적 2: UI 직관성 비교 (대안 평가)

[가설] A 방식이 B 방식보다 직관적일 것이다

검증 방법:

1. Figma 프로토타입 2개 버전 제작
• A안: 한 가지 방식
• B안: 다른 방식

2. 사내 동료 소규모 테스트
• 대상: 개발팀, 다른 프로젝트 기획자
• 방법: 프로토타입 링크 전송 → 시나리오 제시 → 관찰

3. 측정 및 비교
• 소요 시간: B안이 더 짧음
• 오류 발생: B안이 더 적음
• 피드백: A안 “복잡함” / B안 “명확함”

💡 검증의 한계와 타당성

한계 인정

• 실제 운영 환경 테스트 불가 (프로토타입 기반 추정)
• 제한적 표본 (사내 동료 소규모)
• 정량 데이터 없이 정성적 비교

그럼에도 타당한 이유

💡 데이터 없이 판단하기에서 배운 것

1. 완벽한 데이터는 이상, 합리적 추정은 현실

• 이상적: “데이터 분석 결과…”
• 현실적: “벤치마크 + 휴리스틱(Heuristic) + 소규모 테스트 결과…”
• 중요한 건 추정 과정의 투명성

2. 소규모 테스트 > 추측

• “통계적으로 유의하지 않다”며 아무것도 안 하는 것이 최악의 방식
• 불완전해도 실제 반응을 확인하는 것이 의미 있음
• 트렌드 파악이 목적

3. 벤치마크는 가장 쉬운 검증

• 짧은 시간에 여러 서비스 분석 가능
• 산업 표준 파악 = 강력한 근거

---

Part 6: 솔루션 설계 – 제약 속에서 만든 화면들

문제를 정의하고, 우선순위를 조율하고, 검증 방법을 찾았습니다. 이제 실제로 해결책을 만들 차례였습니다.

고객사 기획자가 UI 작업을 할 수 없어서, 와이어프레임부터 상세 디자인까지 모든 화면 설계를 제가 담당했습니다. 제약이 많았던 만큼, 각 화면 하나하나에 문제 해결의 의도를 담아야 했습니다.

🎨 Front Office: 사용자 화면 설계

개선 1: 예약 유형별 맞춤 설계

기존 문제

• 모든 예약이 동일한 입력 형태
• 불필요한 옵션도 항상 표시
• 케이스별 필요 기능 누락

개선 방향

• 예약 유형에 따라 필요한 입력만 표시
• 사용 맥락에 맞는 UI 구성
• 불필요한 정보 숨김

구현

• 케이스별로 다른 입력 화면
• 각 상황에 맞는 옵션만 제공

개선 2: 처리 로직 명확화

기존 문제

• 예약 처리 과정이 불명확
• 사용자가 결과를 예측하기 어려움

개선 방향

• 기획서와 플로우차트로 과정 정의
• “사용자 행동 → 시스템 반응” 명확히
• 모든 경우를 문서화

구현

• 각 케이스별 처리 로직 문서화
• 개발팀과 공유
• 예외 상황 사전 정의

개선 3: 동적 화면 구성

기존 문제

• 예약 전/후 동일한 화면
• 모든 버튼 항상 노출
• 사용자: “지금 뭘 해야 하지?” 혼란

개선 방향

→ 이후 상태들도 동일한 방식으로 설계

효과

• 사용자 오류 감소
• “뭘 해야 할지 명확하다” 피드백

개선 4: 시간별 가시성 강화

기존 문제

• 단일 뷰만 제공
• 정보 찾기 어려움

개선 방향

• 여러 뷰 제공 (일간/월간)
• 사용자가 선택 가능
• 즐겨찾기 기능 추가

구현

• 각 뷰의 목적을 명확히 규정
• 상황에 맞는 뷰 자동 제공
• 자주 쓰는 것에 빠른 접근 가능

사용자 화면만 잘 만든다고 끝이 아니었습니다. 아무리 사용자 화면이 좋아도, 관리자가 설정을 제대로 못 하면 시스템은 제대로 돌아가지 않습니다.

오히려 Back Office가 복잡하면 운영 자체가 마비될 수 있습니다. 그래서 관리자 화면 설계에도 많은 공을 들여 구조적으로 설계했습니다.

⚙️ Back Office: 관리자 화면 설계

개선 5: 정책 설정 UI 간소화

기존 문제

• 설정 옵션 너무 많음
• 관리자도 혼란
• 설정 변경 어려움

개선 방향

• 옵션을 카테고리로 분류
• 단계별 안내 제공
• UI 설정 방식 표준화

구현

• 여러 카테고리로 재구성
• 각 옵션 설명 추가
• 충돌 방지 로직

개선 6: 도면 관리 개선

기존 문제

• 도면 업로드 후 공간 편집 어려움
• 사용자 화면 설정과 불일치
• 복잡한 설정 시, 오류 빈번

개선 방향

• 공간 편집 프로세스 재정의
• 직관적 UI 구성
• 구조 연결 레이아웃 설계

구현

• 도면 위에서 직접 설정
• 동일 인터페이스 적용(사용자/관리자)
• 검증 로직 추가로 오류 방지

개선 7: 하드웨어 연동 설정

기존 문제

• 하드웨어 ID 체계 미정립
• 데이터 시각화 기준 부재
• 관리 효율성 부족

개선 방향

• ID 체계 정의
• 데이터 연동 및 시각화 규칙 수립
• 상태 모니터링 흐름 정의

구현

• 장비 관리 체계 표준화
• 도면에 하드웨어 위치 표시
• 사용자 화면의 연동 정확도 개선

💡 솔루션 설계에서 배운 것

1. 제약이 창의성을 낳는다

• 완벽한 환경보다 제약 상황이 때로는 더 나은 솔루션을 제시할 가능성 있음

2. 프로토타입은 대화 도구

• “이렇게 하면 좋을 것 같습니다” (약함)
• “A방안으로 만들어봤는데 어떤가요?” (강함)

3. 관리자 UX도 중요

• Front Office만 신경 쓰기 쉬움
• Back Office가 복잡하면 운영 비효율
• FO/BO 인터페이스 연동 효율이 매우 중요

---

Part 7: 품질 검수 – 체계적 QC

화면을 설계하고 개발이 완료된 후에는 기획 의도대로 제대로 구현되었는지, 예외 상황은 없는지 확인하는 과정이 필요했습니다.

제가 담당한 QC는 단순히 “버튼이 작동하는지” 확인하는 것이 아니었습니다. 초기에 정리했던 정책 문서, 매트릭스 표를 기준으로 모든 케이스를 검증해야 했습니다.

🔍 QC 프로세스

내 역할 (QC 35%)

• 기능별 동작 확인
• 화면 검토
• UI 요소 점검
• 이슈 리포트 작성

QC 방식

📋 이슈 처리 방식

이슈 발견 시

재현 방법 기록:

1. 어떤 상황에서
2. 무엇을 했을 때
3. 어떤 결과가 나왔는지

예상 vs 실제:

• 예상: “A→B” 로 되어야 함
• 실제: “A→C,?” 이렇게 됨

우선순위 판단:

• 영향도
• 발생 빈도

처리:

• Critical: 즉시 수정 요청
• High: 빠른 시일 내
• Medium: 일정 조율
• Low: 추후 반영

📊 QC 결과

체계적 검수

• 주요 이슈 사전 발견
• 런칭 전 수정 완료
• 안정적인 서비스 오픈

고객사 피드백

“안정적으로 잘 작동합니다”

💡 QC에서 배운 것

1. 초기 정리가 QC의 기준

• 기획 단계에서 만든 문서
• QC 시나리오 작성의 기준
• 초기 정리의 중요성 실감

2. 우선순위 있는 QC

• 모든 이슈를 동일하게 처리 불가
• Critical 우선
• 안정성이 목표

3. 구체적인 이슈 리포트

• “버그 있어요” (X)
• 재현 방법 + 예상/실제 (O)
• 개발팀이 즉시 이해 가능

---

Part 8: 결과 및 회고

협력 업체 평가에서 최고 등급을 받았고, 고객사로부터 “안정적이고 사용성이 개선되었다”는 평가를 받았습니다.

하지만 개인적으로 더 의미 있었던 건 숫자가 아니었습니다. 제약 조건 속에서도 문제를 해결해낸 그 과정, 그리고 그 과정에서 배운 것들이었습니다.

📊 프로젝트 성과

🎓 프로젝트 회고

프로젝트를 되돌아보면 쉬웠던 순간은 단 한 번도 없었습니다. 매 순간이 도전이었고, 제약이었습니다.

하지만 바로 그 어려움 속에서 가장 많이 배웠습니다. 그 과정에서 마주했던 주요 도전 과제들과, 어떻게 극복했는지 정리해 보겠습니다.

Challenge 1: 정책 문서 이해의 어려움

왜 어려웠나

• 방대한 문서
• 서로 다른 부서 작성 → 용어 불일치
• 조항 간 관계 복잡
• SI 특성상 배경 정보 접근 제한

극복 방법

• 문서 반복 숙독
• 시각화로 정리
• 충돌 지점 발견 즉시 질문
• 최종 통합 문서화

배운 것

Challenge 2: VPN 원격 근무의 한계

왜 어려웠나

• 얼굴 보고 일하지 못함
• 사무실 방문 불가
• “잠깐 물어볼게요” 불가능
• 모든 소통이 약속 필요

극복 방법

• 문서화 철저히
• Figma 툴로 시각적 소통
• 질문 리스트로 준비

배운 것

Challenge 3: 데이터 없이 판단하기

왜 어려웠나

• 사용자 데이터 접근 불가
• 테스트 환경 제한
• 추정으로 판단해야 하는 불안감

극복 방법

• 벤치마크 분석
• 직접 테스트
• 소규모 동료 테스트
• 간접 정보 수집

배운 것

Challenge 4: 갑작스런 계획 변경

왜 어려웠나

• 작업 중인 내용 변경
• 예상 못 한 요구
• 이유 설명 제한적
• 거부 권한 없음

대응 방법

• 영향 범위 즉시 파악
• 여러가지 옵션 제시
• 프로토타입 제작
• 현실적 일정 공유

배운 것

회고를 하며 자연스럽게 드는 생각이 있습니다. “만약 프로젝트를 다시 진행한다면 어떻게 해야 할까?”

완벽한 프로젝트는 없습니다. 돌이켜보면 아쉬운 점도, 더 잘할 수 있었던 부분도 보입니다. 하지만 그것 또한 성장의 증거라고 생각합니다.

🔮 만약 다시 한다면

더 잘할 수 있었던 것

1. 사용자 접근을 더 적극적으로

• 아쉬움: 간접 피드백만 전달받음
• 개선: 직접 접촉 기회 요청
• 효과: 더 구체적 니즈 파악

2. 프로토타입의 초기 도입

• 아쉬움: 후반부터 프로토타입 적용
• 개선: 기획 초기부터 간단한 프로토타입 제시
• 효과: 오해 조기 발견

3. 목표를 더 명확하게 설정

• 아쉬움: “개선”이라는 막연한 목표
• 개선: 구체적인 측정 가능 목표
• 효과: 우선순위 결정 기준

4. 테스트 체계화

• 아쉬움: 즉흥적 테스트
• 개선: 정기적 테스트
• 효과: 더 신뢰할 만한 피드백

잘했던 것

1. 문서화

• 모든 결정과 이슈 기록
• 나중에 근거 자료로 활용

2. Figma 프로토타입 활용

• 짧은 시간 내 프로토타입이 효과적
• 원격 환경 최고의 도구

3. 개발팀과 긴밀한 협업

• 개발 난이도 사전 파악
• 우선순위 결정에 반영

4. 투명한 커뮤니케이션

• 추정임을 명확히 할 것
• 근거 공유
• 불확실성 숨기지 않기

---

Part 9: 제약 속에서 발견한 UX 사고방식

이 프로젝트를 진행하며 가장 많이 생각했던 질문이 있습니다.

“데이터도 없고, 권한도 없는데 어떻게 PM처럼 사고할 수 있을까?”

해답은 PM 역량의 본질은 권한이나 데이터가 아니라 ‘사고방식’에 있다는 점입니다. 제약 조건 속에서도 문제를 정의하고, 판단 근거를 만들고, 의사결정을 지원하는 것. 그것이 제가 이 프로젝트에서 배운 PM 사고방식입니다.

1. 문제 정의 능력

이상적 상황

“데이터 분석 결과 X 문제가 Y% 발생”

내 현실

“방대한 정책 문서 + 고객사 ‘개선해주세요'”

PM 사고방식

• 모호함을 구체적 과제로 쪼개기
• 많은 요구사항을 핵심 문제로 압축
• 시각화로 정리

이 프로젝트에서

• 직접 데이터는 못 봤지만
• 문서 분석 + 질문 + 시각화로 문제 정의 가능
• 권한 없어도 “문제를 정의하는 능력”은 기를 수 있음

2. 우선순위 결정 능력

이상적 상황

“ROI 계산 결과 A가 최우선”

내 현실

“고객사가 이미 우선순위 결정, 중간에 변경도 다수 발생”

PM 사고방식

→ 전체는 못 정해도, 부분 우선순위는 가능
→ 여러 조합 제시
→ 의사결정 지원

이 프로젝트에서 적용 방법

• 개발 난이도 파악
• 실행 가능 조합 제시
• 결정권 없어도 “판단 근거 제공”은 가능

3. 실행 관리 능력

이상적 상황

“이해관계자 조율 완료, 순조롭게 진행”

내 현실

“VPN 원격, 갑작스런 변경”

PM 사고방식

→ 프로토타입으로 빠른 합의
→ 문서화로 결정 추적
→ 변경 시 옵션 제시

이 프로젝트에서 적용 방법

• Figma가 소통 도구
• 변경 요구에 여러 옵션 제시
• 권한 없어도 “대안 제시”는 가능

4. 데이터 기반 의사결정

이상적 상황

“A/B 테스트 결과…”

내 현실

“데이터 없음, 그래도 판단해야 함”

PM 사고방식

• 벤치마크로 산업 표준 확인
• 직접 테스트
• 소규모 검증
• 추정 과정 투명하게 공유

이 프로젝트에서 증명한 것

• 벤치마크로 근거 마련
• 직접 테스트로 추정
• 소규모로 검증
• 완벽하지 않지만 “합리적 추정”은 가능

📌 SI 협력사 UXUI 기획자의 제약과 PM 역량

많은 사람들이 생각하는 PM

“데이터로 의사결정, 우선순위 결정, 팀 리드”

내 현실

그렇다면 PM 역량을 쌓을 수 없나?
→ 아닙니다.

PM 역량의 본질

• 권한이 아니라 ‘사고방식’
• 데이터가 아니라 ‘판단 프레임’
• 결정권이 아니라 ‘의사결정 지원’

이 프로젝트에서 증명한 것

이러한 방법들이 모두 PM 사고방식에 포함될 수 있다고 생각합니다.

---

Part 10: 개선 방향

🔍 프로젝트 한계와 개선 방향

한계 1: 정량 검증 부재

문제

• 런칭 전 사용성 테스트 제한적
• 런칭 후 모니터링 프로세스 미흡
• 데이터 수집 체계 부재

다음 개선

• 계약 단계에서 모니터링 포함 협의
• 최소한의 측정 지표 사전 정의
• 정기 리뷰 미팅 합의

한계 2: 요구사항 변화로 인한 재작업

문제

• 기획 방향 여러 차례 변경
• 이미 만든 작업 수정
• 일정 영향

다음 개선

• 초기 단계부터 프로토타입 공유
• 변경 관리 프로세스 합의
• 고정 범위 명확히

한계 3: 원격 소통의 한계

문제

• 뉘앙스 전달 어려움
• 실시간 피드백 불가

다음 개선

• 시각적 기준 사전 합의
• 참고 사례 함께 공유
• 비동기 소통 도구 적극 활용

---

마치며

협업을 기반으로 한 프로젝트를 ‘완벽하게’ 진행하는 것은 모두에게 어려운 일입니다. 이 프로젝트 또한 완벽하지 않았습니다.

데이터도 없었고, 권한도 제한적이었고, 잦은 계획 변경에 직접 소통도 제한적이었습니다.

하지만 바로 그 불완전함 속에서, 기획자로서 정말 중요한 것이 무엇인지 배웠습니다. 완벽한 조건이 아니어도, 주어진 환경에서 최선의 해결책을 찾아가는 것.

그것이 진짜 기획자의 역할이라고 생각합니다.

제약 속에서 실행한 일

PM 사고방식의 단련

이 프로젝트의 경험을 통해서 아래와 같은 기획자로 성장할 수 있었습니다.

완벽한 환경에서 완벽한 의사결정을 하는 사람이 아니라, 제약 속에서도 합리적 판단의 근거를 만드는 사람.

데이터가 주어져서 분석하는 사람이 아니라, 데이터 없을 때 어떻게 판단할지 방법을 찾는 사람.

권한이 있어서 결정하는 사람이 아니라, 권한 없이도 의사결정을 지원할 방법을 아는 사람.

SI 협력사, VPN 원격 근무라는 제약이 오히려 PM 사고방식을 단련시켰습니다.

다음 프로젝트에서는 사용자 접근을 더 적극적으로 시도하고, 프로토타입을 초기 단계부터 도입하며, 변경 관리를 더욱 체계화하고, 측정 가능한 목표를 명확히 설정하여 계속 발전해 나가겠습니다.

— Lane