2025-04-03-TIL
이력서에 관하여
이력서에 관하여 지인에게 피드백을 받을 기회가 있었다. 경력이 많거나 직책자는 아니지만, 내가 원하는 회사에 가서 느낀점들을 바탕으로, 상세한 피드백을 해주었다. 정말정말 고맙게도 나라는 사람을 좋게 봐주면서 진심어린 피드백을 해주는 모습이 감명깊었다.
나의 이력서의 현재 모습은 다음과 같다.
(주)회사명 | 프로젝트명
2024.1 ~ 2024.11
주요 내용
- 레거시 시스템 전면 개편 및 API 중심 아키텍처로 재설계
기여한 점
- … API 설계 및 구현
- 계약 코드 생성 프로세스 최적화 → 트랜잭션 처리 속도 5배 향상 (1m 30s → 500ms 이하)
- 엑셀 업로드 프로세스를 동기 → 비동기 방식으로 전환하여 시스템 부하 감소
- 감사 대응 및 로깅 시스템 개선
사용 기술
…
성과
- 대용량 파일 업로드 프로세스 개선으로 운영 리소스 1.5MM 절감
- 곡 관리 시스템 최적화로 대량 콘텐츠(약 8,000만 곡) 운영 효율성 향상
- 계약 코드 생성 방식 개선으로 트랜잭션 처리 속도 5배 향상 (1m 30s → 500ms 이하)
우선, 1페이지를 읽고 그 다음 페이지를 읽고 싶은 마음이 드는가? 또는 이 사람이 한 일이나 사람 자체에 대한 호기심과 관심이 생기는가? 라는 부분이 정말 중요한데, 그 부분에서 부족함이 느껴진다. 과연 왜 그럴까?
기여한 점이나 성과 부분에서 특히 수치에만 집중한 무작위식 나열은 하나도 눈에 들어오지 않는다. 예를 들면, 계약 코드 생성 프로세스 최적화라는 부분에서 계약 코드 생성 프로세스가 어떤 방식이었는데 -> 어떤 방법을 떠올렸고 -> 그 중에서 어떤 방법으로 해결했는지 -> 그리고 그 방식으로 얼마나 효과를 보았는지를 상세하게 작성하는것이 훨씬 눈에 띄고 몰입이 되는 이력이다. 나머지 내용들을 다 삭제하더라도 4개 중에 하나의 내용에 대해서 충분히 잘 작성하면, 굳이 설명하지 않더라도 나머지 부분에서는 오히려 “더 많은 것들을 생략하고 겸손하게 썼구나”하는 일종의 버프를 받을 가능성도 높다고 생각한다는 의견을 받았다. 비슷한 맥락으로, 대용량 파일 업로드 프로세스를 비동기 방식으로 전환했다면, 어떤 불편한 점이 있었고 -> 어떤 아키텍쳐를 떠올렸으며 -> 그 방법으로 진행하면서 어떤 고민까지 해보았는지를 상세히 써볼 수 있다.
8,000만 곡을 운영했다면 꼬리질문을 예상해볼 수 있다. 8,000만 곡이 Read/Write DB에 저장되는 상황에서 ReadOnly DB를 별도로 구성한다고 가정해보자. 이때 R/W DB에서 10만 건의 데이터가 한 번에 insert되는 경우에 ReadOnly DB로 레플리케이션 되는 상황에 1~2분의 쓰기지연이 발생한다. 이 경우에 쓰기 지연을 어떻게 해소할 수 있을까? 이처럼 항상 꼬리질문을 스스로 문답해보고 충분히 대답할 수 있도록 준비되어야 한다. 그리고 준비가된 글만 이력서에 담도록 해야한다.
꼬리질문으로 준비할 것
B-Tree는? 쿼리에서 LIMIT가 쿼리 실행순서 상 어느 단계에 포함되며, 왜 성능에 유리한가?
아래는 위 질문들에 답하기 위해 MySQL 공식 문서에서 확인한 내용이다.
복제 지연과 병렬 적용
MySQL 복제에서 레플리카는 소스의 바이너리 로그를 받아 릴레이 로그에 쓰고, 이를 다시 적용(apply)한다. 한 번에 많은 행이 들어오면 이 적용 단계가 밀리면서 읽기 전용 DB가 늦게 따라온다. MySQL 8.0 문서에 따르면 replica_parallel_workers(8.0.26 이전 이름은 slave_parallel_workers)를 1 이상으로 두면 레플리카가 지정한 수의 워커 스레드로 트랜잭션을 병렬 적용하고, 코디네이터 스레드가 릴레이 로그를 읽어 워커에 나눠 준다. 지연을 줄이는 방법을 답하려면 이런 적용 단계의 병렬화와, 큰 쓰기 작업을 어떻게 나눌지를 함께 설명할 수 있어야 한다.
B-Tree 인덱스
MySQL 문서에 따르면 B-Tree 인덱스는 =, >, >=, <, <=, BETWEEN 같은 비교와, 와일드카드로 시작하지 않는 LIKE에 쓸 수 있다. 복합 인덱스에서는 키의 왼쪽부터 이어지는 접두 부분(leftmost prefix)만으로도 행을 찾을 수 있다. 반면 해시 인덱스는 =나 <=> 같은 동등 비교에만 쓰이고 범위 검색에는 쓰이지 않는다.
LIMIT가 성능에 유리한 이유
MySQL은 필요한 행 수만큼 클라이언트에 보내면 쿼리를 중단한다. ORDER BY와 LIMIT를 함께 쓰면 정렬된 결과의 앞쪽 row_count개를 찾는 즉시 정렬을 멈추고, 정렬을 인덱스로 처리할 수 있으면 매우 빠르다. 그러나 인덱스를 쓰지 못해 filesort를 하면 LIMIT 없이 조건에 맞는 행을 모두 고른 뒤 대부분을 정렬하고 나서야 앞쪽 행을 얻는다. 그래서 LIMIT의 이점은 정렬 기준에 맞는 인덱스가 있는지에 크게 좌우된다.
댓글
아직 댓글이 없습니다