개요
올해 여름방학, 협업툴을 만드는 IT 기업에서 개발 인턴십을 진행하였다. 2번의 과제 수행이 주된 업무였고, 2차 과제는 인턴 팀원과 함께 수행하였다. 내가 속한 팀에서는 서버 개발이 주된 업무지만 프론트(웹)까지 개발을 하기 때문에 과제에서도 동일하게 실제 UI까지 구현을 하였다. 비록 짧게 지나갔던 2달이였지만, 배우고 느낀점을 회고록을 통해 정리하려고 한다.
표현 그리고 소통
과제는 다음과 같은 과정으로 이루어졌다.
설계
- 요구사항 분석을 바탕으로 기능을 어떻게 구현할 것인지에 대한 설계를 진행했다.
- 설계를 바탕으로 기능, DB, API 스팩, UI 설계에 대한 문서를 위키로 정리하였다.
개발
- 기능 설계를 한 바탕으로 개발을 진행하였다.
- git-flow 전략을 간단하게 도입하여, PR를 통해 멘토님들에게 코드 리뷰를 받았다.
발표
- 구현이 끝난 후, 최종 발표를 통해 개발을 진행하면서 설계, 구현 과정에서 핵심이 되었던 부분을 설명하였다. 발표가 끝난 후, 팀원분들의 질문과 피드백이 이루어졌다.
이 과정에서 코드 뿐만 아니라 글쓰기, 발표 등 많은 부분에서 생각을 표현할 일이 많았다. 또한 이러한 과정들이 팀원 모두에게 공유가 되어 소통을 하였다.
글쓰기도 코딩
인턴십을 진행하면서 글을 쓸 일이 많았다. 글쓰기는 설계 문서, 발표 자료등의 큰 부분 뿐만 아니라 매일매일 작성했던 업무일지, PR 요청과 답변 등의 작은 부분에서도 이루어졌다. 이러한 글쓰기 과정에서 자신의 생각을 논리적으로 표현하는 것이 중요하다는 것을 느꼈다. 그렇다면 논리적인 글쓰기를 어떻게 하면 할 수 있을까??? 개발자답게 글을 코드라고 생각한다면 쉽게 답을 찾을 수 있었다.
구성
코드에서도 가독성, 재사용성 등으로 인해 로직을 메서드 클래스 별로 나눈다. 또한 효율적인 구성을 위해 어떠한 아키텍쳐 패턴을 적용하기도 한다. 글쓰기도 마찬가지이다. 글을 공통된 부분별로 잘 나눠야하고, 구성의 순서 등 효율적인 글 구성을 위해 고민해야 한다.
핵심 표현
코드에서는 반복을 지양하고 코드를 간결하게 표현하려고 한다. 글쓰기도 그저 길게 쓰기보단 핵심적인 내용을 일목요연하게 잘 표현해야한다.
소통과 생산성
2차 과제는 인턴 동기분과 함께 협업을 하면서 진행했다. 회의를 통해 설계를 결정하고, 서로 구현할 부분을 나눠서 진행을 했다. 그러나 서로 소통이 되지 않은 부분들에 대해서, 의견 불일치가 생기기도 했고 이는 생산성에 저하를 일으켰다. 또한 프로젝트 초기에 멘토님들과 소통이 부족하여, 프로젝트의 방향성을 빠르게 잡지 못했다.
따라서 잦고 올바른 소통을 통해 생산성을 향상시켜야 한다. 소통 방법은 직접 말로 주고 받는 것 뿐만 아니라 문자, 문서화, 코드 리뷰 등 여러 방법이 있어 상황에 맞춰 사용하면 된다. 이 때, 의견과 생각을 미리 논리적으로 정리해서 소통하는 것이 중요하다.
기술 그리고 구현
과제를 구현한 기술 스팩은 다음과 같다.
- FrontEnd : Vue js (Vue 2)
- BackEnd : Spring boot(Kotlin)
- db 접근 기술 : MyBatis- DB : MySQL
- Message Broker : Kafka
결론적으로 이러한 기술들을 이용하여 대규모 트래픽 상황 속에서 원하는 기능(요구사항)을 구현하고자 했다.
핵심은 로직
2차 과제 진행 당시 설계적인 부분에서 많은 시간을 할애했고, 이 과정에서 로직까지 신경을 썼다. 그러나 설계 후 구현 당시에 로직에 있어서 철저한 고민을 하지 못했다. 따라서 최종 발표 당시에 특정 로직 순서로 발생할 수 있는 문제들을 피드백을 해주시면서 로직의 중요성을 크게 깨닫게 되었다.
- 과연 설계하고 구현한 flow가 어떠한 영향을 미칠 수 있을까?? 일반적인 상황이 아닌, 예외적인 상황이 일어날 수 있다를 가정하고 고민하자.
- 특히 쿼리 실행 같은 데이터 관련 작업 수행시에는 더욱 더 신경을 써야 한다.
기술은 도구다
우리가 도구의 사용법을 모르면 그 도구를 이용하여 원하는 목적을 수행할 수 없듯이, 기술도 마찬가지이다. 정확하게 그 기술 사용의 목적과 사용 방법을 알고 있어야 한다. 또한 이 기술을 이용해서 어떠한 개선이 진짜로 이루어질 수 있는지에 대한 철저한 조사가 필요하다.
- 인턴 과제를 진행하면서 주로 RDBMS를 사용했었다. RDBMS도 대규모 트래픽을 견딜 수 있으려면 설계부터 쿼리 튜닝(인덱스), 트랜잭션까지의 깊은 이해가 필요하다.
항상 검증하라
요구사항을 만족하기 위해 설계와 구현을 진행했다면, 테스트를 통해 이를 항상 검증하도록 노력해야 한다. 코드와 설계가 맞다고 생각하고 진행하지만, 실제로 테스트나 운영 환경에서는 틀릴 수 있기 때문이다. 코드는 테스트 코드, 대규모 트래픽 상황은 Stress Test를 통해 검증해야 한다. 과제 진행 당시에 검증에 관하여 신경을 많이 쓰지 못한 부분이 아쉬웠다.
DRY
반복을 되도록 피해야 한다. 최종 발표 전, 시연을 위해 샘플 데이터를 넣는 과정이 있었다. 이 과정에서도 반복적인 작업을 줄이기 위해 샘플 데이터를 넣는 코드를 작성해보는 것이 어떤가에 대한 피드백이 있었다.
- 반복은 코드 뿐만이 아니라 개발자가 수행하는 모든 업무에 포함이 된다.
