금융 회사에서 일하는 개발자는 어떤 일을 할까 : 쿼리 잘못 짰다가 문의 폭탄 맞은 썰 푼다

오늘은 문제가 되지 않을 정도의 선에서 데이터와 테이블, 내용을 각색한 실무 썰을 한번 풀어볼까 한다.
 
[타겟 독자]

• ORACLE GROUP BY / DISTINCT 실제 쓰임새가 궁금하다.
• 백단에서 조회 ORACLE 쿼리를 짜고 유지/보수하는 실무 사례가 궁금하다.
• 금융회사에서 일하는 개발자가 하는 일이 궁금하다.
• 고기만두가 무슨 뻘짓을 하고 다녔길래 연이틀 야근을 하고 이 글을 쓰게 되었는지 궁금하다

[이 글을 쓰고 있는 고기만두는]
금융회사에서 일하고 있는 개발자이며, 직급은 대리.
마냥 주니어라고 말하긴 이제 좀;;
금전과 관련된 내부 프로덕트 시스템을 다루고 있으며,
(백-프론트 다 얕고 넓게 보고 있지만 백단에 더 방점이 찍혀있는 업무긴 하다.
그래서 백엔드 빌리지 소속.)
매일 완벽한 개발자 포스를 자랑하고 싶지만 아직도 가끔 정신놓고 뻘짓거리도 하고 그런다.
그리고 주니어 시절부터 실수를 하고 작아지고 심약해질때마다

그래서 만두 대리가 테이블을 TRUNCATE해서 복구가 안돼?
회사에 막 수 조 원대 복구불능 손실을 끼쳐서 사람들이 회사 로비에 식칼을 들고 찾아왔나요?

와 같은... 소리를 들으며 강하게 자라났다.

728x90

(사실 본인 포함 우리팀 절대다수가 대문자 T)

 
*양심고백.
제목에서 어그로를 끌긴 했지만 대고객 접점에 바로 엮인 팀이 아니고서야,
전화폭탄을 직접적으로 맞는 일은 보통 많지 않다.
더군다나 나의 경우 내부 프로덕트이다보니 사실 문의전화 폭탄..까지는 아니다.
대신 현장의 VOC를 모으고, 실제 운영 정책 방향을 기획하는 담당자 분들이
문의를 나름대로 정제해서 전달해주시는 경우가 더 많긴 하다.
하지만 시스템이 사용 못할 정도로 뻗어버리면..
그 때는 내 전화기와 메신저 역시도 불이 나고 내가 이미 내 윗선에 불려가서 잔소리 한번 듣고 오겠지.

---

[테이블]
인적공제 대상자를 입력하는 FAMILY 테이블과, 기부 내역을 입력하는 DONATION 테이블을 만들었고
이에 샘플 데이터를 집어넣었다.
 

테이블 정의서

*데이터와 테이블을 그대로 구현하면 업무 기밀 누설이 될 것 같으므로,
데이터는 임의의 샘플 데이터 몇 건을 집어 넣었고,
오늘 글에 필요하지 않은 기타 다른 칼럼은 삭제 및 수정하여 필요한 부분만 남겨 가상의 테이블을 생성하였다.

개인PC에 ORACLE SQL DEVELOPER 와 SCOTT 계정 이 있었어서 여기서 예시 데이터를 만들어보았다.
CREATE문이랑 INSERT문 직접 치기 귀찮았는데 긁어만 올 수 있도록 대신 짜 준 따봉 chatGPT야 고마워!

인적공제 테이블 FAMILY

기부금공제 테이블 DONATION

[문제 상황 1]
매년 연말정산 입력 시즌은 1주일 남짓이지만,
이 때 전사 직원들과 담당 스탭부서 사람들이 다 달라붙어 단기적으로 폭발적인 양의 S/U/I/D가 발생한다.
그리고 올해 들어온 VOC 중
'인적공제 대상자가 전년도와 같은 경우, 직접 하나씩 입력이 아닌,
버튼 한 번만 눌러서 기존 데이터를 그대로 불러오고 싶어요.'
라는 내용이 있었다.
그런데, 기능을 만들고 보니 중복입력을 시도해도 제어가 되지 않는 문제가 발생하였다.
 
(주)김치만두최고 에 다니는 사원 김영희 씨 (사번 : 23456472)가 있다.
작년에는 아버지 김개동 씨만 인적공제대상자로 올려놔서,
신기능 버튼을 보고 흡족한 마음으로 작년에도 대상자였던 아버지를 먼저 입력하고
다음 어머니 이영자 씨를 추가로 올해 입력하였다.
그리고 오 이거 괜찮다 하고 버튼을 한 번 더 눌렀는데,
아버지 김개동 씨가 일련번호 하나 더 추가되어 바로 들어가 버렸다.
그리고 삭제를 까먹은거다.

반응형

김영희 씨의 부양가족 모두 기부 내역이 있어,
기부금 영수증을 받아서 입력을 했는데, 한 가지 문제가 생겼다.
아버지가 기부한 건 1건인데, 아까의 중복입력이 해결되지 않아 똑같은 기부건이 2건이 떠버렸다.
이 VOC내용을 전달받고 쿼리를 분석하였다.

SELECT T1.* , T2.HUMN_DCT_RLT, T2.DCT_TRGM_NM
FROM DONATION T1 LEFT OUTER JOIN FAMILY T2
ON 1=1
AND T1.DNMN_RRNO = T2.FMY_RRNO
WHERE 1=1
AND T1.YEAR = '2023'
AND T1.ORMM_NO = '23456472'
ORDER BY T1.DNTN_TYP, T1.CBPS_DCMT_NO, T1.DNTN_DT;

 
기부자의 이름을 표시하기 위해 DONATION 테이블에 LEFT OUTER JOIN 을 사용하여
FAMILY 테이블의 기부자명 칼럼을 붙였는데 이렇게 조인하면 중복이 발라지지 않는다.
 
아! 그럼 중복되지 않도록 주민번호를 각각 구분되는 하나씩만 불러와볼까?
GROUP BY와 DISTINCT문을 사용하였다.

SELECT T1.* ,T2.FMY_RRNO, T2.HUMN_DCT_RLT, T2.DCT_TRGM_NM
FROM DONATION T1 LEFT OUTER JOIN 
(SELECT DISTINCT(FMY_RRNO) AS FMY_RRNO, HUMN_DCT_RLT, DCT_TRGM_NM 
FROM FAMILY
GROUP BY FMY_RRNO, HUMN_DCT_RLT, DCT_TRGM_NM) T2
ON 1=1
AND T1.DNMN_RRNO = T2.FMY_RRNO
WHERE 1=1
AND T1.YEAR = '2023'
AND T1.ORMM_NO = '23456472'
ORDER BY T1.DNTN_TYP, T1.CBPS_DCMT_NO, T1.DNTN_DT;

아버지 김개동 씨 한 줄만 나왔다.
문제를 해결하였다...
 
[문제 상황 2]
그런데 또 전화가 왔다.
홍길동 씨 (사번 : 12345678) 는 기부금이 한 건 입력하면 두 줄씩 보인다고 한다.

예???????????? 다른사람들은 다 멀쩡한데 왜 쟤만 저래?

그런데 자세히 보니 기부건이 두 건씩 뜨는 와중에 홍길순이 눈에 띈다.
저 사람 홍길동이라며? 다른 부양가족도 없던데? ...

연도를 지워서 FAMILY 테이블을 조회해보니 2019년의 홍길순이 눈에 띈다.
아, 개명하셨쎄요?
개명한 사람의 개명전의 이월기부금이 그대로 넘어오며 홍길순으로 보이고 있다.
LEFT OUTER JOIN으로 붙인 T2부분을 분석해보자.
 

주민번호를 DISTINCT 하려던 시도는 좋았다.
그런데 GROUP BY에 기부자의 이름 (DCT_TRGM_NM) 이 들어간다.
그러면 이름까지 조건에 포함하여 GROUP BY를 묶을 테니,
당연히 같은 주민번호 940101-2222222 의 홍길동과 홍길순 2개가 나올 수밖에 없다.
그리고 YEAR 은 모두 2023으로 같다보니 GROUP BY 로 묶을 수가 없었다.
그러면 다른 방향을 모색해봐야한다.
아까 문제 1, 이번의 문제 2, 그리고 멀쩡한 다른 건들을 모두 만족시킬 방향.
GROUP BY 문제에 매몰되지 않으면서, 문제를 풀어낼 다른 방법은 없을까?

SELECT T1.* ,T2.FMY_RRNO, T2.HUMN_DCT_RLT, T2.DCT_TRGM_NM
FROM DONATION T1 LEFT OUTER JOIN  FAMILY T2
ON 1=1
AND T1.ORMM_NO = T2.ORMM_NO
AND T1.DNMN_RRNO = T2.FMY_RRNO
AND SUBSTR(T1.DNTN_DT, 0, 4) = T2.YEAR
WHERE 1=1
AND T1.YEAR = '2023'
AND T1.ORMM_NO = '12345678'
ORDER BY T1.DNTN_TYP, T1.CBPS_DCMT_NO, T1.DNTN_DT;

 
간명하게 그냥 FAMILY 를 DONATION에 LEFT OUTER JOIN 하면서, 조인 조건에 없던 연도와 사번을 추가하였다.
말은 간명하게 라고 하지만 이 간명한 결론을 내기 위한 고민의 과정이 꽤 길었다.

중복 문제를 해결했는데, 홍길순이 조금 거슬리지만 ..
홍길순이 개명전 이름이라는 건 담당자한테 잘 설명하면 될 일이다.

하지만 문제1이 재발하였다.
이 부분은 쿼리로 더이상 수정할 수 없는 부분이라고 판단하였고, 중복입력된 데이터를 삭제하기로 했다.
(어차피 아르바이트 학생들이 붙어서 검증하며 삭제 및 수정을 통한 데이터 클렌징을 진행하는 절차를 거치기는 한다.
하지만 그 전에 없던 기능이었고, 그런 사례가 그간 없었을 뿐이다.)
그리고 중복 입력시 제어 기능을 새로 개발 하는 쪽으로 백엔드 수정을 통해 문제를 해결하기로 하였다.
애초의 설계 단계에서 중복을 간과한 탓이 크다.
설령 기획이 안된다고 해도 멱살 잡고 끌고 갔어야 하는 문제였다.
다시 이런 실수 반복하지 않기 위한 기록.

---

COOKIE.

담대해지자.
나도 그렇지만, 놀랍게도 나보다 더더 시니어 분들도 가끔 실수를 하긴 한다.
경력이 쌓일수록 비상 상황 발생시 최대한 신속정확하게 해결 방법을 찾고 복구하는 데에 담대해지고
시치미 뚝 떼는 노하우가 생기는 거 아닐까.