반가운 댓글이 만든 작은 파문을 차려서 행동하기
한국의 켄트 벡이 되기
<Tidy First?> 번역이 바꿔 놓는 삶의 궤적 중의 하나로 베터코드에서 커뮤니티를 운영하기로 했습니다. 역자는 개인 입장이고, 회사 운영에 경제적 이익을 주지는 못합니다. 그럼에도 불구하고 회사의 정체성을 드러내기에 좋은 일이고, 저희가 만드는 제품의 테스트 베드 역할도 해 줄 수 있다고 판단해서 진행하기로 했습니다.
반가운 댓글이 만든 작은 파문
지난 글은 스스로 트리거를 만들고 싶은 '선언'에 초점을 둔 것이지만, 변화를 만드는 힘은 내 통제 밖의 일들에 더 많이 좌우되는 듯합니다. 얽히고설킨 다양한 요인들에 의해 무언가 선택을 해야 하는 순간 그런 점들을 깨달을 수 있습니다.
매주 진행하는 회의에서 동료가 커뮤니티에 댓글이 달렸다는 말을 합니다. 고마운 마음이 들었습니다.
최근에 <SI 초보자를 위한 Q&A 모임>에 초대해 주셔서 교류와 공감이 있어서 그런지 댓글이 소소한 응원처럼 느껴졌습니다. 이렇게 감상을 하고 있자니 동료가 이어서 말했습니다.
댓글 쓴 사람들이 소셜 로그인을 하니
메일 서버를 이용해서 알림을 줄 수 있습니다.
뒤늦은 알아차림 활용하기
이틀이 지나서 생각해 보니, 동료는 개발자니까 당연한 반응이었습니다. 개발자는 자신이 만든 기능의 부족함을 채우려고 합니다. 어떤 면에서는 그 프로그램이 자식 같은 존재니까요. 반면에 저는 커뮤니티 기능이 회사의 일인지에 대한 기준이 없었습니다. 제 무의식이 대화를 하고 있었다면, '지금 그게 필요한가?'라고 묻고 답을 못한 상태라고 해야겠죠.
시간이 지나고 한발 떨어져서 그 일을 생각할 수 있게 되었습니다. 공교롭게 아침에 '알아차림'에 대한 글을 보았는데, 회의 당시에는 머리와 마음을 가득 매운 생각으로 알아차리지 못했던 듯합니다. 이제 다시 기회가 왔습니다.
방금 전까지 스스로 만든 틀에 박혀 일을 처리하다가 갑자기 정신을 차린 느낌도 받습니다. 더불어 생각을 잘 차리기 위해 파문(波紋)의 풀이도 찾아봅니다.
「3」 어떤 일이 다른 데에 미치는 영향.
물결 파(波)와 무늬 문(紋)이 함께 하는 글자입니다. 그렇게 파문처럼 만들어진 생각을 시각화해 보았습니다.
그리는 가운데 생각도 정리하고 가치와 시급성 순서로 우선순위도 부여했습니다. 반가움을 갚는 것이 먼저입니다. 통화를 하신 대신에 이 글을 쓰고 페북 멘션을 하는 방식도 나쁘지 않을 듯합니다.
PI(Program Increment) 결정하기
두 번째는 이왕 커뮤니티를 만들었으니 다른 기능에 앞서 사용자의 소통을 장려하는 기능을 만들 필요가 있을 듯합니다. 개발자인 동료도 뿌듯해하겠네요. 회사 일의 범위로 이번 주에 개발해도 좋은 분량을 제한할 수 있습니다.
다른 시각에서 보니 이 기능은 저의 오랜 숙원이기도 한 추적 문제를 동료들과 함께 맛보는 데에도 적절한 사이즈로 보입니다. 그래야겠네요.
새로 보게 된 사실로 그린 정보
마지막으로 개인적 편향과 선호가 가장 많이 개입되어 있은 프로그래밍 모델에 관한 일이 있습니다. 원래 마음속에 있던 내용을 새로운 배움이 덮어씁니다. 그래서 그걸 그려 봅니다.
흥미롭습니다. 작년 초까지만 해도 아주 추상적인 방식으로만 설명할 수 있었던 '디지털 코어'를 예를 들어 설명할 수 있게 되었습니다. 개발자는 자기가 만든 코드의 모양을 통해 제가 전하려는 추상적 개념을 체감할 수 있게 되었습니다.
더불어 시스템 사이의 통합(Integration)으로 만들어지는 구간의 Realization 전략으로 택한 이름은 '클라우드 네이티브'는 역시 작년 초에 자료를 찾아보며 정리한 개념의 실체적 모양이 될 듯합니다.
Cloud Native 승자는 집적이 가능한 개발 조직
세 번째로 UX에 대한 글은 올해는 실무적으로 다룰 일이 있어서 다른 글에서 자세히 쓰기로 합니다.
CRUD 중심 사고에서 이벤트 중심 사고로...
마지막으로 애초에 갖고 있었던 프로그래밍 욕구에 대해서도 꺼내어 풀어봅니다. 요즘IT에 작년 11월에 쓴 글에 대한 댓글 알람이 없어서 세 달 후에 댓글을 알았던 일이 있습니다.
처음 회의에서 동료에게 댓글에 대해 들었을 때, 이 일이 생각나면서 우리가 만든 제품에도 똑같은 일이 발생하는구나 싶었습니다. 그리고, 이것이 게시판 구현하던 때의 생각하는 방식 혹은 CRUD 중심의 구현 방식이 갖는 약점으로 비쳤습니다.
그래서, <이벤트는 변경을 알리는 표준 프로그래밍 단위>를 프로그래머들에게 알리기 좋은 주제구나 싶었습니다. 그런데, 다시 차려 보니 회사 일과 개인적으로 글을 쓰는 일을 따로따로 하는 대신에 함께 시너지가 날 수 있도록 잘 차려나갈 방법을 깨닫게 되었습니다.
