tomatovibe

기술 부채란 무엇인가? (실무 예시로 이해하는 기술 부채의 모든 것)

babytomato — Mon, 13 Apr 2026 09:17:05 +0900

“이 코드… 나중에 고치자” → 이미 시작된 기술 부채

개발하면서 이런 말, 한 번쯤 해봤을 겁니다.

“일단 돌아가게만 만들자”
“이건 다음 스프린트에서 정리하자”
“테스트는 나중에…”

이 선택들, 사실 하나로 묶입니다.

기술 부채(Technical Debt)

1. 기술 부채란? (딱 한 줄 정의)

기술 부채는
“빠른 개발을 위해 미래 비용을 미리 써버린 것” 입니다.

조금 더 정확히 말하면,

빠른 개발을 위해 최적이 아닌 선택을 하면
나중에 더 큰 비용(수정, 유지보수)이 발생하는 구조 (IBM)

✔ 쉽게 이해하는 비유

지금: 빠르게 개발 → 편함
미래: 수정, 유지보수 → 비용 폭발

금융으로 치면 이자 붙는 빚

2. 실무에서 바로 공감되는 기술 부채 예시

이 부분이 핵심입니다.
“아 이거 내 얘기네”가 나와야 합니다.

예시 1: 급하게 만든 복붙 코드

if (type === 'A') { processA() }
if (type === 'B') { processB() }
if (type === 'C') { processC() }

문제

구조 없음
중복 로직 증가

3개월 뒤

로직 변경 → 3군데 수정
하나 빠뜨림 → 버그 발생

결과
✔ 유지보수 비용 폭증
✔ 코드 수정 공포 시작

예시 2: 테스트 없는 배포

상황:

“시간 없으니까 테스트 빼고 배포하자”

2주 후

기능 수정했는데 다른 기능 깨짐
원인 찾는데 5시간 소요

결과
✔ 개발 속도 오히려 느려짐
✔ 팀 신뢰도 하락

예시 3: 레거시 코드 방치

function process_v2_final_real_last() {}

특징

아무도 모름
삭제 못함 (무서워서)

결과
✔ 신규 개발자 온보딩 지옥
✔ 코드 이해 시간 ↑

예시 4: 기술 스택 미루기

상황:

오래된 라이브러리 계속 사용

이유

“지금 바꾸기 귀찮음”

1년 뒤

보안 문제 발생
대규모 리팩토링 필요

결과
✔ 비용 10배 증가
✔ 서비스 리스크 증가

3. 기술 부채가 쌓이면 실제로 생기는 일

이건 이론이 아니라 실제 현상입니다.

1) 개발 속도 점점 느려짐

처음엔 빠름 → 점점 느려짐

이유
코드 복잡도 증가 → 수정 비용 증가

2) 버그 폭발

하나 고치면 다른 데 터짐
“이 코드 건드리지 마” 문화 생성

3) 유지보수 비용 증가

기술 부채는 실제로
유지보수 비용 증가 + 품질 저하를 유발 (KCI)

4) 결국 리팩토링 지옥

미루다가 한 번에 터짐

이때 비용 = 초기의 몇 배

4. 기술 부채가 생기는 진짜 이유 (핵심)

이건 거의 모든 팀 공통입니다.

✔ 1) 일정 압박

“이번 주 안에 출시해야 함”

✔ 2) 요구사항 변경

계속 바뀌는 기획

✔ 3) 경험 부족

당시엔 최선이었음

✔ 4) 의도적 선택

속도를 위해 일부러 감수

핵심 포인트
기술 부채는 실수가 아니라 ‘선택’인 경우가 많다

5. 기술 부채 해결 방법 (실무 기준, 바로 적용 가능)

여기서 중요한 건
“이론 말고 실제 가능한 것”

✔ 1) 기능 개발하면서 리팩토링 같이 하기

❌ 잘못된 방식

“나중에 한 번에 정리하자”

✔ 현실적인 방식

기능 수정할 때 같이 정리

효과

부담 분산
리팩토링 비용 최소화

✔ 2) 코드 리뷰 기준 바꾸기

❌ 기존

“동작하나요?”

✔ 바꿔야 할 질문

“이 코드 3개월 뒤에도 이해 가능?”

✔ 3) 테스트 ‘최소 단위’라도 작성

핵심만 테스트

핵심 비즈니스 로직
자주 수정되는 부분

효과

리팩토링 안정성 확보

✔ 4) 기술 부채를 “기록”하고 관리하기

❌ 안 좋은 방식

TODO 주석

✔ 좋은 방식

Jira / Notion / 이슈로 관리

핵심
보이지 않으면 관리 안 됨

6. 결론 (이 글의 핵심 요약)

기술 부채는

❌ 없애야 하는 것
✅ 관리해야 하는 것

입니다.

핵심 한 줄 정리

기술 부채는 피하는 게 아니라, 통제하는 것이다

백엔드는 왜 서버까지 알아야 할까? (코드만 알아선 부족한 이유)

babytomato — Fri, 10 Apr 2026 09:22:03 +0900

“나는 개발자인데…
왜 서버까지 알아야 하지?”

백엔드 개발을 처음 시작하면
이런 생각이 한 번쯤 든다.

코드 잘 짜면 되는 거 아닌가?
서버는 인프라 담당 아닌가?

근데 실무를 하다 보면 깨닫는다.

코드만 알아서는 아무것도 해결 못 한다는 것

실제로 겪는 상황

API가 느린데 이유를 모름
서버가 죽었는데 어디부터 봐야 할지 모름
메모리 부족으로 장애 발생

이때 필요한 건 코드가 아니다

서버 이해

왜 서버를 알아야 할까?

백엔드는 결국

서버 위에서 돌아가는 프로그램

이기 때문이다.

서버를 모르면 생기는 문제

❌ 원인을 못 찾는다

CPU 문제인지
메모리 문제인지
코드 문제인지

구분 불가

❌ 장애 대응이 느리다

로그 위치 모름
프로세스 상태 모름
서버 상태 확인 못 함

❌ 성능 개선 한계

왜 느린지 모름
어디를 개선해야 할지 모름

실무에서 최소한 알아야 할 것

✅ 1. 리눅스 기본 명령어

top / htop → CPU, 메모리 확인
ps → 프로세스 확인
df -h → 디스크 용량

✅ 2. 로그 위치 & 확인

핵심 질문

“로그 어디에 쌓이지?”

✅ 3. 프로세스 개념

서버가 어떻게 실행되는지
죽으면 어떻게 되는지

✅ 4. 기본 네트워크 개념

포트
요청 흐름
timeout

⚡ 실무에서 느끼는 순간

이걸 모르면:

“왜 느리지…?”
“왜 안 되지…?”

이걸 알면:

“아 CPU 때문이네”
“메모리 터졌네”
“포트 막혔네”

차이가 엄청 크다

한 줄 정리

“백엔드는 코드가 아니라 ‘시스템’을 다루는 일이다.”

시리즈 마무리

여기까지 읽었다면
이미 중요한 걸 하나 알게 된 거다.

백엔드는 단순히 코드를 짜는 일이 아니다

환경을 이해하고
데이터를 다루고
문제를 해결하고
시스템을 보는 일이다

이 시리즈를 통해 얻어야 할 것

문제를 보는 시각
원인을 찾는 방법
실무에서 살아남는 감각

디버깅이 실력인 이유 (코딩보다 중요한 능력)

babytomato — Thu, 9 Apr 2026 09:13:48 +0900

“코드는 내가 짰는데…
왜 안 되는지 모르겠다”

백엔드 개발을 하다 보면
이 상황을 정말 많이 겪는다.

그리고 어느 순간 깨닫게 된다.

개발자의 진짜 실력은 코딩이 아니라 디버깅이다.

실제로 겪는 상황

분명 맞게 짠 것 같은데 에러 발생
어디서 잘못된 건지 감이 안 잡힘
로그 봐도 이해 안 됨

이때 드는 생각

“나 개발 못하는 건가…?”

왜 디버깅이 어려울까?

코드는 “작성”보다
**“흐름을 이해하는 것”**이 훨씬 어렵다

디버깅 못 하는 사람 특징

❌ 감으로 찍는다

→ “여기 문제 같아”

❌ 코드만 계속 본다

→ 실제 실행 흐름 안 봄

❌ 한 번에 해결하려 한다

→ 범위 너무 넓음

잘하는 사람은 이렇게 한다

✅ 1. 범위를 줄인다

핵심 질문

“여기까지는 정상인가?”

OK / FAIL 기준으로 나눔
문제 영역 좁히기

✅ 2. 로그로 추적한다

A → B → C → D

어디까지 실행됐는지 확인

✅ 3. 가설을 세우고 검증한다

❌ 그냥 수정
위험

✅ 가설 → 테스트 → 확인
반복

✅ 4. 데이터부터 본다

많은 경우 원인은 코드가 아니라

데이터

값이 이상함
NULL 존재
예상과 다른 상태

⚡ 실무에서 느끼는 차이

디버깅 못 할 때

3시간 동안 원인 못 찾음
계속 같은 곳만 봄

디버깅 잘할 때

10분 만에 원인 파악
빠르게 해결

디버깅 실력 = 이런 능력

흐름을 쪼개는 능력
원인을 좁히는 능력
로그를 읽는 능력

이게 진짜 실력이다

한 줄 정리

“개발자의 실력은 얼마나 빨리 원인을 찾느냐로 결정된다.”

마무리

코드를 잘 짜는 것도 중요하다.

하지만 실무에서는 더 중요한 게 있다.

문제가 생겼을 때 얼마나 빠르게 해결하느냐

그래서 결국 남는 건 하나다:

디버깅 실력

왜 요구사항은 계속 바뀔까? (개발자가 가장 많이 듣는 말)

babytomato — Wed, 8 Apr 2026 09:21:30 +0900

“이거 조금만 수정하면 될 것 같아요 ”

백엔드 개발을 하다 보면
이 말을 정말 많이 듣게 된다.

그리고 경험이 쌓일수록 알게 된다.

“조금”의 의미는 절대 ‘조금’이 아니다

실제로 겪는 상황

기능 다 만들었는데 기획 변경
거의 완료됐는데 정책 수정
배포 직전에 요구사항 추가

그리고 항상 따라오는 말

“이거 금방 되죠?”

왜 이런 일이 계속 생길까?

개발자가 보기엔 이상하지만
사실 이유가 있다.

원인 1: 처음부터 완벽한 기획은 없다

기획 단계에서는

모든 케이스를 다 고려하기 어렵고
실제 사용 상황을 완전히 예측할 수 없다

그래서 개발하면서 보완된다

원인 2: 비즈니스는 계속 변한다

정책 변경
경쟁사 대응
사용자 피드백

개발보다 비즈니스가 더 빠르게 움직인다

원인 3: “간단해 보이기 때문”

기획자 입장:

“버튼 하나 추가하면 되겠네?”

개발자 입장:

DB, API, 로직 다 수정해야 함

⚠️ 신입 때 가장 많이 하는 착각

❌ “왜 이렇게 자주 바뀌지?”

→ 이상한 게 아니라 정상이다

❌ 짜증부터 남

→ 협업 어려워짐

실무에서 이렇게 대응한다

✅ 1. 영향 범위부터 본다

요구사항 들으면 바로 생각해야 할 것:

“어디까지 영향 가지?”

DB 변경?
API 수정?
기존 기능 영향?

✅ 2. 바로 하지 말고 확인한다

꼭 해야 할 질문

정확한 요구사항은?
예외 케이스는?
기존 기능 영향은?

✅ 3. “시간”을 같이 말한다

❌ “네 됩니다”
위험

✅ “이건 2일 정도 필요합니다”
현실적인 커뮤니케이션

✅ 4. 변경을 전제로 설계한다

핵심 마인드

“이건 나중에 바뀔 수도 있다”

확장 가능하게
하드코딩 지양

⚡ 실무에서 느끼는 포인트

이걸 몇 번 겪으면 바뀐다:

“왜 바뀌지?” → ❌
“어떻게 대응하지?” → ⭕

한 줄 정리

“요구사항 변경은 예외가 아니라 기본이다.”

마무리

백엔드 개발은 단순히 기능을 만드는 일이 아니다.

변화에 맞춰 계속 수정하는 일이다.

그래서 중요한 건

빠르게 만들기보다
유연하게 대응하는 능력

레거시 코드 처음 만났을 때 살아남는 법 (백엔드 신입 현실)

babytomato — Tue, 7 Apr 2026 09:13:57 +0900

“이 코드… 누가 짠 거지?”

백엔드 개발자로 처음 실무에 들어가면
거의 대부분의 시간을 이렇게 보낸다.

남이 만든 코드를 읽는 시간

그리고 그 코드가…

주석 없음
구조 이상함
어디서부터 봐야 할지 모름

이게 바로 레거시 코드다.

실제로 겪는 상황

기능 하나 수정하려고 했는데 코드가 너무 복잡함
어디를 건드려야 할지 모르겠음
잘못 건드릴까 봐 무서움

그래서 이런 생각 든다

“이거 건드려도 되는 거 맞나…?”

왜 레거시 코드는 어려울까?

핵심은 이거다:

“의도를 모른다”

코드는 있는데
왜 이렇게 짰는지는 모른다.

신입이 흔히 하는 실수

❌ 처음부터 다 이해하려고 함

→ 시간 낭비

❌ 무작정 수정

→ 사이드 이펙트 발생

❌ 코드만 봄

→ 흐름을 놓침

실무에서 이렇게 접근한다

✅ 1. “전체” 말고 “흐름”부터 본다

예를 들어 API 하나 기준으로:

요청 → 서비스 → DB → 응답

이 흐름을 먼저 따라간다.

✅ 2. 로그 찍어서 확인한다

코드만 보는 게 아니라

직접 실행하면서 본다

log.info("여기 들어옴");

어디까지 실행되는지 확인

✅ 3. 작은 단위로 이해한다

한 번에 전체 X
함수 하나씩

쪼개서 이해

✅ 4. “안 건드리는 용기”

모르는 부분은 건드리지 않는다.

실무에서 중요한 태도

✅ 5. 변경은 최소한으로

핵심 원칙

필요한 부분만 수정
영향 범위 최소화

⚠️ 레거시 건드릴 때 가장 위험한 순간

“이 코드 이상한데? 리팩토링 해야겠다”

신입 때 이 생각 들면 위험하다.

이유

기존 로직 깨질 가능성 높음
숨겨진 의도 있음

실무에서 진짜 중요한 포인트

레거시 코드를 보면 이렇게 생각해야 한다:

“이건 누군가의 이유 있는 선택이다”

비효율적으로 보일 수 있지만
당시 상황에서는 최선이었을 수도 있다.

⚡ 실무에서 느끼는 변화

처음엔:

“이 코드 왜 이래?”
“이해 안 된다…”

조금 지나면:

“아 이래서 이렇게 했구나”
“여기서 문제 날 수도 있겠네”

한 줄 정리

“레거시 코드는 이해하려 하지 말고, 흐름부터 따라가라.”

마무리

백엔드 개발자는
코드를 “잘 짜는 것”도 중요하지만

**“남의 코드를 빠르게 이해하는 능력”**이 더 중요하다.

그리고 그 시작은 단순하다:

전체 X → 흐름 O

배포했더니 장애 나는 이유 (백엔드 개발자의 통과의례)

babytomato — Mon, 6 Apr 2026 09:01:59 +0900

“로컬에서는 잘 됐는데…
왜 배포하자마자 터지지?”

백엔드 개발을 하다 보면
한 번쯤은 반드시 겪는다.

배포 = 장애 발생

심지어 잘 동작하던 기능도
배포만 하면 갑자기 문제가 생긴다.

실제로 겪는 상황

배포 직후 500 에러 폭증
특정 API만 갑자기 실패
DB 오류 발생
사용자 문의 폭주

그리고 그 순간

“아… 큰일 났다”

왜 배포하면 터질까?

핵심은 이거다:

“환경과 상태가 바뀌기 때문”

대표적인 원인 1: DB 스키마 변경

이건 진짜 많이 터진다.

예를 들어:

컬럼 추가했는데 코드 먼저 배포
컬럼 삭제했는데 아직 코드에서 사용 중

결과

쿼리 에러 발생
서비스 일부 기능 마비

대표적인 원인 2: 캐시 문제

배포 전과 후의 상태가 다름

기존 캐시 데이터 남아 있음
새로운 코드와 충돌

결과

이상한 데이터 노출
일부 요청만 실패

대표적인 원인 3: 서버 간 버전 불일치

서버가 여러 대일 경우

A 서버: 최신 코드
B 서버: 이전 코드

결과

어떤 요청은 성공
어떤 요청은 실패

진짜 찾기 어려움

대표적인 원인 4: 설정 값 차이

환경 변수 누락
설정 파일 변경
외부 API 주소 변경

결과

특정 기능만 동작 안 함

대표적인 원인 5: 순서 문제

이건 신입 때 거의 다 겪는다.

잘못된 순서

코드 배포
DB 변경

올바른 순서

DB 변경
코드 배포

⚠️ 신입 때 많이 하는 실수

❌ 테스트 안 하고 바로 배포

→ 위험

❌ 배포 후 확인 안 함

→ 더 위험

❌ 롤백 준비 안 함

→ 최악

실무에서 이렇게 막는다

✅ 1. 배포 체크리스트 만들기

DB 변경 여부
환경 변수 확인
캐시 초기화 필요 여부

✅ 2. 점진적 배포 (Rolling / Blue-Green)

한 번에 전체 배포 X
일부 서버부터 적용

문제 발생 시 빠르게 대응 가능

✅ 3. 배포 후 즉시 확인

주요 API 테스트
로그 확인
모니터링 체크

✅ 4. 롤백 준비

항상 생각해야 할 질문

“문제 생기면 5분 안에 되돌릴 수 있나?”

⚡ 실무에서 느끼는 포인트

이걸 몇 번 겪으면 생각이 바뀐다:

“배포는 그냥 올리는 게 아니다”
“배포도 개발이다”

한 줄 정리

“배포는 끝이 아니라, 또 하나의 시작이다.”

마무리

백엔드 개발자에게 배포는

가장 긴장되는 순간이자
가장 중요한 작업이다.

그리고 한 번 크게 겪고 나면
습관이 생긴다.

체크 → 확인 → 대비

재현 안 되는 버그의 정체 (개발자 멘탈 터지는 순간)

babytomato — Fri, 3 Apr 2026 09:06:06 +0900

“분명히 에러가 났다는데…
왜 나는 재현이 안 되지?”

백엔드 개발을 하다 보면
가장 스트레스 받는 순간이 있다.

버그가 있는데 재현이 안 되는 경우

코드를 봐도 문제 없어 보이고
직접 테스트해도 정상 동작한다.

근데 사용자한테는 계속 발생한다.

이쯤 되면 이런 생각 든다

“이거 진짜 존재하는 버그 맞나…?”

실제로 겪는 상황

특정 사용자만 에러 발생
특정 시간에만 문제 발생
같은 요청인데 결과가 다름

특징

로컬에서는 절대 안 터짐
로그도 애매하게 찍힘
QA에서도 재현 안 됨

왜 이런 일이 생길까?

핵심은 이거다:

“환경과 상황이 다르기 때문”

대표적인 원인 1: 데이터 상태

같은 API라도
데이터 상태에 따라 결과가 달라진다.

예를 들어:

특정 사용자 데이터만 이상함
NULL 값 존재
예상 못 한 값 들어옴

그래서

나는 정상
특정 유저만 에러

대표적인 원인 2: 타이밍 문제

이건 진짜 찾기 어렵다.

요청 순서에 따라 결과 변경
처리 중간에 다른 요청 개입
아주 짧은 시간 차이

결국
동시성 문제랑 연결되는 경우 많다

대표적인 원인 3: 캐시(Cache)

캐시 때문에 결과가 달라지는 경우

캐시된 데이터 사용
최신 데이터 반영 안 됨
서버마다 캐시 상태 다름

증상

어떤 요청은 정상
어떤 요청은 이상

대표적인 원인 4: 환경 차이

서버마다 설정 다름
배포 버전 다름
특정 서버만 문제 있음

특히 이런 상황

“서버 3대 중 1대만 에러 발생”

⚠️ 신입 때 가장 많이 하는 실수

❌ 코드만 계속 봄

→ 원인은 코드 밖에 있음

❌ 감으로 수정

→ 더 큰 문제 생김

❌ 로그 안 봄

→ 단서 놓침

실무에서 이렇게 해결한다

✅ 1. 로그부터 본다 (무조건)

언제 발생했는지
어떤 값으로 호출됐는지
어디서 실패했는지

단서 찾기

✅ 2. “차이”를 찾는다

핵심 질문:

“정상 케이스 vs 에러 케이스 뭐가 다르지?”

사용자
데이터
시간
요청 순서

✅ 3. 데이터 직접 확인

DB 조회
문제 데이터 비교

여기서 많이 걸린다

✅ 4. 일부러 상황을 만든다

동시 요청 보내보기
특정 데이터 넣어보기
캐시 비우기

재현 환경 만들기

⚡ 실무에서 느끼는 포인트

이 문제를 겪으면 깨닫는다:

“버그는 항상 이유가 있다”
“재현 안 되는 게 아니라, 조건을 모르는 것뿐이다”

한 줄 정리

“재현 안 되는 버그는 없다. 조건을 아직 못 찾았을 뿐이다.”

마무리

백엔드 개발에서 진짜 실력은

버그를 ‘찾는 능력’이다.

그리고 그 시작은 항상 같다:

로그 → 차이 → 데이터

이 흐름만 익히면
재현 안 되는 버그도 결국 잡힌다.

로그 없으면 장애 못 잡는다 (백엔드 개발자의 생명줄)

babytomato — Thu, 2 Apr 2026 09:25:12 +0900

“에러가 났다고 하는데…
어디서 터진 건지 모르겠어요”

백엔드 개발을 하다 보면
반드시 한 번은 이런 상황을 겪는다.

그리고 그때 깨닫는다.

로그가 없으면 아무것도 못 한다.

실제로 겪는 상황

사용자: “결제가 안 돼요”
서버: 500 에러 발생
개발자: “어디서 터진 거지…?”

코드를 아무리 봐도 모르겠다.
재현도 안 된다.

이때 로그가 없으면?

그냥 추측 게임 시작이다.

왜 로그가 그렇게 중요할까

백엔드는 눈에 보이지 않는다.

프론트처럼 화면이 있는 것도 아니고,
사용자 행동이 그대로 보이지도 않는다.

그래서 필요한 게 로그다.

로그는 말 그대로

“서버 안에서 무슨 일이 일어났는지 기록”

로그가 있으면 가능한 것

1. 어디서 터졌는지 바로 알 수 있음

어떤 API
어떤 함수
어떤 시점

2. 어떤 값으로 실행됐는지 확인 가능

userId=123  
amount=50000  
status=FAILED

문제 원인 추적 가능

3. 재현이 안 되는 버그도 추적 가능

→ 실제 사용자 상황을 그대로 볼 수 있음

⚠️ 신입 때 많이 하는 실수

❌ 로그를 거의 안 남김

→ “나중에 찍지 뭐…”

❌ 에러 로그만 찍음

→ 정상 흐름을 모르면 비교 불가

❌ 로그가 너무 단순함

error 발생

이건 아무 의미 없음

실무에서 로그 이렇게 남긴다

✅ 1. 흐름 단위로 남기기

[Payment Start] userId=123  
[Payment Validate] OK  
[Payment Request PG]  
[Payment Failed] timeout

어디서 끊겼는지 바로 보임

✅ 2. 핵심 데이터 같이 남기기

userId
요청값
결과값

나중에 100% 도움 된다

✅ 3. 에러는 스택까지 같이 남기기

Exception: NullPointerException  
at PaymentService.process()

이거 하나로 디버깅 시간 반으로 줄어듦

✅ 4. 로그 레벨 구분하기

INFO: 흐름 확인
WARN: 이상 징후
ERROR: 진짜 문제

⚡ 로그 하나로 인생 바뀌는 순간

이거 실무에서 진짜 느낌 온다.

로그 없을 때

3시간 동안 원인 못 찾음

로그 있을 때

5분 만에 해결

한 줄 정리

“로그는 선택이 아니라 필수다. 없으면 장애 못 잡는다.”

마무리

백엔드 개발자는
코드를 잘 짜는 것도 중요하지만

문제를 빠르게 찾는 능력이 더 중요하다.

그리고 그 능력의 핵심이 바로 로그다.

왜 이 버그는 가끔만 터질까? (동시성 문제의 정체)

babytomato — Wed, 1 Apr 2026 09:25:20 +0900

“분명히 잘 되던 기능인데…
왜 가끔씩만 에러가 날까?”

백엔드 개발을 하다 보면
재현이 안 되는 버그를 처음 만나게 된다.

그리고 이때 가장 많이 하는 생각:

“내 코드 문제 맞나…?”

결론부터 말하면
높은 확률로 동시성 문제다.

실제로 겪는 상황

결제 요청이 두 번 들어가서 중복 결제 발생
재고가 1개인데 동시에 주문 2개 성공
어떤 때는 정상, 어떤 때는 데이터 꼬임

특징

로컬에서는 절대 안 터짐
테스트할 때는 멀쩡함
운영에서만 가끔 터짐

이쯤 되면 멘탈 나간다

“이거 왜 랜덤이야…?”

진짜 원인: 동시에 요청이 들어옴

우리는 보통 이렇게 생각한다:

“요청 → 처리 → 응답”

근데 실제 서버는 다르다.

“여러 요청이 동시에 들어와서 같이 처리됨”

이해를 위한 간단한 예시

재고가 1개 남은 상황

1. 사용자 A → 재고 확인 (1개 있음)
2. 사용자 B → 재고 확인 (1개 있음)
3. A 구매 성공
4. B도 구매 성공

결과
재고 -1 (말이 안 되는 상황 발생)

왜 이런 일이 생길까?

핵심은 이거다:

“읽기 → 처리 → 쓰기” 사이에 틈이 있음

이 틈 사이에
다른 요청이 끼어들면 문제가 발생한다.

⚠️ 신입이 놓치기 쉬운 포인트

1. 로컬에서는 절대 안 보임

→ 혼자 테스트하면 동시 요청 없음

2. 테스트 코드로도 잘 안 잡힘

→ 의도적으로 동시에 때려야 함

3. “가끔”만 터짐

→ 그래서 더 찾기 어려움

그래서 어떻게 해결하냐

실무에서는 이런 방식으로 막는다:

✅ 1. 트랜잭션(Transaction)

작업을 하나의 묶음으로 처리
중간에 끼어들지 못하게 함

✅ 2. 락(Lock)

데이터를 수정하는 동안 다른 접근 차단

종류

DB Lock (비관적 락)
Optimistic Lock (버전 관리)

✅ 3. 조건 기반 UPDATE

UPDATE product
SET stock = stock - 1
WHERE stock > 0

이렇게 하면
동시에 들어와도 안전하게 처리됨

✅ 4. 큐(Queue) 사용

요청을 순서대로 처리
동시에 실행되지 않게 만듦

⚡ 실무에서 느끼는 포인트

이 문제를 처음 겪으면 이렇게 된다:

“왜 가끔만 터지지?”
“왜 재현이 안 되지?”
“내 코드가 맞는 건가…?”

근데 원인을 알고 나면 바뀐다:

“아, 이건 동시성 문제구나”

한 줄 정리

“가끔만 터지는 버그는, 대부분 동시성 문제다.”

마무리

백엔드 개발에서 진짜 어려운 건
코드를 짜는 게 아니라 ‘상황’을 이해하는 것이다.

특히 동시성은
실무에서 반드시 한 번은 크게 데이는 영역이다.

그래서 미리 알고 있으면
사고를 크게 줄일 수 있다.

SQL 하나 잘못 짰다가 서비스 느려지는 이유 (백엔드 신입 2번째 멘붕)

babytomato — Tue, 31 Mar 2026 09:09:06 +0900

“코드는 문제 없어 보이는데…
왜 서비스가 이렇게 느리지?”

백엔드 개발을 하다 보면
어느 순간부터 API 응답 속도가 미친 듯이 느려지는 경험을 하게 된다.

그리고 대부분의 원인은 코드가 아니라
SQL이다.

실제로 겪는 상황

조회 API 하나가 5초 이상 걸림
사용자가 몰리면 서버가 버벅거림
같은 API인데 어떤 요청은 빠르고 어떤 건 느림

이쯤 되면 이런 생각 든다

“서버가 문제인가…?”
“코드가 비효율적인가…?”

근데 진짜 원인은 따로 있다.

진짜 원인 1: 인덱스를 안 타는 쿼리

이게 가장 흔하고, 가장 치명적이다.

DB는 원래 빠르게 찾으려고 인덱스를 쓴다.
근데 쿼리를 잘못 짜면 인덱스를 못 탄다.

대표적인 실수

WHERE에 함수 사용
컬럼 가공
타입 불일치

WHERE TO_CHAR(created_at) = '2026-03-30'

이렇게 쓰는 순간
인덱스 무시 + 풀스캔

진짜 원인 2: 풀 테이블 스캔 (Full Scan)

인덱스를 못 타면 발생한다.

의미

테이블 전체를 다 뒤짐

결과

데이터 많을수록 지옥

예를 들어 100만 건이면
100만 개를 다 읽는다

진짜 원인 3: JOIN 남용

JOIN 자체가 문제는 아닌데
잘못 쓰면 바로 성능 터진다.

위험한 패턴

불필요한 JOIN
조건 없는 JOIN
다대다 JOIN

결과

쿼리 실행 시간 폭발
메모리 사용 증가

진짜 원인 4: LIMIT 없이 조회

이건 진짜 신입 때 많이 하는 실수

SELECT * FROM user_log

결과

데이터 다 가져옴
네트워크 + 메모리 낭비

진짜 원인 5: 실행 계획을 안 봄

이게 핵심이다.

대부분 이렇게 생각한다:

“쿼리 잘 돌아가니까 괜찮겠지”

근데 DB 입장에서는
“비효율적으로 열심히 돌고 있는 중”

그래서 어떻게 해결하냐

실무에서는 이렇게 한다:

1. 실행 계획(EXPLAIN) 확인

→ 인덱스 타는지 확인

2. WHERE 조건 단순화

→ 컬럼 가공하지 않기

3. 필요한 데이터만 조회

→ SELECT * 금지

4. 인덱스 설계

→ 조회 조건 기준으로 만들기

⚡ 실무에서 바로 체감하는 변화

5초 → 0.1초로 줄어듦
서버 부하 감소
사용자 체감 속도 개선

진짜 체감 확 온다

한 줄 정리

“백엔드는 코드보다 SQL이 성능을 좌우한다.”

마무리

백엔드를 하다 보면 깨닫게 된다.

“코드는 잘 짰는데 왜 느리지?”
“아… SQL이 문제였구나”

이 경험을 몇 번 겪으면
자연스럽게 SQL부터 보게 된다.