9 min to read
면접 경험을 통해 마주한 도메인의 의미
도메인은 개발자에게 어떤 의미인지 조금 다르게 생각한 계기
들어가며
이 글에서는 먼저 ‘도메인’이라는 표현부터 정리하고 시작해 보려 합니다. 진로를 직무와 업계로 나누어 본다면, 이 글에서 말하는 도메인은 후자에 해당합니다. e커머스나 교육, 핀테크처럼 산업적 맥락을 구분하는 정도로 이해해 주시면 충분합니다.
얼마 전까지만 해도 저는 도메인이 개발자에게 미치는 영향이 비교적 제한적이라고 생각했습니다. 만드는 서비스의 성격에 따라 기술 선택이 달라질 수는 있겠지만, 그 이상은 아니라고 보았습니다. SEO가 중요하면 Next.js를 떠올리고, 모바일 앱 중심의 환경이라면 웹뷰를 고려하는 정도, 그리고 어떤 업계에서 일하고 있는지를 나타내는 정체성이 하나 더해지는 수준이라고 여겨왔습니다.
이런 생각이 달라지게 된 계기는 최근에 경험한 면접이었습니다. 질문을 듣고 답변을 이어가는 동안에도 대화가 어딘가 어긋나고 있다는 느낌은 있었지만, 당시에는 그 이유를 명확히 인지하지 못했습니다. 면접이 끝난 뒤에야 제가 질문을 전혀 다른 전제에서 이해하고 있었다는 사실을 깨닫게 되었고, 단순히 지식이 부족한 문제가 아니라 같은 문제를 서로 다른 관점에서 바라보고 있었다는 점이 더 큰 원인이었음을 알게 되었습니다.
이 경험을 통해 도메인은 단순히 ‘어떤 서비스를 만드는가’의 문제가 아니라, 문제를 해석하고 사고하는 방식 전반에 영향을 준다는 생각을 하게 되었습니다. 이 글은 그때의 경험을 출발점으로 삼아, 도메인이 왜 제가 생각했던 것보다 더 중요한 요소로 느껴지게 되었는지를 차분히 정리해 보려는 기록입니다.
면접
이전에 작성했던 면접 회고 글들(1편, 2편, 3편)에서도 이미 어느 정도 맥락을 풀어두었기 때문에, 여기서도 이 면접을 보게 된 회사와 그 이전의 상황을 간단히 정리하고 넘어가려 합니다. 이 회사가 어떤 곳이었는지, 그리고 제가 어떤 인식을 가지고 면접에 들어갔는지를 먼저 짚어보는 것이 이후의 이야기를 이해하는 데 도움이 될 것 같습니다.
회사의 배경정보
해당 회사는 여러 산업 분야의 효율화를 목적으로 ML 모델을 개발하고, 그 결과를 대시보드 형태로 시각화하여 제공하는 곳이었습니다. 여러 산업에 걸쳐 비교적 폭넓은 산업을 다루고 있다는 점이 회사 소개에서도 강조되어 있었고, 문제마다 필요한 도메인 지식을 함께 학습하며 풀어간다는 점이 인상적으로 보였습니다.
이런 설명을 접하면서 저는 이 회사가 특정 산업에 깊게 고정된 도메인을 갖고 있기보다는, 상황에 따라 유연하게 문제를 다루는 곳이라는 인상을 받았습니다. 학부 연구생 시절, 과제마다 새로운 배경지식을 빠르게 학습하며 접근했던 경험과도 어느 정도 닮아 있다고 느꼈고, 그래서인지 면접 전까지는 ‘사실상 도메인이 뚜렷하지 않은 회사’라고 생각했던 것 같습니다.
하지만 실제 면접에서 마주한 질문과 대화는, 그런 인식이 온전히 맞지는 않았다는 점을 자연스럽게 드러내고 있었습니다.
면접 이전의 일의 간단한 정리
전형 과정 전반에서 느낀 인상은, 지원자에 대한 관심이 비교적 분명한 회사라는 점이었습니다. 서류 검토부터 과제, 면접에 이르기까지 각 단계는 지원자와 회사 모두에게 일정한 비용이 드는 과정입니다. 서로 잘 맞지 않는 상태에서 전형을 길게 이어가는 것은 양쪽 모두에게 부담이 될 수밖에 없습니다.
이 회사는 그런 점을 고려해, 약 10분 내외의 짧은 사전 인터뷰 형태로 커피챗을 진행하고 있었습니다. 이 과정에서 회사는 자신들이 어떤 문제를 다루고 어떤 방식으로 일하는지를 먼저 설명했고, 지원자는 이를 바탕으로 회사와의 방향성이 맞는지를 비교적 빠르게 판단할 수 있었습니다. 동시에 지원자 입장에서는, 회사가 중요하게 여기는 관점을 미리 파악하고 이후 전형에서 이를 염두에 둘 수 있다는 장점도 있었습니다.
커피챗 이후에는 실무 역량을 확인하기 위한 과제 전형이 이어졌습니다. 상세한 명세가 포함되어 있었지만, 핵심만 정리하면 데이터를 시각화하여 대시보드 형태로 구현하는 과제였습니다. 표면적으로만 보면 비교적 익숙한 유형의 과제였고, 당시에는 이 과제가 이후 면접에서 도메인에 대한 인식 차이를 드러내는 계기가 될 것이라고는 크게 생각하지 못했던 것 같습니다.
문제의 그 ‘면접’
글의 제목과 URL에서도 도메인에 대한 생각의 전환을 강조했기 때문에, 여러 질문들 중에서 이번 글의 주제에 맞는 부분만 발췌해 다루어 보려 합니다.
이 대화에서 중요한 것은, 어떤 기술이 맞느냐가 아니라 우리가 같은 문제를 전혀 다른 전제에서 바라보고 있었다는 점이었습니다. 꽤나 대화가 길지만, 집중해서 읽어주셨으면 좋겠습니다.
아래 대화는 당시 면접에서 오간 내용을 기반으로, 기억에 의존해 요지를 정리한 것입니다. 실제 표현과는 일부 차이가 있을 수 있습니다.
(과제에 대한 기타 질문들이 전에 있었음)
면접관 : 굉장히 큰 데이터가 웹서버로 옮기게 된다면 어떤 영향이 있을지에 대해서도 말씀해 주실 수 있을까요?
나 : 굉장히 큰 대용량 데이터를 한번에 내리려고 시도하면 내려야 하는 파일의 크기가 늘어나므로, 초기 페인팅까지의 걸리는 시간이 늘어나게 될 것입니다. 그에 따라서 클라이언트가 의미 있는 첫 화면을 보기까지 시간이 걸릴 것이고, 그러한 부분은 UX의 저하로 직결될 수 있는 부분일 것 입니다. 그래서 그러한 큰 데이터들을 받아야 한다면 우선 모든 데이터들을 한번에 다 내리는 것이 아니고, 점진적으로 작은 데이터, 당장 보여줄 수 있는 데이터 부터 UI를 차곡차곡 내려서 보일 수 있는, ISR을 적극적으로 생각해 볼 수 있을 것 같습니다.
면접관 : 그래프의 데이터 같은 것을 서버에서 내려서 그리고 싶다라고 하셨는데, 그래프 데이터가 크다고 하면 그래프 노출 시간이 늦어지는 것이고, 그래프 데이터가 동적이라면 말씀하셨던 정적 페이지로의 전환도 어려워질 수 있는데, 그럴 때는 어떻게 구현을 하실 건가요?
나 : 정적 페이지와 동적 페이지로 크게 나눌 수 있지만 정적 페이지로 내린다고 하여서 따로 추가적인 API 호출을 할 수 없는것도 아니고, 아까 ISR에 대해서 간단히 언급하였는데, 점진적으로 필요한 가장 기초적인 데이터부터 내리고, 이 화면을 예시로 들자면, 제목이나 간단한 메뉴 레이아웃을 내리고, 그래프에 대해서는 플레이스홀더를 먼저 내려준 다음에, 로딩 중 등의 플레이스홀더가 나오는 시간 동안 API를 따로 호출하여 큰 데이터를 한번에 부르는 것이 아닌 따로따로 부르는 식으로 해서 점진적으로 화면이 채워지는 경험을 할 수 있으면 좋을 것 같습니다.
면접관 : 그래프에 대한 처리가 프론트에서 진행이 된다고 하면, 프론트 서버가 부하를 견디지 못할 수 있다고 생각합니다. 그런 부분에 대해서는 어떻게 해결할 수 있을까요?
나 : 그래프 처리 때문에 부하가 걸린다 하셨는데, 그러한 경우의 수 중에서 제가 가장 먼저 생각한것은 원 데이터가 상당히 방대한 것이고, 그 데이터 중에 일부를 추려내서 고객이 원하는 것만 보이게 하는 그러한 시나리오를 상정해 보겠습니다. 그러한 데이터라면 필요한 여러가지 데이터중에서 필요한 것만 골라서 오버페칭이 되지 않도록, graphQL 등의 방법을 통해서 데이터를 페칭해오는 식으로 사용하는 리소스를 줄이는 방법으로 부하를 줄일 수 있지 않을까 하고 생각을 합니다만은, 혹시 제가 이해한 것 외에 다른 상황을 가정하셨으면 그것도 알고 싶습니다.
이때까지 저는 “초기 페인팅 지연”과 “브라우저에서의 점진적 렌더링”에만 집중해서 답하고 있었습니다.
반면 면접관의 질문은, 이미 “대량 연산과 다수 트래픽이 들어오는 웹 서버”를 전제로 깔고 있었던 것 같습니다.
면접관 : 그래프에서 데이터 처리한다는 것은, 어떤 연산이 들어간 처리를 말씀드린 것이고요. 그래서 서버사이드 자체에서 어떤 프론트엔드 자바스크립트 코드가 연산을 하게 되었을 때, 1명만 이 화면을 보는것은 상관이 없지만, 여러 사용자, 클라이언트가 이 그래프를 보고, 이러한 그래프가 또 한개가 아닌 여러개가 되었을 때, 웹서버의 적은 리소스로 어떻게 될지에 대해서 어떻게 생각하시는지에 대해 궁금했던것이고, graphQL 같은 경우는 클라이언트 사이드로 사용을 많이 해야한다고 생각을 하는데, 그래서 아까는 서버 사이드에서 아직 뭔가 클라이언트 사이드로 어떻게 전환을 해야겠다라는 이야기를 못들어서 그 부분에 대해 중간에 공백이 있다는 생각이 들고요.
면접관 : 그래서 다시 질문을 드리자면, 그러면, graphQL등을 써서 이런 부하에 관한 것들을 해결할 수 있을 것으로 본다고 이해하면 될까요?
나 : 네. graphQL로 호출을 하기 위해서는 graphQL이라는 특수한 쿼리를 서버에서도 인식할 수 있어야 하기 때문에, 제가 이해하기로는 graphQL로 예를 들어서 100개가 넘는 방대한 데이터가 있는데 내가 그중에서 5개만 원한다 해서 서버에 ‘나 A,B,E,F,G 이거 주세요’ 하면 서버에서 그 데이터를 추려서 보내는 것으로 알고 있기 때문에, graphQL은 단순히 서버사이드/클라이언트 사이드에서 돌아간다라고 말하기는 저는 좀 어려울 것 같다는 생각이 듭니다. 여쭤보신 부분이 정확하게 어떤 부분인지 다시 한번 설명받을 수 있을까요?
면접관 : 제가 아는 범위의 서버사이드 라는것은 지금 실제로 말씀하신 백엔드 서버가 있고, 거기다가 이제 그래프의 어떤 get 요청을 하는 것으로 말씀을 드린거긴 했거든요. 그래서 말씀해 주신 서버 사이드 라는것이 웹 서버의 서버사이드 얘기를 해주시는것인지, 백엔드의 서버사이드를 이야기 해주시는건지 약간 싱크가 안맞았던것 같고, 다시 정리를 해서 말씀을 드렸을 때, graphQL을 사용해서 서버쪽으로 서버 사이드/ 웹 서버의 서버 사이드 처리가 된다고 말씀을 해주시는게 맞을까요?
나 : DB나 외부 데이터를 가져오는 것은 일반적으로 API 서버에서 중간 과정을 거쳐서 하기 때문에 그러한 부하는 웹서버의 백엔드, 흔히 말하는 API 서버에 넘어가게 될 것이라고 생각합니다.
당시의 저는 ‘오버페칭을 줄이는 도구’라는 의미에서 GraphQL을 언급했지만, 면접관이 기대하던 답은 ‘연산을 서버로 옮겨 캐싱 등을 통해 웹 서버 부하를 조정하는 구조 설계’에 더 가까웠던 것 같습니다.
(이하 생략. 지원자 개인에 대해 묻는 다른 주제의 질문)
지금에 와서 보니, 저는 이 문제를 “브라우저에서 얼마나 효율적으로 데이터를 그릴 것인가”의 문제로 보고 있었고, 면접관은 “대량 연산과 다수 사용자 상황에서 웹 서버의 역할을 어떻게 설계할 것인가”의 문제로 보고 있었던 셈이었습니다.
당시 과제에서 사용한 원시 데이터는, 숫자를 그대로 시각화하는 데에 큰 무리가 없는 공공 의료 데이터였습니다. 그래서 저는 필요한 데이터만 적절히 받아오고, 그 이후의 연산이나 가공은 브라우저에서 처리해도 충분하지 않을까 하는 인식을 가지고 있었습니다. 동시에, 면접 내내 논의가 ‘브라우저에서 동작하는 프론트엔드’가 아니라, 별도의 BFF나 웹 서버를 전제로 흘러가고 있다는 점이 계속해서 마음에 걸렸습니다.
면접이 끝난 뒤 이 대화를 다시 돌아보면서, 왜 이렇게 서로의 설명이 맞물리지 않았는지를 천천히 정리해 보게 되었습니다. 그 과정에서 깨달은 점은, 저와 면접관이 서로 다른 전제를 기준으로 문제를 바라보고 있었다는 사실이었고, 그 전제의 차이를 만들어낸 원인 중 하나가 제 도메인에 대한 이해 부족이었다는 점이었습니다. 이 깨달음은 단순한 아쉬움을 넘어, 제가 도메인이라는 개념을 다시 생각해 보게 만드는 계기가 되었습니다.
회고하며 - 해당 회사의 ‘도메인’
이 회사는 다양한 산업 전반을 다루고 있었지만, 그렇다고 해서 도메인이 없는 회사는 아니었습니다. 다시 생각해 보니, 이 회사의 도메인은 ‘AI 모델의 결과를 시각화하여 전달하는 것’에 훨씬 가까웠다. 이 관점으로 면접 과정을 돌아보니, 당시 오갔던 질문들과 대화의 방향이 그제서야 조금씩 정리되기 시작했습니다.
ML 모델의 계산 결과는 단순히 숫자를 그대로 그려내는 수준에 머무르지 않는 경우가 많고, 실제 서비스 환경에서는 대량의 데이터 처리나 비교적 복잡한 연산까지 함께 고려하게 됩니다. 그런 맥락에서 보면, 사전 과제에서 사용한 데이터가 비교적 단순했음에도 불구하고 면접관이 지속적으로 BFF나 웹 서버 단의 역할을 전제로 질문을 이어갔던 이유가 아니었나 하고 생각하게 되었습니다.
당시의 저는 과제의 형태와 당장의 구현 난이도를 기준으로 문제를 바라보고 있었지만, 회사의 입장에서는 장기적으로 다루게 될 문제의 성격과 서비스 환경을 기준으로 사고하고 있었던 셈입니다. 이 인식의 차이가 면접 내내 이어졌던 미묘한 어긋남의 원인이었고, 결과적으로 제가 놓치고 있던 도메인 맥락이 무엇이었는지를 뒤늦게 드러내 준 계기가 되었습니다.
마무리하며 - 현 시점에서 내가 생각하는 ‘도메인’이란?
이 경험을 겪고 나서, 내가 생각하는 도메인의 의미도 조금 달라졌습니다.
처음 개발을 배울 때, 그리고 비교적 경험이 적었을 때 떠올렸던 도메인 지식은 주로 눈에 보이는 형태에 가까웠습니다. 이 도메인에서는 어떤 용어를 쓰는지, 버튼이나 화면 구성은 보통 어떻게 되는지, 어떤 그래프가 자주 등장하는지 같은 것들 말이죠. 이런 정보들이 도메인 지식의 전부라고 생각했던 시기가 있었고, 이 면접을 보기 전에도 비슷한 생각을 하고 있었습니다.
하지만 이번 면접 경험을 돌이켜보면서 느낀 것은, 그런 요소들은 도메인의 아주 표면적인 부분에 불과하다는 점이었습니다. 실제로 더 큰 영향을 미치는 것은 문서에 잘 드러나지 않는 전제들인 것 같습니다. 이 도메인에서는 어느 정도 데이터 규모를 당연하게 상정하는지, 특정 질문이 나왔을 때 브라우저 단의 처리를 이야기하는 상황인지, 아니면 서버 단의 역할을 전제로 하는지, 혹은 어떤 연산은 ‘어디서 처리하는 것이 자연스럽다’는 합의가 이미 존재하는지 같은 감각들이죠. ‘기술자에게 도메인의 의미’ 가 이런 것이 아닐까 하고 생각이 듭니다.
이런 전제들은 명시적으로 설명되지 않는 경우가 많고, 몇 주 혹은 몇 달간 그 문제를 직접 다뤄보면서 서서히 체득되는 경우가 대부분이지 않을까 생각합니다. 그래서 돌이켜보면, 면접이라는 자리가 단순히 기술적인 해결책을 맞히는 자리라기보다는, 이런 도메인 전제를 얼마나 공유하고 있는지를 확인하는 과정에 더 가까웠던 것 같다는 생각이 이제서야 드는 것 같습니다.
이번 경험을 통해 알게 된 것은, 도메인 지식이란 특정한 해답의 목록이 아니라, 문제를 어디서부터 어떻게 바라보는지를 결정짓는 사고의 틀에 가깝다는 점입니다. 그리고 그 틀을 제대로 이해하지 못한 상태에서는, 기술적으로 그럴듯한 답변을 하고 있더라도 대화의 방향이 어긋날 수 있다는 사실이었습니다. 아마도 제가 이번 면접에서 느꼈던 불일치는, 바로 그 지점에서 비롯된 것이었을 것입니다. 그리고 경력직에게 바라는 것들 중 하나도, 어쩌면 이런 도메인 전제를 스스로 인식하고 설명할 수 있는 능력이 아닐까 합니다.
긴 글이지만 끝까지 읽어주셔서 감사합니다.
