데브콘2024 다녀와서

created:

last-updated:

이번 포스트는 지금까지와 조금 다른 주제로 작성을 해봅니다. 이번주 한빛앤 사옥에서 진행한 데브콘2024 을 다녀왔습니다. 세션을 듣고 이것저것 드는 생각들을 몇 가지 키워드로 짧게 기록해두는데 목적을 두겠습니다. 기술적인 지식을 정리하기보다 현재 회사에서 일하는 방식, 개인으로써 일하는 방식, 앞으로 어떻게 할 것인가를 위주로 작성이 될 듯 합니다.

팀장이 되고서야 알게된 잘하는 개발자의 비밀 (당근 박미정님)

잡식성 야생 개발자의 성장기 (코드스쿼드 김정님)

나도 오픈소스 하나쯤 내놔볼까 (LINE 김영재님)

Rust는 어떻게 안전한 프로그래밍을 이뤄내는가 (Microsoft MVP, 42dot 옥찬호님)

세션중에는 이렇게 4가지 세션이 인상적이었습니다. 각 세션 모두 주제가 다 달랐고 관점과 발표 스타일도 다 다르셔서 40분이라는 세션 시간이 짧게 느껴질 정도로 흥미롭게 들었습니다. 그리고 오프라인 커뮤니티 행사에 많이 참여를 안해보기도 했고 너무 오랜만에 가본거라 그 현장감이 좋았네요. (참여설문 당첨돼서 입문서지만 개발공부 시작할 때 많이 봤던 생활코딩 이고잉님 의 git책도 받은ㅎㅎ)

1 .

모든 걸 다 잘할 수는 없다. 내가 잘 하는 걸 잘하기 위해 집중하자.
좋은 팀은 각각의 팀원이 자기가 잘하는 걸 잘하게 해준다.
문제를 해결하고 싶은데 잘 안될 때 나의 어려움의 배경, 진행상황, 시도한 내용, 어떤 도움을 요청하고자 하는지 장황하지 않게 공유하자. -> 이렇게 하면 결국 다음이 자연스럽게 된다.
나의 문제로 고립시키지만 말고 팀의 의제로 끌어올리자. -> 혼자서 안되면 리더를 적극 활용하자.
경력이 늘고 일이 능숙해져도 꼼꼼함을 놓치지 말고 끝까지 트래킹하는 습관을 들이자.

2 .

한 가지 기술만 고집하지 말자.
그치만 트렌드에 휘둘리지 말고 내가 정말 좋아서 하는 걸 하자. 필요한 걸 직접 만드시는 모습 멋있..
다른 걸 공부하거나 경험하더라도 언젠가는 도움이 된다. 10년뒤 20년뒤 또하나의 인사이트가 된다.
diversity를 위해 의도적인 액션을 취하는 것에 껄끄러워할 필요없다. 망설이지 말자. 마이크든 연사자분이 부드럽지만 강력하게 업계 성비와 장애인 접근성에 대해 언급해주셔서 감동이었다.

3 .

오픈소스 만든다고 생각하고 시작하면 훨씬 더 확장성 있는 구조를 만들 수 있는 시야가 생긴다.
동료를 설득하지 못하면 유저도 설득할 수 없다.
한 가지 일을 자동화하는 걸 만들어 프로세스를 개선하고나면 100가지의 일, 다른 환경의 프로세스도 개선할 수 있는 것도 만들어보자.
오픈소스는 배포방식의 일종이라고 생각하고 부담갖지 말고 시작하자. 레포지토리 소개에 이 소스가 하고자 하는 걸 명확하게 적어두고 시작하자.
버저닝 오픈소스 만드신게 참 좋다고 생각했다. 회사에서 시멘틱버저닝 쓰고 있긴 한데 매번 릴리즈 노트 써야하고 배포 됐나 안됐나 헷갈리고 아주 카오스라서 도입해보면 좋을 것 같다.

4 .

컴파일 타임에 안정성을 굉장히 엄격하게 보장하고자 하는 Rust의 기본적인 멘탈모델을 알게 해준 느낌.
어려운 내용을 쉬운 예제로 정해진 시간안에 구성해서 깔끔하게 세션 진행하시는 모습이 대단하다고 느낌. -> 나도 내가 아는 기술을 그 기술을 모르는 누군가에게 이렇게 잘 설명할 수 있을까?하는 생각.

데브콘 다녀와서 3번째 세션 발표자 김영재님의 인프콘 영상 성장하지 않아도 괜찮습니다도 이어서 찾아보게 됐는데, 참 아이덴티티가 뚜렷하신 분이라고 생각이 들었습니다. 저도 항상 성장, 성장, 성장..을 외치는 개발자들의 스탠스가 참 어색하게 느껴지기도 했었고 한국형 성장주의라고 생각했었거든요. 시간이 한참 지난뒤에 '지나고보니 성장해있더라..' 가 더 자연스러운거 아닌가 하는 말씀에 동감했습니다. 이 포스트를 마치면 re:COMMIT 시야가 넓은 개발자는 무엇이 다를까도 들어봐야겠네요.

성장하지 않아도 괜찮습니다 키워드

긴 호흡으로 지치지 않고 지금 하는 걸 더 많이 하는게 중요하다. -> 하다보면 그게 나의 아이덴티티가 된다.
언젠가 어느분이 sns에 언급하셨던 말이 인상깊어서 일할 때마다 되뇌이는 말이 있습니다. "지칠 때까지 일하지 말고, 언제 어떻게 지칠지 선택해서 일하자" 정확히 이 워딩이었는지는 기억나지 않지만 실제로 정말 도움이 되었습니다. 제 이력서 상단에 제가 개발자로서 추구하는 가치로 적어둘 정도로 업무에 치이고 힘들 때 중심을 잡고 일할 수 있게 해줍니다. 아래는 이력서 인용..

"지칠 때까지 일하기보다는 언제 지칠지 선택해서 일하는 주체적인 엔지니어링을 추구합니다. 사용자의 니즈와 엔지니어가 문제해결에 접근하는 방식 사이의 간극을 메꾸는 데에 관심이 많습니다. 정말로 필요한 것이 무엇이고 어떤 문제를 해결하고 있는지 동료들과 토론하는 시간을 즐깁니다."

제 아이덴티티는 뭘까요? 지난 6개월간 개인 주간회고에서 가장 많이 쓴 말이 "내 색깔은 뭘까"였는데 어쩌면 고민하는 시간이 많고 "계속 하는 시간"이 아직 부족해서 드는 생각일 수도 있겠습니다. 내가 나를 설명하지 않아도 나를 [ ____]로 찾아주는 것. 멋진 일인 듯 합니다.
디자인, 기획, 개발 모두 엔지니어링이 가능하다.
"반복되는 질문에는 악마가 숨어있다" 회사에서 일을 하다보면 반복적이고 성가진 일들 때문에 정작 중요한 일을 못할 때가 많다는 생각을 자주 하게 됩니다. 일을 할 수록 재생산 비용을 낮춰야 한다는 말에 너무 동감합니다. 루틴의 자동화, 지식의 일반화.. 이런 것들로 엔지니어링 관점에서 일을 할 수 있도록 해야합니다. 회사에서 제가 했거나 앞으로 할 수 있는 엔지니어링은 무엇이 있는지 고민해봐야겠습니다.
글을 쓰는게 왜 엔지니어링인가
업무 일지, 회고 문서, 디자인/설계문서, readme나 wiki 쓰는 일은 코딩하는 것 외의 서브 태스크로 여겨집니다. 하지만 일을 하다보면 실제 코드 작성만으로는 절대 업무가 부드럽게 진행되지 않는다는 걸 알게 됩니다. 실제로 회사에서 저는 히스토리 로깅, 정책 결정사항, 패키지 관리, 배포나 이슈대응 가이드 같은게 문서화되어있지 않았을 때 생산성이 확연히 떨어지는걸 경험했습니다. 결국 회사에서는 컴퓨터 앞에 앉아 로직만 짜는게 아니라 협업을 해야합니다. 내가 했던 일, 다른 팀에서 했던 일들을 글로 잘 정리해두면 모두가 더 넓은 시야를 가지고 프로덕트를 만들어갈 수 있습니다. 플러스 글을 쓰다보면 자연스럽게 모두가 알아볼 수 있게 작성하기 위해 노력하게 되므로, 스스로 문제 정의, 해결과정을 정리할 수 있고 팀내 지식의 일반화와 전파에도 도움이 됐던 것 같습니다.