토스 플레이스 프론트엔드 어시스턴트 면접 회고

intro

토스에서 어시스턴트를 했던 형이 갑자기 공고를 보내주면서 한 번 지원해보라고 했다.
사실 서류를 넣을 때만 해도 면접까지 갈 거라고는 크게 기대하지 않았다.

하지만 토스플레이스에서 면접을 진행하면서 생각보다 얻은 게 많았다.

단순히 기술적인 질문에 대한 답변뿐만 아니라,
개발할 때 어떤 식으로 사고해야 하는지,

그리고 내 판단을 어떻게 말로 전달해야 하는지를 많이 돌아보게 됐다.

면접 준비 과정

면접 준비를 하면서 이력서에 적힌 문장 하나하나에
“왜 이 경험을 했는지”, “왜 이런 선택을 했는지” 나름대로 이유를 붙여보려고 했다.

 

문제는 인턴 시절 경험 중 일부가 잘 기억나지 않았다는 점이었다.
시간이 지나면서 기억도 많이 휘발됐고,
회사 보안 문제로 코드에도 접근할 수 없는 상황이었다.

 

그래서 기억이 나지 않는 부분은 AI에게
“그럴듯한 이유를 만들어달라”고 요청해보기도 했다.

준비과정에서도 나름대로의 얻은점이 있었다.

차라리 기억이 나지 않는 경험이라면, 이력서에서 빼는게 좋다.

면접을 준비하면서 가장 크게 느낀 점은
내가 제대로 설명할 수 없는 경험은, 내 경험이 아니라는 것이었다.

기억이 나지 않아 설명을 못 할 것 같은 경험들이
준비 과정에서 계속해서 스트레스로 다가왔다.

 

예를 들어, 대피로 팀에서 디자인 시스템을 개발했던 경험이 있다.
당시에는 시간 제약이 심했고, 빠르게 결과를 내야 해서
AI를 활용해 구현 위주로 진행했다.

그 결과, 기술 선택에 대한 나의 판단이나
어려웠던 지점이 명확하게 남아 있지 않았다.

솔직히 말하면 이 경험은
“내 경험”이라기보다는 “AI가 대신 만들어준 결과물”에 가까웠다.

디자인 시스템과 관련된 질문을 쭉 뽑아 연습해보았지만
말이 되는 답변이 하나도 나오지 않았다.

그래서 결국 이런 결론에 도달했다.

이 질문이 나오면 버리자.
차라리 이 경험을 설명하려 애쓰지 말자.

나름의 판단 기준을 세울 수 있게 되었다.

이전까지 면접에서
“왜 전역 상태 관리로 Zustand를 사용했나요?”라는 질문을 받으면
항상 비슷한 답변을 반복했다.

 

보일러플레이트가 적고, 러닝 커브가 낮아서
팀원들이 빠르게 효율을 낼 수 있기 때문입니다.

 

이번 면접을 준비하면서
여러 상태 관리 라이브러리들의 개념과 차이를 다시 정리해보았고,
그 과정에서 나만의 기준을 조금이나마 세울 수 있었다.

• Context API
  • 전역 상태 관리라기보다는 전역 상태 공유에 가깝다
  • 일부 값만 구독하기 어려워, 값 하나가 바뀌어도 하위 트리가 모두 리렌더링될 수 있다
• Recoil
  • 하나의 atom(SoT)을 두고, 여러 파생 값을 UI에 반영해야 할 때 유용하다
• Zustand
  • 도메인별로 store를 나누어, 서로 의존 없이 빠르게 전역 상태를 사용할 수 있다
• Redux
  • 하나의 store에 모든 상태를 모아 관리한다
  • reducer 패턴을 통해 액션 단위로 상태 변경 흐름이 명확하다

 

이 기준들은 사실
코드를 작성할 때 자연스럽게 나와야 하는 것들이라고 생각한다.
이번 준비를 통해 그동안 얼마나 생각 없이 코딩을 해왔는지도 함께 느끼게 됐다.

면접 도중

면접 내용은 자세히 말할 수 없기에,
느꼈던 점 위주로 정리해보려 한다.

면접 중 가장 기억에 남았던 말은 다음이었다.

“코드에는 정답이 없어요.
옳고 그름을 정하려 하지 말고,
코드를 작성할 때의 사고 흐름을 보고 싶습니다.”

 

라이브 코딩을 하면서
무작정 코드를 먼저 작성하고,
GPT에게 “어떻게 바꾸면 좋을까”를 물은 뒤 수정했다.

 

지금 돌아보면,
이 선택이 이번 면접을 어렵게 만든 가장 큰 이유였던 것 같다.

AI에게 코드 수정을 맡기지 않았다면
내 사고 과정을 더 온전히 면접관에게 전달할 수 있었을 것이다.

너무 잘해야겠다는 강박 때문에
오히려 내가 어떤 판단을 했는지가 흐려졌다.

이번 경험을 통해 느낀 점은 단순하다.

 

평소 하던 방식대로 하는 것이 가장 중요하다.
그래야 내 판단을 숨기지 않고, 그대로 보여줄 수 있다.

회고

앞으로 개발을 하면서
스스로에게 계속 질문하는 습관을 가져야겠다고 생각했다.

• 이건 왜 이렇게 했지?
• 다른 방법에는 뭐가 있을까?
• 둘 중에 더 나은 판단은 무엇일까?

이런 질문을 반복하다 보면
내가 중요하게 생각하는 기준들이 코드에 자연스럽게 드러날 것이고,
그 과정이 결국 더 좋은 개발자,
그리고 좋은 환경에서 일할 수 있는 기회로 이어지지 않을까 생각한다.

Outro

이번 면접은
‘잘 짜는 코드’보다
‘왜 그렇게 판단했는지를 말하는 능력’이 중요하다는 걸 깨닫게 해준 경험이었다.