2022.08. INFCON 2022

오프닝

- 왜 열었는가? 감사. 함께 성장. 성장에 대한 다양한 기술과 경험에 대해 토론, 공유.

- 슬로건은? Learn, Share and Grow.

- 한국의 스택오버플로우가 되고 싶다.

 

실리콘밸리로 떠나는 비전공자 개발자의 지난 4년 회고 - 좋았던 선택 vs 후회되는 선택

- 체대 개발자 회고를 쓰셨던 그 분.
- 줌인터넷에서: 신입 개발자 파일럿 프로그램. 노션을 이용해 현재 진행 중인 프로젝트의 상태를 동료들에게 공유.
- 서비스 분야(도메인)을 정하고 이직.
- 매년 '내 나이'만큼 책 읽기.
- 영주권 신청을 미리 해뒀었는데 4년만에 인터뷰가 잡힘.
- Pixelic. Full Remote, Fully Asnyc 협업. 여섯 번의 pivot.
- Shape Up(제품 개발 프로세스). 베이스캠프라는 회사에서 공개한 제품 개발 프로세스.

  Shape Up을 사용하기 때문에 완전한 비동기 협업이 가능하다는 설명이 있었습니다. 동료에게 무언가를 요청하면 그 응답은 상대의 업무 시간 이후에 받는 것이 당연시 된다고 하는데, 과연 개발 프로세스 덕분일까 하는 의문이 생깁니다. 시간이 허락하는 대로 한 번 살펴보려고 합니다.

 

팀을 넘어서 전사적 협업 환경 구축하기

- 아틀라시안의 슬로건. Unleashing the potential of every teams.
- 자율성 Autonomy와 Alignment..
  - Jira 이슈에 기능 플래그 연결.
  - 현대 업무는 너무 복잡하므로 팀이 자율성을 가지고 결정. 모든 걸 의사결정권자가 다 할 수 없다는.
  - 90일 온보딩 계획. 주차별로 공부 할 내용. 만나야 할 사람.
  - 가장 마지막에 온보딩을 한 사람이 온보딩 메뉴얼 수정에 대한 책임이 있다.
- 개방성 Openness
  - 업무 프로세스를 설계할 때, 개방이 기본 정책이 되도록 해야 한다.
  - DACI 방법론. Decision Making Framework. 컨플루언스에 템플릿이 있다고.
- 친절 Kindness 즐겁게 협업하기 위한 Karma System. Atlassian Karma 슬랙 앱도 있음.
- 단일 진실 공급원 SSOT(Single Source of Truth)
- Conflunce가 많은 SASS를 지원하니까? Figma도 embed하고?
- 모든 프로젝트에 대해서 Know who’s working on what.
- Atlassian에서 각 팀들의 보고 라인도 볼 수 있음.

  최근 일하는 방식에 변화가 많았고, ClickUp에서 Jira/Confluence로 툴을 변경한 터라 힌트를 좀 얻을 수 있을까 해서 들었습니다. 좋은 내용들이었고 풍성한 기능 소개도 받았지만, 전반적으로 내용이 산만해서 발표 의도를 가늠하기가 어려웠습니다. Feature flag를 지라에 연결해서 관리할 수 있다니 대단하네요. On/Off 까지도 지라에서 할 수 있는 것으로 이해했는데, 어떻게 사용하는 건지 한 번 찾아봐야겠습니다.

 

코드 리뷰의 또 다른 접근 방법: Pull Requests vs. Stacked Changes

Pull Requests
- 변경 내용이 왜 커졌던 걸까. Commit을 나눠도 리뷰할 땐 File Changed로 일단 가서 보니까.
- 코드 리뷰 속도 느려짐.
Stacked Changeds
- Graphite 그라파이트
- GitHub 연동 됨. 대시보드 상에서 stack으로 보여줌.

  Base branch를 연결해서 PR 기차를 사용하던 것과 유사한 접근입니다. (PR 기차는 지어낸 용어입니다.) 실제로 PR을 생성해주는 것인지 Graphite가 approve, merge, rebase 에 준하는 동작을 직접 관리해주는 것인지는 확인이 필요합니다. 1, 2, 3번 commit이 stack을 이루고 있을 때, 1번 commit이 change request를 받는다면 어떤 식으로 해결하게 될까요? main에는 언제 merge되는 걸까요?

 

나와 팀을 성장시키는 리뷰들 - 코드리뷰만 리뷰가 아니라니까?

일하는 일련의 과정 속에서 각 단계별 리뷰.
요구 사항 분석 단계 - 설계 단계 - 구현 단계 - 테스트 단계 - 배포 단계
1. 요구 사항 분석 단계의 리뷰.
  - 다양한 이해 관계자의 상충할 수 있는 요구사항을 고려. → 문제를 명확히 정의하는 것이 중요.
2. 설계 단계의 리뷰.
  - 하지 않아도 되는 일, 하면 좋은 일을 하지 않게 해주고.
  - 테크 스펙. 뱅크 샐러드의 사례.
3. 구현 단계의 리뷰
  - 요구 사항이 온전히 반영되었는지.
  - 코드의 확장성, 응집도. Side Effects.
  - 기술 공유
4. 테스트 단계의 리뷰
  - 예상과 실제에 어떤 차이가 있는지.
  - 테스트란 이미 리뷰의 의미를 담고 있음.
  - 테스트 자체도 리뷰하기 → 테스트 코드를 리뷰. 테스트 시나리오를 리뷰.
5. 배포 단계의 리뷰
  - 배포 후에도 리뷰? 의도대로 사용되고 있는가. 성능 문제는 없는가.
6. 장애 발생 시, 리뷰
  - 탐지 → 공지 → 전파 → 복구 → 후속 조치
  - 근본적인 원인이 무엇인가. (’누가'에 대한 것은 제외)
  - 재발 방지 대책 수립.
7. 그리고, 성장
  - 각 단계의 리뷰를 잘 하면? 일을 잘 하는 사람이 된다.

  뱅크 샐러드의 테크 스펙. 최근 읽은 '구글 엔지니어는 이렇게 일한다'에서도 설계 문서란 명칭으로 유사한 문서를 작성한다고 합니다. 심지어 거긴 반드시 2개 이상의 설계를 제출해야한다고 하는데... 설계 단계의 리뷰를 잘 할 수 있도록 더 노력해야겠습니다.

 

지금 당장 DevOps를 해야 하는 이유

- 속도를 빠르게 하고, 일정을 맞출 수 있으려면?
- AWS. 평균적으로 11.7초마다 배포가 이루어진다고.
- 어떻게 하면 개발과 배포를 빠르게 할 수 있을까? → 데브옵스를 도입하면!
- 개발과 운영의 합성어. 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.
- ‘데브옵스하면 쿠버네티스가 떠오릅니다.’? → 하지만 도구가 적재적소에 잘…
- DevOps = 철학 & 방법론 → 문화
- 도구를 도입하는 목적은 개발과 배포를 편하고 빠르게. 무슨 도구를 쓰느냐가 문제가 아니라.
- 스터디, 코딩, 코드리뷰, 소스관리, 빌드, 테스트, 배포, 운영, 모니터링. 어느 단계든 작은 지연들이 모여서 느리게 만드는.
- Git clone이 느린데? → Shallow clone
- 주간 보고 정리가 오래 걸리는데? → git changelog generator. gitmoji?
- 배포가 자꾸 깨져 → Docker?
- 테스트가? → E2E 테스트 도입.
- 결국 네 가지로 정리. 자동화 / 측정 / 공유 / 축적
- 공유: 노하우와 프로세스를 문서화하고. 공유하고 발표하고.
- 축적: DevOps를 문화로 받아들인다는 것? 도입해보죠. 개선해보죠.

  생각했던 것보다 DevOps의 영역이 넓고 일상적이어야 하는구나 했습니다. 각 단계에서 발생하는 작은 지연들이 결국 모이면 전체를 느리게 한다는 것인데, 툴이나 자동화를 통한 개선 뿐 아니라 일하는 방식, 협업 방식을 개선하는 것도 다 포함해야할 것 같습니다. 이렇게 생각하다보면 DevOps가 별도로 있어야 하는 포지션인가... 모두가 DevOps가 되어야 하나... 싶다가도, CI/CD를 누가 책임지긴 해야하니까...  전문가가 필요하니까... 하고 생각하게 됩니다.

 

FE 개발자도 할 수 있다! RESTful API 개발 (with Firebase, GCP)

- 프론트엔드 개발자는 어디까지 해야하는가?
- 웹 클라이언트. DB의 데이터를 API를 이용해서…
- Serverless. AWS Amplifier, GCP Firebase, Asure…
- Firebase. 왠만한 경우에는 무료 플랜 범위를 안 넘어감.
- CORS 에러? 로컬에선 괜찮았는데, 배포를 해보니 문제가… 프론트쪽 이야기인가?

  시작하면서 프론트엔드 개발자들 손을 들어보라고 했는데, 모바일 앱 개발자도 포함되는 맥락인지 아닌지 약간 혼란스러웠습니다. 들어본 결론은... 우린 아니었다! 사실 거의 따라잡지 못하고 그냥 허허 그렇구나 하면서 들었습니다. 앱의 경우, Firebase에 완전히 종속될 각오만 한다면 아예 backend 배포 없이도 유사한 요구 사항을 구현할 수 있을 것 같은데...

---

  마지막 세션이 남아있었지만, 육체적 피로와 공복을 이기지 못하고 리타이어 했습니다. 영상이 공개되면 아래 4개도 마저 따라잡아야겠네요. 즐거웠습니다. 준비하신 분들, 발표자 분들 모두 감사합니다.

• 나도 내 코드의 문제를 찾고 싶다고요?! - 테스트 할 때 기억할 7가지
• Rust 크로스 플랫폼 프로그래밍
• 개발자의 셀프 브랜딩
• 어느 날 고민 많은 주니어 개발자가 찾아왔다 - 성장과 취업, 이직 이야기