My First Engineering Job Is Teaching Me Something I Didn't Expect
Well, first real job and I still haven't gotten used to waking up for a 6:30 AM shift... I've been...
개요 #
22살 신입 개발자 Aryan Choudhary가 첫 직장에서 몇 달을 보낸 뒤 쓴 회고다. 그가 상상한 첫 직장은 코드를 쓰고, 새 시스템을 배우고, 실수하고, 더 나아지는 곳이었다. 실제로 배치된 곳은 메인프레임 유지보수 팀이었다.
기술은 오래됐고, 시스템은 중요하고, 업무 대부분은 지원과 유지보수다. 프로덕션을 개인 사이드 프로젝트처럼 다룰 수 없다. 그는 이 상황이 부당하다고 말하지 않는다. 실제로 사람들이 그 시스템에 의존하고 있으니까. 다만 예상과 달랐고, 그 간극에서 배운 것들을 정리했다.
새벽 6시 30분 출근에 아직도 적응하지 못했다는 문장으로 글이 시작된다. 몇 달째인데 몸은 아직 아침형 인간임을 받아들이지 않았다고. 하지만 정작 힘든 건 일찍 일어나는 게 아니라 사무실에 도착한 다음부터 벌어지는 일들이라고 그는 말한다.
절차는 아는데 이유는 모른다 #
Aryan의 업무는 메인프레임 시스템 지원, 기록 관리, 프로세스 준수다. 프라이버시와 보안을 상당히 엄격하게 다루는 시스템이라 "이렇게 하면 어떨까" 하며 프로세스를 바꿀 여지가 거의 없다. 아주 작아 보이는 작업 하나에도 확인해야 할 매뉴얼이 있고, 그 결과는 팀 리드부터 온사이트까지 여러 층에서 검토받는다.
신입으로서 가장 이상한 지점이 여기다. 자기가 왜 그 작업을 하는지 모를 때가 있다.
특정 값을 추가하거나 삭제하거나 수정하라는 지시를 받는다. 어떤 필드를 확인하고 어떤 조건을 충족해야 하는지 적힌 매뉴얼이 있으니 그대로 따른다. 그런데 머릿속에서 작은 목소리가 계속 물어온다. "근데 이 값이 실제로 뭘 하는 건데?" 무엇이 이 값에 의존하는지, 애초에 왜 이걸 추가하는지. 대답은 대부분 "모르겠다"다.
그가 말하는 건 애플리케이션의 큰 비즈니스 목적이 아니다. "왜 이것을 바꾸는가" 같은 아주 구체적인 왜다. 절차에 따라 정확히 작업하고 있으면서도 그 절차의 이유는 모르는 상태. 엔지니어로서는 묘한 자리다.
모든 세부사항을 이해하려고 몇 시간을 쓸 수도 있지만 그것도 현실적이지 않다. 배워야 할 게 이미 터무니없이 많고, "ASAP으로 처리해야 하는" 일에 그만큼 시간을 쓸 수 없다. 그리고 모든 일이 ASAP이다. 그는 아직 그 균형점을 찾는 중이라고 썼다.
사이드 프로젝트에서는 고민할 필요가 없던 문제다. 새벽 2시에 만든 React 앱이라도 DB에 그 필드가 왜 있는지는 알았다. 자기가 넣었으니까. 여기서는 그렇지 않다.
시뮬레이션과 실전 사이 #
온보딩은 세 단계로 나뉘었다. KT(지식 이전), 시뮬레이션, 그리고 실전 투입.
KT에서는 시스템, 프로세스, 용어를 배웠다. 시뮬레이션에서는 실제 도구 없이 업무를 수행했다. 여기까지는 순조로웠다. 문제는 실전이었다. 시뮬레이션은 결국 시뮬레이션이었기 때문이다.
단계를 이해하고, 문서를 따라가고, 시나리오를 정확히 완수할 수 있다. 그런데 실제 도구를 열면 고려해야 할 줄도 몰랐던 열 가지 사소한 것들이 갑자기 튀어나온다. 훈련이 나빠서가 아니라, 무엇을 해야 하는지 아는 것과 실제 시스템 안에서 그것을 해내는 것이 다른 일이기 때문이라고 그는 정리했다.
Git을 몇 주간 읽고, 배포를 이해하고, 데모 앱을 만들어볼 수 있다. 그러다 뭔가 실제로 망가지면 튜토리얼이 한 번도 언급하지 않은 것을 알게 된다.
여기서 그는 가장 큰 혼란을 느꼈다고 한다. 중요한 시스템이고 뭔가 잘못되면 실제 문제가 생기니 실수를 그냥 넘길 수 없다는 건 이해한다. 하지만 시뮬레이션에서 실제 도구로 막 넘어온 상태라면 실수하는 것도 어느 정도 요점이다. 그렇게 자기가 모르는 걸 파악하고, 나중에 일을 쉽게 만들어주는 감각을 천천히 쌓는다.
Photo by Harrun Muhammad on Pexels
20년 경력과 22살 사이의 간극 #
이 프로젝트를 이전에 담당했던 사람들은 경력 20년 이상이었다. Aryan은 22살이다(글에서는 "2주 뒤면 23살이지만 이야기상 22로 가자"고 덧붙였다). 주변 동료들도 대체로 어리고, 팀에서 경력이 가장 많은 사람은 팀 리드 한 명이다.
그리고 그는 결국 한 사람이다. 팀 전체의 모든 기술 질문, 모든 문제, 모든 결정, 모든 커뮤니케이션 이슈를 혼자 감당할 수 없다. 그래서 경력 격차가 체감되는 순간이 온다. 배우는 중이고, 실수하는 중인데, 동시에 이미 시스템을 수년간 익힌 사람들이 설정한 수준으로 일하기를 기대받는다.
Aryan의 경우엔 변수가 하나 더 있다. 일본어를 아직 배우는 중이고, 업무에서 그 언어를 쓴다. 퇴근 후 시간의 상당 부분이 언어 공부에 들어간다. 그래서 시스템이 무엇을 하는지 파악하려 애쓰면서, 동시에 아직 배우는 중인 언어로 누군가가 하는 말을 알아들으려 진땀을 빼는 순간들이 있다.
그는 이걸 실수의 변명으로 삼지 않는다. 뭔가 망쳤으면 더 나아져야 하고, 실제로 실력 문제일 때도 있다고 인정한다. 제대로 이해하지 못했고, 뭔가를 놓쳤고, 잘못된 판단을 했다. 자주 일어나고, 같은 실수를 반복한 적도 있다. 다만 "나는 이게 처음이다"와 "나는 이걸 진짜 못한다"를 구분하는 법을 익히고 있다고 썼다.
통제권 없이도 책임은 진다 #
책임과 통제에 대한 생각도 정리했다.
유휴 시간, 팀 구조, 업무량, 왜 어떤 일이 진행되지 않았는지에 대한 대화가 오간다. 그런데 질문을 받는 사람이 정작 그것을 통제하는 사람이 아닐 때가 있다. 자기가 한 일에 대한 책임은 당연히 자기 것이다. 실수했으면 그건 자기 몫이다. 하지만 업무량이 얼마나 있는지, 팀이 어떻게 구성되는지, 훈련이 어떻게 설계됐는지, 누군가가 다른 매니저에게 무엇을 전달했는지는 그의 통제 밖이다.
자기 일에 책임을 지는 것과 자기 일 주변의 모든 것에 책임을 지는 것은 다르다.
여기에 하나 더 있다. 모두가 같은 환경에서 일하지 않는다. 처리 시간을 문제 삼는 쪽이 특정 작업을 훨씬 빠르게 만들어주는 시스템과 도구에 접근 가능한 반면, 그의 팀은 더 제한된 환경에서 일하는 경우가 있다.
물론 정말로 너무 오래 걸린다면 원인을 찾아 개선해야 한다는 게 그의 입장이다. 다만 사람이 느린 것과 그 사람이 쓰는 시스템이 느린 것은 다르다. 대기업에서 일해보지 않았다면 별로 생각해보지 않았을 구분이라고 그는 말한다.
얼마나 빨리 일하는지는 얼마나 열심히 일하는지만의 문제가 아니다. 어떤 도구가 있는지, 무엇에 접근할 수 있는지, 어떤 프로세스를 따르는지, 몇 명에게 의존하는지가 모두 영향을 준다.
커뮤니케이션이라는 별개의 문제 #
커뮤니케이션은 그 자체로 하나의 학습 경험이었다. 여러 층의 관리 조직, 서로 다른 기대치, 때로는 서로 다른 지시가 있다. 한 사람이 이렇게 말하고, 다른 사람이 조금 다르게 말한다. 들은 대로 했더니, 또 다른 사람이 왜 그렇게 했느냐고 묻는다. 기술 문제를 푸는 중인지 아주 정교한 전화 게임을 하는 중인지 헷갈리는 순간이다.
반대 문제도 있다. 커뮤니케이션이 아주 잘 되는데 — 그냥 너무 오래 되는 경우다. 20분이면 전달할 수 있었을 설명을 두 시간 가까이 들은 적이 있다고 그는 썼다. 이걸 위해 점심을 몇 번 건너뛰기도 했다. 어느 순간부터는 시스템에 병목이 있는지 궁금해하기보다 회의 자체가 병목인지 궁금해지기 시작했다고.
그 아래에서 그가 알아차린 게 있다. 커뮤니케이션은 정보가 상대에게 도달했느냐로 끝나는 문제가 아니다. 상대가 이해했는가? 들어야 할 사람이 들었는가? 두 시간 회의 대신 메시지 한 통이면 됐던 일 아닌가? GitHub 이슈, 디스코드 메시지, "이 PR 리뷰 좀 해줄래?"가 커뮤니케이션의 대부분이었을 때는 거의 생각하지 않았던 질문들이다.
어디로 가든 커뮤니케이션 문제는 계속 돌아온다고 그는 덧붙였다. 사람들이 늘 그게 중요하다고 말하면서도 실제로 실천할 때는 그 지점을 놓친다는 게 아이러니하다고.
그래서 우리가 못하는 건가? #
그는 이 질문을 진지하게 자문했다고 한다. 실수하고, 질문받고, 경력 있는 사람들이 쉬워 보이게 처리하는 걸 보다 보면 자기가 부족한 게 아닌가 하는 생각이 들기 쉽다.
그렇게 보지 않으려 한다는 게 그의 결론이다. 경험이 없는 건 사실이다. 자기들이 합류하기 전부터 존재했던 시스템을 KT와 시뮬레이션과 실전을 거쳐 배우는 중이고, 꽤 빠르게 생산성을 내기를 기대받는다.
어떤 실수는 돌아보면 완전히 자기 탓이었다고 그는 인정한다. 모든 실수가 나쁜 훈련, 나쁜 도구, 나쁜 관리 때문이라고 스스로를 설득하려는 게 아니다. 정말로 잘못 이해한 경우도 있었고, 그게 전부다.
다만 사람들이 잘하게 만들려면 결국 실제로 일을 하게 해줘야 한다는 것도 깨달았다. 실수하고, 왜 그랬는지 이해하고, 매뉴얼이 줄 수 없는 종류의 이해를 천천히 쌓을 공간이 필요하다.
이 일이 나와 맞지 않는다는 것도 알았다 #
그가 받아들여야 했던 사실이 하나 더 있다. 이 일 자체를 별로 즐기지 않는다는 것이다.
지원과 유지보수는 장기적으로 하고 싶은 일이 아니다. 메인프레임은 자기가 전문성을 쌓을 분야로 보이지 않는다. 그리고 그걸 알게 된 게 나쁜 일이라고 생각하지 않는다고 그는 썼다.
소프트웨어 엔지니어링 일자리를 얻으면 자기가 소프트웨어 엔지니어로 사는 걸 좋아하는지 자동으로 알게 될 거라고 생각했었다. 하지만 제품을 만들 수도, 시스템을 유지보수할 수도, 인프라를 다룰 수도, 엔터프라이즈 애플리케이션을 지원할 수도, 장애를 해결할 수도, 아키텍처를 설계할 수도, 클라이언트와 일할 수도, 그냥 코드만 쓸 수도 있다. 그리고 새벽 4시쯤에 일어날 수도 있다.
첫 직장의 쓸모 중 하나가 이것일지도 모른다고 그는 정리했다. 하고 싶은 일을 정확히 찾지 못할 때도 있다. 대신 앞으로 10년을 절대 쓰고 싶지 않은 일이 무엇인지 알게 된다. 그것도 수확이라고.
이 1년이 생각만큼 무의미하지는 않을지도 #
1년을 낭비하는 게 아닌가 싶은 날들이 분명히 있다고 그는 인정한다. 일본어를 공부하고, 업무 외에 뭔가를 만들고, 커리어 방향을 고민하는 중이라도 그렇다.
그런데 합류 이후 실제로 뭐가 변했는지 생각해본다. 대기업을 조금 더 이해하게 됐다. 전에는 무시하고 넘겼을 커뮤니케이션 문제를 알아차린다. 훈련과 경험이 왜 같지 않은지 이해한다. 경력 있는 엔지니어들이 생각조차 하지 않고 그냥 아는 것들이 얼마나 많은지 눈에 들어오기 시작했다. 멍청한 질문을 하는 것에 대한 두려움도 훨씬 줄었다.
그리고 가장 큰 건, 앞으로 10년을 쓰고 싶지 않은 일의 종류가 훨씬 명확해졌다는 것이다. 어디로 가야 할지 찾는 중이라면 어느 방향이 틀렸는지 아는 것도 여전히 유용하다.
교훈이 무엇인지는 아직 모른다 #
최종 교훈이 무엇인지는 아직 모르겠고, 그게 이 글을 끝내는 가장 정직한 방식일 거라고 그는 썼다. 아직 그 안에 있다. 여전히 실수하고, 여전히 나아지려 하고, 언제쯤 아침형 인간이 될지 여전히 궁금해하는 중이다.
이 1년을 돌아보며 "시간 낭비였다"고 생각할지 "현실 세계가 실제로 어떻게 돌아가는지 배운 해였다"고 생각할지는 아직 모른다. 둘 다일 수도 있겠다고 그는 덧붙였다. 다만 첫 엔지니어링 직장이 항상 기대했던 경험을 주지는 않는다는 것은 안다. 때로는 완전히 다른 걸 주고, 그게 무엇이었는지는 훨씬 나중에야 이해할지도 모른다.
글은 이렇게 끝난다. 한동안 일해온 사람들에게, 당시에는 몰랐지만 직장이 무엇을 가르쳐줬는지 묻고 싶다고.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.