저는 서울에 사는 뉴질랜드 사람입니다. 이 글은 안에서 본 한국 개발 현장, 채용 테이블의 양쪽에서 본 모습, 그리고 한국에서 일해 보려는 사람에게 해 주고 싶은 이야기입니다. 외국인 개발자를 뽑으려는 한국 팀에게도 드릴 말이 조금 있습니다.

어떻게 여기까지 왔나

#

시작은 석사였습니다. 뉴질랜드에서 Waikato 대학교 학사를 마치고 통신사에서 1년간 네트워크 운영 일을 한 뒤, 2017년 3월부터 2019년 2월까지 경희대학교에서 컴퓨터공학 석사 과정을 밟았습니다. 연구실은 학기마다 국내 학회인 KSC와 KCC에 나갔습니다. 2018년 평창에서 열린 KSC에는 한국의 대형 IT 기업 여러 곳이 후원사로 참여했고 취업 준비생을 위한 채용 부스도 있었습니다. 한국에서 대학원을 다니는 외국인이라면 알아 두면 좋은 사실입니다.

그 뒤로는 이렇게 지나왔습니다.

엔지니어링은 익숙한 절반이었습니다. 소프트웨어를 출시하는 일의 상당 부분이 사실은 운영이라는 걸 배운 곳이 고객 지원 스타트업이었고, 크리에이터 플랫폼의 백엔드는 지금의 제가 고를 법한 것보다 훨씬 많은 스택 위에서 돌아갔습니다. 한국만의 차이는 가장자리에 있습니다. 네이버는 신경 써야 하는 검색 엔진입니다. Kiwi Alumni 웹사이트를 새로 열었을 때도 SEO를 구글과 네이버 양쪽에 맞춰 했습니다. 한국 플랫폼들은 짐작하기 어려운 이름으로 크롤링을 합니다(네이버 크롤러는 Yeti이고, 카카오톡 링크 미리보기는 kakaotalk-scrap이라는 녀석이 가져갑니다). 그리고 한국 인터넷 뱅킹은 아직도 내 컴퓨터에 자기네 보안 프로그램을 깔라고 하죠.

하지만 어느 것도 어려운 부분은 아닙니다.

눈치란 무엇이고, 왜 ‘optics’가 아닌가

#

한국 독자에게 눈치를 설명하는 건 좀 쑥스럽지만, 밖에서 들어온 사람의 눈에 어떻게 보이는지 적어 보겠습니다. 눈치는 상대가 무엇을 생각하고 원하고 기대하는지를, 말이 아니라 상황에서 알아차리는 감각입니다. 『The Power of Nunchi』(2019)로 눈치를 영어권에 가장 널리 알린 유니 홍(Euny Hong)은 이 단어를 ’eye-measure’, 그러니까 ‘눈으로 재는 것’이라고 옮겼습니다. 눈치가 빠른 사람은 분위기를 금방 읽고, 눈치가 없는 사람은 전혀 못 읽습니다. 칭찬이 아니죠. 그리고 눈치를 본다는 건 다른 사람, 대개는 윗사람의 반응을 계속 살피면서 미움받지 않는 쪽으로 자신을 맞추는 일입니다.

영어권 사람들이 이럴 때 꺼내는 단어가 ‘optics’인데, 저는 틀린 단어라고 생각합니다. optics는 실제가 어떻든 밖에서 어떻게 보이느냐의 문제입니다. “구조조정 발표와 같은 주에 보너스를 발표하면 optics가 나쁘다” 같은 식이죠. 겉모습의 문제이고, 관리하는 쪽은 보이는 사람입니다. 눈치는 대체로 반대 방향을 가리킵니다. 내가 남에게 어떻게 보이느냐가 아니라 내가 남을 얼마나 잘 보느냐의 문제입니다. 둘이 만나는 지점은 ‘눈치를 본다’뿐입니다. 남들을 지켜보면서 남들 눈에 내가 어떻게 보일지를 관리하는 것. 해외 기사에서 한국 직장 문화를 다룰 때 나오는 게 바로 이 버전입니다.

그런 기사에 나오는 예시는 늘 비슷합니다. 팀장보다 먼저 퇴근하지 않기, 연차 쓸 때 보는 눈치, 회식에서 언제 일어나도 되는지 알기, 윗사람 말에 반대할 때 회의 중에 할지 끝나고 조용히 할지 정하기. 각각을 어떻게 보든, 모양은 같습니다. 모두가 따르지만 아무도 말하지 않는 규칙이라는 점입니다.

그리고 이건 언어와는 별개의 문제입니다. 한국어는 말 속에 있고, 눈치는 말을 둘러싼 모든 것 속에 있습니다.

개발팀에서 눈치가 드러나는 곳

#

개발팀은 바로 그 모양으로 돌아갑니다. 처음 매니저를 맡고 몇 달 뒤 팀 규범에 관한 글을 썼는데, 첫머리가 이랬습니다. 제가 다룬 마찰의 대부분은 기술 문제가 아니었다. 코드 리뷰가 얼마나 빨리 돌아와야 하는지, ‘완료’가 정확히 무슨 뜻인지, 두 번 핑하는 게 무례한지에 대해 사람마다 말하지 않은 가정이 달랐을 뿐이다. 그때는 그 단어를 쓰지 않았지만, 그 목록은 한 줄 한 줄이 다 눈치로 읽어 내야 하는 것들입니다. 팀이 말없이 합의한 규칙이고, 새로 온 사람은 지켜보는 것 말고는 배울 방법이 없습니다.

같은 글에서 저는 신입이 규범을 온보딩 때 명시적으로 듣는 대신 ‘구전 설화처럼’ 배운다고 투덜댔고, 글로벌 팀이 자기 기준을 모두의 기준으로 여긴다고도 썼습니다. 눈치가 무엇으로 돌아가는지 설명할 때 제가 찾은 가장 좋은 영어 단어가 folklore, 구전 설화입니다. 팀에 외국인이 나 혼자라면 어긋난 기준은 내 쪽이고, 그 설화는 어디에도 적혀 있지 않습니다.

비용이 가장 크게 드는 곳은 스탠드업입니다. 2023년에 제가 맡았던 프로젝트가 늦어지는데 누가 물어봐 주기만 기다렸던 이야기를 쓴 적이 있습니다. 3주 뒤에야 누군가 물었고, 그때는 이미 재앙이었습니다. 눈치가 좋다고 이게 해결되지는 않습니다. 분위기를 읽으면 아무도 듣고 싶어 하지 않는 말이 무엇인지는 알게 되지만, 그래도 말하라고 알려 주지는 않으니까요. 제가 얻은 습관은 기다림의 정반대입니다. 누가 묻기 전에 먼저, 글로 말하는 것. “생각보다 오래 걸리고 있습니다. 5일이 아니라 8~10일 정도로 보고 있습니다. 범위를 줄일까요, 마감을 미룰까요?”

내가 읽히는 쪽이 됐을 때

#

2024년 2월 서울의 한 소프트웨어 회사에서 엔지니어링 팀을 맡으면서 눈치의 방향이 뒤집혔습니다. 개발자일 때는 제가 분위기를 읽는 쪽이었습니다. 매니저가 되니 제가 곧 분위기였습니다. 회의에서 한 말과 하지 않은 말, 답장 속도, 퇴근 시간까지 전부 다른 사람이 읽을 수 있는 것이 됐습니다.

프로젝트 리드 시절에 썼던 것들 상당수가 매니저가 되면 더 강하게 적용됩니다. 사람들이 무엇이 망가졌는지 편하게 말하지 못하면, 매니저가 가장 늦게 알게 됩니다. 정보를 너무 오래 쥐고 있으면 사람들은 그걸 느끼고, 내가 남긴 침묵은 소문이 채웁니다. 회의에서 다섯 명이 내 답을 기다릴 때 “모르겠습니다"는 실패처럼 느껴지는데, 바로 그래서 말할 가치가 있습니다. 그리고 제가 늘 되새기는 한 줄. 사람들은 내 의도를 읽을 수 없고, 내 말만 읽을 수 있습니다. 눈치로 돌아가는 팀에서는 그래도 읽으려고 합니다. 표정에서, 내가 건너뛴 것에서, 퇴근 시간에서요. 그러니 추측할 거리를 줄여 주는 게 맞습니다.

제가 기댄 건 화려하지 않은 것들이었습니다. 모든 팀원과의 1:1. 스프린트가 아니라 그 사람에 대한 이야기를 하고, 대부분의 일을 해 주는 평범한 질문을 던졌습니다. “업무에 도움이 되도록 저나 팀이 해 줄 수 있는 게 있을까요?”

모두가 볼 수 있는 곳에 적어 둔 서너 개, 많아야 다섯 개의 짧은 팀 규범. 매니저가 규범을 어기면 어떻게 되는지도 포함해서요. 여덟 명이 모인 자리에서는 절대 입을 열지 않을 사람에게 기다리지 않고 직접 찾아가 묻기. 그리고 다시는 언급되지 않을 “한번 보죠” 대신 솔직한 “안 됩니다, 이유는 이렇습니다”. 애매한 대답은 눈치 볼 거리를 하나 더 늘릴 뿐이니까요. 제가 온 지 한 달쯤 됐을 때 프로덕트 팀 워크숍은 카페에서 서로의 가치관과 팀 규범을 이야기하는 시간으로 시작했습니다. 회사가 눈치에 내놓을 수 있는 답으로는 이보다 직접적인 게 드물 겁니다. 평소에 말하지 않는 것들을 소리 내어 말하는 데 오전 한나절을 쓴 셈이니까요.

외국인으로 채용된다는 것

#

한국 채용에 관한 플레이북 같은 건 없습니다. 제게 있는 건 채용 매니저 쪽에서 본 경험이고, 거기서 나오는 조언은 결국 계약서에 서명하기 전에 회사를 향해 눈치를 쓰라는 겁니다.

매니저로서 채용할 때 제가 가장 뽑고 싶었던 개발자들은 채용 사이트에 한 번도 없었습니다. 그리고 예전에도 썼듯이 창업자들은 이미 같이 일해 본 사람을 훨씬 뽑고 싶어 합니다. 그러니 가장 좋은 입구는 사람들이 내가 일하는 모습을 먼저 볼 수 있는 곳입니다. 작은 회사 인턴십은 조용히 정규직 제안으로 바뀌는 경우가 많습니다. 해커톤은 주말 내내 그걸 보여 줄 기회입니다. 2023년에 저는 루닛 글로벌이 주최한 Seoul Tech Impact Hackathon에서 네 명이 한 팀으로 우승했습니다. 만든 건 한국에서 주소가 없는 길거리 음식 노점을 찾아 주는 앱이었습니다.

그리고 커피챗이 있습니다. 편한 대화에서 사람이 어떻게 행동하는지가 연습한 면접보다 같이 일하는 모습을 훨씬 더 많이 알려 준다고 썼는데, 이건 양방향입니다. 후보자에게는 팀 안에 들어가기 전에 그 팀을 읽어 볼 유일한 기회입니다. 후보자 자리에 앉는다면 저는 이렇게 묻겠습니다. 지금 팀이 마주한 가장 큰 과제는 무엇인가, 왜 합류했고 무엇 때문에 계속 있는가, 그리고 여기서 일하면서 저를 놀라게 할 만한 게 있다면 무엇인가. 마지막 질문은 눈치를 미리 알려 달라고 정중하게 부탁하는 방법입니다. 이직률이나 회사 방향에 대해 얼버무리는 대답이 돌아온다면, 그것만으로도 많은 걸 알 수 있습니다.

외국인 개발자를 채용하려는 팀에게

#

한국에서 팀을 운영하면서 외국인 개발자를 채용하려 한다면, 가장 도움이 되는 건 그 팀 규범 글에 썼던 한 구절입니다. 암묵적인 것을 명시적으로 만드세요. 새로 온 사람이 팀의 규칙을 구전 설화처럼 배우게 두지 마세요. 첫 주에 알려 주세요. 리뷰는 보통 얼마 안에 돌아오는지, ‘완료’가 무슨 뜻인지, 두 번 핑하는 게 무례한지, 사람들이 실제로 몇 시에 퇴근하는지, 연차를 쓸 때 신청서 말고 신경 쓸 게 더 있는지. 마지막 두 개가 전형적인 눈치 질문입니다. 팀 안에 있는 사람은 말할 생각조차 못 하는 것들이죠.

외국인 개발자의 입장에서 보면, 한국어를 잘하는 것과 이런 규칙을 아는 것은 전혀 다른 문제입니다. 한국어가 유창한 외국인도 눈치 앞에서는 신입이고, 정작 본인은 무엇을 모르는지조차 모릅니다. 그래서 물어봐 주기를 기다리기보다 먼저 알려 주는 쪽이 훨씬 빠릅니다.

그다음은 읽을 거리를 줄여 주는 지루한 습관들입니다. 누가 묻기 전에 먼저 말하기. 금요일에 이해관계자들에게 세 줄짜리 메일(이번 주에 나간 것, 다음에 할 것, 걱정되는 것)을 보내는 데는 10분이면 됩니다. 회의에서 조용한 사람을 기다리지 말고 직접 묻기. “안 됩니다"를 포함해 진짜 대답을, 이유와 함께 주기. 그리고 모든 후보자를 같은 질문과 같은 평가 기준으로 면접 보기. 이건 저도 배우는 데 시간이 좀 걸렸지만, 사람을 공정하게 비교하는 유일한 방법입니다. 안 그러면 가장 최근에 이야기한 사람에게 점수를 더 주게 됩니다. 그리고 이렇게 하면 팀의 말하지 않는 규칙을 모르는 후보자도, 아는 후보자와 똑같은 질문을 받게 됩니다.

여기 있는 뉴질랜드 커뮤니티

#

2018년, 아직 학생이던 시절에 Kiwi Chamber 리더십 조찬 행사에서 사진을 찍었고, 그 뒤에 두 나라의 관계를 넓히는 행사에서 봉사하는 게 정말 즐겁다고 적었습니다. 2020년 1월부터는 Kiwi Alumni의 회장을 맡고 있습니다. 한국에 사는 뉴질랜드 사람들, 그리고 뉴질랜드에서 공부하고 지금은 한국에서 살며 일하는 사람들의 커뮤니티입니다. 자원봉사 자리이고, 대부분은 사람을 챙기는 일입니다. 행사를 기획하고, 주한 뉴질랜드 대사관과 교육 기관들과 관계를 쌓고, 새 로고나 회원들이 실제로 원하는 걸 찾을 수 있는 웹사이트 같은 티 안 나는 일도 합니다. 2023년에는 대사관과 함께 Kiwi Alumni Night를 열었고, KTV에도 나왔습니다.

그날 밤 이후에 쓴 문장이 이 글에서 주제문에 가장 가깝습니다. 한국과 뉴질랜드 양쪽에서 살아 본 사람들은 두 문화를 모두 겪어 봤기 때문에 그 차이를 어떻게 잇는지 압니다. 일하러 한국에 온다면, 어느 나라 출신이든 그런 사람들을 찾으세요. 그 자리의 분위기가 무슨 말을 하고 있었는지 평범한 말로 알려 줄 사람들입니다.

서울에서 프리랜서로

#

매니저 일을 그만두고 2025년 10월에 프리랜서가 됐습니다. 실제로는 계약직 DevOps·MLOps 일이고, 대부분 온프레미스입니다. 고가용성 PostgreSQL 클러스터를 만들었고, 이어서 같은 하드웨어에 LLM 서빙 인프라를 올렸습니다. 해 보니 배관 공사보다 품질 관리가 더 많았습니다. 트레이스와 멀티턴 대화를 지켜보면서 모델 출력이 어디서 어긋나는지 찾는 일이죠. 2026년 2월부터는 제 마켓플레이스·커뮤니티 앱도 따로 만들고 있습니다.

프리랜서가 된다고 눈치에서 벗어나지는 않습니다. 읽는 대상이 바뀔 뿐입니다. 어느 팀에 가든 제가 가장 먼저 보는 건 모니터링입니다. 팀에 대해 README보다 더 많은 걸 알려 주니까요. 시스템에 쓰는 눈치인 셈입니다. 팀이 한다고 말하는 것이 아니라 실제로 하는 것을 읽는 일이요.

한국행을 고민하는 사람에게

#

1. 채용 전에 사람들이 내가 일하는 모습을 볼 수 있는 문으로 들어오세요. 제 경우엔 석사였습니다. 해커톤, 작은 회사의 인턴십, 여기 있는 자기 나라 커뮤니티도 같은 역할을 합니다. 양쪽에서 살아 본 사람들을 만날 수 있는 곳도 커뮤니티입니다.
2. 작은 회사를 배제하지 마세요. 제 경력의 대부분이 작은 회사였습니다. 열 명짜리 회사에는 지루한 일을 넘길 사람이 없고, 내가 만든 게 실제로 나갑니다.
3. 합류하기 전에 팀을 읽으세요. 커피챗을 활용하고, 여기서 일하면 무엇이 놀라울지 묻고, 이직률에 대한 얼버무림은 진지하게 받아들이세요.
4. 누가 물어봐 주기를 기다리지 마세요. 밀리는 일정, 위험한 변경, 다른 사람이 기다리는 결정. 먼저, 글로 말하세요.
5. 적혀 있지 않은 규칙을 소리 내어 물어보세요. 리뷰는 얼마나 빨리 돌아오는지, ‘완료’가 무슨 뜻인지, 두 번 핑하는 게 무례한지. 아무도 적어 두지 않았다면 내가 적겠다고 하세요.
6. 내 스택을 둘러싼 스택을 배우세요. 여기서는 네이버와 카카오가 구글 습관으로는 커버되지 않는 방식으로 중요합니다.

엔지니어링은 오기 전에 준비할 수 있는 절반입니다. 눈치는 일하면서 배우는 절반이고, 제가 아는 가장 빠른 방법은 사람들에게 말하지 않는 부분을 소리 내어 말해 달라고 부탁하는 것, 그리고 내 것을 먼저 말하는 것입니다.

커피챗은 30~45분짜리 가벼운 대화입니다. 카페든 화상 통화든 상관없습니다. 화이트보드도, 면접관 패널도, 함정 질문도 없습니다. 저는 우리가 뭘 왜 만드는지 이야기하고, 상대는 지금 뭘 하고 있고 다음에 뭘 원하는지 이야기합니다. 그것만으로도 더 깊은 대화가 의미 있을지 양쪽 다 알게 되죠. 채용은 선발 문제라기보다 매칭 문제이고, 매칭에 필요한 정보를 교환하는 데 이보다 빠른 방법을 저는 모릅니다.

왜 계속하는가

#

저는 이 대화를 “채용 활동"이라고 생각하는 걸 그만뒀습니다. 그냥 대화입니다. 그리고 그중 몇 개가 잊을 만하면 채용으로 이어집니다. 상대의 상황이 바뀐 18개월 뒤에 성사되기도 하고요. 좋은 채용을 꾸준히 만들어내는 파이프라인은 채용 공고가 아니라 이런 관계의 축적으로 이루어져 있습니다.

직무 기술서 문제도 해결해 줍니다. JD는 어쩔 수 없이 일반적으로 쓰입니다. 커피를 사이에 두면 후보자가 정말 궁금한 걸 물을 수 있습니다. 첫 6개월에 뭘 해내면 성공인지, 누구와 일하게 되는지, 팀이 지금 씨름 중인 제일 골치 아픈 기술 문제가 뭔지. 이런 질문에 솔직한 답을 들은 사람은 자기와 맞는지 스스로 잘 판단합니다.

그리고 커피챗은 문화를 “설명"하는 대신 “보여"줍니다. 준비해 왔는지, 진짜 호기심이 있는지, 상대의 시간을 존중하는지. 어떤 채용 페이지보다 많은 걸 말해주죠. 이건 반대 방향으로도 작동합니다. 긴장이 풀린 대화에서의 모습은 연습된 면접보다 함께 일할 사람에 대해 훨씬 많은 걸 알려줍니다.

특히 효과가 좋은 순간은 이렇습니다. 이직 생각이 없는 사람에게 다가갈 때, 정식 절차 전에 추천받은 사람과 미리 안면을 틀 때, 커리어 전환(IC에서 매니지먼트로, 스타트업에서 대기업으로, 혹은 그 반대)을 고민하는 사람과 이야기할 때. 인재 쟁탈전이 벌어지는 시장에서는 원하는 사람 대부분이 이 셋 중 하나에 해당합니다.

진행 방식

#

첫 메시지가 전부를 결정합니다. 템플릿 같은 접근은 그냥 삭제당합니다. 사전 조사를 하고, 의도를 솔직하게 씁니다.

“안녕하세요 Sarah님, QCon에서 하신 분산 시스템 발표와 이벤트 소싱에 대한 블로그 글을 잘 봤습니다. [회사]에서도 결제 인프라를 확장하면서 비슷한 문제와 씨름하고 있습니다. 30분 커피챗 어떠세요? 면접 의제는 없습니다—그저 관점을 듣고 저희가 하는 일을 공유하고 싶을 뿐입니다.”

이게 통하는 이유는 구체적이고, 의도를 숨기지 않고, 시간만 달라고 하는 게 아니라 “흥미로운 문제에 대한 대화"라는 가치를 내밀기 때문입니다. 그다음은 상대의 수고를 줄여주는 일입니다. 시간 옵션을 몇 개 제시하고, 상대에게 편한 장소(온라인이라면 다운로드가 필요 없는 화상 도구)를 고르고, 내용이 명확한 캘린더 초대를 보내서 아무것도 추측하게 만들지 않는 겁니다.

대화 자체는 느슨한 틀이면 충분합니다. 처음 몇 분은 진짜 스몰토크와 연락한 이유. 다음은 상대의 이야기입니다. 지금 하는 일, 즐거운 것, 답답한 것, 다음에 원하는 것. 여기서 할 일은 말하기보다 듣기입니다. 그다음이 우리 이야기입니다. 미션과 팀이 실제로 안고 있는 과제를, 힘든 부분까지 포함해서요. 후보자는 투명함을 존중하고, 영업 냄새는 귀신같이 맡습니다. 가장 값진 구간은 후반의 열린 시간인데, “어떤 조건이 갖춰지면 이직을 고려하시겠어요?“를 함께 탐색합니다. 마무리는 다음 단계를 분명히. “계속 연락하고 지내요” 정도라도 괜찮습니다.

끝나면 24시간 안에 대화 속 구체적인 내용을 언급한 짧은 감사 메시지를 보냅니다. 약속한 건(소개든 링크든) 바로 전달하고요. 이런 심심한 뒷정리야말로 회사 문화를 진짜로 보여주는 대목입니다.

이걸 꾸준히 할 거라면, 대화한 사람들을 간단한 스프레드시트로 관리하고 자리가 없을 때도 가끔 안부를 물어보세요. 매니저 전용 활동으로 둘 필요도 없습니다. 엔지니어들이 자기 네트워크의 멋진 사람들과 커피를 마시는 것. 좋은 리퍼럴은 대개 거기서 시작됩니다.

써먹을 수 있는 질문들

#

제가 자주 묻는 것:

• “최근에 작업한 것 중 제일 흥미로웠던 문제는 뭐였나요?”
• “다음 직장에서는 뭐가 달라졌으면 하나요?”
• “어떤 방식으로 배우는 게 잘 맞나요? 앞으로 어떻게 성장하고 싶으세요?”
• “핏이 맞을지 판단하는 데 도움이 될 만한, 궁금한 게 있으신가요?”

제가 후보자 쪽이라면 물어볼 것:

• “팀이 지금 마주한 가장 큰 과제는 뭔가요?”
• “이 역할의 성공은 어떻게 측정하나요?”
• “승진 경로는 어떻게 되나요?”
• “왜 이 회사에 오셨어요? 왜 계속 계신가요?”
• “여기서 일하는 것에 대해, 제가 들으면 의외라고 할 만한 게 있나요?”

커피챗 제안을 받은 쪽이라면

#

커피챗이 무슨 뜻인지 찾아보는 사람은 대부분 저와 테이블 반대편에 앉는 쪽입니다. 누군가에게 커피챗 제안을 받았고, 어떤 자리에 나가게 되는 건지 알고 싶은 거죠. 초대를 보내는 쪽에서 해 드리고 싶은 이야기는 이렇습니다.

면접이 아닙니다. 아무도 점수를 매기지 않고 테스트도 없으니 모범 답안을 준비할 필요는 없습니다. 그래도 첫인상인 건 맞으니, 친구의 친구를 만난다기보다 미래의 동료를 만난다고 생각하세요. 면접과 다른 점은 마음껏 궁금해해도 된다는 것, 그리고 대답하는 만큼 질문도 하길 기대받는다는 것입니다.

복장은 그 회사에 평범한 날 출근할 때 입을 법한 옷이면 됩니다. 잘 모르겠으면 깔끔한 캐주얼이 틀릴 일은 없습니다. 화상 통화라면 카메라를 켜고 조용한 방을 찾으세요. 셔츠보다 그게 더 중요합니다.

준비는 30분 정도면 충분합니다. 그 회사가 뭘 만드는지, 상대가 쓴 글이나 만든 게 있다면 읽어 보세요. 지금 하는 일과 다음에 하고 싶은 일을 2분 안에 말할 수 있게 정리해 두세요. 그 질문은 반드시 나오니까요. 직접 물어볼 질문도 두세 개 챙겨 가세요. 위의 질문 리스트로 시작해도 괜찮습니다.

무슨 이야기를 할지는 이렇습니다. 내 일, 그 일에서 즐거운 부분, 상대의 일에서 궁금한 부분. 연봉 이야기는 상대가 먼저 꺼내지 않는 한 나중으로 미루세요. 염두에 둔 포지션이 있는지, 있다면 절차가 어떻게 되는지 묻는 건 전혀 문제없습니다.

계산은 보통 초대한 쪽이 합니다. 내겠다고 말은 하되, 계산대 앞에서 실랑이까지 할 필요는 없습니다. 하루 안에 실제로 나눈 이야기를 하나 언급한 짧은 감사 메시지를 보내면, 이미 대부분의 사람보다 잘한 겁니다.

그리고 만나 보고 싶은 사람이 있다면 직접 커피챗을 요청하세요. 메시지는 짧게, 왜 하필 그 사람인지 밝히고, 수락하기 쉽게 만드는 게 요령입니다. “팀에서 진행하신 새 검색 기능 작업을 계속 지켜보고 있었습니다. 저도 플랫폼 엔지니어링 쪽으로 옮기는 걸 고민하고 있는데, 몇 주 안에 30분 정도 커피나 통화 가능하실까요? 시간은 편하신 대로 맞추겠습니다.” 이 정도로 구체적인 요청이면 대부분 응해 줍니다.

망치는 방법들

#

제일 빠른 건 몰래 면접으로 바꾸는 겁니다. 기술 역량을 테스트하거나 행동 면접 질문을 슬쩍 끼워 넣는 순간 암묵적인 약속은 깨집니다. 그건 정식 프로세스를 위해 아껴두세요. 그다음이 과한 영업입니다. 오래 남는 채용은 힘든 부분까지 다 보고 들어온 사람들에게서 나옵니다. 준비 없이 나타나는 것, 끝나고 연락이 끊기는 것도 조용히 타격을 줍니다. 커피챗 한 번의 인상이, 그 사람이 자기 네트워크에 여러분 회사를 어떻게 이야기할지를 정하니까요.

제 쪽에서 보는 위험 신호는 이렇습니다. 아무것에도 호기심이 없는 후보자, 완전히 거래처럼 느껴지는 대화, 과거 직장을 전부 똑같은 원망조로 이야기하는 사람. 후보자도 자기만의 리스트를 갖고 있어야 합니다. 일의 의미를 설명하지 못하는 담당자, 이직률이나 회사 방향에 대한 얼버무림, 여러분을 이해하기보다 팔아넘기는 데 열심인 상대.

모든 커피챗이 어딘가로 이어지는 건 아닙니다. 사실 대부분은 안 이어져요. 그래도 괜찮습니다. 중요한 건, 다음에 핵심 포지션을 채워야 할 때 백지 채용 공고가 아니라 쌓여 있는 진짜 대화들에서 시작할 수 있다는 점입니다. 직무 기술서 말고, 커피 한잔하자는 초대를 보내세요.

추가 읽기

#

이 사이트의 관련 글:

• 개발자 면접에서 STAR 방식을 쓰는 이유 - 커피챗이 정식 면접 프로세스로 이어졌을 때를 위해
• 새로 엔지니어링 매니저가 되면서 집중하기로 한 세 가지 - 팀을 굴러가게 하는 것이 무엇인지. 결국 매칭에서 봐야 할 것들입니다
• 스타트업에서 인턴을 해야 하는 이유 - 스타트업행을 고민하는 사람과 이야기할 때의 배경 지식으로

외부 리소스:

• First Round Review: 엔지니어 채용 - 경험 많은 운영자들이 쓴 스타트업 채용 가이드
• Lara Hogan의 “첫 1:1을 위한 질문” - 1:1용으로 쓰였지만 커피챗에서도 그대로 잘 먹힙니다
• Patrick McKenzie의 연봉 협상 글 - 후보자 쪽 시각을 이해하는 데 좋습니다
• Who: 채용의 A 메소드 - Geoff Smart와 Randy Street의 체계적인 채용 프레임워크
• Harvard Business Review: 채용 - 인재 확보에 대한 연구 기반 글 모음

올해부터 엔지니어링 팀을 맡으면서, 성과 평가가 “받는 것"에서 “제가 운영해야 하는 것"으로 바뀌었습니다. 이 글은 제 생각을 정리하는 목적도 있으니, 정답이라기보다는 아직 배워가는 사람의 메모로 읽어주시면 좋겠습니다.

애초에 평가를 왜 하는가

#

직급이 무엇이든, 목적은 결국 두 가지입니다. 계속 배울 수 있게 하는 것, 그리고 역할의 기대치를 넘어서는 사람이 제대로 보상받게 하는 것.

“평가할 시간도 여력도 없다"는 작은 회사가 많습니다. 그런 회사는 결국 근속 연수 하나만 보고 누가 시니어가 될 준비가 됐는지 정하게 되죠. 저는 이게 실수라고 생각합니다. 근속이 게으른 지표라서만이 아닙니다. 평가를 생략하면 회사와 직원 사이의 양방향 채널이 사라지고, 일하는 관계 자체가 상하기 때문입니다.

이건 양쪽 모두에 해당합니다. 본인은 회사를 위해 최선이라고 진심으로 믿는 방식으로 일하고 있어도, 습관이나 방법론, 커뮤니케이션 스타일이 안 좋은 쪽으로 흘러갈 수 있습니다. 피드백이 없으면 아무도 그걸 잡아주지 못합니다. 반대로 구조화된 자리에서 직원들의 이야기를 듣지 않는 회사는, 직원들이 회사를 어떻게 생각하는지 모른 채 편안하게 지내게 됩니다.

서로 무엇을 기대하고 들어와야 하나

#

직원 입장에서 기대할 것은 복잡하지 않습니다. 내 일이 팀 목표와 어떻게 연결되는지, 뭘 잘하고 있고 어딜 고쳐야 하는지 알고 싶어 합니다. 그것도 “커뮤니케이션을 더 잘하세요"가 아니라 구체적으로요. 기여를 인정받고 싶고, 커리어와 교육에 대한 진짜 대화를 원하고, 사내 정치가 아니라 일 자체에 기반한 공정한 프로세스를 원합니다.

매니저인 제 입장에서는, 우선 자기 평가를 준비해 오길 기대합니다. 뭐가 잘됐고 뭐가 아쉬웠는지 본인의 시각을 듣고 싶거든요. 변호인의 모두진술이 아니라 피드백에 열린 자세를 바라고, 앞으로의 목표에 대한 진솔한 논의, 그리고 팀 안에서 본인이 어떻게 맞물려 있다고 느끼는지에 대한 솔직한 이야기를 기대합니다. 평가는 제 계획의 시간이기도 합니다. 팀 구성, 승진 후보, 누구에게 어떤 성장 기회가 필요한지.

하나의 틀이 모든 엔지니어에게 맞지는 않는다

#

엔지니어링 팀에는 문화적 배경도, 연차도, 전문 분야도 다른 사람들이 모여 있습니다. 같은 대본이 모두에게 통할 리 없죠. “똑같이 대하는 것"과 “공정하게 대하는 것"은 다른 얘기고, 방식은 각자의 필요, 커리어 단계, 기여에 맞춰 구부러져야 합니다. 기본은 각 엔지니어의 역할과 책임이 명확하고, 그것이 보상과 실제로 맞아떨어지게 하는 것입니다.

제일 꼬이기 쉬운 지점이 직급과 연봉입니다. 타이틀이 애매하다고 느끼거나 승진할 준비가 됐다고 생각하는 사람에게, 두루뭉술한 격려는 독입니다. 통하는 건 구체성입니다. 다음 직급의 기준이 될 구체적인 도전 과제나 프로젝트 목표에 합의해서, 승진이 ‘분위기’가 아니라 객관적 기준이 되게 하는 것. 보상도 마찬가지입니다. 연봉이 낮다고 느끼거나 더 큰 책임을 원하는 사람에게는, 다음 평가 전까지 무엇을 달성해야 그 변화가 정당화되는지 측정 가능한 목표를 플랜에 적어 넣습니다. 그리고 다음 평가에서는 양쪽 모두 그 약속 앞에 정직해져야 합니다.

개선 피드백도 같은 원칙입니다. 특정한 갭을 겨냥한 특정 교육 프로그램, 워크숍, 프로젝트는 도움이 됩니다. “계속 역량을 키우세요"는 도움이 안 됩니다.

기준선은 첫 미팅에서 시작된다

#

새 팀원과의 첫 평가 미팅은 거의 기준선을 잡는 시간입니다. 역할이 실제로 무엇을 포함하는지, 그게 팀과 회사 목표에 어떻게 이어지는지 같이 확인하고, 성과를 판단할 측정 가능한 결과에 합의하고, 단기와 장기 목표를 세웁니다. 컬처와 기대되는 행동, 피드백이 언제 어떻게 오는지, 쓸 수 있는 리소스와 멘토링, 그 자리에서 보이는 커리어 패스를 이야기하기에도 좋은 타이밍입니다. 어느 것도 짜릿하진 않지만, 이걸 해두면 이후의 모든 평가가 쉬워집니다.

그 이후에 쓰는 아젠다

#

1. 스몰토크. 사소해 보여도 이걸로 긴장이 풀리고, 이후 대화가 훨씬 솔직해집니다.
2. 아젠다 훑기. 어느 쪽도 주제에 기습당하지 않도록.
3. 지난 평가 이후의 성장. 발전은 명시적으로 짚어줍니다. 본인은 의외로 모르거든요.
4. 현재 성과. 강점부터.
5. 개선할 부분. 각각 구체적이고 현실적인 목표를 붙여서.
6. 커리어 계획. 지금 하는 일이 실제로 그 방향을 향하고 있는지도 함께.
7. 다음 평가까지의 타깃, 목표, 액션 아이템.

KPI는 개인 맞춤이어야 작동한다

#

프로덕트 팀 엔지니어의 KPI는 팀 목표와 개인 양쪽에 맞아야 합니다. 프론트엔드, 백엔드, 풀스택의 역할이 다르고, 주니어와 시니어의 차이는 더 큽니다. 커밋 수는 주니어 개발자에 대해 뭔가 말해줄 수 있을지 몰라도, 주요 산출물이 아키텍처 의사결정인 시니어 엔지니어에 대해서는 아무것도 말해주지 않습니다. 그래서 KPI는 템플릿을 복사하는 게 아니라 대화 속에서 정하는 겁니다.

제가 보는 영역은 이렇습니다.

• 코드 품질: 에러율, 코딩 표준 준수, 버그 수정이 필요해지는 빈도
• 프로젝트 딜리버리: 마일스톤과 마감 준수
• 혁신과 문제 해결: 효율 개선, 어려운 문제를 실제로 풀어냈는지
• 협업: 피어 리뷰, 팀 목표와 논의에 대한 기여
• 자기 계발: 학습 목표 달성, 자격증, 새로 익힌 기술
• 고객 임팩트: 사용자 피드백, 출시한 기능의 사용 지표

측정 가능한 지표 쪽에서는 요즘 유닛 테스트에 관심이 갑니다. InfoQ의 이 글은 유닛 테스트를 성과 평가에 녹이는 방법을 다루는데, 실무적인 구현과 팀 문화에 미치는 영향을 함께 짚습니다. 코드 건강도를 정성·정량 양쪽으로 보자는 주장이라, 엔지니어를 코드 줄 수로 환원하지 않는 KPI를 찾고 있다면 읽어볼 만합니다.

무엇을 고르든 평가나 1:1에서 함께 합의하고, 역할과 프로젝트와 기술이 바뀌는 만큼 다시 들여다봐야 합니다. 아무도 합의하지 않은 KPI는 그냥 몽둥이일 뿐입니다.

제가 채워 쓰는 템플릿

#

저는 사람마다 문서를 하나씩 두고 평가할 때마다 섹션을 추가합니다. 그러면 히스토리가 한곳에 모이죠. 뼈대는 이렇습니다.

## 성과 평가: [이름], [기간]

**역할과 직급:** [직함, 그리고 이 팀에서 그 직급이 뜻하는 것]
**지난 평가의 목표:** [이전 섹션에서 복사]

### 자기 평가 (엔지니어가 미리 작성)
- 잘된 것, 사례 한두 개와 함께
- 잘 안된 것, 그리고 다시 한다면 무엇을 다르게 할지
- 1년 뒤에 하고 있고 싶은 일

### 지난 평가 목표의 진척
- [목표]: 달성 / 일부 달성 / 미달성, 근거와 함께

### 강점 (구체적인 사례)
- [무엇을, 언제 했고, 그게 무엇을 바꿨는지]

### 개선할 부분 (각각 목표와 함께)
- [행동이나 스킬] → ["더 나아진" 모습] [날짜]까지

### 커리어와 직급
- 다음 직급 기준에 비춰 지금 어디쯤인지, 무엇이 부족한지

### 다음 평가까지의 목표
1. [측정 가능한 목표]
2. [측정 가능한 목표]

### 합의한 액션 아이템
- [누가] [무엇을] [언제까지] 한다

자기 평가는 미팅 하루이틀 전에 받고, 미팅 중에 쓰게 하는 일은 없습니다. 먼저 읽고 들어가면 대화가 달라집니다. 절반쯤은 제가 꺼내려던 얘기를 엔지니어가 이미 직접 적어 와서, 미팅 시간을 “그래서 어떻게 할지"에 쓸 수 있거든요.

자기 평가 질문

#

미리 보내는 질문들입니다. 일부러 열린 질문으로 만들었습니다. 그래야 무엇을 했는지뿐 아니라, 본인이 자기 일을 어떻게 보는지가 답에 드러나니까요.

• 지난 평가 이후 가장 뿌듯했던 일은 무엇이고, 왜 하필 그 일인가요?
• 어디서 막혔고, 무엇이 있었다면 더 빨리 풀렸을까요?
• 팀원이나 리뷰어에게 받은 피드백 중 마음에 남은 게 있나요?
• 지난 평가의 목표 중 달성했다고 생각하는 건 무엇이고, 빼거나 바꾸고 싶은 건 무엇인가요?
• 다음에 배우고 싶은 건 무엇이고, 지금 하는 일이 그럴 기회를 주고 있나요?
• 매니저로서 제가 다르게 해야 할 건 무엇인가요?

마지막 질문에서 가장 어색한 침묵이 흐르고, 가장 쓸모 있는 답이 나옵니다.

구체적인 피드백은 이렇게 들린다

#

나쁜 평가 피드백은 대부분 가혹해서가 아니라 두루뭉술해서 나쁩니다. 차이를 보여 드리면, 제가 쓰려고 애쓰는 피드백은 이런 식입니다.

구체적인 쪽은 모두 실제로 있었던 일을 짚고, 그게 무엇을 바꿨는지 말하고, 그 사람이 다음에 할 수 있는 행동을 가리킵니다. 쓰는 데 시간이 더 걸리죠. 그래서 저는 평가 전날 밤에 기억을 쥐어짜는 대신, 분기 내내 사례를 모아 두도록 스스로를 다그칩니다.

기록으로 남기기

#

미팅이 끝나면 요약을 씁니다. 논의한 핵심, 제기된 이슈, 액션 아이템, 서로 합의한 목표. 관료적으로 들리지만, 이 기록이 있어야 여섯 달 뒤의 “그런 약속 한 적 없는데요” 대화를 막을 수 있습니다. 문서화된 이슈는 증발하지 않고 추적되고, 액션 아이템은 다음 평가의 첫 아젠다가 되고, 문서에 적힌 목표는 훨씬 진지하게 다뤄집니다.

결국 시스템의 전부는 이겁니다. 첫날부터 기대치를 명확히 하고, KPI는 사람에 맞춰 만들고, 전부 기록하고, 모든 액션 아이템을 팔로업하는 것. 양방향 대화와 측정 가능한 결과가 없는 평가는 체크박스 놀음이고, 엔지니어들은 캘린더 초대만 봐도 체크박스 놀음 냄새를 맡습니다.

사실 저도 곧 이 전환을 하게 됩니다. 그래서 요즘 경험자들을 붙잡고 이야기를 듣고, 구할 수 있는 책은 다 읽어보는 중입니다. 지금까지 가장 분명하게 배운 건 이겁니다. 엔지니어에서 엔지니어링 매니저가 되는 건 한 계단 올라가는 게 아니라, 완전히 다른 직업으로 옆걸음질하는 거라는 것. 내 아웃풋은 더 이상 코드가 아니라 팀이 만들어내는 모든 것이 됩니다. 다들 이 말을 하는데, 다들 그 무게를 과소평가한다고 하네요.

실제로 달라지는 것

기술 문제를 직접 푸는 대신 사람 문제를 풀게 됩니다. 캘린더는 1:1 미팅, 기획 회의, 팀 간 조율로 채워지고, 채용과 성과 평가가 내 책상 위로 올라옵니다. 일의 중심은 팀이 일에 집중하는 데 필요한 것들, 그러니까 맥락과 명확한 우선순위, 그리고 최대한 적은 잡음을 확보해 주는 쪽으로 옮겨갑니다.

곤란한 지점은, 아키텍처 논의에서 밀리지 않고 제대로 된 기술 판단을 내릴 만큼의 기술력은 유지하면서도, 코드를 짜는 사람은 더 이상 내가 아니라는 걸 받아들여야 한다는 겁니다. 둘 다 하려던 매니저들을 몇 명 봤는데, 대개 둘 다 어중간해지더군요.

엔지니어와 엔지니어링 매니저, 나란히 놓고 보면

이 중에서 다들 제일 많이 경고하는 게 피드백 루프입니다. 엔지니어일 때는 거의 매일 작은 성취가 있습니다. 매니저의 성취도 분명히 있지만 느리게 오고, 내 결정이 옳았는지 한동안 모르는 상태에 익숙해져야 합니다.

중요해 보이는 스킬들

일의 대부분은 커뮤니케이션입니다. 팀과 프로덕트와 리더십 사이의 통역이 되는 건데, 이 세 그룹이 같은 이야기를 하고 있는지 확인하는 데만 놀랄 만큼 많은 시간이 들어갑니다. 어떤 프로세스보다 중요한 건 신뢰입니다. 팀원들이 “이거 망가졌어요"라고 편하게 말하지 못하면, 문제를 가장 늦게 아는 사람이 바로 내가 됩니다. 캘린더는 정말로 사람을 집어삼키려 들기 때문에, 생각할 시간과 팀을 위한 시간을 지키는 건 끝나지 않는 싸움입니다. 그리고 회사가 뭘 이루려는지 이해하지 못하면 팀을 쓸 만한 방향으로 이끌 수도 없습니다.

직함이 오기 전에 준비하기

계속 듣는 조언이자 제가 직접 보증할 수 있는 부분은 이겁니다. 직함을 받기 전에 먼저 리드해 보라는 것. 프로젝트를 굴려 보고, 누군가를 멘토링하고, 뭔가를 조직해 보는 거죠. 저는 지난 1년 정도를 프로젝트 리드 역할로 보냈는데, 그 경험이 어떤 책보다 큰 도움이 되고 있습니다. 물론 책도 도움이 됩니다. Camille Fournier의 “The Manager’s Path"는 모두가 추천하는 책인데, 읽어 보니 이유를 알겠더군요. 기술력도 계속 갈고닦으세요. 아키텍처 논쟁은 사라지지 않으니까요. 그리고 이미 이 전환을 겪은 멘토를 찾으세요. 지나고 나서야 뻔해 보이는 실수들을 미리 피하게 해 줍니다.

트레이드오프

무엇이 어떻게 만들어질지에 대한 영향력은 커지지만, 직접 만드는 일은 거의 없어집니다. 어떤 날은 그게 뿌듯할 테고, 어떤 날은 코드가 사무치게 그리울 겁니다. 겪어본 사람들은 하나같이 그게 정상이라고 하네요. 6개월 뒤에 다시 물어봐 주세요.

요즘 이 생각을 자주 하는 이유는 제가 직접 프로젝트를 리드하는 입장이 되면서 얼버무리고 싶은 유혹이 뭔지 몸으로 느끼고 있기 때문입니다. 회의에서 질문을 받고 다섯 명이 답을 기다리고 있을 때 “모르겠습니다"라고 하면 지는 기분이 들죠. 그런데 사실은 반대입니다. 대부분의 경우 그게 가장 강한 수입니다. 다만 다음에 뭘 할지, 그러니까 누구에게 물어볼지, 언제 답을 가져올지를 붙인다는 조건이 있습니다.

아는 척은 반드시 들킨다

#

소프트웨어는 변화가 너무 빨라서 모든 걸 머릿속에 담아둘 수 있는 사람이 없습니다. 그리고 엔지니어들은 아는 척을 놀라울 만큼 잘 알아챕니다. 한 번이라도 아는 척하다 들키면, 팀은 그다음부터 진짜 답까지 깎아서 듣기 시작합니다. 반대로 모르는 걸 인정하고 그 구멍을 직접 메우러 가는 매니저의 말은 신뢰를 얻습니다. 진짜 답인지 아닌지, 다들 듣고 구분할 줄 알거든요.

“모르겠습니다"는 답이 아니라 출발점

#

중요한 건 그다음입니다. “모르겠습니다"에서 끝나면 그냥 떠넘기기죠. 좋은 매니저는 거기서부터 더 나은 질문을 만들어 갑니다. “지금 쓰는 것과 비교하면 어떤가”, “이 전제가 틀리면 뭐가 깨지는가.” 그리고 그 질문을 맞는 사람에게 던집니다. 어느 팀에나 데이터베이스에 사는 것 같은 사람, 프론트엔드의 골치 아픈 엣지 케이스를 다 꿰고 있는 사람이 있기 마련입니다. 모든 걸 직접 알 필요는 없습니다. 누가 아는지 파악하고, 실제로 물어보러 가면 됩니다.

일할 때 “모르겠습니다"를 잘 말하는 법

#

제가 지키려는 원칙은 하나입니다. “모르겠습니다"로 문장을 끝내지 않는 것. 실제로 입 밖에 내서 쓸 수 있는 표현을 몇 가지 적어 봅니다.

• “지금은 잘 모르겠습니다. 목요일까지 확인해서 말씀드릴게요.”
• “그 부분은 민수 님이 저보다 훨씬 잘 아세요. 같이 여쭤보죠.”
• “확실하진 않은데, 제 추측으로는 X입니다. 결정 전에 Y는 한번 확인해 보고 싶어요.”
• “지금 숫자가 손에 없어서요. 회의 끝나고 채널에 공유드리겠습니다.”
• “제가 정확히 알지 못하는 부분이라, 담당자에게 확인 후 회신드리겠습니다.” (고객이나 외부 미팅에서)

“모르겠습니다"라고 하면 무례해 보이지 않을까 걱정하는 분도 있는데, 다음 행동이 붙어 있으면 무례하지 않습니다. 정말 곤란한 건 아무것도 진전시키지 못하는 “글쎄요"나, 자신 있게 답했는데 나중에 지어낸 것으로 드러나는 답입니다. 면접에서도 마찬가지입니다. 모르면 모른다고 하고, 어떻게 알아볼지를 이야기하세요. 찍어서 맞히려는 답보다 훨씬 많은 걸 보여 줍니다.

의사결정의 질이 올라간다

#

소프트웨어에서 내린 결정은 오래 남습니다. 그래서 “여기는 확신이 있고, 여기는 추측이다"를 솔직하게 구분하는 게 값어치를 합니다. 모르는 부분을 미리 인정해 두면 결정한 뒤가 아니라 결정하기 전에 부족한 정보를 모을 수 있고, 반대 의견이 있는 사람도 목소리를 내기 쉬워집니다. 그게 사실 가장 들어야 하는 목소리고요. 결정했으면 이유를 설명하고, 틀렸으면 그것도 인정합니다. 매니저가 자기 실수를 인정 못 하는 팀만큼 솔직함이 빨리 죽는 곳도 없습니다.

어려운 얘기가 아닙니다. 질문하고, 나보다 잘 아는 사람 말을 듣고(나보다 잘 아는 사람은 언제나 있습니다), 추측으로 말할 때는 추측이라고 말하는 것. 그게 전부입니다. “모르겠지만 알아보겠습니다"라는 한마디가, 얼버무리며 넘긴 그 어떤 답변보다 제 신용을 더 많이 쌓아 줬습니다.

“진행 상황 어때요?“라는 질문을 반기는 사람은 없습니다. 그런데 회사에서 프로젝트를 이끄는 입장에서는 진행 상황을 모르고 지나갈 수도 없죠. 제 타협점이 Git 그래프입니다. 누군가에게 묻기 전에 먼저 그래프를 봅니다. 대부분의 경우 답은 이미 거기 있습니다. 커밋 활동, 브랜치, 병합이 한눈에 보이고, 그걸 위해 회의를 잡을 필요도 없습니다.

그래프에서 실제로 읽을 수 있는 것

#

찬찬히 본 적이 없는 분들을 위해 설명하면, 노드 하나가 커밋이고 갈라져 나가는 선이 브랜치이며, 전체가 프로젝트의 타임라인이 됩니다. 이 배치에 생각보다 많은 정보가 담겨 있습니다.

• 한 번 훑어보는 것만으로 활성 브랜치 수와 커밋 빈도가 보입니다.
• 갑자기 조용해진 브랜치나 몇 주째 병합되지 않은 브랜치는 대개 누군가 막혀 있다는 신호입니다. 이런 조기 경보는 값지죠.
• 병합 빈도는 팀의 협업 방식을 비춥니다. 병합이 잦다는 건 작업이 꾸준히 통합되고 있다는 뜻이고, 너무 오래 산 브랜치는 고립된 작업이 되어 있을 가능성이 높습니다.

방해는 줄고, 대화는 나아지고

#

눈에 띄는 이득은 누구의 작업도 끊지 않고 상황을 알 수 있다는 겁니다. 더 큰 이득은 정말 대화가 필요해졌을 때 나타납니다. 추측이 아니라 그래프에서 이야기를 시작할 수 있거든요. “이 브랜치가 화요일부터 안 움직이던데, 뭐 막힌 거 있어요?“는 “진행 상황 어때요?“보다 훨씬 나은 첫마디입니다.

루틴을 공개해 두는 것도 도움이 됩니다. 저는 거의 매일 아침 슥 훑어보고, 일주일에 한 번 제대로 들여다봅니다. 팀도 그 리듬을 알고 있으니 아무도 놀라지 않습니다.

감시 도구로 만들지 말 것

#

이 부분은 저 스스로에게도 계속 되뇌는 대목입니다. 커밋 수는 가치가 아닙니다. 공들인 커밋 하나가 요란한 커밋 50개를 이길 때도 있습니다. 모든 커밋이 보인다고 해서 모든 결정에 토를 달 자격이 생기는 것도 아니고요. 팀을 믿고, 패턴이 정말 수상할 때만 개입해야 합니다. 그리고 그래프를 대화에 끌어들일 때는 피드백의 출발점으로 써야지, 기소용 증거로 쓰면 안 됩니다.

터미널에서 그래프 보기

#

Git만 있으면 됩니다.

git log --graph --oneline --all --decorate

옵션별 의미는 이렇습니다.

• --graph: 왼쪽에 브랜치와 병합 선을 그립니다.
• --oneline: 커밋 하나를 한 줄로, 짧은 해시와 메시지 첫 줄만 보여 줍니다.
• --all: 지금 있는 브랜치뿐 아니라 원격을 포함한 모든 브랜치와 태그를 보여 줍니다.
• --decorate: 브랜치와 태그 이름을 가리키는 커밋 옆에 표시합니다. 최근 Git은 출력이 터미널로 갈 때는 알아서 표시하지만, 이 옵션을 붙여 두면 파이프로 다른 명령에 넘길 때도 이름이 남습니다.

매일 아침 이걸 다 칠 수는 없으니 alias로 만들어 둡니다.

git config --global alias.graph "log --graph --oneline --all --decorate"
git graph

오래된 저장소라면 그래프 전체는 스크롤이 끝나질 않습니다. 줄이는 방법 몇 가지입니다.

git graph --since="2 weeks ago"    # 최근 2주만
git graph -20                      # 최근 커밋 20개만
git log --graph --oneline main..feature                # feature에는 있고 main에는 아직 없는 것
git log --graph --oneline --left-right main...feature  # 양쪽 모두, < 와 > 로 구분

마지막 두 줄은 두 브랜치 비교입니다. alias 대신 그냥 git log를 쓰는 이유는, --all이 들어가면 다른 브랜치가 전부 다시 딸려 오기 때문입니다. 점 두 개는 feature에는 있고 main에는 없는 것을 보여 줍니다. 점 세 개에 --left-right를 붙이면 서로 상대에게 없는 것을 양쪽 다 보여 주니, 오래 살아 있는 브랜치가 얼마나 멀어졌는지 금방 확인할 수 있죠.

VS Code에서 그래프 보기

#

VS Code에는 그래프가 기본으로 들어 있습니다. 소스 제어 뷰(Ctrl+Shift+G)를 열면 그 패널 안에 Source Control Graph 섹션이 있습니다. 1.93 버전(2024년 8월)부터 생긴 기능입니다. 기본값으로는 현재 브랜치와 그 원격 브랜치를 따라가고, 그래프 제목 표시줄의 브랜치 선택기로 다른 브랜치를 추가할 수 있습니다. 가볍게 훑어보는 용도라면 이것으로 충분합니다.

모든 브랜치를 한 번에 보고 싶다면 mhutchie의 Git Graph 확장을 설치합니다(확장 뷰에서 “Git Graph” 검색). 상태 표시줄의 Git Graph 항목, 소스 제어 뷰 상단의 Git Graph 아이콘, 또는 명령 팔레트의 Git Graph: View Git Graph (git log) 중 아무거나로 열면 됩니다. 커밋을 클릭하면 바뀐 파일이 보이고, 한 커밋을 클릭한 뒤 다른 커밋을 Ctrl/Cmd+클릭하면 둘을 비교할 수 있습니다. 다만 이 확장은 2021년 이후 새 릴리스가 없어서, 기본 그래프도 알아 두면 좋습니다.

Git Graph 버튼이 안 보인다면 확장이 저장소를 못 찾았을 가능성이 큽니다. 기본 설정에서는 연 폴더 자체만 확인하고 하위 폴더까지는 찾지 않습니다. 저장소 폴더를 직접 열거나, 설정에서 git-graph.maxDepthOfRepoSearch 값을 올리세요.

그 밖의 도구

#

웬만한 Git 도구에는 어딘가에 그래프가 있습니다. gitk --all은 Git 자체의 히스토리 브라우저입니다. GitHub, GitLab, Bitbucket에는 리포지토리 페이지에 “네트워크"나 “그래프” 뷰가 있고요. 데스크톱 클라이언트인 SourceTree(Atlassian의 무료 도구), GitKraken, Tower, Windows용 TortoiseGit에도 모두 그래프가 있습니다.

무엇을 고르든 목적은 같습니다. 진행 상황을 이해하는 것. 커밋 수를 세는 게 아니라요.