ACK, OOO, YAGNI… 개발자 커뮤니티 약어 23개 정리
코드 리뷰를 처음 받을 때 가장 당황스러운 건 지적 내용이 아니라, 그 지적에 붙은 줄임말입니다. “LGTM”이 승인이라는 걸 모르면 칭찬인지 반려인지 알 수가 없죠. 실무에서 실제로 자주 오가는 약어 23개를 뜻과 쓰임새, 그리고 뉘앙스까지 정리했습니다.
“코드 리뷰에서 바로 만나는 것들”
LGTM — Looks Good To Me
“내가 보기엔 괜찮다.” 리뷰어가 승인할 때 답니다. 뉘앙스가 중요한데, “완벽하다”가 아니라 “내가 본 범위에서는 문제를 못 찾았다”에 가깝습니다. 그래서 LGTM을 받고 배포한 코드에서 버그가 나와도 리뷰어 탓을 하지 않는 게 관례입니다.
WIP — Work In Progress
“아직 작업 중.” PR 제목 앞에 [WIP]를 붙여두면 “리뷰는 아직 하지 마세요, 방향만 봐주세요”라는 신호입니다. GitHub에는 Draft PR 기능이 생겨서 요즘은 그쪽을 쓰기도 합니다.
PR — Pull Request
“이 변경을 받아달라”는 요청. 내 브랜치의 변경사항을 원본에 합쳐달라고 여는 것입니다. GitLab에서는 같은 것을 MR(Merge Request)이라고 부르니, 회사를 옮기면 단어가 바뀝니다.
PTAL — Please Take A Look
“한번 봐주세요.” 리뷰를 요청하거나, 수정을 마치고 다시 봐달라고 할 때 씁니다.
ACK — Acknowledged
“확인했습니다.” 원래 네트워크 프로토콜에서 수신 확인 신호를 뜻하는 말인데, 사람 사이 대화로 넘어왔습니다. 답을 길게 쓰지 않고 “봤다”는 사실만 빠르게 알릴 때 씁니다.
NACK — Negative Acknowledgment
ACK의 반대. “봤는데 이대로는 안 됩니다.” 리뷰에서 쓰면 명확한 반대 의사라, 반드시 이유를 함께 적어야 합니다. 이유 없는 NACK만큼 팀을 멈추게 하는 것도 없습니다.
nit — nitpick
“사소한 지적.” 코멘트 앞에 nit:을 붙이면 “고쳐도 되고 안 고쳐도 되는, 반영 안 해도 승인은 한다”는 신호입니다. 오타나 변수명 취향처럼 본질이 아닌 것에 씁니다. 이걸 안 붙이면 상대가 필수 수정으로 받아들여 불필요한 왕복이 생깁니다.
RFC — Request For Comments
“의견을 구합니다.” 확정된 제안이 아니라 논의를 열려고 낸 문서나 PR입니다. 인터넷 표준 문서(RFC 2616 같은)에서 온 표현인데, 지금은 사내 설계 제안서에도 그대로 씁니다.
“의견을 말할 때 붙이는 완충 장치”
IMO / IMHO — In My (Humble) Opinion
“내 생각엔.” IMHO가 조금 더 조심스러운 표현입니다. 사실이 아니라 의견임을 명시해서, 상대가 반박하기 편하게 만들어주는 장치입니다.
AFAIK — As Far As I Know
“내가 아는 한.” 확신이 없다는 걸 미리 밝히는 말입니다. 이 말이 붙은 정보는 검증하고 쓰는 게 좋습니다.
TL;DR — Too Long; Didn’t Read
“너무 길어서 안 읽음.” 원래는 긴 글에 대한 핀잔이었는데, 지금은 글쓴이가 스스로 맨 위에 요약을 달 때 씁니다. 긴 이슈나 설계 문서 첫머리에 TL;DR: 한 줄을 두는 게 예의로 굳었습니다.
FYI — For Your Information
“참고로.” 답을 요구하지 않고 정보만 공유할 때 씁니다. 반대로 답이 필요하면 FYI를 붙이면 안 됩니다 — 상대가 안 읽어도 되는 것으로 분류합니다.
RTFM — Read The Manual
“매뉴얼 좀 읽어라.” 원래 표현에는 욕이 들어갑니다. 문서에 이미 있는 걸 묻는 사람에게 쓰는 면박이라, 지금은 커뮤니티 대부분에서 무례한 말로 취급합니다. 뜻은 알아두되 쓰지 않는 쪽을 권합니다.
“자리와 일정을 알릴 때”
ETA — Estimated Time of Arrival
“언제쯤 됩니까.” 원래 비행기 도착 예정 시각을 뜻하는 말인데, 작업 완료 예상 시점으로 넘어왔습니다. 답할 때는 “내일쯤”보다 “내일 오후”처럼 폭을 좁혀주는 편이 서로 편합니다.
WFH — Work From Home
“재택근무 중.” 자리에 없지만 일은 하고 있다는 뜻이라, 연락은 받는다는 의미를 포함합니다.
OOO — Out Of Office
“부재중.” 휴가나 출장처럼 아예 일을 안 하는 상태입니다. WFH와 헷갈리기 쉬운데, OOO는 “연락하지 마세요”에 가깝습니다. 메일 자동응답에서 자주 보입니다.
AFK — Away From Keyboard
“잠깐 자리 비움.” 온라인 게임에서 온 말이 업무 채팅으로 넘어왔습니다. 분 단위의 짧은 이석에 씁니다.
BRB — Be Right Back
“금방 돌아옴.” AFK와 거의 같은 상황에서 쓰되, 이쪽이 조금 더 가볍고 짧은 느낌입니다.
“설계와 일하는 방식에 관한 말들”
MVP — Minimum Viable Product
“최소 기능 제품.” 검증에 필요한 최소한만 만들어 먼저 내보내는 방식입니다. 스포츠의 MVP(Most Valuable Player)와 철자가 같아서 문맥으로 구분해야 합니다.
POC — Proof Of Concept
“개념 증명.” 되는지 확인하려고 만드는 시험용 구현입니다. 버리는 것을 전제로 만든다는 점이 MVP와 다릅니다. POC 코드가 그대로 운영에 올라가는 게 흔한 사고 유형입니다.
DRY — Don’t Repeat Yourself
“같은 걸 반복하지 마라.” 같은 지식이 여러 곳에 흩어지면 한 곳만 고치고 나머지를 놓치게 된다는 원칙입니다. 다만 우연히 비슷해 보이는 코드까지 억지로 합치면 오히려 결합도만 높아집니다.
YAGNI — You Aren’t Gonna Need It
“그거 필요 없을 거야.” 나중에 필요할 것 같아서 미리 만들어두는 걸 경계하는 말입니다. 대개 그 “나중”은 오지 않고, 안 쓰는 코드를 유지보수하는 비용만 남습니다.
SSOT — Single Source Of Truth
“단일 진실 공급원.” 같은 사실이 두 군데에 적혀 있으면 반드시 어긋난다는 전제에서, 원본을 한 곳으로 정하는 원칙입니다. 문서와 코드가 다른 말을 하는 상황이 대표적인 위반 사례입니다.
“한눈에 보기”
| 약어 | 원문 | 뜻 |
|---|---|---|
| LGTM | Looks Good To Me | 승인. “내가 본 범위에선 문제없다” |
| WIP | Work In Progress | 작업 중. 아직 리뷰하지 말 것 |
| PR | Pull Request | 변경 반영 요청 (GitLab은 MR) |
| PTAL | Please Take A Look | 봐주세요 |
| ACK | Acknowledged | 확인했음 |
| NACK | Negative Acknowledgment | 확인했으나 반대. 이유 필수 |
| 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 | 문서 읽어라 (무례한 표현) |
| ETA | Estimated Time of Arrival | 완료 예상 시점 |
| WFH | Work From Home | 재택근무. 연락은 됨 |
| OOO | Out Of Office | 부재중. 연락 어려움 |
| AFK | Away From Keyboard | 잠깐 자리 비움 |
| BRB | Be Right Back | 금방 돌아옴 |
| 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를 붙이면 확신 없는 정보가 사실처럼 굳지 않습니다.
그래서 상대가 모를 것 같은 약어는 안 쓰는 게 맞습니다. 줄여 써서 아낀 몇 초보다, 무슨 뜻인지 되묻는 왕복이 훨씬 비쌉니다. 특히 NACK처럼 강한 신호는 약어만 던지지 말고 이유를 함께 적어야 합니다.
테크 블로거 성주였습니다.