우리가 굳이 엔지니어의 고민까지 기록하는 이유

안녕하세요. 채널 Developer Relations 소마입니다.

여러분은 기술적인 결정을 내릴 때 어떤 고민을 하시나요? 보통은 여러 방법을 비교해 보고, 동료와 의견을 나눈 뒤에 결정을 내립니다. 그런데 시간이 지나면 결과만 남고, 기록해 두지 않으면 왜 그런 선택을 했는지는 점점 희미해지곤 합니다.

채널에 합류하고 한 달쯤 지났을 때, 여러 엔지니어와 이야기를 나눴습니다. 왜 이 기술을 골랐는지, 문제를 해결하면서 어떤 시행착오를 겪었는지, 동료와 의견을 주고받으며 어떻게 결정했는지 등 모두 결과만 봐서는 알 수 없는 것들이었습니다.

채널 DevRel팀은 엔지니어들이 쌓아 온 경험을 모으고, 이를 외부에 전하고 있는데요. 저도 채널 엔지니어링 팀의 이야기를 소개하면서 무엇을 어떻게 전해야 할지 자주 고민하게 되었습니다.

기술적인 성과나 문제 해결 과정뿐 아니라, 그 과정에서 엔지니어가 했던 고민과 선택까지 함께 전할 수 있다면 어떨까요?

DEV POSTING은 이런 생각에서 시작했습니다. 이번 글에서는 DEV POSTING이 어떤 활동인지, 어떤 이야기를 담고 있는지, 그리고 왜 굳이 고민까지 기록하려고 하는지 소개해 보려 합니다.

DEV POSTING은 어떤 활동인가요?

DEV POSTING은 채널 엔지니어링 팀의 엔지니어들이 자신의 경험과 생각을 글로 정리해 공유하는 활동입니다. 매주 두 명의 엔지니어가 작성한 글을 링크드인에 공개하고 있어요.

다루는 주제는 정해져 있지 않습니다. 기술적인 경험이나 문제 해결 과정부터 의사결정의 배경, 시행착오, 협업과 팀 운영에 관한 고민까지 다양합니다.

그런데 이미 기술블로그도 있고, Dev Session도 진행하고 있는데 왜 별도의 활동을 시작했을까요?

기술블로그나 Dev Session과는 무엇이 다를까요?

채널 엔지니어링 팀은 기술블로그와 Dev Session을 통해서도 기술과 경험을 공유하고 있습니다. 기술적인 내용을 깊이 있게 다루거나 구현 과정과 결과를 소개하기에 좋은 형식이죠.

하지만 일하면서 마주하는 모든 고민이 기술블로그 글이나 발표로 이어지는 것은 아닙니다.

작은 개선을 하면서 얻은 배움도 있고, 아직 명확한 답을 찾지 못한 문제도 있습니다. 다른 팀과 협업하면서 발견한 문제나 예상과 다른 결과를 통해 알게 된 점도 있죠. 이런 경험도 기록할 가치가 있지만, 처음부터 완성도 높은 콘텐츠를 만들려고 하면 어디서부터 시작해야 할지 막막할 수 있습니다.

DEV POSTING은 이런 부담을 조금 덜어내기 위해 시작했습니다. 정해진 주제나 형식에 맞추기보다, 각자가 실제로 경험한 문제와 생각을 자신의 언어로 정리해 보는 거예요.

링크드인을 선택한 이유도 있습니다. 팀 안에서 경험을 나누는 데 그치지 않고, 외부 엔지니어들도 우리의 이야기를 읽고 자신의 경험과 연결해 볼 수 있기 때문입니다.

우리가 기록하고 싶은 것은 '무엇을 했는가'에서 끝나지 않습니다

그렇다면 DEV POSTING에는 어떤 이야기가 어울릴까요?

새로운 기술을 도입한 경험을 기록한다고 생각해 봅시다. 어떤 기술을 선택했고 어떻게 구현했는지 설명하는 것만으로도 좋은 글이 될 수 있습니다. 여기에 몇 가지 질문을 더해 보면 이야기가 조금 달라집니다.

• 기존 방식에는 어떤 문제가 있었을까요?

• 다른 선택지는 무엇이었고, 왜 선택하지 않았을까요?

• 당시 가장 중요하게 고려한 기준은 무엇이었을까요?

• 지금 다시 같은 문제를 만난다면 어떤 선택을 할까요?

이런 질문을 따라가다 보면 기술을 소개하는 데서 그치지 않고, 문제를 어떻게 바라봤고 어떤 판단을 거쳐 해결했는지까지 이야기할 수 있습니다.

우리가 기록하고 싶은 것도 바로 이런 과정입니다. 무엇을 만들었는지뿐 아니라 왜 그렇게 만들었는지, 어떤 문제를 해결했는지뿐 아니라 문제를 어떻게 정의했는지까지 함께 남기는 것이죠.

모든 글에 거창한 의사결정이나 시행착오가 필요한 것은 아닙니다

작은 개선 하나가 좋은 기록이 될 수도 있고, 예상한 결과를 얻지 못한 경험이 다른 엔지니어에게 유용한 참고가 될 수도 있습니다. 중요한 것은 경험의 규모보다 그 과정에서 무엇을 발견했는지입니다.

실제 DEV POSTING에도 이런 고민이 담겨 있습니다.

1/ 기술적 문제를 바라보는 관점과 해결 과정

디자인 시스템에서 AI가 반복해서 실수하는 이유를 찾다 - 티모

AI가 반복해서 실수하는 원인을 살펴보며 기존 디자인 시스템의 구조를 재검토한 경험입니다. 눈앞의 문제를 해결하는 데서 그치지 않고, 원인을 다시 살펴보고 설계를 개선해 나가는 과정을 공유합니다.

2/ 실제 업무의 불편함을 개선한 경험

추상화를 문서와 사람이 하고 있었습니다 - 탄토

사람과 문서에 의존하던 배포 과정을 시스템으로 옮겨 반복 작업을 개선한 경험입니다. 기존 업무 방식의 한계를 발견하고, 자동화와 표준화를 통해 더 나은 방식으로 바꿔 나간 과정을 보여줍니다.

3/ 팀의 일하는 방식에 대한 고민

팀장 업무의 위임도 분할 정복이다 - 페퍼

팀장의 업무를 어떻게 나누고 위임할 수 있을지에 대한 경험과 생각을 공유합니다. 기술적인 문제뿐 아니라 협업과 팀 운영에서 마주하는 고민도 기록할 수 있다는 점을 보여줍니다.

물론 이 세 편이 DEV POSTING의 전부는 아닙니다. 기술과 시스템 설계, AI와 모델, 제품과 비즈니스, 협업과 팀 운영 등 다양한 주제의 글이 꾸준히 쌓이고 있습니다.

주제와 문제는 서로 다르지만, 실제 업무에서 마주한 문제를 출발점으로 삼고 그 과정에서 얻은 생각을 나눈다는 공통점이 있습니다.

기록은 작성자에게만 도움이 될까요?

글을 쓰면 자신의 생각을 정리할 수 있습니다. 하지만 기록의 의미가 글을 쓴 사람에게만 있는 것은 아닙니다.

같은 팀에서 일하더라도 서로의 업무를 모두 알기는 어렵습니다. 다른 도메인에서는 어떤 문제가 생기는지, 동료가 어떤 기준으로 기술적 결정을 내리는지 매번 깊이 있게 이야기하기는 쉽지 않죠.

글은 이런 간극을 좁혀 줍니다. 평소 대화에서는 접하기 어려웠던 동료의 고민을 알게 되고, 내가 익숙하지 않은 영역의 문제도 이해할 수 있습니다. 같은 상황에서도 서로 다른 판단이 나올 수 있다는 사실을 발견하기도 하죠.

서로 다른 판단에는 각자의 맥락과 제약 조건이 있는데요. 동료가 어떤 이유로 그런 결정을 내렸는지 이해하면 함께 일할 때 더 나은 질문을 하고 구체적으로 의견을 나누는 데도 도움이 됩니다.

또 내가 직접 경험하지 않은 문제라도 동료의 기록을 통해 미리 살펴볼 수 있습니다. 나와 다른 관점에서 문제를 해결하는 방법을 배우기도 하고요. 이렇게 서로의 경험을 나누다 보면 함께 배울 수 있는 범위도 넓어집니다.

그래서 지금까지 얼마나 쌓였을까요?

현재까지 공개된 DEV POSTING은 총 21편입니다. 그동안 다룬 주제도 다양합니다.

• 기술과 시스템 설계: 문자 전송 플랫폼 재설계, 디자인 시스템 개편, 데이터베이스에서 데이터 플랫폼으로의 확장

• AI와 모델: 상담 AI의 토큰 비용 최적화, 직접 모델을 학습할 필요가 있는지에 대한 고민, 보이스 에이전트의 품질

• 제품과 비즈니스: 좋은 기능을 만드는 것을 넘어 좋은 비즈니스를 고민하는 관점, 데이터 분석 제품의 개발 경험

• 개발 환경과 협업: 사내 개발자 플랫폼, 엔지니어의 역할, 팀장의 업무 위임

글이 늘어나는 것만큼 눈여겨보고 싶은 것은 기록의 폭인데요.

제품을 만들고 운영하면서 생긴 문제부터 팀 안에서 더 나은 방식으로 일하기 위한 고민까지, 엔지니어들이 실제 업무에서 마주하는 다양한 경험이 담겨 있습니다.

이런 기록은 외부 엔지니어에게도 채널 엔지니어링 팀을 이해하는 단서가 됩니다. 기술 스택이나 완성된 제품만으로는 팀이 실제로 어떻게 일하는지 모두 알기 어렵습니다. 어떤 문제를 중요하게 생각하는지, 선택의 순간에 무엇을 고려하는지, 시행착오에서 무엇을 배우는지까지 살펴보면 일하는 방식이 조금 더 구체적으로 드러납니다.

기록이 쌓이면 문화가 될 수 있을까요?

좋은 개발 문화는 제도 하나로 만들어지지 않습니다. 기록도 마찬가지예요. 글을 꾸준히 발행하는 것만으로는 충분하지 않습니다. 동료들이 서로의 글을 읽고, 경험을 이해하고, 실제 업무에서 생각을 나눌 때 비로소 의미가 생깁니다.

그래서 DEV POSTING에서 중요하게 생각하는 건 발행 편수만이 아닙니다. 글이 동료의 경험을 이해하는 데 도움이 되고, 서로의 생각을 나누는 계기가 되는 것도 중요합니다.

궁극적으로는 이러한 캠페인이 없어도 자신의 경험을 돌아보고, 필요할 때 자연스럽게 기록하고 공유하는 문화를 만들고 싶습니다! 😌

지금까지 공개된 21편의 글은 그 문화를 만들어가는 과정에 있습니다. 채널 엔지니어링 팀이 어떤 문제를 고민하고, 어떤 기준으로 결정하며, 어떻게 일하는지 보여주는 기록이 하나씩 쌓이고 있습니다.

앞으로도 완성된 결과뿐 아니라 그 결과에 이르기까지의 고민을 함께 나누며 기록을 이어가려 합니다!

채널 엔지니어링 팀은 오늘도 문제를 해결하고, 그 과정에서 배운 것을 기록합니다.

지금까지의 그리고 앞으로의 DEV POSTING은 링크드인에서 만나보실 수 있습니다.