병원의 하루를 설계하는 사람들 - KOS 프로덕트 디자이너 직무 인터뷰
KOS는 예약부터 내원, 상담, 시술, 재방문까지 이어지는 미용의료 병원의 운영을 연결하는 SaaS입니다. KOS의 프로덕트 디자이너는 병원 직원이 필요한 정보를 찾고, 예약과 현장 운영을 더 수월하게 이어갈 수 있는 경험을 설계합니다.
KOS에서 디자인한다는 것은 어떤 일일까요? 두 분의 KOS 프로덕트 디자이너께 실무에서 마주하는 문제와 일하는 방식을 들어봤습니다.
Q1. 자기소개와 KOS에 합류하게 된 이야기를 들려주세요.
Rico: 안녕하세요. KOS의 프로덕트 디자이너 이혜린(Rico, 리코)입니다.
돌이켜보면 저는 계속 ‘일하면서 겪는 문제’를 해결하는 제품을 만들어왔어요. 사내 구성원들의 업무 비효율을 해결하는 제품을 만들었고, 웹사이트 관리자가 사용하는 백오피스 기능을 설계하기도 했어요. 도메인은 달랐지만, ‘복잡한 업무를 이해하고 더 단순하고 효율적인 방식으로 바꾸는 일’인 건 같았네요.
KOS에 합류한 가장 큰 이유는 힐링페이퍼의 문화였어요. 좋은 결정을 위해 필요한 이야기를 숨기지 않고 나누는 방식을 중요하게 생각했거든요. 극도의 솔직함, 협업, 투명함 같은 단어에서 느껴지듯 서로 충분히 의견을 주고받고, 더 나은 답을 같이 만들어가는 팀이라는 점이 매력적이었어요.
그 안에서 제가 해보고 싶은 일도 분명했어요. 기존의 구조에서 조금 더 편하게 만드는 데서 끝나는 게 아니라, 사람들이 일하는 방식과 구조 자체를 더 나은 방향으로 바꾸는 제품을 만드는 과정에 참여하고 싶었어요. 인터뷰에서 제품과 팀의 비전과 목표를 듣고 나니, KOS에서는 그런 시도를 충분히 해볼 수 있겠다고 생각했어요.
Hans: 안녕하세요. KOS에서 프로덕트 디자이너로 일하고 있는 이준환(Hans, 한스)입니다. 지인 분께 추천을 받아서 KOS에 오게 되었습니다.
직전에 디자인하던 제품은 분석 솔루션이었어요. 그러다 보니 제품의 우선순위는 사용성보다 분석 결과의 정합성이었어요. 많은 VoC도 거기에 초점이 맞춰져 있었고요.
KOS는 미용 의료 병원의 실무자 분들이 사용하는 운영 솔루션입니다. 직원 입장에서는 당장 눈앞에 있는 고객을 응대해야 하는데, 조작이 번거롭거나 헷갈려서 허둥대면 안되겠죠. 직관적인 UX가 정말 중요해요. 챌린지가 확실한 환경이 디자이너로서 더 압축적으로 성장할 수 있는 기회라고 생각해, 고심 끝에 합류를 결정했습니다.
Q2. KOS는 어떤 제품인가요?
Hans: 저는 KOS를 ‘병원의 하루를 운영하고, 쌓인 데이터를 바탕으로 더 나은 운영 결정을 돕는 제품’이라고 설명하고 싶어요.
KOS는 병원의 여러 직군이 함께 사용하는 제품이에요. 코디네이터가 내원 고객의 예약을 확인하면, 상담실장은 상담 내용을 남기고 수납을 진행해요. 이어 간호사, 관리사, 의사 등이 고객이 받기로 한 시술과 서비스를 제공하죠. 그 과정에서 기기, 약물, 공간, 인력도 조율해야 해요. 정보를 저장하는 데 그치지 않고, 고객을 응대하며 다음 업무를 이어갈 때 계속 사용하는 제품이죠.
이렇게 쌓인 운영 데이터는 직원과 원장이 업무 흐름과 리소스 활용을 파악하고 개선점을 찾는 바탕이 돼요. 현장의 업무 수행이 데이터 기반의 운영 개선과 병원 전체의 매출 향상으로 이어지도록 돕는 거죠.
그렇기 때문에 현장의 정보를 연결하는 것만큼, 기록을 나중에 해석할 수 있게 하는 것도 중요해요. 예약을 잡은 날과 방문할 날, 상담한 사람과 수납한 사람이 다를 수 있으니까요. 어떤 업무에서 남긴 기록인지 알아야 지표의 의미도 제대로 이해할 수 있어요.
그래서 KOS의 프로덕트 디자이너는 개별 화면만 설계하지 않아요. 직군마다 필요한 기능을 만들면서도, 고객·예약·시술처럼 함께 사용하는 정보와 앞뒤 업무가 일관되게 연결되도록 고민해야 해요.
Q3. KOS의 프로덕트 디자이너가 일하는 방식이 궁금해요.
Rico: 프로덕트 디자이너는 스쿼드와 디자인 챕터, 두 조직에 속해서 일해요.
스쿼드에서는 프로덕트 오너, 엔지니어, 서비스 운영 매니저와 제품 문제를 풀어요. 디자인 챕터에서는 다른 디자이너들과 설계 기준, 디자인 시스템, 작업 방식을 논의해요. 스쿼드에서 고객의 문제를 깊게 풀고, 그때 얻은 기준과 패턴을 챕터에서 함께 다듬고 표준화하는 방식이에요.
프로덕트 디자이너가 직접 판단하는 범위도 넓어요. 화면 구조, 인터랙션부터 사용자 흐름, 정보 구조, 정책과 예외 조건까지 먼저 제안하는 경우가 많아요. 제품 우선순위와 비즈니스 목표는 프로덕트 오너와, 데이터 구조와 구현 방식은 개발자와 맞춰요. 업무 영역 나눠 가지기보다, 가장 잘 할 수 있는 사람들과 같이 논의하는 방식에 가까워요.
리뷰도 완성된 시안을 승인받기보다 중간 과정에서 자주 의견을 맞춰요. ‘왜 이 구조여야 하는지’, ‘빠진 예외는 없는지’, ‘다른 기능에 영향을 주지는 않는지’를 이야기하죠. 디자이너끼리도 화면의 완성도뿐 아니라 문제 정의와 논리까지 깊게 피드백하고요.
사용자와의 거리도 가까운 편이에요. 병원의 요청과 운영 이슈를 프로덕트 오너나 고객 접점의 동료에게 듣고, 필요하면 직접 인터뷰나 미팅에서 업무 방식을 확인해요. 요청 자체보다 왜 그 기능이 필요한지, 지금은 어떤 방식으로 대응하고 있는지를 알아보려 해요. 설계 중에도 궁금한 운영 방식은 다시 확인하고요.
그 외에도 반복 작업은 자동화하고, 본격적인 디자인 이전에 빠르게 프로토타입을 만드는 용도로 AI를 많이 활용합니다. 회사에서 아낌없이 지원해줘서, 잘 누리고 있습니다.
- 더 알아보기: AI 잘 써서 반복 작업이 없는 디자이너 되는 법
Q4. ‘UI 얘기하지 마세요’라는 말을 들었다면서요?
Hans: 맞아요. 디자이너한테…(웃음)
조금 배경 설명이 필요한데, KOS의 제품 설계 철학은 DDD(Domain-Driven Design, 도메인 주도 설계)입니다. 기술이나 공급자 관점으로 제품을 만드는 게 아니라 현실의 문제 영역에서 발생하는 일을 최대한 반영하려고 지향하는 설계 방식을 의미해요.
처음에는 ‘현실의 업무를 잘 이해해서 제품에 반영하는 방식이구나’ 정도로 막연하게 이해했던 것 같아요. 그런데 모델링 과정에 직접 참여해보니 이전과는 확실히 프로세스가 다르다는 걸 알게 됐어요. 디자이너가 기능 정책을 먼저 짜거나 화면을 먼저 그려보지 않더라고요. 우리가 해결하고자 하는 현실에서는 어떤 일들이 일어나며, 그 속에서 어떤 문제가 발생하는지를 봐요. 그리고 어떤 경험을 전달해야 이 문제들이 해결될 수 있는지 세계관과 이야기를 정립하는 과정을 거쳤어요. 아마 이 과정에서 들으셨던 얘기인 것 같습니다.
그러다 보니 제품에서 다루는 개념과 관계를 먼저 맞춰보고, 디자이너가 어떤 구조를 기반으로 경험을 설계해야 하는지가 훨씬 선명해지더라고요.
여기서 특히 인상적이었던 건 이 언어를 개발자만 사용하는 게 아니라는 점이에요. 프로덕트 오너, 프로덕트 디자이너, 개발자가 같은 도메인 언어를 바탕으로 현실의 문제를 함께 해석하고, 그 위에서 가장 적절한 제품 구조를 찾으려고 해요. 모두가 같은 세계관을 이해한 상태에서 제품을 만든다는 게 가장 특이하면서도 이상적인 개발 문화라고 생각해요.
Q5. ‘KOS팀은 의사만 있으면 클리닉 차릴 수 있다.’ 사실인가요?
Rico: 아쉽지만 한국에서는 법적 이슈로 실현되기 어려운 일이에요.(웃음) 하지만 그만큼 KOS가 미용 의료 병원의 최적화된 운영 방식을 잘 알고 있다는 말처럼 들리는 것 같아요.
처음으로 KOS를 사용하게 되는 병원은 KOS팀이 직접 현장에서 제품 사용을 위한 지원을 도와드리고 있어요. 영업·운영 팀 이외에 제품 팀이 직접 현장 지원을 나가기도 하는데요. 제품의 구조를 아는 메이커 직군이 안내함으로써 더 정확한 도움을 줄 수 있고, 현장에서 직접 보고 체감한 인사이트가 제품에 반영돼야 병원 운영의 실질적인 변화를 만들 수 있다고 믿기 때문이에요.
처음 현장 지원 얘기를 들었을 때만 해도 반나절 잠깐 둘러보면서 직원 분들 도와주는 정도라고 생각했어요. 그런데 현장 지원 전부터 병원의 기존 운영 흐름을 차근차근 분해하고, ‘이 경우에는 상담실장님이 어떻게 응대하고 있나요?’ 같은 질문이 이어지는 걸 보면서, KOS가 병원 운영에 영향을 주는 범위가 생각보다 넓고 깊다는 걸 알게 됐어요. 현장 지원을 나가서도 실무자 분들과 소통하면서 문의를 소화하고, KOS를 더 잘 쓸 수 있는 방법을 제안해 보기도 해요. 이렇게 현장에서 바쁘게 움직이는 과정에서 얻는 인사이트가 굉장히 많다고 느껴요.
Q6. 사용자의 업무를 절반으로 줄였다고 들었어요.
Hans: 네, 정확히는 고객이 신청한 예약을 원내 직원이 한 번 손보는 비율이 절반 가까이 줄었어요. ‘예약 규칙’을 도입한 덕분이죠.
병원에서 예약을 잡는 건 빈 시간 하나를 고르는 일이 아니에요. 예를 들어 상담 30분, 마취 30분, 시술 30분이 순서대로 필요할 수 있어요. 어떤 상담실장의 일정이 비어 있어도 그다음 마취나 시술을 처리할 수 있는 인원이 없으면 그 시간에는 고객을 받을 수 없는 거죠. 상담을 마친 고객이 긴 대기를 감수해야 할 테니까요. 고객이 일본어를 사용하면 일본어가 가능한 상담실장이나 통역사 일정을 고려해야 하고, 하루에 여러 시술을 받는다면 그 순서도 생각해야 하고요.
1,000칸 가까이 되는 복수 시술 사례 표를 가지고 업무하는 고객사가 있었어요. 고객이 인모드와 보톡스를 받고 싶다고 하면 가로축에서 인모드를 찾고 세로 축에서 보톡스를 찾고 교차되는 셀을 확인하는 거죠. 그제야 해당 시술을 같은 날 받을 수 있는지, 있다면 어떤 순서로 받아야 하는지 알 수 있었어요. 이 작업을 예약을 잡을 때마다, 예약을 수정할 때마다 한 거죠. 그러다 진행하기 어려운 조합이면 고객에게 연락해서 예약을 바꿔달라고 요청해야 했죠.
직원에게는 확인과 조정 업무가 생기고, 고객은 이미 확정한 일정을 다시 맞춰야 하는 상황이었어요. 예약 입력을 조금 더 빠르게 만드는 것보다, 처음부터 실제로 진행 가능한 예약을 받게 하는 게 중요했습니다.
그래서 만든 게 ‘예약 규칙’이에요. 어떤 고객이 어떤 시술을 희망할 때, 어떤 일정을 어떤 순서로 확보해야 하는지 병원이 미리 설정할 수 있게 했어요. 온라인에서 고객이 예약할 때도 그 규칙을 기준으로 필요한 일정이 모두 들어가는 시간을 안내하도록 했고요. 직원이 예약을 받은 뒤 머릿속의 규칙과 대조해 고치던 일을, 예약이 만들어지는 시점에 시스템이 처리하도록 바꾼 거예요.
그 규칙을 직원이 직접 예약할 때도 쉽게 활용할 수 있도록 했어요. 마취 자리, 시술 자리를 각각 찾아 맞추는 대신, 고객과 예약 정보를 바탕으로 추천된 시간을 고르면 필요한 일정이 함께 구성되도록 했습니다. 다만 규칙만 적용하는 별도 화면으로는 충분하지 않았어요. 고객의 과거 내역과 특이사항도 보면서 예약을 잡아야 하니까요. 그래서 고객 차트 안에 예약 편집 모드를 만들고, 다른 예약의 점유 상황을 보면서 필요하면 직접 조정할 수 있게 했습니다.
도입 후 들은 VoC가 기억에 남아요. 예약할 수 있는 시간이 미리 보여 안내하기 쉬워졌고, 나중에 고객에게 일정 변경을 요청하며 불편을 끼치지 않게 되어 좋다고 하셨어요. 다음 방문 예약을 잡거나 방문 전 차트를 점검하는 부담도 줄었다고 했고요. 직원용 예약 화면은 처음에는 조작을 익힐 필요가 있었지만, 익숙해진 뒤에는 필요한 자리를 하나씩 찾아다니던 때보다 시간이 크게 줄었다는 평가를 받았습니다.
실제 사용 데이터에서도 직원이 신규 예약을 생성하는 시간이 약 40% 짧아졌어요. 예약을 만드는 시간은 줄이고, 만들어진 일정을 다시 손봐야 하는 상황도 줄인 것이 이 프로젝트의 성과라고 생각해요.
이 프로젝트를 하면서는 ‘이 일을 어떻게 더 쉽게 하게 할까?’뿐 아니라 ‘이 일을 꼭 사람이 매번 해야 할까?’도 물어봐야 한다는 걸 느꼈어요. 화면에서 몇 번 덜 누르게 하는 데서 끝나지 않고, 직원이 뒤에서 확인하고 조정하던 일을 덜어내는 것까지 디자인의 범위로 볼 수 있었던 경험입니다.
Q7. 지금 KOS에 합류한다면 무엇을 바꿀 수 있나요?
Rico: KOS는 PMF를 찾았고, 이제 본격적인 스케일업에 집중하는 단계예요. 이 시기에 프로덕트 디자이너는 크게 두 가지에 집중하고 있어요.
첫 번째는 전반적인 사용성 개선이에요. 앞서 Hans가 말씀해 주셨듯이, KOS는 누적된 데이터를 기반으로 병원 운영 최적화를 달성하고자 하는 솔루션이에요. KOS가 지원하는 각종 데이터 필드와 입력 형식은 이런 가치를 고려해서 설계됐어요. 운영 편의만을 위해 명확한 분류나 구획 없이 여러 필드를 만들어놓은 타제품 대비 차별화되는 지점이에요.
하지만 이 엄밀함이 바쁜 업무를 하고 있는 원내 실무자 분들에게는 허들이 될 수도 있어요. 지금까지는 0 to 1을 하는 과정에서 우선순위에서 많이 밀리기도 했지만, 반드시 챙겨야 하는 일이며 디자이너만이 해낼 수 있다고 생각해요. 사용자가 덜 고민하면서도, 더 정확하고 편한 입력을 보장할 수 있을지 생각해야 해요.
두 번째는 공통화예요. 제가 지금까지 경험한 과제들을 보면, 앞으로 KOS는 더 많은 병원을 지원하면서도 어떤 공통 제품으로 남을 것인지 구체화하는 일이 중요해질 것 같아요.
병원마다 운영 방식이 꽤 달라요. 새로운 병원을 만날 때마다 새 기능을 추가하는 방식으로 당장의 요청은 빠르게 해결할 수 있겠지만, 다른 병원은 알아야 할 기능들이 계속 늘어나 불필요한 학습 부담을 만들 수도 있어요.
반대로 모든 병원을 하나의 흐름에 맞추면 병원의 니즈에 맞는 업무 관리 방법을 제품에서 충분히 커버하지 못할 수도 있어요.
앞으로는 무엇을 KOS의 공통 구조로 만들고, 무엇을 병원별로 맞출지를 더 많이, 더 신중하게 결정해야 하는 시기라고 생각하고, 지금 KOS에서 프로덕트 디자이너가 크게 기여할 수 있는 영역이라고 생각해요.
결국 지금 눈앞의 요청을 잘 해결하는 것만큼, 다음에 문제가 생겼을 때도 또 쓸 수 있는 기준과 구조를 만드는 일이 중요하다고 생각해요.
그래서 이미 잘 정리된 제품을 운영하는 것보다, 복잡한 도메인을 이해하면서 제품의 기준과 구조를 함께 만들어가는 일을 좋아하는 분이라면 KOS에서 바꿀 수 있는 게 굉장히 많다고 생각해요.
Q8. 지원을 고민하는 분들에게 하고 싶은 말이 있나요?
Hans: 저는 눈앞에 보이는 해결책보다, 실제로 풀어야 할 문제가 무엇인지 궁금해하는 분이라면 KOS에서 꽤 재미있게 일할 수 있을 것 같아요.
KOS에서는 기능 하나를 만들 때도 그 화면만 보는 경우가 많지 않아요. 이 기능을 누가 어떤 상황에서 쓰는지, 앞뒤 업무와 어떻게 연결되는지, 다른 직군에게는 어떤 영향을 주는지까지 같이 봐야 해요. 처음에는 단순해 보였던 문제가 파고들수록 전혀 다른 구조의 문제로 바뀌는 경우도 참 많고요.
복잡한 도메인이라고 해서 꼭 복잡한 화면을 만들어야 한다고 생각하지는 않아요. 오히려 현장에는 이미 나름의 업무를 위한 체계가 있는데, 제품은 아직 충분한 업무 범위를 커버하지 못하거나 이해도가 부족한 상태로 설계된 경우도 많아요. 그 복잡함을 이해한 뒤 사용자가 더 쉽고 편하게 일할 수 있도록 바꾸는 과정을 좋아하는 분이라면 잘 맞을 것 같아요.
또 자기 설계에 확신을 가지면서도, 그 답을 계속 의심해 볼 수 있는 분이면 좋겠어요. 논리적으로 맞는 구조라도 실제 사용에서는 불편할 수 있고, 개발 과정에서 새로운 제약을 발견할 수도 있으니까요. 동료들과 계속 피드백을 주고받고, 더 나은 근거가 생기면 처음에 생각한 답도 바꿀 수 있는 태도가 중요하다고 생각해요.
지원하실 때에도 꼭 큰 프로젝트나 화려한 결과가 아니어도 괜찮아요. 처음에는 문제를 어떻게 찾았고, 어떤 문제라고 생각했고, 무엇을 확인하면서 생각이 달라졌고, 왜 그 선택을 했는지를 자세히 들려주시면 좋을 것 같아요. 프로젝트의 크기보다 그 판단 과정이 구체적으로 보이면, 같이 일하는 모습을 훨씬 더 잘 상상할 수 있거든요.
복잡한 운영을, 더 수월하게 이어지는 업무로
KOS 프로덕트 디자이너의 일은 병원의 복잡함을 화면에 빠짐없이 옮기는 일이 아닙니다. 직원이 필요한 정보를 찾아 업무를 수행하고, 다음 사람에게 일을 이어갈 수 있도록 경험을 만드는 일입니다.
그러기 위해 사용자의 목적과 제품의 확장성을 함께 보고, 동료와 설계, 구현, 검증을 이뤄내야 합니다. 복잡한 구조를 설명하는 데서 나아가, 그 구조가 실제 업무에 도움이 되는지 확인하는 것이 중요합니다.
현장감 있는 업무를 깊이 이해하고, 여러 병원에서 쓸 수 있는 제품의 변화로 연결하고 싶다면 KOS의 문제를 함께 풀어주세요.