개발 문화에 대한 사색

• 각 개발팀마다 고유의 개발 문화가 존재한다. 문화는 둘 이상의 사람이 만나야 만들어 진다고 한다. 혼자서 행하는 것은 문화라기보단 습관이나 개인학습에 가깝다고 본다.

• 개인적으로는 코드 리뷰도 있었으면 좋겠고, 똑똑한 사람들만 한다는 TDD 방식도 도입했으면 좋겠고, 주 1회 스터디도 있었으면 좋겠고, 등등 이지만, 사실 본인이 주니어 개발자이다 보니, 이것 저것 경험 해보고 싶은 욕심이 커서 바라는 것만 많을 뿐이다.

• 문화는 원한다고 다 만들 수 있는게 아니다. 주위 환경에 가장 큰 영향을 받고 한정된 리소스에 두번째 영향을 받을 것이며, 함께하는 구성원들이 마지막 영향을 미칠 것이다. 윗사람이 그거 필요없다 라고 하면 얄쨜없다는 것이다.

• 그럼에도 불구하고 코드 리뷰와 스터디 정도는 생겼으면 좋겠다는 바람이다. 혼자서 학습하는게 효율이 영 좋지않은 나로써는 반강제로라도 의미를 부여해야 발전이 있을 것이니까.

• 오늘은 곧 개발팀이 만들어질 회사와 더 정확히는 나를 위해 어떤 협업툴이 있는지, 백엔드라면 꼭 필요한 API 문서화 툴에는 어떤 것이 있는지 한번 찾아보자. 그리고 어떠한 개발문화가 우리 회사에 적합하고 앞으로 만들어질 팀원들은 어떤 것을 원하는지 들어본 뒤에 결정해도 늦지 않을 것이다.

협업툴

Github

1. issue 탭에서 현재 발생한 문제점들을 등록하고 관리 할 수 있다.
2. Project 탭에서 issue 와 연결하여 업무를 세분화 하고 분배가 가능하다. 유사한 협업툴로는 Trello 가 있는데, Trello는 티켓 내부에 체크리스트를 만들 수 있는 기능도 존재한다.

장점 : 깃헙의 기능들이 늘어남에 따라 단순히 코드만 관리하던 공간에서 협업을 용이케하는 기술을 갖춤. 깃헙 하나에 툴이 몰빵되어 있으므로 이곳 저곳 돌아다니며 프로젝트 관리를 따로 하지 않아도 됨.

단점 : 기능들이 하나씩은 부족한 부분들이 존재함. 또한 혹시라도 깃헙이 다운되어 버린다면 멘붕이 올 수도 있음.

Trello

1. 티켓을 생성하고 티켓 내부에 체크리스트 및 task 관리가 가능한 툴
2. 직관적이고 누가 담당하고 있는지 쉽게 알아볼 수 있음.
3. 티켓 내부에 노션만큼 다양한 마크다운 기능들이 있음

장점 : 티켓을 잘 만들어 두면 스크럼이나 스프린트, 회고와 같은 미팅들에서 티켓만 열어서 회의 가능. 티켓 오픈 방식이 팝업형이라서 시각적으로도 편리함.

단점 : 프로젝트외의 용도로는 사용하기 어려움. 회의록이라던지 레퍼런스 및 스터디 관련 공유를 위해서는 다른 툴 사용이 불가피. 규모가 커지면 유료.

Jira

1. 노션과 트렐로가 적절히 섞여 있는 느낌. 인터페이스는 생각보다 난잡함.
2. 사용법을 잘 알고 있다면 세세하고 보다 꼼꼼하게 프로젝트 관리가 용이함.
3. 10명 이상부터 유료

장점 : 많은 개발팀들이 지라를 활용하여 프로젝트 관리를 하고 있음. 인터페이스는 처음보기에 복잡해 보이지만 사용법이 직관적이고 쉬움. 무엇보다 일정을 분기 및 일별, 시간별로도 나눌 수 있어서 철저한 계획성을 지켜나갈 수 있음.

단점 : 사람에 따라 굉장히 귀찮은 부분이 될 수 도 있다. 사용법에 대한 학습 시간 필요. 구성원이 많아지면 유료.

Notion

1. 문서 작성, TASK 관리, 일정 관리, 레퍼런스 공유 등등 활용도와 방식에 따라 자유자재로 사용이 가능함.
2. 개발자라면 누구나 한번쯤 써봤을 법 할 정도로 대중적이고 잘 알려져 있어서 따로 학습의 기간 불필요.
3. 기업형은 유료

장점 : 친숙하고 문서 작성만큼은 노션을 따라 올 툴이 없는 듯. 캘린더 기능도 있고 체크리스트, 토글 기능까지 없는게 없는 수준.

단점 : 생각보다 최적화가 좋지 않음. 전체 너비로 바꾸면 전체 페이지로 하지 않는 이상 문단들이 시각적으로 보기 좋지 않음. 개인별 일정 관리 힘듦. 프로젝트용 협업툴 이라기 보다는 전사적인 공유 페이지 역할이 더 잘 어울림.

API 문서 작성용 툴

swagger

1. DRF 에 더없이 친숙한 API 전용 툴
2. 라이브러리는 다소 무겁지만 코드 내부에 몇 줄을 추가하여 자동화 할 수 있음
3. 자칫 코드가 지저분해 보일 수 있음
4. 회사에 이미 관련 코드가 존재함. 다만 모든 api에 적용되어 있는지는 추가 확인 필요

Postman

1. mock 서버를 만들 수 있는 기능 존재
2. api test 에 거의 필수적인 프로그램
3. api 문서화 시 별도의 코드 작업 불필요. 프로그램 내부에서 클릭 몇 번으로 문서 생성 및 배포도 가능.
4. 불-편 (올 수작업)
5. 포스트맨 자체가 겁나 무거움(다량의 리소스 쪽쪽)

Slate

1. 깃헙 돌아다니다가 찾은 api 문서화 툴
2. api 에 대한 설명을 붙이기 좋음. 마크다운 지원.
3. html 파일 하나만 수정함으로써 문서화 가능. 사용법에 대한 예제도 제공하므로 학습에 용이함.
4. 사용을 위해서는 루비를 설치 해야함.

API Blueprint

1. Slate와 비슷한 인터페이스와 결과물

2. 문서를 세련되게 꾸미고 표현 할 수 있음

3. 렌더러 없음. 단, Third-party 렌더러 사용이 필요함 (ex: Aglio)
   Aglio 사용 시 5개 테마 & 2, 3패널 디자인 제공

4. 학습난이도 약간 높음

GitBook

1. 깔끔한 UI 제공

2. Git의 commit / merge가 존재 -> 문서 버전 관리 가능 (=업데이트 내역 확인 용이)

3. 테스트 요청 / 응답 사용 불가

4. 팀이 사용할 경우 유료 (개인은 무료)

Ref.

API 문서 작성이란(카카오)
Slate 관련 블로그
GitBook 관련 블로그