인프콘 2024에서 들었던 4개의 강연들

올 해 3년차를 맞이하는 인프콘, 올 해도 감사하게 지인 덕분에 다녀올 수 있었다.

다만 몸 상태가 그렇게 좋지 않아 강연에 집중했다.

오전에 듣고 싶었던 강연이 있었지만 체력 비축을 위해 패스하고..!

굿즈 받는 것도 (나에겐) 상당한 체력 소모라 입장시 주는 굿즈 외에는 받지 않으려고 했지만.. 두번째 강연 들으러 가는 길에 ‘여기어때’ 줄이 짧아서 참여했다.

결과는 친환경 칫솔 세트!

혹시 당신은 데이터를 모르는 백엔드 개발자인가요?

데이터를 모른다는 것이 뭘까 싶어 들었다.

발표자는 백엔드 개발자이자 데이터 엔지니어라 데이터를 관리하는 하나의 관점이라고 봐달라고 하셨다.

백엔드 엔지니어에게 데이터란?

• 나는 재료, 발표자는 CRUD라고 생각했다.
• 행을 중점으로 데이터를 읽는다.
• 행 단위로 데이터를 처리할 때 JSON, Array 타입이 간편하지만, row가 많을수록 full scan 비용이 증가한다.
• 정규화도 좋지만 앞으로 이 데이터가 분석에 쓰일 것인가?를 생각해보자.
• 그렇다면 형태가 어떻든 상관없지만 현실은 대부분 쓰인다..

데이터 팀에게 데이터란?

• 열을 중점으로 데이터를 읽는다.
• 열을 잘 읽고 쓰는 것이 중요하다 → 분석 비용 감소, 확장성/생산성 증가
• 왜 이렇게 설계되었는지 데이터 맥락이 잘 공유되어야 한다.
• 데이터 공유 시스템(데이터 카탈로그) 공유: 데이터의 문서화 → 없으면 적어도 코멘트라도 써놓아야

데이터베이스는 데이터 관리가 전부가 아니다

• 데이터는 역사를 나타내는데, 저장만 했다고 데이터가 아니다
• GIGO(garbage in garbage out): 잘못된 데이터를 넣으면 잘못된 데이터가 나온다
• 화면, 기능에 문제가 없으면 괜찮은거 아닌가? 데이터 무결성을 고려해야
• 데이터를 기능적인 면에서만 고려하면 안된다 → 데이터 유효성을 고려해야
• delete 쿼리: 데이터 저장 비용 vs 데이터 가치 → 모두 저장하는 것이 비즈니스를 위한 방법
• 좋은 서비스를 만들기 위해서는 데이터에 대해 잘 알아야 한다.

결국 문서화의 중요성을 일깨워주는 강연인가? 싶으면서도

데이터 엔지니어 관점으로 데이터를 바라보는 시각을 조금은 알 수 있었다.

달리는 기차의 바퀴 갈아끼우기: 인프런 프론트엔드 마이그레이션 여정

프론트엔드 개발자는 아니지만, 마이그레이션을 진행했던 적이 있어 들었다.

wordpress로 시작한 서비스가 node + express.js + pug + e.js로 마이그레이션했다.

랠릿이라는 서비스가 등장하면서 2차 마이그레이션을 진행하며 겪은 경험과 고민을 공유하셨다.

기존 코드의 문제

• 코드 사용처 파악 불가
• 서버, 클라이언트 코드 혼재
• 채용 시장의 변화
• HMR 미지원 + 빌드 시간 증가: 빌드 시간이 21분?!

랠릿의 스택을 인프런에 적용하자

• react + SSO 필요 유무에 따라 Vite, Next.js로 결정
• 현재 유지보수가 힘들고 서비스 내 영향도가 높은 페이지 vs 현재 유지보수가 비교적 쉽고 서비스에 영향도가 낮은 페이지 → 전자 선택
• 언제든 롤백이 가능한 형태 + 기존의 url을 유지하면서 마이그레이션 진행 → 기능 플래그

기능 플래그(Feature flag)

• 특정 기능 동적 제어 → 점진적 배포, 특정 환경/사용자만 사용: 배포 안정성
• 하지만 on/off 코드 2개 관리 및 배포 + 기능 플래그 코드 정리 → 단점보다 장점이 컸다.
• vite 결과물을 s3에 업로드, 쿠키 기반으로 되어있던 기능플래그로 request를 분리했다.

shadow DOM

• header, footer 말고 그 안의 내용들을 마이그레이션하고 싶다.
• 기존 레거시 레이아웃 vs react 컴포넌트로 바꾸기? 작업 소요 시간 줄이자 (레거시를 함께 가져가기)
• 스타일 침범 이슈 발생하면서 전역 레거시 컴포넌트 스타일이 리액트 컴포넌트에 영향을 미친다.
• !important / sass meta.load-css(스타일 변수 접근 불가) / shadow DOM 3가지 방법 중에 shadow DOM 선택했는데..
• 웹 컴포넌트에 캡슐화를 도와주므로 react component 스타일을 격리한다.
• vite manifest file option을 통해 manifest.json 자동 생성 → 빌드된 파일들의 파일들의 의존성을 알려준다 → 불필요한 작업 개선
• 하지만 shadow DOM에서 여러 문제가 발생하여 결국 header, footer를 리액트 컴포넌트로(공용화) 만들었다.
• 공용 컴포넌트 분리로 유지보수성이 높아졌다.

Module Federation

• 공용 라이브러리의 문제점은 마이그레이션할 수록 업데이트 주기가 늘어난다
• 각 목적 조직(개발, QA 등) 단위마다 배포 주기가 다르고 관리하는 패키지가 증가해서 Module Federation을 적용했다.
• 베포 프로세스가 변경되면서 비효율적인 작업이 줄었다.

reverse proxy

• 인프라 관련 문제(트래픽): AWS CloundFront Behavior
• 하지만 설정이 너무 쉬워 request 출처가 불분명하다.
• 또한 쿠키 기반(기능 플래그)은 분기가 제대로 되지 않아 reverse proxy 서버 구축

처음 들어보는 개념도 있고 다양한 키워드가 나오다보니 키워드를 알아간다는 생각으로 가볍게 들었다.

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

객체지향의 사실과 오해를 흥미롭게 읽어서 들었다.

발표 타이틀은 강의 후에 질의응답에서 꾸준히 나왔던 질문이라고 한다.

절차적인 방식과 객체지향 방식으로 구현한 코드를 중심으로 비교하는 방식으로 진행되었는데 맨 앞자리에 앉길 잘했다 싶었다.

• 대부분 OOP 언어를 사용하므로 객체지향에 대해 알 필요는 있다.
• 어떤 요구사항(데이터, 타입)이 변경됐을 때 무엇을 변경해야 하는가?

객체지향적 설계

• 데이터와 로직이 같은 class에 담겨있다.
• 데이터가 변경되어도 같은 클래스 내 로직을 변경하면 된다 → 낮은 결합도
• 코드를 수정하지 않고 데이터 변경과 타입 확장이 가능하다 → 일관성있는 설계(implement)

절차지향적 설계

• 데이터와 로직이 별도의 클래스로 분리
• 의존성이 높아(높은 결합도) 데이터가 분리되면 로직도 변경해야 한다.
• 타입 추가 시, 내부 코드 수정 (리팩토링) 후 새로운 타입을 추가한다.

하지만 OOP가 무조건 좋은 것은 아니다

타입에 새로운 operation이 추가되면, OOP에서는 전체적으로 overriding 해줘야 한다.

절차적인 설계

• 포맷 변경을 위한 데이터 변환
• 데이터 중심
• 데이터 노출 → get, set의 의미가 없다
• 기능 추가에 유리

객체지향 설계

• 규칙에 기반한 상태 변경
• 행동 중심: 행위의 응집도 중심
• 데이터 캡슐화
• (유사하게 행동하는) 타입 확장에 유리

실제로는 절차적 설계와 객체지향 설계를 혼용하여 사용, 절차적으로 짜는 비율이 높다.

• presentation 레이어: 절차적 → 데이터 변환(HTTP request 등)
• service 레이어: 절차적 → 애플리케이션 flow 처리(db에서 data(객체)를 읽고 response를 만든다)
• domain 레이어: 객체지향 → 규칙 기반의 상태 변경
• persistence layer: 절차적 → 데이터 변환(database ↔ sql)

객체지향이 언제 유효한가? 가 좀 더 좋은 질문이라고 생각한다.

• 무얼 배워야할까요? 일단 배워보라(알아야 상황에 따라 적용할 수 있다)
• 나의 경우가 어떤 경우인지?(언제 적합할까?) 를 먼저 알아야 한다.
• 어떤 설계도 모든 상황을 커버하지 못한다. 즉, 유용하지 않은 기술은 없다.

결론: 코드의 목적과 변경의 방향성에 따라 언제 어떤 기술을 사용할지 결정하라.

강연이 끝나고 나도 모르게 와.. 소리가 나왔다.

강연 제목 같은 질문들을 던졌던 분들처럼 그동안 나도 어떤 기법이나 기술을 이분법적으로 생각하는 것이 아닌가? 하는 생각이 들었다.

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

요즘드는 고민 중 하나라서 들었는데 알고 보니 내가 발표자 분 옆자리에 앉아 있었다.

마지막 강연은 멘토링 듣는다는 마음가짐으로 들었다.

• 몸으로 부딪혀 배우는 것만큼 효율적인 것은 없다.
• 모든 결정을 해보고 나서 판단을 내릴 수 있다. → 커리어는 내가 완성시키는 것
• 우측상향은 불가능하다 → 다양한 up & down이 존재하니 변화를 두려워하지 말라.
• 내가 원하는 것이 무엇인지? 나한테 맞는 환경은 무엇인가?
• 평정심/꾸준함
• 나이에 대한 의식 → 결국 남과의 비교가 아닌가 싶다.

30년 일하고 깨달은 점

• 생각보다 시간이 많다
• 실패가 실패가 아니구나(정신 승리)
• 선택이란 순서의 문제다
• 스톡데일 신드롬: 길게 보면 잘 될 것이라 믿고 현재에 충실하자
• 내가 원하는 것이 무엇인지 고민하자
• 나에 맞는 환경을 찾아가자(때로는 환경 탓 하기)
• 의사소통이 정말 중요하구나(호기심 갖기)
• 주변에 서포터를 많이 만들자 또한 누군가의 서포터가 되자

내 주변의 서포터는 누굴까 생각해봤을 때 3명 정도 있는 것 같다.

• 이 시대의 전문성은 변화를 두려워하지 않는 것이다
• 회고하는 사람이 되자

주니어에게 하고 싶은 말

• 기본기는 여전히 중요하며 의사 소통 능력을 포함한다 → 문제 정의를 잘 하는 것이 중요하다
• 코딩을 잘한다는 것은 검증 능력(테스트)을 포함
• 코칭이 가능한 사람이 되자(동일한 문제를 반복하지 말자)
• 나에게 맞는 공헌이란 무언지 항상 고민하자
• 결과지향 vs 기술지향
• 문제 정의: 나에게 업무를 준 사람의 의도를 잘 파악하자
• 우선 순위를 파악하자
• 시간 관리를 잘하자

시니어에게 하고 싶은 말

• 업무 완료 시간 추정 연습하자
• 운영을 고려한 코드를 작성하자
• 서비스 사고 대처 잘하자
• 코딩 몽키가 아닌 영향력을 가진 사람이 되자: 나로 인해 다른 사람들의 역량이 올라가는 사람
• 어려운 대화를 잘하자(호기심)
• 다양한 문제와 행복하게 공존하는 연습을 하자
• 기회가 생기면 리더가 되어보자 → 영향력 측면에서
• 리더 vs 전문가

최근 주변에서 어떤 사람이 되고 싶냐는 질문을 받은 적이 있었는데 그 때가 떠올랐다.

그래서 결론은,

• 남과 비교하지 말고 나에 집중하기 → 나말고 믿을 건 읍다
• 좋은 환경 찾기
• 현재에 집중하고 꾸준하기
• 주변에 서포터 많이 만들고 서포터 되기
• 변화를 두려워하지 않기
• LOVE YOURSELF

불완전한 나를 있는 그대로 받아들이자.