madup-inc / madup-inc.github.io

MadTech
https://madup-inc.github.io
2 stars 2 forks source link

업무 중 인상 깊었던 버그나 이슈 글 마무리 #22

Closed firepunch closed 3 years ago

firepunch commented 5 years ago

https://github.com/madup-inc/madup-inc.github.io/pull/15/files

---
layout: post
title: 업무 중 인상 깊었던 버그나 이슈
author: Willy
date: 2019-03-26
---
안녕하세요 이번 글에서는 매드업 개발자 3명 각자 업무 중 인상 깊었던 버그나 이슈에 대해 공유하려고 합니다.

실제 프로젝트에서는 어떤 일들이 있는지, 서비스 운영에서는 어떤 이슈들이 있을 수 있는지를 3명의 개발자가 하는 일이 조금씩 다르고 경력도 달라서 3인 3색의 다양한 관점에서 공유합니다.

업무나 서비스 운영 도중 생각지도 못했거나 정말 엉뚱한 문제들이 발생하기도 합니다. 그런 경험들은 현업에서 배울 수 있는 값진 경험이면서 또 재미있는 이야깃거리가 될 수 있습니다.

3명에게 하는 질문은 다음과 같습니다.

1. 자기소개
1. 어떤 버그나 이슈가 인상 깊었는지
1. 인상 깊었던 이유
1. 해결 과정과 방법

# Willy

[월리 사진]

## 자기소개

안녕하세요 Willy입니다.

저는 매드업에서 1년 6개월 정도 일했고 매드업이 첫 직장인 주니어 개발자입니다.

현재 하는 일은 가칭 R3라고 하는 **웹 대시보드** 개발을 하고 있습니다. 

주로 JavaSciprt를 사용하는 React와 Node.js로 업무를 하고 있고 함수형 프로그래밍에 관심이 많습니다.

## 어떤 버그나 이슈가 인상 깊었는지

저는 **쿼리 개선 이슈**가 인상 깊었습니다. 

기존에 1달 치 리포트를 뽑는데 3초씩 걸려서 사용에 불편을 끼치는 쿼리가 여러 개 있었는데 이 모든 쿼리에 대한 속도를 0.3초 이내로 줄이는 작업을 했습니다.

쿼리 개선은 대시보드의 로직 개선 작업 중 일부였지만 데이터에 백업과 성능, 확인 작업까지 생각할 거리가 많았습니다.

## 인상 깊었던 이유

매드업이 첫 직장이다 보니 그 이전에 개발 경험이 적었습니다.

그래서 이런 생각도 했습니다.

> '학교 DB 시간에 배운것 중 실제로 쓰는게 얼마나 있지? '
> '트리거는 블로그에서 자제하라는 글도 본거 같은데?'
> '학교 다닐 때 쿼리 최적화 해본 적이 없네'

학교에서 하는 프로젝트들에 데이터는 많아야 몇천, 몇만 수준이었는데 실제 현업에서 다루는 데이터 양은 정말 많았고 인덱스에 대한 생각 없이 쿼리를 짜면 속도 이슈로 고통받을 수 밖에 없었습니다.

**현업**이 아니면 있기 힘들 일이라서 기억에 남습니다.

## 해결 방법
**인덱스**를 다시 잡는 방법과 **집계테이블**을 활용하는 방법으로 해결했습니다.

A 인덱스가 평균적으로 성능이 좋아도 조회 기간에 따라서는 다른 인덱스가 더 성능이 좋을 수도 있습니다.
그런 경우 Mysql은 A인덱스로 데이터를 찾는데 `USE INDEX` 문을 사용해서 더 상황에 맞는 다른 인덱스를 사용하게 할 수 있습니다.

인덱스로도 해결이 안 되는 경우나 데이터 자체가 너무 많은 경우 기존에 있던 집계테이블을 활용했습니다.

집계테이블이 없는 경우 트리거로 새로운 집계 테이블을 만들기도 했습니다.

만약에 다른 방법들을 썼다면 테이블을 분리하거나 데이터를 아카이브하는 정책이 있을 수 있었는데 그런 방법들은 예전 데이터를 어떻게 보관 할 건가 이슈가 있어 사용하지 않았었습니다.

---

# John

[John 사진]

## 자기소개

안녕하세요 John입니다.

매드업에서는 2015년 겨울부터 4년째 일하고 있습니다.

현재는 **매드업 네트워크 운영** 업무를 하고 있고 관심사는 심리학, 철학입니다.

최근은 사주도 관심이 생겨 한 번 받아 보고 싶습니다.

## 어떤 버그나 이슈가 인상 깊었는지

매드업 초창기 핀켓이라는 --- 어플리케이션 서비스를 개발해서 운영했었습니다.

그 당시 **포인트 통합 기능**에 실수가 있어서 회사에 금전적 손해를 끼쳤던 일이 기억에 남습니다.

버그의 원인은 개발 서버에서 포인트 통합 기능을 테스트하던 중 사용하는 서버를 운영 서버로 돌려놓지 않고 그대로 배포해버려서 발생했습니다.

## 인상 깊었던 이유

회사에 금전적 손해가 발생해서 충격적이었고 저에게 많은 영향을 끼친 버그입니다.

이 일 이후로 배포할 때 더 신중해지고 안정성에 대해 집착하게 되었습니다.

## 해결 과정과 방법

운영 업무에서 발생하는 장애는 장애를 고치는 일도 중요하지만, 더 중요한 것은 

**똑같은 일이 일어나지 않는 것입니다.**

테스트를 하고 배포 전에는 **점검표**를 만들어서 문제가 될 수 있는 사항들을 **확인하는 절차**가 생겼습니다.