[GDSC] konkuk kprint; (건국대 컨퍼런스를 다녀오며) [1편]

경북대에서 GDSC 2기와 중도에 인턴과 캠프 때문에 나오게 됐지만 3기까지 활동을 하면서 전국의 여러 대학에 있는 GDSC에서 진행하는 행사를 자주 참가하러 다녔던 것 같습니다. 다녀온지는 꽤 됐지만 항상 정리는 열심히 해놓고 블로그에 올려야지 올려야지 하다가 습관을 좀 잡으려고 하나씩 올려볼까 하다가 이게 제일 먼저 생각나서 살살 적어봅니다. 

컨퍼런스 포스터

생각보다 다양한 주제로 이워져 있어서 흥미가 갔었고, 백엔드 현직자 한명 그리고 컴공 복수전공생 한명을 꼬셔서 컨퍼런스를 들으러 가게 되었습니다. 개인적으로 관심있었던 내용은 제가 프론트를 하고 있기 때문에 "React 19, 2년만의 업데이트엔 무엇이 달라졌을까?" 였지만 다른 주제들도 워낙 흥미로운 주제가 많아서 현장에서 여쭤보고 영상을 올려주신다고 하셔서 다양하게 강의를 듣는 쪽을 선택했습니다. 

Hexagonal Architecture

함께 간 백엔드 친구가 들어보자고 해서 한번 들어본 강의 입니다. 디자인 패턴이나 아키텍처에 대한 이해가 필요하다고 올해 초 부터 생각을 좀 했던 것 같습니다. 그래서 개발쪽으로는 잘 모르는 자바를 메인으로 한 강의지만 한번 들어보려고 했습니다. 밑에 내용을 들으면서 간단하게 정리한 부분을 올려뒀습니다. 전체적인 느낌은 이해가 되었지만 구체적인 적용에 대해서는 이해가 좀 부족했던 것 같아서 나중에 좀 더 공부를 해야겠다 라고 생각을 했습니다. 밑에 가기 전에 듣고 참고 했던 우아콘 아키텍처 관련 영상 링크를 달아뒀으니 참고하셔도 좋을 것 같습니다. 

[가기 전에 듣고 갔던 2022 우아콘에서 아키텍처 관련 영상] 
https://youtu.be/saxHxoUeeSw

[내용 정리] 

• UI Layer → business Layer(incoming/.service/outogin port) → persistente adapter
• Adapter를 통한 진입점 만들기
  • 웹어댑터(Http, 직렬화 검증)
  • 비즈니스 레이어(incomming layer / service)
    • 들어올 때 incomming 레이어가 아니라 웹어댑터에서 유효성을 검증하고 서비스에서는 비즈니스 파트만 다룰 수 있도록 해주는
    • 검증의 범위에 따라서 레이어가 달라진다고 생각하면 됨
• 포트 패키지의 분리
  • UI 계층에서는 port은 in만 바라보도록
  • 클린아키텍처의 usecase → 내가 만들고자 하는 시스템을 사용하는 클라이언트가 그 시스템을 통해 하고자 하는 것을 말한다.
• 헥사고날에서는 entity를 다 분리해서 사용
  • JPA Entity와 도메인 Entity를 분리하면?
    • 연관관계 매핑, 즉시 로딩, 지연 로딩에 대한 고민이 줄엊들게 된다.
    • 핵심 비즈니스 로직에만 집중할 수 있게 된다.
  • 분리 안하면?
    • 왠만하면 JPA가 달라지지 않기 때문에
    • 그리고 객체를 나눠서 관리하게 되면 매핑이나 컨버팅, 역 컨버팅 처리를 다해줘야 한다.
  • JPA repo interface인데? 포트에 해당 할까?
    • PersistenceAdapter로 실질적 동작을 하게 된다.
  • Incoming port가 필수적인가?
    • imcomingport가 없어도 의존성의 방향은 고수준을 향하여 흐르고 있으니까?
    → 내부를 아는 것 보다 외부에서는 스펙만 알고 들어올 수 있도록 해주는게 좋다.
  • 접근 제한자
    • Default 접근 제한자를 평소에 얼마나 사용하는가?클래스가 디폴트 접근제한을 가지면 같은 패키지에서는 아무런 제한 없이 사용할 수 있지만 다른 패키지에서는 사용할 수 없도록 제한됨
    • 단일 집임점을 만들기 위해서 공통적인 요소만 퍼블릭으로 해주고 나머지는 다 제한을 걸어두는 방식으로 할수도 있다. 
• 결국 기능을 지지하는 구조가 중요하다.
  • 기능이 있는 건 당연하고 구조가 이를 뒷받침 해야 한다.
  • 구조에 의존하여 더 안정적이고 유지보수하기 좋은 애플리케이션을 만들자

CS와 함께하는 BE 이야기

개인적으로 듣고 도움이 될 거 같긴한데, 내가 이해를 할 수 있을까? 라고 생각했다가 가장 도움이 많이 되었던 강의 였습니다. 1학년 부터 3학년 1학기 까지는 Python 백엔드를 했지만 당시에 그저 Django나 Flask를 활용해서 개발만 할 줄 아는 감자였기 때문에 백엔드 지식은 있지만 이해도가 많이 떨어지는 상태였습니다. 지금은 또 프론트를 메인으로 하고 있기도 하고요.

초반에 강연자 분이 얘기해주신 내용은 강연을 들으러 오신 분들이 대부분 대학생, 취준생 이었기 때문에 그를 위한 내용이 었습니다. "네카라쿠배나 대기업은 CS를 빡세게 묻는 다면서요?",  "작년이랑 올해 코테, 면접 보니까 중고신입만 뽑는 거 아닐까요?" 라는 질문을 자주 받으셨다고 합니다. 이 중 공통 적인 내용이 바로 CS에 대한 부분인 것 같았습니다. 강연자 분은 이 부분에 대해서 신입 개발자 분들과의 회사 내 대화 세션에 대한 예시를 말해주시면서 이렇게 얘기해주셨습니다.

"이제는 단순히 프로그램을 만드는 게 아니라 잘 만들어야 된다. 전에는 어떤 기능을 만들어보는데 집중했다면, 이제는 성능최적화라는 것에 신경써야 되고 결국 기반이 되는 게 CS일 수 밖에 없다. 

위의 내용을 들으면서 CS에 대한 기본 지식이 면접이나 취업 과정에서 개발자가 어떤 포텐셜을 가졌는지 평가하는 중요한 요소가 되는 이유를 이해할 수 있었던 것 같습니다. 

그 이후에는 CS를 기반으로 해서 BE의 여러 요소에 대해서 얘기를 해주셨습니다. 

예를 들어 토이 프로젝트를 할 때 백엔드 개발자에게 필요한 시작점은 서버의 성능을 어떻게 예측하고 개발할 것인가에서 시작합니다. 프로젝트를 간단하게 나눠보면 클라이언트 - 서버 - 데이터베이스 구조로 보통 이뤄져 있습니다. 여기서 우리는 한 명의 사용자가 아니라 여러 명의 사용자가 동시에 요청을 쏘는 것에 대해서 고려를 해야 합니다.

수 많은 서비스 들에서 이런 부분은 기본적인 것이지만 기본이기에 더 중요한 것 같습니다. 여기서 또 서버의 구조가 만약에 바뀐다면? 코드가 바뀔 것이고 그렇다면 그 동안에 작성한 코드는 어떻게 관리를 할 것인지 까지 이어집니다. 이런 부분에서 객체지향이나 디자인 패턴, 아키텍처와 같은 영역으로도 나갈 수 있는 것 같습니다. 그리고 만약 데이터 베이스 구조를 바꿔야 된다면 운영 중인데 어떻게 바꿀 것인지 그리고 기존의 데이터는 어떻게 처리를 할 것인지 까지 고민을 할 수 있어야 된다고 해주셨습니다. 

다음편에 이어서...