비개발자가 AI로 사내 시스템을 만드는 법 _PFCT 총무팀 AX 인터뷰

Q. 안녕하세요 식님, 간단한 소개와 하고계신 역할에 대해 소개 부탁드려요!

PFCT에서 GA(총무)팀 롤 리더를 맡고 있는 이식이라고 합니다. 자산관리, 사무환경, 복리후생 등을 담당하고 있고, 최근에는 사내 총무 업무 자체를 시스템으로 바꾸는 AX(AI 업무 자동화) 환경까지 직접 구축하고 있습니다.

Q. 현재 근무하고 계신 PFCT, 어떤 회사인지 궁금해요.

PFCT는 2015년에 설립된 11년 차 AI 렌딩테크 기업입니다.

사업은 크게 두 가지로 나눌 수 있습니다.

첫째, 온투금융입니다. 온라인투자연계금융업(온투업) 라이선스로 크플(CPLE)이라는 플랫폼을 운영합니다. 중저신용자 대상 개인신용대출과 주택담보대출을 자체 심사해서 실행하고, 그 채권에 개인·법인·금융기관이 투자하는 구조입니다.

둘째, AI 리스크 솔루션 사업입니다. 대출을 직접 운영하면서 쌓은 심사·리스크 관리 기술을 AIRPACK이라는 솔루션으로 만들어 저축은행·카드사에 공급합니다. 인도네시아, 베트남 등 해외로도 진출하고 있고요. 금융을 직접 운영하면서, 그 기술을 파는 회사라고 보시면 됩니다.

그리고 이렇게 AI를 사업의 핵심으로 다루는 회사이다 보니, 회사 안에서도 AI 활용에 굉장히 열려 있어요. 저희는 AI가 개발자만을 위한 도구라고 생각하지 않거든요. 개발자는 물론 비개발자도 각자의 업무에 맞는 AI 툴을 적극적으로 활용해 반복 업무를 줄이고, 더 빠르게 아이디어를 구체화할 수 있도록 회사 차원에서 장려하고 있어요.

Q. 총무라는 직무를 시작하게 된 계기가 궁금해요.

저는 대학교를 컴퓨터공학과로 입학했다가 정보통계학과로 편입했어요.

첫 직장은 친구 소개로 들어가게 됐어요. 어릴 때부터 포토샵이나 홈페이지 제작에 관심이 있었는데, 그 경험이 이력으로 이어져 IT 자산관리와 경영지원 업무를 함께 맡게 됐습니다.

그렇게 1년 4개월쯤 다니다가 문득 다시 개발을 배워보고 싶었어요. 회사에서 IT 자산관리를 그냥 엑셀로 하고 있었는데, 이걸 시스템으로 직접 개발해보고 싶다는 생각이 들었거든요.

그렇게 국비교육과정으로 6개월 정도 IT 교육센터에서 자바와 스프링 프레임워크를 배우게 되었고, 프로젝트 과제를 수행한 경험을 살려서 '신보'라는 전기건설업 회사 전산팀으로 들어가게 되었어요. 당시 제가 속한 팀은 중간 연차 없이 바로 위에 팀장님이 계신 구조였어요. 커리어 격차가 크다 보니 체계적으로 배우기보다는, 3개월 동안 따라가기에도 벅찬 시간을 보냈습니다. 그러다 수습기간이 끝나갈 때쯤 회사에서 이전 커리어와 전산업무 경력을 살려 IT/총무를 본격적으로 해보길 권하더라고요. 규모가 있는 회사여서 그렇게 본격적으로 4년 정도 총무 업무와 체계를 그곳에서 대부분 배웠던 것 같아요.

이후에는 젠틀몬스터, 패스트파이브, 코리아포트원을 거쳐 현재 PFCT에 정착했습니다.

Q. 총무 업무에 컴퓨터공학 배경이 있다는 게 특이한 조합일 수도 있다는 생각이 들어요. 업무에 전공을 활용한 경험도 있으신가요?

총무는 다양한 업무를 다루는 직무라서, 문과적 역량과 이과적 역량이 각각 장점으로 작용할 수 있다고 생각해요. 그렇다 보니 컴퓨터공학 전공과 개발언어를 공부한 경험이 도움이 되었던 경우가 있었어요.

특히 이전 회사에서 6개월 정도 회계법인, 재무팀, 총무팀과 함께 자산관리 시스템 구축 TF에 참여했을 때 가장 큰 도움이 되었고, 소규모 네트워크 구축이나 보안 관련 업무 같은 경험들도 AI 시대가 도래한 지금 AI 업무 자동화 환경을 구축하는 데 아무래도 도움이 많이 되는 것 같아요.

하지만 저 역시 전공만 했을 뿐이지 개발 업무로 본격적인 커리어를 쌓은 건 아니기 때문에, 혹시 전공이나 경험이 없으신 분들이 관련 지식이 없다고 AX를 두려워하지 않으셨으면 좋겠어요. 무엇보다 중요한 건, 자신이 맡은 업무 환경과 프로세스를 정확히 이해하는 것이라고 생각하거든요.

Q. AX를 하면서 뭘 자동화할지, 그 기준을 어떻게 세우셨어요?

세 가지를 봤어요.

그중에서 저는 명확성을 제일 중요하게 봤어요. 실제로 업무를 하다 보면 리소스를 더 많이 쓰는 쪽은 요청자보다 업무를 처리하는 담당자일 때가 많거든요. 실제로 가장 답답한 지점은 요청 내용이 명확하지 않을 때예요. 슬랙 채널에 공지된 양식대로 오지 않는 경우가 많고, 그렇게 되면 저희 입장에선 다시 되묻고 답변하는 과정이 계속 반복되어 생각보다 굉장히 많은 리소스가 들거든요.

그리고 아무리 완벽한 시스템이라도 최소한의 필수 가이드라인이 없으면 휴먼 에러는 무조건 있다고 생각해요. 그래서 가장 큰 목표는 에러를 최소화하는 거였어요. 설문조사에 필수 항목을 체크해두면 다음 단계로 못 넘어가잖아요. 그런 것처럼, 애초에 누락이 없고 서로 티키타카하지 않도록 만드는 게 핵심이었어요.

Q. 실제로 만드신 것 중에 '피플의 서재'라는 사내 도서관 시스템이 있다고 들었어요. 원래는 어떤 방식이었어요?

노션 페이지로 구매 신청을 받고, 구매 후 도착하면 GA팀에서 구매 신청자에게 안내하는 방식이었어요.

그리고 구매 신청자는 구글폼으로 대여·반납 응답을 제출해야 했고요. 노션에 구매 도서 데이터베이스가 있긴 했지만, 사실상 신청 페이지를 모아두는 수준에 가까웠어요. 그러다 보니 데이터의 정확성이 떨어지는 게 가장 큰 문제였어요.

그리고 마이페이지 개념이 없었어요. 그러니까 "내가 지금 뭘 빌리고 있는지"를 확인할 방법 자체가 없었던 거예요. 대여 현황도 실시간으로 볼 수가 없으니까, "이 책 어디 있나요? 누가 빌려갔나요?" 하는 질문이 되게 많았어요.

더 큰 문제는 도서 정보를 사람이 직접 입력했다는 점이었어요. 도서별로 구분할 수 있는 고유 값이 없으니까, 이 책이 이미 회사에 있는 책인지 아닌지 도서명을 검색해야 알 수 있었죠. 그래서 같은 책을 모르고 중복 구매하는 일이 실제로 있었어요. 비용 낭비죠.

반납도 페이지에는 14일 의무로 정해놨었는데, 사실상 강제할 방법이 없었어요. 본인이 구글폼에 "반납했습니다"라고 제출하면 그걸로 끝이었거든요. 실물을 확인하는 절차가 없었던 거예요. 신청 없이 그냥 가져가신 분들도 있어서 유령 재고가 꽤 많았고요. 결국 어떻게 보면 임직원을 그냥 믿고 운영하던 상황이었어요. "빌려 갔겠지, 반납했겠지" 하는, 반쪽짜리 믿음으로요.

Q. 새 시스템에서는 이 문제들을 어떻게 풀었어요?

일단 가장 먼저 실제 책장에 보유하고 있는 도서(1,100여 권)를 ISBN 기반으로 DB화했어요.

구글시트(DB용)를 하나 만들고, 알라딘 API 키를 스크립트화해서 바코드 리더기로 책 뒷면 바코드의 ISBN 값을 찍기만 하면 제목, 지은이, 발행일이 자동으로 불러와지게 했죠. 그렇게 실제 보유 도서를 기준으로 새로운 DB를 구축했어요.

그다음 새로 신청될 도서의 정보가 틀리지 않도록 했어요.

신청 페이지에 교보문고, 알라딘, Yes24의 도서 링크 URL만 붙여넣으면 제목, 저자, 발행일 정보가 자동으로 불러와지도록 했어요. 이 부분은 대부분의 도서를 구매하던 교보문고에서 해당 API를 제공하지 않아, 각 사이트별 URL 링크에서 ISBN 값을 스크래핑해 알라딘 API로 도서 정보를 받아오는 방식으로 우회했어요. ISBN 값을 기준으로 신청을 걸러내다 보니, 이미 다른 사람이 신청 중인 책이나 이미 구매해 재고가 있는 도서의 중복 신청도 자동으로 막았어요.

예전엔 이 값 자체가 없었으니까 거르는 게 불가능했고, 이 부분이 제일 오래 걸렸던 것 같아요.

다음은 사용자 DB를 만들었어요. 구글워크스페이스 API를 통해 계정 정보를 동기화했어요. 공용 계정 같은 건 따로 제외해야 해서 동기화 후 제외 목록을 관리하는 것도 신경 썼고, 매일 오전 12시에 자동으로 동기화되도록 구성했어요. 그리고 구글 SSO 로그인 기능을 넣어 나의 대여 현황, 구매 신청·이력 등을 바로 볼 수 있게 만들었죠. 이미 대여 중인 책이면 예약 가능하도록 기능을 추가했고, 예약해두면 도서가 반납되는 즉시 입고 알림을 받을 수 있도록 구성했어요. 기존 노션에는 없던 기능들이었어요.

이렇게 새로운 피플의 서재가 탄생했습니다.

알림의 경우 이용자 입장에서 모든 과정을 슬랙 알림봇을 통해 받도록 했어요.

그래서 전 과정(구매신청, 입고, 대여 등)에 알림을 받을 수 있고, 대여 후엔 반납일 도래 하루 전에 알림이 가고, 당일 안 하면 한 번 더 가도록 해서 놓치지 않게 했어요. 물론 1회 연장 기능도 탑재되어 있고요.

마지막으로 시스템만 만든 게 아니라 운영 방식도 바꿨어요. 반납의 경우 기존에는 대여자가 반납 양식을 내고 직접 책장에 반납하도록 했는데, 그러면 진짜 반납했는지 확인이 안 되거든요. 지금은 총무팀이 반납 존을 따로 만들고, 도서관 사서처럼 실물을 직접 확인한 다음에만 반납 처리해요.

"AX는 시스템만 넣는다고 되는 게 아니고, 물리적인 제도가 같이 받쳐줘야 하더라고요."

Q. 회의실 예약 시스템도 만드셨다고요. 구글 캘린더만 쓸 때는 어떤 점이 제일 골치였어요?

제일 문제는 회의실이 자주 부족하다는 이야기였어요. 그런데 실제로 가보면 노쇼로 비어있는 경우가 하루에 한두 건씩은 꼭 있었죠. 예약은 돼 있는데 아무도 없는 거예요. 그럼 가끔 저희 팀이 직접 돌아다니면서 확인해서 취소 요청을 드리곤 했어요. 그것도 하루 종일 돌아다닐 수는 없으니까 회의실 캘린더를 저희 팀이 전부 구독해놓고, 틈날 때마다 비어있는지 보고, 비어있으면 예약자한테 연락해서 취소해달라고 요청하는 식으로 수동 관리했어요.

그래서 사실 예전에 비슷한 상용 솔루션 도입도 검토했었어요. 그런데 회의실마다 태블릿을 따로 놓아야 해서 비용이 꽤 나가더라고요. 그때는 그 비용을 감당할 상황이 아니어서 도입을 접었어요.

Q. 새로운 시스템은 어떻게 구성돼 있어요?

저희 사옥 5층 메인라운지에 대부분의 회의실이 모여있어요.

그래서 5층에 전체 회의실 현황을 볼 수 있는 대시보드 TV를 놓게 되었죠. 대시보드 TV를 하나만 놓아도 전체 현황이 한눈에 다 보이더라고요.

이 대시보드 TV로 실시간 전 층 회의실 현황을 볼 수 있고, 비어있는 시간은 즉석에서 8초, 10초면 예약이 끝나요.

누가 지금 이 회의실을 잡아놨는지도 바로 보이고요. 예전 회사에서 썼던 동아PM을 벤치마킹했는데, 대시보드에서 바로 예약할 수 있게 만든 건 제 아이디어였어요.

상용 솔루션을 도입하면 태블릿을 따로 사야 하는 비용 문제가 있었는데, 이건 기존에 있던 터치패널 탑재 대시보드 TV로 해결했어요. 별도 개발이 필요한 게 아니라, 재고 노트북을 연결해 윈도우 터치 키보드를 상시 모드로 켜두면 작동해요. 처음엔 작동이 안 돼서 왜 그런가 했는데, 알고 보니 윈도우 태블릿 모드나 터치키보드 상시 켜짐 설정이 따로 있더라고요.

무엇보다 현장에서 즉석 예약 시 주최자(예약자)의 캘린더와 연동하는 부분이 중요했어요. 그래서 실제 인원 정보는 GA팀과 People팀이 협업하는 인사 DB에서 가져와요. 재직 중인 분들의 사번·이름·소속 정보만 가져오도록 했고, 주 1회 자동으로 배치 파일이 돌아가게 해놨어요.

비공개 일정은 제목이 안 보이게 해놨어요. 그리고 하나 재밌는 결정이 있었는데, 예약을 삭제하는 기능은 일부러 안 넣었어요. 이 대시보드는 로그인 없이 쓰는 공용 화면이거든요. 그러다 보니 삭제까지 되게 하면 남의 예약을 아무나 지울 수 있게 되잖아요. 그래서 그건 막아뒀죠.

노쇼는 완전히 잡히진 않았지만 그래도 예전보다는 많이 나아졌어요. 그 대시보드 TV 하나 덕분에, 지나가다가 화면을 보고 "여기 예약해놓고 안 쓰고 있네" 싶으면 예약자에게 직접 연락해서 사용 여부를 물어보고 그 자리에서 바로 쓸 수 있게 됐고, 비어있는 회의실은 즉석에서 바로 등록해서 사용할 수 있게 되었죠. 사람이 눈으로 보고 판단해서 쓰는 방식으로 개선이 된 거죠.

다만 이게 어디까지나 사람이 지나가다 봐야 되는 거라, 완전히 자동으로 감지되는 건 아니에요. 노쇼가 나면 시스템이 알아서 잡아주는 감지 기능은 아직 없거든요. 그래서 이 부분은 하반기 내로 최소한의 비용으로 노쇼 감지 기능을 넣어 태블릿을 추가해서 운영해보려고 해요. 그렇게 되면 겨울쯤엔 완벽한 회의실 관리 시스템이 되지 않을까 기대하고 있어요.

Q. 방문 주차 시스템 이야기가 제일 흥미로웠어요. 이것도 원래는 완전히 수동이었나요?

기존에는 별도의 방문 주차 등록 시스템이 없었어요. 방문 차량 등록이 필요하면 슬랙 채널이나 DM으로 총무팀에 요청하는 방식이었어요. 요청이 들어오면 차량번호, 입차 시간, 주차 시간을 정리해 주차관리실 담당자 두 분께 문자로 전달해야 했어요. 두 분이 격일로 근무하셔서 날짜마다 담당자가 달라지는 점도 신경 써야 했고요. 안 그러면 1층에서 입차를 안 시켜주거든요. 그리고 주차장이 협소해서 위치 안내를 따로 해야 하는 경우도 있었고요.

그래서 요청 방식을 채널에 공지하긴 했지만, 양식에 맞게 신청해주시지 않으면 수 차례 메시지가 오가야 했어요.

누락된 정보를 확인하려고 신청자에게 다시 물어봐도 정작 답을 듣지 못하는 경우가 비일비재했고요. 무엇보다 신청한 시간대에 이미 다른 예약이 있어 자리가 없는 경우, 총무팀이 매번 대조해서 판단한 뒤 재안내해야 했어요.

또한 직원분들과는 슬랙으로 정보를 주고받지만, 주차관리실과는 문자로 소통해야 했기 때문에 물리적인 시간과 번거로움이 많이 발생하는 업무였습니다. 총무팀인 저희도 사람이다 보니 놓치는 경우도 발생했고요.

Q. 그 수동 프로세스, 지금은 어떻게 자동화하신 거예요?

지금은 '방문주차 신청' 웹페이지에서 필수 정보만 기재한 뒤 신청 버튼만 누르면 됩니다.

실시간 시간표를 참고해 예약 가능한 슬롯(시간)도 사전에 확인할 수 있죠. 신청자가 신청을 완료하면 총무팀은 '등록완료' 버튼 하나만 누르면 돼요.

버튼을 누르고 주차 위치나 특이사항 메시지를 작성하면 신청자에게 완료 메시지가 나가죠. 동시에 총무팀에는 문자 발송 링크가 생성됩니다. 스마트폰에서 해당 링크를 누르면 사전에 등록해둔 주차관리실 연락처(두 분)와 메시지 내용이 자동으로 연동되어 바로 보내기만 누르면 문자를 보낼 수 있어요. 기존처럼 직접 메시지 내용을 복사·수정·붙여넣기로 보낼 필요가 없어졌죠.

물론 특별한 사유로 신청을 반려할 경우에도 알림이 갑니다.

이 과정에서 시행착오도 있었어요. 테스트할 때 AI가 테스트 삼아 실제 직원 두 분께 무작위로 알림을 보내버린 적이 있어요(웃음). 그분들께 다급하게 사과드렸죠.

이런 구조로 만들다 보니, 외부접속·슬랙알림·신청인 DB 연결 작업이 제일 난이도가 있었어요. 사내뿐 아니라 외부에서도 신청할 수 있게 해야 했기 때문에 가장 오래 걸렸던 것 같아요. 길게 설명드릴 순 없지만, 위 세 가지를 모두 가능하게 하는 작업이 제일 손이 많이 갔어요. 현재는 서버가 재부팅될 경우 관리자가 1차적으로 슬랙에서 관련 URL 링크를 변경해줘야 하는데요, 이 부분도 알림봇을 통해 관리자가 서버에서 변경된 URL 링크를 자동으로 받아 설정란에 복사·붙여넣기만 하면 되도록 최대한 간편하게 해두었습니다.

Q. 프로그램들을 개발하실 때, 전문적인 개발 경험이 없으셔서 어려움도 많으셨을 것 같아요.

우선은 바이브코딩과 AI를 통해 작은 기능들부터 개발했어요. 봇, API 연동 같은 기능부터 시작했죠. 그랬더니 조금씩 자신감이 들기 시작하면서, 저희가 겪는 불편함과 어떻게 개선해야 할까 하는 생각이 들기 시작했어요.

막상 개발을 시작해보니 문제들이 굉장히 병렬적으로 발생했어요. UI가 어느 정도 잡히면 백엔드에서 문제가 생기고, 그걸 해결하면 또 다른 버그가 나타나는 식이었습니다. 그래서 AI 툴 안에 팀을 꾸렸어요.

그 팀을 꾸릴 때 기준이 있었어요. 저는 기획자도, 프론트엔드도, 백엔드도, 디자인도, QA도, 보안 담당도 아니잖아요.

그래서 AI에게 각자의 역할을 맡겼어요.

시작할 때 "나는 몇 년 차 총무고, 개발 지식은 이 정도 있고, 서버를 직접 올릴 수 있는 상황은 아니야" 등 여러 조건을 다 말해줘요. 그리고 기획, 프론트, 백엔드, 디자인, 이렇게 에이전트 팀을 구성해달라고 하고요.

한 번에 여러 기능을 추가할 때마다 이 에이전트 팀들끼리 토론해서 각자 개선할 점을 나열하게 하고, 거기에 우선순위를 부여받아서 그대로 처리했어요. 재밌었던 건 디자이너와 프론트엔드가 좀 부딪혔어요. 반응형으로 만들어달라고 했는데, 웹에서는 잘 되는데 모바일에서는 폰트가 잘리는 경우가 있었거든요. 그런데 AI끼리 싸우진 않더라고요. 대신 데브옵스와 보안 검토는 제일 마지막 순서로 뒀어요. 관리자 비밀번호나 API 키가 코드 주석에 그대로 노출되는 경우가 있을 수 있어서, 최종 빌드하고 배포하기 직전에 따로 요청해서 검토받았어요.

Q. 막히는 부분이 생기면 어떻게 풀어나가세요?

예전엔 구글링이나 업무 자동화를 했던 분들에게 직접 물어보는 게 살길이었는데, 지금은 그냥 AI에게 물어봐요. 중간중간 아이디어는 있는데 실제로 구현 가능한지 모를 때가 많거든요. 사실 주차 문자 자동 발송 기능도 처음엔 이게 될지 몰랐어요. "이거 매번 문자 내용을 수정하고 복사해서 보내는 게 귀찮은데, 스마트폰에서 슬랙 메시지 링크 하나 눌렀을 때 메시지 앱이 바로 켜지면서 보내지게 할 수 있어?"라고 물어봤다가 나온 결과물이에요. 요즘 AI가 그런 걸 되게 잘 찾아주더라고요.

Q. 배포하고 나서 반응은 어땠어요?

되게 좋았어요.

우선 총무팀에서 비개발자가 시스템을 만들었다는 점에서 신기해했고, 대표님도 반응이 좋으셨고요. 그리고 무엇보다 간편하고 정확한 알림을 받을 수 있어서 좋다는 의견이 많았어요.

지금은 리뷰와 함께 이용자들의 기능 추가 요청도 들어오고 있어요.

Q. 개인적으로 이 작업이 어떤 의미였어요?

저는 경력이 좀 있고 나이도 있는 편이잖아요. 총무 업무는 100% 정량화하기 어려운 영역이 많아요. 어느 정도 경험이 쌓이면 직무를 전환하지 않는 이상 성장의 방향을 새롭게 찾기 어려운 순간이 오기도 하거든요.

그런데 지금은 비개발자여도 개발을 할 수 있는 상황이 됐고, 저희만큼 백오피스의 불편함을 눈으로 보고 몸으로 느끼는 사람들도 없잖아요.

예전엔 뭔가를 시스템화하고 싶거나 필요할 경우 사내 개발팀에 요청해야 했어요. 그런데 그분들은 회사가 파는 상품을 개발하는 분들이지, 백오피스를 위해 개발하는 분들이 아니거든요. 그래서 이번 기회에 나이 먹은 만큼 쌓인 연륜과 경력으로 그 허점을 직접 커버할 수 있었던 것 같아요.

그리고 저는 총무 담당자로서 사내에서 AI를 통해 개인의 생산성만 늘리는 건 크게 의미가 없다고 생각해요. 회사 전체에 영향을 줄 수 있어야 진짜 의미가 있는 것 같아요. 요즘 AI에 열려 있는 회사들은 직원들에게 AI 활용을 장려하고 지원도 해주잖아요. 그런데 회사 입장에서도 지원한 만큼 뭔가 얻는 게 있어야 하는데, 개인의 업무 생산성 향상만을 위해 쓰기엔 좀 아깝다는 생각이 들어요. 물론 직무마다 다를 수 있겠지만, 적어도 백오피스에서는 협업하거나 전사 직원의 업무 편의성을 높일 수 있는 걸 만드는 게 더 낫겠다 싶었어요.

Q. 같은 직무를 하는 후배들에게 조언을 하신다면요?

처음부터 거창하게 시작하지 않아도 된다고 말해주고 싶어요.

슬랙의 워크플로나 리스트 기능을 시작으로 슬랙봇 알림 하나, 구글 스프레드시트 동기화나 연동 작업 등 주어진 AI 툴을 통해 가벼운 것부터 하나씩 시작하면 돼요. 예전엔 슬랙봇 알림 하나 만드는 것도 너무 어려워서 개발자분들께 묻곤 했고, 엑셀 매크로나 GAS(Google App Script) 사용도 많이 어려웠지만, 지금은 AI가 방법까지 다 알려주거든요.

결국 총무 업무를 구조적으로 보면 크게 "신청 – 승인 – 처리 – 안내"라는 네 단계로 나뉘기 때문에, 이 큰 틀만 처음에 잘 잡아두면 중간에 기능을 하나씩 붙이는 건 어렵지 않다고 생각해요.

Q. 앞으로의 계획은요?

올해 오픈한 시스템들을 더 고도화하고, 실제 사용자들의 피드백을 반영해 계속 개선해가고 싶어요.

그리고 GA(총무)팀은 People(인사)팀과 협업이 잦아 이 부분으로 영역을 좀 더 넓혀가고 싶어요.

그렇게 하나둘 만들어가면서 최종적으로는 GA 관련 업무를 총괄 운영하는 시스템을 하나 만들고 싶습니다. 개인적으로도 계속 배우고 시도하면서 변화에 뒤처지지 않는 사람이 되고 싶은 게 앞으로의 계획인 것 같아요.