내가 개발 회고록을 쓰는 법

사람은 서사를 좋아한다. 인간이 그린 그림과 AI 가 그린 그림이 있을 때, 요새는 AI 도 워낙 그림을 잘 그리기 때문에 사실 그림 자체만 놓고 보았을 때는 긴가민가 할 수 있지만, 그림에 서사가 부여되는 순간 사람들은 인간이 그린 그림을 선호하게 된다. 그 그림을 그리게 된 계기나 비하인드 스토리, 기분, 의도, 시대적 배경과 같은 서사가 있는 작품을 사람들은 좋아하고 즐거워한다. 반면 AI 가 그린 그림에는 화풍을 따라 하거나 모방할 뿐 스토리가 없어서 예술이 가져다주는 감동을 얻을 수 없다. 예술은 작품 그 자체뿐만 아니라 작품에 담긴 서사또한 포함하는 것이 진짜 예술이라고 생각한다. 아이가 그린 그림을 볼 때 감동을 얻는 이유는 그림을 잘 그렸기 때문이 아니라 아이가 가진 순수함과 의도, 화풍과 같은 표현하고자 하는 방식에서 나오는 느낌 때문이다.

 

다만 코드는 문학이나 그림과는 다르게 개발자가 아니라면 코드 그 자체에서 느껴지는 감동이 없기도 하고, 프로그램의 내부에 가려져 있기 때문에 인간과 AI, 누가 코드를 작성했던지 간에 제대로 동작만 한다면 대중들은 딱히 관심이 없는 것도 사실이다. 이 때문에 혹자는 '코딩을 예술적으로 하려 들지 마라'와 같은 말도 하곤 하지만, 그럼에도 불구하고 내게 코딩은 이야기를 가진 하나의 예술과도 같다. 문제를 인식하고, 타당한 기술을 선정하고, 문제를 해결하기 위한 가설을 제시하고, 코드로 구현하고, 테스트를 통해 검증하고 운영하는 그 과정에는 많은 이야기가 담겨있다. 물론 프로그램 자체는 문학적으로 감동을 주거나 울림을 주지는 못하지만, 기획자, 디자이너, 개발자의 경험과 노하우, 고민이 담겨있는 결정체인 만큼, 프로그램에서는 드러낼 수 없는 그 이면의 이야기를 개인 블로그뿐만 아니라 노션이나 토스 기술 블로그, Naver D2처럼 사내 기술 블로그와 같은 기록으로 남겨둔다면, 내가 개발자로서 문제를 해결하기 위해 선택한 접근 방식을 보여줄 수도 있고, 설령 실패한 프로젝트라 하더라도 과거의 실수를 되풀이하지 않기 위해 후배 개발자와 팀의 교육용 자료로도 사용될 수 있다.

 

회고를 작성하는 템플릿은 KPT, 5F, 4L 등이 있지만, 나의 개발 회고록은 작성 주기가 길기도 하고 대체로 프로젝트를 마친 이후에 작성하기 때문에 소프트웨어나 기능을 개발하기에 앞서 발생한 문제나 고민, 계기, 목적부터 출발하여 요구 사항, 기대 효과, 기술 선정 사유, 가설을 세우고 구현하는 것에 대한 시행착오, 목적 또는 기대 효과에 부합했는가에 대한 평가와 기준 및 방법, 느낀 점, 미래에 개선했으면 하는 사항과 같은 내용을 포함하고 있다. 그림조차 쓰지 않은, 그저 내 스타일대로 쓴 형식화되지 않은 에세이긴 하지만, 티스토리 스킨 프레임워크 개발기에서 그 사례를 보여주고 있다. 사내에서 쓰는 개발 회고록이라면 요구사항, 기대 효과 등의 회고에 포함되어야 할 구성요소들을 템플릿으로 만들고 체계성을 부여할 수 있다. 에세이 형식은 내가 개인의 회고를 작성하는 방식으로 좋아하는 것일 뿐이다.

 

소프트웨어는 비즈니스 상의 문제를 해결하기 위해 만들든, 그저 재미를 위해 만들든 계기나 목적이 있기 마련이다. 단순히 외부에서 요청했더라도 그들이 왜, 무엇을 위해 해당 기능이나 소프트웨어를 만들고자 하는지 이유를 알지 못하면 그들이 원하는 결과물을 빠르게 내기 어렵고, 요구사항을 충족하기 위한 시행착오를 많이 겪어야 하므로 그들의 의중을 먼저 이해하고 정리하는 과정이 선제적으로 필요하다. 이러한 과정을 거친 결과로써 개발 회고록에는 계기나 개요, 목적, 기대효과와 같은 내용이 포함될 수 있고, 개발자뿐만 아니라 비개발자가 읽더라도 평가하거나 파악하기 좋을 뿐만 아니라 비즈니스 문서로 쓰이는 등의 대외적으로도 설득력을 얻을 수 있는 가능성이 높아진다.

 

소프트웨어 개발 또는 기능 추가 및 개선은 특정 목적이나 비즈니스 문제를 해결하기 위해 개발되기 때문에 기대 효과도 있기 마련이다. 이를테면 '사용자의 이탈률 감소 및 활성 사용시간을 늘린다'와 같은 목적과 기대 효과를 미리 명시할 수 있다. 우선적으로 기대 효과를 정리하는 이유는, 기술적인 내용과는 별개로 전체적으로 해당 프로젝트가 성공했는지 실패했는지에 대한 사후 평가를 하기에 좋기 때문이고, 또한 평가 방법과 기준까지 기재하여 설득력과 객관성을 더할 수 있기 때문이다. 간단한 사례로는 GA에 따른 기준이나 도달하고자 하는 퍼포먼스 지표 등의 전후평가를 기준으로 삼을 수 있다. 결과에 따라 기대하는 효과가 더 좋게 나왔거나 또는 못 미친다면 그냥 넘길 것이 아니라 그 이유를 고민하고 정리하는 것이 중요하고, 이를 통해 개인뿐만 아니라 팀차원에서도 차후 프로젝트에서 같은 실수나 문제를 가지고 고민하는 시간이 줄어들고 개선하고 학습함으로써 생산성이 증대될 수 있으며 더 나아가면 사내 전반적인 매뉴얼의 토대가 될 수도 있다.

 

기술 선정의 경우에는 사내에서 개발할 때는 이미 기술 스택이 정해져 있는 경우도 많지만, 만약 개인 프로젝트 이거나 실험적인 프로젝트, 또는 다른 기술 스택으로 바꾸려는 시도라면 기술 스택을 명시하고 해당 기술을 선정한 이유를 명확히 제시하는 편이다. 그 기술의 장단점, 이 프로젝트에 이 기술을 사용하는 것이 타당한 이유 같은 것을 명시하는 것은 해당 프로젝트에 대한 기술적 설득력을 부여하기 때문이다. 개발자들은 프로젝트의 특수한 조건이나 상황에 따라 적절하게 도구를 선택하여 사용할 수 있는 능력이 있는 만큼, 그 기술을 채택한 이유를 명시할 수 있다면 좋은 개발 회고록이 되는 것은 물론, 평가 결과를 토대로 기존에 레거시 기술을 사용하는 기업의 마이그레이션을 유도할 수도 있다.

 

다만, 도입하고자 하는 기술이 개발자 입장에서 매력적이고 좋더라도 '지금도 잘 동작하는데 굳이 왜 바꿔야 되는가?'와 같은 경영진의 의견과 상충하는 경우가 빈번하기 때문에 개발자의 입장에서 기술의 장단점만 나열하는 것만으로는 설득력을 얻기란 결코 쉽지 않다. 이는 그저 개발자의 욕심으로만 치부될 수도 있다. 따라서 기술의 장단점뿐만 아니라 해당 기술을 도입함으로써 얻을 수 있는 사업적 기대 효과도 명시하면 그나마 낫다. 개인적으로는 인력 수급, 개발 생산성 증대, 비용 절감과 같은 부분이나 이탈률 감소, 활성 시간, 사용자 증가, 사용자 경험 증대와 같이 회사가 추구하는 방향에 따라 시장 점유율 확대나 영업이익과 연결하는 것이 좋았다. 그저 레거시가 싫다는 식의 개발자의 단순 욕심에 의한 기술 선정 사유는 기술적으로나 사업적으로 보나 설득력을 얻기 어려울 것이다.

 

목적이나 기대 효과에 부합하기 위한 가설을 세우고 구현하고 검증하는 부분 또한 개발자가 많이 고민하는 부분이다. 코드 한 줄을 쓰더라도 그 의도가 있기 마련인데, 기대 효과에 도달하기 위해 시도한 기술적 도전들과 시행착오를 적어보자. 다만, 개인적으로 문제를 해결하기 위한 방식을 소개하고 독자의 이해를 돕기 위해 그림이나 다이어그램을 사용할 수 있지만, 꼭 필요한 경우가 아니라면 구체적인 코드를 직접 언급하는 것은 자제하는 편이다. 개발 회고록은 개발자들만을 위한 문서는 아니기 때문이다. 개인 블로그에서는 연구, 알고리즘, 수식, 코드를 통해 문제를 접근하는 방식 등의 기술적 내용뿐만 아니라 개인적으로 문제를 해결하면서 느낀 깨달음이나 미래에 개선해야 할 사항 등을 포함으로써 반성과 성찰의 시간을 가지는 것을 선호한다.

 

개발 회고록은 기대 효과를 달성하기 위한 기술적 여정의 기록이다. 한 가지 재미있는 것은 미래의 관점에서 볼 때 지금의 개발 회고록에는 시대적 상황도 반영된다는 점이다. 당대의 기술만으로 요구 사항에 부합하기 위해 시도했던 방법들과 마주한 한계, 그리고 이를 뛰어넘기 위한 시도와 단순한 아이디어에서 탄생한 돌파구의 탄생과 같은 이야기들은 마치 역사책이기도 하고 성장을 주제로 하는 소설을 읽는 듯한 느낌을 주기도 한다. 개발 회고록은 소프트웨어를 개발하기 위해 걸어온 궤적을 다시 되짚어보는 일이니만큼, 과거에서 얻은 배움을 적용하고 더 나은 미래를 만들어나갈 수 있을 것이라 믿는다.