I/O Extended 2024 Incheon 참가 후기

 

매년 GDG 컨퍼런스들을 참가하고 있고, 이번에도 참가했다.

좋은 세션이 많아서 매 시간마다 가고싶었던 세션들이 겹치는 경우도 있어서 아쉬웠다.

 

 

나는 백엔드 개발자를 지망하는 학생이라 Server와 General 세션에 관심이 많았다.

시간당 1개씩 총 6개를 들을 수 있었는데 

내가 들었던 세션들의 후기를 적어봤다.

 

1. 구글 커뮤니티 구성원들의 I/O 현장 참가 경험과 글로벌 컨퍼런스 참여 팁 - 최가인

• 커뮤니티나 인플루언서가 아닌경우에 해외 컨퍼런스를 참여하려면 어떻게 해야하나요?
  • google for developers, 노마드 코더 뉴스레터를 통해 컨퍼런스 정보를 볼 수 있다.
• 해외 컨퍼런스에 가져갈 것
  • Elevator pitch 나를 소개하는 1분~3분 어필
  • 스케쥴 미리 짜기

 

후기 : 해외 컨퍼런스는 어떤식으로 진행되는지 볼 수 있어서 좋았다.

          하지만 일반인이 해외 컨퍼런스에 참여하기 위해서는 어떻게 해야할지는 정보가 부족했다.

          국내 컨퍼런스도 다양한 사람이 모이는데 해외는 얼마나 더 다양한 사람이 모일까 궁금해졌다.

 

2. IT 행사+에서 내향인이 네트워킹하는 법 - 성태이

• Why 네트워킹?
  • 정서, 정보 교류를 위해 느슨하게/끈끈하게 연결
  • 이점
    • 빠른 트렌드 파악
      • 요즘 업계의 관심사(대화, 이후 SNS)
    • 커리어 기회
    • 개인의 성장
      • 생각해보지 못한 태도, 새로운 관점 발견 가능
  • 내향인의 네트워킹이란
    • 소수와 밀접한 관계 선호
      • 나만의 네트워킹 목표 정의하기
      • 양보다 질
        • 다수와의 관계보다 한두 사람을 만나더라도 잘 알아가기
    • 신중함, 경청, 관찰
      • 저 사람은 어떤 사람일까? → 호기심을 갖고 질문하기
      • Active listening → 고개 끄덕이기, 추임새로 맞장구 등등
    • 충전은 혼자서
      • 어떤 세션은 혼자 듣기
      • 다음 날은 오롯이 혼자 보내기
• how 네트워킹?
  • 상황별 전략
    • 지인과 함께
  • 팔로업
    • 메시지 남기기
      • 내용 예시
        • 어디서 만났는지
        • 인상적이었던 대화 내용
        • 상대와의 공통점 : 대화 내용, 프로필 참고
    • SNS 팔로잉
      • 프로필 세팅 미리 해두기
        • 헤드라인 문구, 이력, 동아리/프로젝트 등
      • 댓글, 포스팅 태그 등
        • 사진 예쁘게 찍어 포스팅 후 태그하기
  • IT 행사에서 적용하기
    • 컨퍼런스/세미나
      • 컨퍼런스 연사
        • 뒤풀이, 연사 대기실 이용
      • 참가자
        • 네트워킹 유무에 따라 앞서 제시한 방법 활용해보기
    • 해커톤
      • 팀 빌딩, 해커톤 후 뒤풀이로 같이 놀기
    • 행사/커뮤니티 자원봉사
      • 가장 자연스럽게 연사, 커뮤니티 운영진과 대화하고 친해질 수 있는 계기
• For community organizers
  • 그룹 네트워킹일 때
    • 그룹화가 가능하다면, 관심사/직무에 따라 자리를 정해주기
    • 대화 주도를 해줄 수 있는 사람이 필요 → 없으면 금방 해산해버림
  • 자유 네트워킹일 때
    • 서성이는 사람들에게 먼저 인사하고 말걸기, 다른 사람과 연결해주기

 

후기 : 소심해서 카카오톡 톡방, 링크드인등을 활용하기 시작하고 직접 가서 인사드리는등 개인적으로 많이 발전했다는걸 느꼈고,
         강연해주셨던 뒤풀이, 같이 컨퍼런스 듣기등을 해보고 싶다는걸 느꼈다. 

         조심스레 해볼 수 있는 것들이 은근 있다는게 놀라웠다.

 

3. 사수 없는 주니어 개발자가 성장하는 방법 - 이승민

• 주니어가 절대 가지 말아야 할 회사
  • 사수 없는 회사 → 성장할 수 없다!!!
• 발표
  • 여러 행사에서 발표로 지식과 경험 공유
  • 장점
    • 알고있는 지식을 정리할 수 있다
      • 흩어진 지식들의 연관관계를 명확히 한다
      • 그냥 사용하던 기술들의 원리를 파악한다
    • 업계 사람들이 나를 기억하기 시작해요
      • 내 브랜드가 생겨요
  • 발표하기 어려운 가장 큰 이유 : 자신감 부족
    • 다 아는 내용일거 같은데 의미있을까? → 누군가에게는 의미가 있다
    • 틀리면 어떡하지?
      • 조금은 틀려도 괜찮다. 알아서 걸러 듣는다
      • 경험에 자신감을 가져라
• 블로그
  • 블로그로 지식과 경험 공유
  • 발표보다 컨텐트가 더 오래 남는다
  • 브랜드 형성에 더 큰 도움이 된다
  • 개발자 브랜드를 쌓으면 왜 좋은가요?
    • 유명 ≠ 고수
    • but, 유명하면 기회가 많다
  • 블로그 쓰기 어려운 이유 : 자신감 부족
    • 다 아는 내용일거 같은데 의미있을까? → 누군가에게는 의미가 있다
    • 틀리면 어떡하지?
      • 조금은 틀려도 괜찮다. 알아서 걸러 듣는다
      • 경험에 자신감을 가져라
• 커뮤니티
  • 지식을 공유하는 훌륭한 개발자들과 직접 지식을 주고받는다
  • 참여방법
    • 지식을 나누면서 커뮤니티에 기여
  • 단점
    • 시간은 많이 들어가는데 물질적 보상이 없다
  • 커뮤니티를 지속하려면 내적 동기를 만들어야 한다
    • 지식공유의 즐거움, 사람들과 교류하는 즐거움
• 스터디/사이즈 프로젝트
  • 학교, 회사, 커뮤니티
    • 관심사가 맞는 사람들과 스터디/사이드 프로젝트
  • 단점
    • 현생을 살면서 저녁시간 투자가 힘들다
  • 맞는 사람들끼리 교류하면서 완주하다보면 풍성해진 나를 보게 될 것이다
• 연합 동아리
  • 대학생, 사회 초년생 함께 팀 프로젝트
    • 기수가 있고 주기적으로 발표회도 가진다
  • 기술적인 기회도 좋지만 협업을 경험하는 것이 큰 장점
  • YAPP, SOPT, 디프만, MAsh-up, Nexters…
• 오픈소스
  • 개발 업계만 있는 축복받은 문화
  • 장점
    • 글로벌
      • 여러 나라로부터 발표 초청
      • 외국계 회사 리모트 입사 기회
    • 장소와 시간에 제한받지 않고 전세계 개발자들과 교류하며 성장이 가능한다
• 야근
  • 가장 성장할 수 있었던 방법이었다
  • 새로운 프로젝트를 잘 구축하는 것 VS 만들어진 코드에서 새로운 요구사항을 잘 반영하는 것
  • 회사 업무
    • 못 바꾸는 레거시 코드
    • 많은 사용자
    • 복잡한 요구사항
  • 사수 없이 회사의 문제를 풀기에 시간이 부족 → 야근이 필수….
  • 사수 없이 회사 일을 열심히 하면
    • 스스로 복잡한 문제들을 해결하고 하고싶은 기술을 모두 적용해보며 경험의 폭을 빠르게 성장할 수 있다.
• 즐기기
  • 지치지 않으려면 좋아하는 일을 해야한다
  • 퇴근하고 즐길 수 있는 성장 방법을 찾는다면 매일 할 수 있다 → 성장 가능
• 마무리
  • 동기에 집중하면 습관이 쌓이고 성장은 따라온다
  • 과정을 즐길 수 있는 시스템을 만들면 행복하고 건강하게 성장할 수 있다

 

후기 : 사수 없이는 굉장히 힘들겠다는 생각도 들었고, 아직 직업은 아니지만 프로그래밍을 좋아하고 있어서 추후에

          번아웃등이 오게되면 시도해볼 방법을 알 수 있을 것 같다.

 

4. 100명의 개발자분들을 도와 100개 넘는 오픈소스 PR을 함께 만들고 세상을 바꾼 이야기 - 김인제

후기 : 아직 아는게 많이 없지만 오픈소스에 기여해서 다른 분들께 도움이 되었으면 좋겠다는 생각을 하게되었다.

         프로그래밍을 시작하게된 계기가 다시 상기되는 섹션이었다.

         유익했고,  오픈소스 기여 참여해 보고싶다.

 

5. DB를 느리게 만드는 다양한 방법들! - 강성욱

• 사람이 생각하는 방식이 아닌 옵티마이저 관점에서 생각
• 문제를 바르게 인식하기
  • 엔드 포인트의 장애는 전체 장애로 확산
    • 데이터베이스는 대부분의 시스템에서 엔드 포인트를 담당
    • 쿼리가 느리다는것을 어떻게 판단하나요?
      • 응답속도?
      • 실행계획 분석?
      • 느낌?
  • 어떤 문제를 해결할 때에는 문제의 정의부터 명확히 필요
    • DB 성능을 이야기 할 때에는 순수 DB 관점에서 파악
    • client, internet, web server + application server, database server등등 전체를 보지말고 database server를 보자
  • DB는 코드만 살펴봐도 어느정도 성능 예측이 가능
    • 데이터가 어떻게 적재될지 알고 있음
    • 이미 쌓여진 데이터가 있음
    • 스키마가 사전에 정의되어 있음
    • 사용자 패턴을 알 수 있음(인덱스 설계)
    • DBMS의 물리적 특성을 알고 있음
  • ORM이 알아서 해주는데 쿼리를 알아야 할까?
    • Object Relational Mapping(객체-관계 매핑)
    • ORM에 의존하지말고 읽을줄을 알아야한다
  • 쿼리를 읽는 방법
    1. From 절
    2. WHERE 절
    3. ON 절(JOIN 테이블 경우)
    4. SELECT 절
    5. etc…
  • 쿼리를 분석하는 방법
    • 테이블의 정보를 수집
      • 생성된 인덱스 확인
        • WHERE절, ON절에 사용된 키가 인덱스에 있는지 확인
        • SELECT에 사용된 컬럼이 인덱스에 포함되어 있는지 확인
      • 제약 조건 확인
      • 컬럼의 속성 확인
        • 조회하려는 컬럼의 길이가 얼마인지 확인
    • 데이터 확인
• 인덱스 기초 이해
  • 클러스터 인덱스
    • 인덱스 키 값을 기반으로 테이블 데이터 행 전체를 정렬해서 저장
    • B-Tree 구조
    • 리프 레벨에만 데이터 전체가 저장
    • 고유 컬럼이면 UNIQUE 인덱스로 생성할 것 권장
      • UNIQUE로 설정되어 있지 않으면 고유한 주소값을 만들기 위해 4Byte의 uniquefier정보를 추가로 저장
    • 키 값으로 정렬된 넓은 범위 검색에 유리
    • 테이블당 1개 인덱스 생성 가능
  • 넌-클러스터 인덱스
    • 테이블과 별개로 인덱스 키로만 구성된 별도의 B-Tree 인덱스 영역 생성
    • 고유 컬럼이면 UNIQUE 인덱스로 생성할 것 권장
      • UNIQUE로 설정되어 있지 않으면 고유한 주소값을 만들기 위해 4Byte의 uniquefier 정보를 추가로 저장
    • 테이블(뒤에 못적었어ㅓㅓㅓㅓㅓ)
  • 클러스 인덱스와 넌클러스 인덱스의 순서가 중요하다 → 중복으로 생성되어 다른 스키마가 잠기기 때문
  • 인덱스 크기가 중요한 이유
    • 인덱스 깊이가 깊어 질 수록 성능에 영향을 받는다
    • 키의 크기가 작을 수록 페이지당 밀도가 높아 검색 효율이 높음
• 다양한 사례를 통한 튜닝 전략
  • 컬럼의 순서는 중요하지 않다
    1. 쿼리 파서는 SQL 문장을 잘게 쪼개서 서버가 이해할 수 있는 수준으로 분리 하여 트리 형태로 구조를 생성(파스트리)
    • 문법 확인
    • 쿼리 문장에 구조적 문제가 있는지 확인
    • 객체의 존재 여부과 접근 권한등을 확인
    • 쿼리 오류나 권한이 없을 경우 이 단계에서 걸러진다
  • 최적의 경로 찾기
    1. 옵티마이저는 쿼리를 가장 저렴한 비용으로 가장 빠르게 처리할 수 있는 방법을 결정하는 역할 담당
    • SQL의 파싱 정보를 확인하여 어떤 테이블을 읽고 어떤 인덱스를 읽을것인지 선택 - 최적화 및 실행계획 수립 단계
    • 쿼리 플랜 생성
    • 대부분 옵티마이저가 선택하며, 옵션과 힌트로 사용자가 더 나은 선택을 할 수 있도록 유도 가능
  • 쿼리 실행
    1. 쿼리 플랜을 실행
    • 스토리지 엔진은 레코드를 반환
    • SQL엔진은 조인, 정렬등 작업 수행
    • 최종적으로 실행
  • 반드시 필요한 컬럼만 조회한다
    • Lookup 최소화
    • 인덱스에 없는 컬럼의 데이터를 조회하기 위해서 실제 데이터 페이지에서 데이터를 조회하는 과정
    • Non-Clustered
    • Lookup은 인덱스 페이지의 주소값을 이용한 랜덤 액세스 방식으로 실제 I/O비용이 많이 발생함
  • 복합 인덱스는 컬럼 순서가 중요하다
    • 선행 컬럼에 따라 성능 차이가 크다
    • 복합 인덱스여도 트리 높이가 동일하면 검색 속도가 동일하다
  • 형변환 주의
    • 데이터 타입 불일치로 암시적 형변환 발생시 인덱스 사용할 수 없음
      • 데이터 타입을 준수하여 조회 쿼리 작성
  • 부정 조건은 긍정 조건으로 최대한 변경하여 사용
    • 기본적으로 RDBMS는 부정 조건 (NOT IN, ≠, <>등)은 인덱스를 활용하지 못한다
    • NOT IN, ≠는 OUTER JOIN으로 변경하여 NULL 검색으로 치환
      • 조인 조건에 따라
  • 데이터 존재 유무 판단을 하는 다양한 방법
    • EXISTS 추천
    • EXISTS : 1행으로 검색되면 TRUE를 반환하고 종료
  • UNION ALL과 UNION 차이점 이해
    • 두 개 이상의 결과를 합쳐서 보여줄때 UNION 또는 UNION ALL 사용
    • UNION 대신
  • 불필요한 정렬, 그룹화는 성능을 느리게 만든다
    • 정렬에는 많은 리소스 비용이 소모
    • 반환되는 결과가 작다고 쿼리 비용이 적게드는것이 아니다
  • 조인은 약이 되기도 하고 독이 되기도 한다
    • 첫 테이블은 작게 가져가는게 좋다
    • 조인을 제대로 이해하고 사용하지 않으면 매우 심각한 문제 발생
  • 사용자 함수는 정말 주의해서 사용
    • 결과 ROW 수 만큼 함수가 호출 되어 실행
    • 수행 횟수 최소화 중요
    • 함수 내부 최적화 중요
  • 서브쿼리는 정말 느릴까?
    • 스칼라만 느리다 → ROW 수 만큼 호출되기에…
  • Lookup이 데이터가 적을때는 큰 차이가 없지만 점점 비용이 크게 증가한다

강연이 조금 빠르게 넘어가서 못적고 구멍이 난곳이....

 

후기 : 아직 초보 백엔드 공부하는 학생이라 아는 내용보다 모르는 내용이 많았던 것 같지만 부가적인 설명으로 쉽게 설명해주셨고,
         오늘 알게된 내용이 흥미진진해서 프로그래밍 욕구가 더욱 뿜뿜해진 섹션이었습니다.

         카톡방에 계신분을 실제로 보니 뭔가 연예인 본 기분...

 

6. 터닝포인트 / 한국화 전공생의 개발자 생존기 - 송민정

• 내가 이걸 질문해도 괜찮을까?
  • 순서도나 구성도를 그리며 구체적으로 질문
  • 필요한 데이터, 업무 진행 방향 점검
• 내 코드가 괜찮을까?
  • 꾸준한 학습을 위한 노력
  • 다양한 스터디 참여
  • 코드리뷰 적극 활용
  • 매일 오전 코드 리마인드 시간 갖기
• 집중력과 업무단위 작게 만들기
  • 뽀모도로 기법 사용하여 완결성있게 업무 진행해보기

 

후기 : 맨 처음 이 섹션을 고를때 그림쪽 용어인줄 모르고 한국의 전공생들은 어떻게 생존하는가?에 대해서 강연하실 줄 알았다.

          알고보니 비전공자의 개발자 생존기였던것!
          이해가 안되서 통으로 외운다는게 대단하셨고 부러웠다! 기억력 절반만요....

 

7. 후기

• GDG 행사들을 매년 있을때마다 들을만한 세션이 있는지 보고 참여했었고, 이번에도 참여를 했는데
  매년 내가 성장한 상태로 세션을 참여하면 받는 느낌이 이렇게 다르구나! 라는걸 느꼈다.
• 티켓 신청할때 예전처럼 티셔츠 사이즈를 선택할 수 있으면 좋겠다
  이번 티셔츠도 옷장행....