인프런 커뮤니티 질문&답변
작성한 질문수
이력서 작성 시 궁금한 점
해결된 질문
작성
·
80
0
1. 현재 학습 진도
몇 챕터/몇 강을 수강 중이신가요? 3챕터 인덱스 파트 수강 중
질문 1. "기존 API 응답 시간에서 **를 개선하여 **ms까지 빨라졌다." 이런 식으로 문구를 작성하라고 하셨는데, 기존 API 시간이 너무 크면 어떻게 해야할까요?
API 성능 측정을 하려면 데이터를 넣어야하니까 각 테이블마다 백만 건을 넣어놓고 테스트를 했는데, 개선 전 응답 시간이 너무 오래 걸려서 그걸 그대로 써도 될지 모르겠어요.
강의 중 index파트에서 통계 테이블을 만들어서 @scheduled로 개선하는 부분을 제 프로젝트에 적용했는데, 데이터를 넣을 때 다른 API 성능을 측정하면서 각 테이블 당 백만개, 1:N관계일 때는 1개당 10개씩으로 해서 총 천만개 넣어놓은 상태입니다. 데이터가 너무 많아서 통계 테이블 만들기 전인 상태에서 COUNT 쿼리를 할 때 JOIN하는 테이블은 3개로 각 백만개, 이백만개, 천만개 데이터가 들어가있어서 약 20-30초 가량 쿼리가 실행이 됩니다.
근데 이력서에 "23초 걸리는 통계 데이터 조회 API를 통계 테이블을 만들고 @scheduled를 활용해 5분마다 갱신하고, 갱신된 데이터를 가져오도록 개선하여 **ms로 개선되었다." 라는 문구를 쓰려니까 23초라는 수치가 "인위적으로 드라마틱한 개선을 위하여 만들어낸 수치 아닌가?" 라는 의문이 들 수 있을 것 같아서 어떻게 하면 좋을까요?
물론!! 23초가 나온 근거라고 해야할지... 그 퍼포먼스 테스트 결과는 있고, 일부러 조작하지 않고 데이터가 많아서 그렇다! 라고 설명은 할 수 있겠지만, 이력서에 들어가는 수치를 보면 위에서 얘기한 것 같은 의심이 먼저 들 것 같아서 질문 드립니다. ㅠㅠㅠㅠ
답변 2
0
수환님 좋은 질문 해주셔서 감사합니다!!!
저도 처음에 성능 개선할 때 같은 걱정했었어요. "이 수치가 너무 극단적이면 의심받지 않을까?"
그런데 사실 23초는 전혀 이상하지 않습니다.
실제로 현업에서 일하다 보면 이런 일이 정말 많습니다. 특히 데이터가 쌓이기 시작하면 처음에는 데이터 적어서 괜찮았는데 몇 달 지나니까 갑자기 통계 화면이 안 열리거나 몇십 초씩 걸리고 있는게 흔한 패턴입니다!! 그래서 너무 걱정하지 않으셔도 됩니다.
데이터 규모와 비즈니스 상황을 구체적으로 설명만 해주신다면 충분히 납득가능한 상황이라고 느껴질 수 있으니, 걱정하지 않으셔도 됩니다
면접에서 데이터가 어느 정도 규모였는지, 어떤 상황이었는지 질문이 들어올 거고 이에 대해 자연스럽게 설명만 해주시면 될 것 같아요 결국 중요한 건 숫자 자체보다는 "문제를 어떻게 발견하고 해결했는지"가 더 중요하기 때문입니다.
직접 프로젝트에 적용해보시고 수치까지 얻으시는 모습 넘넘 좋습니다!!! 빠이팅입니닷 ㅎㅎㅎ
0
안녕하세요, 인프런 AI 인턴입니다. 정수환님.
이력서를 작성하시면서 API 성능 개선에 대한 수치를 어떻게 표현할지 고민하시는 것 같습니다. 특히, 초기 API 응답 시간이 매우 길어 고민이신데요, 이력서에 성능 개선을 효과적으로 나타내기 위한 몇 가지 팁을 드리겠습니다.
성능 개선 사항을 이력서에 적는 방법:
컨텍스트 제공:
- 데이터 볼륨이나 시나리오에 대한 배경을 설명하십시오. 예를 들어, “테이블에 백만 건 이상의 데이터가 포함되어 있는 상황에서” 같은 문구로 시작하면, 왜 응답 시간이 그렇게 오래 걸렸는지에 대한 배경을 제공합니다.
- 이 문구는 대량의 데이터를 다루는 환경임을 명확히 해주므로, 초기 23초라는 시간이 이상하게 보이지 않을 것입니다.
- 데이터 볼륨이나 시나리오에 대한 배경을 설명하십시오. 예를 들어, “테이블에 백만 건 이상의 데이터가 포함되어 있는 상황에서” 같은 문구로 시작하면, 왜 응답 시간이 그렇게 오래 걸렸는지에 대한 배경을 제공합니다.
비교적 측정 강조:
- 개선 전후의 상황을 명확히 비교하여 설명하세요. 예를 들어, “백만 건의 데이터가 있는 테이블에서 기존 API 응답 속도가 23초였으나, 최적화 후 **ms로 감소”와 같이 서술하면 전후의 변화를 이해하기 쉽습니다.
- 또한, 동일한 데이터량 하에서 개선된 성능을 강조하면 의도가 정확히 전달됩니다.
- 개선 전후의 상황을 명확히 비교하여 설명하세요. 예를 들어, “백만 건의 데이터가 있는 테이블에서 기존 API 응답 속도가 23초였으나, 최적화 후 **ms로 감소”와 같이 서술하면 전후의 변화를 이해하기 쉽습니다.
구체적인 개선 과정 설명:
- 이력서나 인터뷰에서 성능을 개선하게 된 구체적인 히스토리를 설명할 수 있도록 준비해 두세요. “어떤 전략을 사용하여 어떻게 개선했는지”에 대한 구체적인 사례를 적으면 신뢰도를 높일 수 있습니다. 예를 들어, “@scheduled를 활용한 주기적 데이터 갱신으로 중요 데이터의 최신성 확보 및 성능 최적화” 등.
- 이력서나 인터뷰에서 성능을 개선하게 된 구체적인 히스토리를 설명할 수 있도록 준비해 두세요. “어떤 전략을 사용하여 어떻게 개선했는지”에 대한 구체적인 사례를 적으면 신뢰도를 높일 수 있습니다. 예를 들어, “@scheduled를 활용한 주기적 데이터 갱신으로 중요 데이터의 최신성 확보 및 성능 최적화” 등.
정량적 성과 표현:
- 성능 개선이 실제로 비즈니스나 프로젝트에 어떤 긍정적인 영향을 주었는지를 설명하면 효과적입니다. 예를 들어, “서비스 가용성 향상 및 사용자 경험 개선을 통한 유지율 증가” 등과 같은 부가 설명이 추가되면 좋습니다.
- 성능 개선이 실제로 비즈니스나 프로젝트에 어떤 긍정적인 영향을 주었는지를 설명하면 효과적입니다. 예를 들어, “서비스 가용성 향상 및 사용자 경험 개선을 통한 유지율 증가” 등과 같은 부가 설명이 추가되면 좋습니다.
관련하여 이력서 및 성능 개선 측정법에 대한 보다 자세한 논의는 다음의 링크를 참조하시면 도움이 될 것입니다:
- 질문 제목: 백엔드 성능 개선 방법들에 대해 궁금해요
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.