Notice
Recent Posts
Recent Comments
Link
«   2024/09   »
일 월 화 수 목 금 토
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
Tags
more
Archives
Today
Total
관리 메뉴

DevYGwan

다우 인턴 회고 본문

daily

다우 인턴 회고

YGwan 2023. 9. 23. 20:51

 

2023.07.03~2023.08.11 약 한 달 반 동안의 다우 인턴 생활이 끝났다. 너무 짧아서 아쉬우면서도 많은 것을 배울 수 있었던 1달 반이었던 것 같다. 처음에는 단순문서 작업과 단순 일 처리만 할 줄 알고 걱정을 많이 했는데 그래도 실제 업무를 경험하게 해 주셔서 좋았던 것 같다. 생각해 보면 팀장님하고 사수님들이 배려를 많이 해준 것 같다.

회사 생활하면서 나의 첫 회사이기 때문에 많은 걱정과 두려움도 있었지만 기대감도 있었다. "내가 주어진 일을 잘할 수 있을까?", "내가 회사 생활을 잘 적응할 수 있을까?" 하는 걱정이 컸다. 더군다나 내가 결국 이 회사를 지원하게 된다면 내가 생활한 1달 반이라는 시간 동안 어떻게 했는지가 많은 영향을 미칠 것 같다는 생각도 들어 더 걱정됐던 것 같다. 하지만 이러한 도전을 통해 내가 한층 더 성장할 수 있을 것이라는 확신이 들어 기대감이 더 컸던 것 같다. 실제로도 지금 생각해 보면 내가 회사 생활을 하기 전과 후를 생각해 보면 내 실력이 많이 향상되었다는 느낌을 강하게 받는다. 이번을 계기로 단순히 공부해서 얻는 지식보다 회사에 다니면서 배울 수 있는 지식이 훨씬 많을 것으로 생각해 빨리 회사에 들어가 성장하고 싶다는 욕구가 생겼다.

 

 

나의 팀

 

나의 팀은 다우 기술의 차세대 비즈 개발팀에 배정받았다. 이 부서의 주 서비스는 B2B 서비스로 메세징 서비스와 쿠폰 서비스를 담당하고 있다. 이 중 나는 메세징 서비스의 기능 중 하나를 개발하는 과제를 받았다. 다우 기술을 보며 느낀 것은 확실히 회사는 많은 일들을 분업화하고 있다는 생각이 들었다. 팀마다 주로 개발하는 특정 기능이 있지만 결국 해당 서비스를 배포 및 런칭하려면 여러 팀과의 소통은 필수적이라는 것을 느꼈다. 확실히 개발자한테는 개발 능력만큼 중요한 것이 소통 능력이라는 생각이 들었다. 또한 저는 이러한 서비스를 사용해 본 적만 있지 개발해 본 적은 없어서 간단하게 과제를 받기 전 두 서비스의 전반적인 흐름을 팀장님께서 알려주셨는데, 내부 구조는 정말 복잡하게 이루어지고 있다는 것을 알게 되었다. 이러한 것을 듣고 나니 빨리 일하고 싶다는 생각이 들었다. 우리 팀의 주요 기술 스택은 5가지로 아래와 같다.

  • springboot
  • Mybatis
  • Dbeaver
  • Oracle db
  • Html & css & js
  • thymeleaf

(물론 제가 경험한 기술 스택이 이정도지 실제로는 더 많다.)

 

 

나의 과제

제가 부여 받은 과제는 영업관리시스템의 프로필 삭제 기능이었다. 과제 주 내용은 다음과 같다.

 

 

  • 회사 사내 프로그램인 영업관리시스템에서 프로필 삭제 기능 구현
  • 삭제 시 관련된 DB 내용 전체 삭제 ( DB 간의 연관 관계는 매핑되어 있지 않음)
  • 최종 삭제 후 전체 총괄 서버에도 요청을 보내 해당 내용 삭제

 

삭제 기능을 수행하는 거라 부담이 좀 되었지만, 실제 업무를 하게 되어 기대감이 더 컸던 것 같다. 저는 위의 설명한 기술 스택 중 백엔드 개발은 Springboot로 db 접근 기술은 mybatis, db는 oracle을 사용했다. springboot는 이전에도 사용해 봐서 부담이 적었지만 mybatis는 처음이라 걱정했다. 하지만 이전에 jdbc과 sql을 공부하면서 sql이 좀 익숙해서 금방 적응할 수 있었다. 과제를 진행하면서 든 생각이 만약 spring JPA만 공부한 사람이 이 과제를 접했으면 얼마나 당황했을까 하는 생각이 많이 들었다. mybatis는 실제로 sql을 사용해서 개발하는 것이기 때문이다. 나랑 같이 공부하는 형이 항상 말해준 말이 있다. "요즘 백엔드 개발자면서 JPA부터 시작해서 sql을 못 짜는 백엔드 개발자가 진짜 많대…. 그런 건 진짜 별로라고 생각해"라는 말이 떠올랐다. 실제 우리 회사는 아직 JPA를 잘 사용하지 않는다고 했다. 만약 JPA부터 공부를 한 개발자면 과연 JPA를 사용하지 못하는 상황을 잘 헤쳐 나갈 수 있을까…? 이번을 계기로 나는 기술에 의존하지 않는 개발자가 되는 것이 진정한 개발자라는 생각이 들었다. 내가 회사에 다니게 되면 해당 회사가 어떤 기술을 쓰는지 정확하게 알지 못하기 때문에 만약 기술에 의존하게 된다면 해당 기술을 쓰지 않는 회사에 들어갔을 때 문제가 발생할 것이라고 생각한다. 또한 그러한 개발자의 한계는 분명 존재한다고 생각한다. 따라서 이번 기회로 기본이 얼마나 중요한지에 대해 고찰을 하게 된 계기가 되었던 것 같다.

 

 

과제하면서 고민했던 점 

내가 과제를 하면서 고민했던 점은 다음과 같다.

 

  • 왜 DB간의 연관 관계를 매핑하지 않았을까?
  • 쿼리 성능을 어떻게하면 더 좋게 할 수 있을까?
  • 로컬 system DB에서 삭제 후 중앙 관리 서버 DB를 삭제할때의 트랜잭션 처리를 어떻게 해야될까?

 


왜 DB 간의 연관 관계를 매핑하지 않았을까?

 

삭제 기능을 구현하다 보니 이러한 의문이 생겼습니다. 제가 여태까지 한 프로젝트는 항상 DB 간의 관계가 있다면 관계 매핑을 해줬습니다. OneToOne, oneToMany, ManyToOne, ManyToMany 같은 어노테이션으로 관계를 설정해 주었습니다. 이는 관계형 DB를 사용해본 경험이 있는 사람이면 다 한 번쯤은 경험했을 것이라고 생각합니다. 하지만 내가 처음 이 개발 코드를 받았을 때는 DB 간의 관계 매핑이 하나도 되어 있지 않았습니다. 그래서 왜 이렇게 코드가 작성되어 있을까 라는 생각이 들어 고민했습니다. 이에 대한 답을 알아보니 DB 간의 관계가 복잡할 시 실제로 매핑 관계를 설정 안 하는 경우가 많다는 답변을 받았습니다. 해당 페이지는 실제 사용자가 사용하는 페이지가 아니라 개발자가 사용하는 페이지기 때문에 설정 안 하는 게 테스트할 때나 성능상 좋을 수 있기 때문입니다. 실제로 DB 삭제나 수정할 때의 경우 연관관계가 매핑되어 있으면 테스트할 때 연관관계를 고려해야 하기 때문에 복잡합니다. 하지만 관계가 되어있지 않다면 바로 바로 삭제 및 수정이 가능합니다. 하지만, 이 경우 DB 간의 무결성 조건에 위배가 될 수 있다는 문제가 있기 때문에 실제 사용자가 사용하는 페이지의 DB의 경우 DB 간의 연관관계가 되도록이면 매핑되어 있어야 관리가 편합니다. 제가 작업하는 환경은 실제 사용자가 사용하는 페이지가 아닌 개발자가 모니터링하는 개발자 관련 페이지기 때문에 이렇게 관리합니다.

 


쿼리 성능을 어떻게하면 더 좋게 할 수 있을까?

 

삭제를 할때 테이블 간 관계 매핑이 되어 있지 않기 때문에 데이터 간 무결성을 보장하기 위해 키와 관련된 모든 데이터를 삭제해야 했습니다. 키와 관련된 데이터는 한 테이블에만 있는 것이 아니라 여러 테이블에 관련 데이터들이 있었고 이를 다 다 조회 후 삭제해야 했습니다. 이 과정에서 불필요한 쿼리 문이 많이 발생했습니다.

예를 들어 A 테이블에 키 값이 있고 B 테이블에 해당 키에 따른 NUM이 있고 C 테이블에 해당 NUM에 대한 자료와 함께 BUTTON이 있고 마지막으로 D에는 BUTTON에 따른 데이터가 있을때 이를 도식화하면

이런 테이블 형태로 데이터가 이루어져 있습니다. 이때 KEY에 따른 NUM, BUTTON 수가 여러개라면 처음에는 삭제를

 

  1. A 테이블에서 KEY에 따른 NUM을 다 조회
  2. B에서 NUM에 따른 BUTTON을 각각 다 조회
  3. C에서 조회된 BUTTON에 따른 값 각각 삭제 (2에서 조회된 BUTTON의 갯수만큼 SQL문 발생)
  4. B에서 조회된 NUM에 따른 값 각각 삭제 (1에서 조회된 NUM의 갯수만큼 SQL문 발생)
  5. A에서 조회된 KEY에 따른 값 삭제

 

이런식으로 로직을 구성했습니다. 그러다보니 NUM의 갯수에 따라 C 테이블에 삭제 쿼리가 나가 너무 많은 쿼리가 발생하는 문제를 확인했습니다. 따라서 이러한 성능 문제를 해결하기 위해 

 

  1. A테이블에서 KEY에 따른 NUM을 다 조회 후 리스트로 생성
  2. B 테이블에서 IN문을 통해 조회된 NUM 값들에 해당하는 BUTTON 데이터 조회 후 리스트로 생성
  3. C 테이블에서 IN문을 통해 조회된 BUTTON에 값들에 해당하는 데이터 삭제
  4. B 테이블에서 IN문을 통해 조회된 NUM 값들에 해당하는 데이터 삭제
  5. A 테이블에서 KEY값에 따른 값 삭제

이런식으로 구현하니 불필요한 쿼리를 깔끔하게 IN문을 통해 제거할 수 있었습니다. 

 


로컬 system DB에서 삭제 후 중앙 관리 서버 DB를 삭제할 때의 트랜잭션 처리를 어떻게 해야 될까?

 

이 경우 두개의 서버가 다르기 때문에 한 트랜잭션으로 처리를 할 수 없습니다. 실제 다중 서버를 활용하는 MSA 환경에서 이러한 문제가 자주 발생합니다. 트랜잭션은 한 DB에서는 관리가 되지만 여러 DB인 경우에는 관리가 되지 않기 때문입니다. 제가 처한 문제는 발신프로필을 삭제할때 한번에 최대 5개까지 삭제를 할 수 있는대 발신프로필 관리를 로컬 시스템 DB 서버, 중앙 관리 시스템 서버, 카카오 발신 프로필 관리 시스템 DB 서버 이렇게 3개의 서버에서 관리하고 있었습니다. 즉, 삭제 순서는 아래와 같은 순서대로 삭제가 진행됩니다. 

 

로컬 DB에서 삭제 -> 중앙 관리 서버에서 삭제-> 카카오 발신프로필 관리 시스템 서버에서 삭제

 

또한 삭제는 한 번에 최대 5개까지 삭제가 가능한 식으로 구현해야 했습니다. 처음에는 이 5개의 삭제 로직을 한 트랜잭션으로 묶어서 처리했는데 이렇게 하니 문제가 발생했습니다. 예를 들어 1,2,3 번째 키까지 삭제가 완료된 상태에서 4번째 키를 삭제하려고 할때, 4번째 키의 삭제시 문제가 발생하면 로컬 DB는 한 트랜잭션으로 묶여있기 때문에 정상적으로 이전 작업까지 백업이 되지만 다른 DB 서버의 경우 트랜잭션으로 묶을 수 없기 때문에 이미 삭제가 완료된 것을 백업할 수 있는 방법이 없었습니다. 따라서 이러한 문제를 해결하기 위해 고민해본 결과 해당 작업을 한 트랜잭션으로 묶을 순 없다고 판단하여 작업 내 키 각각당 트랜잭션으로 나누어서 처리했습니다. 이렇게 되면 중간에 작업이 실패가 되더라도 삭제가 정상적으로 처리된 것은 정상적으로 처리되어 백업되지 않고 문제가 생긴 부분만 로컬 DB에서 백업되는 식으로 작업이 처리되기 때문에 문제가 발생하지 않는다고 생각해 이렇게 처리했습니다. 이보다 더 좋은 방법이 있을 것이라고 생각하지만 그 당시에는 이렇게 처리하는 게 가장 좋을 것 같아서 이렇게 처리했습니다. 이후에 내가 경험과 실력이 더 쌓이면 이 부분을 더 보완하고 싶다는 생각도 들었습니다.

 

 

최종 회고

회사를 다니면서 위에서 말했던 것 외에도 참 많은 것을 배웠다. 사람들과 소통하는 방법, 내 생각을 조리 있게 발표하는 방법, 문제가 생겼을 때 어떻게 해결할 수 있을까 + 그렇게 했는데도 해결이 안 된다면 어떻게 사수님한테 잘 질문할 수 있을지에 대한 방법 등을 배웠다. 실제로 저는 인턴이기 때문에 작업 권한이 그리 많지 않았다. DB 접근할 때 계속 문제가 발생해서 계속 구글링을 해봤지만 도저히 해당 문제가 왜 생기는지 알 수가 없었다... 그래서 사수님한테 물어본 결과 DBA 쪽에서 저의 IP권한을 뚫지 않아서 생긴 문제인 것을 확인할 수 있었다. 이로 인해 허무하면서도 안 되는 것을 계속 붙잡고 있는 것보다는 열심히 해결하려고 노력했는데도 안 되는 거면 사수님한테 물어보는 것이 중요하다는 생각이 들었다. 또한 DB의 경우 매우 중요한 것이기 때문에 이렇게 관리하는 것이 보안적으로 매우 중요하다는 생각이 들었다. 회사는 확실히 보안적인 부분에 대한 신경을 많이 써야한다. 실제로 회사 작업을 하려면 여러 보안 프로그램을 깔아야하고 IP 권한 부여 등을 해야 실제 개발 코드에 접근할 수 있다. 한편으로는 회사 밖에서는 작업을 못한다라는 단점이 있지만 이는 보안상 필수적이라고 생각한다. 이러한 것도 학교에서는 경험할 수 없는 것을 경험할 수 있어서 좋았다.

또한 내가 회사 생활을 하면서 우리 회사는 TT데이라고 개발자 분들이 1년에 한 번 자유 주제로 발표하는 행사 같은 것이 있어서 해당 행사에 참여할 수 있는 기회가 생긴 적이 있다. 그래서 참여했었는데 발표하시는 분들이 참 멋있다는 생각이 들었다. 내가 공부한 것을 조리 있게 발표하는 것도 멋있었지만, 발표 주제가 대부분 회사 생활을 하면서 겪은 문제들을 해결하는 과정에서 경험한 주요한 개념등을 소개하는 것이었다. 발표 이후 질의응답 시간도 있었는데 확실히 내가 학교에서 겪은 건 아무것도 아니구나 라는 생각이 들었다. 질문 하나하나가 전문적이었고 이에 대한 답변 또한 전문적이었다. 특히 보면, 확실히 연차가 많으신 사람들의 질문은 내가 생각했던 관점이랑은 다르구나 라는 생각이 들어 나도 언젠간 저런 질문을 할 수 있는 능력 있는 개발자가 됐으면 좋겠다는 생각이 들었다.

 마지막으로 회사를 다니면서 선배 개발자 분들께서 해주신 말씀이 있다. 그중 가장 기억에 남는 것은 문제가 발생했을 때 이 문제를 해결한 것에서 끝나면 아무것도 너에게 도움이 안된다는 말씀이었다. 생각해보면 나는 문제가 발생했을때 해당 오류 코드를 구글링해 여러번 시도해보고 문제가 해결되면 그냥 넘어가는 경우가 대부분이었던 것 같다. 이는 단순히 문제를 해결해야겠다는 초점에만 몰두한 것이지 왜 이러한 문제가 발생했고 어떻게 이러한 문제를 해결했는지에 대한 고민을 덜했던것 같다. 이제부터라도 문제가 발생했을때 좀 더 시간을 할애해 이러한 관점으로 접근해야겟다는 생각이 들었다. 참 1달 반이라는 짧은 시간 동안 많은 것을 배운 것 같다는 생각이 든다.

 

 

이렇게 내 첫 회사의 회고 글을 끝내고 이제부터는 더 열심히 해서 인턴의 회고 글이 아닌 실제 회사 직원으로서의 회고글을 남겨야겠다는 목표가 생겼다. 인턴의 짧은 경험도 참 많은 것을 경험하게 해 줬는데 실제 회사 직원으로 오랜 기간 일하다 보면 또 얼마나 나에게 많은 것을 알려줄지 벌써부터 기대가 된다.

 

 

저작자표시