<div id="readability-page-1" class="page"><div><figure id="29ca360d-33e3-8051-b7c7-f27b5521ea58"><img src="https://static.toss.im/ipd-tcs/toss_core/live/b514634d-b400-4fc9-913d-adc34b6d56c3/1031-img-inner-techblog1.png" alt=""></figure><h3 id="29ca360d-33e3-8085-a47a-d2ce7bfaf91a">Q. 데이터 아키텍트라는 일을 처음 알게 된 건 언제였나요?</h3>대학생 때 우연히 한 데이터 컨설팅 회사의 세미나를 들은 적이 있어요. 그 자리에서 처음으로 ‘데이터 아키텍트’라는 단어를 접했죠. 당시 국내에서는 아직 생소했던 데이터 아키텍처 개념을 도입하고 데이터 관리 방법론을 정립해 가던 분들이었는데, 정말 멋있다고 느꼈어요.‘나도 저런 일을 해보고 싶다’라는 마음이 생겼고, 운 좋게도 그 회사에서 데이터 아키텍트로 커리어를 시작할 기회를 얻었습니다. 그곳에서 데이터베이스 성능, 모델링의 원리 등 데이터 설계의 본질을 깊이 있게 배울 수 있었고, 무엇보다 “데이터의 품질은 결국 설계에서 결정된다”는 사실을 몸으로 체감할 수 있었어요.<figure id="29ca360d-33e3-80dd-91e7-df752eb0a850"><img src="https://static.toss.im/ipd-tcs/toss_core/live/8be4ac4b-eb41-4c26-85c2-f2e5ef6d06d6/1031-img-inner-techblog2.png" alt=""></figure><h3 id="29ca360d-33e3-806f-ab19-ce98558c8e01">Q. 안정적인 컨설팅 회사에서 플랫폼 회사로 옮긴 이유가 궁금해요.</h3>데이터 컨설팅 회사에서의 경험은 제게 정말 의미 있는 시작점이었고, 데이터 설계의 원리와 철학을 배울 수 있었던 소중한 기억이에요. 그런데 어느 시점부터 시장 전체가 운영계 시스템 중심에서 분석계 플랫폼 중심으로 빠르게 전환되기 시작했죠. 당시 저는 이 변화 속에서 ‘컨설턴트’가 아닌, 실제 데이터의 생성부터 활용까지를 책임지는 ‘운영자’ 입장에서의 경험이 필요하다고 느꼈어요.데이터 아키텍트라는 역할을 좀 더 넓은 관점에서 실현하려면, 실제 프로덕션 환경에서 데이터를 어떻게 만들고, 어떻게 쓰이며, 어떤 품질 이슈들이 발생하는지 현장에서 겪고 구조를 개선해 보는 경험이 반드시 필요하다고 판단했어요. 그래서 컨설팅이라는 틀을 벗어나, 플랫폼 조직의 내부에서 데이터를 주도적으로 설계하고 운영해 보고자 이직을 결심했습니다.IT서비스를 제공하는 플랫폼 회사로 옮기면서, 빠른 개발 사이클과 데이터 품질 관리 사이의 간극을 처음으로 실감했습니다. 제품은 빨라야 했고, 데이터는 그 뒤를 수습해야 했죠. ‘속도와 품질은 싸우는 게 아니라, 균형을 찾아야 한다.’라는 것을 그때 깨달았어요.<h3 id="29ca360d-33e3-80d9-8317-fcef05e18e00">Q. 배달플랫폼 회사에서는 어떤 경험을 하셨나요?</h3>데이터 소비자들이 일관된 방식으로 데이터를 활용할 수 있도록 표준과 정책을 정비하는 데이터 아키텍트였고 , 동시에 데이터 파이프라인을 설계하고 운영하는 Data Analytics Engineer 역할도 함께 했어요. 전사 KPI와 연결된 마트나 지표, 대시보드를 만들면서 실제 비즈니스와 데이터를 연결하는 경험은 정말 인상 깊었고, 데이터 플랫폼을 중심으로 통합된 구조를 설계하고 운영해 보는 것도 좋은 배움이었죠.그런데 어느 순간부터 제 일이 ‘뒤에서 퍼즐을 맞추는 느낌’처럼 다가오기 시작했어요. 서비스가 빠르게 바뀌다 보면, 데이터는 늘 그 다음에 맞춰야 했고, 어느샌가 제가 하고 있는 일이 문제를 해결하는 것보다는 수습하는 쪽에 가까워지는 거예요. 그래서 더더욱 데이터가 들어오는 흐름부터 구조적으로 정리돼야 한다는 걸 몸으로 느꼈죠. 결국 데이터 품질은 플랫폼에서 뒷단에서만 만들어지는 게 아니라, 처음부터 끝까지 연결된 구조 속에서 관리되어야 한다는 걸 깨달았습니다.<figure id="29ca360d-33e3-8080-9985-da3ee4ce3259"><img src="https://static.toss.im/ipd-tcs/toss_core/live/2cee2912-34af-42d5-959b-545477fd8abb/1031-img-inner-techblog3.png" alt=""></figure><h3 id="29ca360d-33e3-80de-8319-d61e5527da88">Q. 토스로 이직하게 된 계기가 그 지점이었겠네요.</h3>맞아요. 높은 수준의 데이터 품질을 유지하기 위해서는, 조직 전체가 데이터를 하나의 ‘설계 대상’으로 보고 함께 정리해 나가려는 문화가 필요하다고 느꼈어요. 단순히 뒷단에서 정제하는 게 아니라, 데이터가 만들어지는 순간부터 책임져야 한다는 관점이 조직 전반에 깔려 있어야 아키텍트로서도 진짜 의미 있는 역할을 할 수 있으니까요. 그러던 중 토스의 블로그와 채용공고에서 End-to-End 데이터 거버넌스를 지향한다는 문장을 보게 됐고, 그 부분이 특히 깊이 와 닿았어요.“아, 이 회사는 데이터의 시작과 끝을 함께 고민하려는 문화를 가지고 있구나.” 이 점이 정말 매력적이었죠.토스는 이미 데이터를 중심으로 의사결정하는 문화가 자리 잡은 곳이었고, 전통적인 대기업처럼 역할이 고정된 아키텍트가 아니라, 빠르게 변화하는 환경 속에서 ‘데이터를 어떻게 잘 설계하고 관리할 것인가’를 주도적으로 고민할 수 있는 조직이었어요. 여기라면 진짜 데이터 아키텍트로 일할 수 있겠다고 판단했습니다.<figure id="29ca360d-33e3-8066-857b-e1fc78d384cf"><img src="https://static.toss.im/ipd-tcs/toss_core/live/07cd910a-f51e-4bee-a332-612f2ab139a3/1031-img-inner-techblog4.png" alt=""></figure><h3 id="29ca360d-33e3-809f-a940-f4e1c48047c4">Q. 막상 들어와 보니 어땠나요?</h3>쉽지 않아요. 아니, 솔직히 말하면 정말 어렵죠.이미 잘 작동하고 있는 데이터 환경에서 ‘이걸 90점에서 95점으로 더 끌어올려야 한다’고 설득하는 일, 그리고 그 변화가 조직 전체 리소스를 들일 만큼 의미 있는 개선이라는 걸 입증하는 일은 생각보다 훨씬 더 복잡하고 어려워요. 더 나은 구조를 제안한다는 건, 기존에 익숙하게 사용 중이던 테이블과 방식들을 바꾸자고 말하는 일이기도 하니까요. 그에 따르는 변경 비용도 결코 작지 않죠.하지만 다행히도, 토스에는 ‘더 나아가야 한다’는 방향성에 공감해 주는 동료들이 정말 많아요. 그리고 무엇보다, AI 시대에 우리가 다루는 데이터가 ‘사람만이 아니라 기계도 이해할 수 있는 구조여야 한다’는 데에도 깊이 공감해 주죠.지금 저는 그런 동료들과 함께, 우리 데이터에 담긴 ‘진짜 의미’를 찾아내고 연결하는 일을 하고 있어요. 표준화, 의미기반 표준사전, 온톨로지 등으로 설명할 수 있는 작업들이고, 그걸 통해 사람과 AI가 더 정확하게 이해할 수 있는 데이터 구조를 만들어가고 있습니다. 결국 이 모든 과정이 데이터 품질을 올리고, 토스가 더 빠르고 똑똑하게 일할 수 있는 기반을 만드는 일이라고 생각해요.<h3 id="29ca360d-33e3-806f-886f-cd722f9911ca">Q. AI가 이해할 수 있는 데이터를 만든다니, 흥미롭네요.</h3>네, 요즘은 데이터를 사람만 이해하는 구조로 만들면 부족한 시대인 것 같아요. 이제는 AI가 질문하고, 요약하고, 분석하는 시대잖아요. 그럴수록 데이터 간의 의미 관계가 명확히 설계돼 있어야 AI도 맥락을 놓치지 않고 제대로 이해하고 응답할 수 있어요.예전에는 사람이 테이블이나 컬럼의 설명 같은 메타데이터를 보면서 의미를 어느 정도 유추하고 이해할 수 있었죠. 지금도 그런 메타데이터를 잘 설계해서 제공하는 건 여전히 중요하고, 저희도 그렇게 하고 있어요. 하지만 AI는 물론이고, 사람도 추론에만 의존하면 해석의 오류나 오해가 생기기 쉬워요. 그래서 지금 저희가 하고 있는 일은, 그런 추측의 여지를 줄이고 데이터 간의 의미적 연결을 훨씬 더 명확하게 설계하는 것이에요.“이 컬럼이 어떤 개념이고, 어떤 관계 안에 놓여 있는지”를 기계가 스스로 추론하지 않아도 바로 이해할 수 있도록 연결해 주는 작업이라고 보시면 됩니다. 이것이 AI가 정확하게 이해하고 응답할 수 있는 기반이 되는 거고요. 결국 이런 구조가 사람과 AI 모두에게 신뢰할 수 있는 데이터 환경을 만들어주는 기반이 된다고 생각해요.물론, 이런 구조를 만들기 위해서는 단순히 ‘좋은 설계’를 넘어서, 조직이 빠르게 움직이는 속도 안에서 현실적으로 실현 가능한 방식으로 접근해야 해요. 그래서 토스에서는 품질과 업무 속도 사이의 균형을 항상 고민하게 됩니다.<h3 id="29ca360d-33e3-805c-86dd-d847b307d898">Q. ‘품질’과 ‘속도’를 함께 지키는 게 쉽지 않을 것 같아요.</h3>맞아요, 정말 쉽지 않죠. 토스처럼 빠르게 움직이는 조직에서는 속도 자체가 경쟁력이기 때문에, 데이터 아키텍트가 단순히 “이게 맞는 구조니까 바꿔야 해요”라고 말하는 건 크게 와닿지 않을 수 있어요. 설득력이 떨어지죠.그래서 저는 항상 ‘속도를 해치지 않으면서도 품질을 높일 수 있는 방법’을 고민해요.예를 들어, 처음부터 완벽한 설계를 하겠다는 접근보다는, 지금의 수준과 맥락에 맞는 구조를 만들고, 가까운 미래에 생길 수 있는 변화까지만 적절히 고려한 뒤, 나중에 상황이 바뀌었을 때 최소한의 기준선을 기반으로 유연하게 대응할 수 있도록 여지를 남겨두는 방식으로 접근하죠. “지금은 어디까지 만들고, 무엇을 열어둬야 나중에 무리 없이 정리할 수 있을까?“를 계속 고민하는 거예요.또, 자율성을 유지하면서도 자연스럽게 표준을 따르게 만드는 구조를 설계하려고 해요. 규칙을 강제하기보다는, “이렇게 만드는 게 오히려 편하다”는 경험을 설계하는 일에 더 가깝죠. 결국 속도와 품질은 충돌하는 가치가 아니라, 서로를 이해하고 조율해야 공존할 수 있는 가치라는 걸 매일 느끼고 있어요. 그리고 그 중간 지점을 찾아가는 과정이 지금 이 역할에서 가장 도전적이고, 또 가장 흥미로운 부분이라고 생각해요.<h3 id="29ca360d-33e3-80c1-9374-e0001a79d79c">Q. 앞으로 어떤 일을 더 해보고 싶으세요?</h3>가장 먼저는 진짜 의미에서의 End-to-End 데이터 거버넌스 체계를 제대로 구축해보고 싶어요.데이터 구조, 표준, 품질 관점에서 처음 생성되는 순간부터 최종 활용까지 전 과정이 자연스럽게 연결되고 관리되는 구조를 만드는 거죠. 이건 말로는 쉽지만, 실제 조직 내에서 잘 작동하는 경우는 정말 드물어요. 특히 토스처럼 빠르게 변화하는 환경에서는 단순히 기존의 방법론을 가져와선 한계가 있고, 속도와 유연성을 해치지 않으면서도 정합성과 품질을 지킬 수 있는 ‘토스다운 방식’을 새로 만들어야 한다고 생각해요.그래서 지금 하고 있는 작업들을 더 발전시켜서, 토스만의 설계 철학과 운영 방식이 담긴 데이터 거버넌스 모델을 완성해 보고 싶어요. 궁극적으로는 그게 업계에서도 하나의 좋은 레퍼런스로 남을 수 있으면 좋겠고요.<h3 id="29ca360d-33e3-8014-9d53-eddb944522db">Q. 마지막으로, 데이터 아키텍트를 꿈꾸는 사람들에게 해주고 싶은 말이 있다면요?</h3>저는 사실 데이터 엔지니어든, 분석가든, 어떤 데이터 직군에 있는 사람이 데이터가 잘 작동하길 바라는 마음만 있다면 누구나 아키텍트의 시작점에 있다고 생각해요. ‘데이터 아키텍트’라는 이름이 주는 무게감이나, 모든 걸 설계할 줄 알아야 한다는 부담 때문에 괜히 유니콘처럼 느껴지는 경우가 많은데, 사실은 작은 구조 하나를 더 낫게 만들고 싶은 마음에서 시작하는 역할이에요.그래서 “내가 그런 생각을 하고 있었다면, 이미 그 길 위에 있는 거다”라는 말을 꼭 해주고 싶어요. 그리고 적어도 토스에서는 그 생각을 진짜로 실현해볼 수 있는 환경이 있어요. 규칙을 주입하는 게 아니라, 실제 문제를 구조로 풀어가는 문화가 있고, 그 구조를 함께 설계해 갈 동료들이 옆에 있다는 점도요.Words 고정현
Edit 고정원</div></div>

토스테크

오늘은 토스의 1호 Data Architect 고정현님의 이야기를 들려드려요. 정현님은 토스에서 단순히 ‘규칙을 만드는 사람’이 아닙니다. 데이터를 사람과 AI가 정확히 ‘이해할 수 있는 구조’로 설계하는 아키텍트죠. 데이터 컨설팅 회사, 배달 플랫폼 회사, 그리고 지금의 토스까지, 정현님이 걸어온 길은 단순한 규칙 설정이 아닌, 데이터의 ‘의미’를 구조화하고 연결하는 설계 여정이었습니다.
Q. 데이터 아키텍트라는 일을 처음 알게 된 건 언제였나요?
대학생 때 우연히 한 데이터 컨설팅 회사의 세미나를 들은 적이 있어요. 그 자리에서 처음으로 ‘데이터 아키텍트’라는 단어를 접했죠. 당시 국내에서는 아직 생소했던 데이터 아키텍처 개념을 도입하고 데이터 관리 방법론을 정립해 가던 분들이었는데, 정말 멋있다고 느꼈어요.
‘나도 저런 일을 해보고 싶다’라는 마음이 생겼고, 운 좋게도 그 회사에서 데이터 아키텍트로 커리어를 시작할 기회를 얻었습니다. 그곳에서 데이터베이스 성능, 모델링의 원리 등 데이터 설계의 본질을 깊이 있게 배울 수 있었고, 무엇보다 “데이터의 품질은 결국 설계에서 결정된다”는 사실을 몸으로 체감할 수 있었어요.
Q. 안정적인 컨설팅 회사에서 플랫폼 회사로 옮긴 이유가 궁금해요.
데이터 컨설팅 회사에서의 경험은 제게 정말 의미 있는 시작점이었고, 데이터 설계의 원리와 철학을 배울 수 있었던 소중한 기억이에요. 그런데 어느 시점부터 시장 전체가 운영계 시스템 중심에서 분석계 플랫폼 중심으로 빠르게 전환되기 시작했죠. 당시 저는 이 변화 속에서 ‘컨설턴트’가 아닌, 실제 데이터의 생성부터 활용까지를 책임지는 ‘운영자’ 입장에서의 경험이 필요하다고 느꼈어요.
데이터 아키텍트라는 역할을 좀 더 넓은 관점에서 실현하려면, 실제 프로덕션 환경에서 데이터를 어떻게 만들고, 어떻게 쓰이며, 어떤 품질 이슈들이 발생하는지 현장에서 겪고 구조를 개선해 보는 경험이 반드시 필요하다고 판단했어요. 그래서 컨설팅이라는 틀을 벗어나, 플랫폼 조직의 내부에서 데이터를 주도적으로 설계하고 운영해 보고자 이직을 결심했습니다.
IT서비스를 제공하는 플랫폼 회사로 옮기면서, 빠른 개발 사이클과 데이터 품질 관리 사이의 간극을 처음으로 실감했습니다. 제품은 빨라야 했고, 데이터는 그 뒤를 수습해야 했죠. ‘속도와 품질은 싸우는 게 아니라, 균형을 찾아야 한다.’라는 것을 그때 깨달았어요.
Q. 배달플랫폼 회사에서는 어떤 경험을 하셨나요?
데이터 소비자들이 일관된 방식으로 데이터를 활용할 수 있도록 표준과 정책을 정비하는 데이터 아키텍트였고 , 동시에 데이터 파이프라인을 설계하고 운영하는 Data Analytics Engineer 역할도 함께 했어요. 전사 KPI와 연결된 마트나 지표, 대시보드를 만들면서 실제 비즈니스와 데이터를 연결하는 경험은 정말 인상 깊었고, 데이터 플랫폼을 중심으로 통합된 구조를 설계하고 운영해 보는 것도 좋은 배움이었죠.
그런데 어느 순간부터 제 일이 ‘뒤에서 퍼즐을 맞추는 느낌’처럼 다가오기 시작했어요. 서비스가 빠르게 바뀌다 보면, 데이터는 늘 그 다음에 맞춰야 했고, 어느샌가 제가 하고 있는 일이 문제를 해결하는 것보다는 수습하는 쪽에 가까워지는 거예요. 그래서 더더욱 데이터가 들어오는 흐름부터 구조적으로 정리돼야 한다는 걸 몸으로 느꼈죠. 결국 데이터 품질은 플랫폼에서 뒷단에서만 만들어지는 게 아니라, 처음부터 끝까지 연결된 구조 속에서 관리되어야 한다는 걸 깨달았습니다.
Q. 토스로 이직하게 된 계기가 그 지점이었겠네요.
맞아요. 높은 수준의 데이터 품질을 유지하기 위해서는, 조직 전체가 데이터를 하나의 ‘설계 대상’으로 보고 함께 정리해 나가려는 문화가 필요하다고 느꼈어요. 단순히 뒷단에서 정제하는 게 아니라, 데이터가 만들어지는 순간부터 책임져야 한다는 관점이 조직 전반에 깔려 있어야 아키텍트로서도 진짜 의미 있는 역할을 할 수 있으니까요. 
그러던 중 토스의 블로그와 채용공고에서 End-to-End 데이터 거버넌스를 지향한다는 문장을 보게 됐고, 그 부분이 특히 깊이 와 닿았어요.
“아, 이 회사는 데이터의 시작과 끝을 함께 고민하려는 문화를 가지고 있구나.” 이 점이 정말 매력적이었죠.
토스는 이미 데이터를 중심으로 의사결정하는 문화가 자리 잡은 곳이었고, 전통적인 대기업처럼 역할이 고정된 아키텍트가 아니라, 빠르게 변화하는 환경 속에서 ‘데이터를 어떻게 잘 설계하고 관리할 것인가’를 주도적으로 고민할 수 있는 조직이었어요. 여기라면 진짜 데이터 아키텍트로 일할 수 있겠다고 판단했습니다.
Q. 막상 들어와 보니 어땠나요?
쉽지 않아요. 아니, 솔직히 말하면 정말 어렵죠.
이미 잘 작동하고 있는 데이터 환경에서 ‘이걸 90점에서 95점으로 더 끌어올려야 한다’고 설득하는 일, 그리고 그 변화가 조직 전체 리소스를 들일 만큼 의미 있는 개선이라는 걸 입증하는 일은 생각보다 훨씬 더 복잡하고 어려워요. 더 나은 구조를 제안한다는 건, 기존에 익숙하게 사용 중이던 테이블과 방식들을 바꾸자고 말하는 일이기도 하니까요. 그에 따르는 변경 비용도 결코 작지 않죠.
하지만 다행히도, 토스에는 ‘더 나아가야 한다’는 방향성에 공감해 주는 동료들이 정말 많아요. 그리고 무엇보다, AI 시대에 우리가 다루는 데이터가 ‘사람만이 아니라 기계도 이해할 수 있는 구조여야 한다’는 데에도 깊이 공감해 주죠.
지금 저는 그런 동료들과 함께, 우리 데이터에 담긴 ‘진짜 의미’를 찾아내고 연결하는 일을 하고 있어요. 표준화, 의미기반 표준사전, 온톨로지 등으로 설명할 수 있는 작업들이고, 그걸 통해 사람과 AI가 더 정확하게 이해할 수 있는 데이터 구조를 만들어가고 있습니다. 결국 이 모든 과정이 데이터 품질을 올리고, 토스가 더 빠르고 똑똑하게 일할 수 있는 기반을 만드는 일이라고 생각해요.
Q. AI가 이해할 수 있는 데이터를 만든다니, 흥미롭네요.
네, 요즘은 데이터를 사람만 이해하는 구조로 만들면 부족한 시대인 것 같아요. 이제는 AI가 질문하고, 요약하고, 분석하는 시대잖아요. 그럴수록 데이터 간의 의미 관계가 명확히 설계돼 있어야 AI도 맥락을 놓치지 않고 제대로 이해하고 응답할 수 있어요.
예전에는 사람이 테이블이나 컬럼의 설명 같은 메타데이터를 보면서 의미를 어느 정도 유추하고 이해할 수 있었죠. 지금도 그런 메타데이터를 잘 설계해서 제공하는 건 여전히 중요하고, 저희도 그렇게 하고 있어요. 하지만 AI는 물론이고, 사람도 추론에만 의존하면 해석의 오류나 오해가 생기기 쉬워요. 그래서 지금 저희가 하고 있는 일은, 그런 추측의 여지를 줄이고 데이터 간의 의미적 연결을 훨씬 더 명확하게 설계하는 것이에요.
“이 컬럼이 어떤 개념이고, 어떤 관계 안에 놓여 있는지”를 기계가 스스로 추론하지 않아도 바로 이해할 수 있도록 연결해 주는 작업이라고 보시면 됩니다. 이것이 AI가 정확하게 이해하고 응답할 수 있는 기반이 되는 거고요. 결국 이런 구조가 사람과 AI 모두에게 신뢰할 수 있는 데이터 환경을 만들어주는 기반이 된다고 생각해요.
물론, 이런 구조를 만들기 위해서는 단순히 ‘좋은 설계’를 넘어서, 조직이 빠르게 움직이는 속도 안에서 현실적으로 실현 가능한 방식으로 접근해야 해요. 그래서 토스에서는 품질과 업무 속도 사이의 균형을 항상 고민하게 됩니다.
Q. ‘품질’과 ‘속도’를 함께 지키는 게 쉽지 않을 것 같아요.
맞아요, 정말 쉽지 않죠. 토스처럼 빠르게 움직이는 조직에서는 속도 자체가 경쟁력이기 때문에, 데이터 아키텍트가 단순히 “이게 맞는 구조니까 바꿔야 해요”라고 말하는 건 크게 와닿지 않을 수 있어요. 설득력이 떨어지죠.
그래서 저는 항상 ‘속도를 해치지 않으면서도 품질을 높일 수 있는 방법’을 고민해요.
예를 들어, 처음부터 완벽한 설계를 하겠다는 접근보다는, 지금의 수준과 맥락에 맞는 구조를 만들고, 가까운 미래에 생길 수 있는 변화까지만 적절히 고려한 뒤, 나중에 상황이 바뀌었을 때 최소한의 기준선을 기반으로 유연하게 대응할 수 있도록 여지를 남겨두는 방식으로 접근하죠. “지금은 어디까지 만들고, 무엇을 열어둬야 나중에 무리 없이 정리할 수 있을까?“를 계속 고민하는 거예요.
또, 자율성을 유지하면서도 자연스럽게 표준을 따르게 만드는 구조를 설계하려고 해요. 규칙을 강제하기보다는, “이렇게 만드는 게 오히려 편하다”는 경험을 설계하는 일에 더 가깝죠. 결국 속도와 품질은 충돌하는 가치가 아니라, 서로를 이해하고 조율해야 공존할 수 있는 가치라는 걸 매일 느끼고 있어요. 그리고 그 중간 지점을 찾아가는 과정이 지금 이 역할에서 가장 도전적이고, 또 가장 흥미로운 부분이라고 생각해요.
Q. 앞으로 어떤 일을 더 해보고 싶으세요?
가장 먼저는 진짜 의미에서의 End-to-End 데이터 거버넌스 체계를 제대로 구축해보고 싶어요.
데이터 구조, 표준, 품질 관점에서 처음 생성되는 순간부터 최종 활용까지 전 과정이 자연스럽게 연결되고 관리되는 구조를 만드는 거죠. 이건 말로는 쉽지만, 실제 조직 내에서 잘 작동하는 경우는 정말 드물어요. 특히 토스처럼 빠르게 변화하는 환경에서는 단순히 기존의 방법론을 가져와선 한계가 있고, 속도와 유연성을 해치지 않으면서도 정합성과 품질을 지킬 수 있는 ‘토스다운 방식’을 새로 만들어야 한다고 생각해요.
그래서 지금 하고 있는 작업들을 더 발전시켜서, 토스만의 설계 철학과 운영 방식이 담긴 데이터 거버넌스 모델을 완성해 보고 싶어요. 궁극적으로는 그게 업계에서도 하나의 좋은 레퍼런스로 남을 수 있으면 좋겠고요.
Q. 마지막으로, 데이터 아키텍트를 꿈꾸는 사람들에게 해주고 싶은 말이 있다면요?
저는 사실 데이터 엔지니어든, 분석가든, 어떤 데이터 직군에 있는 사람이 데이터가 잘 작동하길 바라는 마음만 있다면 누구나 아키텍트의 시작점에 있다고 생각해요. ‘데이터 아키텍트’라는 이름이 주는 무게감이나, 모든 걸 설계할 줄 알아야 한다는 부담 때문에 괜히 유니콘처럼 느껴지는 경우가 많은데, 사실은 작은 구조 하나를 더 낫게 만들고 싶은 마음에서 시작하는 역할이에요.
그래서 “내가 그런 생각을 하고 있었다면, 이미 그 길 위에 있는 거다”라는 말을 꼭 해주고 싶어요. 그리고 적어도 토스에서는 그 생각을 진짜로 실현해볼 수 있는 환경이 있어요. 규칙을 주입하는 게 아니라, 실제 문제를 구조로 풀어가는 문화가 있고, 그 구조를 함께 설계해 갈 동료들이 옆에 있다는 점도요.
Words 고정현
Edit 고정원

토스 피플 : 데이터를 ‘이해하는’ 구조를 설계합니다

댓글