면접을 봤습니다. 결과는 떨어졌지만, 제가 혼자 생각했던 것만으로는 미처 헤아리지 못한 부분이 너무 많아서 기억나는 대로 정리해두려고 합니다.

나름 기술 답변을 준비해 갔습니다. 그런데 돌아보니 “어떻게”에만 치중했고, “왜”에 더 많은 비중을 두었어야 했다 싶더라고요. 면접관들이 제가 작업한 구조 그 자체의 근거를 파고들었거든요.

큰 서버 하나로는 안 되나요

가장 오래 남은 질문은 이거였습니다. “그냥 큰 서버 한 대에 다 올리고 편하게 쓰면 안 돼요? 굳이 여러 노드로 나눈 결정적인 이유가 뭐예요?”

당황했습니다. 저는 여러 노드로 나뉜 캐시를 운영해왔지만, “이 구조여야만 했던 이유”를 그 자리에서 명료하게 답하지 못했거든요. 안정성 때문이라고 얼버무렸는데, 돌아와서 곱씹어보니 제 답에는 구멍이 있었습니다.

집에 와서 다시 정리해봤습니다.

먼저 용량. 데이터가 커서 한 서버에 안 들어가니 나눈다는 논리는 사실 반쪽짜리였습니다. 큰 서버를 사면 되니까요. 같은 자원을 두고 공정하게 비교하면, 용량은 노드를 나눌 결정적 이유가 되지 못합니다. 정말 용량이 이유가 되는 건 “어떤 큰 서버로도 도저히 담을 수 없을 때”뿐인데, 제가 다루던 데이터는 그 정도로 크지 않았거든요.

남는 건 처리량이었습니다. Redis는 명령을 처리하는 스레드가 사실상 하나입니다. 그래서 서버를 아무리 키워도 한 대가 초당 처리할 수 있는 명령의 양에는 천장이 있습니다. 더 많이 처리하려면 서버를 키우는 게 아니라, 여러 대로 쪼개서 각자 병렬로 처리하게 해야 하고요. “큰 서버 한 대”로는 이 천장을 넘지 못합니다. 이게 제가 그 자리에서 했어야 할 답이었습니다.

여기에 하나 더, 장애가 번지는 범위가 달랐습니다.

마스터 한 대에 레플리카 한 대를 붙인 구조라면, 그 마스터가 죽는 순간 데이터 전체가 영향을 받습니다. 모든 데이터가 그 한 대에 얹혀 있었으니까요. 레플리카가 대신 올라오긴 하지만, 전환되는 그 짧은 순간의 충격은 전체에 미칩니다.

반면 마스터를 세 대로 쪼개고 각각에 레플리카를 붙여두면, 한 대가 죽어도 영향받는 건 전체의 3분의 1뿐입니다. 나머지 3분의 2는 아무 일 없다는 듯 계속 돌아가고요. 제가 안정성이라고 뭉뚱그렸던 말의 진짜 이름은 이 ‘장애가 번지는 범위’였더라고요.

왜 세 대예요

또 하나 막혔던 질문. “서버가 왜 세 대예요? 그리고 네 대로 늘려야 한다면 뭘 근거로 늘리자고 하실 거예요?”

솔직히 앞부분은 몰랐습니다. 제가 정한 게 아니라 합류하기 전부터 그랬고, 관성적으로 받아들이고 있었거든요. 그 자리에서는 그럴듯한 이유를 지어내려다 오히려 더 어설퍼졌습니다.

나중에 설계 문서를 다시 보고 나서야 이해했습니다. 애초에 “정확히 세 대”라는 답은 존재하지 않았습니다. 서버 대수는 못 박아 두는 상수가 아니라, 사용률을 일정 수준으로 유지하도록 로드밸런서 뒤에서 조정하는 변수였거든요. 부하가 늘면 늘리고 줄면 줄이는.

그렇게 생각하니 뒷부분 질문의 답도 자연스럽게 나왔습니다. 늘려야 하는 근거는 감이 아니라 데이터여야 합니다. 사용률이 목표치를 계속 넘는 추세, 부하가 몰릴 때 시스템이 스스로 남기는 포화 신호, 예상 트래픽을 흉내 낸 부하 테스트 결과. 이런 걸 모아서 “지금 구성으로는 여기까지가 한계”라고 보여줄 수 있어야 하는 거였습니다.

모르는 걸 지어내려 했던 게 그날의 실수였습니다. 몰랐으면 “이 부분은 제가 정한 게 아니라 정확히는 모른다, 다만 지금 관점에선 이렇게 본다”고 했으면 될 일이었거든요.

‘차단’이라고 썼지만

마지막은 조금 부끄러운 이야기입니다.

저는 결제 연동 경험을 소개하면서 “데이터 위변조를 원천 차단했다”고 적었습니다. 그런데 제가 실제로 한 건, 결제사 응답 원문을 가공 없이 그대로 남기고 로그 포맷을 표준화한 것이었습니다.

면접관은 특별한 방어 기법을 기대하는 눈치였는데, 제 설명은 거기에 못 미쳤습니다. 당연했습니다. 제가 한 건 위변조를 “막는” 일이 아니라, 나중에 문제가 생겼을 때 원본과 대조해 “추적할 수 있게” 해둔 일이었거든요. 막는 것과 추적하는 것은 층위가 다른데, 저는 더 세 보이는 단어를 골라 썼던 겁니다.

‘차단’이라고 쓰면 강해 보입니다. 그런데 실제가 그만큼 강하지 않으면 그 단어는 오히려 기대를 올려두고 스스로를 궁지로 몹니다. 정확한 단어가 과장된 단어보다 낫다는 걸, 실망한 표정을 보고 나서야 배웠습니다.

그래서

갑자기 다른 이야기를 해보자면, 제가 대학교를 졸업하고 아르바이트하던 수학 학원에서 정직원 제안이 왔을 때 느꼈던 감정이 있었거든요. ‘이제 사회가 보기에 나는 영락없는 어른이구나.’ 수학 강사의 길과 개발자의 길을 고민하다 지금은 개발자로 일하고 있습니다.

이번 경험이 단순한 기술 회고가 아니라는 생각이 드는 건, 그때의 상황과 비슷해서입니다. 들어오는 질문들이 저에게 이렇게 말하고 있는 것 같았거든요. ‘이제 당신, 마냥 주니어가 아니야.’ 지금 회사에 들어오려 할 때 받았던 질문들과는 느낌이 확실히 달랐습니다. 물론 AI의 발전으로 “왜”가 더 중요한 시대가 온 것도 있겠고요.

어엿한 미들 레벨 개발자가 되려면 아직 노력해야 할 게 많은 것 같습니다.