gdg 송도 2024 간단 정리

 에어프레미아는 왜 재개발을 하는가? 

평상시 즐겨보는 velog 분 개발자 분 과 개발바닥 에 나와서 인터뷰를 하신분의 영상을 본 적이 있기에 

익숙한 회사이고 이 세션의 스피커 이신 분은 라인 출신의 개발자 셔서  좋은 개발자분들이 모이는 회사라는 

생각이 들어 궁금해진 상황이여서 첫 세션부터 꽤 기대를 했다.

역시 기본 레거시는 외주로 맡긴 프로젝트의 레거시 국룰 조합 jsp + mybatis +모놀리식+싱글모듈 을 사용 중이라고 한다.

원래는 재 개발을 따로 하실 생각이 없었다고 한다. 하지만 유지보수를 하면서 큰 단점들이 부각이 되어 전환을 한다고 하셨다.

 책임의 모호 함

현대 웹프레임워크에서는 백엔드 프론트엔드를 분리해 하며 백엔드에서는 핵심 비즈니스 로직을 처리하며

데이터를 핸들링하고 추출 가공 후 반환을 하는 역할을 많이 한다.

프론트엔드에서는 ui의 데이터를 보여주며 상태관리를 잘 하고 재사용성이 높은 컴포넌트를 만들어 나가는게좋은 방향 이지 않을까 라고 생각을 하고 있다.

기존 에어프레미아 랩스의 프로젝트에서도 동일한 문제점이 있었다고 한다.분명히 백엔드에서 해야할 로직을 프론트엔드에서 구현이 되어 있는 상황이 많았다고 하셨다.

 

si 의 프로젝트

위의 내용을 듣고 많은 생각이 들어 적어본다.

내가 보고 들어온 si 에서의 상황 에서는 이런 각 역할을 분리해 구현을 한 모습을 들은 적 이 없다.

실제로도 si에서 오래일하신 분들은 백엔드 프론트엔드를 분리 한 것을 아직도 적응 못하시는 분들이 많고 분리를 해서 프로젝트를 시작을 해도 프론트 ,백엔드  분리 형태가 아니라 각 프로젝트의 도메인(작은 기능)  단위로 나뉘어 각자 진행을 많이 해 나가신다.

이 문제는 기존에는 문제가 없고 당연한 프로세스였으며 시대가 바뀐것이기에 나쁜거라고 생각을 하지않는다. 하지만 이런개발을 계속 해왔기에 개발자의 자유도가 너무높기에 레이어간 규칙도 지키지 않는 상황이 많이 나온다. si 에서는 자바 코드를 활용하는 것보다 js에서 모든 것을 수행하고 sql로 나머지 해야 할 부분을 모두 처리하는

로직을 너무 많이 봐왔고 들었고 이렇게 하라고 말까지 들은 상태에서 어떤 레거시 프로젝트인지 듣자마자 머리 속으로 상상이 갔다 ㅋㅋ

버그 지점의 파악이 어려움

위의 문제점이 이어지는 모습이다.

운영 상황의 버그가 나왔다면 이슈사항을 보고 대충 백엔드문제인지 프론트엔드 문제인지 예측 후

티켓을 각 맞는 조직에 할당한다. 그렇기에 각 팀에 티켓이 부여되고 그 티켓을 맡은 개발자는 꼼꼼히 디버깅을 한다.

꼼꼼히 디버깅하는데 몇시간을 사용을 하니 이 로직의 문제점은 본인 파트의 문제가 아니였다.

예시 : 디버깅 하는 개발자가 백엔드개발자이면 프론트문제 프론트 개발자 이면 백엔드 문제 

이 상황이 정말 자주 나왔다고 한다. 이는 1시간이면 해결하는 문제가 3시간 4시간 씩 이어지는 

상황이 자주 나오며 생산성의 많은 저하가 나온다고했다. 

 

 

코드 수정의 두려움

테스트코드 부재와 의존성 관리를 안해놓았던 상황 이었기에 어떤 버그가 나올 지 혹은 코드 수정시

이 코드 변경이 어느정도의 영향력이 있을지 파악이 어려웠기에 개발자들이 코드 변경이

두려웠다고 말씀을 하셨다. 

 

위에 상황들이 발생을 했기에 회사내의 관리자분들께 동의를 얻어  코틀린 + 스프링부트 로 

새롭게 재개발을 시작했다고 하신다. 코틀린을 시작하며 너무 만족하고 돌아가지 않을 것 같다고 

말씀을 하셨다. 다들 이렇게 코틀린의 만족도가 높고 자바로 돌아가고싶지 않다고 하는걸 보니

궁금증이 많이생긴다.

이클립스로 개발을 하다 인텔리제이로 넘어가며 편리함을 느끼는 그런건가...?

프로젝트 재 개발을 하며 멀티모듈 과 레이어간의 의존성 관리를 중점으로 재 개발을 하셨다고 하셨다.

 

우리는 이런 문제가 있었기에 재개발을 시작했으며 이런 문제를 방지하기위해 어떤걸 조심하며 재개발을 시작했어요

라는 것을 중점으로 이어지는 세션을 말씀해주셨는데 너무 좋았다. 인프라 인스트럭쳐의 DIP 라던가 레이어 모듈간 의존성 관리 내가 생각하는 좋은 프로젝트의 구조를 많이 갖춰지는 모습으로 설명을 해 주시는 모습이 참 공감이 가고 좋았다.

최대 동접 10만트래픽을 소화하는올리브영 온라인몰의 전시 전략

 

전제는 올리브영의 이벤트 마다 대용량 트래픽이 몰려와 서버가 너무 느렸고 이에

앱 리뷰 커뮤니티 등등에서 악평 같은 것이 너무 많았고 사내에서도 인지를 해

성능개선에 리소스를 투여해 이에 대한 애기를 주로 많이해주셧다.

첫 올리브영의 접속화면인 상품을 전시하는 화면을 중점으로 스피커분 께서 말씀해 주셨다.

핵심은 많은 도메인( 상품 ,쿠폰 , 가격 ,수량 )의 정보를 보여 주어야 하고 많은 정적리소스 들도 있다 보니

성능에 많은 부하가 갔고 굉장히 느린이유 였다. 

이를 cache를 도입하는 방향으로 결정을했다고 한다.

보여야하는 화면을 CQRS를 통해 비정규화를 한후 RDB로 구현을 할 수가 있었지만 스키마의 자유성과

압도적인 성능에 의해 몽고디비를 선택을 했고 캐시가 만료되는 시점 캐시쓰기가 한번에 RDB로 가는 경우를

방지 하기 위해 몽고디비에 값을 넣어둔것을 기반으로 스케줄링으로 캐시에 값을 넣어주는 전략을 활용을 했다.

 

엄청난 성능튜닝이 된후 요즘 올리브영 폼미쳤다라는 댓글들과 함께 조직원분들도 모두 행복해졌다는 

애기를 해주셨다 ㅋㅋ

 

올리브영 온라인몰의 전시, 그리고 백엔드 여정 | 올리브영 테크블로그 (oliveyoung.tech)

올리브영 온라인몰의 전시, 그리고 백엔드 여정 | 올리브영 테크블로그

자세한 기술적인 많은 내용들은 기술블로그의 출처를 납깁니다.

web Application Service 에서 E2E & API 테스트 자동화 사례 공유

 

평상시 본 채용공고이자 내 회사 근처인 곳이기도한 소속의 개발자분께서 발표를 해주셨다.

요점은 스타트업 특성상 빠른제품을 딜리버리하기위해 테스트코드없이 MVP개발 후

이제는 시장에서 상품을 인정받고 안정성을 키우는 단계이기에 테스트코드를 추가하면서

단위 테스트와 통합테스트같은 경우는 그래두 조금의 러닝커브로 구현을 했다면 이제는

E2E테스트를 추가하는 상황에 node진영에서의 라이브러리의 장단점과 기술선택에 부터 

아키텍처 구현까지 자세히 설명해주신것이 너무 좋았다.

여기서 공감이 갔던것은 최근에 내가만든 사이드프로젝트의 핵심 로직이 웹 스크래핑 이었기에 E2E 테스트의 꿀팁으로 브라우저가 렌더링되는 특정시간을 기다려주어야합니다 라고 말씀을 해주셨는데 이번 사이드프로젝트의 가장 삽질을 했던 부분에 정확히 애기해주셨기에 나와 같은 삽질을 하시고 구현을 하셨구나 ㅋㅋ 라는 생각과 함께 더 재밌게 들었다.

의도 자체가 비개발자 직군에서도 편하게 E2E테스트를 쉽게하기위해 UI 상 버튼을 제공하고 서버는 AWS 람다로 구현을 하셨다고 한다. 

100명의 개발자분들을 도와 100개가 넘는 오픈소스 PR을 함께 만들고 세상을 바꾼 이야기

 

마음에 드는 세션이 없던 와중에 오픈소스 컨트리뷰터가 되보고싶단 생각이 있었는데 마침 좋은

세션이라는 생각이 들어 참여를 한 세션이고 가장 크게 만족을 한 세션이다.

일단 우리나라가 오픈소스의 참여도가 전세계적으로 봐도 낮은 수치를 보여주면서 설명을 시작해주신다.

 

현재 라인에서 일하시며 아메리아 ,스프링 시큐리티 , 배치 의 컨트리뷰트이시기도 한 분이다.

 

오픈소스에 참여하는게 진입장벽이 가장높은 문제라고하신게 가장 공감이 갔다.

코드스타일  , 어떤문제가 있는데 읽어야하는 코드의 범위부터 영향범위 파악 ,

심리적으로 이렇게까지 해야하나? 가 대부분이고 실제코딩에대해서는 10%정도라고 하신다.

(이건 회사에서도 똑같지 않나..?)

이를 스터디에 참여하는 인원들에게 적절한 오픈소스 선정 부터 어떤소스 코드의 어디를 어떻게 고쳐야 하는지

모두 알려주시며 떠먹여 주신다고 하신다 ㅋㅋ

이정도면 거의 다 해 주시는거아닌가?

라는 생각이 들었지만 이런 첫 진입장벽을 해결해주시니 스터디에 참여하는 모든분들이 하루만에 PR작성에 성공하시고 많은분들이 컨트리뷰트가 되었다는 모습을 보고 정말 신기했다.

평상시 오픈소스 컨트리뷰트가 되야지라는 막연하게 생각만 했던 나에게 조금더 자신감을 주었던 세션이다.

마음같아선 정말정말 참여하고싶지만 난 왜 송도에 살지...

혼자서 오픈소스를 시작하는 동기를 갖기에 너무좋았던 세션이다 혼자서 글을 작성하며 다시한번 감사드립니다!!

 

 

스피커분의 오픈소스 멘토링을 구하는 링크이다!

 

오픈소스 멘토링 PR, 기부 (notion.site)

오픈소스 멘토링 PR, 기부 | Notion

DB를 느리게 만드는 다양한 방법들

 사실상 지금도 이전에도 가장 중요시 여겼던 db 의 관련된 세션이기에

이 세션도 크게 기대를 했다. 크게 기대를 했던것에 비해 꽤 너무 기본적인 애기만 해주시기에 반전이였다.

스피커분께서도 세션을 시작하는 처음부터 아주 기본적인 설명부터 시작을 한다고 하셨기에 대상자가 데이터베이스를 잘

모르시는 분들이라고 하셨기에 큰 불만없이 아주 중요한 핵심개념(index , btree)부터 설명해주셨기에 기본을 다지자는 생각으로 들었던 세션이였다.

 

 

 

 

나의 첫번째 참여한 오프라인세션이였다.

원래부터 참여 하고싶었지만 물리적으로 너무 멀었기에 참여를 못하다 집앞 에서 열리는 것이기에

꼭 참여를 하고 싶었고 참여를 해봤는데 너무 만족하는 컨퍼런스였다. 

다른 많은 컨퍼런스에도 참여를 하고싶지만 물리적으로 참여를 못하는 아쉬움 이 많이드는 생각이지만

내가 참여를 할수있는 조건이라면 컨퍼런스에 좀더 참여를 하고싶다는 생각이들었던 첫 컨퍼런스였다.

그리고 가장크게든건 유튜브에 영상들을 올려주는 컨퍼런스들이 많이 늘었으면좋겠다 ㅠㅠㅠ

나같은 서울, 판교  거주지가 아닌 분들은 유튜브로서 많이 듣는걸 감안해서 녹화만 해주시면 좋겠다고 생각을 한다.