미국 회사생활의 키워드
업무를 레벨업 시켜주는 마법 단어들
이제 미국에서 생활한 지 8년, 업계에 종사한 지 4년 정도가 되어간다. 그중 2년은 바이오 업계, 그리고 나머지는 테크기업에서 일했지만 하는 일이 결국엔 코드 짜기여서 그런지 업무상 사용하는 단어들은 다 비슷비슷한 것 같다. 그중 흔히 사용하는 키워드를 정리해 보자면 보자면
Onboarding: 신입 수습과정. 신규 입사자가 조직에 순조롭게 적응하고 정착할 수 있도록 지원하는 과정. 영어로 '배에 탄다'는 뜻으로 신규 직원이 조직에 수월히 적응할 수 있도록 업무에 필요한 지식이나 기술 등을 안내·교육하는 과정을 뜻한다.
Onboarding buddy: 사수, 수습과정 때 질문을 답해줄 사람.
OKR (Objective Key Results): 주어진 시간 안에 이루고자 하는 목표. 흔히 팀이나 조직의 목표를 외부에 공개하며 계획하는 용도로 세워진다.
KPI (Key Performance Indicator): 윗 경영진이 가장 신경 쓰는 비즈니스 지표. 측정 가능한 숫자여서 매달/매주/심하면 매일 업데이트를 받는다.
Abbreviations / One sentence definitions/Glossary: 팀 내 업무에 따라서 가장 많이 쓰이는 전문 용어들을 약자(Abbreviations)나 한 줄 정의 (One sentence definitions) 혹은 용어정리 (Glossary) 페이지에 정리해 놓는다. 새로 팀을 조인했거나 새로운 업무 환경에 놓여있을 때 사수나 매니저에게 이 전문 용어들을 요청하면 좀 더 빨리 팀에 적응할 수 있다. 만약 그런 리소스가 없다면 온보딩 할 때 용어들을 정리해 둔 뒤 팀에 적응 한 뒤 전체에 공유하면 업무환경을 개선시킬 수 있다 (Process Improvement). 승진할 때 쓸거리가 생겨서 좋음.
Individual Contributor (IC): 사람 관리 업무가 없는 조직원. 대다수의 경우 승진하면서 사람 관리 업무가 주어지지만 전설적인 엔지니어의 경우 승진여부에 상관없이 IC로 남아있을 수 있다 (ex: 제프 딘)
PA (Product Area): 계열사. 예를 들어 삼성 아래 전자 / 화재 / 물산 등등이 있는 것처럼 알파벳/메타에서 각 다른 조직을 부를 때 사용된다.
Scope: 업무 범위. 일을 받아서 할 때, 업무의 경계선 파악이 매우 중요하다 (Out of scope)
Impact: 업무 성과. 일을 받았을 때 왜 해야 하는지, 달성했을 때 얻는 회사의 이익을 파악하는 게 매우 중요하다. 팀의 OKR/KPI 등의 객관적 결과(Quantitative Result)로 직결되는 게 가장 좋으나 업무에 따라 주관적인 결과(Qualitative Result)도 포함할 수 있다.
Role & Responsibility: 역할과 책임. 특히 협업을 할 때, 어느 팀에서 어떤 역량으로 참여하는지 명시하는 데 사용된다. 예를 들어 역할은 Contributor - 참여자 / Reviewer - 검토자 / Approver - 결정권자 / Audience - 관심이 있어 업데이트받고자 하는 자들로 분류된 뒤 세분화할 수 있다. 그 외에 책임은 RACI (Responsible / Accountable / Consulted / Informed) + Supportive로 나눠질 수 있다.
다음은 개발자 팀에서 흔히 사용되는 용어들이다.
Standup: 참석자 모두가 발표할 게 있는 팀미팅. 일어나서 선 상태에서 각자 업데이트를 하고 중요 뉴스를 간결하게 나누는 것을 지양하지만 팀(혹은 매니저마다)마다 다를 수 있음 주의.
Sprint: 프로젝트 계획을 세우는 시간 단위. 가장 흔하게 2주를 잡고 그에 맡게 업무를 배정받는다.
Oncall: 당직. 문제가 생겼을 때 팀을 대변하여 바로 응답할 수 있는 사람을 돌아가면서 맞는다.
Standard Operation Procedures (SOPs): 돌발상황 대처 매뉴얼. 특히 당직 때 자주 일어나는 이슈를 어떻게 대응해야 하는지 적어놔서 당직 서는 팀원 모두가 획일화된 대처법을 취할 수 있기 위해 사용된다.
SLO/SLI (Service Level Objective/Indicator): 원래 의미는 약속된 시스템 안전성 (ex: 9의 개수)으로 사용되지만 당직 때 약속된 응답 시간 (3분 내 답변 혹은 24시간 내 확인)을 지칭하는 데 사용되기도 한다.
Design Document: 새로운 시스템을 개발하기에 앞서 여러 방안들을 비교한 뒤 가장 합리적으로 판단되는 방안을 제시하는 제안서. 시스템 범위에 따라서 큰 디자인은 High Level Design Document (HLDD), 그 외에 기존에 디자인닥에 기반한 Low Level Design Document (LLDD)으로 나누어진다.
Spike: 익숙하지 않은 업무를 맡았을 때 일을 시작하기에 앞서 업무의 방향 밑 범위, 테스트 방법, 필요한 리소스 밑 시간, 결재받아야 할 책임자들 등등을 미리 정리하는 글. 돌다리도 두들긴다음 건너라고, 돌다리 제대로 두들겨 보았고 건널 준비 완료되었습니다를 보여주는 목적으로 쓴다. 다만 신입 때는 사수/매니저가 저 대신 돌다리를 두들겨 주었습니다, 저에게 이정도의 쉬운 다리 정도는 빠르게 건널 능력이 있습니다를 보여주기 위해 시키는 대로 까는 것도 필요한 것 같다.
Frontend: 웹사이트/모바일앱 같이 비개발자들이 주로 사용하는 시스템. 요즘은 비개발자들이 바로 보는 영역을 아우를 때도 사용되는 것 같다.
Backend: 개발자들만 보는 시스템 영역. 바로 유저 눈에 보이지 않는 뒷면을 지칭할 때도 사용되는 것 같다.
Infra(structure): 개발자들을 위한 개발의 영역. CI/CD (Continuous Integration/Continuous Development, 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포)나 설정 관리 (Config store)등의 분야들이 있다.
별 것 아니지만 일하는데 써주면 그럴싸해져서 애용하는 단어들. 혹은 자주 쓰이는데 정확하게 이게 뭐지 라는 궁금증을 해소하는데 도움이 되었으면 한다.
