IT 회사에서 자주 쓰는 약어 정리 (F/U, ASAP, PoC 등)

 

IT 회사 회의나 메신저를 처음 접하면 “한국어인데 문장이 안 들리는” 순간이 있습니다. “ASAP로 부탁드리고, PoC는 이번 주에 보고, F/U는 제가 할게요” 같은 말이 자연스럽게 오가니까요. 단어 자체가 어려운 게 아니라, 줄임말이 빠르게 지나가서 놓치기 쉽습니다.

그래서 IT 회사에서 자주 쓰는 약어 정리를 한 번 만들어두면 꽤 편합니다. 특히 직장인 신입, 인턴, 취준생, 그리고 팀 프로젝트 하는 학생에게 도움이 됩니다. 아래는 뜻만 적어두는 방식이 아니라, “언제 이런 표현이 나오고, 어떻게 대답하면 자연스러운지”까지 묶었습니다.

 

 

 

 

회의에서 자주 나오는 기본 약어

회의에서는 말이 짧아질수록 속도가 빨라집니다. 그래서 ‘일정’과 ‘다음 액션’을 나타내는 약어가 자주 나옵니다. 뜻을 아는 것도 중요하지만, 분위기를 읽는 데 더 도움이 되는 건 “지금 이 말이 나왔다는 건 뭘 하자는 신호인가”입니다.

자주 쓰는 표현

• ASAP: 가능한 한 빨리. “오늘 중이면 좋겠다”에 가까운 뉘앙스로 쓰일 때가 많습니다.
• ETA: 예상 도착/완료 시간. “언제쯤 될까요?”를 짧게 묻는 표현입니다.
• EOD: 오늘 업무 종료 전. “오늘 퇴근 전까지”라는 뜻으로 자주 씁니다.
• FYI: 참고로. “결정은 아니고 공유만”이라는 톤이 붙습니다.

이런 말이 나오면 보통 질문이 따라옵니다. “ETA 언제로 볼까요?” 같은 식입니다. 답변은 길게 설명하기보다 “몇 시까지 가능/어려움”을 짧게 주는 편이 자연스럽습니다. 말이 짧아야 서로 편합니다.

 

 

F/U는 ‘후속 조치’라는 뜻으로 정말 자주 보입니다

F/U는 follow up의 줄임말로, 쉽게 말해 “내가 이어서 챙기겠다”는 의미로 쓰입니다. 회의가 끝날 때 “그건 제가 F/U 할게요” 한 마디로 책임자가 정리되는 순간이 많습니다.

자주 헷갈리는 포인트가 있습니다. F/U는 ‘확정’이 아니라 ‘진행’에 가깝습니다. 예를 들어 외부 업체에 확인해야 하는 일이 있거나, 다른 팀 답변을 기다려야 하는 일이 있을 때 많이 씁니다. 그래서 F/U만 던져놓고 끝내면 다음 주에 또 같은 얘기가 반복됩니다. 결과를 언제 공유할지도 같이 붙이면 깔끔해집니다.

체크 포인트

• “제가 F/U 하겠습니다” = 제가 이어서 확인하고 공유하겠습니다
• 가능하면 “언제까지 공유”를 같이 말하는 편이 좋습니다
• 메신저에서는 “F/U done”처럼 완료 표시로도 씁니다

짧게 말해도, 약속은 남겨두는 편.

 

 

PoC는 ‘가능한지 먼저 시험해보자’는 말입니다

PoC(Proof of Concept)는 “이게 실제로 되는지 먼저 확인해보자”라는 뜻으로 많이 씁니다. 완성품을 만들기 전에, 기술적으로 가능한지, 성능이 나오는지, 비용이 맞는지 등을 작은 범위로 시험해보는 단계입니다.

PoC가 등장하는 순간에는 보통 불확실성이 깔려 있습니다. 새로운 API 연동, AI 기능 도입, 특정 벤더 솔루션 적용 같은 상황이 그렇습니다. 이때 PoC를 한다는 건 “일단 작은 증거를 만들자”는 의미입니다. 그래서 목표를 너무 크게 잡으면 PoC가 본 프로젝트처럼 커지는 일이 생깁니다. 실무에서 흔한 함정입니다.

체크 포인트

• PoC는 완성보다 “가능/불가능 판단”에 초점이 맞춰지는 경우가 많습니다
• 기간과 성공 기준을 짧게 잡는 편이 안전합니다
• 결과는 “수치/비용/리스크” 형태로 남기는 경우가 많습니다

작게 해보고, 빠르게 결론.

 

 

업무 문서에서 자주 나오는 약어

문서나 메일에서는 ‘의도’가 중요합니다. 같은 문장도 “확정”인지 “제안”인지가 달라지기 때문입니다. 이때 자주 쓰는 약어는 톤을 정리하는 역할을 합니다.

• TBD: 미정. 결정 전이라 나중에 채운다는 의미입니다.
• TBC: 확인 중. 확정되면 알려주겠다는 뉘앙스가 섞입니다.
• TL;DR: 요약. 긴 글 앞에 “바쁜 분은 이것만 보세요” 느낌으로 씁니다.
• WIP: 작업 중. “아직 완성 아님”을 표시할 때 씁니다.

문서에서 TBD/TBC가 많아지면 읽는 사람은 불안해집니다. 그래서 “무엇이 미정인지”와 “언제 확정되는지”를 같이 써주는 편이 좋습니다. 짧아도 방향이 보이면 됩니다.

 

 

개발·디자인 협업에서 자주 들리는 약어

개발팀과 같이 일하면 줄임말이 더 빠르게 나옵니다. 다만 겁먹을 필요는 없습니다. 몇 개만 익히면 대화 흐름이 잡힙니다. 모르면 “그 약어가 어떤 상황에서 쓰이는지”만 물어봐도 충분히 자연스럽습니다.

• PR: Pull Request. 변경 내용을 리뷰받고 합치는 요청입니다.
• MR: Merge Request. PR과 비슷한 뜻으로 쓰이는 경우가 있습니다(도구에 따라 표현이 다름).
• QA: 품질 확인/테스트 과정 또는 담당 역할을 말합니다.
• HOTFIX: 긴급 수정. 급한 문제를 빠르게 고치는 상황에서 씁니다.
• RFC: 의견 요청/제안 문서. “이 방향 어떨까요?”를 문서로 던질 때 씁니다.

이 표현들이 나오는 순간은 대부분 “일이 합쳐지기 직전”이거나 “문제가 터진 직후”입니다. 그래서 짧고 명확한 커뮤니케이션이 더 중요해집니다. 말이 길어질수록 오해가 늘어납니다.

 

 

메신저에서 자주 쓰는 ‘톤 조절’ 약어

실무에서 메신저는 속도가 빠른 대신 오해도 빠릅니다. 그래서 분위기를 부드럽게 만들거나, 부담을 줄이는 표현이 자주 붙습니다. 약어는 그 역할을 합니다.

• FYI: 참고로 공유. “결정은 아님” 톤으로 자주 씁니다.
• IMO / IMHO: 제 생각엔. 단정 대신 의견으로 말할 때 씁니다.
• BRB: 잠깐 자리 비움. 팀에 따라 가볍게 쓰입니다.
• LGTM: 좋아 보입니다. 리뷰에서 승인 의미로 자주 보입니다.

이런 표현은 사실 ‘업무 스킬’에 가깝습니다. 같은 내용도 “IMO” 하나 붙이면 분위기가 달라집니다. 팀이 클수록 이런 톤 조절이 은근히 중요합니다.

 

 

초보자가 덜 민망하게 물어보는 방법

약어를 몰랐다고 해서 문제 되는 경우는 거의 없습니다. 다만 “그냥 넘어가다가” 나중에 방향이 어긋나는 게 더 큰 문제입니다. 물어보는 문장만 자연스럽게 준비해두면 됩니다.

• “지금 말씀하신 ○○는 어떤 상황에서 쓰는 말인가요?”
• “○○는 오늘 안에 확정되는 건가요, 공유용인가요?”
• “PoC면 범위가 어느 정도까지일까요?”

이렇게 물으면 대화 흐름을 해치지 않으면서도, 필요한 정보를 확보할 수 있습니다. 처음엔 한 번만 물어보면 됩니다. 두 번째부터는 내가 더 빨라집니다.

 

 

자주 묻는 질문

Q. F/U는 무조건 내가 한다는 뜻인가요?
A. 보통은 “내가 이어서 확인하고 공유하겠다”는 의미로 씁니다. 다만 팀에 따라 ‘담당자 지정’처럼 쓰이기도 하니, 언제 공유할지까지 붙이면 오해가 줄어듭니다.

Q. ASAP는 ‘당장’이라는 뜻인가요?
A. 상황에 따라 다릅니다. 정말 급할 때도 있지만, 관성적으로 붙는 경우도 있습니다. 그래서 “오늘 가능한가요, 내일 오전까지면 될까요?”처럼 확인 질문이 안전합니다.

Q. PoC는 시제품을 만드는 건가요?
A. 완성품이라기보다 “가능성 확인”에 가까운 경우가 많습니다. 기간과 성공 기준을 짧게 잡으면 PoC가 과하게 커지는 걸 막을 수 있습니다.

Q. FYI는 답장을 안 해도 되나요?
A. 공유만이라는 의미로 쓰이지만, 확인이 필요한 경우도 있습니다. 중요한 공유라면 “확인했습니다” 정도로 짧게 반응하는 편이 안전합니다.

Q. LGTM은 정확히 어떤 의미인가요?
A. 코드 리뷰에서 “문제 없어 보이고 승인한다” 쪽으로 자주 씁니다. 팀 규칙에 따라 “한 번 더 테스트 후 머지” 같은 조건이 붙기도 합니다.

Q. 약어를 모르면 실무에서 불리한가요?
A. 처음엔 누구나 모릅니다. 다만 계속 넘어가면 불리해집니다. 자주 쓰는 약어 20개정도 처음에 익혀두면 도움이 많이 됩니다

 

---

 

IT 회사에서 자주 쓰는 약어 정리는 외우는 게 목적이 아니라, 회의에서 길을 잃지 않게 해주는 장치에 가깝습니다. F/U, ASAP, PoC 같은 표현은 “지금 무엇을 하자는지”를 알려주는 신호로 보면 편합니다.