들어가며최근 모든 업계에서는 빠르게 서비스를 생산하고 소비자의 선택을 받는 것이 중요해졌습니다. 사회의 속도가 빨라진 만큼, 소비자들의 관심이 집중되고 흩어지는 속도 역시 그만큼 빨라졌기 때문인 것 같습니다. 이는 소프트웨어 역시 마찬가지입니다. 빠르게 새로운 기능, 서비스를 개발하고 고객들에게 선보이며 그 피드백을 반영하면서 발전하는 것이 곧 기업의 경쟁력이 되었습니다. 최고의 기업 중 하나인 아마존은 이미 2014년에 1초에 1.5회의 배포 주기를 가졌다고 합니다. 주 1회 배포하는 동일 산업의 기업과의 경쟁력은 말할 필요도 없겠죠. 하지만 배포는 쉬운 일이 아닙니다. 기존의 시스템을 중단하고, 새로운 버전의 시스템을 가동해야 합니다. 또한 운영 환경에서 충분한 테스트를 거쳐야 하고, 문제가 발생하면..
🎸 ETC
시작개발 프로젝트를 진행하면 기능을 개발하는 것이 전부가 아니라는 것을 아실 겁니다. 성능, 신뢰성, 보안 등 다양한 비기능 요구사항 역시 충족시켜야 하죠. 저 역시 프로젝트에서 만든 기능에 대한 성능을 점검하고, 개선할 수 있는 부분은 능력이 닿는 한 향상하려고 노력합니다. 저는 가장 먼저 하는 작업으로는 조회 API에 대해서 성능 테스트를 진행하고, 캐싱이 가능한 부분은 캐싱을 도입해서 성능 개선을 하려고 하는 편입니다. 이 글은 제가 성능 테스트와 캐싱을 적용하는 과정에서 겪었던 시행착오에 대해서 다룹니다. 이미 내용을 아는 분들은 웃으면서 읽어주시고, 알지 못했던 분들은 저와 같은 실수를 하지 않으시길 바랍니다. 발단 블로그 소재가 없나.. 하면서 `velog`를 구경하는 와중에 이런 글을 읽었..
들어가며 `Velog`에서 작성했던 글들을 `Tistory`로 이전하면서 `Tistory`에서도 인라인 코드 블럭을 적용할 수 있다는 사실을 이번에 처음 알게 되었다. 하지만 알아보니 굉장히 번거로운 과정을 거쳤어야 했다. 이 포스팅에선 인라인 코드 블럭을 쉽게 이용할 수 있는 방법과 그 과정에서 발생했던 시행착오에 대해서 기록한다. 기존의 인라인 코드 블럭 사용방법 마크다운을 이용할 때, 많은 개발자들은 백틱(`)을 활용하여 인라인 코드 블럭을 작성한다. 쉬운 방법으로 코드를 하이라이팅 할 수 있기 때문이라고 생각을 한다. 하지만 티스토리에서 인라인 코드 블럭을 작성하는 방법은 굉장히 번거롭다. 보통의 티스토리 유저들은 `기본 모드`를 이용하고 있을 것이라고 생각이 되는데, 그 상황에선 아래와 같은 작..
