[Intern] 지난 1년간 경험 되돌아보기

오늘은 1년동안 인턴을 하면서 배우고 겪은 경험들을 작성하려고 합니다.
개발자로써 사람들과 협업하는 방법, 개발하는 태도 등에 대해 배웠고, 사내 서비스 기획 단계부터 참여하여 MVP를 거쳐 production까지의 경험들을 정리해보려고 합니다.

[근데 왜 1년동안이나 다녔냐구요...?]
처음에는 4학년 1학기 여름방학 현장실습이었고, 회사측 권유로 2학기, 2학기 겨울방학까지 다니게 되었어요.
그러다 사내 서비스인 SIGMA 개발에 참여하게 되었고, 처음 맡은 회사 프로젝트라서 더 애정이 갔어요.

"내가 SIGMA 서비스 배포까지는, 내가 만든 프로젝트의 끝은 보겠다. 
ver2, ver3까지는 못하더라도, 내가 첫 배포 버전은 만들고 사용할 수 있도록 끝내고 갈거다"

라는 다짐이 생겼어요. 
그러다보니 시간이 길어져 회사에서 일한지 어느덧 1년이 되었네요 ㅎㅎ 
후회는 없어요. 오히려 두고 떠났다면 그런 선택을 한 자신을 후회했을 것 같아요.

1. 시키지 않아도 좋은 방법 찾아내기

🚀 제목: 서버 분리, 폴더 구조 다시 설계하기
✅ 요약
1. 운영 과정에서 Crud-server 에서 OOM(메모리 부족) 현상 발생
2. 이유는 임베딩 작업
3. 메모리를 많이 쓰는 임베딩 작업을 다른 서버로 분리하고, 폴더 구조 설계 및 프로젝트 리팩토링
기존 서버 구조: Client ➡️ Public-server ➡️ Crud-server ➡️ Database
새로 분리한 서버: Client ➡️ main-server ➡️ Database // Embedding-server

1️⃣ 문제 발견 및 원인 분석
서버 운영 중 crud-server에서 임베딩 작업 중 메모리 부족 현상이 발생하였다.
이로 인해 DB와 통신하는 crud-server에서 다른 API 처리 작업까지 모두 에러가 발생했다.
또한 임베딩 시 많은 자원을 잡아먹기에 에러가 발생하지 않더라도 API 처리에 효율적이지 못하였다.

⬆️ 문제 발생 및 원인 추적

2️⃣ 의견 제안
"임베딩 작업이 메모리를 많이 사용한다면 인스턴스를 따로 분리해야되지 않나?" 라는 생각이 들었다.
마침 팀 내에서 레포를 합치고, 서버도 합치면 좋을 것 같다는 의견이 있었다.
이 때 도메인형 폴더 구조가 떠올랐다. 개인 프로젝트에서 DDD 보다는 완화시킨 도메인형 폴더 구조를 채택하여 되게 효율적이고, 잘 정리된 느낌을 받았었다.
이를 활용해 폴더 구조를 바꾸자는 제안을 하였다. 이대로 폴더 구조를 가져간다면, 업무 성격별로 폴더를 나눠 업무 분담에도 효율적이고, 배포 단위도 분리하기에 편리하다.

⬆️ 도메인형 폴더 구조 제안

3️⃣ 의견 수용
이후 회의를 진행하였고, 내 제안이 받아들여졌다.
물론 장점만 있는 것은 아니었다. 기존 폴더 구조와 많은 것이 달라지고, 각 파일 위치나 애매한 것들도 많았기에 시간이 더 오래 걸린다는 단점이 있었다.
하지만 당시 MVP 개발을 끝낸 이후였고, 테스트 전 단계라서 추가 구현보다는 수정만 하는 상황이었다.
덕분에 시간이 오래 걸린다는 단점이 있음에도, 많은 시간을 리팩토링에 쏟을 수 있어 제안을 받아들여졌다.
또한 지금 안 바꾸면, 나중에 더 큰 시간을 쓰면서 정리해야할지도 모른다고 생각했었다...
생각만 했다😭....

⬆️ 회의 진행 및 의견 수용 (링크는 이모티콘으로 가렸습니다)

2. 갑작스런 문제 대처하고 예방까지

🚀 제목: 무한 루프 트랜잭션, idle in transaction timeout 설정하기
✅ 요약
1. 운영 DB에 어떤 트랜잭션이 무한 루프에 빠져 락을 잡고 있음을 확인
2. 비정상적 연결 종료로 인해 무한 루프에 빠져 강제 종료하더라도 동일 현상 재발생
3. 발생한 문제를 분석하고, 해결 과정과 근거를 제시하고, 트랜잭션 타임아웃 설정하여 추후 발생 예방

1️⃣ 문제 발견 및 원인 분석
운영 중인 데이터베이스에서 특정 트랜잭션이 계속해서 락을 점유하고, 강제 종료해도 다시 켜지는 현상을 발견하였다. 확인한 결과 "idle in transaction" 상태의 세션이 테이블 락을 점유하고 있었고, 이로 인해 세션을 강제 종료 하더라도 다시 켜지는 무한 루프에 빠져있었다.

⬆️ 문제 발생 (중요 로그는 이모티콘으로 가렸습니다.)

2️⃣ 해결 방법 조사
일단 현재 문제가 무엇인지, 어떤 현상인지에 대해서 정확하게 파악하였다. 강제 종료를 해도 스스로 다시 시작된다는 것을 확인한 뒤 왜 이런 문제가 발생했는지, 이런 문제에 대해 공식 문서에 나와있는지 등을 조사하였다.
문제 원인은 idle in transaction 상태가 유지되는 것으로 해결 방법으로는 idle transaction session timeout 설정을 하는 것이다.
이를 적용하면 대기 중인 트랜잭션은 1분이 지나면 DB측에서 자동으로 삭제될 것이다.

⬆️ 문제 분석 및 해결 방법 조사 (링크는 이모티콘으로 가렸습니다.)

3️⃣ 해결 방법 적용
추후 같은 문제를 막기 위해 postgresql idle_in_transaction_timeout 값을 1min으로 설정하였고, 기존 발생하던 트랜잭션이 삭제되는 것까지 확인하였다.
간단한 문제였지만, 이를 알게 되고 설정까지 해볼 수 있는 기회여서 좋았다.
이런 뜬금없는 문제들이 더 많이 발생했으면 좋겠다.
그 문제를 해결할 기회까지 오면 더더더 좋을 것 같다.🙂
미친놈 같으려나....

⬆️ 해결 방법 적용

3. 부족한 부분 찾아서 도입하기

🚀 제목: 우리 이거 없지 않나요? proto-validation 방법 찾기
✅ 요약
1. 현재 proto-validation 체크 의도대로 되지 않음을 확인
2. 현재 사용 중인 proto3에서는 optional 키워드가 동작하지 않는 legacy임을 발견
3. optional이 동작하지 않는 이유와 validation 방법 등을 찾아 공유 및 도입 제안

1️⃣ 문제 발견
gRPC를 사용하는 프로젝트 진행 중에 proto에서 validation 체크가 되지 않는 것을 발견하였다.
테스트 중에 필수 값이 비어있는 Request도 Service단까지 전파되는 것을 확인하였다.
"validation 체크가 필요하지 않나?" 라는 의문이 생겼고, 다른 분들은 어떻게 하고 계시는지 물었다.

⬆️ validation 체크에 대해 의논된 게 있는지 확인

2️⃣ 원인 분석 및 해결 방법 공유
validation에 대해 논의가 되었지만, 결정은 되지 않은 상태였다.
현재 환경에서 optional이 동작하지 않는 이유, 사용할 수 있는 validation 방법들을 조사해 제안했다.
타입 검증을 수행할 수 있는 라이브러리 도입을 제시했고, 공식 문서와 사례를 첨부하였다.

⬆️ validation 도입 제시하기

3️⃣ 제안 사항 적용
제안 내용을 팀 회의에서 공유했고, 논의 끝에 해당 방법이 적합하다는 결론에 도달했다.
이후 라이브러리 테스트를 진행해 정상 동작을 확인했고, validation을 프로젝트에 도입하였다.
내가 제안한 것이지만...다른 업무 때문에 다윤님께서 맡아서 테스트 해주셨다. 감사합니다. 👍

⬆️ 해결 방법 적용

4. 마감일까지 시간이 부족한 경우

🚀 제목: 마감일까지 시간이 부족해? 하루는 24시간이야
✅ 요약
1. 프로젝트 마감일이 다가왔지만, 아직 구현할 기능들이 많이 남아있는 상황
2. 팀원끼리 작업 현황을 알 수 있도록 공유
3. 야근, 주말 작업하면서 마감일까지 마무리 성공

1️⃣ 문제 발생
프로젝트 마감일이 다가왔지만 아직 구현해야 할 기능들이 상당 부분 남아있는 상황이었다.
특히 여러 명이 동시에 개발을 하다보니 어떤 기능이 완료되었고, 어떤 기능이 진행 중인지가 명확하지 않아 효율적인 작업 진행이 어려웠다.
이런 상황에서 남은 시간을 최대한 효율적으로 배분하고, 팀 전체가 진행 현황을 공유하는 것이 시급하다고 생각했다.

⬆️ 마감일이 얼마 남지 않았다...

2️⃣ 진행 현황 공유
누가 무엇을 하고 있는지에 대해 명확히 하고, 담당자가 누군인지, 진행 중인 작업인지 확인을 위해 진행 현황을 공유하였다. 기존에는 코드 리뷰로 하면서 팀원의 풀리퀘 하나하나 살펴봤지만, 이 때는 빠른 개발을 위해 코드 리뷰를 살짝 뒤로 미루고, 리뷰가 필요할 것 같은 부분만 리뷰를 개인이 요청하도록 하였다.

⬆️ 진행 현황 공유

3️⃣ 성공적 마무리
정리된 내용을 기반으로 작업 진행 상황을 알 수 있었고, 각자 맡은 작업에 집중하였다.
내 담당 기능을 완수하기 위해 기존 퇴근 시간을 넘겨가며 개발을 이어갔고, 그 때부터 꾸준하게 변경 사항을 기록하고 공유하고 있다.
시간과 리소스가 한정된 상황이었지만, 체계적인 진행 현황 관리와 팀원들의 책임감 있는 마무리 덕분에 성공적으로 마무리할 수 있었다.🎉

⬆️ 성공적 마무리

5. 직접 사용자 받아보기

🚀 제목: 야야야, 이거 내가 만들었다니까?
✅ 요약
1. 국민대 잡페어 행사에 참여
2. 후배들, 친구들에게 시연하기
3. 내가 만든 서비스 뿌듯해하기

1️⃣ 잡페어 행사 참여
위 경험들을 하면서 MVP 단계를 지나 프로덕션 개발을 진행 중이었다. 도중에 국민대 잡페어 행사에 참여하게 되었고, 행사에는 사수분과 함께 내가 참여하게 되었다. 행사 참여를 위해 환경 세팅과 데이터 준비도 하였고, 시연 과정도 준비하면서 준비하였다.

2️⃣ 시연하기
부스를 열어 시연을 하였다.
"시연 전에 에러가 발생하진 않을까, 기능이 제대로 동작하지 않으면 어떡하지?" 등 많은 걱정이 있었지만,
다행히도 별 일 없이 성공적으로 마칠 수 있었다.

3️⃣ 뿌듯해하기
이전까지는 내가 서비스를 만들거나 회사에서 서비스를 만들거나, 내가 아는 사람이 서비스를 테스트하는 걸 보았다. 행사에 참여하니 모르는 사람에게 서비스를 설명하고, 시연하고, 쓰게 하는 이 행위 자체가 너무 신기하고 뿌듯했다. 특히나 내가 참여한 서비스를 사람들에게 설명한다는 게 너무 좋았고, 이걸 경험할 수 있어 감사했다.

⬆️ 국민대 잡페어 행사 참여하기