Google app script 로 자동화 만들어보자 - (00)
Prologue
정말 놀라운 한 해의 연속. 여러 개인적인 일들이 터지고, 이를 수습하고, 정말 정신없이 올 초, 봄이 다 지나갔다. 공통과정 과제를 깨는 것도 일인데, 그와 함께 찾아오는 여러 개인적인 일들을 수습하다보니 peer 커뮤니티를 위해 무언가 한다는 것이 불가능했다. 그럼에도 다행이, 일들은 정신없이 지나감에도 어떻게든 대응을 할 수 있었다. 과제에 집중을 하면서 여러 경험들을 했고, 몸도 마음도 다져지는 기분이 드는 것은 기분탓이 아니었다.
그렇게 정신 차리니 4월이 되어 있었고, 어느 정도 일이 끝나자 내 앞에는 기존에 하던 일들에 대한 책임, 이제는 진짜로 이룰 수 있으리라- 라는 내 나름의 자신감이 생기게 되었었다.
그리하여 기존에 해야할 일들을 떠올려 보니 다음과 같은 일들이 었다.- 기존에 피어 참여자들의 리워드 자동계산을 구현했었는데, 이를 개선하고자 했다.
- 피어를 위한 웹 서비스 구축을 진행해본다.
- 42서울의 개발 판도나, 개발에 대한 환경 자체를 좀 바꿀만한 플랫폼을 만들고 싶다.
1번의 경우 단순히 구글 스프레드 시트와 기존에 만들어진 도구들을 활용한 전형적인 짜집기 형태로 구축을 했었다. 하지만 여기엔 여러 문제가 있었다. 데이터 크롤링이 유료 서비스인지라, 무료 수준으로는 한계가 많았다.
뿐만 아니라 복잡한 수식을 단순히 가져온 데이터를 스프레드 시트로 옮기고, 그걸 계산해내는 것은 쉬운 것이 아니며, 무엇보다 조금만 틀어지면 에러가 발생했다. 실제로 그렇기에 사용을 잘 해야할 운영 담당자들은 아날로그식으로 계산하는 것을 보았을땐(…) 한숨이 절로 나왔었다. 고쳐달라는 말도 하지도 않고, 그렇게 쓰고있다니…
여튼 그리고 피어 웹 서비스는 어쩌면 내가 할 수 있는 가장 좋은 기회를 나타내는 경우일 것이다. 3번… 이 문제이긴 한데. 정말 하고 싶던 것은 바로 3번이지만, 현실적으로 시간이 허락해주지 않는 다는 것을 깨달았다.
그리하여 피어 운영진 복귀 이후 일을 벌렸다. Google app script 를 활용한 자동화 경험. 충분히 경험적으로나 토이 프로젝트로 충분히 가치 있다고 판단된다.
egile & scrum
여하튼 결론적으로 프로젝트 진행을 하려고 한다. 우선 가장 중요한 1번의 깔끔한 성공을 기준으로하여, 2번을 해보고자 한다. 추가로 ft_transcendance 과제는 TDD 방식을 녹여서 진행할 것으로 보이는데, 그래도 애자일과 TDD, 두 방식을 해본다는 것은 생각보다 경험적으로 좋아 보인다.
그렇다면 왜 애자일(스크럼)인가
피어 내부에서 하는 활동들, 특히 토이 프로젝트에 가까운 이러한 내용들은 개발할 기능이 많지는 않다. 그럼에도 관리와 운영이 포인트라는 것을 느꼈다. 이유는 간단하다. 피어는 커뮤니티이고, 개발자적 마인드로 무언가를 해결하는 방식으로는 반짝 빛날 수는 있어도 은은하게 유지되어 확장되어가는 형태로는 되기 어렵다. 거기다 주요한 활동들이 아니고선 많은 에너질 쏟을 수는 없다.
그 와중에 개발 방법론에 대한 내 안의 물음증이 나타났고, 그 결과 애자일이라는 것을 발견하게 된 것이다.
애자일은 기본적으로 짧고 간결하다. 계획에서 설계, 개발과 마지막 테스트 및 검토까지 그 사이클에서 흘러내리는 핵심적 가치는, ‘사람은 완벽하지 않다’라는 점이며, ‘일을 해결하고 개선하는 것이 중요하다’ 라는 포인트이다. 제한적인 날짜를 지정하고, 그 한정된 시간에서 가능한한 분석을 마치면, 그 수준에서 할 수 있는 최선의 개발을 진행한다. 개발에서도 팀을 중시해서, 완성이 필요하며 독보적 누군가의 능력치를 요하진 않는다.
가장 중요한 것은 역시나 마지막 피드백의 순간이다. 당연히 제한된 시간 내에 개발이 되었었고, 그 말은 개선의 여지는 당연히 있다는 것이다. 그러니 시간과 상황이 허락할때 2회차, 3회차를 진행하면서 점점 그 기능과 수준을 끌어 올린다.
이러한 형태는 현재의 피어에게 최적이라는 생각을 했다. 운영도 필요하고, 나아가 계속 발전을 해야 한다. 다른 팀들을 보니 프로젝트 진행을 하고 2기 개발자를 선발 시, 2기도 개발하러 왔지 운영을 하러 오지 않았다는, 그래서 다시 갈아엎는다는 굉장한 비효율과 더불어, 결국 그렇게 진행하면 얻을 수 있는 확장 불가능한 구조는 피어에서 있어서는 안된다고 생각했다.
그러니 여기서는 관리, 인수인계의 용이, 발전적 목표가 가능하게 만들어서 새로운 개발이나 운영이 이어지더라도 항상 목표를 만들어 다음을 노릴 수 있는. 그런 형태를 만들 수 있으리라 판단했다.
스크럼의 업무 절차
본 내용은 오늘 있을 회의에 앞서 내가 머릿속에 집어 넣기 위해 적어보는 것이다.
- 계획단계 : 해당 하는 목적에 맞추어 타당성 조사, 기능 조사를 하고 이를 정리한다. 기능 정의, 기능 개발의 우선순위, 구현 가능 여부를 반드시 포함한다! (양식자유)
- 설계단계 : 기획 의도에 맞는 설계, 데이터 디자인, 기술 검증 마무리. 기능별로 개발 일정이 반드시 포함되어야 한다.
- 개발단계 : 설계 단계에서 만들어진 것을 기반으로 프로그램 작성. 스크럼 미팅을 반드시 진행하고(일정은 팀이 상황에 맞춰 진행, 매일 혹은 이틀에 한번이 적절) 팀 전체의 진행 절차를 반드시 파악하고, 진행이 제대로 안되는 쪽은 함께 해결함.
- 검증단계 : 요구사항들에 대해 판단하는 단계. 기획 의도를 파악하고 시험 결과등을 통해 개선 요소가 있는지 판단하는 작업. 바로 보수하는 것이 아닌, 리스트업을 통해 2단계 개발 작업에 들어가야 하는지를 판단한다.
- 피드백 단계 : 개선해야하는 경우, 다시 STEP 1로 돌아가기 위해 밑 작업을 재 진행한다.