인프콘 2024 정리

올해 진행되었던 인프콘 2024 중 일부 세션에 대해 간략히 정리해 보았습니다.

 

https://www.inflearn.com/course/%EC%9D%B8%ED%94%84%EC%BD%982024-%EB%8B%A4%EC%8B%9C%EB%B3%B4%EA%B8%B0

[지금 무료] 인프콘 2024 다시보기 강의 | 인프런 - 인프런

 

트랙 1

실리콘밸리 개발 문화 및 서바이벌 전략 - 이승준

핵심 5가지

• 자기 PR, 새로운 기술 트렌드 습득, 네트워킹, 협업 능력, 창의성과 문제 해결 능력

자기 PR

기술 트렌드 습득

네트워킹

협업 능력

창의성과 문제 해결 능력

 

위의 핵심 내용들은 모든 사람에게 공통적으로 중요한 요소인 것 같고, 다음으로 반드시 갖춰야 할 것들에 대해 소개합니다.

• English: 대부분의 기술은 영어로 기록됩니다. 최신 기술을 빠르게 배우기 위해 영어로 학습하는 것이 중요합니다.
• Work experience: 책이나 부트캠프에서 얻을 수 없는 실무 경험을 중요하게 생각하세요.
• Linux: 대부분의 서버는 리눅스 기반입니다. 도구의 환경설정 보다는 중요한 일에 시간을 투자하세요.
• 멀리 가고 싶다면, 운동하시는 것을 잊지 마세요.
• 도전을 포기하지 마세요, "포기하지 않으면 실패는 없다."

 

경력이 늘수록 CS이론이 중요해지는 이유 - 최호성

기본기가 충실하면 좋은 점

• 새로운 프레임워크가 놀랍지 않음 -> 다시 학습모드
• CS 근본은 여전히 변함없음 -> 원리와 별개로 표면 현상을 암기
• 상대적으로 환경전환이 매우 수월함

• 컴파일러 공부 -> 프로그래밍 언어의 근본에 눈뜨게 된다. (식견이 넓어진다..)
• 운영체제, 컴퓨터구조에 대한 이해도는 장애 처리 능력이 높아진다.

 

결론 -> (필수) CS 공부를 하지 않으면 결국 개발자로 살아가는 동안 후회

• 모든 개발자에게 CS 이론은 중요 (성능, 장애대응, 설계 등)
• 최초 나는 왜 개발자가 된 것인지 다시 생각해볼 것
• 분야에 따른 차등을 인정하더라도, 최소한의 지식은 필수

결론 -> (선택) 목표에 대해 진지하게 다시 생각해볼 것

• 애초에 나는 어떤 이유로 개발자가 되려는 것인지 스스로에게 질문
• 앞으로 얼마나 오랫동안 개발자로 살아갈 것인가?
• 다양한 분야에 대해 알아가고 자기 분야에 대한 '독보적' 전문성 확보

 

객체지향은 여전히 유용한가? - 조영호

장바구니에 할인 프로모션 적용 - 절차적인 설계 vs 객체지향 설계

 

절차적인 설계

 

객체지향 설계

 

데이터 변경

• 요구사항이 변경될 때 두 가지 방식이 어떻게 변경되는지에 따라 선택해야 한다.
• 할인 여부를 판단하는데 사용하는 데이터를 변경한다면?

 

절차적인 설계 vs 객체지향 설계

• 절차적인 설계는 데이터와 데이터를 사용하는 프로세스가 별도 클래스에 구현되어 있기에 데이터 변경 시 관련 프로세스도 함께 변경된다 -> 결합도가 높다.
• 객체지향 설계는 데이터와 데이터를 사용하는 로직을 한 곳에 모아두기 때문에 (캡슐화) 요구사항 변경 시 Promotion 클래스만 변경하면 된다 -> 결합도가 낮다.

결론은? 데이터가 변경될 때는 절차적 설계보다 객체지향 설계가 더 유용하다.

타입 추가

• 장바구니 총 수량을 기준으로 할인 여부를 판단하는 새로운 타입을 추가한다면?

 

절차적인 설계 vs 객체지향 설계

• 절차적인 설계는 데이터에 타입을 추가하더라도, 데이터를 구현하는 Promotion 클래스, Process 클래스가 함께 변경
• 객체지향 설계에는 다형성을 적용한다 -> 인터페이스 및 구현체 추가 (DiscountCondition ... Price & Quantity)
• 객체지향 설계에서는 어떤 로직을 처리하려고 할 때, 그 로직에 사용되는 데이터들이 적합한 클래스로 분배되고, 분산된다.
• 객체지향 설계는 굉장히 큰 리팩터링이 필요하고, 절차적인 설계는 국소적인 리팩터링이 필요한데 무엇이 좋은가?

 

• 가격 수량이 아닌 날짜 기반으로 변경된다면? 기존 코드 수정 없이 새로운 클래스만 추가하면 된다.
• 객체지향의 강점: 어떤 로직을 확장하거나 시스템의 기능을 확장하려고 할 때 기존 코드를 수정하지 않고, 새로운 클래스를 추가하여 확장할 수 있는 여지가 생긴다.
• 할인 조건을 지속적으로 확장이 가능하다.
• 설계가 발전하고, 진화할수록 동일한 구조로 일관성을 유지하며 코드 크기를 늘릴 수 있는 것이 객체지향의 가장 큰 장점
• 절차적인 설계는 이러한 규칙을 강제하기가 어렵다, 왜냐면 내부 로직을 수정해야 하고, 사람에 따라 구현 방식이 달라지기 때문에 일관된 구조를 강제하기가 어렵다.

 

• 객체지향 설계에는 타입이 확장되는 것에는 유리하지만, 새로운 오퍼레이션이 추가되면 전체적으로 수정이 필요하다.
• 따라서 현재 변경하고 있는 것들이 타입 확장이 많은지, 기능이 추가되는 경우가 많은지?를 판단해보자.

 

• 다루는 것이 데이터라면, 절차적인 설계가 더 적합할 수 있다.
• 행동 중심, 행위 기반의 로직을 처리한다면, 객체지향 설계가 더 적합할 수 있다.

 

레이어

• 도메인 레이어의 가장 큰 목적은 시스템의 상태를 바꾸는 것이고, 이때 특별한 규칙(요구사항)이 발생 -> 객체지향 설계

 

• 프리젠테이션 레이어는 외부의 불확실한 데이터를 변환, 처리, 반환하는 것 -> 절차적인 설계

 

• 서비스 레이어는 특정 알고리즘에 따라 수행되어야 할 작업을 정의하는 규칙 -> 절차적인 설계

 

• 퍼시스턴스 레이어도 데이터를 반환하는 절차적인 설계

 

객체지향은 여전히 유용한가요? (X), 객체지향은 언제 유용한가요? (O)

• 우리는 이미 다양한 기술과 패러다임을 상황에 맞게 응용하고 활용하여 코드를 작성하고 있다.
• 객체지향이 유용하지 않다고 느껴지는 이유는, 현재 작업하는 영역이 데이터를 처리하거나 룰이 급격하게 변경되지 않는 경우가 많아서지, 룰이 복잡해지고 로직이 추가된다면 객체지향 설계가 더 적합하다.
• 코드의 목적과 변경의 방향성에 따라 언제, 어떤 기술을 사용할지 결정하라.

 

트랙 2 (디자인)

10년 동안의 실패 이야기: 실패를 의미있는 일로 탈바꿈하는 가장 쉬운 방법 - 강영화

자신의 실패에 대해 말해본 적이 있나요?

실패를 하려면 시도가 있어야 하고, 이를 통해 실패 -> 받아들임 -> 배우기 -> 다시 시도 등의 과정이 필요합니다.

 

작은 실패를 합시다. (잃어버려도 아쉽지 않을 정도의 실패)

• 직무 전환 -> 성과를 잘 어필하는 마인드셋을 갖추기 위해 리더와 적극적으로 소통했을 것 같습니다.
• 스스로 회고하고 팀과 함께, 고객의 피드백을 받아봅시다.

시도 할 때 도움이 되는 질문

• 실패를 미리 감지할 수 있는 문제가 있을까?
• 다른 방식으로 시도해볼 수 있나?
• 과정 중에 다른 사람을 참여시킬 수 없을까?
• 시도하는 태스크의 크기가 지나치게 크진 않나?

실패를 알아차릴 때 도움이 되는 질문

• 진행중에 문제는 없나?
• 지금 하고 있는 방식이 맘에 드는가?
• 내가 우선순위를 잘 매기고 있다고 생각하는가? 그 이유는?
• 여유가 있는가?

받아들이는 데 도움이 되는 질문

• 어떤 감정이 드는가? (부정적 / 긍정적으로)
• 다양한 시각으로 바라보고 있는가?
• 이야기를 재구성해서 내 이야기로 만들고 있는가?

배울점을 어떻게 찾을지 도와주는 질문

• 다른 사람을 참여시키고 있는가?
• 중요한 것을 짚고 있는가?
• 핵심은 내버려둔 채 변죽만 울리고 있지는 않는가?

다시 시도할 때 도움이 되는 질문

• 에너지가 있는가? (인지적, 신체적, 정서적으로)
• 도움을 받을 사람이 있는가?
• 다시 시도할 때 어떻게 다르게 해볼지 계획이 있는가?
• 이 계획이 맘에 드는가?

1. 실패를 들여다보기

• 실패가 모두 실패로 이루어져 있지 않고 성공도 마찬가지다. 성공과 실패는 섞여있다. 구분하고 구조화해서 살펴보기

2. 회고하기

• 회고를 하고 끝이 아니라, 조정하고 적용하면서 복리효과를 맛보기

3. 질문하기

• 그냥 일하는 게 아니라 계속 질문을 던지면서 일하기, 각 과정에 초점을 맞춰서 질문 해보자.

4. 용기를 내기

• 실패하고 받아들이는 과정은 용기가 필요한 일이다. 다른 것보다 스스로를 격려해주기

5. 함께하기

• 함께할 수 있다면 더 의미있고 효과적인 학습이 일어난다. 팀, 고객, 스스로와 함께

 

트랙 3

지속 성장 가능한 설계를 만들어가는 방법 - 김재민

설계를 잘하는 방법? 설계를 하지 않는 것이다...

서로 연관되어 있는 도메인들을 생각하다 보면, 이것도 맞고 저것도 맞는 것 같은 생각이 든다.

-> 랭킹은 웹툰만 아니라 작가에도 있는 개념이 아닌가? 

 

코드 레벨에서 결제, 포인트, 구매 도메인에 대해 살펴보자.

 

• Point 도메인 네이밍 변경이 되었을때, 변경사항이 생기는 개념들 (결제, 구매)

 

• 개념을 잘못 사용한 예시 (변경 범위가 많은경우)

 

커머스 사례

상품의 개념, 외부 연동사는 개념일까? (X)

• 개념은 우리가 만든 소프트웨어의 비즈니스를 지탱하는 것들을 위주로 분리해야 한다.
• 외부 연동사는 개념 없는 곳에 존재할 확률이 높다, 왜? 말 그대로 외부이기에 내부에서 지탱해야 할 개념 X
• 외부는 항상 우리의 의도와는 다르게 변하기 때문에 격리해야 한다. (격벽)

 

• 참조 불가의 벽을 통해 영역을 나누고, 외부 연동사는 DB에 저장하는 역할만 처리한다. (격리)

 

좌) As-Is, 우) To-Be

• 코어 -> 개념 영역에 집중
• 수집 및 정제 (외부 연동사)는 별도의 모듈로 분리하고, 더 강하게 격리한다.

 

• 분석, 설계에 매몰되기 보다는 지금 할 수 있는 최소한의 구현을 즉시 하셨으면 좋겠다.
• 개념 + 격벽을 활용해서 구현을 하고, 테스트 코드를 통해 증명 + 피드백을 받으면서 구현을 계속 하다보면 결국 설계가 된다.

결론: 개념을 잡고, 격벽을 세워, 구현을 채워나가며 설계를 완성한다.

 

인프런 아키텍처 2024-2025 - 이동욱

2023년 인프런 아키텍처 리뷰 -> 인프런 학습 서비스들만 국제화에 용이하도록 먼저 신규 기술 스택 전환, 글로벌 기반 작업 시작

트래픽 비용 개선: 치솟는 환율? 결과적으로 클라우드 비용도 증가함

 

이미지 포맷

고품질, 저용량의 AVIF(AV1 Image File Format?) 

• 이미지 포맷의 확장자에 따라 파일 크기가 다르다 -> 최적화
• 품질 저하 없는 고효율 압축, JPEG에 비해 최대 50% 용량 개선, 대부분 브라우저에서 지원하는 기술
• 전체적으로 60% 이상 개선, 전체 이미지 트래픽의 60% 감소

 

JSON CDN Cache

기존에는 데이터베이스에서 관리하고, 백엔드에서 카테고리 정보 내려주어 모든 페이지마다 클릭 시 노출되도록 구현 -> 하루에 대략 150GB 호출되는 JSON 데이터..

• DB 부하 감소를 위해 외부 캐시(ElasticCache) 도입했으나, 외부 캐시의 높은 트래픽이 발생.... 여러 대의 캐시 서버 필요
• 따라서 외부 캐시 -> 로컬 캐시로 전환 : JSON 데이터이고 복잡한 데이터가 필요하지 않음
• 하지만 EC2의 수많은 트래픽 비용은 어떻게 개선할까? -> JSON 데이터 자체를 CDN 캐싱 적용

 

앞으로...

• 국제화, 글로벌 작업은 화폐부터 타임존, 언어 등 여러 제약이 많지만, 일단 시도하고 깨지면서 넘어지더라도 앞으로 넘어지자.

 

클린 스프링: 스프링 개발자를 위한 클린코드 전략 - 이일민(토비)

Clean Code That Works!

 

클린 코드가 강조하는 것?

• 읽기 좋은 코드
• 이해하기 좋은 코드
• 확장하기 좋은 코드
• 결국, 유지보수하기 좋은 코드 -> 유지보수성

 

유지보수성

• 개발 생산성과 유지보수성은 서로 영향을 주는 관계이다.

 

기술 부채

• 부채가 지속적으로 효과를 발휘하려면, 리팩터링(부채상환)이 동력이 되어야 한다.

 

클린 코드 선순환

그래서, 시작은 어떻게...?

 

• 유지 보수성과 생산성의 균형을 잡아줄 리팩터링을 잘 하기 위해서는? 테스트가 중요!
• 그런데 테스트를 작성하면 구현 능력과 구현 속도가 .....

"테스트를 빠르고 효과적으로 작성하면서 개발하는 능력이 필요" -> 충분한 연습과 노력이 필요

 

• 결국 클린 코드의 많은 원칙은 팀의 동료 개발자와 관련된 것, 상황에 따라 다른 기준을 가지고 있다.
• 팀과 함께 결정하고, 탐험하고, 학습하고, 성장한다.

 

클린 스프링

• 자기 책임에 충실한 오브젝트로 구분하고, 의존관계를 유연하게,
• 헥사고날 아키텍처(?),
• 계층과 모듈 경계에는 API, 즉 인터페이스를 사용

"클린 코드는 항상 코드에 관심을 가지고 보살피는 사람이 작성한 것처럼 보인다."

 

개발자로 긴 커리어를 가지고 싶다면? - 한기용

• 변화를 두려워하지 말 것
• 내가 나이가 많다고 생각하지 말자. 생각보다 지내온 시간보다 남은 시간이 훨씬 많다.
• 내가 무엇을 원하고, 이것을 얻기 위해 무슨 환경을 원하는지 등 진지하게 고민해보자.
• 평정심과 꾸준함 -> 복리활동

 

• 모든 걸 다 할 순 없다. 모든 걸 다 하려고하면 질문도 안하고, 엉뚱한 산에 오르게 된다.
• 기술 지향적인 사람이 아닌, 내가 맡은 일을 하는데 필요한 기술을 공부하자.

 

• 사고는 언제 터지냐의 문제이지, 안터지는건 절대 아니다.
• 영향력? 나의 존재로 인해 주변 사람들의 역량이 올라간다는 의미

 

• 고민을 많이, 깊게 할수록 역량이 향상된다.
• 나에게 맞는 환경을 잘 찾아가고, 현재에 집중하자 -> 몰두해보는 경험이 더 중요하다.
• 내 자신을 스스로 사랑하고, 나를 있는 그대로 받아들이자.

 

트랙 4 (PM, PO)

성장하지 않아도 괜찮습니다. - 김영재

꾸준함이 곧 의미를 만듭니다. 지금 하는 일을 더 긴 호흡으로 지치지 않고 하는 지속가능성에 집중

우리에게 부족한 것은? 호흡이 너무 짧다, 팀플레이가 부족하다.

성장은 결과일 뿐, 성장이 동사로 쓰이면 "나를 잃어버린다."

 

고민할 포인트는, 지금 하는일을 어떻게 하면 많이, 함께, 크게, 오래 할 수 있을까?

 

많이

• 엔지니어링? 재생산 비용을 제로에 가깝게 떨어뜨리려는 노력
• 일을 할수록 자신의 재생산 비용을 낮춰야 한다. (루틴의 자동화, 지식의 일반화)
• 동료들에게 글을 쓰는 것을 권장한다.  
  • 개인 블로그 -> 일기장
  • 위키 -> 메모장
  • 회사 블로그 -> 지식의 일반화를 위한 훌륭한 방법  

 

함께

• 동일한 질문이 자꾸 나온다라는 생각이 든다면, 원인을 찾아서 없애보자.
• 릴리즈를 관리하다 보니 버전 관련 문제가 많았다. -> 따라서 버전의 규칙을 만들었다.

https://github.com/line/headver

GitHub - line/headver: SemVer compatible version specification that has {head}.{yearweek}.{build} system.

https://techblog.lycorp.co.jp/ko/headver-new-versioning-system-for-product-teams

HeadVer - 기민한 프로덕트 팀을 위한 새로운 버저닝 시스템

 

크게

5년만에 프러덕트 개발 (ABC User Feedback 오픈소스 개발)

• 유저 의견을 누구나 부담없이 시각화, 가시화
• API, Webhook으로 번역, AI 분석, Slack 알림
• 개인정보 취급에 가장 안전한 DB 직접 관리

https://github.com/line/abc-user-feedback

GitHub - line/abc-user-feedback: ABC User Feedback is a standalone web application that manages Voice of Customer (VoC) data. It

https://techblog.lycorp.co.jp/ko/5-year-effort-to-put-abc-user-feedback-on-track

 

• 서비스 간 우선순위 질문이 너무 많았다 -> 어떻게 수치화하고, 가시화할 수 있을까?
• 매출 상승, 비용 절감, 사용자 만족도, 레거시 해소 4가지를 기준으로 결정 

https://techblog.lycorp.co.jp/ko/a-formular-for-prioritizing

우선순위에 시달리다 공식을 만들었다

 

오래

• 나의 아이덴티티를 발견하는 과정
• 거창한 주제보단 지금 하는걸 더 많이 하는게 첫걸음
• 지치지 않고 하다 보면 하나의 키워드로 모아질 때가 온다 -> 그것이 나의 아이덴티티
• 누군가가 뭐하는 사람인지 물어본다면? -> ~ 등의 아이덴티티를 만들어가고, 일반화를 해나가며 확립해나가야 한다.

 

정리

꾸준하게 매 주, 1년에 50번 반복하여 많이, 함께, 크게, 오래 하자.

 

트랙 5 

하루 1억 건 이상을 처리하는 견고한 포인트 시스템 구축하기 - 서주은

포인트 시스템의 요구사항

• 적립, 차감, 잔액 확인, 내역 확인
• 광고 클릭 포인트, 미션 완료 포인트, 추천인 포인트, 수동 적립 포인트, 차감 포인트

 

초기 설계

• 포인트 유형 별 테이블 분리, 포인트 적립이 발생할 때마다 잔액을 구하기 위해 과거 히스토리를 다 검색해서 합산
• 별도의 잔액 테이블을 사용하는데, 문제가 발생함 (새로운 포인트 타입 추가시 테이블 추가, 적립 내역 조회 성능 저하)

 

개선하기

 

문제 발생: 동시성

• 문제를 해결하기 위해 비관적 잠금(Lock) 사용

 

• 분리된 테이블을 하나의 테이블로 설계하여 로직 파악이 용이하고, 트랜잭션이 필요없도록 개선

 

낙관적 잠금

• 포인트를 적립할 때마다 잠금을 매번 획득하고, 반환하는게 비효율적으로 보였음
• 작은 확률로 발생할 수 있을까 말까한 문제로 매번 잠금 획득&반환하는 게 불필요한 오퍼레이션이라고 생각했고, 그로 인해 낙관적 잠금을 적용함
• Unique 제약 에러 발생 시 재시도 처리

 

추가 요구 사항 - 1년 이상 미사용 포인트 소멸

2023년 12월 24일 기준 소멸되어야 할 포인트는? 700 (1200 - 500)

• balance = deposit_sum + withdraw_sum
• deposit_sum: 현재까지 쌓은 포인트의 합
• withdraw_sum: 현재까지 사용한 포인트의 합

 

후기

이번에도 오프라인에 직접 참여하지는 못했지만, 온라인에 공개된 영상들을 보며 자극도 많이 받고, 많이 배울 수 있었습니다.

 

조영호 님의 "객체지향은 여전히 유용한가?" 발표를 통해서 요구사항에 대해 절차적인 설계와 객체지향 설계를 토대로 각각 어떠한 장단점이 있는지, 언제 어떠한 설계가 유용한지에 대해서도 정리할 수 있었습니다

 

김재민 님의 "지속 성장 가능한 설계를 만들어 가는 방법" 발표를 통해서는 개념과 격벽이라는 용어가 굉장히 신선했다. 특히 이번 발표뿐만 아니라 지속 가능한 시리즈를 매년 공유해 주셨었는데, 가장 기억에 남고 유용했던 내용이 import 문을 통해 책임이 적절한지 등에 대해 본 적이 있었는데 이 부분도 굉장히 유용한 것 같습니다.

또 "서로 연관되어 있는 도메인들을 생각하다 보면, 이것도 맞고 저것도 맞는 것 같은 생각이 든다." 라는 부분이 있었는데, 추후 비슷한 상황에 접하게 된다면 해당 영상을 떠올려보면 굉장히 많은 도움이 될 것 같습니다.

 

토비 님의 "클린 스프링: 스프링 개발자를 위한 클린코드 전략" 발표를 통해 결국 테스트가 굉장히 중요한 요소이고, 이러한 역량을 향상시키기 위해 좀 더 다양한 경험들을 통해 정립해 나가는 것이 필요하다는 생각이 들었습니다.

 

한기용 님의 "개발자로 긴 커리어를 가지고 싶다면?" 를 통해 앞으로의 커리어에 대해 다시 한번 되돌아볼 수 있는 계기가 되었습니다.

최근에 특히 방향성의 중요성에 대해 다시 한번 느끼게 되었고, 방향성에 대해 주기적으로 되돌아보는 시간을 가져야 할 것 같습니다.

"고민을 많이, 깊게 할수록 역량이 향상된다.", "나에게 맞는 환경을 잘 찾아가고, 현재에 집중하여 몰두하는 경험"

 

김영재 님의 "성장하지 않아도 괜찮습니다." 발표를 통해 성장의 의미에 대해서도 다시 한번 되돌아 볼 수 있었습니다. 평소에 성장이라는 단어를 꽤나 사용하는 것 같은데, 성장 자체에 대해서는 크게 고민을 해본 적이 없는 것 같습니다. 이전에도 자동화와 관련하여 영재 님의 발표를 본 적이 있었는데 오픈소스나 발표, 블로그를 굉장히 잘 하시기에 깊은 인상을 받았었습니다. 또한 나만의 아이덴티티에 대해 고민해 보고, 확립해 나가야겠다는 생각이 들었습니다.