풀스택 개발자 면접 준비 예시

저는 루미너스랩에서 결제 실패가 바로 구독 종료로 이어지는 흐름을 개선했습니다. 일시적인 결제사 오류와 카드 유효기간 만료처럼 재시도로 해결되지 않는 경우를 나누고, 일시 오류에는 일정 간격으로 최대 세 번 다시 요청하도록 구성했습니다. 같은 결제가 중복 처리되지 않도록 거래 식별값을 기준으로 결과를 확인하고, 재시도 중인 구독은 종료 대신 보류 상태로 관리했습니다. 변경 전후 각각 8주 동안 전체 갱신 시도 중 최종 실패 건의 비율을 비교해 8.4%에서 2.1%로 낮아진 것을 확인했습니다. 실패를 다시 처리할 기회를 주되 중복 결제를 막는 설계가 중요하다는 점을 배웠습니다.

저는 루미너스랩 월간 리포트 API의 지연을 느린 쿼리 로그와 요청별 실행 계획으로 확인했습니다. 같은 리포트 조회에서 연관 데이터를 행마다 다시 읽는 N+1 구간 34곳을 찾아 묶음 조회로 바꾸고, 고객사와 조회 기간처럼 필터에 반복 사용되는 조건을 중심으로 인덱스 6개를 추가했습니다. 변경 후 동일한 고객사 데이터와 조회 조건으로 응답 시간을 비교했고, 캐시를 적용하기 전에도 6.8초에서 2.2초로 줄었습니다. 이후 반복 조회 결과를 캐시해 최종 응답 시간을 1.4초로 낮추고 DB CPU 피크도 82%에서 45%로 줄였습니다. 쿼리와 인덱스를 먼저 정리해야 캐시에 대한 의존을 줄일 수 있다는 점을 배웠습니다.

저는 루미너스랩에서 고객사 12곳의 도입을 지원하며 반복되는 데이터 이관과 계정 설정을 나눠 자동화했습니다. 고객사별 원본 데이터를 정해진 항목으로 읽어 옮기는 스크립트를 만들고, 건수와 필수값을 대조해 결과를 확인했습니다. 형식이 다르거나 누락된 예외 데이터는 별도 목록으로 뽑아 고객사별로 수정 후 다시 검증했습니다. 계정과 기본 설정은 관리자 화면으로 옮겨 담당자가 직접 처리하게 했습니다. 3시간은 계정 초기 설정에 걸리던 작업 시간이고, 개선 후에는 같은 범위가 20분으로 줄었습니다. 반복 가능한 절차와 예외 처리를 분리해야 온보딩 속도와 검증 품질을 함께 지킬 수 있었습니다.

저는 글벗에듀에서 학습 기록 서비스의 동시 접속 점검을 하며 조회 지연이 나타나는 구간을 확인했습니다. 실제 사용 흐름을 기준으로 진도 목록과 퀴즈 결과 조회를 반복하는 부하 조건을 구성해 1,200명 수준의 동시 요청을 재현했습니다. 요청별 응답 시간과 데이터베이스의 느린 조회를 함께 살펴보니 학습 기록을 가져오는 일부 쿼리에서 지연이 반복됐습니다. 그중 응답에 영향을 주는 지연 쿼리 8건을 골라 조회 조건과 데이터 접근 방식을 개선했습니다. 이후 배포 후 결함 11건도 대응했습니다. 사용자가 체감하는 지연을 먼저 재현하고 원인이 확인된 구간부터 고치는 방식이 효과적이었습니다.

저는 글벗에듀에서 학습 진도와 퀴즈 기록 기능을 만들 때 화면 동작을 데이터 흐름으로 나눠 설계했습니다. 학습자가 문제를 풀고 제출하면 화면에서 입력값을 검증하고, API에는 학습자와 콘텐츠 식별값, 응답 결과를 보내도록 구성했습니다. 서버에서는 기록을 저장한 뒤 진도 화면과 결과 화면이 필요한 형태로 조회하도록 API와 화면을 함께 구현했습니다. 이 과정에서 제출 직후 화면에 표시되는 상태와 저장된 결과가 어긋나지 않도록 성공·실패 응답을 점검하고 화면의 갱신 흐름을 다듬었습니다. 총 18종의 API와 21개 화면을 개발하고 오픈 후 3개월 동안 기록 46만 건을 처리했습니다. 화면 요구를 데이터 계약으로 구체화하는 것이 중요하다고 배웠습니다.

저는 고객사별 리포트가 느리다면 먼저 실제 조회 조건과 응답 시간을 나눠 보고, PostgreSQL 실행 계획과 느린 쿼리부터 확인하겠습니다. 루미너스랩에서도 리포트의 N+1 조회 34곳을 정리하고 인덱스 6개를 추가한 뒤, 반복 조회 부하가 남아 캐시를 적용했습니다. 쿼리 개선으로 응답 시간은 6.8초에서 2.2초로 줄었고, 캐시 적용 후 1.4초가 됐습니다. 캐시는 최신성 요구와 데이터 갱신 빈도를 확인해 적용 범위와 만료 기준을 정하고, 결과 일관성도 함께 점검하겠습니다. 지표를 단계별로 비교해야 각 개선의 효과와 부작용을 구분할 수 있다고 생각합니다.

저는 루미너스랩에서 결제사 연동 규격 변경에 대응하며 구독 갱신의 성공과 실패 흐름을 함께 점검했습니다. 재시도 대상이 되는 일시 오류, 재시도하지 않는 영구 오류, 재시도 도중 같은 거래가 중복 처리되는 경우를 나눠 테스트했습니다. 규격 변경 때는 요청과 응답 필드뿐 아니라 구독 상태가 정상 갱신, 보류, 최종 실패로 각각 바뀌는지도 회귀 확인했습니다. 이런 점검을 두 차례 반영했고, 재시도 도입 후 갱신 실패 비율은 8.4%에서 2.1%로 낮아졌습니다. 결제 기능은 성공 응답만 확인해서는 부족하고 실패 뒤의 상태 전이까지 검증해야 한다는 점을 배웠습니다.

저는 루미너스랩 고객사 12곳의 도입 과정에서 설정 단계별 소요 시간과 반복 문의를 살펴 초기 설정 기능의 범위를 정했습니다. 여러 고객사에서 같은 계정 생성과 기본 설정이 반복되고 처리 시간이 길어, 우선 예외가 적고 담당자가 직접 확인할 수 있는 항목을 관리자 화면으로 옮겼습니다. 고객사별로 다른 데이터 이관은 스크립트로 처리하되 예외값은 별도 검증 목록으로 남겼습니다. 같은 초기 설정 범위를 기준으로 개선 전 건당 3시간과 개선 후 20분을 비교했고, 반복 문의 15건은 도움말로 전환했습니다. 빈도가 높고 절차가 안정적인 작업부터 기능화하는 것이 운영 부담을 줄이는 방법이었습니다.

저는 본사와 가맹점으로 이어지는 멀티테넌트 권한 구조를 직접 설계한 경험은 없습니다. 다만 루미너스랩에서 관리자용 구독 현황 화면과 조회 API를 만들며 운영 사용자가 구독 상태를 확인하는 흐름을 다뤘고, 이 기능으로 주 6시간의 수기 확인 업무를 줄였습니다. 모아스퀘어에 합류하면 첫 달에 기존 권한 요청과 고객사 문의를 유형별로 정리하고, 3개월 안에 본사·지역 관리자·가맹점주별 업무와 데이터 접근 범위를 표로 구조화하겠습니다. 이후 6개월 동안 권한 변경 시나리오와 기존 기능의 영향을 함께 점검하며 설계 작업에 기여하겠습니다.

저는 Terraform으로 인프라를 관리한 경험은 없습니다. 루미너스랩과 개인 프로젝트에서는 AWS EC2와 S3, Docker를 사용해 서비스를 배포하고 운영 환경에서 애플리케이션 동작을 확인했습니다. 글벗에듀에서는 배포 후 결함 11건을 대응하며 기능 변경이 서비스에 미치는 영향을 점검했습니다. 합류 후 첫 달에는 현재 인프라 구성과 배포 절차, 환경별 설정을 익히고, 3개월 안에 반복되는 변경 작업과 수동 점검 지점을 문서화하겠습니다. 그다음 팀의 기준에 맞춰 Terraform 변경안을 작은 범위에서 검토하고 배포·복구 절차까지 익혀 인프라 관리 역량을 보완하겠습니다.

저는 글벗에듀에서 상담팀의 엑셀 문의 이력을 웹 검색 도구로 바꿀 때 기존 업무 흐름을 먼저 살폈습니다. 상담팀은 익숙한 열 구성은 유지하길 원했지만 문의를 찾는 데 건당 4분이 걸려 검색 기능이 필요했습니다. 그래서 기존 파일의 주요 항목은 유지하고, 고객 정보와 문의 내용을 조건으로 찾는 화면을 만들었습니다. 9명의 사용자를 교육한 뒤 실제 조회 과정을 확인해 월 1회 의견을 모았고, 우선순위를 정해 개선 요청 7건을 반영했습니다. 조회 시간은 건당 30초로 줄었습니다. 사용자의 익숙한 흐름을 존중하면서 반복되는 불편을 바꾸는 조율이 중요하다는 점을 배웠습니다.

저는 동네 도서 교환 서비스를 운영하며 원본 이미지를 처리할 때 업로드 평균 시간이 5.2초까지 늘어나는 문제를 확인했습니다. 소규모 서버 한 대로 운영하고 있었기 때문에 서버를 늘리기 전에 이미지 크기와 전송량을 줄이는 방안을 선택했습니다. 업로드 단계에서 이미지를 필요한 크기로 리사이즈하도록 적용하고, 서비스 화면에서 확인할 수 있는 선명도를 유지하도록 결과를 점검했습니다. 적용 뒤 평균 처리 시간은 1.3초로 줄었고, 서버 한 대를 유지하면서 이용자 210명과 누적 신청 1,340건을 관리했습니다. 성능 개선은 자원을 늘리기 전에 병목과 실제 사용 품질을 함께 살펴야 한다고 배웠습니다.