아이비즈 기업협업 후기

📌 들어가기 전에

위코드 부트캠프 마지막 과정인 기업협업이 끝났다. 약 한 달간 (주)아이비즈에 인턴으로 경험을 쌓을 수 있었다. 기업협업 과정을 대략적으로 소개하고 공유하고자 한다.

📌 아이비즈는 어떤 회사?

아이비즈는 여러 솔루션을 만드는 업체이다. 특히 Blackboard라는 학사 정보 관리 시스템을 제공하는 글로벌 기업의 한국 파트너사이다.

구체적으로 아이비즈 내부에 몇 분의 개발자가 계신지는 모르겠지만, 우리가 기업협업에 참여해서 실질적으로 만난 개발자는 한 분이었다.

📌 대략적인 프로젝트 소개

첫 날에 담당자분께서 전반적인 프로젝트의 구조를 설명해주셨다. 실제 대학교의 DB와 블랙보드 서버의 중간에서 특정 데이터를 처리하는 로직을 가지고 있는 미들웨어를 구현한 것이었다.(기업의 정보이다 보니 자세한 설명은 생략) 우리가 처음부터 개발해야되는 상황은 아니었다. 이미 앞서 다녀간 3개의 기수에서 개발을 어느정도 진행한 상황이었다. 담당자분께서 우리에게 주신 임무는 transaction과 store procedure를 사용해서 개발되어 있는 기능에 조금 더 안정성을 높히고자 했다.

📌 개발 환경의 중요성을 깨닫다...

현재 블랙보드 고객(대학교)의 학사 정보 db는 오라클을 사용하고 있기 때문에, 오라클 db와 통신을 할 수 있어야 했다. 노드에서 oracleDB 라는 외부 라이브러리를 사용해서 학사 정보 db에 접근을 하는 구조였다.
그런데 문제는 맥북 m1에서는 oracle을 사용할 수가 없었다. oracle에서 아직 m1을 지원해주지 않았으며, m1 환경이라서 부트캠프나 도커로도 오라클 db 사용이 불가능했다. 프로젝트 레포를 클론 받고 npm install에서부터 에러가 발생했다. 앞의 기수에서는 어떻게 개발 환경을 세팅했는지 모르겠지만, 결국은 AWS cloud9으로 개발환경을 세팅했다. amazon linux2 ec2를 생성하고 ec2에 oracle-clinet를 설치하고 npm install을 성공시키기까지 약 3일을 삽질을 했다. 패키지들을 겨우 설치하고, 코드들을 들여다봤다. 그리고 우리는 담당자와 대화하여 프로젝트의 목표를 바꾸기를 요청했다.

📌 왜 목표를 수정했는가?

우리가 오기 전에 3개의 팀이 협업을 하고 갔다. 그 분들은 python을 중점적으로 사용하신 분들이었다. 그래서 그런지 모르겠지만, 변수명, 프로젝트 구조, 등등.. 일반적인 자바스크립트 및 express 컨벤션이 안 지켜지고 있는 코드들이 너무 많았다. 동작하지 않고, 사용하지 않는 코드들도 많았다. 그러다보니 새로운 기능을 개발은 커녕, 코드를 파악하는 것조차 어려움이 많았다. 개인적으로 새로운 기능을 추가하는 것도 좋지만 멀리 본다면 코드들을 다듬고 정리하는 것이 더 유의미하겠다는 판단을 내렸다. 담당자분께 현재의 상황을 자세히 설명을 드렸다. 담당자분께서도 좋은 방향이라고 동의해주셨고, 새로운 목표를 잡았다. 아래의 3개를 주요 목표로 삼아서 프로젝트를 진행했다.

수정된 목표

1. 지금 개발되어 있는 기능을 제대로 동작하게 한다.
2. 개발 확장 및 수정이 용이하게 한다.
3. 다른 팀이 오더라도 프로젝트를 빠르게 파악할 수 있도록 문서를 남긴다.

📌 그래서 무엇을 했나?

1. 알아보기 힘든 변수명, 함수명을 최대한 의미 있게 변경하기.
2. 프로젝트 구조 개선
3. 일반적인 JS 및 express 컨벤션에 맞지 않는 코드들을 수정
4. 동작하지 않고, 아무 의미 없는 코드들을 삭제
5. service, controller 단에서 이루어지던 reqeust body의 유효성 검사 로직을 미들웨어로 분리
6. JWT 관련 코드들을 모듈화해서 분리
7. 백엔드와 프론트엔드의 성공적인 연동
8. 개발 문서화

📌 프로젝트를 통해 얻은 것

지금까지 내가 아닌 다른 누군가가 써놓은 코드를 수정해볼 기회가 많이 없었다. 프로젝트 구조를 짜고, 설계 과정에 참여하고 의견을 냈다. 백지에서부터 무언가를 시작할 기회가 압도적으로 많았다.

하지만 이번에는 달랐다. 누군가 열심히 써놓은 코드를 접할 기회가 생겼다. 다른 사람이 써놓은 코드를 보면서 이 코드가 무슨 의도로 쓰였을까, 이건 더 깔끔하고 읽기 좋게 바꿀 수 없을까? 라는 고민을 할 수 있는 기회를 얻었다. 처음에는 이렇게 생각하기가 쉽지 않았다. 코드 하나를 잘 못 건드리면 무언가 와장창 무너져내릴 것 같았고, 조심스러웠다. 그렇기 때문에 최대한 코드를 잘 이해하려고 애썼다. 시키지도 않은 플로우 차트를 API별로 그려보기도 했다. 동작하지 않는 코드들을 실컷 디버깅했다.

딱히 무언가를 새로 개발한 것은 없다고 생각한다. 하지만 유지/보수 또한 개발자가 해야할 일이고, 새로 무언가를 개발하는 것보다 어쩌면 더 중요한 덕목이 아닐까라는 생각도 조심스럽게 해봤다. 덕분에 좋은 경험을 할 수 있었다.

🖍 기업의 비즈니스 로직이 노출될 수 있어서 차트 이미지를 블러처리 하였습니다.

📌 잘한 점

① 문서화

새로운 기능 개발에 집착하지 않고, 더 길게 보고 다음에 올 누군가를 위해서 코드를 다듬고 개발 문서를 남겼다는 사실 자체가 개인적으로 뿌듯하다. 최대한 좋은 문서를 남겨서, 다음에 오게 될 개발자가 최대한 빠르게 코드를 이해하고 시간을 아낄 수 있도록 노력했다. 불필요한 삽질은 막을 수 있도록 문서에 남기고, 파편화 되어 있는 자료들을 취합하고 첨부했다.

② 커뮤니케이션

담당자와 커뮤니케이션이 잘 이루어졌다. 이 부분은 기업협업을 같이 나온 프론트엔드 팀원분의 덕이 크다. 협업 초기에 팀원분이 먼저 담당자분께 적극적으로 질문하고, 미팅을 요구했다. 이런 환경 덕분에 아이스 브레이킹이 빠르게 잘 이루어졌다. 나 역시도 내가 이해하고 있는 부분과 이해하지 못한 부분을 정확하게 설명을 드렸다. 이 과정에서 내가 이해한 것과 요구사항의 간극을 많이 줄이고, 결과적으로 담당자 분과 팀 전체의 분위기도 상당히 좋았고, 서로 만족할만한 마무리를 할 수 있었다.

📌 아쉬운 점

① 테스트 코드의 부재

이 부분이 상당히 맘에 걸린다. 테스트 코드의 필요성을 알고는 있었다. 하지만 몸소 느낄 수는 없었다. 테스트 코드를 쓰면 내 코드에 자신감이 붙는다는 말을 들은 적이 있다. 이번 프로젝트에서 프론트와 연동하는 부분이나, 다른 팀원이 이거 안되는데요? 라고 물을 때 자신있게 내 코드는 문제 없다라고 할만한 근거가 없었다. 아 이래서 테스트 코드를 짜야하는구나 라고 몸소 체험할 수 있었다. 근거가 없다보니 주저하게 되고, 내 코드에 대한 자신감이 떨어지더라... 테스트 코드의 중요성을 다시 한 번 깨달았고, TDD에 관해서도 공부를 해봐야겠다.

② 에러 객체 미구현

에러에 관련된 코드를 하나의 모듈로 빼서 따로 관리하는 기능을 추가적으로 구현해보고 싶었다. 하지만 메인 테스크와 문서화에 집중하다보니 구현하지 못했다. 개인적으로 공부해서 개인 프로젝트에서 구현을 해보고 공부해야겠다.