🍀 올해도 인프콘에 가게 됐다!
첫 해에는 정말 운이 좋게 당첨이 돼서 다녀올 수 있었고 작년에 이어서 올해도 우드 덕분에 초대권을 받아서 다녀올 수 있었다!
최근에는 랠릿도 열심히 사용하는 엔드유저로서, 인프런과 랠릿 서비스가 매일 조금씩 좋아지는 걸 경험하고 있는데 인프콘도 매년 달라지는 프로그램들을 경험하러 가는게 너무 기대되고 즐겁다! 이번에 랠릿 허브랑도 연동해서 인프콘 참여자들을 필터해서 보는 거랑 프로필 QR을 네임택에 붙여주시는 것도 재미있었다!
회사에서 여러 경험들을 하면서 작년보다 올해는 발표 세션을 들을 때 더 많은 내용들이 들리고 공감되기도 했다. 역시 아는 만큼 보인다는 말을 또 되새기며 내년에는 올해보다 더 많은 경험을 하고 더 시야를 넓혀서 참여할 수 있으면 좋겠다고 생각했다.
작년에는 세션도 열심히 듣고 기업 부스도 열심히 참여하느라 체력이 정말 바닥났던 기억이 있어서 올해는 기업 부스는 거의 참여하지 않고 중간에 시간이 나면 네트워킹에 참여해야겠다는 마음으로 갔다 ㅎㅎ
🐬 발표 세션
3년째 혼자 참여한 대문자 I는 올해도 세션을 6개나 듣고 왔다 🤓
1. 지속 성장 가능한 설계를 만들어가는 방법
예전에 개발바닥에서 재민님 인터뷰를 재미있게 봤었는데 첫 세션으로 있어서 시간표에 담아뒀었다
최근에 회사 코드에서 circular dependency 문제를 보기도 했고 여러 개념이 한군데 뒤섞인 설계에 피로감을 느끼던 중이라 관심이 갔다. 새로운 기능 개발에 들어가면, 기존 코드베이스와 통일감을 가져가면서도 최대한 의존성이 적은 설계를 해야할 것 같은 부담감에 설계 단계를 가장 어려워했는데 설계를 하지말고 바로 구현을 하라는 말씀을 바로 시도해봐야겠다고 생각했다!
[메모]
"설계를 잘 하는 방법은 설계를 하지 않는 것이다."
- 설계를 하다보면, 개념들에 대해 생각하다가 개념 그룹이 많아지고 개념 사이의 흐름이 잘 안보이거나 개념들간 격리가 잘 안되게 된다.
- 개념 사이에 방화벽 역할을 하는 격벽을 세워, 의존과 참조를 통제하고 흐름을 만든다.
- 코드상에서 개념과 격벽이 잘 정의 되었는지 느껴보자.
- 하나의 개념이 너무 많이 쓰이면, 개념이 너무 많은 것을 담고있을 수 있으니 분리를 검토하자.
- 상태에 의해 개념이 생기면, 격벽을 세워보자. (예. 상환 실패 => "연체" 개념 추가)
- 참조 불가의 벽: 개념이 없는 곳(외부 서비스, 테스트 코드)은 내부의 개념이 있는 곳과 격리 해야한다.
"software는 soft 해야한다."
- 요구사항은 언제나 변화한다. 변경되는 요구사항을 유연하게 적용할 수 있는 설계를 해야한다.
- 분석하고, 설계하고, 구현하지 말고 계속 구현만 하자.
- 변경하면서 계속 증명할 수 있는 환경을 테스트코드로 마련해두자.
2. 디버깅 마인드셋: 디버깅의 고통을 절반으로 줄이는 고수들의 행동패턴 따라하기
지난주에 헤더가 변경되서 들어온다던가.. 데이터 변경이 예상치 못하게 발생한다던가.. 원인 파악이 어려운 버그들이 연달아 들어왔는데 마침 디버깅 관련 세션이 있어서 듣게 됐다. 역시 고수들은 본인이 어떻게 사고하고 행동하는지 설명하지 못한다는 말이 떠올랐는데, 발표자분께서 그런 고수들의 암묵지를 적극적으로 인터뷰하고 연구하신게 인상적이었다.
[메모]
디버깅할 때 하는 행동
- 원인파악 60% -> 문제해결 30% -> 사후처리 10%
- 어떤 조건에서, 어떤 순서로, 어떤 일이 일어나야 하는지에 대한 정상 상태를 정의해야한다. (심정 표상)
- 정상 상태를 정의하지 못한다면 아직 더 많은 정보 수집이 필요한 것이다.
- 상황에 맞는 디버거를 사용해야 한다. 실용적 도구의 필요성
- DescriptionDrivenDebug / 커밋과 PR은 나중, 남을 위한 것이라고 생각.
- 문제 정의 -> 정상 상태 정의 -> 최소 재현 환경 구축과 관찰 -> 다양한 원인 탐색 -> 가설 설정 및 검증 을 반복한다.
3. 경력이 늘수록 CS이론이 중요해지는 이유
널널한 개발자님을 작년에 <HTTP 완벽 가이드> 스터디를 하면서 알게 됐는데 발표 세션을 하셔서 놀랐다! 내가 새로운 기술이나 도구를 익히는게 재미있지만 처음에 부담감이 있다는 고민을 이야기 했을 때, 팀원분께서 결국에는 모든 웹 기술과 도구들은 컴퓨터 시스템 위에서 동작하는 것이기 때문에 민서님이 아는 CS 시스템과 유사하게 동작한다. 라고 이야기해주셨는데, 그 이야기를 듣고 CS 지식이 탄탄한 개발자가 되고싶다는 생각을 했었다. 발표에서도 비슷한 결의 이야기를 들으며 공감이 많이 됐고 아직 연차가 낮은 이 시점에 CS 이론 공부를 틈틈히 잘 해둬야겠다고 다짐했다.
[메모]
cs 이론을 잘 알면,
- 새로운 웹 프레임워크가 놀랍지 않다.
- 새로운 언어나 기술을 접해도 근본적으로 달라지는 건 없다는 생각
- 환경 전환이 쉬워진다.
- 컴파일러를 배우면, 프로그래밍 언어들에 대한 나의 식견이 생긴다.
cs 이론을 잘 모르면,
- 원리를 이해하는게 아니라, 표면적인 현상을 외우게 된다.
- 나는 왜 개발자가 되었나?, 나의 정체성과 독보적인 전문성을 마련해야 한다.
- 하루에 2시간을 할애해야한다. 타협할 수 X
4. 혹시 당신은 데이터를 모르는 백엔드 개발자 인가요?
혹시 당신은 데이터를 모르는 백엔드 개발자 인가요? 네.. 하며 시간표에 담은 세션이다. 백엔드 개발자이신 김지호님이 데이터 팀에서 근무하시면서 얻은 인사이트를 공유해주신 발표였는데, "백엔드 엔지니어에게는 데이터의 행이 중요한데, JSON으로 여러 정보가 하나의 열에 같이 담겨있으면 열 단위 분석 비용이 늘어난다"는 말씀이 정말 공감됐다. 종종 고객사나 PM팀에서 데이터를 요청하시면 가뜩이나 NoSQL이어서 보조 인덱스를 세팅해두지 않은 경우에 추출하기 곤란한데, JSON 타입 열에 대한 분석이 필요하면 과거의 나를.. 후회했었다 🥲 평소에도 클라이언트 팀을 대상으로, 새로운 테이블을 추가하면 문서화를 해두는 편인데 새로 알게된 Data Catalog를 도입해봐도 좋겠다 싶었다! 그리고 발표를 들으면서 고등학생때 데이터 엔지니어가 되고싶었던게 생각나기도 했다 ㅎㅎ
[메모]
데이터를 보는 관점
- 백엔드 엔지니어에게는 데이터의 행이 중요한다.
- 데이터 엔지니어에게는 데이터의 열이 중요하다.
- JSON, Array로 뭉쳐 하나의 열에 담으면 편하지만, 열 단위 분석 비용이 늘어난다.
- 어떤 필드가 비즈니스 분석에 필요하다고 판단된다면 정규화를 해야한다.
- 테이블 설계 맥락이 잘 공유되어야 한다.
- DB Comment, DATA Catalog (오픈소스 DataHub)
- 라이브 DB에 무거운 분석 쿼리를 날릴 수 없기 때문에, 분석환경을 분리해서 운영한다.
- 데이터를 기능적인 면에서만 고려하면 안된다.
5. 우리 회사에도 LLM 기반의 서비스를 도입할 수 있을까요?
코파일럿이나 Chat GPT 같은 툴을 사용하기는 하지만, AI가 나와 별개라는 생각이 불쑥불쑥 들던 것을 경계하기 위해서 작년부터는 컨퍼런스에 가면 AI나 ML등의 주제에 대한 세션을 들어보고있다! 이해가 안되도 가볍게 듣자는 마음으로 갔는데, 잘 모르는 사람들도 이해할 수 있게 용어부터 쉽게 설명해주셔서 좋았다. 프롬프트 엔지니어링, 회사에서 LLM 서비스를 도입할 때의 프로세스를 대략적으로나마 알 수 있었다!
6. 소수 인원으로 글로벌 1위 앱 서비스를 만든 비결
평소에 알라미도 사용하고있고 딜라이트룸 회사 문화에도 관심이 많았는데, 패널토크가 있어서 듣게 됐다. 고객 목소리에 귀기울이는 것, 우선순위를 정하고 하나의 목표를 가져갈 수 있게 하는 것 등 단순히 도덕책같은 비전과 목표를 제시하는 게 아니라 실현하기 위해서 치열하게 고민하고 노력하는 팀인 것 같다는 생각이 들었다. 특히 안정성이 99.5%인 시스템에서 구멍을 발견하고 팀을 설득해서 개선 작업을 진행했고, 커다란 매출 증가로 이어졌던 사례를 들어주셨던게 인상적이었다. "불편을 감수하는 부지런한 개발자는 팀에 필요 없다"라고 하셨던 향로님의 글이 생각나기도 했다.
[메모]
- 우리만의 수상한 시간 활용법 6+2 = 12
- 매 스프린트마다 팀의 가용 시간을 트래킹, 예측해서 태스크를 정한다.
- 하루 8시간 중 2시간을 버퍼로 둔다.
- 오버페이스도 예방할 수 있고, 시간관리를 효율적으로 할 수 있다.
- 8시간을 모두 사용했을 때와 결과는 동일한데, 팀원들이 느끼는 심리적 성과가 다르다.
- 좋은 게 좋은 것이다는 나쁜 것
- 안정성이 99.5%인 코드 개선 작업을 진행한 사례
🧵 네트워킹
대문자 I에게 혼자 네트워킹 프로그램에 참여하는건.. 너무나도 어려운 일이지만 주변에 개발 고민을 나눌 분들이 많지 않고 좋은 자극에 대한 갈증도 커져서 최근에는 커피챗도 해보고 컨퍼런스에 참여하게되면 네트워킹 프로그램에도 참여해보고있다!
야심차게 들어갔지만 불안한 눈빛으로 두리번거리고 있었는데 친절한 스탭분께서 백엔드 무리에 넣어주셨다 ㅋㅋㅋ ㅜㅜ
나와 비슷한 2년차부터 5년차, 10년차 개발자 분들과 대화를 나눌 수 있었다.
여러 도메인 경험들을 듣는게 재미있었다! B2B 회사에서 일하면서 다양한 비즈니스 케이스를 간접적으로 경험하고 도메인별로 특성과 니즈가 천차만별이구나싶었는데, 아직 모르는 세상의 이야기들이 훨씬 많았다.
우연히 빅테크 개발자분들이 한자리에 모였는데, 헥사고날 아키텍처 실무 경험들도 들을 수 있었고 Onion Architecture 라는 몰랐던 아키텍처도 소개받았다. 취업을 한 뒤로는 주로 회사에서 사용하는 기술이나 이론들을 공부하다보니 그 외의 주제들은 흐린눈 하고 있었는데, 새로운 인풋을 넣는것도 게을리하지말자고 다짐했다.
💭 후기
올해도 알차게 좋은 세션들을 많이 듣고왔다. 컨퍼런스에 다녀올 때마다 그 활기찬 현장감 덕분에 동기부여를 많이 얻고온다. 내년에 또 인프콘에 갈 수 있다면, 세션 뒤 질문을 많이하고 네트워킹에서 내 이야기를 많이 나눌 수 있도록 1년간 열심히 해야겠다는 생각이 들었다!
한 타임에 듣고 싶었던 발표가 많았어서 얼른 영상이 올라오면 좋겠다 🤓
감사합니다 인프랩!!
'Notation > 회고' 카테고리의 다른 글
| 스타트업 백엔드 개발자 첫 1년 회고 (0) | 2024.02.22 |
|---|
