안녕하세요. 사람인HR IT연구소 개발1팀 권종성입니다 :) 저는 웹 개발자로 사람인 채용포털 전반에 걸친 서비스를 개발하고 있으며, 이번에 좋은 기회로 사람인 모바일 페이지와 베트남 자회사인 앱랜서에서 IT직무에 특화된 채용포털 사이트인 Topdev 웹 사이트 성능을 최적화하는 작업을 하게 되었습니다. 지금부터 기존에 어떤 성능 이슈들이 있었고, 어떻게 최적화를 하였는지 하나씩 알아보겠습니다. 시작은? 사람인HR IT연구소에는 길드라는 아주 특별한 모임이 있습니다. 길드는 IT연구소 연구원들의 주도하에 실험적인 도전이나 다양한 문제들을 해결하기 위해 결성되는 모임인데요. 저는 모바일 서비스 성능개선 길드원을 모집한다는 공지를 보고선 뭔지는 잘 모르겠지만.. 뭔가 멋진데?라는 생각과 함께 참여하겠다는 메일을 보내고 길드에 참여하게 되었습니다(속전속결!). 결과적으로 여러 개선 방법들을 통해 웹 사이트를 최적화하여 사용자에게 더 나은 서비스를 경험할 수 있도록 하였고, 저 또한 웹 개발자로서 한층 더 성장하는 뜻 깊은 시간이었습니다. 현재의 문제들 Page Load Time(seconds) Bounce Rate(%) 1 7 2 6 3 11 4 24 5 38 6 46 7 33 Does Page Load Time Really Affect Bounce Rate?(2018) 포스트에서는 페이지 로드 시간에 따른 사용자 이탈률의 상관관계에 대한 내용이 작성되어 있습니다. 특히 페이지 로드까지 4초가 소요되면 이탈률은 24%로 급격히 증가한다고 나와 있는데요. 이와 같이 사용자는 페이지의 응답, 콘텐츠의 노출, 사용자가 마우스나 손을 통해 페이지를 동작할 수 있을때까지 4초를 넘어가게 되면 사용자는 적지 않은 불쾌감을 느끼게 되며, 더욱 심각한 건 사이트에 대한 불신이 생길 수도 있습니다. 특히, 한번 이탈한 사용자는 언제 돌아올지 알 수 없습니다. 불쾌하더라도 정말 보고싶은 콘텐츠나 사용하고 싶은 서비스가 있기 전까진 말이죠.(좋은 서비스를 만드는 건 다른 얘기입니다!!) 사람인 모바일 메인페이지는 접속자 수가 TOP 5 안에 들지만, 많은 콘텐츠와 기능들로 인해 무거워져 있어 최적화가 가장 시급하여 첫 최적화 작업 대상으로 사람인 모바일 메인페이지를 선정하였습니다. google analytics에서 확인해본 결과 지난 한 달간 모바일 메인페이지의 평균 로드 시간은 4.13초, 이탈률(Bounce Rate)는 5% 대 였는데요. 위에서 소개한 이탈률과는 괴리가 있는데요. 이는 사람인은 많은 구직자가 접속하는 사이트로 사이트 성능이 좋지 않아도 그에 상응하는 구직과 관련된 콘텐츠와 서비스가 있어 참아내며 이용하는 것으로 추정하였습니다. 그렇다고 내버려 두면 안되겠죠?! 웹 페이지를 최적화 하는데 일반적으로 사용할 수 있는 방법들은 다양하게 있는데요. 저희는 프론트 엔드를 분석하여 아래와 같이 최적화 할 수 있는 것들을 검토하였습니다. 방문 페이지 HTML 압축 인라인 CSS, Javascript 파일로 통합 Javascript 지연 로드 콘텐츠

새로운 프로젝트를 시작하면서 기본 구성에서 시작하여 시행 착오를 통해 시간이 지남에 따라 파이프라인 구성을 개선하는 것이 일반적입니다. 더 나은 프로세스는 효율성을 즉시 개선하고 더 빠른 소프트웨어 개발 수명주기를 더 일찍 확보하는 파이프 라인 기능을 사용하는 것입니다. 파이프라인을 보다 효율적으로 만들면 개발자 시간을 절약할 수 있습니다. 온-프렘 쿠버네티스 클러스터에서 GitLab Auto DevOps 커스터마이징으로 빌드 속도를 향상시킨 내용을 소개하고자 합니다. 요약 docker 서비스가 registry-mirrors 로 nexus 를 사용하도록 설정하여 네트워크 대기 시간(latency) 개선 빌드 작업 전용 GitLab Runner 서버 구성 CI/CD 작업에서 docker 명령을 가능하도록 소켓 바인딩 사용 (도커 레이어가 캐시됩니다.) 커스텀 빌드팩 및 빌드 환경으로 CI/CD Variable 전달하여 라이브러리 다운로드 경로를 사내 네트워크로 변경시켜 네트워크 지연 개선 커스텀 Dockerfile 빌드 캐시 마운트로 종속성(dependencies) 등이 재사용 되어 빌드 속도 향상 병목 현상 및 일반적인 오류 비효율적인 파이프라인은 작업의 실행 시간으로 확인됩니다. 2분 걸리던 작업이 10여분 걸린다거나 1-2시간이 지나 타임아웃 되는 경우 GitLab Runner 와 관련된 사항: 러너와 이들이 프로비저닝 된 리소스의 가용성. 빌드 종속성 및 설치 시간. 컨테이너 이미지 크기 - 이미지나 레이어 캐시가 되지 않는 경우 네트워크 지연 및 느린 연결. - 빌드 팩에서 다운로드가 느리거나 타임아웃 되는 경우, 무작위로 실패하거나 신뢰할 수 없는 테스트 결과를 생성하는 비정상적인 단위 테스트는 TEST_DISABLED 로 그룹 환경 변수로 비활성 하였습니다. 또는 수동, 실패해도 넘어가도록 설정하는 할 수도 있습니다. Registry Mirror 사용 Nexus 를 Docker Hub 미러로 사용(registry mirror) 성능 향상을 위해 레지스트리 미러를 구성 하고, Docker Hub 속도 제한에 도달하지 않도록 합니다. Docker 프락시 저장소 생성 docker.io Proxy Registry for Docker Hub http://sri-nexus.example.com/#browse/browse:docker.io Enable Docker V1 API Support Allow anonymous docker pull ( Docker Bearer Token Realm required ) registry.gitlab.com Proxy Registry for GitLab Repository Allow anonymous docker pull ( Docker Bearer Token Realm required ) Docker 저장소 그룹핑 Name: registry-mirrors Repository Connectors: HTTP: 8082 v Allow anonymous docker pull ( Docker Bearer

안녕하세요. 2020년 사람인 IT 연구소 신입 개발자 공채 1기를 거쳐 정규직으로 전환되어 개발 2팀에 근무하고 있는 이정규입니다. 취준생이였을 때 사람인을 통해 입사 지원도 하면서 자주 사용해왔는데, 내가 사용했던 서비스를 직접 개발하고 있다는 걸 생각하니까 신기하기도 하고 한편으론 책임감도 느껴집니다! 저는 전자공학을 전공했는데, 웹 개발자로 진로를 정하기까지 고민이 많았어요. 그래서 졸업할 때쯤부터 웹 개발이나 알고리즘 등 SW 교육을 찾아서 많이 들었습니다. 최근에는 특히 기업에서 주최하는 IT 관련 캠프나 교육들이 많아져서 이런 교육들도 찾아다니면서 수료했어요. 이런 교육 경험들과 SW에 대한 높은 관심도를 많이 어필했던 게 어느 정도 도움이 되지 않았나 개인적으로 생각해봅니다. 이렇게 사람인 공채 1기에 합격하게 되었고 지금부터는 제가 사람인 인턴으로 입사해서 3개월간의 인턴 생활과 정규직 전환 후 약 6개월간 어떤 일을 하고 어떤 방식으로 일을 하는지 얘기해볼까 해요. 인턴 과정 처음 인턴으로 입사를 하고 며칠 동안은 사람인의 전반적인 서비스에 대한 교육들을 들으며 회사에 대해 많이 알아가는 시간을 가졌어요. 사람인에서는 멘토-멘티 제도를 통해 신규입사자들이 회사에 빠르게 적응할 수 있도록 도와주고 있는데, 멘토님이 개발환경 세팅이나 그룹웨어 사용법 등 업무 관련 지식뿐만 아니라 사내카페나 각종 복지 혜택에 대해 두루두루 알려주셔서 적응하는 데 많은 도움이 되었어요! 1차 프로젝트 이렇게 교육과 며칠간의 적응 기간이 끝난 후 프로젝트를 시작하게 되었고, 인턴과정 동안 크게 두 가지 프로젝트를 진행했어요. 1차 프로젝트는 제시된 주제 중에서 선택하거나 자신만의 새로운 주제를 생각해서 진행할 수 있었어요. 언어는 php로 진행하였고, 프레임워크는 자유롭게 선택할 수 있었습니다! 저는 php 프레임워크 중에 Laravel을 선정해서 진행했는데요. 일단 Laravel은 php 프레임워크들 중에 가장 인기가 많고, 많은 개발자가 사용하고 있다는 게 큰 메리트라 생각했어요. 가장 많이 사용하고 있다는 건 그만큼 개발 커뮤니티가 활성화되어 있고, 오류가 발생했을 때 많은 도움을 받을 수 있죠. 그뿐만 아니라 MVC 패턴을 제공하고 있고, composer라는 패키지 매니저를 사용할 수 있어서 편리하고 효율적으로 개발할 수 있어요. 그 외에도 라라벨 코리아 커뮤니티가 있어서 처음 배울 때 한글화된 문서를 통해 쉽게 입문할 수 있는 것도 큰 장점이라 생각했습니다! 1차 프로젝트에서는 개인 프로젝트였기 때문에 프로젝트 구조 설계, DB 스키마 및 관계도, 기획 등을 모두 혼자서 해야 했는데요. 혼자서 프로젝트를 설계하는 게 쉽진 않았지만 멘토님 도움도 받아가면서 문서도 작성해보고 하니 전체적인 프로젝트 구조나 어떤 식으로 구성되어있는지 알아갈 수 있어서 좋았어요. 저는 XML 뉴스 데이터를 토대로 게시판 CRUD 기능을 구현해보는 프로젝트를 진행했어요. 중간중간 잘 안되거나 모르는 부분이 나오면 멘토님이 많이 도와주셔서 수월하게 진행

CTO 님으로부터 레거시 시스템 컨버팅 과정에 관한 기술 블로그를 작성해보는 것은 어떠냐, 하는 제안을 받았습니다. 순간 1년이 꼭 10년 같았던 고난과 좌절, 그리고 환희의 순간들이 주마등처럼 머리를 스쳐갔습니다. 그 대장정의 이야기 보따리를 하나씩 짚어가며 풀어나가 보겠습니다. 1. 레거시 시스템 현황 파악 2019년 6월 4일 화요일, 딸의 생일 다음 날, 동대문을 시스템화 한다는 거대한 꿈을 가지고 있는 회사에 부푼 마음을 안고 힘차게 첫 출근을 했습니다. 무슨 일부터 해야 할까요? 일단 소스 보면서 구조부터 파악하시면 될 것 같습니다. 네! 알겠습니다. 여러 모듈이 있던데 git 주소 좀 알려주세요~. 네. XX와 XX의 git 주소는 OO 이고요, XX와 XX의 FTP 주소는 OO 입니다. !! FTP. 마지막으로 이 단어를 들었던 순간이 언제였을까 한참 생각해보았습니다. 조금 과장을 보태면 아마도 구한말 순종 8년 때 마지막으로 듣고 못 들어본 단어였습니다. 형상 관리부터 심상치 않음을 느낀 저는 떨리는 마음으로 한가지 질문을 추가했습니다. 그. 그럼 모바일이랑 웹에서 사용하는 API 소스는 그 중에 어느 것일까요? 모바일 API 주소는 XX, 웹 API 주소는 OO, 관리자 API 주소는 KK 등등 블라블라 입니다. !!!! 뭐. 뭐지. 왜 API 주소가 모조리 나뉘어 있는 거지. 좀 구식이지만 MSA(Micro Service Architecture)로 구현한 형상관리인가 이런 저런 의문과 두려움을 품은 채 소스를 하나씩 분석해 나가기 시작했는데, 결과는. 절망이었습니다. 그 이유를 한가지 예를 들어 설명해보겠습니다. 어떤 상품의 상세 정보를 반환 하는 API가 있다고 가정하면, 일반적으로 그 API 하나를 작성하고 나면 그것을 사용하는 매체는 모바일이나 웹, 플랫폼 상관없이 호출할 수 있고 인증 부분만 다른 구조를 가질 것입니다. 그러나 이 레거시 시스템은 모든 매체에 따라 API 서버, 소스가 모두 나뉘어져 있었습니다. DB에 어떤 테이블에 컬럼이 하나 추가되었다고 가정하면 관련된 API만 수정하면 되는 게 일반적인데, 이 시스템에서는 해당 컬럼과 관계된 모든 부분을 같은 코드로 수정해야 하는 안타까움이 존재하고 있던 것입니다. (실제로 2019년 7월경에 약간 복잡도가 있는 모듈을 개발한 경험이 있었는데, 그 때 자칫 잘못하면 소스 수정하다가 공황 장애가 올뻔했습니다.) 비슷하면서도 살짝 씩 다른 소스를 계속 수정하다 보니 데자뷔 같기도 하고, 8중 if 문을 따라 들어가다가 길을 잃고 림보 상태에 빠졌다가 겨우 현실 세계로 돌아온 경험도 있었습니다. 위대한 수학자이자 철학자 피타고라스께서는 이런 상황에 대해서 아래와 같은 말을 남겼습니다. 내가 보기엔 이건 답이 없다. - 피타고라스 - 빛이 보이지 않는 상황이었습니다. 설상가상으로 서버는 AWS가 아닌 다른 서비스를 사용하고 있어서 오토 스케일링 같은 유연함도 없었고, 어떤 서비스는 상용 서비스임에도 불구하고 서버 1대로 운영하는 깡(?)을 보여주기도 하였습니다.