개발 문서 작성 질문 드립니다.

Question

안녕하세용.담당한 프로젝트가 끝나가는 뉴비입니다.다름이 아니라, 기획 단계부터 조금씩 작성해왔던 개발 문서들이 있습니다.이걸 이제 좀 정리를 하고, 다음 프로젝트부터는 좀 처음부터 잘 해보려고 합니다.그래서 도움을 주셨으면 좋겠습니다.1. 어떤 개발 문서를 작성해야 하는가?제가 찾아본 바로는, 일단 아래 4가지 정도는 어딜 가나 필수로 작성하는 거 같았습니다.화면 설계서 / 와이어프레임?기능 정의서 / 요구사항 명세서ERDAPI 명세서제가 궁금한 건 요즘에는 저 4개로 끝내는 건가요?요즘에는 클래스 다이어그램, 시퀀스 다이어그램, 유스케이스 다이어그램이나 데이터 흐름도 등등은 요새는 잘 안쓰는 추세라 하더라고용?2. 각 문서 작성자가 누구인지?일단 저는 문서 작성을 혼자 했었는데,보통 각 문서마다 작업 부서가 나누어져 있는 건지 궁금합니다.화면 설계서는 디자인해주는 사람이 있는 지 등등...3. 문서 종류가 정해져 있는지?보통 회사에서 '엑셀을 써라' 하고 정해주나요?일단 지금 있는 건 엑셀이랑 몇개 섞어서 썼는데, 정해져 있는 지 궁금하네용

정규분포 · Answer

이런 회사마다 다른거고, 솔직히 말하면 왠만하게 큰 곳 들어가는 것 아니고서야 그렇게 깐깐하고 분업화 되어있는 곳 찾기 어려워요. 다들 바빠 죽겠는 환경이면, 학교에서 배우는 것은 다 이상에 가깝죠.1. 어떤 개발 문서를 작성해야 하는가?UML 얘기하는 것 같고요. 단순한 CRUD 앱 개발하는데 다이어그램 하나하나 다 그리는 것은 좀 그렇고. 피드백 받아 보면 다이어그램이 필요한 부분이 어디인지 파악되실겁니다. 왠만하게 시스템이 복잡하게 얽히지 않는 이상, 코드만 봐도 충분한 곳이 많긴 함.제가 궁금한 건 요즘에는 저 4개로 끝내는 건가요?네. 4개만 하는 것도 힘들고, 다 헛소리 없이 다 나와있으면 휼륭한거죠.화면 설계서 / 와이어프레임?각자 알아서/상사가 쓰라는 대로/Figma 같은 사용 프로그램/종이에다 그리고 스캔/백터 그래픽 에디터로 그리고 svg로 뽑아두기 등등. 대기업은 대부분 프로세스가 따로 있고, 배우시게 됨기능 정의서 / 요구사항 명세서명세서만 적어도 많음. 시트에 목록 만들고, 필요한 부분은 따로 정의서로 뺌. 저는 편하게 그냥 md로 적고, 문서로 뽑으라는 대 있으면 그냥 pdf로 렌더링해서 줍니다. 표랑 도형 들어가기 시작하면 워드를 써야하지만, 반대로 오픈소스 치고 그렇게 하는 곳 못 봄.ERD프로그램으로 스키마를 ERD 이미지 파일로 뽑는 것은 의미가 없고, 데이터 모델 설계를 왜 그렇게 했고, 연관 관계가 뭔지 설명하는 문서가 더 중요합니다. 인덱싱은 왜 했고, 필드에 들어가는 값은 어떤 RFC에 정의되어 있고 등등. Join이 어떻게 되어서 애플리케이션에 사용되는지 등.API 명세서글세요. javadoc 등 코드 주석을 문서로 렌더링하는 것에 불과하죠. AWS SDK 문서화 같이, 각 API 문서보다 예제를 만들어서 개발자들이 어떻게 사용하게 유도하는지가 더 중요함.2. 각 문서 작성자가 누구인지?구현체는 만든 사람이 해야 하고, 기획한 사람이 기획 문서 만들고, 클라이언트 요구사항 파악하는 사람 등등이 행죠. 그런 당사자가 아닌 사람이 문서화 하는건 좀 그림이 이상하네요. proof reading 하는 사람이 필요하긴 할겁니다. 근데, 그렇게 분업 잘 되있는 조직은 사실상 유니콘.화면 설계서는 디자인해주는 사람이 있는 지 등등...3-4년제 UX/UI 디자인 전공하는 사람이 있기는 해요. 한국에서는 있지 모르겠음.3. 문서 종류가 정해져 있는지?아니요. 적절한거 쓰세요. 참고로 UML 마저도 도형 형식만 정해진 표준이고, 실제로 파일 형식이나 소프트웨어까지 정의하는 표준이 아님. 찾아보면 은근 특화된 툴도 많이 나와있음. KiCad, plantuml 같은거.

캐티 · Answer

솔까 정답이 없지만 정부에서 하는 프로젝트에 공무원들이 보여주거나 남길 문서를 억까 요구하여서 실질적으로 인력 낭비가 심하다고 전문가들이 입을 모았쩌. 일반 사람들은 다른 기준을 들겠지만 진심 개발자들이 가려는 목표가 있는데 이케이케 나쁜 작용을 하빈다.내가 개발을 하는데 목적을 정의하고 나면 기술 문서만 남아요. 주로 기초 기술 문서들이고 이거는 RFC에서 나오는 공통 규칙은 안해요. 첫 장에 보면 키워드들을 규정하거든요. 남에게 보여줄 특별한 이유가 있어야 이케하빈다.텍스트 내지는 마크다운이 가장 좋고 앵간한 경우에 텍스트 문서를 써요. 이케 하지 않으면 수정하는데 난리가 날꺼 아니나요.RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport 1.2. 규정 정의

halfenif · Answer

개인적인 생각입니다.현재 작성자님 마음 속에는 방법론의 개념이 아직 없다고 판단됩니다.물론 많은 사람들이 캐캐묵은 방법론이 무슨 필요가 있냐라는 사람도 있습니다만.개발자로서 "체계"를 가지고 zero-base에서 "구축"을 해 보라고 하면, 할 수 있는 역량을 가진 개발자가 몇 %나 될까요?주먹구구식으로 접근하지 마시고 각종 방법론과 산출물 그리고 테일러링 한 내 것을 만들어 보는데 시간을 투여해 보시면 어떨까요?

개발 문서 작성 질문 드립니다.

3개의 답변

Q&A 목록