단무지 시즌 Ⅲ: 단무지의 죽은 프로젝트 살리기(5회)

개발 프로젝트에 투입된 DBA 단무지의 활약

들어가면서
프로젝트 맛도 보지 못한 단무지 과장이 대출시스템 재개발 프로젝트의 발주사측 PM으로 투입되었습니다. 단 과장은 걱정이 앞섰지만 데이터 모델링 부분의 개선이 필요한 프로젝트라는 점과 냉정해 차장의 적극 추천 등으로 참여하게 됩니다. 업계에 소문이 난 탄탄해시스템즈가 수주사로 선정이 되었으며, 지난 3편에서는 킥오프와 프로젝트 수행계획서 작성까지 완료하였습니다.

그런데 프로젝트가 시작되자 마자 리스크가 발생하기 시작합니다. 프로젝트에서 가장 중요한 역할을 맡고 있는 현업 담당자인 대출해 대리가 프로젝트 참여에 미온적인 입장을 취하고 있는 것이 첫 번째요, 수주사 측 2명의 PL 중 한명인 나허세 과장이 이름 그대로 허세 작렬로 허당의 냄새를 슬슬 풍기고 있는 점이 두 번째입니다. 이번 4편은 분석/설계에 대한 이야기입니다. 단무지 과장이 프로젝트를 어떻게 진행 시킬까요 산으로 보내 버릴지, 아니면 연착륙 시킬 것인지 독자 여러분과 함께 지켜 보도록 하겠습니다.

[등장 인물]

단무지 과장
잘나가은행의 과장으로 DBA다. DBA로서 DB 실력은 탁월하나 프로젝트 경험이 없다. 잘나가 대출시스템 재개발 프로젝트의 발주사 측(은행) PM(Project Manager)으로, 첫 프로젝트에 좋은 성과를 내기 위해 상황에 맞는 합리적인 판단을 내려고 노력을 한다.



문희만 부장
탄탄해시스템즈의 부장으로 이번 프로젝특의 수주사 PM이다. 탄탄해시스템즈는 SI(System Integration) 전문사로서 업계에서 인정받는 회사다. 문 부장은 프로젝트 경험은 많으며, 프로젝트의 상세 진행은 PL에게 위임하는 성격이다. 능력 있는 PL과 만났을 때는 좋은 성과를 내지만, 그렇지 않을 때는 프로젝트를 어렵게 꾸려간다. 정말 이름과 같이 무늬만 PM인 듯한 인사다.



홍두깨 과장
탄탄해시스템즈의 과장으로 잘나가은행 대출 시스템 재개발 프로젝트의 PL(Project Leader)이다. 정말 홍두깨 같은 인물이다. 파트원들과 노는 것만 같으나, 프로젝트의 매 중요한 순간의 결정은 전광석화 같이 빠르고 정확한 결정을 한다. 프로젝트 내내 자리에 앉아 있는 시간보다는 파트원들 책상 옆에 앉아 노닥거리는 시간이 더 많은 사람이다. 홍 과장 파트의 파트원들은 휴일 근무뿐 아니라, 시간외 근무도 하지 않는 정시 출퇴근 족이다. 하지만 이상하리만큼 마일스톤에 따른 매 일정에 정확한 산출물을 제공한다. 아마도 우렁각시라도 숨겨놓고 프로젝트를 하는 것 같다.



나허세 과장
탄탄해시스템즈의 과장으로, 잘나가은행 대출 시스템 재개발 프로젝트의 PL이다. 이름 그대로 허세 작렬이나 중요한 순간 순간을 놓치기 일수이다. 나 과장 파트는 PL의 능력에() 힘입어 프로젝트를 암흑 속으로 몰고 간다. 나 과장 파트의 파트원들은 매일 반복되는 야근에 휴일 근무까지 마다 안는다. 아무래도 나 과장은 파트원들을 수퍼맨 수퍼우먼들로 만들고 있는 듯 하다. 나 과장의 파트원들은 나 과장을 ‘직장의 신’이 아닌 ‘진작에 신’으로 만들어 버리고 싶어한다. 요컨대 신이 이승에 있는 것이 아니듯이, 신이 있는 곳으로 보내고 싶어 하는 것이다.



대출해 대리
잘나가은행의 대출팀 대리다. 이번 프로젝트를 위해 현업에서 파견된 직원으로 대출업무에 오랜 경험을 갖고 있으나, 전산에 대한 개념이 약한 직원이다. 어려운 상황에 봉착했을 때 위기를 약자에게 돌리는 얍삽한 성격의 소유자다. 낮은 책임감과 갑으로서의 권위주의적 성격으로 프로젝트 구성원들을 다양한 ‘기법’으로 힘들게 한다. 아마도 대출해 대리의 조상은 먼 나라 이웃나라에서 넘어온 것이 아닐까 의심이 되는 인사다.

단무지는 인천공항으로 향하고 있다. 이때 한 통의 전화가 걸려 온다. 한지아였다. 순간 단무지는 받아야 할지 말아야 할지 고민하다, 이네 전화를 받았다. 한지아: 무지 오빠, 뭐하고 계시나 한지아보다 단무지가 두 살 더 많다. 그래서 한지아는 단무지를 오빠라고 부른다. 단무지는 한지아가 불러주는 오빠소리가 참 듣기 좋았다.

단무지:
아~~ 누구 좀 만나려고 어딜 좀 가고 있어. 한지아:
누~~~구~~~ 단무지:
음~~ 친구. 친구가 멀리 유럽에서 온다고 해서 지금 운전해서 가고 있는 중이야. 한지아:
많이 친한 친구인가 보네 공항까지 마중 나가는 것 보면.
잘 다녀오시고 나중에 나도 소개시켜 줘야 해. 단무지:
어, 금방 다시 갈 거래. 지금 어디 한지아:
지금 고속도로 휴게소. 아빠가 졸립다고 엄마랑 운전 바꾼다고 휴게소 들어왔어.
1시간만 더 가면 할아버지 댁에 도착해. 다녀와서 전화할 게요.
일요일 저녁 잠시 시간 될 지도 몰라. 일찍 올라오면 전화 할게. 단무지:
그래, 잘 다녀오고. 올라와서 전화해

단무지는 한지아에게 왠지 죄를 짓는 것 같았다. 단무지는 ‘양다리 스타일’은 절대 못 된다. 하지만 아직 정지연의 상황도 파악되지 않았고, 정지연이 남는다고 무조건 지연과 계속 만날 것인지도 결정하지 않았다. 그래서 한지아에게 자세한 이야기를 하지 못 했으며, 전화로 할 이야기 또한 아니었다. 단무지 머리는 복잡했지만, 정지연을 다시 만난다는 들뜬 마음 또한 어쩔 수 없었다.

12시가 되고 드디어 정지연이 나오기를 기다리고 있었다. 많은 사람이 쏟아져 나온다. 그리고 이네 기다리고 기다렸던 정지연이 눈에 들어온다. 단무지는 다른 사람들은 안중에도 없다. 정지연은 후광이 비추고 있는 것 같았다. 지연은 3년 전보다 훨씬 세련된 듯 보였다. 그리고 지연도 바로 단무지를 알아보고 뛰듯이 달려왔다. 그리고 이내 곧 단무지 품으로 달려와 안겼다. 얼마나 기다렸던 순간이었던가 정지연은 눈가에 눈물이 촉촉히 젖었다.

정지연: 정말 많이 보고 싶었어(더 이상 말을 잇지 못한다).단무지: 나 역시 너무 보고 싶었어요. 하루도 당신을 생각하지 않은 날이 없었어요. 다시 가야 하는 건가

이네 정지연은 눈에 눈물을 닦으며, 살짝 미소를 지으며 이야기 한다.

정지연:
어쩌면 좋겠어요 다시 갔으면 좋겠어요 아님 계속 남아 있을까단무지:
하하. 무슨 얘기야. 하하 아버님 건강은 어떠하시고정지연:
많이 좋아 지셨어요. 이제 어머니가 혼자 돌봐 드려도 될 것 같다고
먼저 귀국하라고 해서요. 다시 안 나가도 될 것 같아. 머지 안아 부모님도 귀국하실 거예요.단무지:
아~~~ 다행이네. 그런데 지낼 곳은 있어 없으면 우리 집도 괜찮은데.정지연:
(실눈을 뜨고 살짝 째려본다) 으이그~~~ 응큼하게…. 단무지:
어~~~허 이 사람. 나는 아무 뜻 없이 선의로 이야기한 거야.
괜히 생사람 잡지 말라고 하하.정지연:
그리고 부모님 사시던 집 비워 달라고 이야기해 놨어요.
그리고 당분간은 이모네 집에서 지내면 되요.단무지: (그것 참 매우 아쉽네… 쩝？)정지연: 무슨 생각을 그리 심각하게 해단무지: 아~~ 아무것도 아니야. 하하

단무지와 정지연은 영종도를 드라이브하며 데이트를 했다. 정지연과 있으니 다른 생각은 전혀 들지 않았다. 그저 정지연과 있는 것이 좋았다. 정지연은 그동안 어떻게 지냈는지, 아버지 건강은 어떠한지, 유럽 생활은 어떤지 등등 쉬지도 않고 새가 노래하듯 계속 지저귄다. 단무지는 잠자코 정지연의 얼굴만 보고 있어도 좋았다. 그리고 늦은 밤, 지연의 이모님 댁에 바래다 준 뒤 집으로 돌아왔다.

WBS의 완성

프로젝트 관리에 있어 가장 중요한 것은 상세 계획서인 WBS(Work Breakdown Structure)와 WBS를 얼마나 잘 수행하고 있는지를 점검하는 시간이 주간회의다. 주간회의는 프로젝트의 대표적인 커뮤니케이션 방식이며, 이를 활용하여 진척도 점검, 리스크에 대한 보고(인지), PM은 이를 통해 인지하고 리스크에 대한 대처방안을 수립한다. 프로젝트 수행계획서가 PMI에서 정의한 SOW(Scope of Work)라면, WBS는 프로젝트에서 수행해야 하는 모든 타스크를 수행 일정과 함께 표기하는 상세 계획서다. 타스크는 80시간 단위로 구분하여 작성한다. 80시간이면 한 사람이 약 2주간 작업해야 하는 시간이다. 또한 6개월~12개월 정도의 프로젝트 규모라면 더욱 상세하게 프로그램 화면 목록별로 작성하기도 한다. PM과 PL은 WBS를 근거해서 프로젝트 진척도를 관리하는 것이 일반적이 방법론이다.

WBS는 수행계획서에 아주 개략적으로 작성이 되며, 이때는 마일스톤(Mile Stone)보다 약간 상세한 수준이다. 잠시 마일스톤에 대한 유래에 대해 이야기 해보자. 과거 미국에서 길 중간 중간에 표기된 목적지까지의 거리를 알려주는 돌에서 유래되었다. 프로젝트에서 마일스톤은 전체 프로젝트 일정 중 주요 꼭지점에 대한 기간을 표기하는 문서이다. 킥오프, 분석-설계-중간보고-개발-테스트(통합 테스트 및 인수 테스트)-적용-완료보고-안정화에 대한 개략적인 일정을 나타내는 것이 일반적이다.

설계단계가 모두 완료되면 화면정의서(개발해야 할 상세 화면에 대한 정의를 담은 문서)와 프로그램 목록 및 업무 기술서(개발해야 할 프로그램의 기능을 담은 문서), 프로그램 설계서(개발 대상인 상세 프로그램별 계획서) 등이 도출된다. 즉 설계 단계가 끝나야 우리가 개발해야 할 프로그램 상세 범위(대상)가 최종 확정되는 단계이다. 따라서 WBS의 완성은 범위가 완료되는 설계 단계 종료 시점이다.

단무지는 DB 산출물로 논리 및 물리 ERD(Entity Relationship Diagram), 테이블 목록, 테이블 정의서를 완료했으며, 홍두깨와 나허세는 각자 맡은 분야의 화면목록 및 정의서, 프로그램목록 및 프로그램 설계서를 모두 완료했다. 그리고 PM인 문희만 부장 주도로 프로젝트 중간보고까지 완료하였다.

개발 시작

개발 단계에서 가장 중요한 것은 단위 프로그램 개발이 하나씩 끝날 때마다 현업이 즉각적으로 확인하는 것이 가장 안전하다. 하지만 대출해는 하루 한 번 잠시 잠깐 프로젝트 사무실에 들러 개발이 완료된 화면을 수박 겉핥기 식으로 보는 것이 전부였다. 그것도 홍두깨가 귀찮을 정도로 대출해 대리에게 확인을 요청했기에 가능하였으며, 나허세 과장 파트는 그것마저 생략되었다.

홍두깨의 허송세월

홍두깨와 나허세의 일하는 방식은 전혀 달랐다. 일단 홍두깨는 개발을 하지 않는다. 주로 개발자들 사이에서 농담 따먹기나 하며, 허송세월을 보내는 것 같다. 어떨 때는 A개발자와 한창 떠들고 이야기하다, 또 어떨 때는 B개발자와 웃고 떠드는 식이다. 가까이 가서 듣지는 못했지만, 대화하는 개발자도 홍두깨도 웃는 얼굴로 이야기 하는 것을 보면 분명 농담 따먹기나 하고 있는 것 같았다. 매일 모든 개발자들 사이를 누비고 돌아다니는 것이 홍두깨의 하루 소일이다. 신선 노름이 따로 없다. 단무지 눈에는 신기하게만 보였다. 저렇게 놀기만 하다간 개발 막바지에 고생할 것 같았다. 심지어는 월급 도둑이 아닌가 하는 생각마저 들었다. 이뿐이 아니었다. 가끔은 일과시간에 개발자 한두 명을 데리고 인근 커피집에서 차 한잔씩 하고 들어올 때도 있었다.

업계에서 프로젝트 잘 하기로 소문이 자자한 홍두깨 이기에 단무지는 별 말없이 지켜 보고만 있었다. 또한 지켜보기만 할 뿐 지휘계통이 다르기에 단무지로서는 어쩔 수 없는 노릇이었다. 홍두깨 네 이놈! 나중에 산출물만 잘 못 나와 봐라. 그때는 그 동안 놀았던 대가를 치르게 하겠다고 단무지는 단단히 벼르고 있었다. 신선 놀음에 푹 빠져있는 홍두깨이건만 DB 문제만큼은 직접 챙겼다. 미처 설계단계에서 놓친 부분을 신규로 개발해야 할 경우는 신규 테이블 생성 또는 기존 테이블 변경이 필요하다. 이때는 개발자가 DBA인 단무지에게 변경 요청하지 않고 홍두깨가 직접 단무지와 상의하고 DB 수정 요청을 진행했다. 이럴 때 보면 홍두깨는 프로젝트 전체를 확 꽤 뚫어 보고 있는 것이 느껴졌다. 대단한 내공이다. 매일 놀기만 하면서 일의 진행은 정확하게 알고 있는 것이 아마도 홍두깨는 장판 깔고 점집을 차려도 돈을 많이 벌 것 같았다.

그리고 홍두깨의 특이한 점은 프로젝트 사무실로 안 오려 안간힘을 쓰는 대출해 대리를 집요할 정도로 오게 하는 것이다. 주제 영역별로 프로그램이 끝나면 반드시 대출해 대리에게 확인을 받는 식이다. 버티는 대출해 대리도 대단하지만, 물러서지 않고 요청하는 홍두깨의 집요함 또한 혀를 내두를 정도였다.

정신없이 바쁜 나허세

나허세는 본인도 다른 개발자와 함께 개발의 일부분을 맡아 직접 프로그램을 개발하였다. 그리고 대부분의 결정 사항은 개발자들에게 위임하였다. 프로그램 개발 진척도는 일주일에 한 번 개발자들에게 보고를 받는 방식으로 진행하고 있다. 신선놀음이나 하는 홍두깨와는 너무도 대조적인 방식이다. 정말 열심히 일한다. 심지어는 야근도 자주하고, 가끔은 주말에도 나와 프로그램 개발을 하곤 했다. 허당인 줄 알았는데, 나름 열심히 하는 사람이었다. 단무지는 자신이 나허세를 잘 못 본 것에 대해 미안한 마음까지 들었다.

주간회의

매주 주간회의는 금요일 오전 11시에 진행했다. 11시에 시작해야 정확히 1시간을 넘기지 않을 거라는 홍두깨의 농담 반 진담 반 던진 말에서 그렇게 하기로 했다. 12시가 되면 점심식사를 해야 하기 때문에 절대 1시간을 넘기지 않는다는 이야기였다. 또한 빠듯하게 1시간 내로 완료 해야 하기 때문에 11시에 정확히 시작할 수 있다는 것이다. 나름 일리 있는 주장이었다.

주간회의는 1. 금주 주요 실적 및 2. 다음 주 예정 사항 3. 프로젝트 전체 정량적인 진척도 4. 주요 의사결정 사항 5. 특이사항 6. 리스크 및 이슈 대응 방법 점검 순으로 진행한다. 1~3번은 금방 지나가지만, 항상 4번과 6번에서 시간을 많이 소모한다. 특히 발주사와 수주사의 의견이 엇갈릴 때는 시간이 빠듯할 때가 많았다. 특히나 프로젝트는 참여도 하지 않으며, 주간회의 시간에만 내려오는 대출해 대리가 말이 제일 많았다. 하는 것도 없으면서 요구사항은 왜 그리도 많은 것인지 좀 심하다 싶어 단무지가 가끔 제동을 거는 경우도 많았다.

프로젝트 품질관리

IT 프로젝트에서 가장 커다란 구멍을 메워 주는 것이 품질관리다. 메이저 프로젝트이든 작은 규모의 프로젝트이든 누구나 진척관리를 하는 것이 기본이다. 하지만 프로 PM과 아마추어 PM의 가장 커다란 차이점은 진척관리의 진실성을 보장하는 것이다. 즉, 개발자가 프로그램 외형만 만들어 놓고, 개발이 완료되었다고 보고하는 경우가 있다. PL과 PM은 이걸 확인하지 않고 그대로 믿고 진척관리를 했다가는 큰 코 다치기 십상이다. 실제 보고자료에는 진척율이 50%라고 적혀있지만, 정말 50%가 맞는지는 확인하지 않고는 알 수 없다. 이걸 정확하게 확인하는 것이 프로젝트 품질관리다. WBS 일정과 일치하게 진척되고 있는지, 산출물은 단계별 정확하게 지켜지고 있는지 관리하는 것이 매우 중요하다. 이걸 관리하는 것이 프로젝트 품질관리다. 메이저 IT 회사에서도 이 실수에 의해 프로젝트가 좌초되고 고객사 및 수행사에 많은 비용적 손실을 끼치곤 한다. 아마 실패한 프로젝트의 대부분이 프로젝트 품질관리를 실패한 경우이다.

홍두깨는 프로젝트 품질관리를 직접 챙기고 있다. 대규모 프로젝트라면 품질관리팀 내에품질관리 및 테스트 담당자가 있겠지만, 현재와 같은 6개월 규모의 프로젝트에서는 PL이 직접 하는 경우가 대부분이다. 홍두깨는 개발자가 개발이 완료되면 꼭 테스트라는 미명하에 제대로 화면이 구현되었는지, 화면에 있는 값이 DB의 정확한 데이터로 들어가는지를 반드시 확인하고 있다. 또한 개발이 완료되었을 경우 개발 방향성이 정확한지를 집요할 정도로 대출해에게 확인 요구를 하고 있는 것이다.

SQL 튜닝

단무지는 SQL 튜닝에 대한 고민이 생겼다. SQL 튜닝의 기본은 가장 많이 수행되는 SQL부터 튜닝해 나가는 것이 기본이다. 운영모드에서 가장 많이 수행되는 SQL 찾기란 식은죽 먹기보다 쉬웠다. v$sql view만 보면 단번에 알 수 있는 노릇이지만, 개발 중에는 난감하기 그지 없었다. 사용자가 사용하지 않고 있기에 어떤 SQL이 가장 많이 수행되는지 찾는 것이란 ‘낙타가 바늘구멍 들어가기’보다 어려운 노릇이었다. 할 수 없이 전체 SQL을 놓고 사전 예측하는 수밖에 없었다. 단무지는 주기적으로 v$sql을 별도 테이블에 축적하였다. 그리고 핵심 엔터티를 주로 사용하는 SQL 위주로 튜닝을 해 나갔다. 자주 사용되는 SQL인지 확신이 안 설 때는 개발자들에게 문의해 가는 식이었다. 그리고 개발자들에게 들어오는 튜닝 요청사항도 그때 그때 지체 없이 처리해 주었다.

파티션 테이블에 대한 SQL 사용의 주의

단무지는 사용량이 많고, 데이터 용량이 크고, 읽는 범위가 한정되었을 경우는 반드시 파티션 테이블로 구축하였다. DBA 입장에서 운영 및 관리하기는 편리하지만 SQL 구현은 까다롭다. 단무지는 파티션 테이블의 인덱스는 가급적 파티션별로 나뉘어 작성되는 로컬 인덱스로 구성하려 노력하였다. 이유는 파티션과 별도로, 그리고 한 통으로 구성된 인덱스를 글로벌 인덱스라 하는데, 이는 제약사항이 있다. 특정 파티션을 Truncate하였을 경우 또는 sql 로더로 데이터를 로딩하였을 경우, 글로벌 인덱스는 인덱스가 깨져 전체를 다시 리빌드해 줘야 하는 단점 때문이었다. 이 경우는 파티션테이블의 관리상 이점을 포기하는 것이기 때문이었다.

대신 로컬 인덱스로 구성했을 경우 SQL 작성에 주의해야 한다. 반드시 검색조건에 파티션 키를 포함시켜야 한다. 로컬 인덱스는 모든 파티션에 root-branch-leaf 형식으로 존재한다. 찾고자 하는 시작점을 찾기 위한 방식이 파티션별로 따로 구성되어 있다. 따라서 검색조건(Where 절)에 파티션 키 컬럼이 제외되었을 경우, 모든 파티션의 인덱스에서 root-branch-leaf 노드를 검색하는 비효율이 발생하게 된다. root 노드에서 leaf 노드 검색방식은 Random I/O로서 비용이 매우 높다. 이는 파티션 개수가 적을 때는 별반 차이가 없어 보이지만, 파티션 개수가 늘어난다면 SQL 속도 증가뿐 아니라 DBMS 부하에 치명적인 영향을 줄 수 있게 된다. 따라서 로컬 인덱스의 경우, 반드시 검색조건에 파티션 키를 포함시켜야 한다.

파티션관련 DBA의 흔한 실수

DBA들이 실수하기 가장 쉬운 것이 개발 완료 후 운영추이를 보고, 데이터가 커지면 파티션으로 바꾼다고 생각한다. 하지만 이는 로컬 인덱스를 사용할 수 없게 된다. 만약 로컬 인덱스로 바뀌는 순간 프로그램 내에 개발된 모든 SQL에 파티션 키 값을 검색조건에 추가해야 한다. 많은 프로그램을 일순간에 수정할 수 없으니, 글로벌 인덱스를 쓸 수밖에 에 없게 된다. 글로벌 인덱스는 위에서 이야기 한데로 DBA가 운영하기에 쉽지 않게 된다.

따라서 테이블 파티션에 대한 결정은 설계단계에서 테이블의 성향을 정확히 파악한 후 개발 이전에 결정해야 한다. 그리고 파티션 테이블로 결정되었을 경우, 개발자들에게 SQL 작성에 대한 충분한 가이드를 해서 검색조건에 파티션키가 포함되도록 해야 한다.

다음 편에서는 통합테스트 단계로 들어 갑니다. 프로젝트는 이 때부터 산으로 가게 됩니다. 대출해 대리가 나허세 과장의 파트에서 개발된 프로그램들을 전면 수정 요청을 하게 됩니다. 이제 프로젝트는 두 달밖에 남지 않았습니다. 문희만 부장과 단무지는 이를 어찌 헤쳐나가야 할까요 다음 편에 ‘통합 테스트’ 편으로 이어집니다. (다음 회에 계속)

출처 : 한국데이터베이스진흥원

제공 : 데이터 전문가 지식포털 DBguide.net