2024년 03월 30일, 송도 컨벤시아에서 진행한 HelloWorld 24에 다녀왔습니다.
한국에는 14개의 Google Developer Groups가 운영되고 있으며, 이번 행사는 GDG Incheon&Songdo 주최로 진행되었습니다.
HelloWorld 24에서 제가 참여했던 세션의 주요 내용과 인상깊었던 인사이트를 공유해보고자 합니다.
전문대 비전공 출신이 커뮤니티를 만나서 해외 취업과, 팡(FAANG) 까지 가게된 이야기 - 강성욱님
커뮤니티에서 성장하기
혼자서도 성장은 가능하지만 커뮤니티에서 함께 성장해나가는 과정은 더 강력한 시너지를 만들어 낼 수 있다.
누군가를 가르치고, 강제로 공부할 수 밖에 없는 환경에 속하고, 질문하며 내가 모르는것을 알아가는 과정은 함께 성장하는 과정에서 얻을 수 있는 이점들이다.
이런 과정에서 새롭게 알게된점이나 꾸준한 실습을 통해 공부한 내용들을 블로그로 정리하면 나만의 콘텐츠가 된다.
커뮤니티 운영자로 활동하기
커뮤니티 운영자로써 참여자들과 소통하고 관계를 형성하면서 다양한 정보들을 접할 수 있으며 커리어 발전에도 긍정적 영향을 얻을 수 있다.
커뮤니티 운영자로 활동하며 다양한 경험을 통해 개인의 역량을 향상시킬 수 있다.
커뮤니티를 운영하며 다양한 상황에 대한 대비와 문제 해결을 위해 노력하는 과정에서 개인의 역량을 향상시킬 수 있다.
학력 컴플렉스와 해외취업
멘토나 사수의 역할의 부재 → 커뮤니티에서 해소
커뮤니티의 도움 + 주경야독으로 학력 컴플렉스 해결
해외취업/이민생활 → LA에서 커뮤니티를 만들어 큰 힘이 됨
성욱님은 커뮤니티를 통해 위와 같은 도움을 받을 수 있었다고 한다.
회사에 멘토나 사수가 없는 경우, 학력에 대한 고민 또는 커리어 고민으로 도움이 필요한 경우에도 커뮤니티에서 도움을 받거나 줄 수 있다.
커뮤니티를 어떻게 시작할 수 있을까?
커뮤니티를 통해 성장할 수 있는 부분들
- 기술에 대한 부채 해소 및 선배의 노하우 습득
- 커뮤니티에서 역할을 수행하며 리더십 향상
- 결국 사람들의 모임이기에 다양한 사람들을 알게 됨
- 사수가 없거나 회사에서 혼자일 경우 커뮤니티를 통해 친목, 소속감 해결
- 공동체 활동을 통한 협업능력 향상
요구사항부터 배포까지 SDLC 전 주기 느껴보기 - 김성진님
SDLC의 개념과 필요성
- SDLC는 소프트웨어 개발 수명 주기(Software Development Life Cycle)를 뜻하는 생성 ↔ 사용 ↔ 소멸 까지의 일련의 과정이다.
- 비용 절감과 효율성 증대 등 경제적 이점이 있다.
SLDC의 단계
1. 요구사항 분석단계
기획자, 고객등의 요구사항 수정
1) 정말 필요한 기능인가?
- 한정된 리소스에서는 요구사항을 통하여 본질적으로 해결하고자 하는것, 원하는것이 무엇인지 파악하는게 중요하다.
2) 기존 기능과의 영향도 확인
- 신규 개발, 기능 추가시 영향 범위 확인
- 버그 수정시 기존 기능 FLOW 영향 여부 확인
→ 정상의 비정상화, 비정상의 정상화가 발생할 수 있다.
3) 기술적으로 개발 가능한 부분인지 확인
2. 요구사항 명세
1) 기능설계 & 화면 설계
- 기능설계 : 구현할 기능에 대한 설계 문서화
- 화면설계 : Figma 등을 이용하여 화면설계 명시화
2) 설계시 고려할 점
- 하위 호환성을 지켜서 설계
- 대응/확장 가능한 설계
- 추후에 추가 요구사항이 들어왔을때 대응이 가능한가?
- 대용량 데이터, 성능을 고려한 설계
예측 가능한 상황이라면 기획자와의 협의를 통해 추후 이용자수 증가, 성능 향상이 요구 될 가능성을 판단하여 확장성을 고려하여 설계한다.
3. 구현(개발)
- 직관적인 변수, 함수명 사용
- 적절한 자료구조와 알고리즘 사용
- DB 고려 개발
4. 테스트
- 로컬 Test
- Git CI/CD
- QC, QA
5. 배포
- 여러 모듈을 수정하고 한꺼번에 배포하는 경우 영향도를 확인하여 배포 진행
6. 유지보수 단계
- 배포 후 검토, 버그 수정 및 패치
- 스프린트 회고
- 일정 준수가 잘 되었는가
- 일정을 준수하지 못했다면 이유가 무엇인가
- KPT 회고방식을 이용하기도 함
NPM 속 보물 찾기 : 오픈소스로 공부하자! - 전창완님
1. 탐색하기
탐색방법
- 검색엔진을 통하여 검색하기 : GPT, Gemini, Claude
- 전통적인 탐색방법 이용하기
NPM Trends 로 내가 사용할 라이브러리 찾아보기
- 다운로드 수, 최종 업데이트 일자 확인
- NPM Trends에서 패키지 검색시 추천해주는 비슷한 패키지를 확인해보기.
- 다운로드 수가 높을 수록 대다수 개발자가 표준으로 사용, 좋은 패키지일 가능성이 높다.(다만, 다운로드 수가 코드의 퀄리티를 보장하지는 않는다.)
- 다운로드 수가 높은 경우 최초 효과일 수도 있으니 프로젝트 생성일을 확인해봐야한다.
NPM Trends의 차트 시그널 판단하기
- 검색엔진 보다 차트 시그널을 판단하는것이 중요하다.
- 다운로드가 정체되지 않았는지, 다른 패키지의 다운로드수가 급격하게 오른 경우 표준 패키지가 교체되었다는 시그널이다.
- 실제 유행하는 패키지와 실무에서 많이 사용하는 패키지는 다르다 (jQuery…..)
의존성 살펴보기
- 라이브러리가 의존하는 라이브러리를 확인해보기
- Dependencies : 현재 프로젝트가 의존하고 있는 외부 패키지들, 다른 패키지의 기능을 사용하기 위해 필요한 패키지이다.
- Dependents : 다른 프로젝트에서 현재 패키지를 의존성으로 사용하고 있는 패키지들, 현재 패키지가 dependents 패키지들에 의존되고 있다는 뜻이다.
- 라이브러리의 의존성
- 실제 기능 구현 위주의 라이브러리
- 편의를 위한 추상화 라이브러리
→ 라이브러리에서 근본적으로 작동하는 코드가 어떻게 작성되었는가? 를 확인해봐야 한다.
2. 분석하기
겁먹지 말고 익숙해지기
언어를 사용할수록 익숙해지듯 코드를 읽고 또 읽다보면 익숙해진다.
(minified 된 코드도 보다 보면 읽힌다!)
2-1. 문서부터 보기
시간이 없는 경우 목차와 예제코드만이라도 확인
시간이 있는 경우 문서 틈틈히 읽어보기
*Can I Use → News 탭 : 브라우저와 관련된 모든 피쳐 업데이트 확인 가능
2-2. 의존성
의존성만 확인해도 프로젝트의 기능을 알 수 있다.
2-3. 기능단위로 코드 찾기
모든 코드를 다 보려면 오래 걸리니, 원하는 부분만 찾아서 기능을 살펴보자
조금씩 읽다보면 어느순간 패키지 전체가 머릿속에 그려진다.
- 알고있는 힌트(문자열, class property 등..)를 검색해보자
- 의존성을 사용할 것 같은 곳 import 구문을 찾아 추적해보자
문자열로 찾고, 의존성으로 찾고, 내가 알고 있는 모든 정보로 찾으면 된다.
3. 비교하기
-
코드에서 반복되는 표현 살펴보기
Adapter, Proxy, Decorator, Observer 등의 반복되는 이름 → 디자인 패턴 -
다른 언어의 동일한 패키지 살펴보기
- 다른 언어로 작성된 동일한 패키지 코드도 같이 훑어보기
- 오래된 언어가 구조가 단단한 경우가 있다.
- 전체적인 구조는 비슷할 수 있지만 파일 내부 코드는 다를 수 있다.
오픈소스로 공부하려면
탐색하기 → 분석하기 → 비교하기 → 클론코딩루틴을 반복하기- 다른언어의 동일한 패키지가 존재하지 않는 경우 클론코딩 해보기
시간과 돈을 줄여보자! 최소 비용으로 서비스 만들기 - 김노트님
목표
적은 리소스로 프로젝트 만들기
기획 → 제작 → 출시 및 이후 피드백
유의해야 할 점
- 완벽하게 하려 하지 말기
- 뭘, 왜 하는지 알기
- 핵심에 집중하기
- 솔루션은 가능한 심플하게 하기
- 낭비하지 말기
1. 기획
-
기획이 어렵다고 느끼는 이유는 처음부터 모든 기능을 완벽하게 구현하려 하기 때문
⇒ 하나의 종이에 주요 기능만 적어보기 -
일이 커보여서 시작하지 못하는 경우
⇒ 기능을 잘개 쪼개서 우선순위 정하기 -
Product의 확신과 확산성 고려하기
제일 중요하거나, 자신있거나 라고 생각하는 것들을 정하고 가중치를 부여한다.
주관적 기준에서 책정될 수 있으니 회의를 통해 도출하는 것이 좋다. -
기획의 구체화/정리 필요
→ 무얼 만드는지, 왜 만드는지 알고 만들기
2. 제작 (디자인, 개발)
기획을 기반으로 디자인, 개발 진행
최소비용의 서비스 도출시에는 명료하고 빠르게 구축하는것이 좋다.
디자인
- 간결하고 빠르게 output 내기
- 사용자의 최고 경험을 기반으로 구현하고 리소스 줄이기
→ 실제 서비스 중인 디자인 참고
→ 사용자를 헷갈리게 하지 않는 것이 중요하다.
→ 어렵다면 세팅된 디자인을 사용한다. 코드를 만드는것도 낭비일 수 있다. - Figma(피그마), 레퍼런스 사이트의 도움받기
개발
-
구현
- 기술 욕심 버리기, 효율적으로 사용하기
- 빠르게 구현하고 피드백 사이클을 돌며 수정하기
-
배포
- supabase, Firebase, AWS, Vercel …
-
테스트
- 최소 비용으로 서비스를 만들 때 테스트는 이유가 있어야 한다.
-
아키텍처
- 모던 != 복잡
- 생산성에 이점을 가져오는것, 생산성이 최우선이다.
- 본인에 수준과 상황에 맞는 best practice로 진행
-
학습용이라면 다양한 기술, 테스트, 아키텍처 사용하여 구현해보기
-
어떤것을 만들때는 이유를 가져야 한다.
나 스스로 구현 방법 별 이점을 파악 한 후, 구현시 특정 방법을 선택한 이유를 설명할 수 있어야 한다. -
개발시 효율성을 고려하기
- 생산성 증가, 효율 증폭을 위해 단축키나 스니펫 등을 사용
- 개발하는 것을 화면녹화하여 나의 개발습관을 파악하고 개선하기
ex) 변수명 짓기에 어려움을 느낀다. → 익숙치 않거나 너무 신중하기 때문에 → 개인의 역량 부족이거나 욕심이다. → 일단 아무이름으로 짓고 나중에 변경하자
3. 출시와 그 이후
1) 제품 알리기
나의 제품을 사용할 고객이 모인 곳에서 제품의 가치를 알리기
- 가치를 알릴때는 직관적, 명확성이 중요하다. (추상적이면 안된다)
2) 피드백 받기
- VOC (고객의 소리) / 앱리뷰
- 지표 확인 재방문률, 이탈률도 피드백이다.
- 구글 애널리틱스
- Clarity : 사용자 행동 패턴 분석
3) 수정하기
비용을 아낄 수 있는 무료 소프트웨어
느낀점
HelloWorld 24를 참여하고 나서 실무에서 부딪히던 기술적 고민과 혼자 해결하려 애쓰던 문제들에 대해 해결책을 찾을 수 있었다.
연사자분들의 경험과 지식을 통해 다양한 접근 방식을 배울 수 있었고 실무에 적용 가능한 방법에 대해 스스로 조금 더 명확한 기준을 가질 수 있게 된 것 같다.
또한 커뮤니티의 중요성과 가치에 대해 깨달았고 커뮤니티에 적극적으로 참여해야겠다고 느꼈다.
이전까지는 커뮤니티에 참여하려면 완벽하게 준비된 기버(Giver)가 되어야하고 생각해서 선뜻 나서지 못했었는데 작은 활동부터라도 시작해 나아가는 것이 중요하다는 것을 깨달았다.
앞으로는 망설임을 내려놓고, 적극적으로 커뮤니티를 참여하여 성장하고 도움을 줄 수 있는 사람이 되기위해 도전해야겠다.
