회고로 탄생한 우리 팀만의 언어

회고의 필요성
회고는 언어를 만든다
회고로 탄생한 우리 팀만의 언어
개발자의 자아를 버려라
테스트 디비는 더러워야 한다.
그래서 그게 지금 당장 필요한 거 맞아요?
잘 팔 수 있나? 더 잘 팔 수 있나?
마무리

회고의 필요성

팀 내부적으로 회고를 진행했다.

회고는 우리를 더 빠르게 한다.

회고는 팀 전체적인 방향을 확인하는 피드백이다.

김창준, 『함께 자라기 애자일로 가는 길』, 인사이트, 2018

에서는 "개인"의 성장과 관련해서 "피드백을 제때 받지 못하는 문제가

개인의 성장을 더디게 한다는 내용이 나온다.

양치질을 예로 들어, 일 년 이를 잘못 닦다가 치과에 가서는 의사에게 한소리 듣는 정도로 느린 피드백을 받으면,

이미 이는 썩어버린다. 그리고 그 피드백을 한 번 받는다고 해서 매번 이를 닦는 적절한 시기에 피드백이 없으면 같은 실수를 반복하고 만다.

팀적으로도 피드백은 마찬가지의 효과를 가진다.

적절한 시기에 피드백을 함으로써 더 뽀족한 방향을 볼 수 있다.

액션과 피드백 사이의 간격이 짧을수록 그 액션을 다듬을 수 있다.

그렇기 때문에 패드백은 액션 후 빠르게 진행하는 것이 좋다.

회고는 언어를 만든다

팀 내부적으로 회고를 하면서

우리의 액션들을 피드백하면서

좋았던 점은 우리만의 언어가 생긴다는 점이다.

언어는 곧 문화다.

언어가 곧 문화인 이유는

짧은 국어국문학적 전공지식으로 설명할 수 있다.

언어는 현상을 정의하는 활동이다.

현상이 있으면, 현상들을 군집화하고, 반복적으로 일어나는 현상을 하나의 언어로 정의할 수 있다.

집단 내에서 반복적으로 일어나는 현상은 문화고,

이러한 것들을 언어로 꼬집어 말할 수 있으면,

문화를 문화로써만 가지고 있는 것이 아니라,

팀 내부적으로 인지할 수 있다.

그리고, 내부적으로 인지하고 있는 문화를

계속해서 팀 내부적인 언어로써 언급해준다면,

그 문화를 더 강화시킬 수 있다.

회고로 탄생한 우리 팀만의 언어

이번에 회고하면서 생겨난 우리 팀만의 언어를 소개하려고 한다.

대게 아쉬운 부분들을 개선하려고 나왔던 언어들이었고, 그 언어들이 어떤 현상을 지적하고,

그 현상들을 어떻게 표현하고 있는지 이야기해보려고 한다.

개발자의 자아를 버려라

우리팀은 모두가 개발자의 자아를 가지고 있다.

모두가 개발자(해커)인 집단의 팀에서 필요한 것은 개발자의 자아를 버리는 일이다.

빠른 출시를 위해 제품을 만들다보면, 아래와 같은 현상이 생긴다.

“개발 도중”:

이 코드가 이렇게 바뀌면 한번만 실행해도 되잖아. 바꿔야겠다. (Development experience 개선)
이렇게 바꾸면 UX적으로 좋을 것 같은데?

간단하게 몇 십분만으로 끝날 것 같던, 1,2번의 일들이 실제로는 하루 업무의 주된 테스크가 되기도 한다.

근데, 이런 것들이 굉장히 중요한가? 현재 팀의 주된 목표를 해소하는데, 이것들이 중요한가?

중요하지 않았다. 팀은 현재 완성을 목표로 달려가고 있는 중이고,

이런 와중에 개발적 디테일이나, 코드의 퀄리티는 중요하지 않았다.

물론 현재 팀의 원띵이 리펙토링으로 개발 경험(DX)을 개선하는 것이라면 당연히 해야 할일이지만,

지금 현재 우리팀의 목표는 그것이 아니었다.

그렇다면, 이런 것들은 지금 당장 필요한 것들이 아니었고, 후순위로 미뤄도 되는 것들이었다.

이러한 문제점들에 대해서 이야기하다보니,

이런 현상을 우리는 “개발자의 자아”라고 정의했다.

개발에서는 좋은 코드는 무조건 "참"이다. 효율적이고, 반복을 덜 하는 코드는 무조건 "참"이고, 반대인 코드는 무조건 "거짓"이다.

하지만, 개발자들이 모인 팀에서 팀의 원띵과 목표를 향해서 간다면, “좋은 코드(clean code)”는 현재 시점에서 "거짓"일 수도 있다.

이런 것들을 항상 인식하자는 생각에서

“개발자의 자아를 버려라”

라는 말이 등장했다.

테스트 디비는 더러워야 한다.

현재 우리는 프롬프트를 활용한 제품을 만들고 있다. 프롬프트를 고도화하여 chat bot의 성능을 높이려면 무엇을 해야 할까? 실험과 테스트다. chat gpt에게 system 프롬프트 입력하고, 써보고 결과를 보고 개선하고, 이를 반복해야 한다.

결국 고객이 만족할만한 경험을 주는 것이 이번 목표였는데, 웹/앱 개발에만 초점을 맞추고 있었다. 수시로 테스트하고 이것이 우리가 의도한 대로 대답하는지를 테스트해야 했다. 하지만, 그러지 못했다.

테스트 디비가 너무 깨끗했다.

테스트 디비가 너무 깨끗하면, 테스트 디비를 파놓은 이유가 없지 않은가? 개발자의 자아가 나와서 무조건 테스트 디비는 필요한 거야 라고 해서 만든게 아닌 이상, 우리는 테스트 디비로 최대한 많은 실험을 해야 했다.

이런 문제 현상을 꼬집고자, 테스트 디비는 더러워야 한다는 문장이 등장했다.

그래서 그게 지금 당장 필요한 거 맞아요?

우선 순위를 계속해서 생각하자는 의미로 우리는 끝임없이 이 문장을 묻기로 했다.

잘 팔 수 있나? 더 잘 팔 수 있나?

우리의 원띵을 계속 되내이기 위해서 탄생한 문장이다.

마무리

회고는 우리를 더 빠르게 한다. 비효율적으로, 감정적으로 손해를 보고 있었던 현상을 꼬집어낸다.

현상의 문제점을 계속해서 짚어내면서 비효율을 개선할 수 있다.

동시에 액션들을 되돌아보면서 문화를 캐치해내고 그것을 언어로 정의할 수 있다.

회고를 통해서 달라질 액션들을 기대한다.