[Review] Hello World24 컨퍼런스 회고

회고 시작

2024/03/30 인천 송도 컨벤시아에서 GDG Incheon에서 개최한 [Hello, World 24] 컨퍼런스에 다녀왔습니다. 

 

총 25개의 세션이 준비되어 있었으며, Tech, General 두 개의 주제의 챕터를 구분하여, 개발자 커리어와 테크 기술에 대한 이야기를 진행한 컨퍼런스였습니다. 따라서 본인이 미리 듣고 싶은 챕터의 세션이 있으면 시간 분배를 잘 하여 미리 선정해 놓는 것을 추천드립니다!

 

👩🏻‍💻 컨퍼런스를 가게 된 이유

가장 먼저 현업에 계신 분들의 이야기를 많이 들어보고 싶었어요. 저는 아무래도 신입 개발자이고 취업을 준비하고 있는 상황이다 보니 현업에서 일어나는? 고민하는? 분야에 접하고 싶고, 궁금한 점이 많았는데 이 궁금증을 해소할 수 있는 기회가 오질 않았었어요. 그래서 직접 찾아보게 되었고 때맞춰 Hello-World! 2024 컨퍼런스를 인천 송도에서 진행한다고 하여, 기대감을 안고 바로 접수하여 참여하게 되었어요 :) 

저는 궁금증이 생기면 꼭 풀어야 하는 스타일인데 그 푸는 과정에서 그냥 건너 건너 블로그를 찾아보는 방법도 물론 좋은 방법이지만, 현직, 현업에 있는 사람들의 이야기를 직접 들을 수 있다는 것이 가장 정확하고 좋은 방법이라고 생각했어요. 다음번에도 이런 컨퍼런스 자리를 찾아서 개발 지식의 깊이를 깊게 만들어가고 깊이 있는 개발자가 되고 싶다는 생각을 다시 한번 하게 되었어요 🙋🏻‍♀️

 

저는 시간대 별로 평소 궁금했던 개발 주제나 고민했던 부분을 주제로 고르게 되었는데요, 연사님들 모두 현업에서 일하시는 개발자분들이셨기에 기술에 대해 어떻게 고민하고 풀어가는지 알 수 있었고, 그 과정을 발표로 지식 공유하는 모습을 보고 신입 개발자인 저의 입장에서 많은 동기부여가 되었던 시간이였습니다. 

 

✔️ 참여한 세션 

1. 학생/신입/주니어 개발자가 취업 빙하기 속 살아남는 법 - 윤창현 연사님

2. 요구사항부터 배포까지 SDLC 전 주기 느껴보기 - 김성진 연사님

3. RESTful API 이해하기 - 남기범 연사님

4. NPM 속 보물찾기 : 오픈소스로 공부하자! - 전창완 연사님

5. 리액트에서 타입 좁혀나가기 - 임성호 연사님

 

 

1. 학생/신입/주니어 개발자가 취업 빙하기 속 살아남는 법

🙋🏻 윤창현 연사님

 

📍 세션 요약

• 결과 보단 과정
  - 취업 이력서 및 포트폴리오에 너무 기술적으로 어필할 필요 없다. 신입에게는 결과보다 과정이 중요하기 때문이다. 즉, 과정이란 공부하는 과정. 그걸 왜 했고 그걸 배우면서 어떤 어려움이 있었고 어떻게 해결했는지 이러한 과정이 중요하다.
• 발표를 두려워하지 말기
  - 앞서 나가서 발표해 보는 경험이 좋다. 발표를 통해서 발표 분야에 깊게 파볼 수 있는 시간이기도 하고 많은 사람들과 질의응답을 통해 더 깊이 학습할 수 있는 기회이기 때문이다. 
• 각종 커뮤니티에서 활동하기
  - 개발자와 소통의 기회가 생긴다.
• 기본기부터 준비하기
  - 프론트엔드 개발자에게도 CS는 중요하다. 그리고 프레임워크보다 언어를 잘해야 한다. 프레임워크는 언어를 잘 쓰기 위한 도구이기에 도구를 쫓지 말고 언어를 쫓아야 한다. 
• 깃헙에서 신경 써야 할 부분
  - 커밋 메시지
• 사람을 뽑기 위해서 면접관 입장에서 볼 때 중요한 포인트는 이력서에 나를 포장하는 게 아니라 내가 질문받고 싶은 걸 적어야 한다.

 

2. 요구사항부터 배포까지 SDLC 전 주기 느껴보기 

🙋🏻 김성진 연사님

 

📍 세션 목적

• SDLC가 실무에 어떻게 녹아들어 가 있는지 공유

📍 세션 요약

• SDLC란 Software Development Life Cycle의 줄임말이다. 
  • Life Cycle은 생명주기인데 React의 생명주기는 컴포넌트가 생성되고 소멸될 때까지의 과정을 나타내듯 소프트웨어 개발에 필요한 일련의 과정을 말한다. 
  • 일반적으로 6가지 단계
    • 요구사항 분석 → 설계 → 구현 → 테스트 → 배포 → 유지보수 단계
  • 왜 필요할까?
    • 개발 생산성을 향상해야 하고 인건비는 줄이고 효율적으로 운영할 수 있기 때문이다.
• SDLC 모형 
  • 폭포수/프로토타입/나선형/애자일 등 있다.
  • 보통은 애자일 방식으로 돌아간다. 연사님은 현업에서 애자일 방식으로 진행하고 있다고 하셨다. 

1. 요구사항 분석 단계 기획자 개발자
   기획자가 중요한 단계이다.
   - 고객사, VOC 등 각종 경로로 요구 사항 수집
   - PO/PM이 수집한 요구사항 분석 및 명세
   - 해당 요구사항이 주어진 시간 내에 적절히 개발될 수 있을지 판단
2. 요구사항 수집 기획자 개발자
   ex. ~~~ 기능 추가해 주세요 → jira에 하나 두 개씩 쌓아둔다.
   - 기능 추가뿐만 아닌, 이슈/보안 등에 관련된 요구사항을 수집해 놓는 단계이다.
3. 요구사항 분석 기획자 개발자
   - 진짜 필요한 기능인가 → 필요한 게 뭔지 분석하는 게 중요하다
      → 왜 중요하냐 고객이 원하는 니즈 즉, 정말 원하는 건 무엇인가 판단력이 중요하기 때문
   - 기존 기능에 영향도 
       → 기존에 있는 데이터를 어떻게 처리할 건지, 버그를 수정했을 시 기존에 해당하는 기능을 사용하던 User의 flow에는 변화가 없는지 모든 케이스 전수 조사하는 등의 영향력을 파악해야 함
   - 기술적으로 가능한 건가
   
   → 즉, 개발자 혹은 요구자와 커뮤니케이션하면서 요구사항 구체화
4. 요구사항 명세 기획자
   - 기능 설계 → 설계화, 문서화 등
   - 화면 설계 → Figma 같은 도구 활용
5. 설계 단계 개발자
   - 설계할 때 고려할 점
     → 하위호환성을 지켜서 설계 : 개발 중인 제품, 무조건 지켜지지 않아도 감수할 수 있는데 이미 개발된 제품이라면 어렵다.
   ex. API 주소가 변경되었어요. Response 값이 수정되었어요. → 배포하고 보니까 프런트는 과거 Response를 받고 있고 backend에서는 새로운 Response를 받고 먼저 추가하고 모든 유저가 최신 버전을 사용한다 했을 때 문제가 생김 → 이 상황을 많이 줄일 수 있는 게 하위호환성을 지켜서 설계하는 것
   
     → 나중에 추가 요구사항이 들어왔을 때 대응(확장) 가능한 설계
   ex. Silder Item 가운데 label을 표기해 주세요. → 중간이 아니라 특정 위치에 label을 표기해 달라는 요구를 고려해 봤을 때 label? : Array와 같이 확장할 필요는 없는지, 다국어 지원 안 해도 되는지 등 처음부터 차라리 나중을 생각해서 설계하는 방식
   
     → 대용량 데이터를 다룰 수 있는 설계, 성능을 고려하는 설계 → 처음 기능 구현에는 구현에 초점 맞춰 개발하는 경우가 많지만 시스템이 고도화되고 많이 이용될 수 록 성능 향상을 요구할 수 있다.
6. 구현단계 개발자 : 열심히 코딩하기 → 설계과정이 중요하기 때문에 설계를 잘해놨다면 코드로 풀어나가면 된다.
   1. 변수 이름, 함수 이름 짓기 : 혼자 개발하는 게 아니고 자신의 코드를 수십 명이 읽고 고쳐야 되는 환경이니 신경 써야 한다.
   2. 적절한 자료구조와 알고리즘 중요하다 : 시간 복잡도 줄이기
   3. BE라면 DB에 대한 기본지식
   4. React 개발이라면 불필요한 리렌더링 줄여보기 → 불필요한 state 줄이기
7. 테스트 단계 개발자 테스터
   Unit Test, Integration Test, E2E test
8. 배포 단계 개발자 DevOps
   배포해야 하는 게 하나가 아니라면 복잡해지고 신경 써야 할 게 많아진다.
   ex. MSA 구조에서 기능 구현을 위해 여러 모듈을 각자 A, B, C 개발자들이 수정을 했다. 근데 A 개발자는 모듈 A와 모듈 B만 수정하였으니 그 부분만 배포하려 하였으나 그럼 문제가 생긴다. B 개발자와 C 개발자도 연관되어 있는 하위 모듈들을 수정했기 때문에 순서대로 배포해야 한다. 
9. 유지보수 단계 기획자 개발자
   - 기능 구현하면서 건드린 코드 버그 원인 분석
   - 스프린트 회고 (일정 산정이 잘 준수되었는지, 준수되지 않았으면 이유가 무엇인지, KPT 방식으로 회고하는 것도 좋은 방법)

 

3. RESTful API 이해하기

🙋🏻 남기범 연사님

 

📍 세션 요약

• REST
  - REpresentational: (리소스의) 표현 State: 상태 Transfer: 전송
  → 클라이언트와 서버 간에 리소스를 표현하고 상태를 전송하는 아키텍처 스타일
• RESTful 한 게 대체 뭘까?
  - 어쩌다 탄생하게 되었는지
     → 인터넷과 웹 출현
     → 웹 서버와 웹 브라우저 →통신할 때 사용하는 프로토콜 HTTP 정의
     → public Domain 공개
  - Roy Fielding은 웹 호환성 고민 → HTTP Object Model → Rest라는 용어로 바뀌게 된다.
  - 언제부터 사용되었을까?
    → 처음 Soap이라는 프로토콜 사용 → 복잡해서 외면받음
    → filcker API (SOAP 복잡함 / REST 간결함) ⇒ 트렌드 REST API가 앞섰다. 
  - 이제 CMIS, Microsoft REST API Guidelines 등 REST API를 정의하는 데가 나오지만 REST 창시자인 Roy Fielding은 모두 REST는 없다고 말하게 된다.
  
• Roy Fielding이 말하는 REST API
  - REST 아키텍처 스타일을 따르는 API
      ⇒ 분산 하이퍼 미디어 시스템 (웹)을 위한 아키텍처 스타일 (아키텍처 스타일은 제약 조건의 집합이다)
  - REST를 구성하는 스타일
  → client-server / stateless / cache / uniform interface / layered system / code-on-demand(optional)
  
• 대부분 Uniform Interface 때문에 대부분 REST가 아니다고 말하였다.
  - Uniform Interface의 제약조건
    → identification of resources
    → manipulation of resources through representations
     → self-descriptive messages : 메시지는 스스로를 설명해야 한다. 
     → hypermedia as the engine of application state (HATEOAS) : 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다. 
  - 왜 Uniform Interface의 제약조건을 맞춰야 할까 → 독립적인 진화
• 좋은 API 디자인을 하기 위해 본질을 파고 들려 노력하는 게 좋다.
  • Roy fielding이 말하는 진정한 의미의 REST API를 구현
  • REST 원칙을 어느 정도 지킨 REST style을 참고한 HTTP API를 구현
  • 다른 API를 선택 ex.GraphQL
• 즉, RESTful이라는 건 6가지 제약조건을 모두 만족했을 때를 말한다.

 

4. NPM 속 보물찾기 : 오픈소스로 공부하자!

🙋🏻 전창완 연사님

 

📍 세션 요약

1. 탐색하기
   
   1. 프로젝트 탐색하기
      1. → 전통적 탐색 1. AI에게 물어보기 2. "~ alternative"키워드 검색에 활용
      2. NPM Trends 많이 사용 → 패키지 별 다운로드 수, 마지막 업데이트 날짜 등 비교 → 중요한 기능 : 패키지를 검색하면 비슷한 패키지를 추천해 줌 
         다운로드 수가 높다면,
         → 대다수 개발자가 표준으로 사용, 좋은 패키지일 가능성 높음 (다만, 다운로드수가 퀄리티를 보장하진 않음)
         → 최초 효과일 수 있으니, 프로젝트 생 성일을 한번 비교해서 확인해봐야 함
         → 다운로드 정체되어 있고, 다른 패키지 다운로드가 급격하게 올랐다면, 표준 패키지가 교체되었다는 시그널
         → 실제 유행하는 패키지와, 실무에서 사용하는 패키지가 다를 수 있다.
   2. 의존성 살펴보기 : pm2 (process manager) → 넥스트 서버에다 운영할 때 넥스트 실행되고 프로세스 죽으면 다시 되살려주는 것 → blessed / chokidar
   3. 고민해 보자 : 쉽게 vs 가볍게
2. 분석하기
   프로젝트 분석하기
   1. 겁먹지 말자 : 언어를 사용하면 할수록 익숙해지듯, 코드도 읽고 또 읽다 보면 익숙해진다.
   2. 일단 문서부터 : 시간이 없으면 목차 + 예제 코드라도 살펴보자
   3. 시간 나면 틈틈이 읽어보기
      - 언어 → ECMAScript spec, ECMAScript proposals
      - 런타임 → Node.js
      - can i use(News) → 웹 개발자 필수!! RSS도 지원함 브라우저에 추가되는 기능
3. 비교하기
   다른 언어의 동일한 패키지도 살펴보기 
   ex. Python, Java, PHP, Ruby
4. 클론 코드 하기

 

4. React에서 타입 좁혀 나가기

🙋🏻 임성호 연사님

 

📍 세션 요약

1. React에 대해 알아보기
   1. SPA (Single Page Application)
      한 번에 로딩되기 때문에 화면의 깜박거림 없이 하얀 화면 보는 게 줄었다.
      SPA 프레임워크 → React / Angluar / Vue
      ✔️ 컴포넌트 위주의 코드를 볼 수 있다
      ✔️ 선언적 ui 강조
      ✔️ 데이터 바인딩
   2. 선언적 UI : 코드가 무엇을 해야 하는지(What)를 설명하고, 그 방법(How)은 리액트에 맡긴다. 가독성 향상, 유지보수성 증가, 버그 감소
   3. 함수형 프로그래밍 : 함수는 입력(X, 정의역)으로 출력(Y, 치역)이 정해진다. → 함수
      ⇒ const identity = <T>(arg: T): T ⇒ arg;
      → 함수가 주어진 입력으로 일정한 출력을 할 수 없게 하는 것을 부수효과(Effect)라고 한다.
      → 그리고 이를 리액트 함수에는 useEffect 훅을 사용하여 다룬다.
      → 리액트에서는 부수효과를 잘 다루기 위해 useEffect 훅을 제공한다.
      → 데이터 가져오기, 구독 설정하기, 수동으로 리액트 컴포넌트의 DOM을 수정하는 것
   4. 렌더링
      → JSX ⇒ ReactElement
      → html ⇒ 트리구조 / react ⇒ 트리구조임
      상위에 있는 데이터를 아래의 컴포넌트에 전달할 땐 props로 전달 → 단방향
      → 만약 상위 컴포넌트의 상태가 바뀌어 컴포넌트의 props의 바뀌었을 때에도 새로운 엘리먼트를 만든다.
      ⇒ 렌더링 하는 과정을 보면 타입이 중요하다는 것을 알 수 있음
2. 타입스크립트 TypeScript
   자바스크립트는 동적 타입의 언어이다. → 개발자의 의도에 맞지 않은 형변환, 오류가 발생할 수 있다.
   1. 자바스크립트의 한계
      → TypeScript가 활성하기 전에, 이를 극복하기 위해 아래의 도구들을 사용했다.
      JSDoc, propTypes
      → 따라서 TypeScript가 중요해졌다.
      → 타입스크립트 등장 (microsoft)
      → 정적 타입 : 정적 타입 언어에서는 모든 변수의 타입이 컴파일 타임에 결정된다.
      → 컴파일을 한다. 컴파일에 대한 체크를 한다. 
      . ts ⇒. js 타입스크립트 코드들이 자바스크립트로 바뀌고 브라우저에서는 자바스크립트로 보여줌
      → 추천 Pretty TypeScript Errors → VSCode 있음
      
      슈퍼셋 : 타입스크립트는 자바스크립트의 슈퍼셋 ⇒ 자바스크립트의 확장된 개념
      
      자바스크립트에서 점진적 적용 가능
      ✔. js 확장자를. ts로 변경
      ✔️nolmpicitAny false
      ✔️타입 오류가 발생하는 곳에 any 사용하기
      ✔️모던 자바스크립트로 작성하기
      ✔️타입 좁혀나가기
      ✔️nolmpicitAny true
      
      → 구조적 타이핑
      타입의 형태만 같아도 같은 걸로 취급을 한다.
   2. 타입을 좁힌다 : 프로그래밍에서의 타입은 수학의 집합과 유사하다.
3. React + TypeScript
   1. 왜 유리할까?
      - 거짓된 타입을 제거한다. → 데이터 페칭 결과를 통한 예시
      - 옵셔널 체이닝
      - 사용자에게 정확한 기능 제공 → 타입을 줄이는 게 중요하다.
   2. 도구들
      - zod : 사용자에게 보이는 에러를 쉽게 정의할 수 있고 코드 내에서 정확한 타입 추론 가능하다.
4. 마무리
   프론트엔드 개발자는 사용자의 입력을 서버가 원하는 데이터 형태로 보내주고,
   서버의 데이터를 사용자가 원하는 형태로 보여주는 직무이다. 
   두 가지 일 모두 타입이 중요하다. 타입스크립트뿐만 아니라 zod와 같은 도구의 도움을 받을 수 있다.

 

✔️ 회고 마무리

이렇게 좋은 기회를 통해 미쳐 생각하지 못했던 부분을 캐치할 수 있었고 더 넓게 바라볼 수 있고 발전할 수 있는 뜻깊은 기회였습니다. 발표를 진행해 주셨던 연사님들이 많은 꿀팁을 알려주셔서 귀담아듣느라 바빴습니다. 한 글자 한 글자 놓치기 아까운 좋은 말들을 많이 해주셨기에 더더욱 동기부여 될 수 있었던 자리가 되었습니다.

 

앞으로도 이런 컨퍼런스 자리에 자주 참석해야겠다는 생각을 가지게 되었습니다. 올해 중 가장 알찼던 하루를 기록하며 :)