[시스템 운영 기록] 하드코딩 최소화를 위한 접근법

하드코딩..

어떤 서비스를 운영하는 사람이라면 한 번 쯤 들어봤을 용어입니다..

 

저는 대학생 때 하드코딩이란 용어를 못들어 봤는데,, (사실 못 들어보는 게 맞긴하죠,, 굳이 일찍 알 필요 없지,,)

취업하고 사용자 대상 서비스를 관리하면서 처음 듣게 되었습니다 🥱

사실 무슨 API KEY를 받아 놓는다든가 그런 것도 하드코딩이라 하니.. 알게 모르게 쓰고 있었네요,,

 

하드코딩을 나무위키에서 찾아보면 아래 처럼 정의되어 있더군요

데이터를 소스 코드 내부에 리터럴의 형태로 직접 입력하는 것

 

데이터가 DB가 아닌 서버 프로세스 소스 안에 있는 것을 의미한다고 이해했습니다 아하..

지금 상태론 진짜 하드코딩이 아닌 방식으로 굴러가는 게 더 힘들겠네..

 

이렇게 보면 좀 좋은(문제해결력이 높은!) 코딩 스타일 같은데,,

그쵸? ? 오! 좋은데?? 라는 생각이 들 수도 있지만,, (실제로 그때 그때 일처리엔 좋음)

 

하드코딩식으로 개발하다가는 100명의 고객이 있을 때 100+개의 해당 소스가 생길 수 있다는 이야기 입니다..

모듈형의 아키텍쳐와는 거리가 멀고 그렇게 됨에 따라,

진짜 소스가 무한정으로 길어지고 신규 정보의 입력/업데이트가 어려워진다는 단점이 있죠..

팀 작업에는 '더' 안 좋음

 

하지만 특수한 경우에는 하드코딩이 필요할 수도? 있긴 합니다..

어떤 케이스 하나 때문에 코드를 리펙토링하거나 테이블을 하나 더 팔 수는 없잖아요,,

그렇지만~ 하드코딩이 어떤 양상을 띄냐에 따라 유지보수의 효율성이 올라 갈 수 있기 때문에~

무자비한 하드코딩보다 좀 더 상냥한 하드코딩 방법을 찾을 필요가 있었다는 것입니다..

 

사건의 발단

어떤 고객사 한 곳에서 저희 프로그램을 사용하던 중에 연락이 왔습니다.

...

고객: ~~화면에서는 ~~의 적용이 필요해요~

본인: 그런 데이터는 저희가 몰라요 ㅎㅎ

고객: 그래도 필요해요~

...

 

이렇게 저희 DB에 없는 정보를 반영해달라는 요청이 올 때가 있습니다.

이럴 때 방법은 크게 3가지로 나뉠 수가 있는데,,

1. 데이터를 정기적으로 고객사에서 수신받는 파이프라인을 구축한다.

2. 사용자(고객)가 직접 데이터를 입력할 수 있는 인터페이스를 만든다.

3. 요청 받고 직접 소스에 하드코딩한다.

 

사실 1, 2가 베스트인데,, 당장 적용되어야 하는 데이터라고 거기서 쪼으면

(거기도 빨리 3번으로 적용 해달라고 하긴함 ㅋ)

어쩔 수가 없죠..

원하진 않지만 검토를 해서 하드코딩 작업을 진행하도록 팀장님이 말씀하시더군요,,

 

근데 문제는.. 하드코딩이 필요한 부분이 20개가 넘어가는데,,

이게 또 띄엄띄엄 있어서 상당히 피로한 작업이라는 것입니다..

앞으로 이러한 작업이 얼마나 지속될지 몰라 유지보수할 업무 담당자를 위해

하드코딩 파트를 1~2개로 줄이는 방법을 찾는 것,, 그게 이번 작업의 핵심 목표가 되었습니다!

 

경과 - 초단기 프로젝트 견적 내기

거창한 서론에 비해,, 사실 과정은 그렇게 어렵지도 길지도 않았고

아래 2가지에 대한 선행 조사를 물꼬로 이 소규모 소스 수정작업이 이루어졌습니다 . . .

- 해당 서비스의 로직 흐름
- 해당 서비스의 시스템적, 비즈니스적 조건

 

지금 회사에서는 아래 3가지의 형태로 로직 대부분 진행되고 있는데,

해당 기능을 개발하신 분은 첫번째 것을 선택하신 것 같았습니다..

3개 다 그렇게 가독성이나 유지보수가 쉽지는 않은 코딩 스타일이긴한데,

첫번째는 코드가 길어지면 길어질 수록 더더욱 쉽지 않기에,,

(사실 수정사항을 반영해서 리팩토링을 그때 그때 안해주면 다음 번에 수정할 일이 있을 때 그냥 힘들어요ㅠㅠ)

 

다음으로 해당 서비스에 주어진 소프트웨어적 기술 외의 조건을 살펴보면

1. 하드코딩이 온 요청사가 한 곳

2. 해당 회사에서 요청한 업무를 보는 사람은 한 명

3. 타겟 데이터가 전날 배치작업으로 생성된 테이블을 조회함

4. 언제 파기가 필요한 소스코드일지 미지수(파기 가능성 높음!! 우리 회사가 취급할 생각이 없는 데이터니..)

 

즉, 생각보다 마이너한 요청인데,, 신규 고객이라 좀 둥가둥가할 필요가 있어서,,

일단 너무 무리한 요구가 아니면 최대한 받아줘야 했습니다..

(살짝 간 좀 보라길래 실제로 간 봤다가.. 고객 나갈 뻔해서 달래줄 필요가 있는 상황 😐)

 

경과 - 견적을 기반으로 설계

※ 개인적으로 이런 하드코딩 방식은 매우매우 지양해야한다고 생각합니다!!!!!!!!!

시스템 운영에 크리티컬한 부분이 아닌 것을 고려해,  아래 3가지 기법(잡기술)을 적용하기로 했습니다..

1. 해당 서비스+고객을 대상으로한 임시테이블을 생성하기

2. 그 임시 테이블에 개별 프로세스가 돌아가는 동안 (테이블 조회의 경우를 제외) 락(FINE GRAINED가 아닌 전체)을 걸기

3. 배치로 생성된 원본 데이터를 임시테이블에 백업 받아두고 원본 데이터 중 고객사가 지정한 일부 데이터를 하드코딩으로 지운 뒤에 프로세스 말단에서 백업에서 불러 오기

 

대충 아래처럼 구성 되게 프로세스 초입 + 마지막에 함수로 빼서 처리해주었습니다..

일단~

저희 시스템 코딩 컨벤션이,

따로 명시적인 DB COMMIT 명령어가 없으면,

프로세스가 끝난 다음에 공통 함수 쪽에서 COMMIT 처리를 해서,

이런저런 조건을 고려해 봤을 때,

확실히 트랜잭션의 ACID가 보장되기에,

이런 선택을 하게 되었습니다.. 후,, 문장 길다..

 

사실 이런 건 치팅이에요;; 진짜 테스트 단에서나 해야되는 거고,,

운영계에서 적용을 위해 다른 아키텍쳐를 적용해서 리팩토링을 해야죠,,

 

근데 어차피 저렇게 제안을 해서 초안을 들고 가도,

"어 좋은데~ 이런 건 나중에 인력 여유있을 때 하자~"

라는 말을 들었기에,, 무차별 하드코딩에 착수할 수밖에 없었습니다..

 

경과 - 소스코드 수정, 테스트 및 배포

운영계 반영으로 넘기는 데까지 따로 큰 어려움은 없었습니다..

그냥 걱정 2가지가 있었죠

1. 얘네 말고 다른 고객이 비슷한 요청을 보내면 어떡하지;; (업력을 봤을 때 없을 것 같긴해요)

2. 내가 모르는 버그(테스트 중에 못 발견한 버그)가 있음 어떡하지;;

 

근데 그건 그때 가서 생각해도 돼요,,

크리티컬과 거리는 먼 업무이고

소급수정도 가능하고

원본 데이터 생성 배치가 엄연히 잘 살아 있으니,,

 

그래서 저런 걱정을 않기 위해 ! ! ! 하드코딩을 안해도 되도록 하기 위해 ! ! !

제가 담당하는 시스템의 아키텍쳐를 재구성해야되는 거에요.. (누가 언제 승인해주고 누가 진행하는것인가..)

 

근데 테이블 락 명시적으로 걸어본 것은 이번이 처음인데 좀 신기하긴 하네요,,

이렇게 RACE CONDITION 해결하면서 다른 프로세스 최적화해보는 것도 재밌을 듯?

 

마치며

가끔 레거시들을 짓밟으며 트렌디한(또는 하다고 생각되는) 코드 스타일로 소스를 수정할 때,,

이런 생각이 들고는 합니다..

혹시 이거 나만 알아보는 코드가 아닌가..
레거시에 익숙하고 익숙해질 예정인 사람들을 내가 너무 배려하지 않은 것은 아닌가 ㅠㅠ

정답은 뭘까요.. 궁금하네요..

이래서 좀 기술 관련한 토론회라든지 교류회라든지 있으면 좋을 것 같은데

(회식 중에 지나가는 이야기로 가끔 하는데 자리가 자리인지라,, 건설적으로 이루어지고 마무리되지 않죠,,)

살짝 아쉽긴하네요 . . .

 

슬슬 기술적인 성장에 정체가 오는 느낌인데,

(회사에 기대지 않고!!) 스스로 돌파구를 찾아봐야할 시점인 것 같습니다..

 

맞는 말이에요.. 언제까지 떠먹여주길 바랄거니;