LGTM, WIP… 개발자 커뮤니티 줄임말 15가지
코드 리뷰를 처음 받을 때 가장 당황스러운 건 지적 내용이 아니라, 그 지적에 붙은 줄임말입니다. “LGTM”이 승인이라는 걸 모르면 칭찬인지 반려인지 알 수가 없죠. 개발자 커뮤니티에서 실제로 자주 쓰이는 줄임말 15가지를 뜻과 쓰임새로 정리했습니다.
“코드 리뷰에서 바로 만나는 것들”
리뷰 코멘트나 PR 제목에서 가장 먼저 마주치게 되는 말들입니다.
1. LGTM — Looks Good To Me “내가 보기엔 괜찮다.” 리뷰어가 승인할 때 답니다. 뉘앙스가 중요한데, “완벽하다”가 아니라 “내가 본 범위에서는 문제를 못 찾았다”에 가깝습니다. 그래서 LGTM을 받고 배포한 코드에서 버그가 나와도 리뷰어 탓을 하지 않는 게 관례입니다.
2. WIP — Work In Progress “아직 작업 중.” PR 제목 앞에 [WIP]를 붙여두면 “리뷰는 아직 하지 마세요, 방향만 봐주세요”라는 뜻입니다. GitHub에는 Draft PR 기능이 생겨서 요즘은 그쪽을 쓰기도 합니다.
3. PTAL — Please Take A Look “한번 봐주세요.” 리뷰를 요청하거나, 수정을 마치고 다시 봐달라고 할 때 씁니다.
4. nit — nitpick “사소한 지적.” 코멘트 앞에 nit:을 붙이면 “고쳐도 되고 안 고쳐도 되는, 반영 안 해도 승인은 한다”는 신호입니다. 오타나 변수명 취향처럼 본질이 아닌 것에 씁니다. 이걸 안 붙이면 상대가 필수 수정으로 받아들여 불필요한 왕복이 생깁니다.
5. RFC — Request For Comments “의견을 구합니다.” 확정된 제안이 아니라 논의를 열려고 낸 문서나 PR입니다. 인터넷 표준 문서(RFC 2616 같은)에서 온 표현인데, 지금은 사내 설계 제안서에도 그대로 씁니다.
“의견을 말할 때 붙이는 완충 장치”
단정을 피하고 여지를 남기는 표현들입니다. 원격·비동기로 일할수록 자주 쓰입니다.
6. IMO / IMHO — In My Opinion / In My Humble Opinion “내 생각엔.” IMHO가 조금 더 조심스러운 표현입니다. 사실이 아니라 의견임을 명시해서, 상대가 반박하기 편하게 만들어주는 장치입니다.
7. AFAIK — As Far As I Know “내가 아는 한.” 확신이 없다는 걸 미리 밝히는 말입니다. 이 말이 붙은 정보는 검증하고 쓰는 게 좋습니다.
8. TL;DR — Too Long; Didn’t Read “너무 길어서 안 읽음.” 원래는 긴 글에 대한 핀잔이었는데, 지금은 글쓴이가 스스로 맨 위에 요약을 달 때 씁니다. 긴 이슈나 설계 문서 첫머리에 TL;DR: 한 줄을 두는 게 예의로 굳었습니다.
9. FYI — For Your Information “참고로.” 답을 요구하지 않고 정보만 공유할 때 씁니다. 반대로 답이 필요하면 FYI를 붙이면 안 됩니다 — 상대가 안 읽어도 되는 것으로 분류합니다.
10. RTFM — Read The Manual “매뉴얼 좀 읽어라.” 원래 표현에는 욕이 들어갑니다. 문서에 이미 있는 걸 묻는 사람에게 쓰는 면박이라, 지금은 커뮤니티 대부분에서 무례한 말로 취급합니다. 뜻은 알아두되 쓰지 않는 쪽을 권합니다.
“설계와 일하는 방식에 관한 말들”
리뷰 코멘트보다는 회의나 설계 문서에서 만나는 축약어입니다.
11. MVP — Minimum Viable Product “최소 기능 제품.” 검증에 필요한 최소한만 만들어 먼저 내보내는 방식입니다. 스포츠의 MVP(Most Valuable Player)와 철자가 같아서 문맥으로 구분해야 합니다.
12. POC — Proof Of Concept “개념 증명.” 되는지 확인하려고 만드는 시험용 구현입니다. 버리는 것을 전제로 만든다는 점이 MVP와 다릅니다. POC 코드가 그대로 운영에 올라가는 게 흔한 사고 유형입니다.
13. DRY — Don’t Repeat Yourself “같은 걸 반복하지 마라.” 같은 지식이 여러 곳에 흩어지면 한 곳만 고치고 나머지를 놓치게 된다는 원칙입니다. 다만 “우연히 비슷해 보이는 코드”까지 억지로 합치면 오히려 결합도만 높아집니다.
14. YAGNI — You Aren’t Gonna Need It “그거 필요 없을 거야.” 나중에 필요할 것 같아서 미리 만들어두는 걸 경계하는 말입니다. 대개 그 “나중”은 오지 않고, 안 쓰는 코드를 유지보수하는 비용만 남습니다.
15. SSOT — Single Source Of Truth “단일 진실 공급원.” 같은 사실이 두 군데에 적혀 있으면 반드시 어긋난다는 전제에서, 원본을 한 곳으로 정하는 원칙입니다. 문서와 코드가 다른 말을 하는 상황이 대표적인 위반 사례입니다.
“한눈에 보기”
| 줄임말 | 원문 | 뜻 |
|---|---|---|
| LGTM | Looks Good To Me | 승인. “내가 본 범위에선 문제없다” |
| WIP | Work In Progress | 작업 중. 아직 리뷰하지 말 것 |
| PTAL | Please Take A Look | 봐주세요 |
| nit | nitpick | 사소한 지적. 반영은 선택 |
| RFC | Request For Comments | 의견 구함. 확정 아님 |
| IMO/IMHO | In My (Humble) Opinion | 내 생각엔 |
| AFAIK | As Far As I Know | 내가 아는 한 (확신 없음) |
| TL;DR | Too Long; Didn’t Read | 요약 |
| FYI | For Your Information | 참고만. 답 불필요 |
| RTFM | Read The Manual | 문서 읽어라 (무례한 표현) |
| MVP | Minimum Viable Product | 최소 기능 제품 |
| POC | Proof Of Concept | 개념 증명. 버릴 코드 |
| DRY | Don’t Repeat Yourself | 반복하지 마라 |
| YAGNI | You Aren’t Gonna Need It | 미리 만들지 마라 |
| SSOT | Single Source Of Truth | 원본은 한 곳에 |
“줄임말보다 중요한 것”
이런 말들이 자리 잡은 이유는 멋있어서가 아니라, 비동기로 일할 때 오해를 줄이기 위해서입니다. nit:을 붙이면 상대가 필수 수정으로 오해하지 않고, AFAIK를 붙이면 확신 없는 정보가 사실처럼 굳지 않습니다.
그래서 상대가 모를 것 같은 줄임말은 안 쓰는 게 맞습니다. 줄여 써서 아낀 몇 초보다, 무슨 뜻인지 되묻는 왕복이 훨씬 비쌉니다.
-테크 블로거 성주였습니다.