[인프콘 2024 후기] 강연 내용 정리 | 인프런 굿즈 | 다양한 이벤트

 

드디어 인프콘 2024에 다녀왔다!
세션에 대한 기억이 남아있을 때, 복습 겸 기록을 남겨본다.
이번 포스팅은 꽤나 길어질 것 같다.
참고로, 모든 세션들은 추후 인프런에서 녹화 영상을 볼 수 있다.
시간 관계상 관심있지만 듣지 못한 세션들은 영상으로 봐야겠다. 인프런 최고!

---

 

1. 발표 / 프로그램

이번 인프콘에서는 개발자 뿐만 아니라 PM/PO, AI, 디자이너, 데브옵스까지 즐길 수 있는 48개의 세션이 있었다.
평소 관심있었던 주제를 선정해서 시간표를 구성했다.
 
🚩내 시간표

 
 

1) 오프닝

인프랩 대표 이형주님, 인프랩 CTO 이동욱님(향로)이 인프랩의 미래와 비전에 대해 설명해주셨다.
단순히 국내에서 강의 제공하는 것을 넘어 글로벌 도약에 포커스를 두고 있었다.
인프랩은 교육을 통해 IT인들을 성장시키고 IT채용 플랫폼 랠릿으로 자신의 커리어를 관리할 수 있는 서비스를 제공하는 사업을 하고 있다. 인프런만 이용하다보니 인강만 제공하는 줄 알았는데 이번 인프콘 오프닝을 통해 인프랩에 대해 더 이해할 수 있었다.
 

인프런, IT 축제 ‘인프콘 2024’ 2천여 명 참석  | 중앙일보

인프콘 2024 오프닝 세션에 대한 내용을 요약한 기사도 있다.
8:1 경쟁률이었다니, 인프콘 2024에 참석할 수 있었던 것에 다시 한 번 감사해진다..
 

2) 지속 성장 가능한 설계를 만들어가는 방법

팀프로젝트, 개인프로젝트를 하면서 설계를 할 때마다 설계가 참 어렵다는 걸 매번 느꼈다.
그래서 이 세션을 선택했다.
이 세션을 한 줄 요약해보면 '설계를 잘하는 방법은 설계를 하지 않는 것이다.' 였다.
강연자가 이 말을 하자마자 모두 표정에 물음표를 띄웠다.
나도 마찬가지 였지만 강의를 다 듣고나서 이 말이 이해가 갔다.
 
보통 프로젝트를 진행할 때, 분석 ➡️ 설계 ➡️ 구현으로 진행한다.

개념을 잡고 격벽을 세워 구현하고 Test code로 증명하고 피드백을 받아서 다시 코드를 구현하는 과정이 곧 설계다.
격벽이 생소한 개념인데, 개념(키워드)의 흐름을 제어하는 벽이다. 
격벽을 통해 무분별한 참조가 아닌 필요한 참조만 할 수 있도록한다.
따라서, 개념에 변경이 일어날 때 변경한 개념과 관련된 코드만 수정될 수 있다.
 
예를 들어, 대출 프로세스를 구현한다고 해보자.

신청, 실행, 대출, 상환등이 개념이다. 개념의 흐름을 화살표로 표현했다.
개념의 흐름 사이에 격벽을 세워서, 흐름을 제어한다.
마치 방화벽처럼 허가된 것만 받아들이는 격벽을 세우는 것이다.
상환 개념을 보면 다른 개념들에 비해 파생되는 개념의 볼륨이 크다.
이런 경우, 개념을 따로 분리 해야한다.
개념끼리 같은 수준의 개념인지 봐야한다. 그렇게 해서 개념간의 의존도를 낮춰야한다.
 
이렇게 개념을 잡고 격벽을 세우고 구현을 하고 테스트 코드를 짜고 해결해나가며 코드를 완성해나가는 것이 포인트다.
 
그리고 중요한 것! 모니터링, 테스팅과 같이 개념이 없는 곳은 모듈을 분리해야한다.

커머스 결제시스템 예시에서 보여준 디렉토리 구조다.
외부 연동사 또한 개념이 없는 곳이기 때문에 product-provider로 분리를 해주었다.
 
개발자가 지녀야 할 마음가짐에 대해서 얘기해주셨는데 꽤 공감갔다.
✔️요구사항은 계속 변한다는 걸 인정하자
✔️ 완벽한 설계란 없다.
✔️ Sofeware는 soft해야한다.
✔️ 설계는 필요한 만큼만 하자.
✔️ 요구사항이 완벽해야 설계가 가능하다고 하지말자.
✔️ 설계해봐야 개발 일정이 나온다고 하지말자.
✔️ 우리 설계에선 그 개발 못한다고 하지말자.
 
⭐강연자 토스페이먼츠 김재민님의 유튜브 링크

제미니의 개발실무

 
 
 

3) 인프런 아키텍처 2024 ~ 2025

이번 세션에서는 주로 레거시 개편에 대해 다뤘다.
인프런은 글로벌로 진출할 준비를 하고 있는데 환율도 오르고 무료 강의 컨텐츠를 제공해야하는 상황에서 트래픽 비용을 줄여야 했다.
 
1️⃣비효율적인 트래픽 비용 지출을 줄인 방법
✔️이미지 트래픽 최적화

인프런 홈페이지는 이미지 조회가 잦은 편이다. 그래서 이미지 트래픽 관리를 해야하는데 그동안 리사이징과 캐시로 이미지 트래픽을 최적화해왔다.
하지만, 이것 마저도 부족했다.

고품질, 저용량의 avif 파일로 포맷을 변환하여 이미지 트래픽비용이 60% 감소되었다고 한다.
avif 포맷을 이번 세션에서 처음 알게 됐다.
 
⭐avif란?
AV1 비디오 코덱을 활용하여 이미지 압축을 수행하는 이미지 포맷이다.
JPEG나 PNG에 비해 훨씬 작은 파일 크기를 제공한다.
압축 효율이 높아 파일 크기가 작아도 이미지 품질을 유지할 수 있다.
고품질 이미지를 작은 파일 크기로 제공하여 웹성능을 크게 향상 시킬 수 있는 이미지 포맷이다.

과거에는 AVIF 포맷을 지원하는 브라우저가 많지 않았지만, 현재는 Chrome, Edge, Safari, FireFox등에서도 지원하고 있어서 브라우저 호환성에 대한 걱정을 덜 수 있다.
 
✔️JSON 데이터, 트래픽 비용 개선

 
빨간 박스에 있는 카테고리가 JSON 데이터로 가져와서 뿌려주는 건데, 페이지를 이동할 때마다 카테고리를 보여줘야하기 때문에 여기서도 만만치 않은 트래픽 비용이 발생한다고 한다. 무려 하루에 150GB!
변경 가능성이 있기 때문에 DB에 접근해서 불러오는 방식이었다.

하지만 변경 가능성이 있긴해도 자주 변경이 일어나는 부분이 아니고 동일 API를 호출하니 여기서 트래픽 비용이 하루에 150GB나 나가는 것이 비효율적이라고 볼 수 있다.
 
카테고리같은 JSON 데이터는 자주 액세스하기 때문에 캐시로 해결할 수 있다.
로컬 캐시를 구현하면 불필요한 DB 접근을 줄일 수 있다.
하지만 EC2 트래픽은 여전히 발생한다.
 
이것을 CDN 계층 캐시로 해결할 수 있다.
CDN 계층 캐시는 지리적으로 분산된 엣지 서버와 오리진 캐시 서버를 통해 효율적으로 콘텐츠를 제공할 수 있는 캐시 방식이다.
사용자가 GET요청을 하면 가장 가까운 CDN 엣지 서버로 요청이 전달되고 엣지 서버에 캐시된 것이 있으면 바로 사용자에게 전달된다. 엣지 캐시에 콘텐츠가 없으면 오리진 캐시 서버에서 캐시된 것을 전달한다. 오리진 캐시 서버에도 없으면 최종적으로 원본 서버(EC2 인스턴스)로 요청이 전달된다.
이렇게 EC2 트래픽을 줄일 수 있다.
 
변경이 되긴하지만 변경이 자주 일어나는 콘텐츠가 아니기 때문에 CDN 계층 캐시를 할 수 있었고 트래픽 비용이 70% 정도 감소되었다고 한다.
 
CDN 계층 캐시를 사용할 때 주의해야 할 점이 있다.
cache-control 헤더에 세션 쿠키가 포함되지 않도록 해야한다.
세션 쿠키를 캐시에 저장하고 응답에 포함시키게 되면 사용자 간 세션 공유가 일어나 다른 사용자의 정보를 보게 되는 불상사가 일어날 수 있다.
 
2️⃣API 환경 개선
인프런은 기존에 express를 사용했었는데 Next.js로 전환을 하고 있다.
Next.js는 API 프록시 서버 역할과 페이지 렌더링을 한다.
그런데 내부 중요 API를 외부에서 호출할 수도 있다는 문제가 있었다.
외부에서 내부 중요 API에 접근할 수 없도록 외부용, 내부용 코드를 분리하면 그만큼 인프라가 2배가 된다.
내,외부 모두 세션 체크를 한다면 인프라에 부하가 오고 코드 복잡도가 증가한다.
그래서 프론트에서 호출할 때, API path가 따로 붙도록 설정해서 이 문제를 해결했다.
 
3️⃣라우트 개선
인프런은 Reverse Proxy로 Nginx 대신 traefik을 사용한다.
트래픽을 받고 규칙에 따라 서비스를 연결해주는 역할을 한다.

⭐traefik 특징
- Go언어 기반
- 구성 파일이  변경 되어도 서버를 재시작 할 필요가 없다 
- 설정을 실시간으로 감지하고 적용할 수 있기때문에 라우트 제약이 없다.
 
인프런 개발팀은 일반 사용자는 레거시로 연결되도록 하고 개발자가 테스트를 할 때는 next.js로 연결되도록 인프라를 구축했다.
인프런 데브옵스팀은 Go언어를 메인으로 사용한다고 한다.
 
레거시를 개선해나가는 시행착오에 대해 들으니 시간 가는 줄 모르게 집중해서 들었다.
나중에 회사에서 레거시를 개선해야하는 상황이 온다면 이 세션을 들었던 순간이 떠오를 것 같다.

향로님과 한컷 찍었다. ( 피곤하셨을 텐데 같이 사진찍어주신 향로님 감사합니다.)
 
 
 

4) ProxySQL을 활용하여 데이터 베이스에서 대용량 트래픽 처리하기

12시 20분 ~ 13시 40분까지 이어지는 80분짜리 딥다이브 세션이라 샌드위치를 받았다. 인프콘 최고다..
 
이번 세션에서 RDBMS 운영 환경에서, 대용량 트래픽이 발생할 때, 어떻게 부하 분산을 할 수 있는 지 배울 수 있었다.
프로젝트 아키텍처에서 중요한 것은 안정성, 가용성이다.
트래픽이 몰려도 중단없는 서비스를 제공해야한다.
이를 위해, 복제 또는 샤딩으로 데이터를 관리한다.
 
✔️복제란?
일반적으로 많이 사용하는 방식이다.
데이터베이스의 데이터를 동일한 다른 데이터베이스로 복사하는 것을 의미한다.
일반적으로 마스터-슬레이브 구조로 구현된다.
마스터 데이터베이스는 쓰기 작업을 처리하고, 슬레이브 데이터베이스는 읽기 작업을 처리한다.
 
장점 

• 하나의 DB에서 장애가 발생해도 다른 복제본을 통해 서비스를 제공할 수 있다.
• 데이터를 여러 곳에 저장하여 데이터 손실 위험을 줄일 수 있다.

 
단점

• 데이터가 모든 복제본에 즉시 동기화가 되지 않으면 데이터가 일관적이지 않을 수 있다.
• 슬레이브 데이터베이스에서는 읽기 작업만 처리하기 때문에 쓰기 작업이 집중되면 성능 저하가 생길 수 있다.

 
✔️ 샤딩이란?
데이터베이스를 여러 개의 작은 데이터베이스로 분할하는 것이다.
각 샤드는 독립적으로 데이터를 저장하고 관리한다.
 
장점

• 데이터를 분산시켜 성능을 향상 시킬 수 있다. 
• 필요에 따라 샤드를 추가할 수 있어서 시스템 수평 확장이 가능하다.

 
단점

• 각 샤드마다 다른 데이터를 저장하고 있기때문에 샤드하나가 날아가게 되면 데이터 손실이 발생할 수 있다.

복제와 샤딩 모두 커넥션 풀을 애플리케이션 코드로 직접 관리해야한다.
(*커넥션 풀이란, 데이터베이스 연결을 미리 생성해 두고 필요할 때마다 재사용하는 것.)
커넥션 수가 대폭 증가하면 네트워크 장비의 세션 테이블에 오버헤드가 발생할 수 있다.
 

✔️ProxySQL이란?

MySQL과 MariaDB를 위한 고성능 SQL 프록시 서버.
데이터베이스 성능과 가용성을 향상시킬 수 있는 도구다.
 
🤔프록시 서버가 없는 경우

데이터베이스에 대한 읽기, 쓰기 작업을 분리하기 위해 write IP와 Read IP를 설정해줘야한다.
그래서 상황 변동에 따라 수동으로 IP를 변경해줘야한다.
 
🤓ProxySQL 사용하는 경우

- 프록시 서버가 있으면, 프록시 서버에만 연결을 설정하면 된다.
프록시 서버가 내부적으로 읽기, 쓰기 작업을 적절한 데이터베이스 서버로 라우팅한다.
로드 밸런싱을 통해 여러 데이터베이스 간의 트래픽을 고르게 분배할 수 있다. 
 
- ProxySQL은 데이터베이스 정보와 설정을 별도 config파일에 저장하지 않는다.
설정을 실시간으로 변경하고 적용할 수 있어서 서비스 중단 없이 구성 변경이 가능하고 설정을 쉽게 수정할 수 있어서 유연하게 관리할 수 있다.
또한, config파일에 데이터베이스 정보를 포함하지 않아도 돼서 보안 측면에서 조금 더 유리한 면이 있다.
 
✔️ProxySQL 클러스터 구성
모든 트래픽을 단일 프록시 서버를 통해 처리하면, 서버에 장애가 발생했을 때 전체 시스템이 중단될 수 있다.
여러 ProxySQL 인스턴스를 클러스터로 구성하면, 장애가 발생했을 때 자동으로 장애를 감지하고 다른 인스턴스로 트래픽을 라우팅하여 서비스 중단을 최소화 할 수 있다.
 
✔️ 오케스트레이터와 ProxySQL 조합
MySQL Galera Cluster는 다중 마스터 구성의 MySQL 데이터베이스 클러스터링 솔루션이다.
모든 노드가 동시에 쓰기 작업을 수행할 수 있고, 데이터가 모든 노드에 실시간으로 동기화된다.
MySQL Galera Cluster와 ProxySQL을 조합하면 효과적으로 데이터 베이스 클러스터의 부하 분산과 고가용성을 관리할 수 있다. ProxySQL은 노드 상태를 모니터링하고 자동으로 페일 오버를 한다.
(*페일 오버 : 시스템에 장애가 발생했을 때, 자동으로 백업 시스템이나 대체 시스템으로 전환하여 서비스를 유지하는 것)
 
✔️GTID
GTID(Global Transaction Identifier)는 MySQL 5.6이상에서 도입된 기능이다.
각 트랜잭션에 고유한 ID를 부여하여 데이터베이스 클러스터의 트랜잭션을 추적하고 관리하는 데 사용된다.
GTID를 통한 효율적인 트랜잭션 관리가 대규모 분산 데이터베이스 시스템에 유용하니 알아둬야 하는 개념이다.
 
 
 

💡Q&A

(정확히 기억나지 않아서 제 방식으로 정리했습니다. 실제 답변과 약간 다를 수 있습니다.)
1. 질문자의 회사에서는 읽기 작업(SELECT 쿼리)을 slave DB로 보내고 읽을 데이터가 없는 경우 master DB로 가게한다.
proxySQL로는 어떻게 라우팅을 해야하는 가?
-> 답변 : proxy를 하나 더 두면 된다.
첫 번째 proxy는 모든 읽기 요청을 slave DB로 라우팅한다. slave DB가 응답하지 않는 경우 두번째 proxy로 요청을 전달한다. 
두 번째 proxy는 전달받은 요청을 master DB로 라우팅한다.
 
2. 커넥션 풀 갯수 설정 기준은?
-> 답변 : Max로 설정하고 모니터링하면서 줄여나가야한다. CPU, 메모리, 요청 개수에 따라 적절한 커넥션 풀 개수가 다르다.
 
3. MySQL , PostgreSQL 차이 
-> 답변 : MySQL은 주로 OLTP 시스템에서 많이 사용한다. OLTP 시스템은 주로 거래 지향 애플리케이션에서 사용된다.
MySQL은 싱글 스레드에서 작동한다. (한 번에 하나의 트랜잭션 처리) 트랜잭션을 하나씩 순차적으로 처리하여 데이터 일관성을 유지하는 것이 마스터-슬레이브 복제 환경에서 중요한 역할을 한다.
 
PostgreSQL은 다중 스레드를 활용하여 여러 CPU 코어를 사용할 수 있다. 여러 쿼리를 동시에 병렬 실행 할 수 있다.
이를 통해 대규모 데이터를 더 빠르게 처리 할 수 있다. MySQL도 옵티마이저가 있지만 PostgreSQL의 옵티마이저는 보다 복잡한 쿼리를 처리하는데 강점을 가진다. ( 다양한 조인 전략 중 가장 효율적인 전략 선택, 병렬처리, JSONB, 배열등 고급 데이터 타입 지원)
 
 

5) 멀티패러다임 프로그래밍 언어의 시대: 객체지향과 함수형을 섞어야할 때!

이번 세션에서는 Typescript로 객체지향, 함수형 프로그래밍을 섞어서 라이브 코딩을 하는 방식으로 진행되었다.
Typescript 문법을 모르고 보니 이해가 안가는 부분이 있었고 왜 객체지향과 함수형 프로그래밍을 섞어야하는지 크게 와닿지 않아서 아쉬웠다.
 
🚩라이브 코딩 내용 요약

• HTML 코드를 자동 생성
• XSS 해킹을 방지하기 위해 사용자 입력을 escape 하기
• escape 될 것과 escape 되지 말아야할 것을 구분하기

객체지향, 함수형 프로그래밍을 함께 사용하여 문제를 해결해나가는 과정을 볼 수 있었다.
 
 

6) 클린 스프링: 스프링 개발자를 위한 클린코드 전략

프로그래밍을 할 때, 빠른 기능 구현이 중요한가? 유지보수성을 높이는 클린 코드를 추구해야 하는 것인가?
개발을 하다보면 이런 고민에 빠질 때가 있다.
일정을 맞추기 위해 빨리 기능 구현을 해야하는 데, 비효율적인 것이 눈에 보여서 효율적으로 리팩토링 하고 싶지만 리팩토링을 하면 일정을 맞추기 힘들 수 있다. 그런데 코드를 이대로 두면 유지보수성이 떨어질 것 같다. 어떻게 해야할 까?
 
이런 고민에 대한 어느정도 해답을 얻을 수 있는 세션이었다.
 
✔️유지보수성과 생산성

개발을 할 때, 유지보수성과 생산성 둘 중 하나를 택해야 하는 것이 아니다.
유지보수성과 생산성은 상반되는 개념이 아니라 서로 영향을 주는 관계다.
 
하지만, 처음부터 완벽하게 클린 코드를 작성해서 유지보수성을 높이고 생산성을 높이자는 것이 아니다.
현재 이해를 바탕으로 빠르게 구현해서 출시하고 이후 리팩토링을 하는 것이다.
(빠르게 출시한다고 해서 대충 코드를 작성하라는 것이 아니라 처음부터 리팩토링하기 좋은 코드로 작성해야한다는 것에 유념해야한다.)
 
✔️시작하는 법
익숙한 기술로 핵심 기능을 가장 단순한 코드로 동작하도록 작성해야한다.
일부 기능을 완벽하게 만드는 것으로 시작하는 것이 아니라 일단 핵심 기능을 동작하도록 하는 것이 중요하다.
 
✔️테스트 코드
테스트 코드를 작성하면 구현 속도가 느리다?
기능 구현하기도 바쁜데 테스트 코드를 작성하면 언제 또 기능 구현하냐고들 한다.

토비님 프레젠테이션 그래프 재구성 해봄.

(x축과 y축 기준이 시간, 구현에 걸리는 시간이 맞는지 기억이 안나지만 맥락은 비슷함)
테스트 코드를 작성하는 프로젝트와 테스트 코드를 작성하지 않는 프로젝트는 시간이 지날수록 구현속도에 차이가 벌어진다. 테스트 코드를 작성하면 개발 초기에는 no test보다 개발에 시간이 더 걸린다. 이 지점이 테스트 코드를 작성하느냐 마느냐의 갈등 지점이다. 그래서 테스트를 빠르고 효과적으로 작성하는 능력이 필요하다. 갈등 지점을 좁힐 수 있도록 테스트 코드를 많이 작성해봐야한다.
 
✔️기준
클린코드에 대한 기준은 상황에 따라 달라진다.
나만을 위한 클린코드는 없다.
개발은 나혼자 하는 것이 아니다.
유지보수성, 생산성 사이에는 팀워크가 있다.
함께 결정하고, 함께 학습하고, 함께 성장하는 방향으로 가야한다.
 
✔️헥사고날 아키텍처

파워포인트로 한땀 한땀 그렸다.

토비님이 클린 스프링을 실현하기 위해 중요한 포인트를 알려주셨다.

• 단일 책임 지키기
• 변경에 유연한 코드만들기(의존성 낮게)
• 구성 정보 클린하게 관리하기(좋다는 거 이것저것 붙이다 보면 나중에 알아보기 어렵고 기능이 엉킬 수 있기 때문)
• 헥사고날 아키텍처 패턴 사용하기

헥사고날 아키텍처란 소프트웨어 시스템을 도메인, 포트, 어댑터로 분리하여 설계하는 것을 말한다.
이 아키텍처는 시스템을 모듈화하여 코드의 유지보수성을 향상시킨다.
또한, 각 구성 요소를 독립적으로 테스트할 수 있어서 테스트에 용이하다.

 
✔️DB테스트에 @Transactional을 사용하자
@Transactional의 테스트 사용에 대해 향로님과 토비님의 의견이 다르다.
 
⬇️ 향로님 포스팅

테스트 데이터 초기화에 @Transactional 사용하는 것에 대한 생각

향로님은 @Transactional에 반대하는 입장이시다.
 
포스팅의 중요한 부분을 요약해보자면, 
향로님은 @Transactional을 테스트 데이터 초기화 용도로 사용할 때 발생할 수 있는 문제점이 있다고 했다.
@Transactional 테스트를 사용하지 않는 이유는 트랜잭션 관련 기능의 정확한 검증이 어렵고 데이터 초기화 문제, 테스트 환경과 실제 환경 불일치로 일어나는 문제가 있기 때문이다.
이런 문제들을 명시적 초기화 메서드를 사용해서 테스트 데이터를 초기화하여 해결한다.
 
 
⬇️ 토비님 포스팅

테스트가 관리하는 트랜잭션 - 향로 님의 @Transactional 글을 읽고

토비님은 @Transactional을 사용하자는 입장이시다.
 
포스팅의 중요한 부분을 요약해보면, 
'@Transactional 롤백 테스트'를 테스트를 실행하고 롤백한다는 개념만 알면 안된다.
테스트 트랜잭션 외에 별개의 트랜잭션이 만들어질 때, 트랜잭션 경계설정 위치로 인해 JPA엔티티 매니저 생명주기가 연장되어 테스트 결과가 거짓 음성으로 나올 때에 주의해야한다.
 
테이블 초기화 방식으로 테스트를 하면, 테스트 성능 저하나 FK 제약 조건 제거와 같은 부작용이 있을 수 있다.
@Transactional을 사용할 때 특정 상황에 추가적인 주의가 필요하다는 것을 알고 잘 사용하면 @Transactional 은  테스트를 단순하고 빠르며 효율적으로 작성할 수 있게 해준다.
 
 
 

7) 객체지향은 여전히 유용한가?

마지막 세션이다. 벌써 마지막 세션이라니 아쉬웠다.
 
그동안 Java나 스프링을 학습할 때, 매번 객체지향 프로그래밍이 중요하다고 배웠었다.
객체지향 설계가 절차적인 설계보다 재사용성과 유지보수성이 좋으니 객체지향 설계가 효율적인 것, 절차적인 설계가 비효율적인 것이라고 생각했었다.
 
💡이번 세션의 포인트는 '객체지향 설계가 여전히 유용한가?' 보다 '객체지향이 언제 유용한가?'가 중요하다는 것이다.
모든 설계에는 용도가 있고 각각 장점과 약점이 있다.
그렇기 때문에 코드의 목적, 변경의 방향성에 따라 적합한 설계 방식을 선택하는 것이 중요하다.

 
✔️객체지향 설계
규칙 기반 상태 변경, 행동 중심일 때는 객체지향 설계로 일관성 있는 설계를 할 수 있다.
인터페이스를 갈아끼우면 되기 때문에 타입 확장에 유리하다.
 
✔️절차지향 설계
새로운 기능 추가가 쉽고, 데이터 처리에 적합하다.
 
🤓우리는 객체지향 설계와 절차지향 설계를 섞어 사용하고 있었다.
주로 애플리케이션을 설계할 때, Domain Layer, Presentation Layer , Service Layer , Persistence Layer로 나눈다.
 

• Domain Layer  : 비즈니스 로직과 규칙을 포함하는 부분이다.
• Presentation Layer  : 사용자 인터페이스와 상호작용하는 부분이다. 데이터가 노출되는 곳이다.  
• Service Layer  : 애플리케이션의 비즈니스 로직을 처리하고 프레젠테이션 레이어와 도메인 레이어 간의 상호작용을 관리한다.
• Persistence Layer : 데이터베이스와의 상호작용을 처리한다.

 
 
도메인 레이어는 객체지향적으로 설계하여 비즈니스 로직을 캡슐화하고 추상화하며, 상속과 다형성을 통해 유연성과 재사용성을 높인다.
프레젠테이션 레이어, 서비스 레이어, 퍼시스턴스 레이어는 절차적 설계를 사용하여 단순하고 명확한 절차에 따라 데이터를 처리하고 전달한다.
 
 
세션을 들으며, 이전 회사에서 '스프링부트를 사용한다는 것이 반드시 객체지향적인 프로그래밍을 한다는 것을 의미하는 것일까?' 의문을 품었던 게 떠올랐다.
막 개발을 배우고 운좋게 들어갔던 회사였는데, 개발하고 있는 코드들이 객체지향적인 것인지 절차지향적인 것인지 궁금했었다. 당시에는 설계 방식이 섞일 수 있다는 것을 인지하지 못했었다.
스프링부트는 객체지향 프로그래밍을 쉽게 적용할 수 있는 도구일 뿐이지, 어떤 패러다임으로 프로그래밍을 하는지는 개발자의 설계와 구현에 달려있다.
 
💡이번 세션을 듣고 다짐한 것들

• 맹목적으로 설계 방식 트랜드를 좇는 것에 주의하자.
• 설계 방식을 떠나서 프로젝트에 어떤 것을 도입하든 도입을 하는데에 타당한 이유가 있는지 고민하는 자세를 가지자.
• 항상 스스로 질문을 던지는 습관을 가지자. 

 

2. 행사

다양한 세션뿐 아니라 여러 이벤트가 있었다.

• 기업 부스에서 프로그램을 체험하고 스탬프를 모아서 한정판 굿즈 받기
• 현직자, 인프콘 참여자들과 네트워킹 파티
• 라이트닝 토크
• 인생 세컷

쉬는 시간을 활용해서 스탬프를 모으기 위해, 기업 부스에 줄을 서고 네트워킹 파티 사전등록하는 등 바쁘게 움직였다.
줄이 엄청 긴 것은 아니었지만, 다양한 이벤트에 참여하기에는 쉬는 시간이 짧게 느껴졌다..
그래서 하루가 굉장히 빨리 흘러갔던 것 같다.
점심에 샌드위치를 받았지만, 강연을 듣는 중에는 먹지 못했고 코엑스에 샌드위치를 먹을 장소가 마땅치 않아서 점심을 걸렀다.
 
라이트닝 토크는 인프콘 참여자가 발표 자료를 미리 준비해서 현장에서 발표를 하는 컨텐츠였다.
다른 세션을 듣느라 아쉽게도 라이트닝 토크는 듣지 못했다.
 
인프콘이 추첨으로 가는 건데 친구끼리 온 사람들이 꽤 많았다.
혼자서 인생세컷도 야무지게 찍었다.
 

 
 

3. 인프콘 굿즈

14:40부터 굿즈 소진시까지 인프콘 굿즈를 받을 수 있었다.
세션을 다 듣고 서둘러 굿즈 수령 장소로 갔는데 줄이 어마어마 했다.
이걸 다 기다려서 굿즈를 받아야 되나, 말아야 되나 한참 고민했다.
그치만 언제 또 올지 모르는 소중한 인프콘이니 어떤 굿즈여도 감사히 간직해야겠단 마음으로 기다렸다.
(사실 이전 인프콘 굿즈가 뭔지 검색하며 기다렸다.)
내년 인프콘 2025에서는 다른 굿즈겠지만, 나처럼 검색할 사람들을 위해 어떤 굿즈를 받았는지 후기를 남겨본다.

 
⭐인프콘 2024 굿즈 
티셔츠, 강의 30% 할인권, 양말, 컵
 
- 티셔츠 가슴팍에 INFCON 2024라고 글자가 프린팅 되어있고 등판에는 인프런의 슬로건?
Learn, Share, Grow가 그려져있다. 포스팅을 하는 지금도 티셔츠를 입고 있다.
재질이 꽤 좋아서 오래 입을 수 있을 것 같다.
 
- 귀여운 인프런 캐릭터가 그려진 양말..귀엽다. 맘에 든다.
 
- 강의 30% 할인권은 강의 하나에만 적용되는 할인 쿠폰이다. 
(장바구니에 한번에 담아놓고 결제해야겠다 생각했다면 오산이다.)
 
- 컵 크기가 꽤 적당하고 프린팅이 귀여워서 요즘 내 전용 물컵으로 사용하고 있다.
 

4. 느낀점

인프콘 2024에 참석할 수 있게 됐다는 메일을 받았을 때 설레고 기뻤었는데, 벌써 인프콘2024가 끝나고 후기를 작성하고 있다니 신기하다. 이번 인프콘을 통해 여러 강연자 분들의 강연을 듣고 공부 동력을 얻을 수 있었다. 
공부의 방향성을 잡게 되었고 개발자로서 가져야 할 마음가짐을 다시 한번 되새겼다.
효율적인 프로그래밍과 좋은 서비스를 제공하기 위한, 여러가지 도구들과 기술들의 존재와 쓰임새를 알게 됐다.
원래 알던 것을 딥하게 공부하는 것이 좋지만 새로운 것을 알게 되는 것이 꽤 짜릿한 일이다.
내년에도 인프콘이 열린다면, 다시 한 번 꼭 참석하고 싶다.