첫 회사의 입사를 앞두고

들어가며

이전에는 완벽하게 준비를 마친 뒤에야 무언가를 시작할 수 있다고 생각했다. 부족한 부분을 다 채우고 준비된 모습으로 새로운 환경에 들어가고 싶었다. 그런데 처음 지원한 회사의 면접에서 합격 소식을 받았다. 스스로 준비가 다 됐다고 느낀 적은 한 번도 없었는데도였다. 지원 동기를 정리하던 순간부터 면접장에서 질문을 받던 순간까지, 그 생각과 실제 나 사이의 거리를 하나씩 확인하는 과정이었다.

지원 동기

프론트엔드 개발을 좋아하는 이유는 코드를 수정한 결과가 곧바로 화면과 사용자 경험으로 이어지기 때문이다. 사용자와 가장 가까운 접점에서 문제를 발견하고 고친 뒤 그 결과를 바로 확인하는 일, 그 피드백 루프를 반복하며 서비스를 다듬어가는 과정 자체가 프론트엔드를 선택한 동기였다.

이 회사에 지원한 이유는 서비스 자체에 있었다. 대학 생활을 하며 여러 번 써본 익숙한 플랫폼이었고, 사용자가 많으리라 막연히 짐작만 하다가 월간 활성 사용자 200만 명이라는 수치를 보고서야 규모를 구체적으로 체감했다. 그동안 여러 프로젝트에서 실제 사용자를 모으려 애썼지만, 개인이나 작은 팀 단위로는 상용 서비스 수준의 트래픽과 사용 패턴을 겪어볼 방법이 없었다. 이미 그만한 사용자가 자리 잡은 환경에서 실제 데이터를 보며 개발할 수 있다는 점이 큰 기회로 느껴졌다.

사용자가 늘어날수록 작은 변화 하나의 무게도 같이 커진다. 버튼 위치를 조금 옮기는 일, 성능 최적화나 웹 접근성처럼 눈에 잘 띄지 않는 작업 하나가 200만 명의 실제 경험으로 이어진다. 지원서에 "사용자 경험을 세밀하게 살피는 개발자가 되고 싶다"고 적은 것도 그래서였다. 코드가 의도대로 동작하는지 확인하는 데서 멈추지 않고, 사용자가 어디서 불편을 겪는지 데이터로 확인하며 고쳐나가는 일을 해보고 싶었다.

코딩 테스트

코딩 테스트를 앞두고는 걱정이 많았다. 다른 지원자에 비해 알고리즘 공부가 부족하다고 느꼈는데, 남은 기간에 그 격차를 줄이기는 어려워 보였기 때문이다. 다행히 실제 테스트에는 평소 풀던 수준의 문제가 나와 큰 어려움 없이 풀어나갔다.

정작 시간을 끈 건 한 문제의 초기 구현에서 생긴 사소한 오류였다. 코드를 고치고 바로 실행해보는 대신 눈으로 다시 읽으며 맞는지 판단하려 한 탓에, 충분히 예방할 수 있었던 실수를 오래 붙들고 있었다. 그래서 알고리즘 문제를 더 많이 푸는 것보다, 한 줄 고칠 때마다 곧바로 실행해서 의도한 대로 동작하는지 확인하는 습관을 의식적으로 연습해보려 한다.

면접

첫 면접이었던 만큼 긴장이 컸다. 손이 너무 떨려 두 손으로 꽉 잡고 있어야 할 정도였다. 다행히 면접관분들이 편안한 분위기를 만들어주셔서 긴장이 조금씩 풀렸고, 실제 프로젝트에서 고민했던 경험을 떠올려 답하기 시작하니 준비한 말을 외워서 전달할 때보다 훨씬 편하게 이야기할 수 있었다. 모든 문장이 논리적으로 완벽하지는 않았겠지만, 직접 겪은 시행착오를 솔직하게 전달했다는 점에서는 후회가 없었다.

인상 깊었던 부분은 질문의 방향이었다. 면접관분들의 질문은 문제를 정의하고 해결해가는 사고의 흐름을 확인하는 쪽으로 이어져, 답하는 동안 내가 어떤 근거로 판단했고 그 결과를 어떻게 검증했는지까지 스스로 설명해야 했다. 프론트엔드 직무 면접이었지만 내 경험에 따라 백엔드와 CS로 질문이 확장되기도 했다. 여러 기술 영역을 연결해 문제를 이해하려는 태도가 느껴졌고, 이런 곳에서라면 프론트엔드 안에 갇히지 않고 성장할 수 있겠다는 생각에 면접이 끝난 뒤에는 합격하고 싶다는 마음이 더 커졌다.

이력서에 적어둔 AI 활용 경험을 두고는 예상보다 훨씬 깊은 질문이 이어졌다. AI가 보편화되면서 이를 활용하는 사람이 늘었고, 최근 화제가 된 바이브 코딩 붐도 같은 흐름에서 나왔다고 생각한다. 하지만 그 뒤편에서 보안이나 사용자 관점을 고려한 설계는 여전히 개발자의 몫이고, 이 역량은 AI가 대신 키워주지 않는다. 그래서 이 지점에서 나만의 차별점을 키우고 AI에게 끌려가지 않는 개발자가 되고 싶다고 답했다. 완성된 답은 아니었지만 그동안 AI를 쓰며 정리해온 생각을 있는 그대로 전달할 수 있었고, 돌아온 뒤에도 AI를 개발 과정에서 어떻게 써야 할지 한참 더 생각하게 됐다.

어떤 개발자가 되고 싶은가

가장 오래 남은 질문은 어떤 개발자가 되고 싶냐는 것이었다. 지원서를 쓸 때는 "사용자 경험을 세밀하게 살피는 개발자"라는 말로 뭉뚱그렸었다. 막연히 동경해오던 현업 개발자들 앞에서 그 말이 구체적으로 무엇을 뜻하는지 답해보고 나서야, 개발자는 결국 문제를 해결하는 사람이라는 걸 알게 되었다. 코드는 그 문제를 해결하기 위한 도구일 뿐이고, 본질은 복잡한 상황에서 문제를 정의하고 가능한 선택지를 비교한 뒤 해결책을 만들어가는 과정에 있었다.

머릿속으로만 그려왔던 엔지니어의 모습이 눈앞에 앉아 있었다. 동경으로만 남겨두지 않으려면 구체적인 목표가 필요했다. 내가 내린 결정의 근거를 스스로 설명할 수 있는 개발자가 되는 것이 지금 세울 수 있는 가장 가까운 목표다. 왜 그렇게 했냐는 질문을 받았을 때 그때 무엇을 비교했고 무엇을 포기했는지까지 말할 수 있다면, 적어도 그 결정만큼은 온전히 내 것이라고 할 수 있다고 생각한다.

정리하며

이전에는 늘 완벽하게 준비한 뒤에야 새로운 환경에 들어가고 싶었다. 하지만 준비가 끝나기를 기다리는 일은 그만큼 새로운 경험을 늦추는 선택이기도 했다. 이제는 부족함을 있는 그대로 인정하고, 그 상태에서 겪는 시행착오로 배우려 한다. 여전히 두렵지만 모든 것을 알고 시작할 수는 없으니, 그 순간에 할 수 있는 최선을 다하며 다음 단계로 넘어가는 편이 낫다고 생각한다.

취업을 준비하며 자주 떠올린 생각은 나에 대한 메타인지가 여전히 추상적인 수준에 머물러 있다는 점이었다. 막연히 강점이라고 여겨온 부분도 왜 그것이 강점인지, 어떤 결과로 이어졌는지 설명하려고 하면 근거와 사례가 부족했다. 나를 제대로 설명하지 못한다는 건 내가 어떤 상황에서 강점을 발휘하는지 아직 모른다는 뜻이었다.

그래서 입사 전까지 남은 시간에는 나를 조금 더 깊이 들여다보려고 한다. 어떤 상황에서 가장 오래 몰입하는지, 우선순위를 정할 때 어떤 기준을 쓰는지, 팀 안에서 내가 가장 잘할 수 있는 일은 무엇인지 차분히 정리해볼 계획이다. 이런 질문에 답을 찾다 보면 새로운 환경에서 내가 어떤 방식으로 기여할 수 있는지도 조금 더 분명해질 것 같다.