데이터 인사이트

데이터 지식공유
나만 알기는 아까운 데이터 지식 함께나눠요.

[데이터 아키텍트 인터뷰] 체계적으로 분류하고 수학을 좋아했다

작성자
관리자
작성일
2020-09-18 09:26
조회
123

데이터 아키텍트에게 듣다

체계적으로 분류하고 수학을 좋아했다

 



 

송정호 데이터 아키텍트(CSLEE컨설팅)



• 데이터 아키텍트는 어떤 일을 하는 사람인가?

최종 사용자에게 보이지 않는 영역에서 데이터를 다루는 전문가라고 할 수 있다. 데이터 모델러가 하는 일에다 데이터 표준화 등 전사적 데이터 표준화, 향후 도입할 시스템과의 통합성까지 염두에 두고 실무 부서에서 필요한 데이터 정책까지 제시하는 데이터 분야에서 가장 상위의 전문가라고 할 수 있다. 쉽게 말하여, DB 관리와 데이터 모델링 등 DB 관련 업무에 대한 경험과 이해를 바탕으로 하는 DB 분야의 최상위의 엔지니어라는 점이다.


• 데이터 아키텍트의 매력은 무엇인가?

기술 전문가 측면에서 머물지 않고 현업 비즈니스 부서와 소통을 하면서 전사 차원의 데이터 정책을 수립하고 결정하는 역할을 한다는 점이다. IT 부서의 TA(Technical Architect), AA(Application Architect)와 소통을 하면서도 비즈니스 부서와도 밀접하게 관련돼 일을 한다. 요즘은 기업에서 어느 때보다 데이터의 가치를 강조하고 있으므로 향후 그 역할이 더 확대될 것이라고 전망한다.


• DA와 데이터 모델러 간의 역할 구분이 약간 모호한 것 같다.

DA는 데이터 모델러의 상위 개념이지만, 여기서 상위라는 개념이 기술적으로 위 단계만을 의미하지 않는다. 업무의 범위가 상대적으로 넓다고 보는 게 더 현실적이다. 데이터 모델러는 실무 부서 또는 고객으로부터 고민이나 문제점, 필요 사항 등을 듣고 데이터를 설계하는 실무 중심의 전문가다. 반면, DA는 데이터 모델러 뒤에서 표준에 따라 데이터 정책을 세우고, 데이터 품질관리, 마스터 데이터 관리, 데이터 정책 등을 수립하는 역할을 한다.


• 엔터프라이즈 시스템 차원에서 역할을 소개한다면.

DA가 정보전략계획(ISP) 컨설팅을 하면, 데이터 모델러가 모델링해 DBA에게 넘긴다. 이 모델링 결과를 토대로 DBA는 성능을 끌어내는 역할을 한다. 프로그램을 구현하는 역할은 개발자들이 한다. 참고로 요즘은 데이터 모델러를 DA로 통합해 부르기도 한다.


• DA로서 보람을 느낄 때는 언제인가.

보통 고객은 처음에는 요구사항이 분명하지 않다. 심지어 ‘예전에 다른 곳에서 하던 대로 해주세요’ 하고 요청하는 경우도 있다. 하지만 고객과 인터뷰하여 데이터적으로 접근하다 보면, 고객이 바라던 바가 구체적으로 드러나게 된다. 이 결과를 보고 고객도 놀라워한다. 가장 보람을 느끼는 순간이다. 또한 고객과 인터뷰를 한 후 데이터 모델링을 하다 보면, 업무 공백 지점이나 빠진 부분이 있음을 발견하곤 한다. 더불어 업무를 데이터 중심으로 이동하려면 기존 업무 프로세스에서 변화가 필요할 때가 있다. 예를 들어, 정보 시스템을 도입해 놓고도 일부에서는 전화로 처리하는 경우도 있다. 이렇게 되면, 데이터의 연관 관계가 어그러지고 만다. 데이터가 가치를 가지려면 데이터 간에 관계가 형성돼야 한다. ‘조언한 대로 프로세스가 바뀌어 업무 효율성이 크게 개선됐다’는 말을 들었을 때는 그 어떤 보람보다 크다.


•DA의 보수는 어느 정도인가?

곤란한 질문이다(웃음). 꽤 오래 전 기준이지만, 한 대형 SI 업체에서 근무할 때 기준으로 말하면, 초급 개발자와 초급 DBA 간에도 월 보수가 60% 넘게 차이가 나는 것을 알 수 있었다. 개발자보다는 훨씬 유리한 조건임에는 분명하다.



 

• DA가 되기까지의 과정을 소개해 달라.

 데이터베이스 관리자(DBA)로 일하다가 DBMS 개발사인 알티베이스에서 DB 엔지니어로서 일했다. DB 엔지니어는 일반적으로 DBMS 공급사에서 일하는, DB 엔진의 특성을 이해한 시스템 소프트웨어 개발자들이라고 본다면, DBA는 SQL을 모니터링하고 튜닝하는 역할을 한다. 다시 말하여 DBA는 데이터(콘텐트) 관리자라고 볼 수 있다. 기존에 DBA로서 일할 때, DBMS 내부 구조가 궁금했기에 DBMS 개발사에서 일해 보고 싶었다. 알티베이스에서 일하면서 궁금했던 점들이 많이 풀렸다.

당시, 나를 불러준 알티베이스가 내게 바랐던 점은 아마도 오라클 DB 기반의 풍부한 개발 경험이지 않았나 싶다. 이때 실무 프로젝트에서 만날 수 없었던 DB 엔진 내부의 특성을 많이 알게 됐다. 하지만 여기서도 그리 오랫동안 일하지 않았다. 현장 프로젝트를 하면서 수많은 경험을 할 수 없는 점이 아쉬웠던 것이다. 자신 스스로 정체된 느낌이 들어 DB 전문업체인 ‘CSLEE 컨설팅’으로 자리를 옮겨오면서 DA로서 일을 하게 됐다.


• DB와 인연을 맺게 된 배경은.

학부에서 경영학을 전공했다. 중학생 때까지 수학을 좋아했기에 공대에 가고 싶었으나 개인적인 이유 때문에 경영학과에 들어갔다. 1~2학년까지 별로 공부를 열심히 하지 않았다. 그러던 중 경영수학과 경영정보학, 회계학, 경제학에 흥미가 갔다. 3학년 1~2학기 중에 경영정보학 수강 중에 팀 프로젝트 과제를 하면서 정보기술이 정말로 재미있다는 것을 발견했다. 함께 참여했던 친구들은 별 흥미를 갖지 못했던 것에 비해 나는 빠져들어갔다. 90학번인데 당시 윈도우 3.0에 플로피 디스크를 사용하던 시절이었다. 로터스 1-2-3 표계산 프로그램과 dBase-III로 구현했다. 그런 특이함이 눈에 띄었는지, 대학 3학년 때에 이미 당시 현대전자 재무팀에 입사가 확정됐다. 졸업과 동시에 입사하여 6개월 정도 일을 했다. 갈망하던 것이 채워지지 않아 당시 LG소프트에서 운영하던 LG소프트 스쿨에서 6개월 과정의 개발자 양성 프로그램에 등록해 프로그래밍을 배웠다. 그때가 매우 즐거웠다. 여기서도 LG소프트로 취업이 바로 됐다. 신입사원이었을 때 처음으로 한 국방 프로젝트의 막바지 테스트 작업에 투입됐다. 선배 개발자들이 인수인계해 주고 빠져나갔다. 고객의 요구사항을 수용하면서 꽤 힘들었던 기억이다. 

당시만 해도 DB 분야에서 역할이 요즘처럼 세분화되지 않았다. 심지어 개발자가 서버 관리와 DB 테이블까지 만지던 시절이었다. 이때 쿼리 실력도 늘었다. 이때 중간 정도 진행되던 한 프로젝트에 투입됐다. 순차적 쿼리를 하던 것 2~3건을 모아 세 번 정도만 돌려서 결과를 도출할 수 있다는 것을 스스로 생각해서 적용한 결과, 놀라운 결과를 냈다. 몇 시간 만에 나오던 결과들이 실시간으로 나오는 게 아닌가! 고객사 담당자도 놀라워했다. 지금은 너무나 자연스러운 집합처리 개념을 모르고 있다가 스스로 이것을 발견했을 때였다. 그때까지만 해도 개발자들은 건마다 select해 가져온 데이터를 join해 SQL로 연산하던 것이 자연스러웠다. 이 방법은 쿼리가 매우 길어졌고, 자연스럽게 오류 발생 가능성도 높았다. 그때 PM이 이런 점을 인정하여 LG-CNS의 전신인 LG-EDS의 ITG 그룹에 추천해 줘서 회사를 옮겼다. 이 조직은 서버?애플리케이션?DA로 구성된 전문가 그룹이었다. 나는 DA팀에 배정돼 이때부터 DB를 본격적으로 배웠다.


• DA가 되기 위해서는 어떤 준비가 필요한가.

DA가 되겠다는 목표를 정했다면, 단기간에 되려고 하지 말고 개? 목표를 향해 차근차근 다가서는 방법이 현실적이라고 본다. 더불어 DBA나 모델러로서 오랜 동안 경험을 쌓는다고 하여 DA가 되는 게 아니다. 실제로 같은 데이터 엔지니어로 시작한 직장 동기 한 명이 있다. 그는 글로벌 DBMS 업체의 기술 전문가로 입사하면서 DB에 대한 관심이 없어졌다고 했다. 오류 처리 등 기술 지원을 위주로 하다 보니까 데이터 관점이 아닌 기술 관점에서 보게 되면서 그런 것이다. 이에 비해 개발자들이 데이터에 대한 관심이 높다. 개발자들과 함께 일하다 보면, 개발자들이 ‘테이블을 이렇게 만들면 좋겠다’는 의견을 제시할 때도 있다. DA 관점에서 봤을 때 수용하지 못할 수도 있다. 이때 왜 그런지 질문을 갖고 데이터를 공부해 볼 수도 있다. 이 과정을 거쳐서 DBA가 되고 다시 데이터 모델러로서 일을 할 수 있다. 개발자로서, DBA로서, 모델러로서 경험을 쌓아가면서 단계별로 나아가는 과정이 현실적이라고 본다.


• 조금 더 쉽게 설명하면.

이것은 모델링을 해 본 사람이 이해할 수 있는 사항인지도 모르겠다. 모델링을 할 때 엔터티 키 식별자를 뭘 선택하느냐에 따라 옵션이 다양하게 생긴다. 개발자 입장에서는 이 방법, 저 방법을 사용하더라도 동일한 결과를 도출할 수 있는 상황이 있다. 하지만 데이터 모델러는 이것 중에서도 어느 게 최선인가를 고민해야 한다. 같은 상황을 두고도 사람마다 다른 말로 표현하지만, 정확하게 표현할 수 있는 말은 하나밖에 없다는 말을 어디선가 본 것 같다. 데이터의 세계에도 이것은 그대로 적용된다고 생각한다.


• 개발 경력 없이 회사 차원에서 육성한 데이터 모델러도 있다고 들었다.

데이터 모델러에게는 개발과 DB에 대한 전반적인 기반 지식이 필요하다. 개발 경험이나 DBA 경험을 거치지 않은 모델러나 DA는 실제 프로젝트에서 개발자들과 소통에서 어려움이 따를 수 있다. 물론, 일부에서는 데이터 모델링을 할 때 개발까지 염두에 두면 안 좋은 결과가 나올 수 있다는 의견을 제시하기도 한다. 데이터 모델링은 업무 중심으로 접근해야 하는데, 프로그래머 관점에서 화면 중심으로 접근할 가능이 있기 때문이다. 하지만 이 단계를 뛰어 넘을 수만 있다면, 개발을 이해하면서 데이터 모델링을 하면 매우 뛰어난 모델이 나올 수 있다. 더불어 분명한 것은 중간 단계를 거치지 않고 바로 DA 또는 모델러가 되는 경우는 매우 드물기에, 앞서 단계별로 접근하라고 한 것이다.


• 어떤 유형의 사람이 DA로서 어울리는 사람이라고 생각하나?

나는 경우의 수를 늘 채워 넣어야 하는 스타일이었다. 경우의 수가 3개가 있다면, 나머지(others)를 분명히 생각해야 한다. 어렸을 때 부모님이 뭘 사오라고 심부름을 시키면, ‘나는 그 상품이 없으면 어떻게 할까?’를 늘 생각했던 기억이 난다. 다음과 같은 두 유형의 사람이 DA로서 가능성이 높다고 볼 수 있다.

첫째, 개발자 유형을 크게 두 가지로 구분하면 ‘시도-에러 수정’ 스타일과 ‘사전에 꼼꼼히 생각해 보고 개발에 착수’하는 스타일로 양분된다. 데이터 모델러에게는 후자의 경우가 훨씬 어울린다. 처음에는 시간이 걸리더라도 나중에는 더 효과를 발휘할 수 있다. 물론, 우선 개발한 다음 에러를 수정하는 유형이 초기에는 생산성이 더 높다. 하지만 데이터 세계에서는 생산성 높은 개발자는 위험할 수 있고, 일단 데이터 모델링과는 어울리지 않는다.

둘째, 꼼꼼하고 조직화와 체계화하는 것을 좋아하는 유형이 잘 어울린다. 고객이 말하지 않은 부분까지 채워나갈 수 있어야 한다. 한 가지의 구조가 나오면, 드러나지 않은 나머지 구조가 있음을 보고 고객에게 질문을 던질 수 있어야 한다. 업무 분석을 할 때 고객이 하는 말만 듣고는 완료하기 힘들다. 따라서 경우의 수까지 봐야 한다. 이런 데이터 모델러를 보고 개발자들은 답답해 하는 경우가 많다. DBA는 더 보수적이다.


• 대학생이라면 어떤 과목이 DA에게 어울린다고 생각하는가?

개발 관련 과목은 모두 도움이 된다. 더불어 고객을 대상으로 컨설팅 업무를 하기 때문에 컨설팅 과목은 필수적으로 듣는 게 좋다. 매우 도움이 된다.


• DA로서 성공할 가능성이 높은 사람의 유형이 있다면?

누구에게나 한 가지씩은 장점이 있듯이 이쪽도 분명히 그런 사람이 있다. 신입사원 가운데 새로운 기술이나 제품 등이 나왔을 때, 재미있어 하면서 공부하는 사람들이 있는데 이런 사람들이 잘하는 경우가 많았다. 이런 유형의 신입 사원들은 하나를 가르쳐 주면 열을 알아차렸다. 더불어 생각나는 대로 사고하지 않고, 분류를 해가면서 체계적으로 하는 사람들이 더 유리하다고 본다.


• 어디에서 차이가 나는가?

개발자에게 테이블을 만들어 보게 하면, 최종 사용자에게 노출될 기능이 들어갈 공간 중심으로 테이블을 설계한다. 그러다 보니 심할 때는 화면 하나에 테이블 하나를 만드는 경우까지 있었다. 경험 많은 개발자들과 일할 때, 설득하는 과정이 일의 절반 이상이 될 때도 있다. 모델러에게 데이터의 정합성은 매우 중요하다. 구조적으로 데이터를 모순 없이 설계해야 한다. 데이터 설계가 잘못되면, 나중에 매우 혼란스러워진다. 해당 시점의 개발자는 그 문제를 프로그래밍 과정 중에서 해결할 수 있다고 접근하지만, 개발자가 바뀌면 문제의 지점을 발견 못하여 혼란스러워 한다. DA는 그 문제를 원천적으로 차단하려고 접근한다.