향식이의 군침 싹 도는 개발일기

HR Insight 2026년 1월호를 읽으며

향식이 — Fri, 16 Jan 2026 10:59:26 +0900

이제 HR은 더 잇아 사람을 '관리'하는 조직이 아니라,
일, 역할, 관계, 몰입을 '설계'하는 조직이 되어야 한다.

"얼마나 뽑을까?" 라는 질문이 더 이상 와닿지 않았던 이유

채용 업무를 하다 보면 자주 듣는 질문은 늘 비슷합니다.

이번 분기 몇 명 채용해야 하나요?
이 포지션 꼭 필요한가요?
TO를 줄여야 할까요?

그러나 실제 현장에서 느끼는 문제는 '사람 수'보다 '일의 구조'였습니다.

어떤 팀은 늘 바쁘고, 어떤 역할은 명확하지 않으며, 어떤 업무는 "원래 이렇게 해왔어요"라는 말로만 유지됩니다.

HR Insight에서 말하는 직무(Job)가 아닌 일, 업무, 스킬 단위의 재설계는 이론적으로 새로워 보일 수 있지만

사실 현장에서 이미 필요하다고 느끼는 방식이었습니다.

즉, 사람이 부족한 게 아니라 일이 제대로 정의되지 않았던 경우가 훨씬 많았습니다.

채용이 어려운 진짜 이유는 '사람' 아니라 '기준'이다.

2026년 1월호에서 채용 트렌드는 "많이 뽑는 채용의 종료, Fit 중심 채용의 강화"라고 말합니다.

이 문장을 읽으면서 분명 채용 공고는 열려 있고 지원자도 많은데 적합한 사람이 없다는 말이 반복되던 경험이 떠올랐습니다.

그 때 종종 이렇게 생각했습니다.

"정말 사람이 없는 걸까, 아니면 우리가 원하는 사람이 무엇인지 설명하지 못 하고 있는 걸까?"

Fit은 결국 조직이 스스로 얼마나 잘 이해하고 있는지에 대한 질문입니다.

우리 조직은 어떤 방식으로 일하는가
이 역할에서 정말 중요한 역량은 무엇인가
성과를 내는 사람들은 어떤 공통점을 갖고 있는가

이 질문에 답하지 못 한 상태에서의 채용은 결국 운에 가까워집니다.

AI 시대에서 HR 중심은 '사람'이다

AI 이야기가 빠지지 않는 시대지만, 이번 HR Insight에서는 오히려 이렇게 말합니다.

AI는 사람을 줄이는 도구가 아니라,
사람이 더 가치 있는 일에 집중하게 만드는 수단이다.

이 문장을 읽으며 HR이 기술을 대하는 태도 역시 바뀌어야 한다는 생각이 들었습니다.

AI를 도입할 것인가 말 것인가가 아닌, 어떤 일은 사람이 해야 하고, 어떤 일은 기술이 맡아야 하는지 기준을 세우는 역할이어야 합니다.

그 기준을 세울 수 있는 조직이 결국 기술 변화 속에서도 흔들리지 않는다는 메세지가 이번 호에 주 내용이었습니다.

2026년의 HR은 정답을 아는 사람이 아니라 더 나은 질문을 던질 수 있는 사람이 되어야 한다는 생각이 들었습니다.

그리고 그 질문은 트렌드에서가 아니라 현장에서 느낀 불편함과 경험에서 시작된다고 생각합니다.

리더는 AI 시대를 어떻게 이끌어야 하는가

향식이 — Tue, 13 Jan 2026 17:29:52 +0900

오늘은 BCG코리아에 게재된 "AI 에이전트 기업의 부상: 리더는 AI 시대를 어떻게 이끌어야 하는가"를 읽어보았습니다.

도구를 도입하는 게 아니라 동료를 들이는 시대

요즘 AI 이야기를 하면 대부분 이렇게 시작합니다.

"업무 자동화가 빨라질 것이다." "생산성이 올라갈 것이다."

그런데 이 글을 읽고 난 뒤 드는 생각은, AI 에이전트는 더 이상 사람이 쓰는 도구에 머무르지 않는다.

스스로 계획하고 실행하고 학습하며, 실제 팀원처럼 프로세스 안에서 움직입니다.

그리고 설문 응답자의 76%가 AI 에이전트를 도구보다 동료에 가깝다고 본다고 합니다.

우리는 지금 '기술'을 도입하는 걸까, 아니면 조직 안에 '새로운 행위자'를 채용하는 걸까?

이 질문은 조금 불편하게 들립니다.

그 이유는, 도구라면 구매와 관리의 문제인데 동료라면 역할, 권한, 책임, 평가, 학습의 문제로 바뀌기 때문입니다.

AI 에이전트가 흔드는 건 '업무'가 아닌 '매니지먼트'

BCG에서 AI 에이전트는 '기술 트렌드'가 아닌 매니지먼트 프레임워크를 무너뜨리는 존재로 정의합니다.

과거에는 자동화 vs 지원이나 도구 vs 일하는 주체와 같이 선택지가 단순했습니다.

그러나, AI 에이전트는 그 중간을 차지합니다.

도구처럼 확장되면서 동시에 사람처럼 적응하고 학습합니다.

그래서 조직은 하나의 시스템을 '자산 관리' 관점과 '인사 관리' 관점으로 동시에 다뤄야 합니다.

IT는 예측 가능성과 확장성을 원하고,

CFO는 투자수익과 회계 프레임을 원하며,

HR은 성과관리, 감동, 윤리를 원합니다.

사업부는 효율도 적응도 둘 다 원합니다.

이 상충을 실행 문제로 보면 계속 삐걱거리게 되는데요,

BCG는 이러한 문제를 전략적 필수 과제라고 말합니다.

AI 에이전트를 잘 관리하는 능력 자체가 조직의 차별화가 되는 것입니다.

리더가 마주할 4가지 딜레마

BCG는 AI 에이전트가 촉발하는 긴장 관계를 4가지로 정리합니다.

리더는 무엇을 결정해야 하고, HR은 무엇을 설계해야 하는가?

1. 확장성 vs 적응성

AI는 표준화된 환경에서 강하지만 표준화가 지나치면 예외 대응/학습 능력을 제한할 수 있습니다.

HR 질문

우리는 업무를 어디까지 표준화 할 것인가?
예외 상황(장애/리스크 등)은 누가 처리하도록 설계할 것인가?
'AI가 잘하는 일'과 '사람이 반드시 해야 할 일'의 경계는 정의가 되었는가?

2. 경험 vs 신속성

AI 투자는 도구처럼 감가상각되는 동시에, 사람처럼 학습하며 가치가 커지기도 합니다.

HR질문

우리는 AI를 '비용 절감'에 둘 것인가, '역량 확장/학습'에 둘 것인가?
사람의 성장 투자와 AI 학습 투자는 하나의 포트폴리오로 보고 있는가?
리스킬링 예산은 지속 재투자로 설계되어 있는가?

3. 감독 vs 자율성

완전 통제도, 완전 자동화도 아닙니다.

리스크 수준에 따라 human-in-the-loop / human-out-of-the-loop를 함께 설계해야 합니다.

HR 질문

어떤 업무는 사람 검토가 필수인가?
어떤 업무는 자율성을 허용할 수 있는가?
AI의 실수는 “결함”인가, “학습의 기회”인가? 우리 조직은 실패를 공유할 문화가 있는가?
가드레일(보안/프라이버시/컴플라이언스)과 책임소재를 문서화했는가?

4. 부분 도입 vs 전면 재설계

HR 질문

AI를 ‘업무 최적화’로만 쓰고 있지 않은가?
어느 시점부터 “부분 개선”을 “프로세스 재설계” 논의로 전환할지 기준이 있는가?
변화관리의 범위를 프로젝트가 아니라 운영모델 수준으로 보고 있는가?

AI 에이전트 시대의 HR은 무엇을 해야 할까

AI 에이전트는 기술의 문제가 아닌 조직의 문제라고 생각합니다.

1) 역할을 다시 쪼개고, 직무를 재정의해야 합니다.

“어느 단계를 자동화할까?”가 아니라 “프로세스 자체를 어떻게 다시 설계할까?”로 질문이 바뀝니다.

HR은 JD 업데이트 수준이 아니라 업무 흐름, 권한 구조, 책임 체계를 포함한 설계를 해야 합니다.

2) 하이브리드 팀 리더십이 필요합니다.

앞으로 관리자는 사람만 관리하지 않을 것입니다. 사람 + AI 에이전트로 구성된 팀을 오케스트레이션해야 합니다.

이때 필요한 역량은 통제나 보고가 아닌 예외 상황 판단/윤리적 감독/협업 설계 같은 리더십입니다.

3) AI 에이전트에도 "생애주기 관리"가 필요합니다.

가장 인상 깊었던 개념 중 하나는 AI 에이전트를 온보딩-교육-평가-재교육-퇴직까지 관리해야 한다는 관점입니다.

즉, HR이 사람에게 해온 것을 AI 에이전트에도 일부 적용해야 합니다.

신규 에이전트 테스트/검증(온보딩)
정확성/편향/적응성 추적(성과평가)
모델 드리프트 대응(재교육/리스킬링)
단계적 전환/폐기(퇴역)

이걸 누가 맡을 것인가? 조직은 이제 정말로 AI 인사 기능을 고민해야 합니다.

월간 인사관리 2026년 1월호를 읽으며

향식이 — Mon, 12 Jan 2026 18:29:04 +0900

월간 인사관리 2026년 1월호 中 2026 노무환경 변화와 노사관계 대응 전략 (이슈 정리 x)

정년연장, 노동시간 단축, 노란봉투법, 임금체계 개편, ...

HR이 뒤로 물러설 수 없는 영역이라는 메세지가 강하게 느껴졌습니다.

2026년은 HR의 시험대

정년연장, 노동시간, 노사관계는 더 이상 '미룰 수 있는 논의'가 아닙니다.

그동안 많은 기업들은 이렇게 대응해왔습니다.

"아직 법이 확정된 건 아니니까 분위기 좀더 봐보자, 우리 회사는 아직 해당 안 될 수도 있다"

하지만 2026년은 HR이 선택을 미룰 수 없는 해입니다.

HR이 아무 말도 하지 않는 동안, 현업과 구성원들은 이미 불안해하고 있습니다.

노사관계의 핵심은 '대립'이 아닌 '설계'

2026년 노사관계를 '갈등의 심화'가 아닌 새로운 규칙을 만드는 과정으로 설명합니다.

노동환경은 분명 달라지고 있습니다.

고령 인력이 늘고, 젊은 세대는 조직에 오래 머무르지 않으며, 노동에 대한 기대와 기준은 세대별로 극명하게 갈립니다.

이 상황에서 노사관계를 '누가 더 양보하느냐'의 문제로만 다룬다면 HR은 계속 소모적인 역할에 머무를 수 밖에 없습니다.

"침묵은 더 이상 HR 전략이 아니다"

HR은 언제 침묵을 선택해왔을까요?

혹시 중립이라는 이름으로 판단을 유예해온 건 아닐까요?

구성원이 불안해할 때, HR은 충분히 설명하고 있었을까요?

HR이 말하지 않으면 그 공백은 소문, 오해, 불신이 채웁니다.

1월호에서 HR의 역할은 노사 관계 중재자가 아닌, 대화가 가능하도록 구조를 만드는 설계자로 정의합니다.

이 관점은 HR의 부담을 줄이기보다 오히려 책임의 무게를 분명히 하는 말처럼 느껴졌습니다.

노동존중 시대, 기업이 살아남기 위해 HR이 해야 할 일

노동존중은 더 이상 가치 선언이 아니라 기업의 생존 조건이 되어가고 있습니다.

1월호에서는 노동존중을 '기업이 도덕적으로 지켜야 할 태도'가 아니라 경쟁력을 유지하기 위한 전제 조건으로 설명합니다.

이유는 명확합니다.

노동시장이 빠르게 재편되고 있음
인재는 점점 더 조직을 선택하는 주체가 되고 있음
불합리한 제도와 경험을 빠르게 공유됨

이제 구성원은 이 회사가 성장하는가?를 판단하기 이전에 "이 회사에서 나의 노동이 존중받는가"를 먼저 묻습니다.

그리고 이 질문에 답하지 못 하는 조직은 채용, 유지, 몰입에서도 어려움을 겪게 될 것입니다.

또한, 노동존중을 이야기하면 HR을 구성원의 편, 보호자로만 인식하는 경우가 많습니다.

하지만 HR은 어느 한 쪽을 보호하는 존재가 아니라 노동이 존중받을 수 밖에 없는 구조를 설계하는 역할에 가깝습니다.

감정적 배려, 선언적 메세지, 이벤트성 캠페인이 아닌 제도, 기준, 일관성, 그리고 설명 가능한 구조 입니다.

노무 이슈를 다루다 보면 HR의 역할이 법 준수에 머무는 경우가 많습니다.

법에 걸리지 않는지 문제가 생기면 어떻게 대응할지 생각합니다.

"법을 지키는 것만으로 구성원의 이 조직을 신뢰할 수 있는가?"

노동존중 시대의 HR은 '법의 최소선'위에 '조직만의 기준'을 세워야 하는 역할입니다.

우리가 왜 이 기준을 선택했는지, 회사의 방향성과 어떻게 연결되는지 설명이 가능할 때 제도는 통제가 아니라 신뢰의 도구가 됩니다.

노동존중은 사람을 편하게 만드는 제도가 아니라 조직이 오래 유지되기 위한 조건이라는 생각이 듭니다.

앞으로 HR로서 노동을 비용이 아니라 구조로 바라보고 갈등을 회피하지 않고 설계하고 싶습니다.

노동존중을 이상이 아니라 현실적인 HR의 과제로 다시 보게 만든 1월호 노동존중 칼럼이었습니다.

2026년 노동 정책 (new)

향식이 — Fri, 9 Jan 2026 11:59:15 +0900

오늘은 2026년을 맞아 바뀌는 노동 정책을 간략히 정리해보았습니다.

근로자의 실질 소득과 일, 생활 균형에 직접적인 영향을 주는 정책들이 시행되면서

근로자와 기업 모두가 알아두어야 할 내용들이 많아졌습니다.

최저임금 인상

2026년부터 최저임금이 시간당 10,320원으로 인상됩니다.

이는 2025년 최저임금(10,030원) 대비 2.9% 오른 금액입니다.

주 40시간, 월 209시간 근무 기준으로 보면

월 환산액은 약 215만 6,880원으로 기존 209만 원대에서 약 6만원 이상 증가하게 됩니다.

최저임금 인상은 단순히 시급에만 영향을 주는 것이 아닌

구직급여, 출산휴가 급여 등 각종 고용보험 급여의 기준 금액도 함께 상승하게 됩니다.

구직급여 인상

최저임금이 오르면서 실업급여 하한액과 상한액도 함께 조정됩니다.

구직급여 상한액: 1일 6만 6천 원 → 6만 8,100원
월 최소 실업급여(30일 기준): 약 192만 원 → 198만 원
월 상한액: 198만 원 → 204만 3천 원

*구직급여 상한액 인상은 2019년 이후 처음입니다.

출산휴가 급여 인상

출산 전, 후 휴가를 사용하는 근로자에게 지급되는 출산휴가 급여도 인상됩니다.

출산휴가 급여 상한액: 월 210만 원 → 220만 원
하한액: 최저임금 인상에 따라 약 215만 원 수준으로 상향

*이미 출산휴가 급여를 받고 있는 경우에도 2026년부터 인상된 기준이 적용됩니다.

주 4.5일제 도입 기업 정부 지원금 지급

2026년 1월부터 주 4.5일제 도입한 중소기업을 대상으로 정부 지원이 시작됩니다.

직원 1인당 월 최대 60만 원 지원
주 4.5일제 도입과 함께 신규 채용 시 신규 인력은 월 80만 원까지 지원

정부는 이를 위해 시범사업을 먼저 운영할 계획입니다.

이는 장시간 노동 구조를 개선하고, 생산성과 삶의 질을 함께 높이기 위한 제도적 실험이라는 점에 주목할 수 있습니다.

노동시간 단축을 위한 중장기 방향성

정부는 2030년까지 우리나라 평균 노동시간을 OECD 평균 이하로 낮추는 것을 목표로 하고 있습니다.

주 4.5일제 추진은 이러한 방향성을 보여주는 대표적인 정책 중 하나입니다.

앞으로는 근무시간의 양 보다는 성과와 효율을 중시하는 노동환경으로 점차 변화해갈 가능성이 크다고 생각합니다.

2026년 노동정책 변화의 핵심 키워드는 소득 보전, 일/생활 균형, 노동의 가치 재정의라고 생각합니다.

근로자에게는 생활 안정과 선택권 확대의 기회가 주어지고, 기업에는 새로운 제도에 적응하고 활용해야 할 과제가 주어졌습니다.

혹시 잘못된 정보나 빠진 내용이 있다면 말씀 부탁드립니다 :)

참고 자료

고용노동부 보도자료 : https://www.moel.go.kr/news/enews/report/enewsView.do?news_seq=18808

고용노동부

고용노동부 국민 누구나 원하는 일자리에서 마음껏 역량을 발휘하는 나라!

www.moel.go.kr

한경비즈니스 : https://magazine.hankyung.com/business/article/202512314946b

최저임금 오르고 노동절로 바뀐다…새해부터 달라지는 노동정책

최저임금 오르고 노동절로 바뀐다…새해부터 달라지는 노동정책, 배현의 기자, 출산휴가

magazine.hankyung.com

세이프티퍼스트닷뉴스 : https://www.safety1st.news/news/articleView.html?idxno=7591

월간 인사관리 2025년 12월호를 읽으며

향식이 — Thu, 8 Jan 2026 10:32:05 +0900

인사 업무를 하다 보면 '성과관리'라는 단어를 하루에도 몇 번씩 마주치게 됩니다.

평가 시즌이 되면 더 그렇습니다.

기준, 등급, 피드백, 보상, 형평성 ... 하지만 정작 마음속에 남는 질문은 늘 비슷합니다.

"이 제도가 정말 사람을 성장시키고 있을까?"

이번 2025년 12월호에서, 성과관리는 줄 세우기가 아니라 '성장 관라'여야 한다는 메세지입니다.

성과관리는 왜 늘 불편한 제도가 될까

잡지에 실린 여러 기업 사례와 전문가 글을 읽으면서 가장 공감됐던 문장은 아래와 같습니다.

성과관리는 숫자를 매기는 절차를 넘어,
조직과 구성원의 성장을 이끄는 수단이 되어야 한다.

(CJ올리브네트웍스 인턴할 때 느꼈지만 성과관리-성장관리를 어떻게 할 것인가에 대해 매우 깊은 고민을 하고 있었다.)

실무에서 성과관리는 늘 예민한 영역입니다.

평가 기준은 설명할수록 질문은 늘어나고, 투명성을 강조할수록 불만도 함께 커집니다.

그런데 잡지를 읽으며, 문제는 제도의 정교함이 아니라 '어떤 성과를 원하는가'에 대한 합의 부족이라는 점을 깨달았습니다.

우리는 어떤 행동을 성과라고 부르고 있는지
결과만 보는지, 과정도 보고 있는지
개인의 성과와 조직의 성장은 연결되어 있는지

이 질문에 답하지 않은 채 평가 방식만 바꾸고 있는 건 아닐까요.

연말 평가표 대신 연중 대화

이번 호에는 연말 평가를 줄이고, 상시 피드백과 대화를 강화한 기업 사례가 여러 소개되었습니다.

평가 결과를 전달하는 자리에서 구성원은 이렇게 말하기 쉽습니다.

"이 얘기를 왜 이제서야 하는 거죠?"

성과관리에서 가장 큰 아쉬움은 결과보다 타이밍이라는 생각이 들었습니다.

이미 끝난 일에 대한 평가보다 진행 중인 일에 대한 방향 제시가

훨씬 큰 의미를 가진다고 생각합니다.

성과는 제도가 아니라 '습관'이다

아무리 제도를 정교하게 설계해도 피드백이 일상화되지 않고, 상사가 대화를 회피하고, 실패가 학습으로 연결되지 않으면

성과관리는 결국 형식적인 절차로 남습니다.

그래서 성과관리의 본질은 평가표가 아니라 일하는 방식이라는 말이 설득력있게 다가왔습니다.

AI, 리더십, 그리고 HR 역할

잡지를 읽고 나서 느낀 점은, 기술과 제도가 바뀌어도 결국 HR의 중심은 '사람'이라는 점입니다.

AI는 평가를 대체하는 도구가 아니라 더 자주, 더 나은 피드백을 가능하게 하는 수단이어야 하고,

리더십은 통제보다 코칭으로 변화하고 있으며,

인재 확보보다 인재 유지와 성장에 더 많은 에너지가 필요해지고 있습니다.

이 변화 속에서 HR의 역할은 더 분명해집니다.

운영자가 아닌, 일의 구조와 경험을 설계하는 사람.

우리는 어떤 성과를 만들고 싶은가
그 성과가 사람의 성장과 연결되어 있는가

앞으로 성과관리를 이야기 할 때, 저는 숫자보다 질문을 먼저 꺼내고 싶습니다.

이 일의 의미는 무엇이었는지
다음에는 무엇을 더 잘 할 수 있을지
이 사람이 성장하고 있다는 신호는 무엇인지

HR이란

향식이 — Tue, 6 Jan 2026 11:34:05 +0900

HR이란 무엇일까요,

한국의 직장인 비율은 70%에 달합니다.

70%를 차지하는 직장인들이 다니는 직장의 산업, 규모, 형태는 다 다를지라도 하나의 공통점을 찾자면 HR이 존재한다는 점입니다.

그만큼 HR은 기업이 존재하기 위해 반드시 필요한 필수조건이라고 할 수 있습니다.

인터넷에서 HR의 정의를 찾아보면 다음과 같이 설명합니다.

기업이나 조직의 인적 자원(사람)을 관리하는 부서 또는 그 활동을 의미하며, 인재 채용, 교육, 보상, 복지, 노무, 조직 문화 관리 등 직원의 채용부터 퇴사까지 전반적인 생애 주기를 책임지는 핵심적인 역할을 한다.

즉, HR은 채용부터 퇴사까지 전반적인 생애 주기를 책임지는 역할이며,

흔히 말하는 EX(Employee eXperience), 직원 경험을 관리하는 영역이라고 볼 수 있습니다.

그렇다면 정해진 절차에 따라 사람을 채용하고 평가하고 보상하기만 하면 되는 걸까요?

이전에는 가능했습니다.

조직의 환경이 비교적 안정적이었고, 산업의 변화 속도가 지금보다 훨씬 느렸을 때에는

정해진 규정과 프로세스를 잘 지키는 것만으로도 HR은 충분히 역할을 수행할 수 있었습니다.

하지만 지금은 상황이 완전히 달라졌습니다.

비즈니스 환경은 빠르게 변하고 있고, 산업 간 경계는 허물어지고 있으며 AI 발전은 조직의 일하는 방식 자체를 바꾸고 있습니다.

이러한 환경 속에서 HR이 여전히 관리 중심의 역할에 머문다면 조직의 성장을 뒷받침하기 어렵습니다.

그래서 HR은 더 이상 '관리 부서'가 아닙니다.

조직의 경쟁력은 결국 사람과, 그 사람을 어떻게 확보하고 성장시키며 몰입하게 만드는지에 의해 결정되기 때문입니다.

HR은 경영 전략을 이해하고,
그 전략이 조직 안에서 실제로 실행될 수 있도록 조직원과 조직의 구조를 설계하는 역할을 수행합니다.

전략과 현장을 연결하고, 비즈니스 방향을 사람과 조직의 언어로 풀어내는 역할, 바로 비즈니스 파트너로서의 HR입니다.

저는 HR을 단순히 제도를 운영하는 직무로 바라보지 않습니다.

비즈니스의 맥락을 이해하고, 조직의 문제를 사람과 구조의 관점에서 해석하며, 지속 가능한 성장을 가능하게 만드는 전략적 파트너라고 생각합니다.

그래서 앞으로 저는 경영진과 현업 리더가 신뢰하고 함께 고민할 수 있는 비즈니스 파트너로서의 인사담당자가 되고 싶습니다.

이 글은 그 출발점으로,

HR이 무엇인지, 그리고 앞으로 HR이 나아가야 할 방향에 대해 스스로 정리해보는 첫 번째 기록입니다.

[Tech-review] 라인 이커머스 플랫폼의 주문 DB 마이그레이션 경험기

향식이 — Tue, 12 Mar 2024 18:18:50 +0900

기술 블로그 출처

https://techblog.lycorp.co.jp/ko/experience-in-migrating-order-db-on-ecommerce-platform

이커머스 플랫폼의 주문 DB 마이그레이션 경험기

들어가며 안녕하세요. LINE Plus에서 Global E-Commerce Platform 개발을 맡고 있는 서종현입니다. 저희 팀은 작년에 주문 DB를 Oracle에서 MySQL...

techblog.lycorp.co.jp

DB 모델 재정의

DB 이관 전에 MySQL에서 사용할 DB 모델을 재정의한 이유는 기존 Oracle 모델에서 조회 성능이 나오지 않았기 때문이다. 주문 데이터 조회 시 17개의 테이블을 조인해야 했으며, 이로 인해 부하가 발생하여 주문당 최대 5초 이상 소요되었다. 새로운 DB 모델을 정의할 때 주된 관심사는 조인을 줄이는 것이다. 이를 해결하기 위한 방법으로 일부 테이블을 JSON 문자열로 저장해 역정규화하는 안과, 두번째로 정규화 테이블과 비정규화 테이블 두 쌍을 운용하는 방법이다.

JSON 문자열로 저장하여 역정규화 진행
- One-to-Many 관계가 많아 컬럼으로 역정규화하기 어려웠고, 따라서 JSON Object 또는 JSON Array로 역정규화하는 아이디어 제안
- JPA를 사용하므로 코드 작성에 큰 어려움은 없지만, JSON 문자열로 저장한 필드를 검색해야 할 경우 테이블 구조를 다시 변경해야 함
검색용 모델과 조회용 모델을 분리하여 운용
- 단점: 2개의 모델을 관리해야 하므로 코드 양과 DB에 저장되는 데이터 양이 늘어남
- 장점: 검색이 유연하고 조회 성능이 뛰어남

1번 방법이 2번 방법보다 읽기, 쓰기 성능이 떨어졌기 때문에 2번 방법을 선택했다. 성능을 테스트할 때 JPA의 Batch Insert를 사용했음에도 불구하고, 데이터가 더 많은 두 번째 안이 더 느린 것으로 나타났다. Pinpoint 등을 사용하여 원인을 분석한 결과, JPA의 변경 감지와 Jackson의 특성 때문인 것으로 확인됐다.

Jackson 호출 횟수: 1번 방법에서 예상보다 많은 Jackson 호출이 있었는데, 이는 JPA가 AttributeConverter를 사용하는 엔티티를 저장할 때 변경을 감지하기 위해 항상 직렬화와 역직렬화를 호출하기 때문이다.
Jackson 호출 소요 시간: 두 방법 모두 Jackson 호출 성능에는 거의 차이가 없었습니다. 이에 따라 큰 객체를 작은 객체로 나눠 여러 번 직렬화하는 첫 번째 안보다 큰 객체로 한 번만 직렬화하는 두 번째 안이 더 좋은 성능을 보여줬다.

따라서, Jackson 호출 횟수 및 수행 시간의 영향으로 두번째 방법이 더 좋은 성능을 보여줬기 때문에 정규화 테이블과 비정규화 테이블 두 쌍을 운용하는 두 번째 안을 선택했다.

퍼시스턴스 레이어 개발

테이블 운용 방법을 결정한 후 퍼시스턴스 레이어를 개발하는 데에는 두 가지 주요 문제가 있었다. 첫째는 JPA를 사용할 때 데이터를 업데이트하려면 먼저 데이터를 읽어와야 한다는 점으로, 이는 정규화 테이블에 대량의 조인을 발생시킬 수 있다는 것이었다. 둘째는 정규화 테이블과 비정규화 테이블 간의 일관성이 깨질 수 있다는 것이었다.

해결 방법

명세 객체 사용: 서비스 레이어와 퍼시스턴스 레이어 간에 도메인 객체 대신 별도의 명세 객체를 사용하여 통신하도록 설계했다. 명세 객체는 업데이트에 필요한 정보만을 갖고 있어서 퍼시스턴스 레이어가 정규화된 테이블 전체를 읽어오지 않고도 작업을 수행할 수 있다.
애그리게이션 활용: 정규화 테이블에 대응하는 JPA 엔티티의 연관 관계를 데이터가 변경되는 단위로 쪼개어 애그리게이션을 만들었다. 이를 통해 항상 페치 조인으로 데이터를 읽어와 N+1 쿼리 문제를 방지하고 부분적인 데이터 업데이트를 가능하게 했다.
도메인 객체 생성과 명세 반영의 분리: 퍼시스턴스 레이어 안에서는 명세를 받고 이를 정규화 테이블을 통해 반영하고, 도메인 객체는 비정규화 테이블을 통해 생성하도록 설계했다. 이를 통해 두 테이블 간의 일관성을 유지하고 코드 일관성을 확보했다.

이러한 방법을 통해 대량의 조인을 방지, 두 테이블 간의 일관성 유지, 퍼시스턴스 레이어의 효율성 향상을 달성했다.

동시성 이슈

주문 프로세스에서 각 상품을 독립적이고 순차적으로 처리하던 중, 주문 전체를 JSON 문자열로 저장하는 과정에서 발생한 동시성 이슈로 인해 데이터 정합성 문제가 발생했다. 정규화 테이블은 부분적으로 업데이트가 가능하여 문제가 없으나, 비정규화 테이블에는 새로운 JSON 문자열로 치환되는 방식으로 저장되어 서로의 변경 사항을 인식하지 못하면서 데이터가 손실되었다.

비정형 데이터 구조를 사용하는 경험이 부족한 저희 팀이 처음 겪은 데이터 정합성 문제를 해결하기 위해 Redis를 이용한 분산 락을 도입했다. 하지만 분산 락과 코드 구조 간의 불일치로 인해 재진입 문제가 발생했다. 이를 해결하기 위해 Spring의 Transactional과 유사한 인터페이스를 락에 적용하여 재진입을 허용하는 분산 락을 구현했다. 이로써 비슷한 문제에 대응할 수 있는 유연한 분산 락을 만들었고, 결과적으로 문제를 해결하는 데 도움이 됐다.

배포

배포 단계

신규 모델 검증: 비동기 방식으로 MySQL에 데이터를 적재하고 검증
이중 쓰기: 동기 방식으로 Oracle과 MySQL에 데이터를 적재하며, 마이그레이션과 비즈니스 프로세스 간 충돌 방지
MySQL로 읽기 전환: MySQL에도 실시간으로 최신 데이터가 저장되어 MySQL로 읽기를 전환하고 이중 쓰기 로직 제거
Oracle 수정 제거: 수정 단계부터 Oracle를 제거하여 배포 호환성 보장
쓰기에서 Oracle 제거: Oracle 의존성을 완전히 제거하여 MySQL만으로 운용

[Tech-review] 쏘카 데이터 디스커버리 플랫폼 도입기

향식이 — Mon, 4 Mar 2024 18:29:58 +0900

회사는 점점 데이터가 많아질수록 데이터의 위치와 의미를 한눈에 보고자하는 니즈가 생길 것이다. 쏘카에서도 데이터가 어디에 있고, 이 데이터는 무슨 의미인지에 대한 의미를 한눈에 보고자 했고, 이를 위한 플랫폼을 데이터 디스커버리 플랫폼(Data Discovery Platform)이라고 한다. 오늘은 데이터 디스커버리의 개념과 왜 디스커버리 플랫폼이 필요한지, 그리고 쏘카는 어떤 기준으로 디스커버리 플랫폼을 선택했는지 알아보자.

기술 블로그 출처

https://tech.socarcorp.kr/data/2022/02/25/data-discovery-platform-01.html

데이터 디스커버리 플랫폼 도입기 - 1편. 데이터 디스커버리란?(feat. Datahub VS Amundsen 비교 분석)

Datahub 도입기

tech.socarcorp.kr

데이터 디스커버리

데이터 디스커버리는 데이터를 쉽고 빠르게 찾을 수 있는 개념으로, 빅데이터 시대에는 많은 양의 데이터가 다양한 형태로 존재하게 됨에 따라 중요해졌다. 데이터 디스커버리는 데이터 이용자에게 어디에, 어떤 데이터가, 어떻게 존재하는지에 대한 정보를 제공한다. 메타데이터는 테이블 정보, 컬럼 정보, 코멘트, 데이터 오너 등을 포함하며, 이를 잘 관리하는 것이 데이터 디스커버리의 핵심 역할이다.

데이터 디스커버리의 중요성

직원들이 각자의 목적에 맞는 데이터를 찾고 의미를 파악하는 데 소요되는 시간을 줄여, 업무 진행 속도와 효율성을 높일 수 있다. 이에 데이터를 적극적으로 활용하는 기업은 데이터 디스커버리를 통해 업무 효율성을 크게 향상시킬 수 있다.

데이터 디스커버리 플랫폼의 종류

Datahub: LinkedIn에서 만든 플랫폼으로, 데이터 디스커버리를 위한 도구
- 데이터를 쉽게 찾고 이해할 수 있도록 돕는 것이 목적이다.
- 메타데이터를 중심으로 데이터의 신뢰성과 가치를 높이는 데 초점을 맞추고 있다.
Amundsen: Lyft에서 개발한 플랫폼으로, 데이터 디스커버리와 데이터 카탈로그를 위한 오픈 소스 도구
- 사용자가 데이터 자산을 쉽게 찾고 이해할 수 있도록 돕는다.
- 사용량 추적, 검색 기능, 품질 측정 등 다양한 기능을 제공한다.
Databook: Uber에서 개발한 인하우스 플랫폼으로, 기업 내부의 데이터 디스커버리와 데이터 공유를 위한 도구
- 데이터를 검색하고 분석하는 기능을 제공한다.
- 데이터 소스의 신뢰성과 유효성을 확인할 수 있는 기능을 포함한다.

데이터 디스커버리 플랫폼이 필요한 이유

도입 효과 - Data Discovery의 관점

쏘카에서는 데이터 활용을 위해 다양한 직군이 데이터를 사용하고 있으나, 데이터 형식의 다양성과 개발 지식 부족으로 데이터 접근이 어려웠다. 기존의 스키마 관리는 유지보수가 되지 않아 정보 부족 문제가 있었고, 질문은 슬랙 채널을 통해 해결되었으나 효율성이 떨어졌다. 이를 해결하고자 데이터 디스커버리 플랫폼을 도입했고, 비개발 직군도 간편한 UI를 통해 메타데이터를 확인할 수 있어 데이터 이해도와 업무 효율성이 향상되었다.

도입 효과 - Data Governance의 관점

여러 사람이 데이터를 생산하고 소비할수록 데이터 거버넌스의 관점이 중요하다. 데이터 디스커버리 플랫폼을 도입하면 기존에 흩어져서 관리되던 테이블 스키마, 코멘트가 중앙 관리 될 수 있다.

* 데이터 거버넌스: 조직 내에서 데이터를 관리, 유지, 보호하기 위한 일련의 정책, 규정, 프로세스, 역할 및 책임을 포함하는 프레임워크이다. 주요 목표는 데이터를 신뢰할 수 있고 효과적으로 활용할 수 있도록 보장하는 것이다.

데이터 디스커버리 플랫폼 비교 분석

쏘카에서는 Datahub와 Amundsen 플랫폼을 비교했다. 두 플랫폼을 직접 배포하고 테스트하면서 비교하는 PoC과정을 거치면서 진행했다.

구조

두 플랫폼의 공통점

React 기반 Frontend
Elasticsearch 기반 Search Engine
Neo4j 기반 Graph DB
MySql 기반 Storage

두 플랫폼의 차이점

Datahub
- 데이터 넣을 때 Kafka를 사용
- Event-based 방식 사용
Amundsen
- 데이터 넣을 때 ETL 라이브러리를 통한 크롤링 방식을 사용
- Monolith 방식 사용

메타데이터 주입 방식

Datahub
- Yaml 파일을 실행하여 메타데이터 주입
- 데이터 소스에 따라 Datahub 라이브러리에 따라오는 연결 플러그인을 설치
Amundsen
- python 파일을 실행하여 메타데이터 주입
- python 라이브러리인 amundsen-databuilder를 사용하여 ETL 프레임워크를 구현
- 이를 통해 ETL 각 과정에서 여러 자체 모듈을 사용
- 종종 여러 Dependency 필요
- 섬세한 커스텀이 가능하나 스크립트가 길어 읽기 무거움

문서 기능

Datahub
- 테이블 별/컬럼 별 태그 부여 가능
- 테이블 별/컬럼 별 풍부한 마크다운 문서 작성이 가능하고, 원본 소스의 Description 보존
Amundsen
- 테이블 별 태그 부여 가능
- 역시 테이블 별/컬럼 별 마크다운 제한적인 문서 작성이 가능하고, 원본 소스의 Description을 보존하지 않음

오너십

Datahub
- 테이블에 유저/그룹 단위로 오너십 지정 가능
Amundsen
- 테이블에 유저 단위로만 오너십 지정 가능

인증 및 권한

Datahub는 SSO 지원 및 세부적인 권한 설정 가능
- SSO(Single Sing-On)로 Keycloak, Okta, Google Auth 지원
- 사용자/그룹 단위로 정책 부여가 가능
  - 현재는 View 관련 권한은 설정이 불가능하나, 테이블이나 컬럼에 대한 설명, 오너, 태그 등을 수정할 수 있는 Edit 권한을 세부적으로 조정 가능
Amundsen은 SSO을 지원 및 세부적인 권한 설정 불가능
- SSO 로 Keycloack, Okta, Flask_oidc 지원
- Amundsen은 자체적인 권한 설정을 지원 불가능

데이터 소스 지원

두 플랫폼 모두 BigQuery, Mysql, dbt, AWS S3 등 대중적으로 쓰이는 데이터 소스를 지원한다. 이에 추가로, Amundsen은 pandas, neo4j 등의 더 다양한 형태를 지원한다.

서포트

공식 Github Repository 의 Star 수를 비교했을 때, Datahub가 4.5K, Amundsen이 3K 로 Datahub 가 더 많은 Star를 보유하고 있다. 또한 두 플랫폼 모두 공식 슬랙, 웹사이트 등 다양한 채널을 지원하나 활성화 측면에서 Datahub가 좀더 우세하다.

최종 결정: Datahub

가장 결정적인 이유는 사용성 차이였다. 데이터 이용자 측면에서는 Datahub가 다양하고 풍부한 기능을 제공하여 데이터를 빠르게 찾고 쏘카의 데이터 디스커버리를 발전시키는 데 도움이 되었다. 또한, 플랫폼 개발자 측면에서도 Datahub가 메타데이터 주입이 더 편리하고 간단하여 유용할 것이라고 판단했다. Amundsen의 Python Script가 길고 복잡한 반면, Datahub는 간단한 yaml 파일로 메타데이터를 주입할 수 있어서 효율적이었다.

PoC 시 Datahub의 깔끔한 UI가 많은 호응을 얻었고, 매 버전마다 UI가 개선되고 있어서 Datahub를 선택했다.

Datahub의 공식 슬랙 채널은 현재 2,000명이 넘는 사용자가 활동하고 있으며, 다양한 주제별 채널에서 질문과 오류 대응이 활발하게 이루어지고 있다. 또한, 새로운 기능을 제안하는 채널도 따로 있어서 사용자의 피드백을 적극적으로 반영하고 있다. 최근 발생한 Log4j 취약점 사태에도 신속하게 대응하여 패치가 반영되었으며, 모든 진행 상황이 슬랙을 통해 공유되고 있습니다. 사용자의 질문에 대한 답변이 빠르게 이루어지는 것으로 보아, 데이터 디스커버리에 관련된 국내 자료가 부족한 상황에서 신입 엔지니어들에게는 매우 중요한 서포트 시스템이라고 생각된다.

[Tech-review] 딜라이트룸 ETL vs ELT

향식이 — Mon, 26 Feb 2024 21:34:23 +0900

오늘은 딜라이트룸 기술 블로그에서 작성한 'ELT vs ETL'에 대해 리뷰해보고자 한다. 딜라이트룸은 알라미라는 글로벌 알람앱을 운영하고 있는 회사로, 누적 다운로드가 7,500만이 넘고 상위 알람앱 중 평점 1위를 기록하는 등 다양한 기록을 가지고 있다. 나도 아침을 잘 활용하기 위해 이 어플을 사용해 본 적이 있는데 단순히 알람 기능만 있는 것이 아닌 질 높은 수면을 위한 기능들이 있어 유용했다. 역시 이렇게 퀄리티 있는 어플을 만들고 유지하기 위해서는 수준 높은 전문가들이 있어야 하는 거 같다. 딜라이트룸에서는 기술블로그를 운영하고 있고 글도 꾸준히 올라온다. 이 중 데이터 엔지니어로서 이목을 사로잡은 ETL vs ELT에 대해 알아보자.

기술 블로그 출처

https://medium.com/delightroom/etl-vs-elt-%EB%8B%B9%EC%8B%A0%EC%9D%98-%EC%84%A0%ED%83%9D%EC%9D%80-3d55ee4c5192

ETL vs ELT, 당신의 선택은?

ELT의 장단점과 딜라이트룸에서의 도입 후기

medium.com

ETL

ETL은 Extract(추출), Transform(변환), Load(적재)의 3가지 단계로 구성된다.

Extract(추출): ETL의 첫 번째 단계로, 원본 데이터 소스에서 필요한 데이터를 추출하는 과정이다. 데이터는 다양한 소스에서 추출될 수 있는데, 이는 관계형 데이터베이스, 텍스트 파일, 웹 API, 클라우드 서비스 등 다양한 형태 일 수 있다.
Transform(변환): 추출된 데이터는 다양한 형식과 구조를 가질 수 있으며, 이를 목표 스키마에 맞게 변환해야 한다. 이 과정에서 데이터의 정제, 필터링, 집계, 조인 등의 작업이 수행된다. 또한 데이터의 품질을 개선하기 위해 누락된 값의 처리, 중복 제거, 오류 수정 등의 작업이 포함될 수 있다.
Load(적재): 변환된 데이터는 목적지로 적재되어야 한다. 이 단계에서는 데이터를 데이터 웨어하우스, 데이터 레이크, 데이터 마트 등의 저장소에 적재하게 된다. 적재는 주기적으로 이루어지는 배치 작업일 수 있고, 실시간으로 데이터를 전달하는 프로세스 일 수 있다.

여기서 중요한 단계는 Transform(변환) 단계이다. ETL은 데이터를 가공한 후 목적지에 저장하기 때문에 우리가 필요한 데이터만을 선택적으로 저장하고, 저장소를 효율적으로 활용하기 위한 과정이다.

ETL 장점

효율적인 저장 공간 사용: 꼭 필요한 데이터만 저장소에 쌓이게 되므로 효율적으로 저장 공간을 사용할 수 있다.
보안과 규정 준수: 변환 과정에서 민감한 정보를 제거하거나 GDPR, HIPAA 등 다양한 규정에 맞추기 용이하다.
검증된 기술: ETL 역사가 오래 됐기 때문에 관련 지식이나 도구가 많다.

역시 각 장점들이 데이터의 품질과 안정성을 유지하는 데 필수적이라서 오래도록 ETL이 사용되어 온 거 같다.

ETL 단점

까다로운 유지보수: 데이터의 종류와 양이 늘어나면 유지보수 하기 어려워진다.
높은 변환 단계 운용 비용: 대량의 데이터를 처리하기 위해서는 변환 단계에서 상당한 컴퓨팅 자원이 필요하다.
낮은 유연성: 변환 단계에서 데이터의 최종 형태가 정해져 있기 때문에 다른 형태의 데이터가 필요할 땐 대응하기 어렵다.

ELT

ELT는 데이터 웨어하우스나 데이터 레이크와 같은 중앙 집중식 데이터 저장소에 데이터를 처리하는 방법이다. ELT는 ETL과 유사하지만 데이터 변환 단계를 적재한 후에 수행하는 점에서 차이가 있다.

Extract(추출): 원본 데이터 소스에서 필요한 데이터를 추출한다. 이 단계에서는 원본 데이터 베이스, 파일 시스템, 클라우드 스토리지 등 다양한 소스에서 데이터를 추출한다.
Load(적재): 추출한 데이터를 중앙 집중식 데이터 저장소로 로드한다. 추출된 데이터를 변환하거나 전처리하지 않고 그대로 저장소로 이동한다. 이는 주로 클라우드 기반의 저장소를 활용한다.
Transform(변환): 데이터가 저장소에 로드된 이후에 변환 작업을 수행한다. 데이터를 필요한 형식으로 변환하거나 정제하고, 분석이나 보고를 위한 추가적인 계산이 수행된다.

ELT 장점

간단한 시스템 구성: 데이터 변환 작업은 데이터 웨어하우스에서 진행되기 때문에 컴퓨팅 자원 관리가 좀 더 수월하다.
높은 유연성: 원본 데이터를 보유하고 있어 필요할 때 언제든지 재가공이 가능하다.
적재 외주화: 원본 데이터를 적재 해두고 변환만 내부적으로 진행하므로 적재 과정을 외부에 맡기기 용이하다. 특히 다양한 소스의 데이터를 받아오는 경우 적재 부분을 직접 구현하지 않아 비용을 아낄 수 있다.

ELT 단점

보안과 규정 준수: 원본 데이터를 모두 적재하기 때문에 보안에 굉장히 유의해야 한다.
비효율적인 저장 공간 사용: 꼭 필요한 데이터보다 더 많은 데이터를 적재해 두고 사용하므로 저장 공간을 더 많이 사용하게 된다.

딜라이트룸에서 ELT를 도입한 이유

딜라이트룸은 ETL방식을 사용하다가 변환 레이어의 복잡성과 운영 비용이 증가하는 문제를 경험했다. 이를 해결하기 위해 ELT 방식을 도입하여 데이터를 먼저 적재하고 필요에 따라 데이터를 처리하는 방식으로 전황했다. 이로써 관리해야 할 요소가 줄어들고, 데이터 모델링에 있어서도 더 많은 유연성을 얻을 수 있었다. 개발자의 자원을 효율적으로 활용하기 위해 EL 파트를 외주화 하고, Fivetran과 같은 서비스를 통해 안정적으로 데이터를 적재했다. 데이터를 모두 받아두었기 때문에 데이터 웨어하우스 내에서 변환할 수 있어 저장 공간에 비용을 절약하고 개발 비용과 운영 복잡도를 감소시키는 효과를 얻었다.

* Fivetran: 클라우드 기반의 데이터 통합 플랫폼으로, 다양한 데이터 소스로부터 데이터를 추출하여 데이터 웨어하우스나 데이터베이스로 신속하고 안정적으로 전송하는 서비스를 제공한다. 이를 통해 사용자는 ETL 프로세스를 간소화하고 데이터를 효율적으로 관리할 수 있다. Fivetran은 사용자가 설정한 주기에 따라 데이터를 자동으로 동기화하고, 데이터의 변환 및 정제 작업을 지원하여 데이터 분석 및 시각화에 필요한 정형화된 데이터를 제공한다.

후기

ETL과 ELT의 장단점이 뚜렷하기 때문에 각 회사 상황에 맞는 방법을 도입해야 하는 거 같다. 딜라이트룸은 저장 공간에 비용을 더 들이는 대신, 개발 비용과 운영 복잡도를 감소시키고 유연성을 얻는 일석삼조의 효과로 ELT 방식으로의 전환을 선호했다. 흥미로웠던 점은 EL 파트를 외주화 한다는 점이다. 내가 다녔던 회사나 다른 동료들 얘기를 들었을 땐 주로 사내 엔지니어나 인턴을 고용해 직접 추출했는데 딜라이트 룸은 개발자의 자원을 아끼고자 외주화 한다고 한다. ELT 방식에서는 단순히 추출하고 적재하는 EL파트에 개발자의 시간을 쓰지 않도록 하는 것이 인상 깊고 엔지니어의 가치를 생각해 주는 거 같아 너무 호감 가는 부분이다.

[Tech-review] 직방 Mysql 인덱스 튜닝

향식이 — Fri, 23 Feb 2024 13:41:44 +0900

데이터 엔지니어로서 효율적인 DB관리는 매우 중요하다. 이 중 인덱스 튜닝을 해서 DB 성능을 높이고자 하는데 직방에서도 이와 같이 SQL의 비효율을 제거하는 고민을 가졌다. 인덱스는 테이블의 특정 열에 대한 검색 및 정렬 속도를 향상시키는 데 사용된다. 따라서 인덱스 튜닝은 DB 성능을 향상시키는 중요한 역할이므로 어떻게 해결해나갔는지 알아보자.

기술 블로그 출처

https://medium.com/zigbang/mysql-%EC%9D%B8%EB%8D%B1%EC%8A%A4-%ED%8A%9C%EB%8B%9D-18e183e9246d

MYSQL 인덱스 튜닝

안녕하세요. 호갱노노BE팀 폴 입니다.

medium.com

SQL 튜닝 개요

SQL 튜닝은 동일한 쿼리 결과를 더 빠르고 더 효율적으로 얻기 위한 모든 작업을 의미한다. 이는 CPU 시간이나 Black I/O등과 같은 성능 지표를 통해 평가된다. 즉, 동일한 결과를 얻는 데 DBMS가 사용한 자원이 얼마나 적은지가 성능 좋은 쿼리의 기준이 된다.

SQL 튜닝의 주요 포인트로는 인덱스 튜닝, 조인 튜닝, 소트 튜닝, DML 튜닝 등이 있다. 이 중 인덱스 튜닝에 대해 다뤄보도록 한다.

인덱스 튜닝 세부 분류

인덱스를 타지 않는 경우
1. 인덱스가 없을 때
  - 인덱스 생성
2. 인덱스가 있을 때
  - 인덱스 컬럼 가공으로 인한 성능저하 여부 확인
  - 인덱스 손익분기점 확인 (테이블 풀스캔이 더 효율적인지 확인)
인덱스를 타는 경우
1. 인덱스 스캔 비효율 (인덱스 스캔량이 최종 rows보다 훨씬 많을 때)
  - 인덱스 필터링으로 동작하는 인덱스 스캔 개선
2. 인덱스 스캔 비효율은 없지만, 테이블 엑세스가 많을 때
  - 인덱스만 읽고 멈추도록 개선
불필요한/중복인 인덱스 제거 or 통합
- DML 성능 향상
- 인덱스 다이브 성능 개선

이 중 아래 4가지 항목에 대한 사례와 함께 살펴보도록 한다.

인덱스가 있는데도 인덱스를 안 타는 상황 → 인덱스 손익 분기점
인덱스를 타지만 성능이 안 나오는 상황 → 인덱스 스캔 비효율
인덱스 스캔 비효율은 없지만 성능이 안 나오는 상황 → 테이블 랜덤 엑세스 최소화
인덱스가 너무 많은 상황 → 중복 인덱스 최적화

1. 인덱스가 있는데도 안 타는 상황 → 인덱스 손익 분기점

인덱스 스캔에서 테이블 풀 스캔으로의 변경은 주로 옵티마이저가 실행 계획을 선택할 때 발생하는 현상이다.

이 상황과 관련하여 Mysql 공식문서에서는 아래와 같이 4가지 상황을 가이드하고 있다.

테이블이 작을 경우 테이블 스캔이 키 조회보다 빠를 수 있음
인덱스된 열에 유용한 제한 사항이 없음
상수가 테이블의 큰 부분을 포함하여 인덱스 키 조회보다 테이블 스캔이 더 빠름
열의 카디널리티가 낮은 키를 다른 열을 통해 사용할 때 인덱스 키 조회보다 테이블 스캔이 더 빠르다고 가정함

인덱스 손익 분기점이란?

인덱스 스캔보다 테이블 풀스캔 비용이 더 낮아지는 지점

인덱스 손익 분기점

테이블 풀 스캔의 비용은 일정하지만, 인덱스 스캔은 조회 건수에 비례하여 쿼리 구조나 시스템 상황에 따라 변동된다. 이런 변화로 옵티마이저는 어느 지점에서는 인덱스를 사용하지 않는 실행계획을 선택하게 된다.

인덱스 스캔은 소량의 데이터를 찾는 목적에서 잘 동작한다. 많은 양의 데이터를 조회하는 쿼리에서는 적합하지 않으므로 다른 조회 전략을 찾는게 유리할 수 있다. 즉, 인덱스 스캔에서는 인덱스트리를 탐색하는 비용과 최종 인덱스 리프노드에서 뽑은 clustered index key로 테이블 로우를 읽는 비용을 합한 비용이 발생하고, 테이블 풀 스캔에서는 전체 테이블 로우를 다 읽는 비용만 발생한다.

따라서 인덱스로 많은 대상을 찾으면 테이블 풀스캔보다 인덱스를 찾는 비용이 더 많이 발생할 수 있으며, 강제로 인덱스를 사용하도록 힌트를 지정하는 것이 오히려 더 많은 IO 비용을 발생시킬 수 있다. 테이블 풀 스캔이 항상 나쁜 것은 아니니 상황에 따라 최적의 스캔 방법을 선택하는 것이 중요하다.

2. 인덱스를 타는데 성능이 안 나오는 상황 → 인덱스 스캔 비효율

인덱스 스캔 자체에서 비효율이 발생하는 경우 인덱스를 잘 타도 성능이 떨어질 수 있다. 복합 인덱스에서는 인덱스 구성 컬럼에서 범위조건 이 사용되면, 해당 컬럼 이후의 컬럼들은 인덱스 스캔이 '액세스'가 아닌 '필터링'으로 동작한다.

예를 들어, 동일 테이블 동일 인덱스에서 아래와 같이 동작할 수 있다.

100건 스캔 → 5건 필터링 → 5건 테이블 엑세스
20건 스캔 → 5건 필터링 → 5건 테이블 엑세스

복합 인덱스의 경우 인덱스 선행컬럼이 조건절에 없거나 = 조건이 아니면, 인덱스 스캔 과정에 비효율이 발생한다. 인덱스 스캔은 액세스 조건과 필터 조건으로 구분되어 동작한다.

인덱스 엑세스 조건 : 인덱스 스캔 범위 결정
인덱스 필터 조건 : 테이블 엑세스 여부 결정
테이블 필터 조건 : 최종 결과집합 포함 여부 결정

인덱스 스캔으로 동작하지만 실제 비효율적인 동작이 있는지 explain analyze 를 통해 한번 더 확인해본다면 예상하지 못한 성능저하를 예방할 수 있다.

3. 인덱스 스캔 비효율은 없지만 성능이 안 나오는 상황 → 테이블 랜덤 액세스 최소화

데이터베이스의 인덱스 스캔이 효율적이지만 성능이 안 나오는 경우가 있다. 이는 실제 데이터 스캔이 많은 상황에서 발생하는데, 이 경우 SQL 외적인 방법보다는 SQL 레벨에서 성능을 개선하는 것이 유용할 수 있다.

쿼리가 인덱스만으로 처리되어 테이블 랜덤 액세스가 사라지면 관련 비용이 줄어든다. 커버링 인덱스를 사용하여 실제 io를 확인해보면, 더 많은 io를 줄일 수 있다. 그러나 과도한 복잡한 인덱스 생성은 다른 문제를 야기할 수 있으니 조심해야 한다.

* 커버링 인덱스: 쿼리 실행에 필요한 모든 컬럼을 인덱스에 포함하는 특수한 종류의 인덱스이다. 이러한 인덱스는 쿼리의 필요한 데이터를 인덱스 자체에서만 가져와서 처리할 수 있기 때문에 추가적인 테이블 액세스가 필요하지 않다. 즉, 인덱스만을 스캔하여 쿼리를 완료할 수 있다.

데이터베이스는 인덱스를 사용하여 쿼리 결과를 가져오기 때문에 테이블 전체를 스캔하는 대신 인덱스를 스캔하면 쿼리 성능을 향상 시킬 수 있다. 그러나 몇 가지 고려해야 할 사항이 있다.
- 커버링 인덱스는 인덱스의 크기를 증가시킬 수 있으며, 이는 인덱스의 업데이트 및 관리 비용이 증가할 수 있다.
- 쿼리의 필요한 모든 컬럼을 포함하는 인덱스를 만들어야 하므로 인덱스의 디자인을 고려해야 한다.
- 모든 쿼리에 대해 커버링 인덱스를 만들 수 있는 것은 아니며, 쿼리의 패턴과 요구사항에 따라 적절한 인덱스를 선택해야 한다.

4. 인덱스가 너무 많이 있는 상황 → 중복 인덱스 최적화

인덱스를 줄이는 것도 인덱스 튜닝이 될 수 있다. 너무 많거나 불필요한 인덱스는 DML 작업의 성능을 저하시킬 수 있다. 또한 저장 공간을 낭비하고 의도하지 않은 인덱스 선택으로 인해 부작용이 발생할 수 있다. 즉, 중복된 인덱스를 제거하고 최적화된 인덱스를 사용하는 테이블과의 쿼리 프로파일을 비교하여 이러한 튜닝 작업의 효과를 확인할 수 있다.

불필요한 인덱스로 인해 DML 쿼리에서 상당한 비효율이 발생할 수 있음
DML 성능 뿐만 아니라, 저장공간 낭비도 발생할 수 있음

인덱스는 꼭 필요한 조회경로에 대해서만 생성하는 것이 좋다. 특히 중복 인덱스의 경우, 조회/갱신 양쪽 모두에서 불필요한 성능저하가 발생할 수 있기 때문에 중복 인덱스가 있다면 인덱스 정리를 고려해보는 것이 좋다.

튜닝의 핵심

튜닝의 핵심은 이슈 상황에 따라 어떤 지점에서 어떤 비용이 많이 발생하는 지 파악하는 것이 가장 중요하다.

explain, explain analyze 등을 통해 쿼리가 어떻게 동작하는 지 확인
쿼리 프로파일링을 통해 실제 시스템에서 cpu, block io등이 얼마나 발생하는 지 확인
비효율을 제거할 수 있는 포인트 검색
해당 지점을 효율적으로 동작하도록 개선