개발 문화/협업에서 자주 쓰는 용어 정리

 

 

• 리뷰 용어 (LGTM, nit, blocking)
• 업무 용어 (ETA, RCA, hotfix)
• 개발 문화 밈 (yak shaving, bikeshedding, works on my machine)
• 코드 품질 은어 (footgun, spaghetti code, god object)
• 협업 표현 (PTAL, FYI, ACK)

1. 리뷰(Code Review) 용어

LGTM

Looks Good To Me

코드 리뷰 승인 표현.
“문제 없어 보인다”, “머지해도 된다”는 의미로 사용된다.

---

nit / nitpick

사소한 수정 의견.

주로:

• 변수명
• 공백
• 스타일
• 가독성

같은 치명적이지 않은 부분에 사용한다.

예:

nit: 변수명 조금 더 명확하면 좋을 듯

 

---

blocking

반드시 수정되어야 하는 문제.

예:

• 버그 가능성
• null 처리 누락
• race condition
• 보안 문제

등이 있으면 “blocking” 리뷰를 남긴다.

---

non-blocking

필수 수정은 아니지만 개선 제안이라는 의미.

---

PTAL

Please Take A Look

리뷰 요청 표현.

보통 PR 올린 뒤:

PTAL

 

처럼 짧게 남긴다.

---

2. 업무/운영 용어

ETA

Estimated Time of Arrival

예상 완료 시간.

예:

ETA 2 hours

 

---

RCA

Root Cause Analysis

장애의 근본 원인 분석.

단순히 “무슨 에러가 났다”가 아니라:

• 왜 발생했는가
• 왜 감지 못했는가
• 재발 방지는 어떻게 하는가

까지 분석하는 문서/과정을 의미한다.

---

hotfix

긴급 수정 배포.

정식 릴리즈를 기다리지 않고 즉시 수정해야 하는 상황에서 사용한다.

예:

• 결제 오류
• 로그인 장애
• 치명적 버그

---

rollback

배포 이전 상태로 되돌리는 것.

배포 후 장애 발생 시 빠르게 이전 버전으로 복귀한다.

---

postmortem

장애 회고 문서.

대형 서비스에서는 장애 이후:

• 타임라인
• 영향 범위
• 원인
• 대응
• 개선책

을 정리한다.

---

3. 개발 문화/밈

yak shaving

원래 하려던 작업과 무관한 준비 작업이 끝없이 늘어나는 상황.

예:

• 버그 수정하려고 시작
• formatter 수정
• docker 수정
• CI 수정
• dependency 업데이트

결국 원래 작업 못함.

개발자들이 매우 자주 겪는 상황이라 밈처럼 사용된다.

---

bikeshedding

중요하지 않은 주제로 과도하게 토론하는 현상.

예:

• 버튼 색상
• 변수명
• 들여쓰기

같은 사소한 것에 회의 시간이 과도하게 소비되는 경우.

중요한 아키텍처 결정은 오히려 빨리 지나가는 경우가 많다는 데서 나온 표현이다.

---

works on my machine

“내 컴퓨터에서는 되는데?”

환경 차이 때문에 발생하는 대표적인 개발 밈.

예:

• OS 차이
• 환경변수 차이
• dependency 버전 차이
• Docker 미사용

등이 원인인 경우가 많다.

---

cargo cult programming

이유를 이해하지 않고 코드를 복붙하는 것.

예:

이 설정 왜 넣었어요?
→ 인터넷에서 다 이렇게 하던데요

 

---

4. 코드 품질 관련 은어

footgun

사용자가 실수하기 매우 쉬운 구조/API.

“스스로 자기 발을 쏘는 총”이라는 의미의 은어.

예:

• dangerous default option
• null 안전성 없는 API
• 실수하면 데이터 삭제되는 함수

---

spaghetti code

코드 구조가 서로 얽혀 매우 복잡한 상태.

특징:

• 흐름 추적 어려움
• 의존성 과다
• 수정 시 사이드이펙트 발생

---

god object / god class

모든 책임이 한 클래스에 몰린 상태.

예:

• 인증
• DB 접근
• 비즈니스 로직
• 캐시
• API 호출

전부 하나의 클래스에서 처리.

객체지향 설계에서 대표적인 안티패턴으로 본다.

---

boilerplate

반복적으로 작성되는 틀 코드.

예:

• getter/setter
• 설정 코드
• DTO 매핑 코드

---

legacy code

오래되었고 수정이 위험한 코드.

보통:

• 테스트 부족
• 의존성 복잡
• 작성자 퇴사
• 문서 없음

등의 특징을 가진다.

---

5. 협업 표현

FYI

For Your Information

참고용 정보 전달.

즉각적인 액션 요구는 아님.

---

ACK

Acknowledged

확인했고 이해했다는 의미.

네트워크/분산시스템에서도 많이 사용한다.

---

NACK

Negative Acknowledgement

반대 또는 거부 의미.

---

IMO / IMHO

• IMO = In My Opinion
• IMHO = In My Humble Opinion

“내 생각에는” 정도의 표현.

---

SGTM

Sounds Good To Me

좋아 보인다는 의미.

LGTM보다 조금 더 가벼운 느낌으로 사용되기도 한다.

---

전체적인 특징과 개발 문화적 의미

이런 용어들은 단순 줄임말이 아니라 개발 조직의 협업 효율을 높이기 위해 발전한 일종의 공용 언어에 가깝다.

특히:

• 코드 리뷰 속도 향상
• 의사소통 비용 감소
• 문제 심각도 구분
• 장애 대응 체계화
• 개발 문화 공유

에 큰 역할을 한다.

예를 들어:

• “nit”은 치명적 문제 아님을 즉시 전달하고
• “blocking”은 반드시 수정 필요함을 명확히 전달하며
• “works on my machine”은 환경 일관성 문제를 상징적으로 표현한다.

또한 “yak shaving”, “bikeshedding” 같은 표현은 단순 농담이 아니라 실제 개발 생산성을 떨어뜨리는 조직 문제를 풍자하는 문화적 표현으로도 사용된다.

결국 이런 용어들은 단순 영어 약자가 아니라:

• 개발팀의 사고방식
• 협업 방식
• 품질 기준
• 엔지니어링 문화

를 압축해서 담고 있는 표현들이라고 볼 수 있다.