요약:
이 토론은 '좋은 시스템 설계'가 무엇인지를 중심으로, 실제 개발 현장과 시스템 디자인 면접에서의 이상과 현실 사이의 괴리, 그리고 실무에서의 실용성과 복잡함이 어떻게 충돌하는지를 솔직하고 입체적으로 다룹니다.
복잡한 시스템이 좋은 설계의 증거가 아니라, 오히려 나쁜 의사결정의 결과물일 수 있음을 다양한 경험담과 조언을 통해 풀어냅니다.
핵심 논점으로는 '간단함의 미학', '면접에서 요구되는 설명 방식', 'ORM과 SQL 활용', '마이크로서비스와 데이터베이스 공유', '면접과 실제 업무의 차이' 등이 등장합니다.

1. 복잡함이 곧 훌륭한 시스템 디자인일까?

시작은 한 엔지니어의 고백에서 비롯됩니다.

"저는 종종 혼자라는 기분이 듭니다. 엔지니어들은 복잡한 시스템을 보며 '와, 정말 체계적인 시스템 디자인이구나!'라고 생각하죠. 사실 복잡한 시스템은 제대로 된 좋은 설계가 부재함을 반영하는 경우가 많습니다."

면접에서는 이런 현실인식이 오히려 감점 요인이 될 수 있다고 말합니다.

"면접 때는 이걸 잠시 잊는 게 중요합니다. 반대로, 제가 예전에 시스템 디자인 면접에서 이런 식으로 솔직하게 답변해 실책을 저질렀죠."

예시로 나온 가상의 스타트업 앱 면접 질문과 지원자의 대화는 현실적으로 다음과 같이 진행됩니다.

면접관: "여기서 backpressure(백프레셔)를 어떻게 처리하나요?"
지원자: "이 정도 QPS(초당 쿼리수)에선 크게 신경 쓸 가치가 없습니다."
면접관: "크론잡 대신 큐를 쓰지 않는 이유가 뭔가요?"
지원자: "이 앱 특성 상 굳이 필요하지 않지만, 트레이드오프를 말씀드릴 수 있습니다."
면접관: "SQL이랑 NoSQL 중 뭘 쓸 건가요?"
지원자: "크게 상관 없습니다. 팀이 가장 익숙한 쪽을 쓰면 되지 않을까요?"

이러한 답변들은 실제 면접 현장에선 고득점 답이 아닙니다.

"면접관들이 원하는 건 화이트보드를 꽉 채우는 복잡한 아키텍처 다이어그램(박스와 화살표)입니다. 마치 쿠버네티스 위에 또 쿠버네티스 올린 것 같은 그림이죠." 😅

2. 시스템 디자인 면접, 그리고 '생색내기'와 진짜 신호

면접관 입장에서의 의견도 많았습니다.

"수백 번의 시스템 디자인 면접을 진행해본 경험에 비춰보면, (특히 중견 이상의 지원자라면) 답변에서 자신의 논리와 고려포인트를 충분히 설명해야 합니다. 왜 그런 판단을 내렸는지, 어떤 상황에서는 선택이 어떻게 달라지는지까지 말이죠."

"지원자가 backpressure가 불필요하다고 말한다면, 언제 필요하게 될지, 그때 어떻게 적용할 것인지 구체적으로 답해줘야 합니다. 좋은 지원자는 추가 질문 없이도 이 과정 전체를 풀어서 설명해줍니다."

"특히 senior 이상 지원자는, 자신이 어느 부분에서 '깊이 들어갈지', 어떤 trade-off가 있는지 등을 명확히 구분해서 심층적으로 이야기하는 주도력이 필요합니다."

3. 진짜 실무와 면접의 괴리

이상적으로는 '간단함'이 미덕이지만, 현실은 복잡함을 요구하거나 과시하는 문화가 있다며 다양한 경험담이 나옵니다.

"대다수의 실제 문제는 캐싱 하나로 해결되지 않습니다. 시스템 디자인 면접에서 처음부터 복잡도를 쓸데없이 높이는 건 오히려 마이너스입니다. 문제 규모에 따라 자연스럽게 계층별로 필요한 부분만 깊이 있게 설명하는 게 중요하죠."

"실제론 대부분 사례에서 Postgres 하나로 충분한데, 스타트업에서도 '카프카나 분산 큐'를 무조건 써야 한다고 답해야 합격점이 나오는 웃픈 현실이 있죠."

"팀 규모가 커질수록 오히려 오버엔지니어링이 많아집니다. 신규 아키텍처를 이력서에 채우고 싶은 욕구도 많이 작동해요."

이러한 면접문화 자체가 회사 문화의 신호라는 점도 지적합니다.

"문제에 실제로 맞지 않는 스케일의 '훙성한' 답변을 요구하는 곳은, 사실 그런 복잡도가 실제 업무에도 존재하더군요. 과연 그런 조직에서 일하고 싶은지 생각해볼 필요도 있습니다."

4. 시스템 설계의 '간단함'과 기술적 Trade-off

복잡함이 항상 나쁜 설계고, 간단함이 정답만은 아니라는 반론도 나옵니다.

"좋은 설계는 복잡함을 숨기는 둘러대기(trade-off)가 아니라, 문제의 본질과 요구사항을 정확히 파악한 후 정확한 수준의 복잡도와 구조를 정하는 능력입니다."

"특정 상황에서는 복잡함이 필요한 경우(특정 concurrency나 스케일, 수평 확장 등)도 반드시 있으니, 문제 자체의 맥락을 설명하고 왜 간단함이 충분한지 or 추가적인 구조가 필요한지 논리적으로 풀어야 하죠."

실제로, 대부분의 데이터베이스, ORM, 애플리케이션 구조 관련 논쟁이 이런 트레이드오프와 연결됩니다.

"실무에선 성능, 확장, 유지보수, 데이터 이슈 등 다양한 상황에서 SQL JOIN, ORM 사용, 마이크로서비스 분리, 공유 데이터베이스 여부를 각기 조율해야 하죠."

"하나의 데이터베이스에 여러 서비스가 직접 접근하는 순간, 테이블 구조 변경·권한 문제·업데이트 충돌 등 복잡성이 기하급수적으로 늘어나기도 합니다."

5. 인터뷰 팁과 실무적 조언들

면접에서 좋은 인상을 주는 답변의 예시도 등장합니다.

"현재 트래픽(QPS)에선 backpressure가 별로 이슈되지 않지만, 만약 트래픽이 y로 늘어난다면 B같은 구조(예: 큐/써큘러 브레이커 등)를 추가할 필요가 있습니다. 성장 가능성이 있거나 이벤트성 급격한 트래픽이 예상된다면 이에 맞게 미리 설계 포인트를 만들어놓겠습니다."

"SQL과 NoSQL 중 선택도 단순히 익숙함만이 아니라, 인덱스 구조, 조인 사용, 스키마 마이그레이션, 데이터 정합성/이력 관리 등 다양한 포인트의 trade-off까지 포함해 설명해야 합니다."

간단함의 미학(Keep It Simple, Stupid)가 반복적으로 강조됩니다.

"가장 간단한 방법부터 시작하세요. 예를 들어 초기엔 싱글 서버+Postgres로 충분히 버틸 수 있지만, 스케일이 커지면 어떻게 변화시킬 수 있을지도 '계획만' 미리 언급해두는 게 좋습니다."

"모든 트레이드오프(단순 vertical scaling, 캐싱, 분산 구조 전환 시점 등)들을 '언제쯤 필요한지', '어떻게 감지할 것인지'를 구체적으로 언급하면 신뢰도를 높일 수 있습니다." 👍

6. 데이터베이스, ORM, 그리고 시스템 구조에 대한 토론

SQL vs NoSQL, ORM 사용법, 데이터베이스 설계에 대해서도 깊이 있는 논의가 이어집니다.

• ORM 활용에 대한 견해가 다름:

  "ORM은 기본적인 CRUD(추가, 조회, 수정, 삭제)에는 매우 유용하고, 복잡한 쿼리나 성능 최적화 구간에서는 원시 SQL 사용이 좋다. 단, ORM 구조를 강박적으로 고집하면 N+1 문제 등 성능 이슈가 자주 발생하니 주의."

• 데이터베이스 다중 접근 문제:

  "여러 서비스가 하나의 DB/테이블에 동시에 쓰는 것은 향후 데이터 스키마 관리, 권한, 확장 등 여러 문제를 초래하니 최대한 한 서비스/한 팀이 직접 write를 담당하고, 나머지는 API나 이벤트로 분리하는 게 맞다."

• 스키마 디자인에 대한 이견:

  "가능하다면 명확한 스키마와 정규화를 권장하며, 너무 유연하게(jsonB, key-value 구조 등)를 남발한다면 오히려 복잡성이 앱 단에서 폭발할 수 있다."

7. 엔지니어 문화와 면접 시스템, 그리고 조직 현실

많은 IT 기업에서의 인터뷰 시스템 자체가 '복잡함'을 미덕이고, 이게 실제 업무 문화와 연결되어 있다는 냉소적 반응도 적지 않습니다.

"링크드인(한줄짜리 Postgres Mono리스를 만들었다고 쓰기)이 아니라 마치 수십 개 마이크로서비스, 별별 fancy 스택을 쌓았다고 이력서에 적는 것이 더 환영받는 현실이죠."

"결국 개발자 채용 프로세스가 실무에 필요한 능력(문제 정의, 트레이드오프 판단, 간결한 설계보존성 등)보다는, 면접 '정답게임'에 치중하는 것도 현실입니다."

8. 조직의 규모, 변화, 그리고 오버엔지니어링

조직의 규모가 커질수록, 필요 없는 복잡함(overengineering)이 당연시되고 심지어 이를 유지해야 하는 현상이 있다고 지적합니다.

"돈을 많이 버는 곳일수록, 오버엔지니어링이 더 쉽게 허용됩니다. 대신 그 엄청난 복잡도를 떠안고 유지하면서 가치를 만들어내는 곳입니다."

9. 성공하는 시스템 디자인의 본질

마지막으로, 진짜 좋은 시스템 디자인은 '눈에 잘 띄지 않는다', '너무 단순해서 평가받지 못한다'는 결론에 여러 엔지니어들이 공감합니다. 🌱

"실제로 훌륭한 시스템 설계는 자화자찬이나 과시적인 복잡함이 아니라, 지극히 단순하고 누구나 바로 이해할 수 있을 만큼 논리적이고 명확해야 한다는 겁니다."

"나중에 우리 코드베이스를 돌아보며, 특별히 신경 쓰지 않는데도 문제없이 오래 잘 굴러가고 있는 부분이 바로 좋은 시스템 디자인이 자리잡은 구간입니다."

마치며

이 토론을 통해 "최소한의 구조+최선의 설명+논리적인 trade-off 인식"이 진짜 좋은 시스템 설계임을 다시 한번 확인할 수 있습니다.
복잡함을 과시하기보다는, 문제의 본질을 파악하고 '왜?'의 근거와 함께 논리적으로 풀어주며, 실제 변화와 확장성엔 어떻게 대처해야 하는지 유연한 태도를 갖는 것이 중요함을 많은 경험자들이 한 목소리로 강조합니다.

"복잡한 시스템은 종종 '좋은' 설계의 증거가 아니라, 오히려 '나쁜' 결정이 누적된 결과다."

이 말을 기억하며, 간단함의 미덕, 타당한 논리, 변화에 대응할 수 있는 설계를 염두에 두는 것이 진짜 엔지니어의 길일지 모릅니다. 🚀