전체
약 10대 1의 경쟁률을 뚫고 점핏에서 진행하는 개취콘에 다녀왔다.
입장 시간이 12시 30분 부터 였지만, 15분쯤 도착했을 때 이미 꽤 많은 분들이 입장한 뒤였다.
여러 컨퍼런스들을 다녀왔지만.. 책을 선물로 주는 곳은 이번이 처음이었다.
언어 관련 서적, 프레임워크, Git, 퍼블리싱, 소프트스킬, 마인드셋 서적들까지 다양하게 준비되어 있었다.
이외 스티커, 피규어, 보조배터리 등 다양한 선물도 같이 받을 수 있었다.
약 180명이나 되는 분들이 모여서 장소가 꽤 좁고 발표 화면까지 좀 먼 분들도 계셨을 거 같지만, 발표자료를 먼저 공유해주면서 이 부분은 잘 해결된 거 같았다.
전반적으로 강연자분들이 정말 발표에 능숙하시고 진행도 깔끔했다. 강연자분들의 세션 하나하나 정말 좋은 주제들을 다루고 있었다.
컨퍼런스 준비를 정말 철저하게 하신 것 같은 느낌..
루기님 서적에 싸인도 받을 수 있었고, 박용권님께 기술적으로 궁금했던 부분도 여쭤볼 수 있는 좋은 기회였다.
세션별 기록
세션 1. 중요한 건 인터페이스야
중요한 것은 이해관계자들 사이의 공유 결계, Interface
먼저 다른 얘기
인프콘에서 들었던, 김정규님의 발표였던 오늘도 여러분의 API 는 '안녕' 하신가요?와 연관이 많은 발표입니다.
인프콘 발표는 API First Design을 통해 이해관계자를 포함한 프론트엔드, 백엔드 개발자가 함께 Open API 명세서 설계부터 함께 진행하는 내용으로
, 기존의 Code First Design보다 API 명세로 인한 고통을 없앨 수 있다는 내용입니다.
심각하게 요약된 내용이라 나중에 인프콘 영상이 올라오면 볼 수 있겠지만 일단 먼저 발표 자료 링크라도 공유하겠습니다.
돌아와서
Json 손진규님의 발표내용은 API First Design 보다 더 포괄적인 내용을 다루고 있습니다.
위에서 언급했던 이해 관계자들까지 이 개발 프로세스에 포함을 한 내용이었습니다.
인터페이스의 정의는
In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information.
위와 같습니다.
즉, 둘 이상의 분리된 컴포넌트들 사이의 서로 공유된 경계를 의미합니다.
고객 - 디자인 - 클라이언트 - 서버 각 이해 관계자들 사이 사이마다 이러한 인터페이스가 있게 되는 걸 의미합니다.
현실
서버 개발자: "어... 이거는 개발이 좀 힘든데요?"
클라이언트 개발자: "음.. 그렇게 만들면 제가 쓰기 어려운데요"
디자이너: "어... 제가 원하던 거랑 동작이 좀 다른데요?"
고객: "어... 이건 제가 원하는 것이 아닌데요?"
많은 커뮤니티나 주위 분들의 얘기만 들어봐도 위와 같은 대답을 들었다는 이야기를 많이 볼 수 있습니다.
해결법
디자인, 클라이언트, 서버 개발자들은 함께 기획하면서 제품에 대한 높은 이해도를 가지는 것이 필요하고, 또한 지금 만들고 있는 제품이 고객이 원하는 제품인지를 인지하는 것이 중요합니다.
각 이해관계자들이 서로에 대한 이해가 부족하게 되면 망하거나, 변경하는데 엄청난 비용을 수반하게 됩니다.
-
제품에 대한 이해도를 높이는 방법에는 위에서 언급했던 API First Design을 이용해 볼 수 있을 것 같습니다.
-
고객의 니즈를 파악하기 위해서는 MVP나 Pretotyping(Pre-Prototyping)과 같은 방식을 이용해 볼 수 있습니다.
고려해야할 점
사공이 많으면 배가 산으로 간다는 말이 생각났습니다.
결국 이해관계자가 많아지게 되면 의사 결정이 어렵게 되기에, 서로 약속을 정해야합니다.
이 때의 기준은 고치는 일이 발생한다면, 비용이 많이 드는 것이 높은 우선순위를 가집니다.
이는 불확실성이 높은 것 부터 약속을 정해야 하는 것과 비슷하다고 볼 수 있습니다.
보통 이렇게 불확실성이 높은 요소들은 본능적으로 미루게 되고 싶기에 미루고 싶은 것에 대한 약속을 정하는 것으로도 이해할 수 있습니다.
Q&A
같이 일하고 싶은 개발자
- 센스있게 일하는 개발자, 믿고 맡길 수 있는 사람.
레퍼런스 체크를 위해 연락이 왔을 때,
"그 사람한테는 믿고 맡길 수 있어"라는 말이 나오는 사람.
- Context의 부재를 적극적으로 어떻게 처리하는 게 좋을지를 고민하는 사람
아무리 서로 소통을 하더라도, 서로의 Context를 모두 이해하기는 쉽지 않기에, 이러한 간극을 채우기 위해 노력하는 사람.
위와 같이 일하기 위해 좋은 tool?
피그마의 피그잼
유저 스토리 매핑하기 적합함.
또한 시각적으로 업무들 간의 연결관계, 또한 큰 청사진을 한눈에 볼 수 있음.
세션 2. 토스뱅크 기업문화와 성장하는 주니어 BE특징
내게 맞는 성장 환경 찾기
기존의 제너럴리스트 개발자들이 점차 DBA들에게 업무를 위임하게 되는 것으로 시작해서 서비스 개발팀, 공통된 기능을 위한 플랫폼 개발팀, DB팀 등으로 팀들로 분화되기 시작했습니다.
팀의 업무, 팀의 목표가 생기게 되면 내가 하는 행동이 팀의 OKR에 부합하지 않게 되면 점차 업무 범위에 제약이 생기게 됩니다.
토스 뱅크는 원팀으로, 같은 목표를 위해 일하고 있고 같은 인센티브를 받고 있다고 합니다.
물론 이미 여러 팀으로 분화가 되어 있다면, 경직된 구조에 굴하지 않고, 본인만의 OKR을 설정하고 이를 달성하기 위해, 조직원으로서 다른 팀들의 업무에도 관심을 갖고 배우기 등의 노력을 하면 된다고 합니다.
기업의 QA팀이 존재하는 경우, 기존에는 모든 개발자들이 소프트웨어 품질 책임을 지게되었던 것에서 QA팀이 이를 담당하게 되면서.. 장기적으로 부정적인 영향을 끼칠 수 있다고 합니다.
세션 3. 알아두면 쓸 데 있는 코틀린
나만의 지식 포트폴리오
4월 인프런에서 진행한 퇴근길 밋업에서의 내용과 연관이 많아서.. 간략하게만 소개하겠습니다.
지식에 대한 투자가 가장 큰 이윤을 남긴다.
수 많은 언어들이 있고, 언어들마다 고유의 패러다임을 갖고 있습니다. 새로운 언어를 배우게 되면 한가지 문제를 해결하더라도, 다각화된 접근 방법을 도입해 볼 수 있습니다.
또한, 한가지 언어를 깊게 배우고 난 후에는 새로운 언어를 배울 때도 기존의 지식을 활용하여 좀 더 쉽게 배울 수 있습니다.
세션 4. 컨테이너 인프라의 필요 배경, 왜 지금 배워야 하는가?
쿠버네티스는 왜? BE 주니어에게 특별히 좋을까
쿠버네티스는 왜? BE 주니어에게 특별히 좋을까요
인프라 엔지니어 뿐만 아니라 적용할 수 있는 것들이 많습니다.
쿠버네티스는 왜 필요할까?
도커 없었으면 어떻게 해야했을까? 를 고민해보는 걸 추천해주셨습니다.
DB를 직접 세팅하고, 배포도 직접하고.. 등등 쿠버네티스를 이용하게 되면 시간을 아낄 수 있고 이는 곧 돈을 아낄 수 있다는 걸 의미합니다.
그럼 어떻게 공부해야 하나요?
쿠버네티스 공부하면 이에 필요한 클라우드, 가상화, 리눅스 배경 지식 등 다양한 방면으로 학습할 수 있습니다.
레퍼런스, 강의, 서적 등 많은 방식이 있지만, 레퍼런스를 통한 공부를 추천해주셨습니다. 쿠버네티스 레퍼런스는 한글화도 많이 되어있고, 만약 미흡한 부분이 있다면 직접 기여도 할 수 있는 기회이기에 가장 추천하는 방식이라고 하셨습니다.
ETC
예시 - Argo CD를 이용한 GitOps
https://yozm.wishket.com/magazine/detail/2010/
자격증?
다른 자격증들 보다도, 가장 유용하다 생각하신다고 합니다. 실제로 레퍼런스를 많이 읽는 것이 가장 쉬운 공부법이라고 하셨습니다.
Q&A
쿠버네티스 로깅
Q: 모놀리식은 한개의 서버 로그만 보면 된다. 하지만 마이크로서비스는 분산되어 있는 로그를 사용한다면 이를 어떻게 처리해야할지 모르겠다.
A: GKE, EKS 등 플랫폼의 서비스 쓰면 just in works라고 합니다.
쿠버네티스는 여러 서버에 대한 접근이 가능하므로, 로그 통합이나 네트워크 추적과 관련된 서비스는 손쉽게 가능하다.
CD는 어떻게 하면 좋을까요?
CLI에 익숙하다면, flux를 GUI를 원한다면 Argo를 사용하면 된다고 합니다.
https://earthly.dev/blog/flux-vs-argo-cd/
또한 추가적으로 오토 스케일링에 대해서는 Karpenter에 대해서도 알아보면 좋다고 하셨습니다.
모니터링/ 메트릭은 어떻게하면 될까요?
그라파나, 프로메테우스와 같은 툴들이 있는데, 쿠버네티스 환경에 맞는 녀석을 잘 골라서 쓰면 똑같이 just in works라고 합니다.
헬름 차트 사용하면 원하는 거 그냥 쉽게 쉽게 가능하다고 합니다.
