2025-04-03-TIL

Today I Learned

이력서에 관하여

이력서에 관하여 지인에게 피드백을 받을 기회가 있었다. 경력이 많거나 직책자는 아니지만, 내가 원하는 회사에 가서 느낀점들을 바탕으로, 상세한 피드백을 해주었다. 정말정말 고맙게도 나라는 사람을 좋게 봐주면서 진심어린 피드백을 해주는 모습이 감명깊었다.

나의 이력서의 현재 모습은 다음과 같다.

(주)회사명 | 프로젝트명

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가 쿼리 실행순서 상 어느단계에 포함되며, 왜 성능에 유리한가?