데이터 엔지니어팀 OJT 후기

2021.07.12

📌 서론

데이터 엔지니어 팀에 입사한 후 수습기간 동안 OJT(On the Job Training) 프로젝트를 진행했습니다. 5개의 프로젝트를 진행했고, 라인웍스 데이터 엔지니어팀에 관심이 있으신 분들에게 3개월 동안 프로젝트를 하면서 느낀점, 배운점 등을 공유하면 좋겠다는 생각을 하게되어서 해당 글을 작성했습니다.

[진행한 프로젝트]

  • HIRA-NPS 데이터 파악
  • MIMIC-IV 데이터에서 심혈관 환자 데이터 큐레이팅
  • EXI-Catalog 구현
  • OMOP CDM으로 구성된 Synpuf5 를 사용해 CLUE Criteria 구현
  • Clinical Note 정형화

📌 수습기간

  • 기간 : 2021.03.22 ~ 2021.06.21(3개월)
  • 그룹 : Data Engineer Group

📌 수습기간 동안 느낀점

1) 데이터 관련

라인웍스는 제가 가장 좋아하는 언어인 Python, 데이터 관련 개발에 없어서는 안 되는 언어 SQL를 사용하고 있습니다. 이 두 개의 언어를 사용해 개발한다는 것은 알고 있었기 때문에 두려움이 크지 않았습니다.

하지만 “의료 데이터“는 두려움을 주기에 충분했습니다.
의료 관련 개발을 한 번도 해보지 않은 저에게 의료 데이터는 너무 어려웠습니다.
해당 값이 어떤 의미인지, 해당 칼럼은 어떤 것을 뜻하는지 이해하는 것이 너무(x100) 어려웠습니다.

[첫 번째 데이터 “HIRA-NPS”]
👉 보건의료빅데이터개방시스템 – 환자표본자료 신청안내

처음으로 제가 파악해야하는 의료 데이터는 청구명세서 데이터로 건강보험심사평가원(심평원)에서  개인 및 법인에 대한 정보를 제거하여 구성한 환자표본자료 중 전체환자데이터셋 (HIRA-NPS) 이었습니다. ‘환자표본자료 변수 설명’ 엑셀 파일을 통해 테이블에 대한 이해를 조금 쉽게 할 수 있었습니다.

  • 처음 생각 : “흐힉?! 뭐야 테이블 5개? 칼럼은 왜 이렇게 많아?!”
  • 지금 생각 : “테이블 이만큼만 있으면 너무 좋겠다…”

의료 데이터 및 용어를 처음 접하는 저에게는 이해하기 너무 어려웠습니다. 또한 데이터를 정확히 파악했는지 확인하는 과정으로 정확한 값을 추출하도록 하는 SQL 문제를 내주셨습니다.
문제가 10개였다면, 체감상 20문제였습니다.
(한 문제 = 문제이해: 1.5문제 + 문제풀이: 0.5문제)

사수님께서 문제 푸는 것보다 이해하는 것이 OJT의 목적이라는 말씀을 해주시고, 시간도 많이 주셨습니다. 그렇기 때문에 최대한 이해하기 위해 많은 시간을 쏟았고, 혼자 이해가 되지 않는 부분은 사수님에게 물어봄으로써 데이터를 파악했습니다.

[두 번째 데이터 “MIMIC-IV”]
👉 MIMIC-IV Docs

HIRA-NPS 데이터를 파악한 후, 그 다음 데이터는 EMR 데이터로 공개된 임상데이터베이스인 MIMIC-IV 를 사용하였습니다. 청구데이터에 비해서 세부적인 의료정보를 포함하고 있어서 검사결과나 판독지 등까지 범위가 넓었습니다. 테이블이 28개나 되어 봐야할 것이 많았기 때문에 OJT 첫 번째 프로젝트를 하지 않고 이 데이터를 만났다면, 아마 한 번쯤은 울지 않았을까 생각합니다.

첫 번째 프로젝트를 통해 그나마 의료 용어를 조금 이해했기 때문에 두 번째 프로젝트는 용어보다는 데이터 파악하는데 조금 더 많은 시간을 쏟을 수 있었습니다.

[세 번째 데이터 OMOP-CDM으로 구성된 “Synpuf5”]
👉 Synpuf5
👉 OMOP-CDM v5.3.1

세번째로 파악한 데이터는 여러 기관에서 동일한 방식으로 정보를 얻을 수 있도록 해주는 OMOP-CDM (표준화데이터) 으로 구성된 Synpuf5 였습니다.

프로젝트를하면 할수록 봐야 할 데이터 테이블도 많아졌지만 계속해서 데이터를 보다 보니 처음보다 이해하기 쉬워졌고, 해당 데이터를 파악하기 좋은 자료들도 팀원분들이 주셔서 훨씬 이해하기 쉬웠습니다.

아래 이미지를 통해 OMOP-CDM 의 큰 그림을 쉽게 이해할 수 있었던 것 같습니다.


출처 : https://www.ohdsi.org/

[데이터 파악할 때 좋았던 점]
의료 데이터를 파악하는 데 있어 OJT 순서가 좋았던 것 같습니다.
테이블이 상대적으로 적은 순서대로 파악을 진행할 수 있게 OJT를 만들어주신 것 같다고 느꼈습니다. 시간도 이해할 수 있을 만큼의 시간, 너무 적지도 않고 많지도 않은 시간을 주신 것 같습니다. 또한, DE(Data Engineer) 그룹의 팀원분들께 질문을 하면 충분히 이해가 될 때까지 설명을 해주셨고, 데이터 파악하기 좋은 자료 및 영상 등을 주셔서 처음 의료 데이터를 접하는 저에게는 너무 좋았습니다.

글을 쓰다 보니, “회사 내에서 쓰는 의료 용어에 대해 정리된 문서가 있다면 좋겠다”라는 생각을 가지게 되었습니다. 의료 용어에 처음인 사람의 입장에서 작성한 용어는 또 다르다고 생각하기 때문에, 시간이 된다면 제가 한번 정리해보는 것도 좋을 것 같습니다.

2) 언어 및 개발 관련

위에서도 말했듯이, 라인웍스는 제가 가장 좋아하는 언어인 Python, 데이터 관련 개발에 없어서는 안 되는 언어 SQL를 사용하고 있습니다. 개발 언어와 개발 툴은 사용하는 것은 크게 어려움은 없었습니다.

[SQL]
Python보다 SQL이 부족하다고 생각했었는데 계속해서 SQL을 쓰다 보니 SQL이 편해졌습니다. 또한, 회사 내에서 ‘SQL 스터디’를 진행했는데, 스터디를 통해 다른 사람들은 어떻게 SQL을 작성하는지 볼 수 있는 기회가 있었고, 로직에 대해 배울 점이 있는 스터디였습니다. 현재는 ‘DB Tuning’에 대해 스터디를 진행하고 있습니다.

하지만 아직까지 SQL을 능숙하게 다룬다고 생각하지는 않습니다.
SQL 문법보다는 더 좋은 구조, 로직을 짜는 생각을 꾸준히 해야 할 것 같고, 간단한 SQL 작성할 때도 더 효율적으로 작성하는 연습해야 할 것 같습니다.

[Python]
Python 개발을 할 때는 나름 잘했다고 생각합니다.
초반에 조금 어려웠던 부분은 ‘Code Convention‘이었습니다. 이때까지 해오던 저의 코드 스타일을 갑자기 다르게 하려니까 어색했습니다. 하지만 변화하는데 크게 어려운 점은 없었고, 지금은 잘 적응했다고 생각합니다.

SQLAlchemy, Pytest 부분에서 아직은 많이 부족하다고 느낍니다.
주로 SQLAlchemy를 사용하고 있는데, 예전에 다뤄보긴 했지만 능숙하게 다룰 수 있다고는 자신 있게 말하지 못하겠습니다. 그러나 계속해서 쓰다 보면 익숙해질 거라고 생각합니다!

계속해서 테스트를 하면서 개발을 하고 있었지만 Pytest는 처음 사용하다 보니 어색한 느낌이 있었습니다.

[언어 관련 및 개발 관련] 부분을 작성하기 전에는 “언어 관련해서는 어려운 점이 없고, 잘하고 있다.”라는 글을 쓰려 했는데, 쓰다 보니 아직 부족한 점이 많고 더 많이 노력해야겠다고 느끼게 되네요.🔥

[Git]
라인웍스에서는 Yona 라는 협업 개발 플랫폼을 사용하고 있으며 이를 기반으로 Git 으로 코드를 관리하고 있습니다. Git을 사용해봤기 때문에 익숙했지만, 제가 모르는 명령어들이 정말 많이 있다는 것을 느꼈고, Git은 알면 알수록 좋다는 생각을 했습니다.

Git을 쓰면서 아래와 같은 습관이 생겼는데, 좋은 습관이 생겼다고 생각합니다.

  • commit message를 작성할 때 내가 이해할 수 있도록 최대한 상세하게 작성.
  • push를 하기 전 $ git log 명령어를 통해 제대로 작성했는지 확인.
  • push를 할 때는 최대한 많이 고민.

[Criteria 구현]
Criteria 구현은 현재 회사에서 개발하고 있는 CLUE에서 원하는 환자군을 추출할 수 있도록 도와주는 기능입니다. OJT 중 가장 힘들었던 프로젝트였지만, 가장 재밌는 프로젝트였습니다.
현재 회사에서 개발 중인 프로젝트이고, 실제로 사용하고 있다니 살짝 떨리기도 하면서 설렘이 있어 좋았습니다.

프로젝트 구조를 먼저 파악 및 이해한 후 개발을 하면서 기존 코드에 에러가 발생하는 부분을 찾아냈고, 해결 방법에 대한 의견을 제시했을 때 실제 코드에 반영된다는 점이 더욱 해당 프로젝트를 재밌게 했던 것 같습니다.

[Clinical Note 정형화]
Clinical Note 정형화는 환자의 의료 기록 샘플부터 원하는 정보를 추출하여 테이블에 적재하는 프로젝트입니다. OJT 프로젝트에서 두 번째로 재밌었던 프로젝트였습니다.
ETL(Extract Transform Load)을 모두 해볼 수 있는 프로젝트였다고 생각하고, Crawling 작업을 좋아하는 제게 비슷한 느낌의 개발이었습니다. 물론 효율적인 코드, 구조로 개발을 했다고 생각하지 않습니다. 하지만 빠른 시간 내에 원하는 기능을 만들었다는 것은 스스로에게 칭찬을 해주고 싶습니다.

3) 코드 리뷰 관련

OJT 프로젝트를 진행하면서 계속해서 DE 그룹의 팀원분들께서 코드 리뷰를 해주셨습니다.
작성한 코드가 많은데도 불구하고 정말 꼼꼼히 봐주셔서 정말 감사한 마음을 갖고 있습니다.
저는 코드 리뷰를 받을 때 열린 마음으로 수용하되 조금은 비판적인 사고를 유지하려 합니다.
리뷰를 받았을 때 무조건 옳다고 생각을 하는 게 아니라 정말로 리뷰 해주신 분의 말씀이 더 좋은 코드인지 스스로도 판단해보는데, 99%는 리뷰 해주신 분의 말씀이 더 좋은 코드였습니다.
하지만 저는 계속해서 리뷰를 받았을 때 리뷰에 대해 다시 한번 생각하는 습관을 가지려고 합니다!

📌 OJT를 통해 배운점

OJT를 통해 많은 기술적, 비기술적인 부분들을 많이 배웠습니다.

1) 예상하지 못한 데이터는 내가 생각하는 것보다 훨씬 많다

대량의 데이터를 만져볼 수 있는 기회가 많지는 않았습니다. 하지만 이번 프로젝트를 진행하면서 대량의 데이터를 다루게 되었습니다. 그러다 보니 추출하려고 하는 데이터에서 예상하지 못한 데이터가 추출되는 상황이 발생했습니다. 이 점을 통해 배우게 된 것이 값을 추출한 후에는 반드시 추출된 값을 다시 확인해 보는 과정이 필요하다고 생각했습니다. DE에게 필요한 것은 ‘신뢰성’ 있는 데이터를 추출해내는 능력이라고 생각합니다. 신뢰성 있는 데이터를 추출하려면 추출된 값을 확인해 보는 과정은 필수라고 생각합니다.

2) 팀원의 코드를 읽고 빠르게 이해하는 능력이 필요하다

개발에 관한 코드를 보거나, 소통을 할 때 아는 만큼 보이거나 들린다고 생각합니다. 기존까지 팀원들이 어떤 스타일로 코드를 작성했고, 어떻게 작성해왔는지에 대한 이해가 확실히 되어야 합니다. 현재까지는 리뷰를 받는 입장이였지만, 후에 제가 리뷰를 해주는 입장이 된다면 빠르게 코드를 이해할 수 있는 능력을 길러야 한다고 생각합니다.

3) 질문을 할 때 스스로 형식을 만들자

팀원 or 사수님에게 질문을 할 때는 제 시간도 사용하는 것이지만 팀원, 사수님의 시간도 사용하는 것입니다. 그렇기 때문에 한번 질문을 할 때 빠르게 질문의 요점이 뭔지를 알아야 합니다. 질문의 요점만을 보고 답변이 오는 경우가 있을 수 있고, 질문만으로 답변이 안 될 수 있습니다. 그렇기 때문에 저는 질문을 할 때 스스로 형식을 만들어서 질문하려고 했습니다.

  • 모르는 것을 질문할 때 형식
    [어떤 것에 대한 질문인지] – [스스로 이해한 내용 설명]
  • 에러에 관련된 질문 할 때 형식
    [에러발생 상황] – [에러명] – [원인이라고 생각하는 부분] – [해결방법 제안]

개인적인 제 생각으로는 이렇게 질문했을 때 빠르게 원하는 답변을 들을 수 있었던 것 같고, 사수님도 좋아하셨던 것 같습니다.

📌 회사 문화

회사 문화&복지는 여러 가지가 있지만, 제가 3개월간 일하면서 가장 좋았던 TOP3를 말해보려고 합니다.

1) Refresh Day

‘Refresh Day (RD)’란 일을 하다 지칠 때 자신의 휴가를 쓰지 않고 쉴 수 있는 날입니다.
연차와 무관하게 월 1회가 자동 부여되고, 별도의 승인이 필요하지 않습니다.

해당 복지가 Notion 채용 페이지에 적혀있는데, 사실 들어오기 전, 이 복지는 말로만 적혀있는 줄 알았습니다. “사용하는데 눈치 보이지 않을까?”라고 생각했습니다. 하지만 직접 회사에서 일해보니, 모든 팀원들이 눈치 보지 않고 월 1회 쓰고 있었습니다.

회사에 이 문화가 정착되어 잘 실행되고 있는 복지라 생각을 했고, 저도 첫 달을 제외한 나머지 달에 RD를 사용했습니다. 이건 진짜 라인웍스만의 좋은 복지라고 생각합니다.

2) 책임 근무제

주 40시간을 근무하되 시간을 스스로 관리해 근무를 할 수 있습니다.
(단, 코어타임은 존재함 11시~17시)

스스로 시간 관리를 하는 것만 보면 좋아 보일 수 있습니다. 하지만 책임 근무제는 정말 ‘책임’을 갖고 근무를 해야 합니다. 모든 일의 결과는 그 사람한테 달려있다고 생각하기 때문에 어떻게 보면 부담이 될 수 있습니다.

BUT! 책임감 갖는 것을 즐기는(?) 저에게는 좋은 영향을 미치는 것 같습니다.
누구를 탓할 수 없는 상황이기 때문에 제 스스로가 결국 열심히 하게 되고, 일에 대해 기한을 주되 기한 내에서 언제 어떻게 작업을 하는 것은 스스로가 만들기 때문에 일정 관리하는 능력도 올라가는 것 같아 좋습니다.

3) 수평적 조직 구조

인턴할 때도 수평적 조직 구조인 곳에서 일을 했고, 그 문화가 너무 좋아 수평적인 구조를 갖는 회사에서 일하고 싶다는 생각을 했습니다. 수직적, 수평적 조직 구조 각각의 장단점이 있겠지만 수평적 조직 구조에서 가장 좋은 것은 존중받는 느낌을 받는다는 것입니다. 또한 아직 제 머릿속에서 이름과 얼굴이 매칭이 되지 않는 분들이 계시지만, 회사 내에서 모두 이름으로 “OO님~”호칭을 사용하다 보니 이름도 알게 돼서 좋은 것 같습니다.

Default) 유머 왕 대표님

ㅇㄱㄹㅇ ㅂㅂㅂㄱ
회사 채용 페이지를 보면 아래와 같은 문구가 있는데 괜히 적어 놓은 게 아니라고 생각했습니다. 회사에서 저와 같이 생각하는 사람은 최소 3명 이상일 것이라고 생각합니다.
(회사 인원 : 30명 이상)

https://images.velog.io/images/insutance/post/24d24155-0b77-483f-bb2d-46ee2510b71e/image.png
출처 : linewalks notion 채용 페이지

Insu Choi

Data Engineer

Insu Choi