병역특례 현역 (대기)로 입사,
보충역 4명 채용을 조건으로 입사 하였으나, 회사 사정이 안 좋아져 퇴사하였음.
담당업무:
본인 포함 3명 개발자로 이루어진 팀의 임시 PM역할을 하였습니다.
대표님께서 '한정된 자원으로 빠르게 정확하게 결과를 만들자'라고 늘 주문하시어 린 스타트업에 대해 이해하게 되었습니다.
'어떻게하면 효율적으로 일할 수 있을까'를 늘 고민하여 일하는 방식을 매번 더 좋은 방향으로 개선하고자 노력하게 되었습니다.
아래는 그러한 지침을 통해,
지속적으로 발전하고자 해왔었던 업무들 내용 입니다.
1. 애자일 개발 프로세스 도입
- Jira 및 Confluence 툴을 이용
- 주 단위로 Task 등록하여 예상시간 및 작업시간 기록
- 매일 오전 Scrum 등을 통한 업무 정리 및 일과 파악
- 매주 Sprint 회고를 통한 문제점 파악 및 해결방안 모색 회의 진행
- 회의록, 스터디, 개발하면서 느낀점 및 정리 내용은 모두 자체 Confluence에 기록
2. 버전관리
- Semantic Versioning 2.0 가이드를 따름.
* Major, Minor, Patch로 나누어 버전 관리 진행
* 기존 버전과 호환이 되는 신규 기능 개발 시, Minor Update.
* 기존 버전과 호환이 되는 bug fix시, Patch Update.
- Github에 Minor 업데이트 시 마다, Reademe.md 파일 및 Release에 업데이트 사항 기록
- Jira Task 등록 시, 버전명과 배포일이 설정되있는 버전을 선택하여 등록. (Minor 기준)
* 각 버전별로 어떠한 Task를 진행하였는지, 언제 시작하였고 언제 배포하였는지 체크.
- Git Commit 시, Minor Update때마다 해당 버전 Tag 등록. (Github Release에 Tag별로 기록하기 위함)
- 신규 기능 개발 완료 시, Minor 버전 업데이트, 버그 및 기타기능(자잘한 기능 추가, UI 변경 등)은
3. GitFlow를 통한 git 전략
- master: dev용 서버에 배포할 때 사용.
- Feature: develop branch를 base로, branch를 생성하여 진행.
- Bugfix: 개발이 끝난 기능에 대해서 bug 발견시 develop 브랜치를 base로, bugfix/티켓번호 branch 생성
- develop: 신규 개발시 base branch로 사용, 팀원과 merge후 bug fix시 base branch로 사용.
(github에서 해당 feature명으로 브랜치 pull request)
- Release: bug fix가 완료되었을때와 develop 브랜치에서 기능 개발을 완료 후에 QA 및 테스트, 리뷰를 위한 브랜치로 사용.
- production: Release단계에서 리뷰 및 QA 작업이 끝난 후 production용 서버에 배포할 때 사용.
4. Study Day 문화
- 금요일 마다 개발관련 본인이 관심있는 내용을 스터디 진행
- 2시간 동안 스터디 및 공부한 내용을 Confluence에 정리.
- 각 10분 간, 각자 정리한 내용을 각 팀원들에게 발표하여 공유.
5. Linux 관리
- 각 팀원별 권한 부여 및 팀원별 폴더 생성
- 그룹별 권한 부여 및 팀원 계정별 그룹 배정.
- sftp로 원격 접속하여 파일 및 폴더 관리.
- disk 공간 관리 및 트래픽 모니터링
(AWS EBS volume Attach하여 리소스 해결 사례,
AWS CloudWatch 및 경보 등록으로 트래픽 파악,
Linux에서 iftop, iptop, whatap 등의 툴로 접속처 및 트래픽, 시스템 모니터링)
- Nginx 및 PM2 이용한 Proxy 관리, Build된 App Serve, 프로세스 관리
6. AWS 인프라
- 비용 절감 사례 (불필요 EC2 삭제, RDS 비용 관련 최소화, 492$ -> 339$)
- Reserve Instance 도입을 통해 비용 절감 건의 (약 850$ 절감 가능).
- Route 53를 통한 도메인 관리, sub-domain으로 각종 서비스 serve.
- RDS: MySQL 엔진 사용, 7일 간의 Snapshot으로 백업 관리
(snapshot을 불필요하게 30일간 backup하고 있었음. -> 7일로 줄이고 추후 필요시, 다른 EC2에 dump 파일을 backup하기로 함)
- S3: 각종 이미지 및 기타 리소스 저장 관리로 사용.
- AWS Service 파악 및 비용 절감을 위한 AWS 101 Seminar 참석.
7. Jenkins CI & Docker
- 편리하게 Dev와 Production 서비스 구분&배포
- github webhook을 통한 git pull 시, 자동 배포.
- Dev, Prod별 서비스를 Build.
8. Clean Code 부분 도입
- 스터디 시간에 진행했던 Clean Code를 부분 도입.
- 각자 개발한 코드를 보고 변수명 관련하여 Review.
- 적절한 변수명에 대한 토의 진행 후, '길어도 친절한 변수명' 규칙을 도입.
9. Dev용 DB 구축
- Dev DB를 구축하기 위한 EC2 생성
- Production용 MySQL 14.09 버전의 DB와 호환을 위해 MySQL 14.14버전으로 설치
- AWS와의 환경과 맞추기 위해 Time Zone을 UTC로 설정.
- Production DB에서 테이블 자료만 Dump하여 import.
10. Telegram을 통한 커뮤니케이션
- Dev 혹은 Prod github push 진행 시, commit 내역 Telegram 알림봇 추가
- github에서 Pull Request 및 Issues 등록 시, Telegeram 알림
- PM과 개발팀원 간 커뮤니케이션 수단으로 사용
[개발 팀원으로써 한 업무]
1. 사내 관리 웹사이트 (Admin)
- 프로젝트 소개: 고객사별 주문한 내역 및 사용자정보, 주별 식단표 만들기, 카테고리별 가격 관리, 음식 메뉴 관리, 발주 및 식재료 관리 등 개발 진행하였음.
- 기존에 여러개의 이름으로 나뉘어져 있는 서비스들을 하나로 통합하는 작업을 주도적으로 진행하여 하나의 Admin 사이트를 구축하였음.
- React-Admin 라이브러리 및 Material-UI를 이용하여 개발
- Authentic, Auth, Token 권한을 통해 접근 메뉴 구분(Super Admin, User 구분),
- 고객사(Bluehole) 납품용 기능 개발 (주문내역, 사용자정보)
- Redux-Form을 통한 여러개의 Field 관리, 자동저장 구현.
- 한 페이지에서 Create, Read, Update, Delete 기능을 구현.
(Id를 기준하여, id가 없는 Object는 Create, id가 있는 Object는 이전 값과 비교하여 Update)
2. 고객용 주문 페이지
3. Node 및 MySQL(Sequelize)을 통한 API 개발
- 설계
- DB
REST한 개발 방식
- 가능한한 모든 기록은 문서화를 하도록 노력하였음.
- API 설계 후 프로토콜 정의서를 Swagger라는 tool을 이용하여 기 개발된 API를 기록함.
- Postman이라는 API Test tool을 이용하여 편리하게 test 진행.
- 위 나열한 Tool 들을 이용하여, 서버 <-> 클라이언트 담당자간 소통.
- 가능한한 Rest한 API를 개발할 수 있도록 담당자간 협의
* 복수/단수 표현(Document, Collection),
* status code 200,204,400,401,404,500 정의,
* 포맷 규칙 정의 (통일되지 않은 response 변수명을 단일화),
* URI path 규칙 정의,
* 같은 URI라도 용도에 따라 get/post/delete/put로 구분,
* pagination 및 filter, sort 기능등을 위한 Header 규칙 정의
4. 기타
- Webstorm을 통한 Change Log와 Jira Ticket 관리(Task 시작,완료)
- Jira Ticket name으로 git commit을 하여, git과 Jira Ticket 동기화 되도록 관리
더보기