인프콘 2024

 

2024 인프콘 다녀왔습니다.

 

저도 펠리컨 참 좋아합니다

 

 

작년에 인프콘 신청했던건 떨어졌는데 이번에는 붙어서 행복하네요 ㅎㅎ

이렇게 큰 개발자 컨퍼런스에 오프라인으로 참석하는건 처음인데 너무 재밌었습니다.

 

세션들도 너무 재밌는게 많았고 특히 이동욱님이 발표해주신 "2024~2025 인프런 아키텍쳐" 세션에서는 실무와 바로 연관성 있는 내용들도 많아서 듣는데 이것저것 해보고 싶어서 설랬습니다. 

신기한게, 인프콘 듣기 전날에 회사에서 "Tech팀의 미션과 가치" 에 대한 토론을 진행했었는데요.

"저 펠리컨적 사고 좋아해요" 라고 이야기했던걸 여기서도 들을 줄 몰랐습니다. ㅎㅎ

나도 맞는 방향을 가고 있구나! 생각이 들어서 기분이 되게 좋았어요.

 

네트워킹 자리도 너무 만족스러웠습니다!
모두 스탠딩으로 서서 진행했는데, 세션 발표자분들이나 다른 개발자분들과 소통할 수 있는 자리여서 이야기 하기도 편했습니다.
앞에 맥주 한잔만 딱 있으면 연회장 같은 분위기였어요 ㅋㅋㅋㅋ

다같이 저녁먹고 파티하면 엄청 재밌을 것 같은 느낌!

 

토스 프론트엔드 챕터 헤드이신 박서진님과도 이야기 할 수 있어서 좋았습니다.
토스가 추구하는 개발자상도 말씀해주시고 이런저런 좋은 말씀도 많이 해주셔서 재밌었습니다.
유튜브에서 보던 사람들을 실제로 보니까 연애인 보는 기분도 들더라구요 ㅎㅎ

나도 개발 공부를 더 많이 해야겠다는 자극도 많이 받았어요!
네트워킹 시간이 생각보다 짧아서 조금 아쉽긴 했지만 다른 기회들도 많이 만들어봐야겠죠?

 

저는 총 6개의 세션을 들었습니다.

1. 7년동안 하나 만들었습니다. : AB180 이찬희님
2. 인프랩 아키텍쳐 2024-2025 : 인프랩 이동욱님
3. Next.js 모범사례 탐구 - Vercel 리더십 블로그 아키텍쳐 파해치기 : 당근마켓 하조은님
4. 처음으로 기술 리더가 된 개발자를 위한 안내서 : 토스 박서진님
5. 기획자/PM/PO가 누구에게나 일 잘한다고 인정받는 법 : 캐치테이블 주현우님
6. AI와 데이터로 실제 업무 효율화가 가능할까?: AI 세차 도입기 : 쏘카: 김연서님

하나같이 저에게 도움 되는 강의였습니다.
수많은 사람들 앞에서 발표하는게 정말 떨리는 일인데, 잘 정리해서 공유해주신 연사분들이 존경스럽기까지 하더라구요.
이 세션들을 들으면서 배우고 느낀점들을 간단하게 정리해보려고 합니다.

 

세션1 - 7년동안 하나 만들었습니다.

발표자: 이찬희(AB180)

 

• 오랫동안 하나의 제품을 개발하다보니 성장하는 키 포인트가 몇 가지가 있었음.
• 대용량 트래픽을 처리하면서
  • "UI는 데이터 양과 변화량의 곱이다"를 느낌.
  • 데이터 참조를 쉽게 하도록 하기.
• 캘린더 컴포넌트를 만들면서
  • 복잡도를 이해하고 문제를 해결하기 위한 쉽고 간단한 방법을 찾아라.
  • 오류 발생 시 이를 방지하기 위해 과도한 조건문을 남발하지 말고, 중요한 로직에 집중.
  • 오버 엔지니어링을 방지하기 위해 결과물을 먼저 그려보고 테스트할 것.
• 새로운 스택을 도입하면서
  • 급하게 기술을 도입하지 말고, 필요한 문제를 먼저 생각한 후 기술을 도입할 것.
  • 측정 데이터가 편향될 수 있으므로 다양한 시각에서 검토할 것.
  • 기술 도입 시 장기적인 유지보수와 디버깅 가능성을 고려할 것.

세션 필기 노트

7년동안 하나 만들었습니다. - Raw

 

1. 첫 번째 경험: 대규모 트래픽 처리
   • 상황: 큰 고객이 들어오면서 이벤트 발생 수가 1000배 이상 증가.
   • 도전: 백엔드는 pagination으로 해결 가능하지만, 프론트엔드는 렌더링 최적화가 필요함.
     • 데이터 양과 변화량을 고려하여 UI를 설계.
     • 데이터 참조를 쉽게 하기 위해 JavaScript의 Map 사용.
   • 교훈:
     • UI는 데이터 양과 변화량의 곱이다.
     • 데이터 참조를 쉽게 할 것. (js Map 사용 등)
2. 두 번째 경험: 캘린더 컴포넌트 개발
   • 상황:
     • "오픈소스로 공개할까?" 라는 고민을 할 정도로 기술적으로 잘 만들어진 컴포넌트 였음.
     • 잘 만든 캘린더 컴포넌트를 수정하는 과정에서 복잡도가 증가함.
     • 이제는 아무도 건드리고 싶지 않아하는 컴포넌트가 됨
       • 남 일 같지 않아서 더 공감이 갔습니다. 요즘 개발하다가 스펙터 초기에 개발했던 내 코드들을 발견하고 리펙토링 하는데, 너무 복잡도도 심해보이고 나도 건드리기 싫은 컴포넌트를 누가 좋아할까 하는 생각도 들어서 반성하게 되네요.
   • 도전: 수정과 추가 과정에서 점점 복잡해져 다루기 어려워짐.
   • 교훈:
     • 복잡도를 이해하고, 문제를 해결하기 위한 "쉽고 간단한" 방법을 찾을 것.
     • 오류 발생 시 이를 방지하기 위해 과도한 조건문을 남발하지 말고, 중요한 로직에 집중.
     • 오버 엔지니어링을 방지하기 위해 결과물을 먼저 그려보고 테스트할 것.
3. 세 번째 경험: 기술 교체의 실패
   • 상황: Redux를 Recoil로 대체했지만, 나중에 후회하게 됨.
   • 도전: 도입 당시 벤치마킹과 테스트를 통해 문제를 파악하지 못함.
   • 교훈:
     • 급하게 기술을 도입하지 말고, 필요한 문제를 먼저 생각한 후 기술을 도입할 것.
     • 측정 데이터가 편향될 수 있으므로 다양한 시각에서 검토할 것.
     • 기술 도입 시 장기적인 유지보수와 디버깅 가능성을 고려할 것.

개발자로서의 성장

• 인원수, 코드 라인수, 기능 수 등의 성장 비교
  • 개발자의 성장과 제품의 성장 간의 비교.
• 리팩토링의 중요성
  • 제품이 오래되면 리팩토링의 의미가 달라짐.
  • 오래된 코드는 새로 작성하는 것보다 리팩토링하는 것이 더 쉬울 수 있음.
  • 리팩토링을 통해 더 깊이 고민할 수 있는 기회를 가짐.
• 개발자의 자세
  • "시니어 개발자는 이래야 한다, 시니어 개발자는 이래야 한다"라는 고정된 규칙은 없음.
  • 각자의 방식대로 결정적인 순간을 만들어 나가는 것이 중요함

 

세션2 - 인프랩 아키텍처 2024-2025

발표자: 이동욱 (인프랩)

• 인프랩의 국제화를 위한 아키텍쳐 및 인프라 환경을 구축. 그때 겪었던 내용을 바탕으로 어떻게 문제를 해결했는지 공유.
• 기존 레거시 인프랩을 복제해서 A, B의 목적조직에서 사용해 점진적 현대화 진행중이였음.
• 와중에 국제화를 진행해야 했기 떄문에 기존 React를 사용한 SPA 환경에서 Next.js 를 채택해 점진적으로 마이그레이션
  • Go기반의 Traefik 사용해서 http header 기반 라우팅 가능
  • 같은 path라도 사용자가 다르면 header에 다른 cookie를 사용해서 운영에서 테스트까지 마치고 일반 유저들에게 오픈 가능함.
• 비싸지는 인프라 운영비 줄이기위해
  • "avif" 이미지 포멧으로 이미지 변환시키는 lambda edge 및 Cloud Front 캐싱 사용
  • JSON API response를 CDN 캐싱으로 돌려서 애플리케이션 로드 80% 감소, LB 트래픽 50% 감소

 

세션 필기 노트

1. 2023 인프런 트래픽 문제 해결 및 국제화

• 조직 개편 및 레거시 운영:
  • 조직을 A와 B로 나누어 레거시 시스템을 각각 운영
  • A 조직은 개선했으나 B 조직은 국제화와 리소스 문제로 개선하지 못함
  • 레거시 개편이 어려운 이유: 사업 중심의 운영과 리소스 부족
  • 전사적인 레거시 개편 합의로 인해 국제화에 유리한 상황
• 트래픽 비용 절감:
  • 이미지 트래픽 최적화:
    • S3와 Lambda Edge를 이용한 이미지 리사이징 및 CloudFront 캐싱
    • PNG와 JPEG 파일 크기로 인해 트래픽 비용 증가
    • AVIF 포맷 사용으로 이미지 트래픽 60% 감소
  • JSON 데이터 트래픽 관리:
    • 하루 150GB 이상의 API 호출로 인한 DB 부하 문제
    • Elastic Cache 사용 후에도 트래픽 문제 지속
    • 로컬 캐시 도입 및 JSON 데이터의 CDN 캐싱
    • 결과: 애플리케이션 로드 80% 감소, LB 트래픽 50% 감소

2. 서비스 국제화를 위한 아키텍처 개선

• Next.js를 통한 API 관리:
  • Next.js의 rewrite 기능을 활용한 API 프록시 서버 관리
  • 문제점: Next.js를 통해 외부에 공개되지 않아야 할 API 호출 문제 발생
  • 해결책: /client 경로를 붙여서 외부와 내부 API를 구분, 세션 쿠키와 토큰을 통해 인증 체크
• CloudFront와 Reverse Proxy 사용:
  • CloudFront의 behavior 제한 문제 해결
  • 헤더 기반 분기 처리를 위한 reverse proxy 사용
  • Nginx 대신 Go 기반의 Traefik 사용, 동적 설정 변환 가능
  • CloudFront와 Traefik을 조합하여 전방위적인 트래픽 관리
• 점진적 Next.js 개편:
  • 도메인 변경 없이 path와 헤더 기반 Traefik 설정으로 운영 및 테스트
  • 점진적인 Next.js 개편을 통해 서비스 안정성 유지

 

세션3 - Next.js 모범사례 탐구 - Vercel 리더십 블로그 아키텍쳐 파해치기

발표자: 하조은(당근마켓)

• Vercel C-Level들의 개인 블로그 탐구
  • CEO: Guillermo Rauch (rauchg.com)
  • VP: Lee Robinson (leerob.io)
• Vercel 임원진들의 블로그는 마치 Next.js 의 모델하우스 같음
  • 개발에는 건축용어가 많으니 "모델하우스" 라는 표현이 되게 와닿았음.
  • Think: 블로그는 나를 표현하는 모델하우스임. 내가 사용할 수 있는 깔끔한 기술 등으로 예제를 만들어서 제공하는 것.

 

세션 필기 노트

1. 일반적인 Next.js 블로그 아키텍처

• Front Matter: 제목, 설명 등 메타데이터 포함
• Markdown 파싱 과정:
  • Markdown -> Markdown AST -> HTML 변환

2. Vercel 리더십 아키텍처

• 예시 블로그: rauchg.com, leerob.io
  • 개발 철학: 블로그를 통해 자신을 표현하는 '모델하우스'로 활용, 최신 기술과 예제 제공
  • 조회수 기능:
    • rauch: Redis 사용 (in-memory DB)
    • lee: PostgreSQL 사용
• 콘텐츠 데이터 관리:
  • rauch:
    • 코드로 글 관리 (MDX 파일)
    • ISR (Incremental Static Regeneration)로 60초마다 리프레시
    • 메타데이터:
      • OG Image: Dynamic Routing 사용, ImageResponse 객체로 HTML에서 이미지 생성
  • lee:
    • 데이터로 글 관리 (MDX 파일, app 라우터 외부)
    • Partial Prerender 사용 (Holes로 불리는 동적 영역을 suspense로 감쌈)
    • 메타데이터:
      • OG Image: 글 제목을 쿼리 파라미터로 전달, ImageResponse 사용
      • JSON-LD 사용해 메타데이터 관리

3. 하조은 블로그

• 앱라적 사고로 생각하신게 인상깊었음.
  • app/(post) 구조를 통해 Next.js 블로그 아키텍처를 구현

 

세션4 - 처음으로 기술 리더가 된 개발자를 위한 안내서

발표자: 박서진(토스)

• 팀원들에게 어떻게 좋은 리더가 될 수 있을까? 어떻게 팀원들을 성장시키고, 변화시키고, 팀워크와 퍼포먼스를 끌어올릴 수 있을까?
• 본인에게 항상 되묻자. "팀원들은 나를 믿고 좋아하는가?"
• 리더는 언행일치로 행동하고 팀원에게 진심어린 관심을 쏟으면서 예측가능하게 행동하고 팀원이 안정감을 느낄 수 있게 한다.

세션 필기 노트

처음으로 기술 리더가 된 개발자를 위한 안내서

발표자: 박서진 (토스)

1. 막막한 생각들

• 팀원을 어떻게 변화시키는가?
• 팀워크와 퍼포먼스를 어떻게 끌어올리고 동기부여를 할 것인가?

2. 기술 리더 공략집

• 기술 리드의 어려움:
  • 컴퓨터와 사람은 다르기 때문에 어려움이 있다.
  • 개발자로서 코딩만하다가 사람을 대하려고 하니 어려움이 있을 수 있다.
  • 동료들의 신뢰를 얻는 것이 중요하다.

3. 팀원들이 나를 좋아하게 만드는 방법

• 신뢰하는 7가지 순간:
  1. 유능:
     • 팀원의 문제를 해결해주는 능력
     • 팀원과 이해관계자의 문제를 파악하고 해결
     • 팀원 간 갈등 중재, 일정 조율, 협업 지원
     • 모르는 문제도 좋은 질문을 통해 해결을 도와줌
  2. 소통:
     • 명확하고 일관된 의사소통
  3. 예측가능성:
     • 리더의 말과 행동이 일치할 때
     • 담백하고 명확한 피드백 제공
     • 공동 목표 설정 (예: 토스 프론트엔드 조직의 목표)
  4. 관심:
     • 팀원에 대한 진심 어린 관심
     • 경청하고 공감하며 문제 해결을 돕기
     • 팀원과의 깊고 넓은 소통
     • 티키타카를 통해 대화의 균형 유지
  5. 안전:
     • 팀원의 심리적 안정성 보장
     • 경험에 따라 지배, 리드, 위임의 방식 조정
     • 구체적, 덜 구체적, 추상적인 지시를 상황에 맞게 사용
     • 진심 어린 칭찬을 통한 안정감 제공
  6. 유사성:
     • 리더와 팀원이 공유하는 유사한 점을 통해 신뢰 쌓기
     • 적절한 TMI(Too Much Information) 방출
  7. 이익공유:
     • 공동의 성공을 목표로 함

4. 요약

• 팀원에게 진심으로 관심을 가지고 다양한 주제로 이야기할수록 신뢰가 높아진다.
• 안정감과 예측 가능성을 제공하며 신뢰를 쌓는다.
• 담백한 피드백과 진실된 칭찬을 통해 팀원들의 심리적 안정감을 높인다.
• 항상 "팀원들은 나를 믿고 좋아하는가?"를 스스로 물어보자.

 

세션5 - 기획자/PM/PO가 누구에게나 일 잘한다고 인정받는 법

발표자: 주현우(캐치테이블)

• 보고는 짧고 강렬하게 영향도에 대한. 도식화 진행해서 보여주기 필요. 
• 모든걸 혼자 하려 하지 말고 주변인들에게 도움을 요청해서 참여를 유도하자. 동료들이 같이 참여한다고 직접 느껴야 함.
• 문제를 정의하고 실행하는 행동이 제일 중요. 주변사람들을 설득하는 능력도 중요.

 

세션 필기 노트

세미나 요약: 기획자/PM/PO가 누구에게나 일 잘한다고 인정받는 법

발표자: 캐치테이블 - 주현우

주요 역할 설명

1. PO (Product Owner)
   • 역할: 무엇을 만들 것인가? 비즈니스에 입각한 목표와 비전을 제시 (What의 관점).
   • 특징:
     • 스쿼드 조직 (bottom-up 방식)
     • 실제 PO 체제를 실행하는 회사는 많지 않음. 토스정도.
2. PM (Project Manager)
   • 역할: 어떻게 만들 것인가? 구현을 책임지는 올라운더 (How의 관점).
   • 특징:
     • 꼼꼼함, 일정 관리, A-Z 만들기 위해 모든 걸 챙기는 사람.
     • 목적 조직 (top-down 방식).
3. 기획자
   • 역할: 어떻게 만들 것인가? 화면 및 정책 중시 (How의 관점).
   • 특징:
     • 기능 조직 (top-down 방식).

전체적인 역할

• 문제 정의 + 실행력이 중심.
  • 문제 정의 방법:
    • 정확한 문제 인식.
    • 비즈니스를 동작하게 만들고, 고객의 진짜 원하는 것을 탐색.
    • 요청에 대해 판단하고 진짜 문제인지 검토.
  • 실행력:
    • 문제 해결 방법을 환경과 리소스를 고려하여 판단.
    • 동료들과 일정을 협의하고 확정.

인정받는 방법

1. 주변 사람 설득:
   • 타인의 직관과 상식을 상대.
   • 상급자의 관심 정보 취득.
   • 빌드업을 잘해야 함.
2. 짧고 강렬한 보고:
   • 지표의 영향도, 성과 도식화.
   • 경쟁사 현황 요약.
   • 변화의 핵심만 언급.
3. 선택 항목 제시:
   • 결정을 주관식이 아닌 객관식으로 준비.
4. 개발자, 디자이너와의 공유와 참여 유도:
   • 기획을 100% 완벽하게 하지 말고, 함께 논의하고 정리.
5. 일정 관리:
   • 스타트업은 일정에 대한 압박이 심함.
   • 최초 예측, 일정 확정, 중간 조정.
   • 진행사항 점검 시 전날 이슈를 미리 문서화하고 다음날 오전 스크럼에 확정.
6. 책임감:
   • 반응 속도와 유사.
   • 질문이 들어왔을 때 빠르게 답변 시도.
7. 본인의 상황 상시 공유:
   • 어려움과 고민을 주변과 공유.

협업 시 중요한 부분

• 누구랑 일하는가?
• 협업 시 중요한 부분:
  • 타인의 직관과 상식을 상대.
  • 짧고 강렬한 보고와 선택 항목 제시.
  • 개발자, 디자이너와의 꾸준한 공유와 참여 유도.
  • 일정 관리와 책임감 있는 대응.
  • 본인의 상황을 지속적으로 공유.

 

세션6 - AI와 데이터로 실제 업무 효율화가 가능할까?: AI 세차 도입기

발표자: 김연서(쏘카)

• 모델을 "잘" 학습 시켰다는걸 100% 확신하면 안된다. 
• 고객이 주는 나쁨, 보통, 좋음 에 대한 만족도 피드백의 신뢰도도 믿을 수 없다. 
• 수많은 경우의 수를 정의하고 기준을 재정의했음.
  • Think: 누구나 실수는 하지만 실수를 바로잡으려는 시도는 데이터 기반으로 옳바른 문제정의부터 시작하는게 인상깊음.
• 이렇게 다시 만든 모델과 GPT-4o 를 비교해서 "이 차량이 더러운가?" 에 대한 판단을 내리는것도 실험했는데, GPT-4o도 되게 괜찮았음.
• 핵심은 데이터나 AI 기술 그 자체가 아닌, 문제 해결을 위한 기획과 설계의 관점이다.

 

세션 필기 노트

세미나 요약: AI와 데이터로 실제 업무 효율화가 가능할까?: AI 세차 도입기

발표자: 김연서 - 쏘카

데이터 프로덕트

• Data as a Product:
  • 데이터 분석가와 데이터 엔지니어가 협력.
  • 데이터를 제품처럼 취급해 지속적인 가치를 창출하고 서비스 개선을 목표로 시스템 구축.

세차 오퍼레이션

• AI 모델 학습:
  • 쏘카 이용 중 업로드된 오염된 차량 사진을 이용해 AI 모델 학습.
  • "어떤 차를 세차해야 하는가?"를 결정하는 로직 필요.
• 초기 실수:
  • AI 모델이 차량이 더럽다고 판단하면 무조건 더럽다고 간주한 것이 문제였음.
  • 모델이 깨끗하다고 한 차량을 고객은 더럽다고 판단하는 경우 발생.
  • 결과 파악의 어려움 (ground truth 부족).
• 문제 재정의 및 접근:
  • 처음부터 문제 정의를 다시 시작.
  • 오염 판단 주체를 세 가지로 정의:
    1. AI 모델의 판단 결과
    2. 고객의 피드백 (good, bad)
    3. 데이터 분석가의 육안 판단
  • 차량 상태를 "깨끗" 또는 "더러운"으로 구분하는 기준 재정의.
  • 세차 필요 여부를 경우의 수로 정의.
  • 세차 오퍼레이션 아키텍처에는 날씨 정보도 포함.
• 고객 피드백의 신뢰성:
  • 고객의 운행 후 피드백 (좋다, 안좋다)은 신뢰할 수 없다고 판단.
  • 피드백에는 편향 가능성 존재.

AI 모델의 성과

• 쏘카의 AI 모델 vs GPT-4:
  • 쏘카의 자동차 오염도 판단 AI 모델이 GPT-4와 비교해도 성능이 나쁘지 않음.
  • 비용 등 여러 요소를 고려해야 하지만, 중요한 것은 문제 해결을 위한 접근 방식임.

결론

• 핵심은 데이터나 AI 기술 그 자체가 아닌, 문제 해결을 위한 기획과 설계의 관점이다.

 

 

내년에도 꼭 다시 가고싶네요! 온라인으로 듣는 것 보다 훨씬 몰입감 있고 뜻깊은 경험이였습니다.

열심히 준비해주신 인프랩 관계자분들 너무 감사합니다. :)