2025년 회고록

안녕하세요. 제가 2024년 부터 몸담아 2025년 말일을 마지막으로 에이아이트릭스의 여정을 마무리 하게되었습니다. 이 회사에 몸담으면서 기술적, 성품적, 경영적으로 얻은 것도 많고 해결해본 것도 많은 것 같습니다. 데이터 엔지니어로써 해결해본 문제와 앞으로는 무엇을 돌파해보며 살았으면 좋겠는지 이번 기회에 정리해보면 좋을 것 같아 아래와 같이 정리해 보았습니다.

직무 발전

데이터 엔지니어로써 일을 하면서 병원의 B2B 제품을 설치하는 일을 주로 했습니다. 그 중 데이터의 연동에서 제일 먼저 생각해야하는 데이터의 정확도, 적시성과 파이프라인의 확장성을 생각하며 일을 했고, 견고한 파이프라인 설계 능력을 갖췄다고 생각이 들었습니다.

파이프라인 설계에서 해결해본 경험들

• 데이터 연동 전략 수립 : 병원에 납품 계약을 하고 AI제품에 맞는 데이터를 뽑아야하는데 이 중 불필요한 데이터 색출하기 위한 전략을 짜야겠다 생각했고, 데이터 프로파일링 기법을 인용하여 데이터 검수 및 연동 전략을 수립하였습니다.
• 데이터 파이프라인 모듈화 전략 수립 : 데이터 파이프라인의 코드 작성에 있어 한 파일에 책임이 너무 많고 결합도가 높은 부분이 많아 이 내용을 도메인과 파이프라인으로 두가지 파트로 나누고 모듈화하여 확장성과 재활용성을 고도화 하였습니다.(참고로, airflow같은 워크플로우 툴을 사용하지 않아서 한 곳에 모여있던 두 개의 개념을 나누는 작업이 필요했습니다)
• Domain Driven Design(=DDD) 도입 : 회사 동료 분께서 확장성에 DDD를 적용해 보는 건 어떻겠냐는 말에 DDD를 공부하고 이를 적용하여 코드의 확정성과 재사용성을 높이고 유지보수 비용을 낮추는 작업을 했습니다.
• Meta Data Management System(=MDM) 초안 작성 : 병원에서 데이터를 연동 시에 마스터 데이터 변경 감지, 수행, 데이터 관계에 대한 자동 매핑 전략을 수립 하였습니다.(Data Governance에 있는 개념입니다. 저도 처음 공부 할 때는 이해 못했는데 이번 기회에 작성해보면서 왜 필요한지 이해하게 되었습니다.)
• Event Driven Architecture(=EDA) 개념 전파 : 결합도는 낮추고 응집도와 확장성을 높이는 작업을 진행하던 중 EDA 라는 개념을 알게 되어 이 부분을 적용하기 위한 데이터 모델링 및 파이프라인 적용 초안을 작성하였습니다.(kafka를 쓰는건 오버엔지니어링이라고 판단하여 손 수 만들었습니다)

기술적으로 경험해 보고 싶은 것들

데이터 파이프라인 설계, 관리, 개발 및 배포에 대한 전략을 수립하고 적용해 보면서 많은 부분을 해결했다고 생각했는데, 아직도 경험해보지 못한 부분이 많다는 생각이 들었습니다. 파이프라인 모니터링, 다른 팀들과 협업을 위한 데이터 계약 전략, 알람 시스템 도입 등 데이터 제품으로써 갖춰야할 역량에 대해 좀더 고민해보는 시간을 갖을 예정입니다. 또한, 개발 적으로 기존에는 코드에 집중했었는데, 설계가 얼마나 중요한지 깨닫는 시간이였어서, 앞으로는 아키텍처 적인 부분도 더 많이 공부해볼 예정입니다.

협업에서 경험해본 것들

2025년에는 Data Platform팀에서 일을 하게 되었는데, 회의 방법, 팀원들을 설득하는 방법에 대해 잘 모르는 부분이 많았습니다. 그래서 뭔가 팀의 방향성 자체가 삐걱되는 부분이 많아서 방향성 설정, 회의 방법에 대한 부분을 많이 생각하고 해결해 보았습니다. 그 중에 아마존의 6pagers라는 개념이 들어와 적용해보며서 느낀점이 많았습니다

6pagers를 인용한 팀 회의 방법 도입

• 아마존의 6pagers를 인용하여 팀의 회의 방법을 개선하였습니다.
• 회의 전 문서 작성
  • 먼저 모호한 부분은 문서로 작성하여 댓글로 피드백 후 회의를 잡는 방법으로 4번 이상 회의를 해야 끝내는 부분을 1~2번으로 줄여 50%이상 불필요한 시간을 없앨 수 있었습니다.
• 문서를 통한 소통
  • 프로젝트 진행 시에 재확인 해야하는 부분이나 까먹은 부분은 문서로 확인하면 되어서 팀의 커뮤니케이션 횟수를 줄일 수 있고 프로젝트 방향성 싱크도 맞출 수 있는 방법이였습니다.
• 고객 지향 소통 방식
  • 프로젝트를 진행 함에 있어 이 대화가 필요한 대화인지, 이 작업이 필요한 작업인지를 구분하기 힘든 부분이 많았습니다. 근데 답은 명확했습니다. 내가 하는 일과 작업이 고객한테 필요한 작업인가 그럼 그냥 하면 됩니다. 아니면 그냥 과감히 버렸습니다.

협업으로 경험해보고 싶은 것들

6pagers를 도입하면서 불필요한 회의나 일을 버릴 수 있었고, 소통 시간도 단축 되니 빠르게 프로젝트 진도를 뺄 수 있었습니다. 하지만, 회의 시간을 줄일지언정 남을 설득하는 스킬이 부족해 제가 원하는 방향성을 가지지 못하는 경우도 생겼습니다. 그래서 앞으로는 데이터 정량화를 해서 소통해보고 다른 사람들을 설득해 나가는 과정을 경험해보고 싶습니다.

내가 아직 시도조차 못해본 것들

리더쉽

이제 어느덧 주니어를 넘어 중니어로 접어 든 시기 입니다. 여태까지는 그냥 내일을 잘하면 되는 수준 이였지만, 이제는 한계를 많이 느낍니다. 회사는 나 하나만 잘한다고 성공하는 곳이 아니니깐요. 팀원들뿐만 아니라 회사 측면에서 어떻게 리더쉽을 가지고 사람들을 이끌어 나가는지에 대해 깊은 고민을 해보고 있습니다. 앞으로는 3명이상의 팀원을 꾸리고 같은 목적지를 바라보고 목표를 달성해보는 경험을 해보고 싶다는 생각이 많이 드는 시기 인 것 같습니다.

리더쉽에서 해봐야할 것

• 팀원들이 이해가능한 소통 방식 제공
• KPI 작성 및 목표 달성
• OKR 작성 및 방향성 달성
• 1on1 미팅을 통한 개별 성과 관리 체계 만들기

고객을 위한 제품 만들기

개발자로 그냥 열심히 코드 작업만 하면 되겠지 생각하던 시대는 이제 끝났다는 생각이 듭니다. AI가 나오고 LLM이 나오고 이제 저보다 AI가 더 코드 작성을 잘합니다. 그럼 나는 대체 가능한 사람인가에 대한 의문이 들었습니다. 지금은 그렇다고 말할 수 있겠습니다. 그럼 대체 불가능한 사람은 누구일까? 라는 질문을 저에게 해봤는데, 고객을 위한 제품을 만드는 사람이 되어야겠다는 생각이 들었습니다. 나는 여태껏 고객으리 위함 제품을 만들려고 주도적으로 노력해 보았는가라는 질문에는 최선을 다했다는 대답을 못하겠더라구요. 그래서 앞으로는 고객이 진짜 필요한 제품을 만들기 위해 노력해볼 예정입니다.

고객을 위한 제품 만들기 위해 생각 해볼만한 것들

• 이 제품이 고객이 찾는 제품인가?
• 제품이 고객의 불편함을 덜어주는가?
• 고객의 재사용률을 높이기 위한 기능이 있는가?
• 고객의 신뢰할 만한 보안을 제공하는가?
• 고객이 필요한, 궁금할만한 정보를 제공하는가?

마무리하며

긴글을 쓰면서 두서 없이 제 머리 속에 있는 내용을 정리해 보았습니다. 저도 적으면서 느낀건데 크게 4파트로 나눠 볼 수 있을 것 같습니다.

• 데이터 엔지니어, 소프트웨어 엔지니어로써 기술적 발전 하고, 이 뿐만 아니라 문제 해결을 해내자!
• 팀원간의, 팀들간의, 회사간의 협업 능력을 증진 시킬 수 있는 커뮤니테이션 능력을 키우자!, 말투 고치자!
• 리더쉽 키우자!(최고의 복지는 좋은 동료!! 잊지 말자)
• 내가 한번 사장 처럼 일해보자! 좋은 제품 만들어 보자!