이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 공공 교통 데이터를 처리하는 파이프라인을 만들었습니다. 하루치 데이터가 약 100만 행이었는데, 처음에는 pandas로 한 번에 불러와서 처리했더니 메모리 오류가 났습니다.
chunksize로 1만 행씩 나눠서 읽고 처리하는 방식으로 바꿨더니 안정적으로 돌아갔습니다. 그 뒤로 한 달치 데이터를 처리해야 할 때 단순히 30배를 반복했는데 시간이 너무 오래 걸렸습니다. 날짜별로 병렬 처리하도록 바꿨더니 4코어 기준으로 처리 시간이 약 60% 줄었습니다.
대규모라고 할 수준은 아니었지만, 데이터 크기가 커지면 메모리와 처리 방식을 같이 설계해야 한다는 걸 그때 처음 실감했습니다. 단순히 코드를 짜는 게 아니라 어떤 순서로 얼마씩 처리할지가 설계의 핵심이라는 감각이 생겼습니다.
팀 프로젝트로 만든 서비스를 발표 기간에 공개했더니 30명이 동시에 접속하면서 응답이 느려졌습니다. 단일 EC2에 모든 처리를 몰아넣은 구조였는데, 동시 요청이 많아지자 병목이 생겼습니다.
가장 느린 부분이 이미지 파일 처리였습니다. 요청마다 이미지를 새로 불러와서 처리했는데, 같은 이미지를 여러 번 처리하는 비효율이 있었습니다. 처리 결과를 캐시로 저장해두고 이미 처리된 건 바로 반환하도록 바꿨더니 응답 속도가 눈에 띄게 빨라졌습니다.
대규모 시스템은 아니었지만, 무엇이 반복되는지를 찾는 것이 성능 개선의 출발이라는 걸 배웠습니다. 처음부터 완벽한 구조를 만들기보다는 병목을 측정하고 가장 큰 것부터 개선하는 것이 실용적이라고 생각합니다.
인턴 때 기존 시스템에서 같은 데이터가 여러 테이블에 중복 저장되는 구조를 봤습니다. 업데이트할 때 한 곳만 바꾸면 다른 곳과 달라지는 문제가 반복됐습니다. 담당자가 "오래된 구조라 어쩔 수 없다"고 했는데, 저는 어떻게 이 문제가 생겼는지가 궁금했습니다.
코드를 따라가 보니 초기 설계에서 조회 속도를 높이려고 중복 저장을 의도적으로 넣었는데, 나중에 쓰기 로직이 분산되면서 동기화가 깨진 것이었습니다. 저는 중복 저장 없이 뷰로 조회하는 방식을 제안했는데, 기존 코드 수정 범위가 너무 넓어서 채택되지 않았습니다.
그 경험에서 설계 결정이 나중에 얼마나 큰 유지보수 비용으로 돌아오는지를 봤습니다. 짧게 보면 중복 저장이 빠르지만, 길게 보면 정합성 유지가 더 비쌌습니다. 초기 설계가 왜 중요한지를 코드가 아니라 현장에서 처음 실감했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.