오늘은 지난 3년간 다녔던 정들었던 회사를 떠나는 날이다.
2019.01.14 일에 입사해서 2022.04.25일 오늘 지난 3년 3개월간의 회사생활을 하면서 내가 어떤 업무를 어떻게 했는지 회고해본다.
1. 에디터 교체, 자료첨부 방식 변경
2019년 1월 입사하자마자 내가 맡은 기업용 SNS 의 에디터를 교체하였고(NicEdit -> CKEditor)
글쓰기 시 자료 첨부 방식을 페이스북처럼 글 하단에 첨부되는 구조에서 블로그 처럼 글 사이사이 첨부할 수 있는 구조로 변경했다.
에디터에 첨부할 수 있는 자료는 snippet(og tag), 언급(mention), 지도, 설문, 파일, 이미지, 드랍박스 파일링크, 구글드라이브 파일링크다.
우리 서비스는 페이스북같은 타임라인 구조였기때문에 글이 길면 ...더보기 를 클릭하면 글 영역이 펼쳐지는 구조였는데 밴드처럼 글을 클릭하면 글상세 레이어팝업이 뜨는 구조로 변경하였다.
에디터 자체가 바뀌었기 때문에 자료 첨부하는 방식자체가 다 바뀌어야했고 자료를 첨부하는 방식도 바뀌었기 때문에 (페이스북 구조에서 블로그 구조로) 대대적인 변화가 있었다.
오자마자 정신없이 달렸던 것 같다. 우선 에디터 교체부터 진행했고, 자료가 첨부되는 구조를 변경하기 위해 디비 구조부터 도메인 구조까지
많이 변경했고 우리서비스는 웹, 앱 서비스가 있어서 웹과 앱에서 동시에 처리하기 위해 첨부자료를 커스텀태그로 저장하도록 했다. 이 과정에서 앱개발자들과도 많이 협업했다.
2. 공유방 기능 재개발
우리 서비스에는 BAND 서비스에서 밴드를 개설하는 것처럼 공유방을 개설할 수 있다.
공유방에서 긴밀하게 협업해야하는 사람 또는 같은 조직사람 또는 관심사가 같은 사람끼리 모여서 글을 작성하고 정보를 공유할 수 있다.
그런데 이 공유방의 기능이 무척빈약하고 설계상 문제가 많았기에 신규 기능을 추가하면서 사실상 새롭게 개발하였다.
우선 신규로 추가해야하는 기능은 아래와 같다.
- 기존에는 관리자만 존재하였는데 운영자를 추가하고 운영자에게 일부 운영 권한을 부여하는 기능
- 기존에는 업무용공유방만 존재하였는데 비업무용공유방 및 카테고리를 추가하여 관심사가 같은 사람끼리 모여서 놀 수 있는 기능
- 업무용 공유방에 작성된 글에는 작성자에 소속/직급이 노출되었는데 비업무용공유방에 작성된 글은 소속/직급 비노출
- 구성원 초대/승인 방식 변경 - 기존에는 공유방에서 누군가를 초대하면 상대방의 승인 없이 자동으로 가입됐는데 비업무용 공유방에서는 상대방이 승인해야만 가입되는 기능
이 기능을 개발하면서 도메인 구조 및 데이터베이스 테이블 설계를 다시 했고
각 상황에서 발생할 수 있는 예외 및 예외 응답 코드를 설계하여 앱개발자와 공유. 협업했다.
공유방에 가입할 수 있는 경우의 수와 예외가 은근히 많았기에 생각보다 신경써야할 부분이 많았다.
가입신청 - 관리자승인 - 가입완료
가입신청 - 관리자거절
가입신청 - 공유방삭제 - 회원 가입 신청 목록에서 삭제
가입신청 - 가입신청한 회원탈퇴 - 관리자승인 목록에서 삭제
관리자가 다른 사용자를 초대 - 초대수락 - 가입완료
관리자가 다른 사용자를 초대 - 초대거절
공유방구성원이 다른 사용자를 초대 - 초대 수락 - 관리자승인 - 가입완료
공유방구성원이 다른 사용자를 초대 - 초대 거절
공유방구성원이 다른 사용자를 초대 - 초대 수락 - 관리자거절
등등...
3. 단일 조직도에서 복수 조직도로 구조 변경
우리 회사의 기업용 SNS 서비스는 기본적으로 하나의 조직만을 염두에 두고 설계가 되어있었다.
즉, 하나의 조직도만 가지고 있는 구조였다.
그런데 우리회사에서 큰 건물 하나를 임대하여 공유형오피스 사업을 추진하였고, 이로 인해 복수 조직도를 생성할 수 있는 구조로 변경이 불가피해졌다.
공유형 오피스 내 회사가 입주하면 그 회사의 조직도도 생성하여 그 회사에서 우리 서비스를 사용하여 협업할 수 있도록 해주기 위해서다.
이 기능을 추가하면서 피치못하게 서비스의 거의 대부분 도메인, 데이터베이스, 비즈니스로직이 재설계되었다.
복수 조직도를 구성하려면 조직도의 도메인과 데이터베이스 설계가 불가피했는데 기업용 SNS 이기 때문에 조직도가 대부분의 다른 도메인과 밀접하게 연관이 있었다.
또한 회원의 도메인도 재설계되었는데 대부분의 시스템이 그러하듯 회원 도메인은 전체 도메인과 관련이 있다. 하여 대대적인 수정이 있었고 많은 고민이 있었다.
또한 관리자 기능을 개발하는데 많은 시간과 노력이 들었다. 원래는 최고관리자 한명만 존재하여 최고관리자만이 조직 및 회원등을 관리할 수 있었는데 복수의 조직도가 되면 각 조직마다 최고관리자가 필요하기 때문이다. 그렇기 때문에 단순하게 관리되던 관리자 권한을 세부적으로 구성해야할 필요가 있었다.
4. 외부서비스와의 연동
위에서 서술했듯이 회사에서 공유형오피스 사업을 추진하였기에 회사내부에서만 사용하던 서비스를 모든사람이 이용할 수 있게 시스템을 변경해야했다.
이를 위해, 고객에 볼 수 있는 전면에 내세울 화면이 필요했고 이 부분은 회사내부가 아닌 외부업체에서 개발을 진행키로 했다.
신규로 추가된 기능은 회원가입, 커뮤니티(자유게시판, 알림방), 추천공유방 노출 등이 있었는데
우선 회원가입을 하면 외부업체에서 개발한 서버에서 회원가입이 되고 기업용SNS 에도 회원가입이 돼야하므로 API 로 연동처리를 하였고
커뮤니티, 추천공유방은 내가 관리하는 서비스에 있는 공유방을 노출만 하는 것이였기 때문에 내가 API 를 외부업체에 제공하였다.
또 우리서비스는 그룹웨어 서비스와 연동이 되어있어 이메일, 전자결재는 그룹웨어에서 이용하도록 되어있었다.
그래서 우리서비스와 그룹웨어 서비스의 회원정보가 일치해야했기 때문에 API 로 연동하였고 우리서비스가 그룹웨어 서비스의 API 를 호출하도록 하였는데 이 과정에서 양 서비스간 싱크가 맞지 않는 상황에 대한 고민과 중간에 실패했을때에 대한 롤백 처리에 대해 많은 고민이 필요했다.
결과적으로 총 3개의 서비스가 연동되어 있는 셈이다. 외부업체에서 개발한 B2C 서비스 - 기업용SNS - 그룹웨어 .
3개의 서비스가 모두 서버, DB 가 달랐기 때문에 싱크, 롤백등에 대한 처리에 대해 노력과 고민이 필요했다.
5. DB, 쿼리, 커넥션풀 튜닝
DB 서버 CPU 가 높은 수치를 보일 때가 잦았고 종종 dead lock 도 보여서 이대로 두면 안되겠다는 생각이 들었다.
하여 Maria DB 의 파라미터 그룹내 wait_timeout, idle_timeout, connection_timeout 등 각 파라미터 값을 튜닝했고,
1초 이상 걸리는 모든 쿼리의 로그를 기록하여 모조리 쿼리를 튜닝하였다.
또한 HikaiCp 의 MaxLifeTime, maximul pool size 등을 튜닝하였다.
결과적으로 DB 서버의 CPU 가 피크타임인 저녁6시에도 안정적인 모습을 보여주었고 쿼리속도가 많이 빨라졌기에 어플리케이션 로딩속도도 현저히 줄어들었다.
6. 포인트 시스템 및 포인트상점 추가
B2C 서비스가 됨에 따라 사용자의 활동에 따라 포인트를 적립하고 포인트로 커피와 빵을 사먹을 수 있도록 하는 기능을 추가하게 되었다.
포인트는 회사의 부채, 자산이기 때문에 설계부터 꼼꼼하게 이뤄질 필요가 있었기에 신중을 기해 설계를 하였다.
이 글 을 많이 참고하여 개발하였다.
어려웠던 점은 활동을 해서 포인트를 적립하여 그 포인트로 빵을 사먹은 후, 활동을 삭제했을때 . 즉 어뷰징에 대한 처리였다.
이 부분은 모든회원은 기본적으로 0원짜리 부채코인을 갖도록 하고 활동내역을 삭제했을때 부채코인에서 차감키로 하였다.