[후기] INFCON 2022
안녕하세요 :) Zedd입니다!
제가 오늘 인프콘을 다녀왔는데요 ^_^ 이게 얼마만의 오프라인 컨퍼런스 후기인지!
원래
신청했을 때는 탈락했었는데요 🥲
운좋게 회사를 통해 티켓을 하나 구하게 되어서 갈 수 있게 되었답니다 \ㅎ_ㅎ/
코엑스 그랜드볼룸에 열리는 컨퍼런스를 간다면 꼭 거치는 이길...
역시나 길을 헤매서 물어물어 왔어요.
저 가방은 와서 열어보니까
티셔츠 + 마스크 + 볼펜 + 스티커 + 물로 구성되어있더라구요.
물이 들어있었군....몰랐어..
# 오프닝
오프닝 하는 곳이 꽉차서 저는 다른방으로..
인프런이 이것저것 많이 시도하는구나 싶었던!
입장할 때 팜플렛도 받았는데, 뒤에 스탬프 이벤트 같은것도 있더라구요.
근데 줄이 에바라서 받지는 않음...ㅋ... 근데 사람들 굿즈 받은것들 보니까 넘넘넘 이뻐서 줄 설걸!!하고 후회했읍니다 ^^;
다들 그러셨겠지만 저 역시 인프콘 발표 시간표를 미리 보고 제가 들을것들을 미리 정해두고 갔습니다!
# 실리콘밸리로 떠나는 비전공자 개발자의 지난 4년 회고 - 좋았던 선택 vs 후회되는 선택
1년차 ~ 4년차까지 각 년차에 뭘 했고 그때 했던 좋았던 선택/후회되는 선택들을 차근차근 이야기해주는 세션.
PPT를 잘 만드셔서 내용을 더 잘 이해할 수 있었다!
# 나도 내 코드의 문제를 찾고 싶다고요?! - 테스트 할 때 기억할 7가지
헉 저도 찾고싶어요 하면서 들었던 세션
일단 인공위성에서 오는 데이터를 받는 그런 업무에 종사하신다고 하셨는데, 짱 멋있다...
다른 사람들의 생각/행동이 내 기준에서 이해가 가지 않을 때, 먼저 상대의 사고과정을 이해하는것부터 시작하면 좋다.
테스트 케이스에 대한 올바른 정의가 필요. → 기준이 되기 때문에 가장 중요. 잘못 정의하면 비정상이 정상으로 둔갑할 수 있음.
어떻게 테스트 케이스를 올바르게 정의할 수 있을까? → 제품 요구사항에 답이 있음.
문제가 생겼을 때 가장 많은 시간을 할애하는 단계 → 원인을 찾는데 가장 시간이 ⬆️
문제 해결을 위해 내부 구현 확인 / 외부 인터페이스 확인을 할 수 있음.
- 내부 구현확인 → 개인의 자율에 맡겨진(짜여진) 코드를 확인하는 것이기 때문에 주관적인 근거로 대화가 이어질 수 있음. 감정적인 반응을 유발.
(ex. 제 코드엔 문제가 없는데... == 님 코드가 문제 인것 같은데 어떻게 생각하시는지..?)
- 외부 인터페이스 확인 → 이것을 먼저 확인하는 것을 추천! 감정이 개입할 여지가 적다.
우리는 언제 제품을 처음 만날까?(눈으로 확인할까) → 테스트 단계.
요구사항은 언제 정의될까? → 제품을 만나기 전에 (눈으로 확인하기 전에)
제품을 보지않은 상태에서 문제를 찾으려고 하면 힘들다. 디테일한 부분을 많이 놓치게됨. (맞어!!!!1)
그래서 개발 프로세스에 아이러니가 있음.
눈으로 직접 보고 나면 진짜 요구사항에 더 가까이 다가갈 수 있다.
어떻게 하면 이 간극을 줄일 수 있을까
- 내가 사용자 관점으로 내가 만든 제품의 첫 사용자가 되어본다.
- 고객의 상황을 상상해본다. → 똑같은 기능을 좀 더 편하게 개선할 수 있게 됨.
사용자가 되어보니 개선할 점, 고객이 필요할 점이 보이기 시작.
일관성을 유지하는 것도 중요.
- 소프트웨어를 사용할 때 기억해야할 것을 최소화하는 것이 좋음. (쉽게 익숙해지도록)
- 테스트단계에서 이 일관성을 개선하기 좋음(여러기능을 한번에 볼 수 있으니) → 애초에 팀이 일관된 기준으로 만드는게 좋음(디자인 시스템이라던가..)
가장 기본적으로 '테스트'를 '해야함'
- 테스트 환경을 구성하기가 까다로워서 or 너무 간단한 기능이라서 테스트를 하지 않음. → 너무 간단한 기능은 "내가 보기에" 그렇게 보이는 거임.
컴퓨터가 음 이코드는 간단하네~~! 맛있다~! 이러는게 아님 (이렇게 말씀하진 않았습니다..)
내가 간단하다고 "판단"하는 것임. 컴퓨터가 정상이라고 말하기 전에는 간단한 코드여도 믿지 않는것이 좋음
일단 목소리가 정말 나긋나긋하셔서 귀에 쏙쏙 들어오는 세션이었다!
# 코드 리뷰의 또 다른 접근 방법: Pull Requests vs. Stacked Changes
Pull Request의 아쉬운점 → 코드리뷰가 길어질 수 있음(시간적으로). 빨리 작업하고 릴리즈 해야하는데 그게 미뤄지고 그러면 쩜 별루임
Stack Changes → 흐름을 아래에서 위로 가져간다. 구현 하나하나 스택쌓듯이.
[장점]
- 코드 변경 크기 줄어듬
- 작업의 명확성 올라감
- 리뷰 속도 올라감
Graphite (그라파이트)라는 도구로 Stack Changes를 해볼 수 있다!
Pull Request 와 Graphite 비교
사실 Stack Changes가 정확히 어떤것인지 감이 잘 안온다..
특히 나는 보통 이전 브랜치를 Base로 PR을 만드는데, 이게 Stack Changes랑 어떤 차이인지가 궁금.. 😵💫
Stack Changes라는 개념도 처음 알게 되었고, Graphite도 알게되어서 유익했던 세션!
# 나와 팀을 성장시키는 리뷰들 - 코드리뷰만 리뷰가 아니라니까?
세션을 다 보고 나니 정말 딱 요 이야기를 해주신 것 같았던..
개발자는 코드만 작성하지 않음. (==개발만 하지 않음). 개발자의 일 중 일부가 '코드를 작성하는 것'
요구사항(문제) 분석 단계의 리뷰 → 문제를 명확히 정의해야함. 서로 '리뷰'하지 않으면 각자 다른 결과물을 생각할 수 있음
설계 단계의 리뷰 → 설계를 리뷰하지 않으면 기술에 집착하게 될 수 있음. 프로덕트(서비스) 측면에서는 지금 당장 하지 않아도 될일. 하면 좋은 일을 하다가 지금 진짜 필요한 일을 못하게 될 수 있음
구현 단계의 리뷰 → 코드리뷰. approve하는 이유를 적어주는 것이 좋다. PR에 충분한 설명이 없으면 집중해야할 코드가 어딘지 헷갈림. 코드작성자의 의무임
테스트 단계의 리뷰 → 이미 '리뷰'라는 행위를 하고있음. 테스트 수행이 곧 리뷰 완료는 아님. (테스트에 결함이 있을 수 있기 때문에)
배포 단계의 리뷰 → 배포한 기능이 잘 쓰이고 있는지, 성능 문제는 없는지.
각 단계의 리뷰를 잘하면 일을 잘하는 사람이 된다. → 결국 팀원 개개인의 일하는 능력을 향상시킴
요 세션을 들으면서 앞으로 내가 시도해보면 좋을것들이 몇개 보였다!
나는 기능조직에 있다가 목적조직으로 온 케이스인데, 와서 정말 뼈저리게 느끼는 건..정말 개발은 일 중 일부구나ㅎ를 느꼈다.
그리고 나도 여기와서 자연스럽게 느낀건, 정말 일을 잘하는 사람은 개발을 잘하는 사람이 아니라는 것..!!
일잘하는(함께 일하고 싶은) 사람이 되기 위해 열씸히 노력해야지 🏃♀️
# 지금 당장 DevOps를 해야 하는 이유
프로젝트에서 가장 중요한 것 → 속도/일정. 빠르게하는것과 일정을 맞추는것.
아마존 → 11.7초에 한번씩 코드를 릴리즈 → 데브옵스가 도움을 줄 수 있음
조금씩 개선해보려는 시도가 중요함.
- 필요할 때 도구를 적절하게 사용하면 된다. (git, 젠킨스, aws, 그라파나 등등등등)
- 자동화를 시도해보자
사실 처음 도입하면 프로세스가 더 느려질 수 있음(잘몰라서..)
하지만 일단 시작하면 개선이 쌓이고 쌓여서 문화로 정착되면 큰 도움이 될 것이드..
데브옵스 알못이라 들어봤는데, 확실히 이런 데브옵스 하시는 분들은 네트워크, 보안 지식이 몬가 뛰어나보이고...(대충 간지난다는 뜻)
일단 시작해보자!!! 작은거부터 시작하고 싶은데 뭐가 좋을까..
# FE 개발자도 할 수 있다! RESTful API 개발 (with Firebase, GCP)
들으면서 느낀건 '헉.. FE개발자가 들어야 하는 세션이었군....'
코드가 많았는데, 사실 뭐 아 대충 이런 로직이군.. 하면서 짐작은 할 수 있지만,,ㅎㅎ
하나 알았던건.. vercel!!!
let us: Go! 홈페이지나 다른 vercel.app으로 된 페이지 보면서
ㅎ
ㅡ
ㅁ... 얘는 몰까...(찾아보지는 않음)
했었는데, 저렇게 배포하는 거였구나~를 알게된..!!!
사실 다음 세션도 있었는데, 오랜만에 만난 동료분과 저녁을 먹으러가서... 하하~!!!
아무튼 정~~말 오랜만의 오프라인 컨퍼런스를 운좋게 다녀오고.. 좋은 세션들 들을 수 있어서 너무 감사한 하루였따.
그리고 역시나 자극도 많이 받은... 💪
제가 요걸 딱 당일에 발행하려고 써놨었는데, 마무리를 못해서 이제야 발행하네요 핳