전문용어보다 문제·판단·검증이 먼저 보이는 반복 독서용 면접 노트
웹 문서에서 청록색 점선 키워드에 마우스를 올리면 짧은 뜻이 먼저 보이고, 누르면(모바일은 탭) 쉬운 설명·전문가 설명·기억할 것이 그 자리에서 열린다. 면접관에게는 전문용어보다 무슨 문제였는지 → 왜 그 방법을 골랐는지 → 무엇으로 확인했는지를 먼저 전달한다.여러 곳에서 이름과 표기 방식이 다르게 들어오는 데이터를 ‘결국 같은 대상인지’ 판단해 연결하고, 잘못 연결되거나 빠진 데이터를 다시 찾아 고칠 수 있게 만드는 일을 해 왔다.
이어질 질문까지 이어 간다.상황 1문장 - 선택 2문장 - 검증 1문장 - 한계 1문장으로 줄인다.Unknown, Needs confirmation은 답변을 꾸미라는 표기가 아니다. 확인 전에는 말하지 않는다.첫 문장을 짧게 말한 뒤 경험과 지원 이유를 한 줄로 연결한다.
저는 여러 곳에서 다른 이름으로 들어오는 데이터를 ‘결국 같은 대상인지’ 판단해 연결해 온 데이터 엔지니어입니다.
지난 5년간 오픈소스 제품과 버전, 취약점, 12종 Linux 배포판의 보안 정보를 맞춰 왔습니다. 잘못 연결되거나 빠진 데이터는 이름을 식별하는 규칙부터 저장 구조와 재처리 방법까지 고쳤습니다. 리멤버에서는 이 경험으로 명함·프로필·회사 데이터를 오래 믿을 수 있게 만들고 싶습니다.
가장 가까운 사례는 컴포넌트 식별자 재설계와 원천 레지스트리 전수 대조입니다. 같은 제품이 이름과 대소문자 차이로 나뉘거나 다른 제품이 하나로 합쳐지는 문제를 키 정책과 원천 대조로 풀었기 때문입니다.
저의 경력은 ‘잘못된 결과의 원인을 재현하고, 다시 발생하지 않게 구조를 고치는 일’로 이어져 있습니다.
석사 과정에서는 IoT 펌웨어를 실제로 실행해 취약점을 찾았고, 2021년부터는 오픈소스 제품과 버전, 취약점 데이터를 수집·연결·검증했습니다. 같은 데이터가 문자열 비교 규칙이나 식별자 차이로 나뉘고, 원본이 없어 오류를 다시 확인하지 못하는 일도 겪었습니다. 그래서 원본 보존부터 실행 환경, MySQL, 저장소, 백업과 모니터링까지 책임 범위를 넓혔습니다. 리멤버에서도 원본부터 최종 이용자가 보는 결과까지 한 흐름으로 확인하겠습니다.
연구에서는 가설만 세우지 않고 실제 실행 결과와 원문을 다시 대조하는 습관을 익혔습니다. 이 방식이 데이터 누락과 불일치의 원인을 증거로 좁히는 정합성 분석으로 이어졌습니다.
저는 현재 회사에서 수집부터 저장, 실행 환경, 배포와 모니터링까지 넓게 경험했습니다.
그중 가장 오래 붙잡고 성과를 낸 축은 식별·매핑·데이터 품질이었습니다. 이제 식별·매핑·마스터 데이터·정합성을 직무의 중심으로 더 깊게 다루는 팀에서 여러 원천의 품질·재처리·관측 기준까지 설계하는 엔지니어로 성장하고 싶습니다.
현 회사를 부정적으로 평가해서 옮기려는 것은 아닙니다. 다음 단계에서는 사람·회사처럼 기준 정보가 계속 변하는 식별 문제를 더 깊게 다루고 싶고, 리멤버 직무가 그 문제와 직접 맞닿아 있기 때문입니다.
리멤버는 제가 해 온 ‘여러 표기를 같은 대상으로 연결하는 일’이 사람과 회사 데이터에서 직접 중요한 곳입니다.
주변 추천으로 명함과 프로필을 올린 뒤 스카우트 제안을 받고 공고를 봤습니다. 공고의 정교한 매핑, , 데이터 정합성은 같은 회사가 여러 이름으로 들어와도 한 회사로 알아보고, 잘못 연결하지 않게 관리하는 일입니다. 이 품질이 프로필과 기회의 신뢰를 떠받치기 때문에 직접 지원했습니다.
사람·기업 데이터의 의미와 개인정보 기준은 새로 배워야 합니다. 다만 원본을 남기고, 같은 대상을 판단한 근거와 변경 이력을 보존하며, 잘못된 결정을 검증하고 되돌리는 운영 원리는 그대로 적용할 수 있습니다.
운영 경험, 학습 중인 영역, 경험이 없는 영역을 분명히 나눈다.
저는 오류가 보이면 쿼리 하나를 고치거나 서버부터 늘리기보다, 데이터가 어디서 갈라졌는지를 먼저 찾습니다.
오픈소스 제품 데이터에서는 문자열 비교 규칙, 테이블 구조, 검색 인덱스와 식별자 규칙이 함께 엇갈려 있는 원인을 풀었습니다. 또 원천 누락을 조사할 때는 외부의 기준 목록과 우리 데이터를 전수 대조했습니다. 리멤버에서도 원본부터 최종 사용 데이터까지, 어느 경계에서 의미가 달라졌는지 먼저 확인하겠습니다.
조사와 대안 작성, 구현은 제가 맡았습니다. 다만 중심 구조는 혼자 확정하지 않았고, 영향 범위가 컸기 때문에 팀장과 CTO 리뷰를 거쳐 결정했습니다.
저는 ··를 프로덕션에서 운영한 경험이 없습니다.
대신 Python····MySQL로 수십억 행 와 80개가 넘는 크롤러의 스케줄링·/, 재처리, 동시성, 를 다뤘습니다. 현재 강점으로 먼저 기여하고, 분산 처리는 팀의 실제 데이터량과 지연 요구를 기준으로 실행 모델부터 학습하겠습니다.
제가 운영한 는 약 1시간 단위로 파일을 전달하는 배치형 동기화입니다. 같은 실시간 스트리밍을 운영한 경험과는 처리 방식과 지연 기준이 다릅니다.
저는 같은 의 프로덕션 운영 경험을 주장하지 않겠습니다.
과제에서는 연도별 전체 스냅샷 조인과 전수 검증에 를 썼고, 실무에서는 MySQL 실행계획과 대규모 데이터 배치 운영 경험이 중심입니다. 전환은 소비 쿼리, 동시 사용자, , 비용을 확인한 뒤 판단하겠습니다.
분석용 대량 조회가 운영 을 방해하거나, 집계 응답시간과 동시 사용자 요구를 운영 에서 맞추기 어려워질 때 계층을 검토합니다. 별도 저장과 동기화 비용보다 운영 보호와 조회 성능의 이익이 커지는 시점이기 때문입니다.
제가 프로덕션에서 운영한 AWS 범위는 EC2입니다.
MySQL과 애플리케이션을 EC2에서 직접 운영했고, RDS··EFS 운영 경험은 없습니다. 제출 자료의 관련 태그는 최종 검수에서 놓친 잘못된 표기이며, 질문받으면 바로 정정하겠습니다.
온프레미스 환경에서 SeaweedFS를 설계하고 데이터를 단계적으로 이관한 경험은 있습니다. 객체 저장소의 용량·복제·이관 문제를 다뤘지만, 이를 AWS 운영 경험이라고 표현하지는 않겠습니다.
제 확인된 경력은 보안 메타데이터 중심이라 리멤버의 개인정보 운영 경험이 있다고 말하지 않겠습니다.
입사하면 먼저 수집 목적, 접근 주체, 보존·삭제 규칙과 감사 경계를 확인하겠습니다. 파이프라인에는 최소 권한, 민감 필드 분리·마스킹, 재처리 산출물의 동일 정책, 접근 로그와 만료 절차를 넣고 실제 사내 기준에 맞추겠습니다.
보안 데이터를 다룬 경험만으로 개인정보 운영을 잘 안다고 말할 수는 없습니다. 수집 목적과 보존 기간, 접근 권한, 법적 기준이 다르기 때문에 리멤버의 정책과 담당자 판단을 먼저 배워야 합니다.
구조를 먼저 설명하고, 수치는 질문을 받았을 때 근거와 함께 꺼낸다.
2022년과 2023년 회사 목록을 비교해 새로 생긴 회사, 바뀐 회사, 그대로인 회사를 구분하는 파이프라인을 만들었습니다.
먼저 입력 파일을 원본()으로 남기고, 중간 단계()에서 사업자번호·주소·근로자수·날짜를 같은 형식으로 정리했습니다. 이후 사업자번호로 신규·변경·변경 없음을 나누고, 최종 목록·변경 이력·최근 원본에서 사라진 항목·8개 검증을 한 번에 커밋했습니다. 파일을 한 작업만 쓰게 하기 위해 실행은 직렬로 제한했습니다.
태스크 사이에는 큰 데이터 자체를 넘기지 않았습니다. 에는 연도, 파일 경로, 적용 정책, 처리 건수처럼 다음 태스크가 작업을 찾는 데 필요한 작은 정보만 전달했습니다.
저는 이 과제를 행 단위 보다 연도별 전체 읽기, 집합 조인, 컬럼 비교와 전수 검증 문제로 봤습니다.
의 읽기, 컬럼 지향 실행, IS DISTINCT FROM, 단일 파일 재현성이 맞았습니다. 약 3만 행에서 성능을 과장하려는 선택은 아니었습니다. 여러 writer와 온라인 serving이 필요하면 중앙 나 로 옮기겠습니다.
파일 하나에 여러 작업이 동시에 쓰는 구조에는 적합하지 않습니다. 현재 설계가 한 번에 한 회차와 한 writer를 전제로 하기 때문에 동시 쓰기가 필요해지면 중앙 나 다른 저장 구조로 바꿔야 합니다.
저는 2022년 30,513행을 초기 적재했고, 2023년 소스 23,261행을 처리했습니다.
공통 키 21,087개 중 4,000개 사업장이 바뀌었고 17,087개는 no-op이었습니다. 신규는 2,174개, 2023 소스에 없던 기존 키는 9,426개여서 최종 마스터는 32,687행, 활성 23,261행입니다. 컬럼 단위 UPDATE 이력은 5,196행이며 2023 와 활성 마스터의 불일치는 0건입니다.
변경된 사업장은 4,000개지만 한 사업장에서 주소와 근로자수처럼 여러 속성이 함께 바뀔 수 있습니다. 변경 이력을 컬럼별로 한 건씩 남겼기 때문에 전체 이력은 5,196건입니다.
입력에서 확인한 사실, 과제 정책, 운영에서 필요한 합의를 구분한다.
과제 원문이 Insert·Update 기준으로 사업자등록번호를 지정했기 때문에 업무 키로 썼습니다.
공백과 하이픈만 제거하고 ASCII 숫자 10자리가 아니면 제외했습니다. 불일치 9개는 두 연도에 같은 키로 반복됐고 외부 정답이 없어 WARN과 원문을 남긴 채 반영했습니다. 모르는 값을 보정해 다른 사업장과 합치는 위험을 피했습니다.
현재 파일에서는 중복 키가 0건이었습니다. 중복이 생기면 지금 자료에는 갱신시각이 없어 행 순서를 임시 기준으로 사용할 수밖에 없지만, 운영에서는 원천 우선순위와 이벤트 시각, 버전처럼 설명 가능한 선택 기준이 필요합니다.
과제 문구의 ‘2023년 최신 정보로 갱신’을 literal rule로 적용했습니다.
주소 결측 2,249개 중 2,093개는 2022 값이 있어 추출 누락일 가능성도 보였습니다. 그래서 기본은 overwrite로 두고 preserve existing on null을 명시적 옵션으로 제공했으며 두 정책 모두 별도 기대값으로 8개 검증을 통과시켰습니다. 운영에서는 컬럼별 completeness 계약과 사업 소유자의 의미 확인이 먼저입니다.
과제에서는 옵션별 결과를 재현하는 것이 답이지만, 운영 정책은 데이터 소유자와 함께 정해야 합니다. 이 미수집인지 삭제 요청인지 알 수 없는 상태에서 제가 하나의 보편 규칙을 정하면 실제 의미를 훼손할 수 있기 때문입니다.
파일 부재만으로 폐업, 추출 누락, 공개 범위 변경을 구분할 수 없고 원문도 Delete를 요구하지 않았습니다.
그래서 다섯 업무 속성은 유지하고 is_active=false, absent_since_year=2023만 남겼습니다. strict 해석을 위해 부재를 무시하는 옵션도 뒀습니다. 제가 확인한 사실은 ‘최근 소스에 없었다’까지입니다.
soft delete는 관리 컬럼 추가가 허용된 범위 안에서 선택했지만, 데이터 해석이 들어간 확장인 것은 맞습니다. ignore 옵션은 필수 다섯 업무 속성의 Insert·Update 결과를 그대로 재현하고, active·absent 상태만 운영 추적을 위해 별도로 관리했습니다.
기준은 간단합니다.
정리된 원천 데이터를 사업자번호로 기존 목록과 연결했습니다. 기존 키가 없으면 신규, 다섯 속성 중 하나라도 다르면 변경, 모두 같으면 변경 없음(no-op)으로 분류했습니다. 의 IS DISTINCT FROM을 써서 값에서 로, 또는 에서 값으로 바뀐 것도 놓치지 않았습니다. 변경이 없으면 최종 데이터와 변경 이력을 쓰지 않았습니다.
비교할 컬럼이 다섯 개이고 어느 값이 바뀌었는지 컬럼별 이력을 남겨야 해서 직접 비교를 선택했습니다. Python과 사이에서 ·문자열 직렬화 규칙이 달라져 hash 결과가 어긋날 위험도 피할 수 있기 때문입니다.
리멤버의 사람·회사 데이터는 사업자번호 하나로 정답을 낼 수 없다고 보겠습니다.
먼저 정확히 일치하는 규칙으로 연결하고, 남은 데이터는 출처·시간·보조 식별자 근거를 점수화하겠습니다. 근거가 충분하면 자동 연결, 애매하면 사람 검토, 부족하면 보류로 나눕니다. 표본을 검사해 잘못 합친 비율과 같은 대상을 나눈 비율을 확인하고, 언제든 잘못된 연결을 풀고 이후 데이터를 다시 만들 수 있게 결정 근거와 버전을 남기겠습니다.
문자열 유사도만으로는 동명이인과 이직, 법인 변경을 구분하기 어렵습니다. 이름 점수는 후보를 줄이는 데 쓰고, 최종 연결은 시간과 출처, 연락처, 회사 식별 근거를 함께 확인해야 합니다.
현재 구현이 보장한 범위와 운영에서 보완할 범위를 나눠 답한다.
에서 2022년 초기 적재와 2023년 갱신을 같은 작업 흐름으로 만들었습니다.
연도는 스케줄러가 전달한 기준 시간에서 가져오고, 에 두 작업이 동시에 쓰지 않게 한 번에 하나의 실행만 허용했습니다. 다만 이 제한은 연도 순서까지 자동으로 보장하지는 않아 이전 연도로 돌아가는 갱신은 별도 규칙으로 막았습니다. 파일이 없는 실행은 실패와 구분해 SKIPPED로 남겼고, 운영에서는 파일 도착 기한과 재처리 승인 절차가 추가로 필요합니다.
SKIP만 보면 정상 미실행과 파일 미도착을 구분하기 어렵습니다. 태스크 실행 상태와 파일 도착 약속은 서로 다른 신호이기 때문에 운영에서는 도착 시각을 따로 감시하고 알림을 보내야 합니다.
는 해당 연도 스냅샷을 각각 한 에서 교체합니다.
같은 2023 스냅샷을 다시 적용하면 업무 속성과 마스터 행 수는 유지되고, Insert 0, 속성 Update 0, 변경 이력 증가 0입니다. 다만 등장한 키의 상태 컬럼 UPDATE와 교체, 실행 기록은 다시 씁니다. 2023 뒤 2022를 넣는 역행은 merge 전에 막습니다.
완전히 아무것도 쓰지 않는 것은 아닙니다. 확인한 키의 상태 UPDATE와 ·실행 기록은 남고, 0인 것은 신규 Insert, 업무 속성 Update, 변경 이력 증가입니다.
최종 업무 데이터는 ‘한 번만 반영된 것처럼’ 보이게 만들었지만, 실행 기록까지 완전히 한 번만 기록된다고 말할 수는 없습니다.
최종 목록, 변경 이력, 원본에서 사라진 항목과 8개 검증은 하나의 으로 묶었습니다. 그러나 성공 상태와 건수는 그 커밋 뒤에 따로 기록됩니다. 두 단계 사이에서 중단되면 데이터는 반영됐지만 상태는 실행 중으로 남을 수 있어, 실행 메타데이터까지 라고 과장하지 않겠습니다.
업무 데이터와 실행 기록이 같은 에 있으면 한 으로 묶겠습니다. 저장소가 분리돼 있으면 나 를 남기고, 오래된 RUNNING 상태를 실제 업무 데이터와 다시 대조해 복구하겠습니다.
키 결측·형식 오류, 근로자수 파싱 오류, 중복 탈락은 ERROR로 제외했습니다.
has_valid_key는 더 넓은 is_valid와 분리했습니다. 속성 ERROR나 중복 탈락 행은 merge에서 제외하지만 업무 키가 유효하면 현재 소스에서 본 키로 계산해 잘못된 부재·비활성화를 막습니다. ·날짜 이상은 외부 정답 없이 고치지 않고 WARN, 주소 결측은 INFO로 남겼습니다. 실제 파일의 ERROR는 0건이고 2023은 WARN 29, INFO 2,249였습니다. 1% ERROR 허용률은 과제 기본값일 뿐 운영 가 아니며 rule별 임계치가 필요합니다.
검증 항목은 키 유일성, 행 수 증분, 분류 합계, 소스 키 포함 여부, 정책값 일치, 보호, 활성 상태, 미래 last_seen_year 존재 여부의 여덟 가지입니다.
세 가지를 먼저 바로잡겠습니다.
README는 절단 의심 주소 4건을 했다고 적었지만 실제로는 수동 프로파일링 후보이며 runtime rule이 없습니다. 대표 실행 로그는 동일 core를 쓴 경로이고, clean extraction에서는 2022·2023 run도 같은 결과로 확인했습니다. 제출 문서는 107 tests, 현재 같은 최종 소스 재검증은 108 tests이므로 기록 시점을 나눠 말하겠습니다.
코드와 테스트 결과는 확인했지만 문서의 각 문장을 실제 실행 산출물과 다시 대조하지 못했습니다. 문서도 검증 대상이라는 출고 기준이 빠져 있었기 때문에 생긴 검수 공백입니다.
현재 설계의 한계를 먼저 인정하고 전환 조건과 검증 순서를 말한다.
먼저 한 연도의 데이터를 모두 Python 메모리에 올리는 부분부터 바꾸겠습니다.
현재는 작은 과제에는 추적하기 쉽지만, 수백만 행에서는 메모리가 먼저 부족해집니다. 이나 로 데이터를 메모리에 전부 올리지 않고 청크 단위로 처리하고, 스냅샷별 목록과 파티션을 두며, 실행 계획·디스크 임시 사용·메모리를 측정하겠습니다. 동시에 여러 작업이 쓰거나 소비자가 많아지면 단일 파일을 공유하지 않고 중앙 나 로 옮기겠습니다.
단일 노드에서 메모리와 , 처리시간 한계를 먼저 측정하겠습니다. 데이터를 나누고 전달하고 장애를 복구하는 분산 처리 비용보다 처리시간 단축과 확장 이익이 커질 때 를 선택하겠습니다.
현재는 안전하다고 주장하지 않겠습니다.
max_active_runs=1, 직렬 태스크, 짧은 연결이라는 단일 회차 가정에 기대고 있고 일부 ·검증 조회가 run_id 대신 source_year 범위를 씁니다. 병렬화를 허용하려면 모든 접근을 run_id 또는 immutable 으로 격리하고 (run_id, key) 유일성, , 를 두겠습니다.
락만으로는 충분하지 않습니다. 락은 writer 충돌은 막지만 읽기 격리, 재시도 중복, 결과 공개 시점의 원자성까지 해결하지 못하므로 회차별 경계가 필요합니다.
이관은 ‘무엇을 언제 기준으로 옮기는지’를 고정하는 것부터 시작합니다.
먼저 원본과 새 저장소의 키, 행 수, 핵심 속성을 대조합니다. 실제 전환 전에 미리 실행하고 일부 대상만 먼저 옮겨 이후 사용처의 결과를 비교합니다. 어느 수준의 차이면 멈추거나 되돌릴지를 미리 합의하고, 전환 뒤에도 원본과 결과를 다시 대조합니다. 실제 IDC 이관에서 확인된 범위는 전후 테이블 행 수 대조입니다.
실제 IDC 이관에서 명시적인 을 실행했는지는 현재 기록으로 확인되지 않습니다. 제가 실제로 확인한 것은 전후 테이블 행 수 대조이며, 절차는 운영 이관에서 필요하다고 보는 설계 원칙입니다.
··ERROR 비율·행 수 drift·no-op spike·중복·소스 대비 불일치를 함께 보겠습니다.
키 유일성이나 정책값 불일치처럼 마스터를 오염시키는 조건은 배포를 막고, 이나 의미 미확정 이상은 WARN과 판정 큐로 분리합니다. 임계치는 과거 baseline, 영향도, 오탐 비용을 보고 owner와 정하겠습니다.
실시간 이상 감지에 항상 가 필요한 것은 아닙니다. 몇 초 안에 알아야 하는지와 원천이 변경 이벤트를 제공하는지를 먼저 확인하고, 허용 지연이 분 단위라면 나 주기적인 metric 수집이 더 단순할 수 있습니다.
현재 과제는 헤더 이름과 순서가 다르면 하고 를 보존합니다.
운영에서는 , additive·required 컬럼 정책, 버전별 parser와 test를 둡니다. breaking change는 와 로 검증하고, 새 파서의 결과를 이전 기간에 재계산해 차이를 확인한 뒤 전환하겠습니다.
컬럼 추가를 무조건 막지는 않습니다. 데이터 계약에 선택 컬럼 추가를 허용한다고 명시하되, 알 수 없는 변경이 기존 컬럼의 의미나 소비자 결과를 조용히 바꾸지 않도록 검사합니다.
결과 수치의 단위와 본인·협업자의 책임 범위를 함께 말한다.
중앙 의 가 비정상적으로 높아져, 느린 쿼리와 실행계획을 따라가며 원인을 좁혔습니다.
두 테이블의 문자열 비교 규칙()이 달라 연결 조회에서 인덱스를 쓰지 못하고 있었습니다. 동시에 제품 식별자가 충돌하거나 대소문자 차이로 같은 제품이 나뉘는 문제도 발견했습니다. 그래서 비교 규칙, 테이블 구조, 인덱스, 식별자 정책을 함께 재설계했고, 실행계획의 예상 스캔 행이 약 130만에서 약 6,000으로 줄었습니다. 이는 응답시간이나 감소율을 잰 수치는 아닙니다.
수치로 확인한 것은 실행계획상 예상 스캔 행이 약 130만에서 약 6,000으로 줄었다는 점입니다. 실제 응답시간과 감소율은 기록으로 확인되지 않았고, 식별자 충돌과 누락 구조를 수정한 사실은 확인됐습니다.
80개가 넘는 수집기가 각자 연결과 재시도를 관리해 lock·connection 오류가 하루 3~4건씩 났습니다.
저는 모든 수집기가 같은 운영 규칙을 쓰도록 하나로 쓰기 요청을 모았습니다. 에 크기 제한을 두고 작업자 수와 연결 수를 통제했으며, 이 차면 429 + Retry-After로 호출자가 나중에 다시 요청하게 했습니다. 같은 요청이 중복 반영되지 않도록 키와 를 쓰게 했고, 각 담당자는 자기 수집기를 이관했습니다. 저는 공통 구조와 운영 규칙을 맡았고, 적용 후 4개월간 해당 오류는 0건이었습니다.
이 가득 찼을 때 요청을 계속 받아 내부 메모리에 쌓으면 장애가 더 커집니다. 그래서 429와 Retry-After로 현재 처리할 수 없다는 사실을 드러내고, 호출자가 정해진 시점에 다시 요청하도록 했습니다.
운영 의 인덱스를 많이 지우는 작업이라, ‘아마 안 쓸 것’이 아니라 지워도 되는 근거를 먼저 만들었습니다.
수집 는 전체 수집기의 쿼리를 조사했고, 배포 는 분석 엔진이 사용하는 95개 쿼리의 실행계획을 모두 확인했습니다. 인덱스 311개 중 해당 쿼리에서 쓰이지 않는 224개를 찾고 삭제 순서와 필요한 수정을 리뷰했습니다. 그 후 수집 는 9.6TB에서 4TB, 배포 는 2.6TB에서 1.2TB로 줄었고, 고객사 설치용 생성 시간은 12시간에서 6시간으로 줄었습니다.
외부에서 다시 받아야만 재처리할 수 있던 흐름을 선보존 구조로 바꿨습니다. 적용된 소스는 재처리 외부 요청이 0건이 됐지만, 2일→5분은 설계 산정 예시라서 실측 성과로 말하지 않겠습니다.
innodb_flush_method 기본값 변화로 좁혔다. 하드웨어별 기준을 나누고 단계적으로 적용했다.검증된 사례만 쓰고, 확인되지 않은 갈등·실패·피드백은 답변으로 만들지 않는다.
사내 범용 PC로 옮긴 뒤 수집 집중 시간의 쓰기·와 발열이 겹쳐 월 10~20건의 운영 이슈가 났습니다.
저는 syslog, 스케줄, 네트워크를 같은 시간축으로 보고 먼저 수집 시간을 분산해 월 5건 미만으로 낮췄습니다. IDC 서버가 준비된 뒤 수집·배포·운영 를 분리하고 , 백업, 모니터링을 다시 구성했습니다. 2024년 전환 뒤 확인된 이슈는 1~2건이며, AWS는 EC2에서 self-managed MySQL을 운영한 범위입니다.
당시에는 바로 옮길 장비가 준비되지 않았습니다. 그래서 수집 시간을 먼저 분산해 서비스 영향을 낮추고, 장비가 준비된 뒤 검증 순서에 따라 역할을 분리했습니다.
저는 공통 실행 환경과 크롤러별 도메인 로직의 소유권을 나눴습니다.
· 자원, 접근 경계, 저장소와 모니터링은 제가 맡고 각 담당자는 자기 수집기 로직을 맡았습니다. 공통 변경의 범위·적용 순서·근거를 문서로 남기고 팀장·CTO 리뷰를 거쳤습니다. 각 담당자가 자기 크롤러를 이관했고, 저는 공통 구조와 운영 규칙을 맡았습니다.
현재 정리된 자료에는 상대의 우려와 제 양보, 최종 결정까지 정확히 확인되는 의견 충돌 사례가 없습니다. 기억이 불분명한 이야기를 만드는 대신 면접 전 실제 사례 한 건을 다시 확인하겠습니다.
30일까지 핵심 개체·키·매핑, 원천에서 소비자까지의 흐름, 담당자와 개인정보 경계를 익히겠습니다.
60일까지 한 원천이나 데이터 품질 문제를 맡아 기준값, 재처리, 중단선을 설명할 수 있게 하겠습니다. 팀 우선순위와 권한이 허용하면 90일까지 작은 개선 하나를 배포까지 이어가고, 결과·한계·재처리·되돌림 방법을 문서로 남기겠습니다. 대형 재설계보다 팀이 믿고 작은 범위를 맡길 수 있는 판단 방식을 먼저 증명하겠습니다.
첫 과제는 고객 영향, 문제의 반복 빈도, 결과를 측정할 수 있는지, 잘못됐을 때 되돌릴 수 있는지를 기준으로 비교하겠습니다. 초기에 작은 범위를 고르는 이유는 팀의 운영 기준을 배우면서도 결과를 안전하게 확인할 수 있기 때문입니다.
이 문항은 아직 면접용 답변이 아니다. 과제 README에 있어야 할 설계 판단을 다른 문서로 옮겼다가 독립 재리뷰에서 발견했고, 이후 요구사항-산출물 매핑, production-path 테스트, 깨끗한 압축 해제 를 출고 조건으로 둔 사실은 확인됐다. 그러나 이것이 직장에서도 반복되는 개인 약점인지는 확인되지 않았다. 본인이 실제 반복 패턴이라고 확인하기 전에는 사용하지 않는다.
실제 반복 상황, 발생한 비용, 당시 본인 책임, 이후 행동 변화가 모두 기억과 기록에 맞는지 직접 확인한다. ‘완벽주의’ 같은 포장 문장으로 바꾸지 않는다.
직장 실패가 아니라 최근 제출 과제의 사전 발견 로 답해도 되는지 먼저 묻겠습니다.
독립 재리뷰에서 README 필수 항목 누락, production에서 쓰지 않는 경로를 검증한 테스트, 재패키징 뒤 실행 권한 위험을 발견했습니다. 제출물 소유자의 검수 실패로 받아들이고 README 복구, production-path 테스트, 파일 모드·인코딩 검사, 한글 경로 clean extraction 를 추가했습니다. 제출 전 두 회차 성공과 source-master 불일치 0을 확인했습니다.
독립 재리뷰에는 AI 도구도 사용했습니다. 다만 도구가 지적한 내용을 요구사항과 실제 실행 결과로 확인하고 최종 제출을 결정한 책임은 제출자인 저에게 있습니다.
현재 자료만으로는 손실과 제 책임을 함께 정확히 설명할 수 있는 직장 실패 사례가 확인되지 않습니다. 사실과 다른 답을 만들지 않고, 면접 전 실제 경험 한 건을 기록과 함께 다시 확인하겠습니다.
130만→6,000은 실행계획상 스캔 행 수. 응답시간· 감소율이 아님.2일→5분은 설계 산정 예시. 결과로 사용하지 않음.30,513 / 23,261 / 21,087 / 2,174 / 9,426 / 32,687 / 4,000 / 17,087 / 5,196을 의미와 함께 말한다..omo/teams/team-4eac0841/artifacts/01-role-company.md, 02-assignment-defense.md, 03-candidate-story.md, 05-behavioral-panel.mdai/repo-notes/remember-data-engineer-assignment-claude.md, ai/worklog/2026/2026-W30.mdai/wiki/people/, ai/wiki/projects/, ai/wiki/academic/, ai/sources/career/career/클로드이력서/리멤버앤컴퍼니-data-engineer/과제/이 문서는 공개 회사 자료와 로컬 검증 기록을 바탕으로 만든 면접용 요약이다. 리멤버 내부 스택, 데이터 규모, 팀 구조와 평가 기준은 공개 자료만으로 확정하지 않았다.
외우기 위한 목록이 아니다. 공개 채용 공고와 기술 글에서 확인된 전체 흐름을 먼저 읽고, 면접 답변의 선택 이유를 자기 말로 바꾸는 데 쓴다.
새로 추가한 7편은 기존 스터디와 겹치지 않는 항목만 다룬다. , , , 일반 , 데이터 품질·계약·이관, MySQL, , 개인정보는 기존 글을 연결 지도에서 이어서 읽는다.