인프런 커뮤니티 질문&답변
작성한 질문수
룰셋으로 문제를 푸는것에 대해
작성
·
32
1
룰셋으로 풀어내면, 일종의 암묵지가 생깁니다.
이런 내용은 결국 어딘가에는 적혀 있어야 다음에 온 개발자가 인지할 수 있는데 보통 안적혀있습니다.
지금 재직중인 회사에도 이런 문제가 있어요.
그래서 이런 암묵지를 문서화하려고 노력중인데, 다른 회사에서는 어떻게 정리해두는지 궁금합니다.
왜냐하면 PRD(기획서)와는 다른 종류의 문서이기 때문입니다.
기획서야 최초 기능, 개선건 등등 개발이 들어갈때마다 신규 문서를 작성하면 쉽지만,
이런 암묵지(정책)를 모아둔 문서는 통합된 단 하나의 문서가 있어야 나중에 이해하기 쉽거든요.
(기획서로 정책을 이해하려면 최초 개발 문서부터 최종 문서(개선건)까지 전부 읽어야 정책을 알 수 있음)
영상에서 이런 암묵지를 관리하는 내용은 소개되지 않아 질문을 남깁니다.
암묵지: 코드로는 보이지 않지만 반드시 지켜져야하는 규칙
답변 2
0
안녕하세요! 질문 감사드립니다!
현실적으로 대부분의 회사가 회사 레벨에서 이런 문서를 관리하지 않고 최소한으로 한다해도 팀별로 관리되는 편인 것 같습니다 😢
그럼에도 몇몇 회사에서 문서화 했던 경험으로 말씀드리면 팀/파트 단위로 문서화를 진행했을때는 프로젝트 별 Git Repo 에 CONVENTION.MD 같은 파일을 만들어서 기록을 해두었습니다.
(레거시 프로젝트가 있었기 때문에 전체 프로젝트의 룰을 동일하게 할 수는 없었고, 프로젝트 별 룰을 만들어서 정의 했었습니다, 최악의 경우 이 프로젝트는 룰이나 수준을 관리하지 않는다 라고 적었던 적도 있습니다)
반대로 전사 컨벤션을 유지 시켜봤던 경험에서는 모~든 신규 개발자가 입사할때마다 정기적으로 교육을 진행했습니다.
(지속 성장 가능한 소프트웨어를 만들어가는 이 문서가 그 교육 세션의 CONVENTION.MD 일부를 발췌한 글입니다)
그리고 개발자 온보딩 문서에서도 해당 문서의 링크를 달아두었고 최대한 많이 노출되도록 가이드 했습니다
이때는 운이 좋았던게 회사 출범 부터 제가 있었기 때문에 이 룰을 정착시키기가 쉬웠습니다
솔직히 중간에 입사한 관점에서는 프로젝트별로 룰 문서 작성하는게 최선아닐까 싶네요 😢
사실 이런 암묵지를 정리하는 것은 정말 큰 과업 중 하나입니다, 그치만 안타깝게도 회사/동료의 태도도 중요하다고 봅니다.
그거 해서 뭐가 나아지는데? 그거 할 시간에 일이나 더 해 << 이런 태도로 나오는 회사/동료(상사)도 제 경험에 있었어서 참 어려운 부분이라 생각합니다.
그들을 설득하는 방법은 결국 효과를 보여주는 것 밖에 없었습니다. 그런 암울한 회사에 있을 때 저는 주말에 개인 시간까지도 할애해서 문서화를 진행했고, 이게 추후 갑작스러운 퇴사자 발생 + 신규 입사자가 생길때의 효과가 있다는 것을 입증한 적이 있습니다.
그치만 이건 뭐 대단하다기 보다는.. 개인이 희생해야 설득이 가능한 것이다보니 안타까운 일이라고 생각합니다 😢
암묵지 청산을 하고 계시다니 아주 멋진일입니다!
모쪼록 답이 되었길 바랍니다! 완강 후 수강평도 기대하겠습니다!
감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다.
buevonhun님이 질문하신 것처럼 암묵지(implicit knowledge)는 개발 작업의 효율성과 품질 유지에 중요한 요소입니다. 이러한 암묵지를 효과적으로 문서화하는 방법은 특히 팀 내 의사소통 강화와 지식 이전에 큰 기여를 할 수 있습니다.
암묵지 관리 방법
컨플루언스(Confluence) 혹은 위키(Wiki) 시스템 활용:
- 많은 기업들이 컨플루언스와 같은 협업 도구를 활용하여 정책, 규칙, 모범 사례 등을 기록하고 관리합니다. 이는 모든 팀원이 쉽게 접근하고 수정할 수 있어서, 암묵지를 공식화하는 데 유용합니다.
- 많은 기업들이 컨플루언스와 같은 협업 도구를 활용하여 정책, 규칙, 모범 사례 등을 기록하고 관리합니다. 이는 모든 팀원이 쉽게 접근하고 수정할 수 있어서, 암묵지를 공식화하는 데 유용합니다.
코드 리뷰 과정에서 문서화하기:
- PR(풀 리퀘스트) 리뷰 시, 코드 외에도 암묵지나 정책에 관한 논의를 포함하여 기록하는 방법입니다. 이는 개발자가 코드를 작성하면서 자연스럽게 문서화 과정을 거칠 수 있도록 유도합니다.
- PR(풀 리퀘스트) 리뷰 시, 코드 외에도 암묵지나 정책에 관한 논의를 포함하여 기록하는 방법입니다. 이는 개발자가 코드를 작성하면서 자연스럽게 문서화 과정을 거칠 수 있도록 유도합니다.
정기적인 회의와 워크샵:
- 암묵지가 자주 변경되는 경우, 정기적으로 스크럼(스크럼 미팅)이나 워크샵을 열어 새로운 정책이나 규칙을 공유하고 문서화하는 것이 좋습니다.
- 암묵지가 자주 변경되는 경우, 정기적으로 스크럼(스크럼 미팅)이나 워크샵을 열어 새로운 정책이나 규칙을 공유하고 문서화하는 것이 좋습니다.
표준화된 문서 양식 만들기:
- 모든 개발자가 따를 수 있는 표준화된 문서 템플릿을 만들어 사용자의 접근성과 일관성을 유지할 수 있습니다.
- 모든 개발자가 따를 수 있는 표준화된 문서 템플릿을 만들어 사용자의 접근성과 일관성을 유지할 수 있습니다.
다른 회사들에서도 다양한 방법으로 암묵지를 관리하려고 노력하고 있으며, 각 회사마다 문화와 운영 방식에 따라 접근이 다를 수 있습니다. 관련 정책을 문서화하는 작업은 혼자 작업하기보다는 팀 전체의 참여와 인식이 함께 이루어지면 더 효과적입니다.
관련 토론과 실무적인 예를 제공하는 게시물을 참고하시길 추천드립니다. 아래 몇 가지 링크가 도움이 될 수 있습니다.
- 컨플루언스 및 위키를 활용한 협업과 문서화 전략 소개 - 팀 내 암묵잠 관리와 관련된 아이디어를 공유할 수 있는 공간입니다.
- 효율적인 코드 리뷰와 문서화 과정 - 팀 내 코드 리뷰 프로세스와 암묵지를 문서화하는 전략을 논의합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.