지난 이야기

나는 휴학생이고 다시 학교에 돌아가야 한다. 하지만 부캠에서 배운 내용을 바로 실무에 써먹어보고 싶다는 강한 열망이 있었다. 그래서 인턴을 많이 도전했고, 감사히도 인턴 기회를 얻을 수 있게 되었다. 학교로 돌아가기 전까지 이 기회를 통해 실무 경험도 쌓고, 새로운 도전도 해볼 생각이다. 부캠의 자산을 가지고 인턴도 잘 헤쳐나갸야지.

인턴 회고로 돌아왔다🙋 (스압주의)

회고에 앞서

회고를 공유하는 데에 많은 고민이 있었다. 아무래도 회사나 팀이 특정될 수 있을 것 같아 민망하기도 걱정스럽기도 했다.

그래도 이 경험을 성장의 과정으로써 기록해두고 나중에 꺼내보고자 적어본다. 인턴 중에 틈틈이 일기도 쓰고 개인적으로 회고도 했었으나, 작은 기록들이 분산되어 있는 것보단 한 곳에 정리해두는 편이 나중에 읽기 좋을 것 같았기 때문이다. 한 번씩 돌아보며 인턴 동안 배운 것들, 감사했던 모든 일들을 잊지 않고자 한다.

나아가, 인턴을 시작하는 누군가가 이 글로 조금이라도 도움을 받을 수 있길 바란다. 나는 보통 무언가를 새로 시작할 때 경험자의 회고 글을 찾아 읽어보는 편인데, 내 글 또한 누군가에게 하나의 간접 경험으로서 도움이 되면 좋겠다. 특히나 나는 처음 인턴을 해봤던지라 시행착오가 많았는데, 이 글을 읽는 인턴분들은 나의 부족한 부분을 반면교사 삼아 잘 해내시길 바란다.

인턴 기간

타임라인대로 배우고 생각한 것들에 대해 정리해본다.

PART0: 팀 정하기

인턴할 곳을 고르면서 가장 중요하게 생각했던 건 '서버 개발자로서 현업의 트래픽을 경험해볼 수 있는가?'였다. 지난 그룹 프로젝트를 하면서 백엔드 역할을 맡아 로그도 쌓아보고, 부하테스트도 해보고, 캐싱으로 성능 최적화도 해봤으나, 실제 트래픽 위에서 한 게 아니다보니 '공부용'이라는 생각을 지울 수 없었다. 실제 고객이 있는 서버는 어떻게 운영되는지, 어떻게 성능을 최적화하는지 등이 궁금했다. 그러던 중 아래의 JD 문구에 후킹했다.

이를 통해 분산 서비스 환경에서 저지연 대규모 트래픽을 처리하는 백엔드 서비스 라이프 사이클 전반에 대한 이해와 경험을 하실 수 있어요.

추가적으로 해당 팀의 도메인에 관심이 갔다. 머신러닝을 활용한 추천 시스템을 구축하는 곳이었는데, 이전 그룹 프로젝트에서 인공지능 기능을 붙이던 경험이 떠올랐다. 파인 튜닝도 해보고, 튜닝 데이터를 만들기 위해 로그도 쌓아봤다. 실제 회사에서는 ML 기술을 활용하기 위해 어떤 작업을 해두었을지 궁금했고, 관련 업무가 재밌을거란 기대감도 있었다.

또 인공지능과 붙어있는 서버라면 엔지니어링적으로 생각해야할 과제들이 아주 많을 것 같았다. 이전에 그룹 프로젝트를 하면서 모델 응답 속도가 너무 느려서 우리 api 서버가 블로킹되지 않게 하려면 어떻게 해야할지 고민을 했었는데, 이렇듯 인공지능을 붙인다는 건 단순 CRUD 작업을 하는 것을 넘어 더 많은 고민을 야기한다는 걸 깨달았다. 현업에서는 이것보다 더 많은 어려운 문제를 마주했을텐데, 팀에서는 그런 문제들을 어떻게 풀었을지도 궁금했다.

운 좋게도 해당 팀에 합격했다!
출근을 기다리며 이런 일기를 썼는데, 그 때의 감정이 생생해서 첨부한다ㅋㅋ 퇴고 없이 그대로라 잘 안 읽히긴 하나, 감정 기록용으로 적어둔다.

드디어 꿈에 그리던 인턴이 내일 시작이다. 솔직히 아직도 떨떠름하다. 너무 감사한 기회를 얻게 되어 오히려 부담도 된다. 꼭 잘 해내고 싶다.

인턴이라고 하더라도, 나도 이젠 서비스를 만드는 사람이라는 자각을 잃지 않으려 한다. 사실은 엊그제, 우리 Ask-It 서비스를 시연하다가 황준일 마스터님께 이러한 질문을 받았다. ‘Ask-It을 실제 목적에 맞게 제대로 Q&A 하는 데에 사용해보신 적이 있나요?’ 사실은 없었다. 이런 점이 우리의 결과물에 차이를 만들었다는 생각이 든다. 질의응답을 진행할 건데 답변 창에 질문을 보여주지도 않고. 인공지능에게 맥락을 보낼 때도, 사실은 우리 서비스 특성상 빠르게 질문을 올려야 하기에 티키타카가 깊어질 경우가 드물텐데 그냥 돈 절약만을 위해 최신 맥락 한 턴만 보냈다. 서비스에 대한 이해가 조금 부족했다고 밖에 말할 수 없다. 이런 결과는 결국 태도에서 기인했다고 본다. 우리 서비스를 정말 잘 만들어서 마스터클래스에서 사용되는 것을 생생히 꿈꿨더라면 우리가 과연 시연을 안 해봤을까? 당연히 해봤을거다. 하지만 우리는 Ask-It을 딱 그룹 프로젝트 감으로밖에 보지 않았다. 그런 점이 너무 아쉽다.

그래서 더더욱 나는 서비스를 만들어가는 사람이라는 사실을 잊지 않으려 한다. 마인드를 인턴에 국한시키면 안 된다. 나도 함께 만드는 사람. 사용자에게 다가가는 서비스를 개발하는 사람이라는 마인드가 중요하다.

무엇보다 회사가 인턴에게 열려있지 않은가. 주인의식을 가지고 도전한다면 나를 막을 사람이 없다. 오히려 더 많은 영향력을 펼칠 수 있다.

목표를 정리해본다.

1. 서비스를 만드는 사람이라는 주인의식. 서비스에 관심을 가지고 많이 사용해볼 것.
2. ‘인턴’이라는 데에 집중하지 말자. ‘일원’이라는 데에 집중하자. 내가 팀에서 무엇을 할 수 있을지 끊임없이 고민하자.
3. 기록을 하자. 네부캠에서 기록을 잘 해뒀던 것처럼 인턴도 기록을 하자. 무엇을 했는지 기록하자. 그리고 꾸준한 회고를 통해 주차별 목표를 잡아 해내고자 노력하자.

기대되는 것

하드한 엔지니어링 느낌? 이제껏 트래픽은 솔직히 부하테스트가 아닌 이상 경험해본 적이 없다. 분산 환경도, 우리가 막 만들기 시작하는 서비스 상에서는 경험해보기 어렵다. 진짜 분산환경 상황에 닥쳐서 처리해보는 것과, 책 같은 걸로 시뮬레이션 돌려보는 건 차원이 다르니까.

인턴으로서, 피드 개인화에 핵심 백엔드 시스템인 추천 엔진과 피쳐 플랫폼, 스트림 프로세서 개발 및 운영에 참여할 수 있어요. 이를 통해 분산 서비스 환경에서 저지연 대규모 트래픽을 처리하는 백엔드 서비스 라이프 사이클 전반에 대한 이해와 경험을 하실 수 있어요.

이걸 진짜 경험하게 된다는 게 너무 감사하다. 정말 인턴이 아니면 해볼 수 없는 기회니까.

(완전 신나있다..)

PART1: 온보딩

'온보딩'이라는 것을 들어보았는가? 나는 온보딩 개념을 회사에서 처음 알게 되었다. 우리 조직이라는 배에 내가 올라 타는 것, 즉 신규 입사자의 적응 과정을 의미한다. 이 과정에서의 경험과 느낀점들을 몇 가지 적어본다.

코드에 기여하기

첫 주차에 온보딩 과제를 하나 받았다. 안 쓰이는 코드를 지우는 간단한 작업이었다. 과제를 받을 땐 가볍게 생각했으나, 막상 코드를 확인해보니 내가 알던 코드(?)가 아니었다. Protobuf 사용법을 알아야 했고, Go로 짜둔 테스트 수정도 필요했으며, PR이 merge되면 배포도 해봐야 했다.

처음엔 한 번에 '어떻게 해봐야겠다'라는 게 머릿속에 잘 그려지지 않아 당황했다. 그래도 필요한 기술들을 AI를 통해 알아보기도 하고, 모르는 건 질문도 해가며 한 걸음씩 헤쳐나갔다. 덕분에 일주일 안에 해낼 수 있었다. 지금 생각해보면 그 간단한 작업 덕분에 많은 것들을 금세 익힐 수 있었던 것 같다. 덤으로 자신감도 얻었다.

만약 첫 주에 명확한 목표가 없었다면 큰 코드베이스를 여기저기 파악해보거나 기술 학습 위주로 시간을 보냈을 것이다. 하지만 목표가 분명하니 그에 필요한 수단들을 배우면서 자연스럽게 큰 그림을 그릴 수 있게 되었고, 이게 추후에도 많은 도움이 되었다.

이번 온보딩 때에는 주어진 과제를 수행했지만, 나중엔 주어지지 않더라도 TODO 주석으로 남겨진 사소한 일을 첫주차에 처리해보면서 업무 처리 프로세스에 대한 감을 잡아보고자 한다.

혼자하면 1시간+, 질문하면 1분 이내

개발환경을 셋팅하면서 Go 설치에 어려움을 겪었다. 권한이 없다고 해서 우분투에서 했던 것처럼 sudo 명령어로 설치했더니, gopath가 꼬여버렸다. 그런 줄도 모르고 1시간 동안 삽질했다. (지금 생각해보면 참 흑역사다.)

그때 버디가 먼저 "안 되는 거 있어요?"라고 물어봐 주셨고, 그제서야 내 상황을 털어놨다. 설치를 다시 도와주셨는데, 1분도 안 돼서 모든 게 해결됐다.

그날 집에 가면서 '질문 좀 할걸'하는 후회를 엄청 했다. 그전까지는 질문을 하더라도 좋은 질문을 해야 한다거나, 이미 문서에 나와 있는 건 아닌가 하는 생각으로 주저하곤 했다. 완벽한 질문을 하려고 하거나 "이거 하나만 더 해보고 질문하자"는 사고가 나를 막았다.

일기를 다시 읽어보니 첫 한 달 동안 이런 비슷한 일이 몇 번 더 있었다. 거기에 "제발 빠르게 질문하자"고 엄청 적어놨고, 고치려고 노력했다. 덕분에 인턴이 끝나는 시점에는 버디로부터 "질문을 적극적으로 하는 모습을 보여주셨다"라는 피드백을 받았다!

물론 질문을 너무 막 해서도 안 된다. 상대가 어떤 컨텍스트도 없는 상황에서 그냥 질문하면 어떤 해결책도 받을 수 없으니까.

이렇게 한 번 경험을 하고 나니, 이전에 읽었던 질문 '잘' 하는 법이라는 글이 새롭게 와닿았다. 질문에 대한 인사이트가 궁금하다면 해당 글을 추천한다.

그래서 도대체 우리 팀이 무슨 일을 하는 건데?

앞서 우리 팀에 들어온 이유를 나열할 때, 팀이 어떤 문제를 풀고 있는지 궁금했다고 말했다. 하지만 정작 와보니, 팀이 어떤 문제를 풀고 있는지 파악하기는 커녕 무슨 말을 하는지 이해하는 것부터 어려웠다. AI 관련 기초 지식이 부족한 채로 들어온 탓도 있고, 분산 환경과 관련된 새로운 기술들도 많았기 때문이다. 대부분의 이야기를 못 알아듣는 찝찝한 상태로 4주를 보내다 보니, 일단 과제는 하고 있는데 팀 업무의 큰 그림이 그려지지 않는 느낌이 들었다.

그래서 시도한 방법이 있다. 팀 회의가 끝난 이후, 해당 회의에서 못 알아 들었던 키워드들을 모두 노션 페이지에 적어두고 혼자 AI와 답을 찾아본 뒤, 그걸 팀원들에게 공유해서 교차검증을 받는 방식이었다. 이 방법은 꽤 유용했다. 팀원들은 수많은 질문에 일일이 답변하지 않아도 되고, 나는 잘못 이해한 부분을 알고 넘어갈 수 있었기 때문이다.

물론 이렇게 벌크로 질문을 한다고 해서 하루 아침에 우리 팀이 하는 일을 이해할 수 있었던 건 아니었다. 그래도 이전에는 회의 때마다 대부분을 못 알아 들었으나, 이제는 반가운 용어도 한 번씩 마주치는 느낌이다.

PART2: 프로젝트를 진행하며

온보딩 과제를 성공적으로 끝내고, 드디어 나의 태스크를 진행하기 시작했다. 프로젝트를 하며 정말 많은 시행착오를 겪었는데, 정리해 이야기 해본다.

모르는 기술들을 어떻게 익혀나갈 것인가

Go, gRPC 등 대부분의 기술들이 새로웠다. 이 상황에서 무언갈 구현하기 위해서는 기술을 익히는 시간이 필요했다.

처음에는 대학에서 해오던 책읽기 방식을 택했다. 2시간 정도 일찍 출근해서 Go랭 책을 읽어보려고 했고, 주말에는 gRPC 책을 읽어도 봤다. 하지만 500쪽짜리 책을 다 읽고 프로젝트를 시작한다는 건 현실적이지 않았다. 3개월이라는 짧은 시간을 고려했을 때 더 효율적인 방법을 찾아야 했다.

그래서 방향을 바꿨다. 회사 코드를 직접 읽으며 배우기로 한 것이다. 내가 필요한 기능과 관련된 코드들을 차근차근 이해해보려고 노력했고, 이해가 안 되는 부분은 AI를 통해 해결했다. 이렇게 하다 보니 점차 문법도 눈에 익기 시작했으며 자주 반복되는 패턴도 보였다.

그리고 구현하며 배우기로 했다. 무언갈 만들기 위해서 완벽히 준비하고 시작하기보다는, 일단 부딪치며 빠르게 실패해보는 게 좋을 것 같았다. 실제로 처음엔 relfection 문법이 잘 안 쓰는 컨벤션인 줄도 모르고 사용했다가 피드백을 받기도 했다. 하지만 그런 시행착오를 겪으며 Go와 gRPC에 조금씩 익숙해져 나갔다.

완전히 베이스가 없는 상황에서 회사 코드로 공부하며 성장하는 게 단기적으로는 아주 좋은 선택이었던 것 같다. 물론 장기적인 관점에서 성장하기 위해서는 책에서 오는 딥한 통찰력도 도움이 될 수는 있겠으나, 단기적으로는 이 방법이 더 효과적이었던 것 같다.

느리다는 피드백을 받았을 때

6주 차에 접어들었을 때, 버디로부터 '구현이 느리다'는 피드백을 받았다. 설계 문서를 작성하는 데에 2주라는 시간을 투자했으나, 구현하는 데에 3주째 쓰고 있었기 때문이다. 설계에 많은 시간을 투자한 것 대비 빠르게 구현이 진행되진 못했다는 피드백이었다.

당시에는 꽤나 철렁했던 기억이 난다. 피드백을 받은 뒤, 내 업무 속도가 느려진 원인을 차분히 되짚어보았다.

1. 블로킹 시간을 효율적으로 활용하지 못한다.

   설계 문서를 작성해 피드백을 요청한 후 대기하는 동안, 다른 업무를 찾아 진행하기보단 우선순위가 낮은 공부 관련 자료를 찾아보며 시간을 보냈다.

2. 설계 문서가 충분하지 않았다.

   구현 직전까지 고민해서 설계 문서를 정리하진 못했던 것 같다. 그러다보니 구현 과정에서 설계해두지 않은 부분이 나타났다. 구현 시간에 설계를 하고 있는 상황이 발생하다보니 구현에만 집중하지 못해 시간이 오래 걸리게 되었다.

3. 일하는 것보다 학습하는 걸 우선했다.

   우리 팀이 무엇을 하는지 궁금했던 걸 정리하고 질문하고 하는 데에, 코드를 이해하는 데에 필요 이상으로 많은 시간을 투자했다. 주로 업무가 블로킹된 시간 동안 그런 활동을 진행했는데, 돌이켜보면 일하는 사람의 마인드보다 학생으로서 배우려는 마인드가 강했던 것 같다.

그래도 이 피드백 덕분에 나의 부족한 점을 인지할 수 있었다. 빠르게 일을 처리하기 위해서 업무를 세분화하고 우선순위를 정하는 작업을 진행하였으며, 나아가 주변에 조언을 구하기도 하고, 동료들의 업무 방식을 관찰해 따라해보려고도 했다. 또 유튜브로도 시청하곤 했는데, 어느 순간부터 알고리즘에 '일 잘하는 사람'이 많이 뜨기도 했다.ㅋㅎㅋㅋ

설계 문서에 대해서도 다시 생각하게 되었다. 단순히 TODO 리스트의 나열이 아니라, 구현 직전까지 구체적으로 고민된 결과물이 되어야 한다는 점을 절실히 느꼈다. (문서에 대해서는 아래 더 자세히 써보려고 한다.)

무엇보다 '학습 마인드'에서 '일 마인드'로의 전환이었다. 지금껏 너무 학생 마인드로 내 상황을 바라봤음을 인지했다. 당시 회고를 하다가, 예전에 다른 인턴 면접에서 '일 경험이 있는지'를 물었던 게 떠올랐다. 그때는 그 질문의 의도를 몰랐는데, 지금 와서 생각해보니 '일하는 사람'으로서의 태도를 묻는 말이었다는 걸 알게 됐다. 확실히 학습이 주인 학생과 업무가 주인 회사는 다르다는 걸 배웠다.

이미 문서는 아쉽게 끝났지만, 1번과 3번의 부족했던 점을 개선하고자 노력했으며, 덕분에 해당 작업은 6주차 내에 잘 마무리할 수 있었다. 그 이후의 작업에서도 속도를 내기 위해 노력했고, 덕분에 그 작업 만큼은 '예상보다 빨리 끝났다'는 피드백을 들을 수도 있었다.

AI가 정말 시간을 줄여주었는가

인턴 기간 동안 Cursor를 사용했다. 입사 전까지는 개인적으로 Claude를 구독해 사용했는데, 코드에 대한 질문을 할 때마다 컨텍스트를 설명해줘야하는 번거로움이 있었다. 그런 면에서 Cursor는 혁신적이었다. VSCode 화면에서 바로 질문을 할 수 있었으니까!

코드를 작성할 때뿐만 아니라 이해할 때에도 많은 도움이 되었다. 거대한 코드베이스 태평양 한 가운데에서 나침판이라도 있는 느낌이랄까. 새로운 모델이 나오면 시도해보고, 뭐가 더 나은지 비교도 해보고 하면서 나름대로 되게 알차게 활용했다.

하지만 어느 순간부터 내가 정말 AI를 통해 성장하고 있는지, 시간을 줄이고 있는지에 대한 의문이 들었다.

AI로 인해 오히려 시간이 더 걸린 것 같은 상황을 적어본다.

1. 생각을 안 하려고 하는 나를 발견했다

   AI에게 질문을 할 때 너무 포괄적으로 물어보다 보니 오히려 시간이 더 걸리는 경우가 많았다. 이를테면 ~기능을 추가할 건데, 우아한 구조로 만들어줘 처럼 모호한 질문을 했다. 내가 쪼개서 스탭 바이 스탭으로 해야할 모든 일들을 통으로 주고, 알잘딱깔센으로 완성해 내놓아달라는 요청을 했던 것이다. 결국 해당 질문에 대한 답변이 마음에 안 들어 별로라고 몇 번 더 피드백을 주다가, '내가 하고 말지' 하며 종이에 설계를 다시 해서 해결했다. 처음부터 종이를 꺼내들었다면 오히려 시간이 절약되었을텐데, 생각하기 싫어하는 대가를 시간으로 치르고 말았다.

2. 바이브 코딩의 부채

   어드민 UI를 만드는 작업을 했다. 초기에는 UI를 바이브 코딩으로 설계했다. 그렇게 만들어진 정적 파일을 사람들에게 공유하여, 단순 디자인보다 훨씬 그럴듯한 데모를 보여줬다. 무언가를 빠르게 만들어내는 데에는 확실히 효과적이었다.

   그러나 운영되기 시작한 뒤부터는 심리적으로 달라졌다. 이미 잘 돌아가는 것에 바이브 코딩으로 기능 추가를 하는 게 꽤나 부담스러운 일로 느껴졌다. 다른 잘 돌아가던 기능에 영향을 줄 것 같았기 때문이다. 그래서 이후의 기능 추가는 일일이 코드를 읽어본 뒤, 직접 구현했다.

3. AI의 결과물을 고치는 데에 두 배의 시간이 걸렸다

   Go를 사용해 MCP 서버를 구현했다. Go도 익숙치 않았는데다가 MCP 서버 또한 이번에 처음 만들어보는 것었지만, 일주일 내로 MCP tool call 데모를 해내는 게 목표였기 때문에 빠르게 만들어야했다. 이를 위해 AI에 과하게 의존해 구현했다. 나름 워킹데이 2일 동안 목표로 했던 기능은 완성했으나, PR에서 accept 받지 못했고, 결국 고치는 데에 4일을 더 썼다.

   이때 후회를 정말 많이 했다. 고치는 데에만 두 배의 시간을 쓴 것도 그렇고, 애초에 만들면서 배울 수 있는 사고의 기회 마저 날려버린 것 같았기 때문이다. 차라리 AI보다 내가 더 주도적으로 구현했다면 Go 공부에도 도움이 되지 않았을까. 그리고 무엇보다 내 코드의 근거를 설명하지 못하고 있는 상태가 굉장히 불편했다.

당시에 MCP 서버를 고치면서 버디와 페어프로그래밍도 해봤는데, 시니어 개발자가 Cursor를 어떻게 쓰는지 엿볼 수 있어 좋았다. 당시 확실히 느낀 건, 주객이 전도되지 않는다는 거였다. 결국 코드의 책임자는 나다!

앞으로는 LLM에게 잘 질문하는 것 또한 의식적으로 훈련해야할 것 같다. 무엇보다 AI를 활용하여 실질적 시간 단축을 이뤄냈는지 계속해서 고민해봐야할 것이다.

PS. 최근 Geek News에서 재밌게 읽은 AI 활용법을 공유해본다. 나의 문제 상황들에 적용해봤다면 도움이 됐을 것 같다.

• AI를 프로젝트 내의 신입 개발자 혹은 코드 리뷰어로 여겨, 원하는 방향으로 상세히 안내하고 점진적으로 퀄리티를 높이는 것이 성공의 비결임 (출처: 프로그래머를 위한 프롬프트 엔지니어링 플레이북)

• 바이브 코딩 시 테스트 코드는 반드시 사람이 작성 (출처: Claude로 실제 코드를 배포하며 얻은 실전 노트)

설계 문서 작성하기

사실 나도 여전히 설계 문서 작성에 있어 부족한 점이 많다. 그럼에도 불구하고, 3개월 전의 나에게 해주고 싶은 말은 아래와 같다.

(멋진 문서는 농담이고)

문서를 쓰는 목적이 무엇인가?

• 설계를 빡세게 하기 위해서

  설계 단계에서 많이 생각해두면, 구현 단계에서 우왕좌왕하는 일이 줄어든다. 장기적으로 보면 일이 훨씬 빠르게 끝난다.

• 함께 일하기 위해서

  내가 쓴 문서를 기반으로 팀원분들과 설계 레벨의 싱크를 맞출 수 있다. 이걸 안 해두면 추후 PR 리뷰를 볼 때 큰 구조에 대한 리뷰가 발생하는데, 그로 인해 PR이 오랫동안 open 상태로 머물게 된다. 문서를 통해 싱크해두고 PR을 보내면 핵심적인 부분에 집중해서 빠르게 리뷰하고 넘길 수 있어 일이 빨라진다.

• 태스크를 나누는 데에 도움이 된다

  문서를 잘 써두면, 해당 작업을 더 작은 단위로 쪼개서 바라볼 수 있게 된다. 자연스럽게 PR 단위로 작업을 계획해볼 수도 있으며, 한 PR이 리뷰 중일 땐 다른 작업을 진행하는 등 논블로킹으로 일할 수 있다.

어떻게 쓰는 것이 좋은가?

• 목표를 명확히 하는 게 좋다. 두 세 문장으로 목표를 표현할 수 있으면 좋다.
• 목표가 아닌 것까지 적어주면 좋다.
• 컨텍스트가 없는 사람이 와서 문서를 읽더라도 바로 구현해낼 수 있을 정도로 잘 설계되면 좋다.
• 성능 이슈나 사용성 개선처럼 해결해야할 문제가 있는 경우, 수치를 동반하면 좋다.

무작정 유저 인터뷰 해보기

프로젝트를 진행하면서 되게 인상깊었던 경험이 바로 유저 인터뷰였다.

내가 만드는 디버깅 환경의 주요 유저는 머신러닝 엔지니어분들이었고, 그분들이 평소에 어떤 점을 불편하게 느끼는지 파악해 서비스에 반영하는 것이 목표였다.

처음엔 해당 기능을 과제로 받아 구현했지만, 점점 궁금해졌다. 이 기능이 실제로 잘 쓰이고 있을까? 정말 도움이 되었을까? 혹시 내가 놓친 니즈는 없을까? 이런 질문들에 대해, 팀 내부보다는 실제 유저인 고객 엔지니어분들의 의견을 듣는 게 좋겠다는 추천을 받았다.

처음엔 설문지를 만들어 돌리려 했는데, 예상과 달리 반응이 거의 없었다. 그래서 그냥 직접 찾아가 보기로 했다. 많은 MLE 분들 중 누구에게 인터뷰 요청을 드려야 할지 고민하다가, 어차피 누군가는 거절하겠지 싶어서 6명에게 무작정 요청을 드렸다. 그런데 정말 감사하게도 모두 흔쾌히 오케이 해주셔서, 다양한 이야기를 나눌 수 있었다.

어떤 일을 하고 계신지, 평소 어떤 점이 불편한지, 그리고 내가 만든 기능 한 번 써보시라고 슬쩍 홍보도 하고, 향후 추가해볼 만한 기능에 대해서도 함께 이야기 나눴다.

이 경험에서 느낀 점이 많다. 이전에는 질문 하나도 어렵다며 망설이던 내가, 직접 사람들을 찾아가 인터뷰를 진행했다는 사실 자체가 신기했다. 무엇보다 예상보다 훨씬 많은 분들이 친절하게 응해주시고, 이야기 나누는 데에도 적극적이셨다. 아무리 바빠 보이는 사람이어도, 결국 내 일을 굴러가게 만들기 위해선 ‘요청할 줄 아는 용기’가 필요하다는 걸 배웠다.

PART3: 일하며 좋았던 것들

훌륭한 동료, 최고의 환경

회사 복지라는 걸 처음 경험해봤다. 아침엔 회사 탕비실에서 아침 식사를 해결하고, 점심 저녁 모두 제공받았으며, 야근 하면 택시까지 지원해준다. 장비도 모두 대박이었다. 특히 집에 있는 모니터는 화질이 안 좋아서 오래 보면 눈이 아팠는데, 회사 모니터를 써보고는 신세계를 경험했다. 이 밖에도 워크샵을 아주 좋은 곳으로 다녀오는 등 호사를 누렸다. (3개월 간 너무 잘 먹어서 체중이 많이 늘었다..)

이런 복지는 입사 직후에 바로 체감할 수 있었지만, 서서히 놀라게 된 건 훌륭한 동료들 때문이었다.
Go, gRPC 등 궁금한 기술들을 구글링할 때면 우리 팀원들의 블로그가 나온다. 게다가 명문대 출신도, 엄청난 커리어를 가진 분들도 많다.

유명세도 놀랍지만, 일할 때 느껴지던 능력들이 더 강렬했다. 대화할 때 군더더기 없이 명료하다는 느낌을 확 받았고, 또 굉장히 논리적으로 잘 말씀하시더라. 저분들의 지식은 도대체 어디까지인가 하며 아득해질 때도 많았다. 너무 뛰어난 분들이 많아서 때로는 내가 되게 작아보이기도 했지만, 오히려 그만큼 배울 게 천지인 환경이라는 생각에 ‘오히려 좋다’고 느꼈다.

특히 좋았던 건, 그들의 일하는 방식을 가까이서 보고 배울 수 있다는 거다!
정리해본 특징 몇 가지를 적어보자면 아래와 같다.

• 생산성을 위한 도구를 잘 찾아서 쓴다.
• 신규 기술이 나오면 간단한 사이드 프로젝트를 해보며 미리 익혀둔다.
• Geek News 등 신규 소식을 접하는 창구가 있다.
• 문서를 읽거나 공유할 땐 영어이더라도 스스럼이 없다.
• 공식문서가 아쉬우면 코드를 까본다.
• 오픈소스 기여가 자연스럽다.
• 무언갈 하기 전에 문서를 작성하고, 공유해서 싱크를 맞춘다.
• 책을 많이 읽는다. (전공 지식이든 아니든 가리지 않고!)
• 비동기·논블로킹 방식으로 일한다. (블로킹 상황이 생기면, 작은 다른 업무를 꺼내와 처리하는 식으로)

인턴이어도 의견을 제시한다

백엔드 팀 소속이지만, 결국 서비스를 만드는 한 사람인 건 변함없다. 주기적으로 PM, MLE, BE 엔지니어가 모여 서비스에 대해 논의하는 시간이 있었는데, 이 시간이 정말 재밌었다.

또 정해진 때가 아니더라도, 특정 기획이 있을 땐 슬랙에서 아이디어를 발산해볼 수 있었는데, 그 때 논의에 참여했던 게 기억에 난다. 내가 제시한 아이디어가 꽤나 긍정적으로 받아들여지기도 했고, 또 이런 측면에서는 아쉽다 라는 이야기도 받았다. 내가 인턴이라서 의견을 못 내는 것도, 내가 인턴이라서 추켜세워 주는 것도 아닌, 그냥 정말 일원으로서 논의에 참여하고 있다는 느낌이 나서 되게 즐거웠던 기억이 난다.

플랫폼 조직이라는 게 있구나

나는 백엔드 개발자라고 하면, 프론트엔드 개발자나 기획자와 협업하며 필요한 API를 만드는 모습을 떠올려왔다. 우리 팀도 처음엔 그럴 거라 생각했다.

하지만 입사 후, 우리 팀이 백 중에 백이구나(?) 라는 걸 깨달았다. 프론트엔드 개발자가 아닌 다른 서버 개발자들(우리의 클라이언트)과 소통하고, 우리 서버 코드에 PR을 올려 특정 기능을 추가하는 기여자들(주로 MLE)과 협업하는 구조였다.

그래서 특히나 설계가 중요했다. 빠르게 작은 걸 만들어내는 것보다 오래 여기저기 쓰이는 것을 주로 만들었기 때문이다. 빠르게 기능을 출시하는 서비스 조직과는 확연히 다른 접근 방식이었다.

또 운영이 어떻게 이루어지는지도 많이 보고 배웠다. 팀이 정말 멋있다고 생각했던 순간은 (웃기게도) 장애가 발생했을 때였다. 나였다면 허둥지둥 당황했을 텐데, 팀원들은 프로페셔널하게 쌓아둔 에러 로그를 확인하고 문제 지점을 파악해 공유한 뒤 차근차근 해결해나가는 모습을 보여줬다. 정말 대단하다고 느꼈다.

또 온콜(On-call) 개념도 이때 처음 알게 되었다. 온콜이 플랫폼 조직만 하는 건 아니긴 하지만, 서버 운영이 어떤식으로 돌아가는지를 느낄 수 있었다.

이런 플랫폼 조직이 있는지도 경험하지 않았다면 몰랐을 것 같다. 인턴십을 통해 알아갈 수 있어 좋았다.

개발하기 좋은 환경

무엇보다 정말 개발하기 좋은 환경이었다.

배포가 놀라울 정도로 간단했다. 원래 정적 파일을 배포하려면 이것저것 설정해야 할 게 많았는데, 사내 플랫폼을 사용하니 엄청 쉽고 빠르게 처리할 수 있었다.

또 필요한 기능이 있다고 플랫폼 팀에 요청드리면 빠르게 만들어주신다. 한 번은 AI 기능을 구현할 때 사내 AI 플랫폼 팀에 필요한 기능을 요청드린 적이 있다. 나와 간단히 커피챗 시간을 가지며 구체적인 요구사항을 들어보시고 바로 구현에 착수해주신 게 기억에 남는다.

하고 싶은 게 있다면 뭐든 빠르게 실현할 수 있는 환경이 정말 좋았던 기억으로 남아있다.

PART4: 전환 면접과 그 이후에 든 생각

인턴 기간이 3주 조금 안 남았을 무렵, 인생 첫 평가를 받았다. 나와 함께 일한 분들이 해주신 평가였다. 내가 잘한 점과 아쉬운 점이 무엇인지 종합해서 전달받았다. 이렇게 객관적인 피드백을 받을 수 있다는 점이 굉장히 감사했다. 명확하게 내가 나아가야 할 다음 단계를 판단할 수 있었기 때문이다.

그리고 감사하게도 팀에서 전환 결정을 내려주셨다. 아직 부족한 점이 있기는 하나, 성장 가능성을 종합적으로 판단해 내려주신 결정이었다. 생각할수록 부족한 점이 참 많았던 것 같은데, 그럼에도 나를 믿어준 우리 팀분들께 너무 감사했다. 얼른 성장해서 어엿하게 1인분 하는 사람이 되어 믿어준 우리 팀에 보탬이 되고 싶었다.

물론 바로 전환이 되는 건 아니었다. 전환 면접이라는 단계를 통과해야 최종적으로 합류할 수 있다. 전환 결정이 나고 거의 4일만에 바로 면접을 봤다. 그래도 나름 준비해서 갔으나, 기술 면접 때 만큼 빡세게 하지 못했던 게 아쉬움으로 남긴 한다. 그래도 면접 준비를 하면서 지금껏 정신없이 업무만 생각해오던 것에서 벗어나, 내가 어떤 생각을 가지고 일해왔는지 정리해볼 수 있어서 좋았다.

결국 면접 시간이 다가왔다. 잔뜩 긴장한 채로 면접에 임했던 기억이 난다. 아쉽게도 면접 결과는 탈락이었다.

면접을 보고 결과를 기다리며, 그리고 결과를 받아들이며 되게 많은 생각들을 했는데, 이에 대해 정리해본다.

지속 가능한 업무 방식이었는가

한 달 반쯤 됐을 때, 버디에게 일이 느리다는 피드백을 받았다. 그 전까진 나름 조금씩 시간을 내서 우리 팀이 뭘 하는지 찾아 정리하고, Go 언어 책도 좀 읽어보고 하고 있었다. 그런데 느리다는 피드백을 받으니까 철렁했던 기억이 난다.

능률 향상을 위해 업무 외 학습하는 시간까지도 모두 없애버리고 일하는 시간을 쫙 늘렸다. 만들면서 배우기 위한 전략의 일환이었다. 이때부턴 거의 9시반 전에 도착해서 10시 넘어 집에 가곤 했던 것 같다. 해당 프로젝트가 잘 마무리된 이후 다른 프로젝트를 할 때에도 주어진 기간 대비 MVP를 키운 바람에 데드라인까지 일을 못 끝내는 상황이 발생했다. 또 한 번 철렁해서 주말까지도 일해 겨우 마무리했다.

돌아보면 장기적으로 좋지 않다는 생각이 든다. 이렇게 일하면서 배우다보면 나중에는 실력이 향상돼서 일하는 시간이 점차 줄어들 거라고 기대하고 있었다. 실제로 첫 문서 작성 이후 아쉬운 점을 회고하고 나니, 다음 문서 작업을 할 땐 좀 더 빠르게 발전된 결과물을 만들 수 있었다. 하지만 개발 작업에 대해 다시 공부하거나 의식적으로 짚고 넘어가는 시간은 거의 가지지 못했다. 빠르게 기능을 쳐낼 뿐이었기에 유의미하게 개발 속도 단축을 이뤄내진 못했던 것 같아 아쉬움이 남는다.

또 되게 심적으로 여유를 가지 못하게 되었던 것 같다. 프로젝트를 하면서, 사용자 경험을 위한 세심한 부분들이나 운영 효율성을 위한 요소들을 더 깊이 고민해보았더라면 하는 아쉬움이 남는다. 그런 디테일을 고민할 새도 없이 일단 빨리 결과를 내는 데에만 사고가 경직되어 있었던 게 아쉽다.

물론 그래도 어떻게든 해내보고자 열심히 한 데에는 후회가 없다. 다만 이런 시행착오를 겪었으니, 앞으로는 더 똑똑하게 열심히 하면 좋을 것 같다.

P.S. <함께 자라기> 책을 다시 읽고 있는 요즘인데, 1부 자라기 부분의 내용이 이전과 다른 무게감으로 읽힌다. 의식적 훈련에 대해 뜨끔하며 읽었다.

P.P.S. 퇴사 전에 몇 권의 책을 추천받아 요즘 읽어보고 있는데, <이펙티브 엔지니어>라는 책에 나의 고민과 맞물려 좋은 해결책을 제시해주고 있는 걸 발견했다. 인턴 기간 중 읽어봤다면 바로 적용해보며 더 전략적으로 일해볼 수 있었을텐데 늦게 알아 아쉽다는 생각까지 들 정도다. 나와 비슷한 고민이 있으신 분이라면 읽어보시길!

PART5: 마지막 주와 퇴사

커피챗 왕창하기!

그 주가 마지막 주라는 걸, 월요일 아침에 출근하고 나서야 알게 되었다. 어떻게 마지막 주를 보내야하나 생각해봤지만, 결국 회사 사람들과 조금이라도 더 많이 이야기해보는 게 남는 일인 것 같아 여기저기 커피챗을 요청드리고 다녔다. 감사하게도 먼저 요청해주시는 분들도 있었다.

커피챗이 앞으로의 방향성을 설정하는 데에 되게 많은 도움이 되었다. Go를 좀 더 공부해보려 한다고 말씀드렸더니, 대부분의 분들이 '언어 공부는 필요할 때 상황에 맞게 익히면 된다'고, '일단은 대학생으로서 CS 지식을 탄탄하게 다지는 걸 우선하라'고 조언해주셨다. 또 좋은 책들도 많이 추천받았고, 오픈소스 활동 역시 공통적으로 추천받았다.

게다가 어떤 분은 더 작은 회사를, 어떤 분은 더 큰 회사를 가보는 것도 제안해 주시기도 했는데, 두 조언 모두 결국엔 다양한 환경을 경험해보며 나에게 맞는 환경을 찾아보라는 거였다.

모두가 진심으로 도움이 되는 이야기들을 해주셔서 정말 감사한 일주일이었다. 진작 더 많이 커피챗을 해봤으면 좋았겠다는 아쉬움이 들 정도로 유익했다.

앞으로의 계획을 세워봤다

1. 다시 대학으로 돌아간다.

   나는 아직 3학년이라 학교로 돌아가야 한다. 하지만 이제는 인턴 전과는 다르게 학교 생활을 할 것 같다. 시간 여행을 하고 돌아온 사람처럼 시야가 달라진 기분이랄까. 이전에는 다들 중요하다고 하는 CS이기에 열심히 했다면, 이제는 내적 동기가 가득 채워진 것 같다. 게다가 시간적 여유를 가지고 마음껏 공부할 수 있다는 것도 너무 좋을 것 같다.

2. 오픈소스

   큰 코드베이스를 이해하고 직접 기능까지 붙여본 건 이번이 처음이었다. 큰 코드를 읽어본 경험이 없다보니 처음에 많이 버벅였는데, 코드 읽는 훈련을 미리 해두면 좋겠다는 생각이 들었다. 커피챗에서도 많이 추천받은 만큼, 반드시 오픈소스 활동을 시작해보려고 한다.

3. 개발자 습관(?) 만들기

   오픈소스 활동, 책을 통한 지식 습득 등 회사 사람들의 습관들을 내 것으로 흡수해보고 싶다.

4. 해보고 싶었던 공부 다 해보기

   위에도 써놨듯 CS 공부 정말 재밌게 해보고 싶다.

   또 회사를 경험하면서 ML, 인프라 분야에 새로 눈 뜬 기분이랄까. 관련 해서 더 찾아 공부해보면 재밌을 것 같다.

5. 인턴, 일 경험 더 해보기

   이번 인턴 경험에서 많이 배웠던 만큼, 앞으로도 기회가 닿는대로 일 경험을 해보고자 한다. 또 만약 다른 인턴을 기회가 다시 생긴다면 그땐 그냥 더 겁 없이 즐겨보고 싶다. 괜히 눈치보고 질문하는 걸 머뭇거리던 순간이 아쉽달까.

   또 경험들을 토대로 내가 어떤 도메인에서, 어떤 체계의 회사에서 일 할 때 더 재밌어하는지를 파악해나가고 싶다. 이번 하반기에 3-2를 보내면서, 또 한번 여기저기 지원해볼 예정이다.

6. 여행다니기

   회사에 다니면 여행 갈 때 휴가를 쓰고 가야한단 말이 드디어 체감된다. 시간 빌게이츠일 때 여행도 다녀놔야겠더라.

퇴사하고 2주가 흘렀다

금요일에 모두에게 인사를 드리고 퇴근을 하는데, 기분이 꽤나 떨떠름했다. 지금까지 다 꿈을 꾼 건가 싶은 기분이 들었달까. 나름 나에게 주는 선물로 퇴근길에 맥북 픽업 이벤트(드디어 맥북 구입!)도 잡아놨으나, 마냥 후련하진 않았다. 계속 회사 건물을 돌아보게 되었다ㅋㅋㅋ

그렇게 2주가 흘렀다. 평일 낮의 자유로움이 얼마나 감사한건지 새삼 느끼고 있다.

시간 빌게이츠로서 하고 싶은 모든 것들을 해보는 중이다. 수영도 다시 시작했고, 이전에 해오던 스터디에도 다시 합류했으며, 읽고 싶던 책들도 마음껏 읽고 있다. 하루종일 잠만 잔 날도 있고, 날 좋으면 훌쩍 산책나가거나 좋아하는 카페를 무작정 찾아가기도 한다. 비로소 대학생으로 돌아온 기분이다ㅋㅋㅋ

이렇게 붕 뜨는 게 꽤나 오랜만인 것 같다. 작년 6월부터 네부캠을 시작해 2월까지 함께했고, 리팩토링 최종 발표를 끝낸 다음주에 바로 인턴 입사를 해서 또 한바탕 달려왔다. 그래서인지 쉬는 게 좋으면서도 한편으로는 도파민이 부족한 느낌도 든다. 또 어딘가에 합류에 열심히 달리고 있어야할 것 같은 기분이다..ㅎㅎ

끝으로

엄청난 스압이었는데, 여기까지 다 읽은 사람이 있을까? (읽어주셔서 감사합니다)

3개월이라는 게 정말 짧은 시간이었는데, 압축적으로 많은 걸 배운 것 같다. 시야가 이전보다 훨씬 넓어진 게 체감된다. 이제 다시 학기를 마치러 학교로 돌아가겠지만, 여기서 배운 것들을 잊지 않고 더 넓게 멀리 보는 학생이 되고 싶다.

또 이 글을 보는 대학생분들께 적극적으로 인턴을 하시길 추천드린다. 사실 나는 3학년이면 인턴 못할거고 시켜주는 곳도 별로 없을거라 생각했는데, 전혀 그렇지 않았다. 특히 추천하는 건 ICT 인턴십 제도나 학교 현장 실습을 활용하는 방법이다. 또 이런 게 아니어도 링커리어, 직행 등의 사이트를 보면 인턴 공고가 심심치 않게 보이니, 잘 활용하시면 좋을 것 같다.

읽으면서 "진짜 많이 저렇게까지 못한다고?" 하며 필자의 부족함에 놀라셨을 수도 있겠으나, 이게 나의 현 주소였다. 털어놓고 나니 진짜 못난 나였구나 싶긴 하지만, 그래도 인턴 경험을 통해 이런 시행착오를 겪어볼 수 있어 다행이라는 생각도 든다. 다시 또 회사에 가게 된다면 그땐 훨씬 더 잘 해내리라!