Database Graph Generator 구축 후기 (1/2)

안내: 본 글은 2023년 상반기 삼성전자 DS부문 장기현장실습에서 진행했던 과제에 대한 필자의 일기입니다. 회사의 민감한 정보나 개발한 소스코드 등 서약서 상에 꼬투리 잡힐만한 내용은 전혀 언급하지 않았음을 미리 선언합니다.

이 글을 쓰기까지

2023년 6월 23일, 4개월 간의 학기대체 현장실습이 끝났다. 2월에 시간표를 짤 때만 하더라도 1학기를 이렇게 보내고 있을 줄은 꿈에도 몰랐다. 3월 내내 9 to 6 비대면 SW교육을 듣고, 세 달 동안 경기도 화성시로 통근버스 타고 출퇴근을 하다보니 어느새 학기가 끝나있었다. 회사 로고 큼지막하게 박힌 수료증도 받았겠다, CV에 2023년 경력 한 줄 늘렸겠다, 아주 만족스러웠다. 하지만 아쉬운 점이 하나 있었는데 그동안 사내 인트라넷에서 개발한 소스코드를 나의 Github에 못 올린다는 사실이었다. 개인 과제를 이렇게 흘려 보낼 수는 없어서 후기 형식으로다가 글을 남기고자 한다.

과제 주제를 고르기까지

원래 나의 과제는 DFD 문서화

메모리 SCM 파트에 배치 받은건 출근한지 3일 째 되던 날이었다. 팀장님, 그룹장님 포함 주변 파트원분들과 인사를 나눈 후 파트장님과 일대일 면담을 진행했고 업무 리더님과도 이야기를 나누었다. 그리고 나서 실습 기간 동안 가까이 지내게 될 지도 선배님과 함께 참여할 과제에 대한 간단한 설명을 들었다. 내가 해야 할 개인 과제는 그거 말고 따로 있었는데, 그 과제를 참여하면서 현행 분석 내용을 바탕으로 DFD(Dataflow Diagram)을 문서화하는 것이었다.

우선 파트장님께서 설명하시길 나의 지원서에서 “SQL 튜닝” 경험을 보고 파트에 데려오셨다고 했다. 그걸 읽어보셨다니 좀 부끄러웠지만 그래도 나의 SQL 실력이나 PL\SQL 개발 경험을 높게 사주셨다는 것에 감사했다. 해당 과제에 참여시키는 배경으로는 현업에서 “SQL 잘 치는 사람”을 필요로한다고 해서 나를 적격으로 꼽으셨다. 또한 파트 내에서 Procedure에 대한 메타데이터 수집의 필요성을 느끼고 있었기에 해당 과제를 진행하면서 DFD를 정리해주면 좋겠다고 생각하셨다.

Procedure 분석 쯤이야….?!

과제 진행에 앞서 우선 4월 한달 간은 사내 개발환경 설정을 하라고 하셨다. 사내 보안 정책이나 방화벽들이 촘촘해서 개발환경 설정하는 기간을 통 크게 잡으셨다. 뭐, 나의 능력을 과소 평가해주셔서 감사했다. “소프트웨어유지보수병”이라는 직책으로 군 복무를 한 나는 인터넷도 안 되는 군 인트라넷 환경에서 빌드부터 테스트, 배포 까지 웹 개발에 필요한 모든 요소들을 Installer 없이 손으로 zip파일을 가져다가 들이부은 경험이 있다. 게다가 내가 복무한 시기가 Windows10 전환 기간과 맞물려서 20여대가 넘는 PC에 저 개발 환경설정을 했으며, 부서장님들의 데스크탑 환경 설정 또한 내가 맡아서 진행했다. 공군본부 직할로 근무하다 보니 Windows10용 보안 프로그램을 처음 맞이했기 때문에 개발 프로그램을 설치할 때 발생하는 문제에 대한 Walkaround를 내가 가장 먼저 발명했다고 해도 과언이 아닐 정도였다.

이러한 나의 짬을 바탕으로 3일 만에 Oracle Client는 물론이거니와 심심할 때 돌려볼 Python과 Java까지 웬만한 개발 환경은 다 갖추었다. 그걸 본 주변 파트원분들은 다들 놀라셨지만, 내 입장에선 아무래도 군대 보안 프로그램이 더 까다로웠다고 평가할 수 있겠다. 본격적인 과제 시작까지 3주 넘게 남았기 때문에 미리 계정 정보를 받아 Oracle 데이터베이스를 둘러 보고 있었다. 이 곳에서는 운영 - QA - 개발 3종으로 운영하고 있었고, 실제 운영 데이터를 개발환경에서의 자유도 만큼이나 QA에서 다룰 수 있었다. 이미 Batch Procedure 유지보수 경험이 있는지라 수백개의 Procedure 목록을 보았을 때는 크게 놀라진 않았다. PL/SQL 소스코드도 대략적으로 훑어보니 이전에 프로젝트의 개발 가이드라인 패턴들이 보여서 이해하는데 수월했다.

본격적인 과제 진행에 앞서 이전 협의 내용들을 Follow-up 하고 회의에 참석했다. 거기서 느낀 점은 Dataflow를 찾아내는게 생각보다 어려울 수 있겠다는 사실이었다. 우선 MIS팀의 담당자들도 관련 내용에 대해 새로 분석이 필요하다는 입장이었고, SDS 측의 CI 또한 난색을 표시하셨다. 과연 현업에 계신 분들과 개발자분들이 어려워하시는 일을 3개월 안에 할 수 있을지 의문이 들었다. 그리고 소스코드를 읽을 수 있다고 하더라도 그 흐름을 그리기 위해선 비즈니스적인 도메인 지식이 필요한데, 지식의 범위는 조절할 수 있겠다만 이것 또한 주어진 실습 기간 내에 이해하기 어려운건 확실했다.

심란해진 마음을 다잡아보자

이제 무엇이 문제인지 모르는 상태에서 아는 상태가 되었다. 나의 직감은 “기존에 내가 하던 방식으론 기한 내에 끝내는 것은 절대로 불가능하다”였다. 예전에 Procedure를 분석하면서 모르는 부분이 있을 때는 Table도 보고, Logic도 분석해보면서 그 의미를 찾아나섰다. 그런데 이제 내 입장에서 SCM 시스템에 사용되는 대부분의 Column들의 의미가 바로 와닫지 않았다. 또한 Web Application의 소스코드 또한 갖고 있지 않았기 때문에 내가 추론한 내용이 맞는지도 검증할 방법이 없었다. 코드 하나하나 열어보면서 그 질문에 대한 답을 해줄 파트원분들도 눈에 안 띄었기 때문에 중도에 과제가 흐지부지 될 것 같은 예감이 들었다.

우선 내 눈 앞에 놓인 산적한 문제점들을 하나하나 풀어가보기로 했다. 우선 Procedure의 의존성 정보부터 파악하기 위해 DBA_DEPENDENCIES라는 시스템 View부터 들여다보기 시작했다. Procedure 내 Table을 정리하고, 호출하는 또 다른 Procedure가 있다면 또 분석하는 식으로 재귀적으로 진행하다보니 저 표로 된 형식을 그래프를 통해 보면 이해가 쉽지 않을까 생각했다. 물론 손으로도 그래프를 그릴 수 있었겠지만 사내 정보 공유 페이지인 Confluence에 관계정보를 입력하면 이를 그래프로 그려주는 Plugin이 있음을 발견했다. 별다른 가공 없이 SQL문에서 나온 결과를 그대로 복붙하니 아주 만족스럽게 그래프가 그려졌다.

그렇게 혼자서 그래프를 그리던 중 지나가던 지도 선배님이 내 모니터를 보시더니 화들짝 놀라셨다. 아니 이거 어떻게 그렸냐면서 물어보셨고 뭐 대충 SQL 만들어서 Plugin 집어 넣으니 이런 그림이 나왔다고 설명드렸다. 그대로 파트장님 불러와서 내가 그린 그래프를 보여주셨는데 파트장님도 굉장히 흥분한 상태셨다. 아 일단 진정시키는 차원에서 이건 의존성 그래프지, Dataflow가 아님을 먼저 이해시켜드렸다. 그러더니 파트장님께서 각 Table의 In/Out 정보를 넣으면 그래프를 다시 그릴 수 있겠는지 여쭤보셨는데, 가능하다고 답했다. 그렇게 나는 자동으로 Dataflow Diagram을 생성하는 과제를 진행하게 되었다.

이쯤에서 알아보는 DFD

본격적인 개발 이야기에 앞서 DFD부터 언급할 필요가 있다. Dataflow Diagram, 줄여서 DFD. 말 그대로 시스템의 데이터 흐름을 시각적으로 나타낸 다이어그램이다. 그 안에서는 이 데이터가 어떻게 생성되어 어디에서 쓰이는지 보거나, 이 프로그램은 무슨 데이터를 끌어와 어디로 넘기는지 등을 한 눈에 파악할 수 있게 해주는 역할을 한다. 보통 신규 개발 프로젝트나 유지보수 과제를 진행할 때 소스코드 말고도 여러 문서들이 나오게 되는데, 그 중에 DFD가 존재한다.

이 문서는 개발자나 시스템 담담자, 특히 MIS팀 입장에서 아주 요긴하다. 우선 데이터 흐름 정보 그 자체는 VoC(Voice of Customer) 대응이나 PI(Process Innovation)에서 현행 분석을 할 때 꼭 필요하다. 사용자 입장에선 화면 대 화면으로 정보를 읽고 해석하지만, 시스템 담당자 입장에선 저 화면에 보여지는 데이터들이 어디서 어떻게 가공되어 보여지고 그들은 서로 어떤 관계를 갖는지 파악해야 할 필요가 있다. 그럴 때 관련 DFD를 본다면 그 질문에 대한 답을 찾을 수 있다.

하지만 실상은 아무도 DFD 문서를 제대로 활용하지 않는다는 점이다. 우선 문서화된 DFD의 첫 번째 한계점으론 특정 범위만을 담고 있다는 점이다. 해당 과제의 산출물로서 작성하다보니 해당 과제에서 다루지 않은 부분의 데이터 흐름은 자연스럽게 생략된다. 자신이 알고 싶어 하는 데이터 흐름 정보를 찾아내기 위해 모든 DFD 문서를 열어보는건 어려운 일이다. 또한 현행화가 이루어지지 않는다는 것도 큰 문제이다. 해당 DFD 문서의 작성 주체는 개발 담당자로 시스템 인수가 끝난 이후에 일어난 일은 DFD에 안 적혀 있는게 당연하다. 해당 문서에 적힌 데이터 흐름 정보가 현재 시스템에서 돌아가는 것과 같다는 것을 아무도 보장해주지 않기 때문에 DFD가 필요할 때마다 새롭게 분석하는 실정이다.

생각해보면 DFD 문서화 자체로는 뭔가 부족한 감이 있었다. 나에게 DFD를 그리라는 일을 시키는 이유도 기존에 갖고 있던 DFD들이 현업에서 제대로 쓰이고 있지 않기 때문이었다. 그래서 기껏 DFD를 그려봤자 한두달 안에는 보긴 하겠지만, 결국엔 다른 DFD들 처럼 제 기능을 못 하게 되리라는게 뻔했다. 그래서 DFD 문서화라는 산출물 자체를 과제 목표로 삼기 보다 DFD를 자동으로 생성하는 시스템을 구축하는 것을 목표로 삼는게 내 입장에서도 더 나았다.

그래서 자동화는 어떻게

“어떻게 하면 DFD를 자동으로 만들어낼 수 있는가?”라는 물음에 답을 내려보고자 생각해봤다. 이것 저것 떠오르는 대로 설명하자면 다음과 같다.

시각화

• AS-IS: PPT나 Word에서 일일이 손으로 그래프를 그렸다.
• TO-BE: Confluence Plugin 중 하나인 ‘Graphviz’를 활용할 생각이다. 노드 간 관계 정보를 텍스트로 입력하면 이들을 화살표로 자동으로 이어주고 묶어준다.

입출력 분석

• AS-IS: Procedure 소스코드를 읽으면서 Table들을 눈으로 찾아냈다.
• TO-BE: ParseTree를 그려서 Table을 찾아낼 생각이다. 예를 들어 INSERT 안에 있는건 데이터흐름 상 Out이고, SELECT에 있는건 In이라고 식별하는 방식이다.

데이터 흐름 추적

• AS-IS: Procedure 내에서 찾은 Table에 정보를 넣거나 빼는 다른 Procedure를 찾아냈다.
• TO-BE: Procedure - Table 간 입출력 관계를 전부 찾은 다음 BFS 방식으로 탐색한다. 하나의 기준점에서 Propagate 하듯이 데이터 원천과 활용처를 찾아낸다.

아이디어 구상 단계에서 가장 신경쓴 부분은 입출력 분석이었다. 시각화 과정 자동화는 이미 완료되었고 데이터 흐름 추적이야 4주 간의 SW교육에서 배운 내용을 적용하면 될 듯 했다. 그런데 이제 BFS 알고리즘을 활용하기 위해선 모든 Procedure - Table 입출력 관계를 알고 있어야 한다는 것이 전제되어야 한다. 만약 입출력 분석에서 문제가 발생하게 된다면 데이터 흐름은 물론 시각화 과정 까지 무용지물이 되어버린다. 지도 선배님께서는 “사람이 직접 입력하면 되지 않냐”라고 말씀해주셨다. 물론 가능하겠지만 이 과제의 완성도를 높이고자 입출력 분석 과정 까지 자동화시키고 싶은 게 나의 확고한 목표였다.

Proof of Concept

일명 PoC, 개념 증명 단계이다. 시스템 구축을 처음 부터 진행하는 것이 아니라, 지금 내가 생각한 아이디어가 실제로 동작하는지 선보이는 것 부터 해야한다. 실습 기간 동안 가만히 놀고 먹는 것 처럼 보이면 안 될 것 같아서 모종의 중간 결과물부터 뽑아내보려 했다. 최종 결과물로 보자면 ‘입출력 분석’, ‘데이터 흐름 추적’, ‘시각화’ 순으로 진행하는 것이 맞지만 지금 당장 눈에 보이는 결과물을 낼 수 있는 순서를 따지자면 ‘시각화’가 가장 쉽고 빠르다. 그 다음으로 Procedure - Table 입출력 관계를 엑셀로 보여줄 수 있는 ‘입출력 분석’, 마지막으로 이미 널리 알려진 BFS를 사용하는 ‘데이터 흐름 추적’ 순이다.

시각화

Graphviz 라이브러리를 열심히 찾아봤다. 찾아보니 그래프 방향이라던가 노드 간 간격이라던가, 노드 별 모양과 색상을 바꿀 수 있었다. 데이터 흐름을 예쁘게 보여주기 위해 Procedure과 Table을 상징하는 각각의 색상과 모양을 입혀보았다. 이미 의존성 그래프를 그릴 때 써봤으니 DFD 또한 무난하게 시각화할 수 있었다.

입출력 분석

이건 좀 할 말이 많다. 직전 학기에 Compiler Techniques에서 배웠던 내용을 떠올려보면 소스코드가 어디선가 컴파일 되고, 그 중간에 Parse Tree를 쓸테니, 그 지점에서 INSERT 또는 SELECT 되는 Table을 찾으면 되겠다 싶었다. 우선 Oracle 내부 Compile 과정에 대해 찾아보았다. 조사 결과 Procedure Compile 과정에서 사용자가 참조할 수 있는 정보들은 어셈블리 언어로 변환된 코드와 해당 코드에서 Table, Procedure 등 오브젝트로 참조되는 항목들에 대한 정보였다. 가뜩이나 자체 언어에 컴파일러라 어렵고 시간도 많이 들거라 판단했다.

그렇게 조사를 이어나가던 중 ANTLR라는 오픈소스 컴파일러를 발견했다. Github에 들어가보니 온갖 언어 별 문법 파일이 있었고, 그 중에 Oracle PL/SQL 또한 있었다. 심지어 회사 운영환경과 동일한 11g로 존재했다. 이제 ANTLR 사용법만 익히면 되었다. 역시 오픈소스 답게 관련 문서와 Tool 또한 여럿 있었다. 이것 저것 따라해보니 어느새 PL/SQL의 Parse Tree를 만들 수 있었다.

여기서 문제는 해당 Parse Tree를 어떻게 시각화하는 것이다. 소스코드 상에서 TreeNode 객체에 접근할 수는 있었지만, 이걸 큰 그림으로 그려내기 위해서는 시각화가 필요했다. 우선 ANTLR가 제공하는 CLI 중에 pop-up 형식으로 Parse Tree를 그려주는 기능이 있었다. 이렇게라도 보니 훨씬 나았지만 문법의 Depth가 깊어질 수록 복잡해져서 알아보기 힘든 경우가 여럿 있었다. 그래서 자체적으로 해당 문법을 요약해서 보여줄 수 있는 방법을 찾아보았다.

ANTLR 라이브러리가 제공하는 기능 중에 TreeWalker가 있었다. 이걸 Graphviz와 잘 결합시키면 Tree를 그려낼 수 있겠다 싶었다. Node를 방문하고 나가는 이벤트에 대해 함수를 붙일 수 있었다. Tree의 자식들이 갈라지는 지점과 Terminal Node만 남기도록 시각화 코드를 만들어서 돌려보니 훨씬 그래프가 깔끔하게 나왔다. 이러한 시각화 도구들을 활용해 Parse Tree들을 그려보고 INSERT, SELECT 등 아래 있는 Table들을 찾아보았다.

WIP…