GDG FRONT-ENDGAME 참관 후기

2019-06-24

conference

front-endgame, gdg, velopert, 김민준, 나석주, 벨로퍼트, 서재원, 진겸, 천민호, 한근택, 한재엽

FRONT-ENDGAME: 여러분의 프런트엔드를 구할 어벤져스가 찾아옵니다
at 구글 스타트업 캠퍼스(구글 캠퍼스 서울)

컨퍼런스 참관기

컨퍼런스 참가 전

조금은 오그라드는 컨퍼런스 패러디 커버
FE 관련 컨퍼런스에 항상 등장하시는 능력자분들

이 두 가지 부분이 우려되어 참가를 고민하였지만 FE 끝. 장(Endgame) 컨텍스트에 이끌려 티켓팅을 하게 되었다.

170명 가량의 많은 참가자분들

언제나 반가운 스티커들

타이트하고도 긴 세션으로 구성되어있다.

여러분이 앵귤러를 안해봤다면 살아갈 이유가 하나 더 있는 겁니다.

천민호, PUBG & Festa

유난히 Angular에 대한 발표가 많은 컨퍼런스로 신기하다 생각했는데 시작부터 Angular 세션이었다.

React Seoul 2017에서 Decorator + HOC + React = Fantastic!!을 발표해주신 천민호님이 연사자로 등장

Angular를 도라에몽과 같다고 비유

PUBG의 프론트엔드 리드 개발자로 일하면서 Angular를 처음 접하게 되었고
처음에는 거부감이 들었지만 점점 도라에몽과 같은 Angular에 빠지게 되었다는 내용이었다.

이 화면이 Angular로 제작된 웹 페이지라고한다.

웹프레임워크 선택에 대한 의문점은 결국 앱의 상태와 화면을 동기화하는 과제에서 나오는데
이에 대한 설명을 정말 명쾌하고 잘 정리하게 풀어주었다.

Angular vs React

	Angular	React
관계	철저한 사육	철저한 방목
시점	우리를 사용자로 본다	우리를 개발자로 본다
동기화 방법	내가 알아서 해줄게	개발자가 명시적으로 동기화 setState()

- React

다양한 선택권
선택의 연속
개발자가 모든 것을 알아서 해야 한다.
Best Practice를 판단하기 어렵다.

Angular의 단점

높은 진입 장벽 (하지만 점점 낮아지는 러닝 커브)
- Directive
- TypeScript
- Template
- RxJS
많은 제약사항
- 개발자를 사용자로 느끼게 해준다.
- 활동 반경을 제한한다.

Angular의 장점

잘못된 길로 빠지지 않는다.
- 결국 Angular is Best Practice
TypeScript
- 팀 & 앱의 규모가 커질수록 큰 도움
RxJS
- 비동기 스트림계의 lodash
- 어차피 사용할 수 밖에 없다.
- 파편화되는 코드를 정리할 수 있다.
DI (Dependency Injection)
- 동일한 인터페이스 동일한 함수에 적용
- DI을 통해 분기문을 줄일 수 있다.

Q & A

Q: 게임에 웹을 도입했을 때 이점?
A: 사용자에게 서비스를 빠르게 서빙할 수 있다.
Q: Angular 최적화에 한계가 존재하는지
A: 결국 React와 비슷하다.
Q: 소규모 프로젝트에서의 이점은 없는지
A: Angular를 배워볼 수 있다.
Q: DI 시스템만의 차별화된 점이 있는지 (HOC와 비슷한가)
A: HOC와 DI는 비슷해 보이지만 비교 대상이 아니다.
Q: DI로 개선 효과는?
A: 분기문이 없어졌다.

느낀 점

국내에서의 Angular 시장은 이제 Vue에 점유율이 밀릴 정도로 작아지는
이 시점에서 천민호님의 발표는 매우 호응이 좋았다.
간결하게 잘 정돈된 내용과 적절한 비유는 오그라드는 발표 제목조차 청중을 납득시켰다.

UX빼면 시체, 프론트엔드

한재엽, 프론트엔드개발그룹 (FEDG a.k.a FEConf)

Blog: https://jbee.io/
Github: https://github.com/JaeYeopHan

웹 프론트엔드 전반적으로 다양한 활동을 하고 계신 한재엽님의 발표였고 UX란 무엇인가를 넘은 내용이었다.

발표자료: https://speakerdeck.com/jaeyeophan/uxbbaemyeon-sice-peureonteuendeu

단순한 문서만 주고받던 WEB이 30주년이 되었다.
과연 지금은 어떻게 변화하였는가

기술의 발전

SSR Page Serving
ES3 / Ajax (1999)
Gmail (2004)
jQuery (2006)
AngularJS (2010)
React (2013)
ECMAScript 2015+
Babel
MEAN Stack => JAM Stack

(Why)? 기술이 발전되는 이유

Rich Client

정보량 과다
모바일 대응
복잡해진 화면
문서를 뛰어넘은 매체

사용자의 환경을 개선

작은 화면에 복잡한 UI
페이지 리프레시
페이징
빠르고 풍부하고 우아한 웹

Not only UX Design

https://uxplanet.org/ux-engineers-what-we-are-2b0c4d10b3a6

프론트엔드 개발자라면 당연히 챙겨야할 덕목인 4가지의 UX 개선 사항을 뽑아주었다.

성능 최적화

초기로딩
빠른 동작
부드러운 애니메이션

예상 가능한 동작

스크롤 복원
dimd 닫힘
손에 쉡게 들어오는 인터렉션
예상 가능한 인터렉션

SEO / SMO

검색 엔진 최적화
소셜 미디어 공유 최적화
어디까지 공유 가능해야 하는가

측정과 개선

트래킹
A / B TEST
GA

결론

프론트엔드의 본질은 UX
UX 디자이너와의 긴밀한 협업
- 디자이너의 1px, 100ms 의 소중함

라이브러리 / 플랫폼 개발자	프로덕트 개발자
Performance	UX
Documentation	Maintentance

느낀 점

수많은 프론트엔드 개발자들을 반성시키는 발표가 아닐까 싶다.
전반적인 WEB 탄생에서부터 시작하여 왜 사용자 관점에서의 UX가 중요한지
프론트엔드 개발자는 이 상황에서 무엇을 해야 하는지에 대해 적절한 경험담과 사례 그리고 방향을 제시해줬다.

프론트엔드 개발에 FRP(Functional Reactive Programming) 녹여보기

서재원, 푸른중학교

Blog: http://environmentset.github.io
Github: https://github.com/environmentset
Interview: https://www.imaso.co.kr/archives/3668

이제는 널리 알려진 프론트엔드계의 이강인 그리고 유망주 서재원님의 FRP 발표였다.

예제코드

프로그래밍 패러다임

추상화 => 함수를 만든다.

명령형 vs 선언형

선언적인 프로그래밍은 가변성과 부수효과를 사라지게 만들어준다.

Reactive Programming

흐름을 정의한다
낮은 결합도
Observer
이벤트

FRP(Functional Reactive Programming)

함수형과 반응형의 만남은 결국
코드 재사용성을 높이며 결합도는 낮춰준다.

Functional 배우기

Monad
부수효과
참조 투명성
순수 함수
HOF

Reactive 배우기

Observable
lifesaver

FRP 배우기

Sequence
Observable (stream)
Operation
Marble Diagram
map
filter
scan
merge
withLatestFrom

느낀 점

점점 발표 스킬이 늘고 키도 커지고 있는게 느껴지는 서재원님의 발표였다.
발표를 하는 것 자체만으로도 많은 개발자들에게 귀감을 주었지만
FRP에 대한 소개와 특징으로 끝난 것 같아 매우 아쉬웠다.

문과생의 커리어 프런트엔드로 refactoring하기

한근택, ODK Media

발표 전에는 같은 비전공자로써 큰 기대는 없없지만
컨퍼런스를 함께한 스터디원분께서 한근택님 발표가 분명 재미가 있을 거라며
큰 기대를 주었고 정말 기대 이상의 동기부여와 재미를 준 발표였다.

비전공자에서 인프라 엔지니어로

노량진 고시생이자 게임 중독에 걸린 시절 자신의 학과에 대한 의문까지 더하게 되어 더더욱 공부를 하지 않고 허송세월을 보내고 있었다.

이때 전 여친(aka 와이프)님의 제안으로 Java 교육 수강을 시작하게 되었는데

결국 보안 교육을 통해 결국 보안 관제 담당자로 취직하게 되었다.

보안 분석, IDC 세팅, 각종 인프라 엔지니어 업무와 장애 대응으로 지치게 되었고 재미를 느끼고는 하였지만
결국 잦은 서버 업무로 이직을 결심하게 되었다.

AWS 인스턴스 200대 점검

취업하자마자 주어진 명령이었고 굉장히 많은 시도를 해보다가
Python CLI로 해결하게되었다.
이 마저도 불편하여 직접 Web에 대시보드를 개발하여 해결을 하였다.

하지만 이런 능동적인 개발 이후 팀장의 잦은 요구로 이직을 결심하게 되었다.

개발 공부 재시작

취업을 위한 공부를 시작하였다 (HTML & CSS는 극혐 그 자체)

그 중 네트워크는 인프라 엔지니어 시절 업무를 통해 몸으로 느끼며 학습하게 되어 따로 공부할 필요가 없었다.

자료구조는 언어에 신경 쓰지 않고 책을 구매 후 원하는 언어로 포팅하며 공부하였고
알고리즘은 흔한 패턴을 공부하다가 나중에는 트릭도 찾아 공부하게 되었다.

면접 & 취직

면접과 과제를 통해서도 성장할 수 있어 고마움을 느끼게 되었지만 점점 지치게 되었다.

결국
하루에 7시간 면대면 면접과 매일 매일 문제를 보내는 어떠한 곳에 백엔드 개발자로 취직을 하게 되었다.

커피 한잔과 Front end

그러던 어느 날 커피 한 잔에 팔려 React를 배우라는 지시를 받았고 동료 쥬니어 개발자와 협업하여 서비스를 출시하게 되었다.

나름 프론트엔드 개발자로 한층 성장하는 계기가 되었다.

사수 A 이야기

알마라는 사수 A 개발자분이 입사하게 되었고 매일 매일 코드 리뷰를 받으며 살해의 위협을 받았다고 한다.

인정을 받다가도 잦은 실수를 하며 굉장히 많이 혼나게 되었고 결국 정신없이 혼나다 성장한 자신을 바라보게 되었다.

어느샌가 사수 A는 떠나게 되었지만 큰 배움을 받게 되었다.

프론트엔드 리드 개발자

그 와중에 프론트엔드 기반이 전혀 없는 어떠한 회사에서 프론트엔드 환경을 리드를 하게 되었다.

사수 A 개발자님에게 배운 것을 토대로 코드 리뷰를 도입하고 많은 노력을 하였지만

리더가 된 이후 살이 빠질 정도로 굉장한 스트레스 받았고
리더라는 이유로 의지할 곳이 없어 외로운 리더가 되었다.

사수 B 이야기

이전 회사에서 다양한 배움과 도움을 주었던 사수 B님의 제안으로 현 회사로 이직하게 되었고 함께 토이 프로젝트를 진행한다.

토이 프로젝트에 최대한 신기술을 자유롭게 도입해보고
그 경험과 노하우를 통해 회사의 코드에 녹여보고
실제 필드에서 얻은 피드백을 또 다시 토이 프로젝트에 적용하는 식으로 학습을 하였다.

결론

좋은 사람들과 일하며 많은 것을 배우자

느낀 점

정말 말을 잘하는 개발자셨다.
개발자가 아닌 일반인이 봐도 재미있을 발표였고
이쁘게 잘 정돈된 발표 자료는 아니었지만 필요할 때마다 등장하는 짤들은 발표를 꿀잼으로 만들어줬다.
좋은 와이프, 좋은 동료 (때로는 무서운)들을 만나 훌륭한 프론트엔드 개발자가 된다는 내용이지만
그 과정 속에 한근택님이 얼마나 많은 노력을 했는지와 실행력은 정말 큰 동기부여가 되었다.

프론트엔드 개발 끝장내기(endgame) feat. Angular

나석주, 비바리퍼블리카

이미 이전 발표 중 천민호님의 Angular 발표와 내용이 겹치게되어 어떤 차별점이 있을까를 기대하게 되었다.

Angular의 특징

Template Binding
Component
HTML attribute 와 DOM Property 비교

Change Detection

데이터의 변경을 감지하여 View 반영하는 Angular의 메커니즘
단방향 강제화

Zone

JavaScript VM 실행 컨텍스트
DOM 이벤트 추적

DI

고립된 컴포넌트들의 상태를 공유
인스턴스 활용

결론

이 밖에도 Promise의 Pull & Push와 RxJS를 설명하는 등
직접 Angular를 사용하며 느꼈던 특징을 공유하는 자리였다.

느낀 점

이전 발표와 겹치는 내용이 많아 이전 내용과 비교를 하거나 살을 보태는 방식의 진행이 아쉬웠고
이쯤 되니 GDG와의 약속으로 Angular에 대한 세션이 많았던 게 아닐까 우스꽝스러운 생각을 해보게 된다.

프로그래머로의 배움

안희종, 비바리퍼블리카

Blog: https://ahnheejong.name/about
Github: https://github.com/heejongahn

프론트엔드계의 브루스 배너 안희종님의 발표는 처음 보지만 그동안 워낙 훌륭한 아티클들을 다수 작성해주셔서 감명 깊게 본 적이 있다.

원래의 발표 제목은 프로그래머로서의 성장을 도왔던 태도들이지만

프로그래머로의 배움으로 변경하였다고 한다.

발표자료: https://www.slideshare.net/HeejongAhn/ss-152627139

무엇을 배울까: 변하는 세상 속에서

코드를 안 짜는 방법 > 적게 짜는 코드
Rich App 생태계에 대처하는 JavaScript
요구사항을 가정하는 방법
- 올바른 가정을 세운다 => 많이 해본다 => 회고를 한다.
왜? 무엇이?
- 모든 사항에 의문을 가져본다.
- 고민해볼 만한 가치가 있다.
겸허함
- 글과 말을 정돈을 잘할수록 코드를 짜는 데 도움이 된다.
세상이 변해도 변하지 않는 것을 공부하자

어떻게 배울까: 이론과 실습 사이의 핑퐁, 사람들은 틀린 말을 한다

균형을 찾는 법

	A 유형	B 유형
방법	문서만 읽음	기본 문법만 습득 => 바로 코딩
결과	실제 코딩은 막힌다	시행 착오로 인한 시간 낭비 많음

A & B 를 핑퐁한다
MVP
- 짧은 주기의 반복을 통해 만들면서 배운다
급할수록 돌아가자
- 쉽게 풀어진 학습 리소스
  1. 재해석을 하자
  2. 진실로부터 멀어질 수 있다.
- 근원에 깊이 파고들자
  1. 어려워도 하다 보면 익숙해진다.
  2. 생각하고 습관을 잡기 위해 노력하자
사람보다는 기계를 믿고 하는 일을 기계에 맡기자

왜 배울까: 나는 작지만 내가 할 수 있는 일이 있다

다양한 리소스에 압도를 당하는 느낌
- 초조함과 모든 것을 다 배워야 한다는 생각이 들지만 결국 불가능하다
외부의 정보량보다는 나의 에너지와 시간의 문제
Action Plan
- 열정적이고 훌륭한 동료를 확보하자
- 내가 그런 사람이 되기 위해 노력하자
배움을 주는 문턱은 생각보다 높지 않다.
- 다양한 길이 열린다.

느낀 점

안희종님의 발표나 자료를 접하게 될 때는 지식의 빈익빈 부익부를 느끼게 된다.
자기 주도 학습을 하는 데 있어서도 사람마다 접근 방식과 Action Plan에 큰 차이를 보인다.
결국 이번 세션도 역시나 큰 반성과 깊은 뉘우침을 받게 되었다.

리액트 꽃길만 걷기

김민준(Velopert), 라프텔

Blog: https://velopert.com
Github: https://github.com/velopert
Facebook: https://facebook.com/velopert
Youtube: https://www.youtube.com/channel/UCmMgRlN-3GKQ_CH7cOtLdvg
Book: https://book.naver.com/bookdb/book_detail.nhn?bid=13799583
ETC: https://velog.io

국내 React 홍보대사이자 대표라고 할 수 있는 벨로퍼트님의 세션으로 React를 사용하고 공부하며 겪은 시행착오와 역사를 공유하는 자리였다.

발표자료: https://drive.google.com/file/d/18MJDVzre8DYnEx9OITrYZOC_cVUeaSdV/view?usp=sharing

전반적인 내용

고생하지 않고 React를 배우는 길에 대한 고민
겪었던 실제 어려움
잘못된 방향들
배웠던 꿀팁
온전한 리액트에 대한 이야기

스타일

전처리기
1. sass, less
  - 다양한 문법과 재사용 방법
2. post css
  - 전처리기들을 흉내 낼 수 있다.
디렉토리 구조에 대한 고민
1. 스타일만 몰아넣기
  - 인덱싱 어려움
  - 컴포넌트화 동기화 어려움
  - 컴포넌트와 동떨어져 관리 어려움
  - 마크업 팀이 있다면 도움 될 수도
2. 컴포넌트에 넣어주기
  - 무난하고 많이 사용됨
  - 폴더 및 index.js 만드는 어려운 생산성
CSS module
- class name 관리 어려움
CSS in JS => Style Components
1. 안 좋았던 단점이 모두 수정되며 장점이 되고 있다 => V5
2. 종착점이 되었다.
UI 프레임워크 사용은 지양하자
1. 절대 필수 요소가 아니다.
2. 커스터마이징이 어렵고 걷어내기도 어렵다.
3. 직접 작성하는 것을 어렵다고 생각하지 말자

함수형 컴포넌트

v16.8 이후 클래스 컴포넌트에서만 가능했던 것들이 함수형 컴포넌트에서 가능해졌다.

다양한 Hooks와 LifeCycle API 흉내내기 그리고 Context API + Hook을 통해 Redu x만큼의 효과를 낼 수가 있다.
(단점으로는 미들웨어를 포기해야 할 수 있다.)

이제 더 이상 클래스 컴포넌트를 사용해야 할 이유가 사라지고 있다.

Store

Redux

v16.8 버전이 다가온다 해서 굳이 Redux를 걷어낼 이유는 없다.

Redux 상태를 관리하는 데 있어서 항상 큰 고민을 동반하게 된다.

결론과 정답은 없지만

스토어에 어떤 상태를 넣어야 할지 고민하고 정의해본다.
로컬 상태로 할 수 있다면 굳이 스토어에 다 넣지는 말자

Container & Presentational

꼭 따라야 할 패턴은 아니다.
Container 컴포넌트가 굉장히 거대해지는 상황이 많으니 조심하자
1 Container <=> 1 Presentational 일 이유는 없다.

Mobx

Hooks 지원 여부에 따라 사용법이 많이 바뀌고 있으니 새롭게 배우게 된다면 몇 달 후에 배워보자.

SSR

결국 서비스를 운영한다면 필수인 부분이다.

Next	Router
생산성이 좋다	프로젝트 설계를 직접 구현
모든 걸 다 해준다	데이터 로딩에 제약 사항이 없다
제약 사항이 많다	올바를 이해와 가이드가 필요하다

기타

데이터 요청 상태 관리에는 스토어가 도움이 될 수 있다.
Immutable.js 보다는 immer.js
상태를 너무 깊게 가져가지 말자
배열 업데이트시 keyed-by-id를 사용하자 (라이브러리도 있다)
TS, TDD는 고민하지 말고 일단 빠르게 적용하자

느낀 점

진겸님의 패스트캠퍼스 100만원짜리 강의라는 말이 와닿을 정도로 굉장히 좋은 발표였다.
사실 React를 하다 보면 문제가 뭔지도 모르고 이상한 길을 마치 맞다고 착각하는 경우도 있고
Best Practice를 찾는 데에만 며칠이 걸릴때도 있다.
물론 Velopert님의 요약된 발표가 React 로드맵의 표본 및 정답이라고 할 수는 없다.
하지만 Best Practice에 가까운 훌륭한 자료와 정리였다.

Q & A

풀스택에 대하여 어떻게 생각하는지? 시간이 들이면 가능한지? 장점이 있는지?

A: 서재원
- 시간을 들이면 모든 것이 가능하다.
- 공부도 그랬다.
A: 나석주
- 충분히 가능하다.
A: 안희종
- 풀스택이 아니라 가능한지는 모르겠다.
- 어떤 한 분야를 깊이 파는 게 필요한 조직도 있고 넓은 분야를 필요로 하는 분야도 있다 본인의 포지션을 정해서 나아가면 된다
A: 진겸
- 스타트업을 가면 결국 서버를 어쩔 수 없이 짜는 경우가 있다.
A: 김민준
- 풀스택 개발자가 있을 수는 있지만 멋있다고 생각되지는 않는다.
- 한 곳에서의 정점보다 두 곳에서의 정점은 어렵다.
- 풀스택을 나눠 협업하는 것이 더 멋지다고 생각한다.
- 굳이 모두 다 잘할 필요는 없다고 생각한다.
- 둘 다 공부는 해도 한곳에 집중하는 것이 더 좋다.
- 둘 다 해야 우리가 원하는 것을 얻을 수 있다.
A: 한근택
- 제사상에 피자가 올라가도 되는지 급의 논란 질문이다.
- 풀스택을 어디까지 볼 것이냐가 중요하다.
- 둘 다 해야 우리가 원하는 것을 얻을 수 있다.
- 굳이 모두 다 잘할 필요는 없다고 생각한다.
- 두 명분의 일을 한 명의 임금으로 해결해야하는 일 같다.
- 트렌드가 빠르게 변하는데 양쪽을 모두 따라갈 수 없다.
A: 한재엽
- 노 코멘트

프레임워크 리서치시 Angular의 평가가 매우 낮다 어떻게 생각하는지

A: 나석주
- 입문이 어려워서 그런 것 같다.
  - 문제 해결이 어려워지게 된다.
A: 진겸
시대를 앞서간 것 같다.
학습 비용이 리액트에 비해 크다.

안희종님 Fear of missing out 경험과 해결 방법이 궁금해요

Fear of missing out

A: 안희종
- 팔로워를 줄이게 되었다 어차피 좋은 정보는 들어오게 되어있다.
- 본인의 능력에 대한 피드백을 빠르게 자주 받아보자
- 면접을 보며 부딪히고 피드백을 받아보는 것도 팁이다.
- 본인을 평가받아보는 환경에 자신을 던져보자
  - 액션 플랜을 짜보자

서재원님 개발은 언제 시작하셨나요?

A: 서재원
- 초등학교 5학년 게임을 하다가 시작하게 되었다.

UX 회의시 의견이 불일치할 때 대처 방법

A: 진겸
- Best Practice는 없다.
- 사용자에게 좋은 경험을 제공하는지를 확인하자
- 조율이 가능한 경우와 아닌 경우가 있다.
- 역량과 상황에 따라 달라질 수 있다.
- 최대한 사용자 측 입장에 대해 많이 생각해보자
  - 실력 상승이 된다.
A: 김민준
- 데이터로 분석할 수 있는 UX 면 좋다.
- A/B 테스트 수용
A: 한재엽
- 안된다고만 하지 말고 안되는 이유를 생각해보자
  - 일정 및 역량
- MVP를 도입하여 디자이너와 협의

프론트엔드 전망이 아직도 좋다고 생각이 되나요? 보험이 되는 서버 언어를 추천해주세요

A: 김민준
- 개발을 잘한다면 전망이 좋다.
- 못 따라온다면 프론트엔드에 어울리지 않을 수 있다.
- 보험이 되는 공부 방법은 별로 같다.
  - 자아 성찰을 하자
- 어떤 언어를 공부하느냐는 중요하지 않다.
  - 개발을 잘 해내는 게 더 중요하다.
  - 절대 언어가 중요한 게 아니다.
A: 나석준
- 한 가지 기술만 고집하지 않는 변화에 대응할 수 있는 자세가 필요한 것 같다.
- 카멜레온 같은 개발자가 되자

개발 문화에 대한 책 중 인상 깊었던 문구

A: 한근택
- 보이스카웃 원칙
  - 들어가서 나올 때는 더 깨끗하게
  - 남이 짠 코드더라도 정돈을 시키고 나오자
A: 한재엽
- 깨진 유리창 법칙
  - 유리창에 한 군데가 깨지면 전체적인 분위기를 망친다.
  - 안 쓰는 코드가 있거나 잘못된 주석이 있거나 하나라도 잘못된 것이 있으면 잘못된 프로덕트로 보일 수 있다
A: 서재원
- 설레발 주도 개발
  - 신기술을 배우고 습득하여 유행에 따라 적용해보며 삽질하고 욕을 하게 된다.
  - 뭐가 중요한 것인지 파악해야 한다.
A: 진겸
- 외주를 하자 일단 질러놓자 어떻게든 하게 되어있다.
- 스스로 목표 없이는 잘 안 하게 되어 있다.
- 어쩔 수 없는 마감을 만들어버리자

유지보수하기 어렵게 코딩하는 방법이라는 책을 본 적이 있는지

유지보수하기 어렵게 코딩하는 방법

A: 한근택
- 제목만 보고 읽지 않았다.

한재엽님 호스팅과 도메인은 무엇을 사용하나요?

A: 한재엽
- 도메인: GoDaddy
- 호스팅: netlify

현재 아무런 프레임워크 없이 뭔가 도입해야 하는데 뷰와 리액트 고민이 됩니다.

A: 한재엽
- 훌륭한 강의 및 자료가 많은 리액트를 추천
- 생태계가 크다.
- 공식 문서가 번역되고 있다.
A: 나석주
- Angular도 번역이 있다.

컴퓨터 전공 중 FE 공부를 한다니 교수님이 그걸 왜 하냐고 혼이 났다. 그냥 재밌어서라고 했더니 그건 전공자가 하는 게 아니라고 혼났다 어떻게 대답을 해야 하나

A: 한재엽
- 비전공자이지만 어딘가에 생각이 머물러있는 교수님인 것 같다.
- 이미 멈춰진 옛날이 FE를 생각하는 것 같다.
- 무시를 하는 것도 좋지만 반박을 하자면 재밌어서라는 이유가 크다…..
A: 안희종
- 사람들은 틀린다.
- 전공자도 많이 하고 있다.
- FE는 많이 복잡해지고 있다.
  - FE 라이브러리나 프레임워크에 적용된 법칙과 구조는 이미 백엔드에도 있는 것들이다 마음에 담아두지 말자

비전공자인데 프로그래밍을 배운지 6개월이 되었다. CS 기초가 꼭 필요한지 어떻게 준비하는지

A: 한재엽
- 본인 깃헙에 CS 기초 정리 자료가 있다
- 깊이 공부한 적은 없고 필요할 때만 공부했다.
- 모르는 지식들만 찾아서 공부하게 되었다.
- 좋은 자료는 이미 굉장히 많다.

알고리즘 공부가 너무 어렵다 얼마나 활용하고 얼마나 노력하는지

A: 진겸
- 결과적으로는 도움이 되는 부분이다.
- 결과에 집착하자
A: 나석주
- 프로그램 서빙으로 문제를 해결해나가는 능력이 결국 중요하다.

마치며

전체 사진 출처(@양성민님)

역대급으로 만족스러웠다.
다양한 인사이트와 깊은 반성 그리고 엄청난 동기부여를 받았던 컨퍼런스였다.
더 이상 무슨 말이 필요할까