WOOWACON 2024 참석 후기 (feat.PM 메타 인지)

(본 글은 WOOWACON 2024 신청 과정, 현장 안내와 같은 내용을 다루지 않습니다.)

WOOWACON 2024 참석한 목적 : 메타인지

회사에서 일을 하다 보면 내가 잘하는지 못하는지에 대한 비교 대상은 한정적이다. 그리고 잘 하는 사람으로부터 좋은 스킬들은 습득하는 것도 보통 1년이면 끝난다. 그래서 나의 현재 위치를 확인하고 또 다른 배움을 얻기 위해 'WOOWACON 2024'에 참석을 결정했다. 특히 이번 컨퍼런스에서는 다양한 PM 세션이 마련되어 있어서 각자의 문제 해결 방식과 업계의 최신 트렌드를 접할 수 있기 때문에 나를 스스로 평가하기에 좋은 기회였다. 

 

< 참석한 PM 세션 >

1. OKR과 프로젝트의 연결 고리 : 과제 관리의 새로운 판을 짜다

2. 파인 튜닝 없이, 프롬프트 엔지니어링으로 메뉴 이미지 검수하기

3. 장애 같은데? 일단 STOP! : 배달 서비스 장애 감지 / 차단 시스템 구축 경험담

 

그 외에도 더 많은 PM 세션들과 PM 업무에 관련된 세션들도 있었지만 나를 평가하기 위해서는 위 3가지 세션이 적절하다고 생각했다. 컨퍼런스 참여 이유가 메타인지였기 때문에 최대한 나의 직업과 관련된 세션에 집중하고자 했다. 

 

1번 OKR 세션을 고른 이유는 내가 입사 초기에 실패했던 미션과 비슷했었기 때문이다. 나는 입사 초기에 각 부서를 평가하고 관리할 수 있는 지표를 설계하는 미션을 받았었다. 나도 그 때 OKR을 선택해 회사의 환경에 맞게 고도화했지만 결과적으로 부서들의 공감을 얻지 못해서 소프트 랜딩에 실패한 경험이 있다. 이번 세션을 통해 나의 실패 원인을 되돌아보고, 더 나은 접근 방식을 배우고 싶었다.

 

2번 프롬프트 엔지니어링 세션을 고른 이유는 내가 제일 관심 있는 분야이기 때문이다. 나는 프롬프트 엔지니어링이 곧 PM이 갖춰야 할 필수 역량이 될 것이라고 확신하기 때문에 이 세션을 꼭 듣고 싶었다. 특히 복잡한 파인 튜닝 없이도 프롬프트 엔지니어링만으로 실제 서비스의 문제를 해결한 사례를 통해, 현업에서의 실질적인 적용 방법을 확인하고 싶었다. 

 

3번 장애 대응 세션을 고른 이유는 내가 경험해보지 못한 분야이기 때문이다. 나는 크리티컬하게 실시간으로 장애를 대응하고 조치한 경험이 없다. 하지만 앞으로 꼭 경험하게 될 업무라고 생각한다. 앞으로 내가 마주하게 될 상황에 대한 좋은 학습 기회가 될 것이라 생각했다.

 

< 참석한 PM 세션 + 참석 이유 >

1. OKR과 프로젝트의 연결 고리 : 과제 관리의 새로운 판을 짜다 → "과거의 실패 경험"

2. 파인 튜닝 없이, 프롬프트 엔지니어링으로 메뉴 이미지 검수하기 → "현재 관심 분야"

3. 장애 같은데? 일단 STOP! : 배달 서비스 장애 감지 / 차단 시스템 구축 경험담 → "미래 준비"

 

이렇게 선택한 세션들은 각각 '과거의 실패 경험', '현재 관심 분야', '미래 준비'라는 시간적 맥락을 가지고 있다. 이를 통해 PM으로서 나의 과거와 현재를 돌아보고, 앞으로의 성장 방향을 그려볼 수 있는 좋은 기회를 포착하고자 했다. 

 

 

OKR과 프로젝트의 연결 고리: 과제 관리의 새로운 판을 짜다

OKR과 프로젝트의 연결고리 : 과제 관리의 새로운 판을 짜다 세션

 

OKR(Objectives and Key Results)은 조직이나 팀의 목표를 설정하고 달성하기 위한 목표 관리 프레임워크이다. 구성요소인 Objectives(목표)는 달성하고자 하는 정성적이고 영감을 주는 큰 목표를 뜻하고 Key Results(핵심 결과)는 목표 달성을 측정할 수 있는 구체적이고 정략적인 지표이다. 

 

배달의 민족으로 예시를 들어보면 아래와 같다. (가안)

 

Objectives : 최고의 사용자 경험을 제공하는 배달 앱 만들기

Key Results : 

  1. 앱 사용자 만족도 점수 4.5점 이상 달성

  2. 주문 완료까지 평균 소요 시간 3분 이하로 단축

  3. 월간 활성 사용자 수 20% 증가

 

배달의 민족 같은 경우는 성과보다는 목표, 목적, 과정에 초점을 맞추기 위해 21년도부터 OKR을 적용하기 시작했다. 도입 초반에는 관리 프로세스의 미흡함으로 OKR 헬스 체크가 제대로 되지 않았고 구성원들의 미인지로 인해 공감대를 형성하기 어려웠다고 한다. 하지만 끊임없는 소통과 회고, OKR 대시보드의 보완, 조직별 과제와 연결을 통해 현재는 보다 안정적으로 전사적으로 OKR 적용했다. 

 

소통의 부재로 인해 목표가 중복되는 사일로 현상 발생

 

특히, 소통의 부재로 인해 목표가 중복되는 사일로 현상을 해결한 것은 주목할만했다. 실별로 소통하지 않은 채 목표, 핵심 결과를 설정하다 보면 같은 목표, 핵심 결과를 설정하는 비효율성을 초래할 수 있다. 하지만, 배달의 민족은 전사적으로 OKR를 도입하고 실별 소통 환경을 보장해서 이러한 문제점을 차단한 것 같았다. 

 

그리고 세션 후반부에서는 실제로 배달의 민족에서 쓰고 있는 OKR 대시보드를 소개해 주셨다. 나도 나중에 활용하기 위해 구글 시트에 아래와 같이 재가공해 보았다. (배달의 민족에서 소개한 OKR과 상이한 부분이 있음)

 

재가공한 OKR 대시보드

 

위 대시보드는 내가 임의의 부서, 이름, 목표 등을 가안으로 기입했다. 

 

데이터 제목 설명:

• 부서: 해당 OKR을 수행하는 조직 단위 
• 목표: 부서가 달성하고자 하는 정성적인 목표
• Key Result: 목표 달성 여부를 측정할 수 있는 정략적 지표
• Key Result 설명: 해당 Key Result가 중요한 이유, 측정 방법
• Key Result 히스토리 : 해당 Key Result 달성 과정에서의 주요 이벤트, 변경사항
• 담당자 : 해당 Key Reult의 데이터를 기록하는 담당자
• 목표 시작값 : 시작 시점의 현재값
• 목표 목표값 : 24년 말까지 달성하고자 하는 목표값
• 분기별 데이터 : 분기별 실제 데이터값, 목표값 대비 달성률에 따라 그라데이션
• 목표값 대비 달성률 : 목표값 대비 실제 Key Result 달성값

마지막으로는 현재 배달의 민족에서도 해결하지 못한 문제들을 소개했다. JIRA와 연동 문제, 잦은 회고의 생산성 등이 주요 문제로 제기되었다. JIRA 연동 문제 같은 경우는 세션을 듣기 전 궁금했던 문제였는데 해결책을 찾지 못해서 더욱 아쉬웠다. 

 

정리:

< OKR과 프로젝트의 연결 고리 : 과제 관리의 새로운 판을 짜다 >

- 내용 : 전사적 OKR를 수립하고 적용하는 과정 소개
- 주요 인사이트 : 조직원들의 공감을 끌어올리기 위한 반복적 회고의 중요성, 대시보드 수치화
- 아쉬웠던 점 : JIRA와 OKR 대시보드 미연동

 

세션을 듣고 나의 실패 경험을 돌이켜보니, 나의 OKR 적용 경험은 주기적인 리마인드와 소통 부분이 많이 아쉬웠다. 사실 OKR 대시보드 자체는 엄청난 와우 포인트가 있는 기능이 아니다. 그저 목표를 관리하고 진척도를 추적하는 도구일 뿐이다. 하지만 나는 OKR을 담당하는 사람으로서 부서 담당자의 데이터 관리와 기입에 소홀했고, 더 중요한 '주기적인 회고 자리'를 만들지 않았다. 이는 결국 구성원들이 OKR을 '또 하나의 귀찮은 업무'로 인식하게 만들었던 것 같다.

 

다음에 OKR과 같은 조직 전반의 미션이 주어진다면, 시스템 구축 자체보다는 구성원들의 공감과 참여를 이끌어내는 데 더 많은 노력을 기울일 것이다. 특히 정기적인 리뷰 미팅을 통해 각 부서의 고충을 듣고, OKR이 실제로 도움이 되는 도구라는 것을 증명하는 데 집중하고 싶다.

 

 

파인 튜닝 없이, 프롬프트 엔지니어링으로 메뉴 이미지 검수하기

파인 튜닝없이, 프롬프트 엔지니어링으로 메뉴 이미지 검수하기 세션

 

다음 세션은 프롬프트 엔지니어링에 관련된 세션이었다. 나도 회사에서 LLM을 자주 사용하다 보니 제일 관심이 가는 세션이었다. 프롬프트 엔지니어링은 GPT, CLAUDE 등과 같은 AI 모델로부터 원하는 결과를 얻기 위해 입력을 효과적으로 설계하는 기술이다. 쉽게 설명하면 사람이 AI와 대화할 때 '어떻게 질문하면 더 좋은 답변을 받을 수 있을까?'를 연구하고 실행하는 것이다. 

 

배달의 민족 같은 경우에는 메뉴 이미지 검수에 GPT를 사용하게 되어 프롬프트를 구체화하기 시작했다고 한다. 가게 사장님들이 메뉴 사진을 올리기 위해서는 검수가 필요하다. 하지만 주말이나 공휴일이 겹치면 사장님들의 대기 시간이 길어지는 문제가 발생한다. 이러한 문제를 해결하기 위해 GPT와 많은 상호작용을 한 것처럼 보였다. 

 

세션의 대부분은 GPT를 더 효과적으로 제어하기 위해 System Instructions, Prompt, Parameter을 어떻게 조정했는지 설명이었다. 주요한 인사이트는 아래와 같다. 

- System Instructions : 입력된 데이터에 대한 암시, 이중부정 표현 삭제

- Prompt : 요구사항 분리, 빠른 응답을 위한 조건, 구체적이고 세분화된 정책 항목, 응답 예시 제공

- Parameter : 서비스에 맞는 값 조정, 출력 안정성 보장

 

메뉴 이미지 검수를 위해서 다양한 케이스의 샘플 사진들을 준비해서 정교한 테스트를 성공적으로 한 것 같았다. 서로 다른 케이스의 90여 개의 이미지로 테스트를 했다고 한다.  중간중간에 이미지 검수에 실패한 사례도 나와서 재밌게 들었던 것 같다. 하지만 기초적인 부분만 다뤘기 때문에 프롬프팅에 관심이 많은 사람이라면 조금 아쉬웠을 것 같다. 물론 도입 당시의 지식, 학습 능력과 현재와의 시간 차이가 있기 때문에 충분히 이해하는 부분이다. 

 

프롬프트 정책 구체화 과정

 

정리: 

< 파인 튜닝 없이, 프롬프트 엔지니어링으로 메뉴 이미지 검수하기 >

- 내용 : ChatGPT 프롬프트 레슨 러닝

- 주요 인사이트 : 안전한 자동화를 위한 탐구적 자세, 테스트를 위한 자료 확보

- 아쉬웠던 점 : 프롬프트 엔지니어링에 대한 기초지식 위주로만 소개

 

현재의 나와 비교해 보니, 프롬프트 엔지니어링에 대한 나의 경험과 이해도가 업계 평균 이상이라는 것을 확인할 수 있었다. 배달의 민족의 사례처럼, 나 또한 수많은 시행착오를 겪으며 프롬프트 엔지니어링을 발전시켜왔다. (Claude의 오토 프롬프팅 기능이 나오기 전까지 ㅎㅎ) 이번 세션을 통해 내가 그동안 쌓아온 경험이 결코 헛되지 않았다는 확신과 함께, 앞으로 더 발전시켜 나가야 할 방향도 명확히 할 수 있었다.

 

 

장애 같은데? 일단 STOP!: 배달 서비스 장애 감지/차단 시스템 구축 경험담

장애 같은데? 일단 STOP! 세션

 

마지막 세션은 배달 장애 대응을 공유하는 내용이었다. 아직 나는 심각한 장애를 실시간으로 대응해 본 적이 없어 어떤 시스템으로 배달의 민족이 장애를 다루고 있는지 궁금해서 청취했다. 그리고 내가 나중에 어떻게 카피할지 생각해 보기도 했다. 

 

배달의 민족 같은 경우는 도요타의 안돈 시스템 컨셉을 적용했다고 한다. 안돈(Andon) 시스템은 도요타가 개발한 품질 관리 시스템으로, '문제가 발견되면 즉시 생산라인을 멈추고 문제를 해결하자'는 철학을 바탕으로 한다. 주요 특징으로는 즉각적인 대응, 모든 직원의 참여, 예방적 접근이 있다. 

 

따라서, 아래와 같이 배달의 민족의 장애 대응 프로세스가 바뀌었다. 

 

AS-IS : 장애 발생 ▶ 담당자 인지 ▶ 장애 공지 ▶ 원인 파악 ▶ 영향 범위 파악 ▶ 의사결정 ▶ 조치

TO-BE : 장애 발생 ▶ 이상상황 감지 ▶ 임시 조치 ▶ 이상상황 공지 ▶ 장애 여부 및 원인 확인 ▶ 영향 범위 파악 ▶ 의사결정

 

이상상황 감지 이후 프로세스

 

빠르게 이상 상황을 감지하고 즉각적인 조치를 통해 효율적인 커뮤니케이션을 지향하는 프로세스로 바뀐 컨셉인듯 하다. 

 

세션이 종료되고 미래의 내가 어떻게 해야 되는지 생각해 보았다. 우선 장애 대응은 사전 준비가 가장 중요한 것 같다. 시스템이 완벽할 순 없지만, 최소한의 피해로 빠르게 대처하기 위해서는 장애 시나리오별 대응 프로세스가 미리 정립되어 있어야 한다. 미리 정립하기 위해서 수많은 과거 데이터를 살펴보면서 유사한 장애를 어떻게 대응할지 문서화하는 작업도 필요할 것 같았다. 또한 빠른 의사결정과 실행이 핵심인 만큼, 명확한 역할 분담과 커뮤니케이션 체계를 갖추는 것에 대한 고민이 깊어졌다. 

 

 

모든 세션을 듣고 나서

이번 WOOWACON 2024 참석은 나의 현재 위치를 객관적으로 파악하고, 앞으로의 성장 방향을 설정하는 시간이었다. 각각의 세션들을 통해 OKR 운영의 실패 경험에 대한 보완점을 파악했고 프롬프트 엔지니어링에 대한 자신감 확인했다. 그리고 장애 대응 시스템 구축에 대한 인사이트까지, PM으로서의 다양한 역량을 점검하고 발전시킬 수 있었다. 따라서 이러한 컨퍼런스를 자주 다녀야 되겠다는 생각에 확신이 들었다. 

 

그리고 마지막으로 장애 대응 세션에서 '과제 속 PM의 역할'을 언급 주셨는데 나의 업무를 어떻게 정의하고 정리할지에 대해 많은 도움이 되어 공유한다. 

 

과제 속 PM의 역할 : 문제 정의, 문제 해결 방안, 기준 검증, 고도화, 소통

 

과제 속 PM의 역할