테크 블로그 TechBlog

짧은 이야기로 시작해 볼까요?

한겨울에 이등병이 찬물로 빨래를 하고 있었습니다.
그 모습을 본 대대장이 짠 했는지 취사장에 가서 따뜻한 물을 얻어다가 빨래를 하라고 합니다.
이등병은 좋아라 하면서 취사장으로 뛰어가 따뜻한 물을 달라고 합니다. 하지만 이등병의 예상과는 다르게 취사장에 있던 선임들은 군기가 빠졌다는 구박하고 얼차려를 줍니다. 호되게 구박만 당한 이등병은 구시렁거리며 다시 차가운 물로 빨래를 하게 되었습니다.

얼마 뒤 이번에는 중대장이 보고선 손에 동상 걸릴지 모르니 취사장에서 따뜻한 물을 얻어다가 빨래를 하라고 합니다. 하지만 이등병은 영혼 없는 대답만 하고 취사장으로 더 이상 가지 않습니다. 구박만 당하고 소득이 없을 테니까요.

이번에는 행정보급관이 지나가며 이등병에게 자기가 세수를 해야하니 따뜻한 물을 떠 오라고 합니다. 당연히 이등병은 어렵지 않게 취사장에 가서 따뜻한 물을 얻어와 행정보급관에게 가져다줍니다.
행정보급관은 이등병이 떠온 따뜻한 물로 세수를 하지 않고 오히려 이등병에게 따뜻한 물을 건넵니다.
“따뜻한 물이 얼마 되지 않지만, 이걸로 손을 녹이면서 빨래를 하게”

---

무엇이 달랐을까요?

대대장은 문제를 바로 인지하고 해결책을 제시했지만 실질적인 도움이 되진 못했죠. 중대장의 경우는 대응이 똑같았으나 결과는 더욱 안 좋았죠. 이등병을 체념하게 만들었으니까요. 행정보급관은 같은 상황에서 선임이 어떻게 반응할지 예측하고 이등병에게 실질적으로 도움이 될 수 있는 대안을 제시하죠.

 

개발 문화에서 문서화 같은 작은 항목에서도 프로세스 개선이 쉽지 않은 이유는 "개선"방법이 실질적으로 빠르게 피부에 와닿지 않거나 프로세스를 위한 또 다른 프로세스를 만드는 방식인 경우가 많기 때문입니다.

Agile이 그간 많은 오해와 회의적인 평가를 받은 이유는 개인적인 생각으로 Agile이라는 이름으로 관리 Process가 추가되고 더 많은 커뮤니케이션 비용을 발생시키기 때문일 것입니다.

 

제가 생각하는 Agile은 단순합니다. 작지만 빠르게 Prototype을 만들어 실행하고 검증해서 실패면 빨리 버리고 개선점이 있으면 발전시켜서 쓸모 있는 Output을 만들어 가는 과정이라고 생각합니다.

---

안녕하세요. 저는 GS Retail 주문방송IT팀에서 주문-결제 개발/운영 업무를 담당하고 있는 최종찬 SoMA라고 합니다.
약간 쑥스럽지만 운영 업무에 투입되어 개발자들과 우리가 하는 일을 기록하는 실질적인 문서화에 대한 고민과 우리만에 개발문화를 만들며 프로세스로 안착시키기 위한 작은 실천의 경험을 공유하고자 합니다.

---

개발문화에서 문서화는 왜 필요한가?

'개발자는 코드로 이야기하는 거 아니야?'라고 생각하는 일반인이 있을 수 있겠으나 개발조직에서도 문서화는 생각보다 큰 의미를 가집니다.

담당자가 없더라도 업무의 영속성을 보장하고 업무 정보를 공유하여 다른 사람들도 업무 흐름을 쉽게 이해할 수 있으며 업무 수행 중에도 효율적인 커뮤니케이션을 위해 문서화는 필수 불가결한 항목입니다. 문제는 SI 프로젝트를 하면서 의미 없는 깡통 산출물을 작성하거나 관리적 관점의 불필요한 문서를 만드는 경우가 많아 개발자들 중에 문서화에 반감을 가지시는 분들도 있습니다.

제가 생각하는 문서화는 형식에 얽매인 관리를 위한 문서는 지양하고 가볍게 작성할지라도 필요에 의해 작성되고 발전할 수 있는 문서를 작성하는 것이 중요하다고 생각하며 그 대 원칙은 "투명한 개발과 공유"라고 생각합니다.

정보가 독점되지 않고 공유하는 것은 개발문화에 미치는 영향이 크다고 생각하고 있으며, 아마도 그런 이유로 당사는 Confluence(Wiki)라는 문서화 도구와 Jira라는 협업도구를 사용하고 있습니다. 우리는 이 도구를 과연 잘 활용하고 있을까요?

---

발전을 위한 첫 단계는 오늘의 문제들 확인하기

말씀드렸듯이 현재 우리 조직은 Confluence(이하 Wiki) 와 Jira를 사용하고 있습니다.

행봇이라는 챗봇을 통해 요구사항이 접수되면 자동으로 Jira Ticket이 생성되고 개발자는 요건을 분석하고 요청자, 기획자와 같이 협의 과정을 거쳐 확정된 feature를 개발합니다. 개발 중에 혹은 개발이 완료된 후에 Wiki에 요구사항, 개발요건, 테스트 결과 등을 정리합니다.

협업을 위해 Jira를 쓰고 산출물을 위해 문서화 도구로 Wiki를 딱 그 목적으로만 사용하고 있는 상태인 거죠.

Jira와 Wiki의 관계는 유기적이고 상호보완적이지만 현재 우리의 상태는 그 시너지를 내지 못하고 있는 상태라는 게 첫 번째 문제 인식이었습니다. 그리고 개발이 끝난 후 관련 내용을 다시 정리해서 작성하는 일은 귀찮은 일로 생각되고 있다는 것이 두 번째였습니다.

• Wiki와 Jira가 이원화되어 관리되어 시스템적 연계가 없음.
• 개발 이후 Wiki 작성 시 기존의 문서를 복사해서 내용은 지우고 작성하고 있음
  → 문서를 작성하는 첫 단계부터 번거로움
• 문서 양식이 표준화되지 않고 여러 개의 버전이 존재함.
• 개발 중에 발생한 수많은 의사결정 사항들은 개개인의 이메일과 채팅창에 있고 차후 아무도 History를 모름.

---

실질적이고 효과적으로 문서화 프로세스를 위한 작은 시도

우선 첫 번째로 Jira Ticket이 따지면 Wiki에 문서를 바로 등록하고 개발을 시작하기로 Groud Rule을 정했습니다. 

Wiki Templete 작성

산출물의 양식을 통일하고 필수 작성 항목을 강제하기 위해 Custom Templete을 만들어서 활용하기로 했습니다.

개발/CSR Note라는 이름으로 Templete을 생성했습니다. 기존의 틀을 크게 흔들지 않은 선에서 작성하되 필수 작성 항목을 규정하였습니다. 그리고 매주 몇 가지 시도를 추가하고 불필요한 항목은 삭제하는 과정을 몇 차례 진행했습니다.

• 양식을 복사해서 내용을 지우고 새로운 내용를 채우는 비효율이 사라졌다.
• Jira Epic을 연동하여 Jira와 Wiki 문서 간 연결고리를 만들었다.
  * Wiki 문서에 Jira Issue를 식별하여 연동하면 Jira에서도 해당 Issue에 Wiki가 연동되어 노출됩니다.
• 개발 요건을 정리하면서 개발자 개개인이 진행할 Jira Task를 바로 생성하자.
  * Wiki에서 Jira Ticket을 바로 발행할 수 있지만 Tool에 익숙하지 않으면 절대 모르는 기능이죠.
• 의사결정사항을 Wiki에 정리하고 상호 Comment를 작성하여 커뮤니케이션과 기록이 별도의 작업이 되지 않게 하자.
  * 대면회의 내용이든 e-mail 이든 우선 해당 내용을 Wiki 문서에 옮겨두기로 했습니다.

Guide 문서 작성 및 문서 생성 간편화

구성원들과 합의(??)가 있었지만 문서를 작성할 때, 해당 Templete을 찾는 일이 번거롭다는 의견이 나왔습니다. 또 신규 입사자가 생기면서 해당 내용을 공유해야 되는 이슈도 생겼습니다. 좀 더 이 과정을 편하게 할 수 없을까 고민하다가 버튼을 통해 정해진 Templete을 찾아다 생성해주는 기능을 찾을 수 있었습니다.

우선 Parent Page에 가이드 문서를 작성하고 버튼을 통해 Child Page로 개발/ CSR Note가 자동적으로 생성되도록 하였습니다.

• 가이드를 보고 누구나 쉽게 최초 산출물을 작성할 수 있게 되었다.
  * 최초부터 완벽한 문서를 요구하지 않는다. 그 시점에 확인된 정보만 작성하고 과제 진행 중에 수시로 업데이트하기로 약속했다.
• Wiki를 작성하면 추가적인 문서작업은 강요하지 않았다.
  * 다만, 과제 진행에 논의되었던 내용을 모두 기록하기로 약속했다.
• 웹상에 공동작업의 이점을 알게 되었다.

필요에 따른 점진적 시도

Templete를 활용해 문서를 표준화하고 편하게 불러올 수 있게 하는 방식은 생각보다 호응이 좋았다. 그래서 DB Object Note, Test Case Note를 Templete에 추가하고 작업해보기로 했다.

• DB Object Note는 현재 기록으로서의 역할만 하고 있지만 사내 Meta System의 요청 프로세스와 연계해보려고 하고 있다.
• Test Case Note에는 순서도를 첨부하여 어떤 포인트를 체크해야 하는지 명확하게 표현해보려 하고 있다.

---

마치며

개발문화는 몇 마디 문장으로 규정지을 수 없고 정답이 있는 프로세스도 아니라고 생각합니다. 다만, 우리가 더 효율적으로 일하고 더 유기적으로 협업하기 위한 개발문화를 위해 노력할 필요가 있습니다. 그 과정에 우리는 Agile하게 접근할 수 있는데, 우선 어떤 형태로든 작은 Prototype을 만들고 필요에 의해 수정하고 개량하여 조금씩 발전시킬 수 있다고 생각합니다.(Agile이라면 기함을 토하시는 분도 계시지만 제가 생각하는 Agile에 대해 따로 공유할 기회가 있을지 모르겠습니다.)

 

개인적인 의견으로 개발자에게 문서화란 결국 자기 자신을 위한 일이라 생각입니다. 내가 한 일을 가감 없이 투명하게 공유하고 그 때의 이슈를 기록하는 습관이 필요합니다. 그런 과정이 반복되면 자연스럽게 업무 매뉴얼이 되고 다른 이는 지식자산화라고 부를 수도 있습니다. 내가 아니어도 다른 인원이 내 일을 백업할 수도 있고 업무가 한 사람에게 집중되지 않아 조정을 할때도 조직은 유연하게 대처할 수 있습니다.

 

---

References

[Confluence Guide] https://www.atlassian.com/blog/confluence/confluence-software-teams-ebook

---

 

최종찬 SoMA | 뉴테크본부 > 주문방송IT팀

주문/결제 Domain 개발/운영 업무를 담당하고 있습니다.

적절한 기술을 최대한 활용해서 개발하고 싶어하고 유연한 개발문화 정착을 위해 노력하고 있습니다.

#주문 #DesignThinking #Agile