총 950명 정도가 참여했었던 내 개발자 인생 첫 컨퍼런스인 Devfest 참여 후기를
스피킹 내용을 듣고 개인 관점에서의 느낀점을 써내려가려고 한다.
티켓을 제공해주셔서 다시한번 감사의 인사를 드리며,
대면으로 감사인사를 드리지 못해 정말 죄송합니다.
혹여 포스팅에 컨퍼런스와 관련되어 문제되는 부분이 있으면 수정해서 반영하도록 하겠습니다.
서론
1년차 백엔드 개발자의 회고록
두서없이 쓰는 본인의 개발 입문 1년( + 1개월) 기념 (실무 3개월차) 1년을 되돌아보며 작성하는 장황한 글이다. 왜 개발자를 선택했는가? 나는 작년 11월. 국비지원 백엔드 개발자 양성과정 교육을
mag1c.tistory.com
1년을 되돌아보는 회고록을 올린지 얼마 되지 않아 한 댓글이 달렸다.
데브 페스트에 참여하신다면 인사 나누어요!! 라는..
내가 놓친 컨퍼런스가 있나 싶어서 급하게 찾아보았고, 페스타에 다음과 같은 컨퍼런스 주최글이 있었다.
Devfest Songdo 2023 | Festa!
Festa에서 당신이 찾는 이벤트를 만나보세요.
festa.io
코드너리에도 명시되어 있었는데, 카카오 테크 밋업으로 연말을 마무리해야지 하는 생각이 머리를 지배하고있어 놓쳤었던 것 같다.
하지만, 운이 좋게도 어떻게 티켓을 한 장 구할 수 있게 되어 참여할 수 있게 되었다.
티켓을 제공해주셔서 다시 한 번 감사드립니다..
섹션 선택하기
페스타에도 있듯이, 섹션별로 정리가 잘 되어있었다.
나는 입사한지 얼마 안되었기도 했고, 원래는 스프링을 주력으로 했지만, Nest를 현재 사용하여 개발하고 있기 때문에
Nest를 0번 타겟으로 삼았고, 나머지 섹션들도 선정했다.
송도로 ㄱㄱ
노트북을 챙기려고 가방을 싸는데, 우리 구찌가 같이 가고싶었던 모양이다 ㅋㅋㅋ
이것저것 준비하느라 20분정도 걸렸는데, 그 때까지 얌전히 가방에서 기다리더라..
다음에 송도 같이가자 구찌야 ㅋㅋ
행사 굿즈도 있었는데, 사진은 찍지 못했다.
기본으로 티셔츠와 GDG, 구글 등등 스티커를 제공해주셨고
인형을 살 수 있었던 것 같았다.
Keynote(13:00 ~ 13:20)
🗣️ : 김석용 님(주최측), Kristine Song 님 (Google Korea)
개발자 커뮤니티를 통해 좋은 인사이트를 얻고, 개발자로서 성장해나가자.
Keyword: Learn, Connect, Inspire, Develop your skils, Network & Showcase
- Git, Stackoverflow 등 커뮤니티를 통한 활발한 활동 (생각 교류, 토론) / 행사 발표, 오픈소스 기여 활동
영어라는 진입장벽이라는 핑계로 스택오버플로우를 트러블슈팅 시 서칭 수단으로만 사용했고,
오픈소스는 아래 섹션에 더 얘기하겠지만, 마찬가지로 진입장벽이라는 핑계를 댓던 것 같다.
진입장벽이고 뭐고 그냥 시도해보기. 개발을 처음 접했던 그 때 처럼.
효과적인 단위 테스트 (13:20 ~)
🗣️ : 장동혁 님(Coupang)
사수분으로부터 아래 책을 추천받아, 읽어보시고 효과적인 단위 테스트에 대해 생각을 공유해주셨다.
단위테스트의 정의, 좋은 단위테스트란?
Keyword: 마틴 파울러, 단위테스트, 통합테스트, E2E테스트, given when then, 고전파와 런던파, 모킹, 테스트 커버리지
- 버그 방지, 리팩토링 내성, 빠른 피드백, 유지 보수성을 고려한 테스트.
- 유지보수성은 영향을 주지 않으니 별개로 둠
- 버그 방지를 극상으로 끌어올린 후 테스트의 성격에 따라 리팩토링 내성과 빠른 피드백 중 어떤 것에 중점을 둘지 고려
- 프로덕션 코드작성 라이프사이클 내에 테스트 코드 작성을 포함시켜라.
- 리팩토링 내성 측면에서 고전파 방식이 더 좋다고 생각한다.
다행히 수 개월 전에, 처음 TDD와 테스트에 관련된 개념을 접하면서
중요성을 알게 됐고 개발바닥을 통해 인프런에서
박우빈님의 실용적인 테스트 가이드를 학습한 경험이 있어서 스피킹을 이해하는 데 충분했다.
고전파 방식을 선호한다는 것이 좀 중요하게 다가왔던 것 같다.
한 로직을 테스트하는데 있어 해당 로직의 하위에
별거 아니라고 생각할 수 있는 기능 구현 코드가 변경되면 테스트가 깨지기 때문에,
스피킹을 예로 들면, 로그인 시 id, pw 파라미터를 통해 그대로 로그인을 수행하던 로직에서,
로직 내에서 DTO를 선언해 유저 로그인을 구현하게 변경한다면
id, pw가 변경되지 않았기 때문에 기능에 문제는 없지만
테스트 자체가 깨져버린다는 내용..
우선 현재 다니는 회사의 특성상, 일정이 빠르게 돌고 새 프로젝트가 계속 생기다보니테스트 코드 작성에 대해 공부를 했지만서도회사 스타일에 맞게 프로덕션 코드를 개발서버에서 통합 테스트 후 QA를 진행하고 있는데,일정을 조금 더 길게 두고 테스트 코드 작성을 하게 사내 문화를 바꾸는 시도를 해보아야겠다고 생각했다.
오픈소스 기여로 수억명에게 임팩트 만들기 / 누구나 원하는 오픈소스에 기여를 (14:10 ~)
🗣️ : 김인재 님(LINE Plus)
GDG에서, 오픈소스 관련 리딩 그룹(?)을 운영하시면서, 이번 기수들의 오픈소스 경험담을 들려주셨다.
오픈소스는 90%가 진입장벽에 막혀있다.
이를 해소하기 위해 우리 GDG 오픈소스 관련 그룹(가명)에서는 이 진입장벽을 해소해주는 역할을 하고 있다.
원하는 오픈소스를 찾아오시면 (선택 이유 등을 기재) 이슈를 선정해 드린다.
이슈를 어떻게 접근하고 어떻게 해결해야하는지 등 같이 토론하며 PR / Merge의 경험 공유
확실히, 오픈소스에 대한 갈증은 늘 느끼고 있는데
우선 오픈소스 선정부터 골머리를 썩고, 오픈소스를 파악하기 위한 어려움.
그리고 공통분모인 영어의 진입장벽 등
여러 진입장벽들 때문에 오픈소스를 시도하는데 어려웠고, 다들 마찬가지라고 생각한다.
스피커님의 오픈소스 경험, GDG 오픈소스 그룹에서의 경험들을 공유해주셨는데 너무 재밌게 들었다.
특히 오픈소스의 진입장벽을 허물어주신다는, 본인의 기술을 공유하며 같이 토론하고
헤쳐나갈 수 있게 가이드라인을 제공해주시는 부분이 가장 인상적이었다.
개인적으로 가장 재밌는 섹션이였고, 오픈소스에 대한 열망을 끌어오르게 하는 섹션이었다.
1월에 오픈소스 3기를 모집한다고 하니, 참여하는 것을 계기로 오픈소스 기여에 스타트를 끊고 싶다는 생각을 했다.
(근데 뭔가 스피커분이 낯이 익다 했더니 비교적 최근 라인개발실록에 올라온 유튜브 영상의 주인공분이셨다 ㅋㅋ;;)
일 잘하는 개발자 - 소프트웨어 엔지니어링 생산성 되돌아보기 (15:00 ~ )
🗣️ : 배필주 님(GDG Android Korea)
아래 책에 대한 리뷰와 함께, 생산성을 향상시킬 수 있는 방법에 대한 스피킹.
Keyword: 생산성, 개발활동 시각화보드, 굿하트의법칙, FlowLight, ETA, COSMIC Function Point
시각화보드: https://www.codealike.com, https://www.rescuetime.com, https://wakatime.com 등
현재 내 환경에서의 지금과 미래에 대한 생산성을 생각해보게 되는 섹션이였다.
스피킹 요약이 적은데, 섹션을 들으면서 계속 나와 내 주변을 되돌아보게되었기 때문이라고 생각한다.
현재 사내에서는 빠른 속도로 계속해서 새로운 프로젝트들이 들어오는 상황이며,
입사 후 3개월이 지난 지금, 회사 환경에 맞춰서 내 프로젝트 라이프사이클을 회사 상황에 알맞게 적응시켜 놓은 상태이다.
우선 백엔드 코드를 프론트에서 통합하여 테스트할 수 있게 제공한 후,
프론트 작업과 QA를 진행하면서 오는 피드백들을 반영하고 있다.
과정에서 프로젝트 주기가 짧기 때문에, 위에서 언급했듯 백단에서 단위 테스트 코드를 따로 작성한다거나 하진 않고
프론트 단에서 API와 연동하여 작업하는 과정에서 오는 피드백들을 테스팅이라 생각하는 문화가 자리잡았다.
코드 품질적인 부분에서는, 배포 전까지 항상 리팩토링을 진행하고있다.
구구절절한 것을 요약하자면
1. 품질을 고려하지 않고 API를 작성
2. 배포 전에 품질 개선
3. 테스트코드 미작성 (테스트는 프론트에서...)
이런 방식을 고수중인데, 위의 단위테스트 섹션과, 이 섹션을 들으면서
반드시 프로젝트 라이프사이클 내에서 단위 테스트를 추가하고,
작업 시간을 조금 더 길게 가져가더라도 프론트에 API 제공 전에 1,2번을 합쳐서 해야겠다는 생각을 했다.
이런 간단한 생각부터 시작해서 현재 나 자신에 대한 반성과 앞으로 해야할 것들을 세부적으로 그려나갔던 섹션이었다.
NestJS Zero to One (15:50 ~ )
🗣️ : 권대건 님((현) JNPMEDI Backend Dev, (전) 슥삭 CTO)
NestJS를 사용한 계기, NestJS 소개
Keyword: 모놀리식 / MSA, NestJS Features (Module, Provider, DI, MiddleWare, Guard, Interceptors, Robuts Exception handling)
사실상 내가 해당 컨퍼런스의 0번으로 듣고 싶었던 섹션으로,
이유는 자바, 스프링으로만 개발을 하다가 현재 회사로 이직했는데, 개발환경이 Nest였기 때문..
무언가 딥한 사용후기나 기술적인 인사이트를 얻을 수 있지 않을까 싶었다.
너무 기대가 컷기 때문일까, 소개 정도로 그친 스피킹이었다고 생각한다.
공식문서에 있는 코드를 기반으로 소개를하셨고, 딥한 내용은 다루지 않았기 떄문에,
딥한 내용이 있다면 그에 대한 질문을 하려고 했으나 딱히 질문지가 없었다.
자사에서 네스트에서 걷어낼 것은 걷어낸 자체 프레임워크를 개발하여 사용한다고 하셔서,
Node보다 가볍지는 않기 때문에 어떤것을 취하고 어떤것을 버렸나?에 대한 질문을 하려고 했으나,
비슷한 질문이 나왔기 때문에 질문거리가 없었다 딱히 ㅠㅠ
내가 조금 더 깊은 개발 지식이 있었다면, 스피커분과 좋은 티키타카를 할 수 있지 않았을까..
GCP를 활용해 확장성있는 NextJS 인프라 구성하기 (16:40 ~ )
🗣️ : Daniel Lee 님(Google Senior Software Engineer)
Next를 Vercel과 같은 인프라를 구축할 수 있을까?? 에서 시작한
GCP, Firebase Hosting으로 호스팅한 경험.
Keyword: GCP, Firebase Hosting, Serverless, Auto-scaling, No Infra Management, Caching, Edge Location, CDN
- Cloud Run에서는 Next의 캐싱이 잘 되지 않았고, 이 문제를 캐싱에 적합한 Firebase Realtime DB를 이용해 해결하려 했다.
- Edge Location을 해결하기 위해 배포한 프로젝트를 Cloud Run에서 static파일은 CDN으로, CDN은 Firebase Hosting으로 해결을 시도했다. 유저가 접근 시 Firebase에서 CDN을 확인하여 있으면 바로 유저에게 보여준다. 이를 통해 req를 줄였고, 비용을 절감할 수 있었다. 확장성과 비용 측면에서 Firebase Hosting을 사용하는 것이 탁월하다!! (?)
- Firebase Hosting에는 블루그린 배포가 없다. 프리뷰 기능은 있다.
본인은 GCP나 Firebase를 판매하러 오신 게 아님을 강조하셨다. (?)
우선, 어떤 이슈를 해결하고자 이런저런 시도를 했고, 성공 경험. 한계치등을 명확하게 알려주셨다.
좋은 개발자가 되기.. 와 비슷한 주제를 다루는 영상이나 글들에서 항상 말하는
트러블슈팅에 대한 자세나, 본인의 경험을 써내려가는 스피킹이 엄청 인상적이었다.
Firebase에서 블루그린배포가 되지 않는다는 말을 듣고,
만약 배포를 시도할 때 잠깐 서버가 죽는 상황을 어떻게 대처해야할까? 생각해보게되었지만
명쾌한 해답이 떠오르지 않았다.
반드시 Firebase를 사용해 호스팅한다고 가정하면, 어떻게 대처해야할까?
잘 모르겠다. 찾아보고 공부를 좀 해봐야할 것 같다.
개발자로 무언가 나의 경험을 누군가에게 스피킹하거나 블로그에 써내려갈때
발표 내용은 사실 크게 와닿지 않았지만
발표의 전반적인 방향 자체가 내가 딱 원하는 이상향에 가까운 엄청난 발표였다.
세상에 꼬인 이력은 없다 (17:30 ~ )
🗣️ : 황혜경 님 (나인코퍼레이션 테크 리크루터)
스피커님을 포함한, 본인이 꼬인 이력이다 라고 생각하는 분들의 이력을 공유하며, 헤쳐나간 경험 공유
Keyword: STAR기법
- 이력을 쌓아나가는 과정은 나를 알아가는 과정이다.
- 관계는 어떠한 사소한 관계라도 도움이 될 수 있다.
- 경력에 대한 목표 설정(N년차의 나는 무엇을 하고있다.)
- 이력을 하나의 이야기로 만들기
이 섹션 또한, 위의 일 잘하는 개발자 섹션과 비슷하게 내 자신을 돌아보게 되는 섹션이었다.
꼬인 이력인지는 모르겠지만, 꼬인 사람(?)이 되어보는 시간이었다.
왜 그런가 하니 섹션을 듣는 내내 했던 생각들을 보면 답이 나오는 것 같다.
1. 채용하는 회사 입장에서, 나의 과정들을 긍정적으로만 봐줄까?
2. 나의 이전 인프라들에서, 현 분야에 도움이 되거나 잠재적으로 도움이 될 사람들이 있을까?
라는 생각들을 하게되었고, 둘다 No라는 답이 나왔다.
하지만 부정적으로 들었다고 부정적인 결론이 나오진 않았다.
1. 새로운 인프라들에서 좋은 인사이트들을 얻고, 나 또한 제공해줄것
2. 나를 알아가다보면 내가 원하는 회사는 결국 나를 원하게 될 것 (맞춰가면 되니까)
두 가지를 계속 생각하게 되는 시간이었다.
내가 단기, 장기적으로 무엇을 원하는가?
계속, 앞으로도 꾸준한 학습을 통해 성장하자!!!!
주니어 개발자의 서버 로그 관리 개선기 (18:20 ~ )
🗣️ : 김연희 님 (스몰티켓)
사내 서버 로그 관리에 대한 개선 경험 공유
Keyword: PLG(Promtail, Loki, Grafana)
- 스프링진영에서의 로그 관리법. (with slf4j)
- 로그의 정확한 필터링이 필요함
- 멀티스레드, 분산환경에서의 로그 추적의 어려움 > traceId로 해결 시도
- 로그의 시각화 시도 (PLG)
현재 사내에서는, 전사 채팅으로 MS의 Teams를 채택해 사용하고 있는데,
WebHook을 사용해서 에러 발생 시 채팅으로 로그를 받아보고 있다.
이렇게 구성을 해 놓으니, 에러 발생 시 채팅이 오기 때문에, 즉각적인 처리가 가능해졌지만
반대로 성능에 대한 모니터링이나, 디버깅과 같은 것들이 원활하게 처리가 되지 않는다고 생각한다.
실제로 갑자기 GPT에게 물어보고 싶어졌고, 아래와 같은 답을 해주었다.
안그래도 요근래 프로젝트들이 끝나고나면
이제 입사 4개월차에 접어드는 지금, 어느정도 적응도 마쳤기 때문에
레거시 코드들에 대한 리팩토링을 일정을 받아내서 대대적으로 진행해야겠다고 계속 생각하고 있었다.
이 때 로그에 대한 개선을 포함해서, 사내 서비스에 부족한 부분을 좀 채워넣고
나의 경험을 스피커분들처럼 서술해봐야겠다.
발표내용 관련해서 최근 배민 기술블로그에서 본 글이 있어 공유하고자 한다.
스피커분도 보셨는지 섹션 내에서 언급을 하셨다.
따끈따끈한 전사 로그 시스템 전환기: ELK Stack에서 Loki로 전환한 이유 | 우아한형제들 기술블로그
{{item.name}} 안녕하세요. 클라우드모니터링플랫폼팀의 이연수입니다. 우아한형제들의 모니터링시스템 구축 및 관리, 운영을 하고 있습니다. 작년부터 올해 초까지 팀에서 전사 로그 시스템을 전
techblog.woowahan.com
후기
포스팅에, 섹션 내용에 대한 깊은 리뷰보다는
그걸 듣고나서, 이제 1년차가 되어가려고 하는 신입 백엔드 개발자 중 1명의 관점에서
느낀 생각들을 서술하려고 노력했다.
사실 내가 기술적으로 깊은 섹션에 참여해봐야 얼마나 얻어가겠냐만,
그런 기술적인 섹션도 좋고, 동기부여가 되는 섹션도 좋다.
어떤 인사이트던 같은 개발의 길을 걸어가는 다른 개발자분들은 어떤 생각을 가지고 계시는지,
어떤 경험을 하고 계시는지 등을 듣고 보고싶었는데,
좋은 기회가 주어져서 많은 인사이트를 얻을 수 있는 자리였다고 생각한다.
괜히 컨퍼런스를 참여하는게 아닌 것 같다.... 라는 생각을 하게된다.
2023.04 ~ 백엔드 개발자의 기록
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!
