저번 달 10월 28일. 정말 운이 좋게 Teo님이 사람인과 함께 주최하시는 TeoConf23에 당첨되어서 참여할 수 있었다.
입사하고 거진 반년이 되어가던 참에 뭔가 자극을 잃어가고 있었는데 좋은 기회가 되었다.
리뷰가 한달이 늦어졌지만 강연을 들으며 끄적였던 내용을 한 번 올려본다.
시간이 없어 다듬지 못하고 일단은 메모 그 내용 그대로 올려본다..ㅎ
📢첫번째 연사: 0년차 신입의 오픈소스 프로젝트 기여 이야기
내가 할 수 있는 것
- 없다면 내가 주도적으로 모임을 만드는 것
- 코드기여에 대한 정리
- 코드 리뷰
회사와 그 외의 프로젝트의 연결
- 회사 코드를 보면서 ‘이게 좋다는 생각이 든다면 왜일까?를 정리해보자’
공식문서 기여
- 사소하지만 내가 할 수 있는 것들을 찾을 수 있다. UI 같은 부분?
- 띄어쓰기 하나 조차 기여가 된다.
- “사소한건데 뭐“, ”대충해~”라는 말을 가장 경계하자.
stackoveflow, 나도 탑 리뷰어가 될 수 있지 않을까?
- 사소한 것부터 답변을 해보자
“성당을 짖는 벽돌공”: 내가 떠올리는 목표는 무엇일까?
💡나의 생각: 내가 떠올린 목표는 뭔가 거창한 ’신을 마주할 준비를 하는 중이다‘와 같은 느낌이었는데, 다시 생각해보니 무조건 거창한 것도 맞지는 않겠다
-> 벽돌을 쌓는다, 돈을 번다. 어쩌면 이런 단순한 목표는 ‘나쁘다’라는 것도 편견 아닐까? 타이밍에 맞는 목표가 있지 않을까?
📢두번째 연사: 주니어 개발자의 개발환경 개선기
연사자님: fe리드 개발자(3년차)
- 이분도 SI -> 서비스로 옮겨 가신 분
non-it에서 it로 옮기는 과정에서 겪은 이야기
- non-it 실무자였던 분들과의 소통
- it, 개발 등에 이해가 없는 분들과 여러 실무 어려움을 겪음
(PM의 일정관리에 대한 이해도도 낮았다)
- 도망가? 근데 옮기며 달라질까?
- 아니, 어디든 문제는 있는 법, 네트워킹의 문제는 다 존재한다.
- it, 개발 등에 이해가 없는 분들과 여러 실무 어려움을 겪음
- 개선은 어떻게??
1) 메신져의 통일
- 이 분은 3개의 메신져를 사용했다. 나랑 비슷하네? 난 사내랑 github을 쓰니..
- 유료인 슬랙을 도입하고자 했을 때 부딛혔고, 이를 설득하기 위한 점을 어필
2) 같이 잘하자
- 소통 외에 언어적인 부분도 통일을 시키자어? 나도 몇가진 정리해서 만들어 볼 수 있을 것 같은데?
내가 입사했을 때도 사내에서 쓰는 용어에 헷갈리고 이해 안되는게 있었는데 이걸 이번에 들어오는 신입분들에게 설명할 수 있는 ‘OJT문서’를 만든다면?
이분은 이런 것도 하셨네? ———
- 채용공고를 올리기 전 채용공고 분석: 10명의 지원자에서 150명으로 up
- 내가 사내에서 이런 행정 처리에 대한 자료조사를 하면서 불평하던 것들을 이분은 자발적으로 찾아내고 조사하셨네… 마인드의 차이가 크구나..
설사 배경이 있어도 개인의 실력이 없다면?
- 개인의 공부도 소홀히 하지 않는 노력
개속되는 개선
- 노션의 도입: 아이디어 보드, 컨벤션 등
- 기획 팀 등과의 소통, 일정관리도 도입
- 오류 접수 양식 제작
Q&A
Q) 신규 도입에 대한 리더를 설득하는 방법은?
A) 그냥 좋으니 합시다가 아니라 설득할 요소를 정리해서 제안해야 한다.
나의 질문) 신규 도입에 대한 팀원의 의욕이 없다면 어떻게 설득하지?
A) 어렵다. 개인 커리어에 욕심이 없는 사람들은 분명 있다. 그러니 혼자라도 해라. 한다면 그건 내 커리어에 도움이 된다. 그리고 과정을 정리해라. 욕심이 없는 분들을 굳이 끌고 갈 필요 없다. 계속 같이 가지 않을 사람이라고 생각해라.
야근을 해서라도 도입하는 걸 불편해하지 마라. 이것이 내 미래 커리어에 도움이 된다.
Q) 다른 포지션과의 소통에 대해서 어떻게?
A) 바꾸는 설득과 얘기는 충분히 제안해라.
팀 토크 세션
- 내 스스로에게 주는 자극과 미션: MC담당하자!
대화흐름 이끌고, 질문 던지기!
📢세번째 연사: 복잡한 오브젝트 우아하게 다루기
레버리지로 성장하는 개발자
> 오웬: 굿닥의 4년차 fe개발자Nested Array Object형태의 form data를 다루며 마주한 문제/해결
사전 설명: 말 그대로 form으로 사용자에게 입력받은 값을 처리하는 것
-
PO님이 내주신 미션: 영유아를 위한 사전 문진 기능을 개발해야 한다.
- 일반 환자도 쓸 수 있게 커스텀할 수 있도록 할거야
- ‘안 어렵겠지~’가 첫 접근
- 일반 환자도 쓸 수 있게 커스텀할 수 있도록 할거야
-
백엔드 개발자님의 의견: 3depth array object로 갑시다.
- 3depth의 CRUD만들기
- 구글폼과 비슷한 구조
- react-hook-form
- 3depth의 CRUD만들기
문제 1. 위 라이브러리를 쓰니 너무 복잡해지더라
-
첫 접근) 데이터 스키마 변경이 가능할까요?
- 이미 합의된 내용이고 시간이 지나 어렵다. fe에서 처리해라
-
솔루션 2) 동료분의 피드백: useFieldArray훅의 사용
- 적용! 개선이 이뤄졌다.
Recap: 직접 CRUD를 짜니 복잡했어서 라이브러리의 훅을 도입
문제 2. 화면 레이아웃
- 솔루션 1) control property: data를 관리하는 프로퍼티
- 중첩된 form data를 하나의 hook으로 관리
- control이 안 먹힘- 솔루션 1-1) 각 depth별로 hook적용
Recap: useForm의 control이 중첩된 배열 오브젝트에서 안먹혔는데 필드별로 hook을 적용하여 개선
문제 3. 유효성 검사
데이터 오염을 방지하기 위해 백과 프론트에서 모두 하는 것을 권장
-
문제1) 하나의 input만 바뀌어도 모두 검사하는 문제
- 해결 1) 마찬가지로 라이브러리를 분석해서 개선점 적용
- 해결 2) Zod의 적용: typescript의 스키마에 대한 체크 도구
- useForm과 궁합이 좋다는 커뮤니티 글이 많았음
=> zod resolver로 검사 -
문제2) 불변성 지키기
나도 최근에 했는데, param에 적용할 객체는 지키기 위해 원본에서 복사하고 새로운 키값 적용해서 UI/UX에 적용
MDN에서 1차원 배열에선 스프레드 연산자를 추천하지만 고차원에서는 다른 것을 사용할 것을 권장
- 해결) immer의 적용
- immutable과 비교해서 적용: immer가 러닝커브가 적어서 적용
WIL
- PO와의 협업에서 배운 점: 일정은 길게 잡고, 개발이 빨리 끝나면 테스트를 꼼꼼히
- 백엔드와 협업에서 배운 점: API나 데이터 구조에 대해 논의할 떄 더 적극적으로 FE의 입장을 전달할 것
- 프론트와 협업에서 배운 점: 동료의 도움으로 해결할 수 있는 길이 많다. 팀차원의 퍼포먼스 성장. 나보다 내가 쓰는 도구를 더 잘 아는 사람이 있을 것이다.
QNA
Q) 왜 JSON.parse나 stringify로 복사하는 방법을 쓰지 않았나?
A) 논의 끝에 잘 된 라이브러리를 적용하는 것이 좋다는 결론이 나왔다.
- 다른 분의 추가 의견: parse나 stringify는 예전 방법이다. 요새는 structured clone(?) 방법이 좋다.
Q) 라이브러리의 전체 적용, 일부 사용, 미사용 상황에 따라 적용하는 것이 좋은가?
A) Yes, 모두 방법이 될 수 있다.
Q) 상황적으로 구조를 flat하게 할 수는 없었다.
A) 백엔드에 요청했던과 같이, 하려고 시도는 했으나 상황이 어려웠다.
- 추가 의견: 프론트에선 플랫하게 처리하고, 보내주기 전에 뎁스를 맞추면 되지 않았을까요?
> 발표자님도 생각 못한 부분인 듯 하다.
(오~ 좋은 생각인 듯 하다.)📢네번 째 연사: 패턴매칭을 통해 선언적으로 typescript 다루기
1. 왜 패턴매칭이 필요한가?
- 데이터 스키마, 요구사항 등 맞추기 위해 우린 TS로 타입가드 등을 진행
- 근데 주객 전도: 타입 관련 코드가 로직보다 길어지는 아이러니
=> 이걸 해결하고자 해온게 분기를 효율적으로 나누는 것
효율적인 분기
- 함수형 프로그래밍에서 힌트를 얻었다.
| 우리가 아는 분기 처리 방법
1. if/else
2. Switch
3. 삼항연산자
등등
=> 문제점:
- 한정된 자료형
- 변경, 추가할 수록 복잡
등등
-> 함수형 프로그래밍 패턴매칭으로 해결 하자
2. 패턴 매칭이란?
- 어떤 데이터든 손 쉽게 추상화 가능
- 타입 추론 가능
JS에서는 듣지 못했을 수 있는 단어
-
표준은 아니다. 하지만 현재 공식문서에도 제안 단계까지 왔다.
| 단 하나뿐인 라이브러리 but 좋다!: TS-pattern 라이브러리
3. 명령형에서 선언형으로!
- 명령형에선 분기를 나눠야하지만 선언형에선 원하는 타입 매칭으로 함수형에서 값을 반환하는 식으로 변경
4. 타입 겹침(Type Overlap)의 문제
- 기존 방법. 타입 가드 등 사용
-> 문제: 스키마, 타입이 바뀔 때마다 수정해야하고, 추가의 번거로움, 중복 코드, 코드 무거워짐 등bff는? 배보다 배꼽이 크다.
- 타입 패턴
- 찾고자 하는 패턴 생성
- 그에 따른 함수값 반환
- 과정
- 타입 필터링
- 조합된 타입을 이용해 match함수로 확인
- 내부의 타입 캐스팅
- 결과: 선언적으로 해놓으면 타입 가드로 했을 때 없으면 에러로 반환하고 끝나는 것에 반해 ‘무엇(어떤 코드)’이 빠졌는지도 알려준다. 그러면 우리는 그 타입만 추가하면 끝.
- 비유: 명령형(‘양치는 치약을 짜고, 칫솔로 위아래로~) vs 선언형(양치해)
- 추상화로 상황에 따라 적용 가능:
- 명령형: 이빨이 없다면? 실행 못함
- 선언형: 사람은 양치를, 개는 양치껌을, -> 각자 맞춰 사용
- 추상화로 상황에 따라 적용 가능:
Recap:
- 추상화를 통해 유연성 증가. 타입에 대한 매칭만으로 논리 연산을 줄임(e.g. nullable 체크 불필요해짐)
But, 언제나 간결하고 좋은 코드를 만들어주진 않는다.
- 어떤 문제를 해결할 수 있는지 깊은 고려 후 적용- 아무리 좋은 기술도 팀을 설득시키고 동의를 얻어야 한다.
+) 연사자님 의견: 복잡한 비즈니스 로직이나 JSON데이터를 다룰 때 효과적이라고 생각한다.
📢다섯번째 연사: 디자인 시스템 - 피그마 플러그인을 통해 사내 생산성 증대시키는 법
피그마 상에 존재하는 수많은 assets을 어떻게 빠르게 개발단으로 옮길까?
- 피그마의 플러그인 만들기
- icona 제작
- 요구사항
1. 버튼 클릭 한 번으로 모든 것이 동기화
2. SVG로 다양한 포맷의 아이콘 생성하기: 여러 플랫폼 지원하기
3. 당근에서만 사용되지 않고 아이콘을 관리하고 싶다면 누구나 사용가능: public
github api로 pr을 올릴 수 있도록 연결했는데 모든 파일을 하나씩 돌린다?
- 비효율적
.json으로 담아 전달
코더(개발자) -> 엔지니어(문제 해결사)로 변모하자!
마무리 소감
이런 conference에 처음 참여해보는 것이었는데 굉장히 재밌고, 또 유익했다.
특히나 고연차의 분들만 강연자로 참여하는 컨퍼런스가 아니라 나같은 저연차인 분들도 참여해서 자신의 경험을 들려주시니 공감도 되고, 앞으로 뭘 해야할지 조금 더 감을 잡을 수 있었던 것 같다.
게다가 요즘 디자인 시스템에 관련해서 관심을 가지고 작업을 진행하고자 했는데 이것과 관련된 이야기가 있어 또 좋았던 것 같다.
그리고ㅋㅋㅋ 마지막에 경품 추첨도 있었는데 이게 웬걸 당첨됐다.
원래 이런 당첨운은 없는 편인데다가 끝까지 안 나오길래 '에이 역시'하고, 마지막 룰렛 돌아가는 거 보는데 '음.. 대충봐도 내 닉네임은 아니네'한 순간.
당첨! SamJ
음??? 와.. 세상에 컨퍼런스 참여만으로도 좋았는데, 책까지 당첨? 너무 좋았다.
게다가 경품들이 앞서선 노트북 거치대나, usb허브였나? 대충 다 있는 것들인데다가 뭐 아무래도 책이 더 갖고 싶었었는데 딱 당첨이 가장 갖고 싶던 것으로 되니 행복!
너무 속물인가..ㅎㅎ 그래도 좋은걸 어쩌겠다. 책이 배민꺼라서 고민됐는데 용기내서 테오님께 싸인도 받았다ㅋㅋㅋㅋ
마지막까지 완벽한 컨퍼런스. 근 시일 내에 또 한번 열리고, 그 때도 참여할 수 있었으면 좋겠다.
이왕이면 연사자로..?
그리고 테오님 영접ㅎㅎ 같이 사진도 찍고, 책에 사인도 받았다. 왠지 연예인 보는 너낌
