brunch

매거진 성장하는 이들의 이야기 그로스토리

라이킷 35 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 마켙커리어 Jul 05. 2021

아무도 알려주지 않는 이커머스와 서비스 기획을 알려주마

#그로스토리23 지그재그 서비스 기획자/PO 이미준 (도그냥)

성장한 이들의 경험담, '그로스토리' 시리즈입니다. 시행착오를 먼저 겪고 성과를 낸 이들의 인터뷰를 통해 실무 꿀팁을 얻어보세요!

➔ 그로스쿨 웹사이트 구경하기

인터뷰이 간단 소개

이커머스 서비스 기획자이자 PO인 도그냥 이미준 님을 만나 서비스 기획 이야기를 들어보았습니다.

일잘러를 위한 교육 플랫폼, 그로스쿨입니다.

최기영(그로스쿨 대표, 이하 최): 지금 무슨 일을 하시죠?

도그냥(이커머스 서비스 기획자 이미준, 이하 도그냥): 지금은 서비스 기획자 역할을 해요.

도그냥 이미준 님.

최: 사실 서비스 기획이라는 게 들으면 그렇구나 하지만, 정확히는 다 모르잖아요.

도그냥: 가장 비슷한 직무를 찾으라고 하면 프로덕트 매니저가 제일 비슷한 것 같고요.

최: PM?

도그냥: 프로젝트가 아니라 프로덕트 매니저가 제일 비슷한 것 같은데요. 국내의 서비스 기획자 역할이 은 해외의 프로덕트 매니저보다 훨씬 넓어요. 프로덕트 매니저가 비즈니스 요구 사항을 분석해 무엇을 개발해야 하는지, 어떤 서비스를 만들어야 하는지 정리하고 프로젝트를 리딩 하는 역할까지인 건 비슷한데… 국내의 서비스 기획자들은 개발에 필요한 케이스 분리나, UI 설계까지도 초안 작업은 개발, 디자인 등 해당 담당자와 거의 함께하고요. 그래서 문제가 발생했을 때 그걸 해결하는 부분도 더 깊게 들어가야 하는 경우가 많습니다. 근데 개인 능력차에 따라 달라서 기획자가 프런트 UI만 아는 사람은 딱 UI 설계까지만 들어가고 다른 건 하지 않는 경우도 있고, 백오피스나 로직 설계만 할 줄 아는 분은 로직 설계만 하고 다른 건 안 하는 경우도 있지요.

서 있는 곳이 다르면 서로를 다르게 보게 된다.

최: 얇게 넓게 알아야 한다?

도그냥: 제가 지향하는 한국판 프로덕트 매니저는 ‘가장 깊게, 가장 넓게’ 예요.

최: 제가 들은 말 중에서 가장 충격적인데, 보통은 I형 인재로 시작을 했죠. 그다음에 T자형 인재를 구했어요. 넓게, 그러나 한 분야에서만큼은 깊게, 근데 사실 슈퍼 PM들은 일단 다 알아야 하는 것 같긴 해요. 잘 모른다고 개발자한테 휘둘리고, 디자이너에게 당하고.

도그냥: 맞아요, 무시당하지 않게.

최: 또 잘 알아야 합리적인 개발 공수 산정을 받을 수 있어요.

도그냥: 그럼요. 아는 만큼 힘이 돼요. 그런 사례들 있거든요. 진짜 업무에서 그런 일이 있어요. 제가 없을 때 다른 주니어가 가서 개발과 협의를 했는데 생각보다 굉장히 여유로운 작업 일정을 받아 온 거예요. 가서 깊이 이야기하고 대안을 제시하고 했더니 바로 다음 날 처리할 수 있을 만큼의 양으로 방법을 바꿀 수 있었죠. 다음 날 바로 처리가 됐어요.

최: 잘 모르면 그럴 수밖에 없죠. 도그냥님의 역할은 요구 사항을 도출하는 것부터 시작하는 거예요?

도그냥: 비즈니스에서 뭐가 필요한지 현업에서 요청하면 서비스 구현을 위한 협의를 하는 단계, 그리고 기존의 서비스에 뭔가 이슈가 있거나 개선이 필요한지를 검토하고 프로젝트를 막 시작하려고 하는 단계, 거기서부터 투입이 되죠.

최: BA(Business Analytics) 또는 PI(Process Innovation).

도그냥: 예를 들어서 새벽 배송 시스템을 만든다,라고 했으면 SCM 부서나 마케팅 부서에서 ‘새벽 배송을 합시다’가 여러 가지 논의로 정리됐겠죠. 그러면 바로 기획자가 붙는 거죠. 시스템 구현을 위해서 여러 가지를 물어보면서 같이 업무자들의 흐름을 정리 해나 가요. ‘어떻게 배차해야 하죠? 물건은 어느 정도 들어가야 하죠?’ 이런 것들에 대해 함께 세세하게 정리하는 거예요. 주문 시간은 몇 시부터 몇 시까지 접수해야 하는지, 상하차를 하는 데 드는 시간이 얼마 나오는지를 통해서 함께 정리해나가죠.

최: 그렇게 비즈니스 요구 사항이 정리되면 다음에 ‘애들 불러 모아’, 해서 프로젝트팀이 꾸려지고.

도그냥: 그렇죠, 프로젝트 끝날 때까지. 오픈할 때까지.

최: 지금 몇 년 차세요?

도그냥: 10년 조금 넘었네요.

최: 거친 프로젝트가 꽤 많을 것 같아요. 10년이면.

도그냥: 그렇죠. 저는 회사에서 프로젝트 쪽을 주로 해서.

최: 보통은 운영하다 프로젝트하고, 왔다 갔다 하지 않나요? 프로젝트 끝나면 ‘이 시스템은 이렇게 쓰시면 됩니다.’라고 교육하고, 또 새로운 프로젝트 들어오면 만들어서 다시 주고, 교육하고요.

도그냥: 이게 운이 잘 못 풀렸거나 잘 풀렸거나, 어떻게 보면 잘 풀린 거고 어떻게 보면 안 풀린 건데… 교육하고 알리고, 사용하는 패턴 보고 수정할 거 있으면 수정 기획을 하죠.

최: 그럼 이커머스 분야의 다양한 분야를 그냥 알 수밖에 없겠네요.

도그냥: 알 수밖에 없어요. 저 같은 경우에는 여러 프로젝트를 하면서 이런저런 것을 보다 보니까 운영하는 곳들의 상황과 정책을 깊이 팔 수밖에 없으니까요. 배송 쪽 구축하다가 고객 CS 처리 프로젝트하고, 주문 관련 시스템 구축하고… 프로젝트를 하면서 협업을 하게 되는 부서도 다 다르고요. 어떨 땐 MD랑 밀접하게 일하고 또 어떨 땐 마케터랑 일하고. 그러면 그들이 일하는 내용에 대해서 알 수밖에 없지요.

최: 하나 만들고 싶은 생각 없으세요 직접?

도그냥: 아유… 제가 창업을 할 수 있을 정도의 사람은 아닌 것 같아요. 그저 정보를 모으고 쌓고 구조화하는 건 굉장히 좋아하고, 제가 정리한 지식을 활용해서 저보다 똑똑한 사람들이 더 좋은 걸 만들었으면 좋겠어요, 제가 만드는 것에만 제 지식을 투자하면 실패했을 때 제 지식은 사장되잖아요.

최: 그런가요?

도그냥: 제가 아는 것을 바탕으로 제가 사업화해서 실패하면 그 지식은 날아간다고 생각해요. 하지만 그러기엔 아깝죠. 제가 엄청 잘한다기보다는 제 생각엔 저보다 많이 아시는 훨씬 많은 선배가 이커머스를 구축했고, 시장 내에는 여전히 이커머스 구조는 잘 모르는 분들이 많아요. 잘 아시는 분들이 자기만 알고 끝나는 경우가 많았던 거죠. 저는 그런 노하우가 잘 모아져서 온라인 비즈니스 생태계 전체가 수준이 올라갔으면 좋겠어요.

특히 기획자. 일해보면 기획자의 수준 차이가 천차만별이거든요. UI를 그림처럼 그려서 개발에 넘기며 ‘나 기획 다 했어요’, 이러면 개발은 까무러칠 듯 반응하는 그런 기획자도 있어요. 디자이너의 역할도 기획의 역할도 하지 못하는 것이죠. 물론 그렇게만 해도 개발이 알아서 쉽게 판단해서 진행이 되는 단순한 프로덕트도 있지만, 이커머스 같은 경우는 복잡도가 굉장히 높거든요. 케이스도 하나하나 구분할 수 있어야 하고, 데이터도 볼 줄 알아야 해요. 꼭 고객의 데이터뿐 아니라 실제 쌓인 주문 데이터 같은 것도 말이죠. 기획자들의 전반적인 수준을 다 높여 놓으면 더 이상 ‘기획자 필요 없다’ 이런 소리 안 나오게 되지 않을까요? 그랬으면 좋겠는 거죠.

출처: appkont

최: 그러게요. ‘기획자 필요 없다’는 얘기들이 종종 들리죠. 그건 왜 그럴까요?

도그냥: 업력이 높은 기획자를 만날 일이 없거나, 아니면 회사나 프로젝트나 프로덕트의 규모가 작아서 아직 기획자가 투입될 필요가 없도록 단순하거나 한 경우라고 생각해요. 초기 스타트업에서 빠른 구축을 위해 오픈소스나 상용화 툴을 많이 사용해서 복잡한 부분이 이미 고정화되어 있다면 기획자는 필요 없을 수 있어요. 오픈소스는 이미 충분히 여러 가지 케이스를 고려해 만들어 놓은 거니까요. 그럼 기획자가 필요 없어요.

최: 스마트 스토어 같은 경우도?

도그냥: 이미 구현된 서비스에서는, 기획자 필요 없고 마케터가 필요하잖아요.

최: 그림만 그리는 기획자는 또 어떤 건가요?

도그냥: UI 설계의 중요성을 무시하는 것은 아니에요. 단지 그 UI를 설계하기 위해서 케이스나 데이터에 대해서 전혀 생각을 안 하는 경우가 문제인 것이죠. 우리가 가진 데이터로는 구현할 수 없는 형태인데, 그려와서 이거 해주세요 하면 문제 해결이 되지 않으니까요.

최: 기획자 역할이 되게 어려운 게, 제대로 된 기획자라고 한다면 진짜 다방면을 다 알아야 하잖아요. 그런데 다 알아야 한다는 건, 대체 뭘 알아야 하는 건가요?

도그냥: 제일 먼저 알아야 하는 게 비즈니스 구조. 이 회사가 도대체 뭐 하는 회사인지, 뭐로 돈을 버는지, 우리 고객은 어떤 사람인지, 비즈니스에 관해서 명확하게 알아야죠. 그다음에 우리 고객이 어떤 식으로 서비스나 프로덕트를 쓰는지, UX에 대해서 알아야 하고요. 그다음에 최소 디자인 트렌드 볼 줄은 알아야죠. 그릴 줄은 몰라도 갑자기 1990년대 PC에서 쓰던 그러데이션에 그림자가 잔뜩 들어가 있는 시안을 갖다 줬는데 ‘이건 아닙니다’ 할 수 있을 정도는 되어야 하니까요. 그 정도 역량은 있어야죠. 그리고 개발자가 이슈를 얘기했을 때 논의할 수준은 되어야 한다고 생각해요.

최: 이거는 언제까지 얼마 걸리고, 문제가 있는데 서버가 죽네 마네 부하 걸리네.

도그냥: 예를 들어, 우리가 API 호출을 했는데 오류가 생겼어요. ‘이거 왜 오류 났어요?’ 했을 때 ‘API 호출을 했는데 응답이 없었어’라고 하면 ‘아 응답이 없으면 없는 대로 두지 마시고, 3초 동안 한 다음에 타임아웃이 나면 이 오류 메시지 띄워주세요’, 이런 정도로 판단하고 대안을 함께 제시해 줄 수 있어야 한다는 거죠. 그걸 이해하지 못하면 개발자한테 ‘이러면 고객이 문제가 있어요’밖에 할 수 있는 게 없잖아요.

할 게 없어진 기획자…

서비스 완성도를 높이려면 같이 논의할 정도는 되어야 하는데, 그렇다고 내가 막 저희 서버에 있는 거를, 인프라를 얼마를 늘려서 뭐, 이런 얘기를 하자는 게 아니고. 그냥 우리 개발자가 이슈가 있다고 할 때 그거를 같이 얘기해주고 함께 문제를 풀어 줄 수 있는, 로직에 대해서는 논의할 수 있는 정도. 그리고 마지막으로 중요한 건 정산. 이건 이커머스일 때 필요한 건데요. 결제가 일어났으면 그 결제된 금액이 어떻게 흘러가서 마지막까지 가는가 하는 부분도 알아야 한다고 생각해요. 그게 비즈니스니까요.

최: 수수료라든가, 쿠폰 방식이라든가, 할인 혜택이라든가.

도그냥: 네, 그걸 알아야죠.

최: 이커머스라면 물류, 배송 다 알아야 하고. 정책, 이건 비즈니스 구조랑 맞물리긴 하겠네요.

도그냥: 쉽게 생각하면 오프라인에서 정의해 놓은 비즈니스를 디지털화하는 거죠. 어디서부터 어디까지는 데이터화, 어디서부터 어디까지는 시스템화, 어디부터 어디까지는 그냥 실무자의 운영, 그 경계를 짜는 일인 것 같아요.

최: 말씀하신 서비스 기획의 플로우가 스타트업 하시는 분들의 일상인 것 같아요.

도그냥: 하지만 초창기 스타트업 구축할 때 모든 프로세스를 다 직접 구축하는 것은 낭비죠. 그래서 오픈소스나 플랫폼이 차지하는 비중이 너무 커서, 이 디테일까지 들어가기 위해서는 충분히 또 성장한 후에나 필요한 내용들일 수 있어요.

최: 우커머스나 카페24를 쓰고 뭐 이런?

도그냥: 스타트업에서 일하며 이커머스 하시는 분들이랑 얘기를 해보면, 결제가 진짜 큰 프로세스인데 PG사 결제 인증 모듈을 붙이는 걸로 끝내고, 정산은 PG사에서 주는 대로 받는 경우가 많아요. 그러면 정산 쪽에 고려해야 할 사항은 아직 고민할 필요가 없어요. 그 사이에서 금액이 어떻게 처리가 되어 입금돼서 오는지는 관심 대상이 아닌 거죠. 그러다 보니 초창기일수록 핵심 프로세스가 아니라면 서비스가 거의 앞단으로 쏠려요. 멋진 UI, 편리한 UX, 근데 그게 안 중요하다는 건 아닌데, 그것만 너무나 강조되는 건 아쉽죠. 결제 자체에도 엄청 큰 세상이 있는데요.

최: 프런트 엔드가 얼굴이니까, 더 신경을 쓰지만 백은.

도그냥: 백에 대한 고민은 차후에 서비스가 훨씬 커지고 차별화해야 할 때 그때 시작하게 돼요. 그러면 백에서 나중에 돈이 술술 새요. 내가 필요한 대로 설계가 안 돼 있는 거기 때문에, 거기서 손실액이 나는 거죠. 그때 이미 큰 회사들처럼 또다시 새로 구축하는 과정에서 같은 실수, 같은 고민을 반복하는 거죠. 경험이 공유된다면 일어나지 않아도 될 문제예요. 모든 기업이 비슷한 상황이 되는 거니까요.

최: 근데 사실 PG사가 제공하는 결제 인증 모듈을 끼지 않는 상태가 된다는 거는 굉장히 성장한 거 아니에요?

도그냥: 그렇죠. 근데 나중에 언젠가는 하고 싶어 져요. 청구할인을 붙이고 싶을 수도 있고, 중개 거래를 하고 싶어질 수도 있고요. 규모가 성장하면 더 다양한 결제형. 예전에 한 번 모 회사에서 저한테 문의가 온 적 있어요. 청구할인 붙이고 싶다고, 근데 PG사를 낀 상태에서 청구할인 붙이기가 까다롭거든요. 쉽지가 않거든요. 특정 카드와 제휴를 하고 싶어도 안 돼요. 특정 카드 할인 같은 거를 넣고 싶어도, PG사를 써서는 직접 할 수 없는 구조예요. 그런 것들에 대해 설계를 하려면 주문 모듈을, 결제를 가지고 들어와야 하죠.

최: 백 엔드 개발 관련 지식이나 프로세스, 노하우가 많이 잘 안 알려져 있나요?

도그냥: 안 알려진 것 같아요. 이번에 구축하려고 기획자를 뽑았을 때도, 이 레벨까지 관여해본 기획자가 거의 없어요.

최: 이게 쉽다면 쉽고 어렵다면 어려운 문제인데, 몰라서 못 하는 영역인 것 같기도 하거든요.

도그냥: 몰라서 못 해요. 그리고 이 존재 자체를 모르고, 이게 중요한지 아닌지 모르고, 그리고 대부분의 회사는 안 만들고. 그러니까 항상 만들 때마다 다시 처음부터 시작하는 문제처럼 해보면서 고민하고 수정해야 하는 거죠.

최: 지식이 쌓이지 않는.

도그냥: 국가적으로 봤을 때도 비효율이죠. 다 같이 성장했으면 좋겠어요.

최: 브런치도 그래서 쓰시는 거예요?

도그냥: 그렇죠. 전 주니어들이 UI 말고 다른 생각을 할 수 있게 성장했으면 좋겠어요. 물론 제가 촌스러운 인간인진 모르겠지만, 실무에서는 이론처럼 일하기가 쉽지 않거든요. 아이디어는 아이디어고 시스템은 시스템인데, 시스템을 만드는 방법도 가르쳐 줘야 하는데, 보이는 부분에 대한 기획 방법만 계속 공부하고 기획자로 일하게 되면, 개발자는 계속 기획자가 필요 없단 얘기만 할 거예요.

최: 일단 멋있어 보이긴 합니다.

도그냥: 시중에 여러 가지 방법론이 이론적으로 맞는 말이긴 해요. 정말 이상적이고 옳은 얘기들, 방법론 코치들 만나 얘기 들어보면 다 맞는데, 현실적으로 실무에서 쓸 수 있는 게 많지 않아요. 특히 외부의 개발자가 개발을 같이하면서 자신의 모든 창의력과 열성을 다해 기획자만큼 고민해서 더 좋은 산출물을 만들기는 쉽지 않아요.

최: 창업자밖에 없죠 그런 사람은.

도그냥: 찾기 어려워요. 내부의 개발이라고 해도 기획까지 모두 커버해서 고민해 줄 그런 사람은요. 실무에서만 나올 수 있는 답답함이 있죠.

최: 그런 것도 있지 않나요? 개발자한테 요구 사항을 주고, 개발자가 개발을 했어요. 근데 뭐가 막혀서 안 돼. 아까 말씀하신 것처럼 ‘그거 이렇게 하면 될 것 같은데요?’ 기획자는 그 정도 생각을 하는데 개발자는 은근히 그런 생각을 못 하는 것 같아요. 대안 제시.

도그냥: 그건 개발하시는 분들이 주어진 문제에 몰입하다 보니 그럴 수도 있는데, 이용자나 비즈니스에 대해 깊이 생각할 틈이 없어서가 대부분이에요. 뭐가 되는지 뭐가 안 되는지 판단이 어려우니 다른 대안도 제시하기 어려운 거죠. 그래서 기획자가 비즈니스를 잘 알고 사용자를 깊이 이해하면 ‘그런 케이스는 별로 안 일어나요. 그냥 이 케이스는 막으세요’라든가 ‘이 케이스는 많이 발생하니 이거는 우선적으로 잡아 주세요’라든가, 이런 우선순위 판단을 해 드릴 수 있는 거죠. 모든 100가지 케이스를 다 완벽하게 할 순 없잖아요. 그게 제가 생각하는 PM은 그래서 개발이랑 대화할 수 있어야 하는데, 꼭 코딩이나 파이선을 공부한 사람은 아니라고 생각해요.

최: 어쩌다가 서비스 기획자가 되신 거죠?

도그냥: 저도 유엑스란 단어에 혹해서 들어온 사람 중 하나인데요. 취준 시절 기획자는 되고 싶었는데 이 세상에 기획이 너무 많더라고요. 그래서 업종을 찾다가, ‘내가 뭘 잘하지’ 했는데 어릴 때 홈페이지도 만들고, 블로그도 쓰고 그러니까 나는 온라인 쪽이 잘 맞는 것 같다, 그래서 온라인 기획이라고 붙어있는 회사를 다 지원해 봤어요.

그러다 네이버에 인턴 면접을 봤거든요. 근데 같은 날 UX 면접도 있었어요. UX가 뭔지 몰라서 또 친화력을 발휘해서 거기 면접 온 사람한테 물어봤거든요. 그 사람이 또 친화력을 발휘해서 되게 자세히 설명해 줬어요. 그래서, 전혀 모르는 사람과 네이버 사옥 앞에서 거의 한 시간 동안, UX 설명을 듣고 나니, 너무 멋있어서 딱 그걸 찾아봤는데,

뭔가 공부를 한 다음에 하면 나는 인문학도니까, 잘 매칭 시킬 수 있겠다는 생각을 했어요. UX 스터디그룹 가서 방법론 교육도 듣고, 멋있다 생각하다 지금 회사의 마케팅 부문 안에 UX 조직이 있는 걸 보고 지원한 거죠. 그리고 면접장에서 계속 UX 가고 싶다고 어필했어요.

최: 들은 것과 공부한 것들을 다 펼쳤군요.

도그냥: 일해보니 테스트도 하고, 버그도 찾고, 솔직히 그땐 어떤 생각이 들었냐면 회사가 촌스러워서 멋진 방법론을 쓰지 않지만, 내가 열심히 성장해서 배운 걸 적용하면 되겠구나, 그게 현실적이겠다, 그런 생각을 했죠. 스터디에서는 현실적으로 우리나라에서 잘 안 된다는 얘기를 엄청 많이 들어서 아, 여기도 그렇구나, 내가 실무적으로 적용시킬 수 있는 방법을 나중에 찾아서 일할 수 있는 사람이 돼야지, 이런 생각을 했죠.

최: 원대한 신입의 꿈

도그냥: 입사하고 1년 다 될 시점에 큰 프로젝트가 있었거든요. 막판에 투입됐어요. 인원이 부족하니 제 위의 선임, 책임 이런 분들하고 사원도 딸려 간 거예요. 인원으로. 원래는 제가 가서 할 수 있는 급은 아닌데, 일단 능력 되는 분들이랑 엮어가지고 보낸 거죠. 능력자분들과 간 거예요. 그 상태에서 기존 프로젝트의 문제점 하나하나 다시 파악하고, 바로잡고 하면서 일반적으로 운영되는 프로젝트와 서비스에서는 절대 못 보는 것들, 그런 거를 볼 수 있었어요.

최: 대부분 그 상황이면 맨날 밤새우고 그러던데. 그때 몇 시 퇴근하셨어요?

도그냥: 퇴근이 뭐예요… 퇴근 개념 없이, 열심히 살았죠. 근데 그때는 그게 너무 재미있었어요.

최: 체력도 되고.

도그냥: 물론 지금도 다른 의미에서 재밌긴 한데, 그때는 아예 모르던 세상을 배우니까, 그것도 그냥 야생에 픽 던져진 거예요. 할 수 있고 알 수 있는 게 없으니까, 개발자 뒤에 앉아 물어보고, 테스트하고, 데이터 보여달라 그러고.

모르면 물어보면서!

최: 도제교육을 받으셨군요 거의.

도그냥: 그렇죠. 그러고 나서 문서화하고. 그렇게 프로세스를 보고 배우니까, 프로세스 막 혼자서 그리고, 결제 프로세스 같은 것도 절대 교육받은 일은 없죠, 운영 중일 때는. 근데 신규로 붙이는 프로젝트니 또 물어보면 다 설명해 주시고, 그걸 제가 다시 그림으로 따로 그려놓고. 혼자 표 그려놓고. 이런 식으로 하니, 전체를 조금씩 보게 되더라고요. 근데 그 과정에서 선배들이 너무 고생한 거예요. 프로젝트 끝나고 선배들이 다른 팀과 회사로 나가는데, 저한테 하나씩 넘겨주기 시작했어요. 하필 그 시점에 우리 회사도 그때 갑자기 정책을 바꿔서 경력직 채용을 자제하는 상황이었죠.

최: 진골 위주로 가겠다.

도그냥: 저 뒤로는 계속 신입만 들어오는 거예요. 그러면 제가 조금 더 아니까 나가는 선배 거를 받아 공부하고, 내가 배운 거는 넘겨주고, 그걸 한 세 번 하면서 범위가 확장됐죠.

최: 본의 아니게 수업이 됐군요.

도그냥: 지금 팀장님이 야생에서 키웠죠. 사자 키우듯이.

일잘러를 위한 교육 플랫폼, 그로스쿨입니다.