역시 회사 생활은 쉽지가 않다.
아!!!!!!!!!
너무너무 힘들고 지쳐서 그래도 이렇게 기록을 정리해두는게 좋은거같아서
모진 풍파에 대한 경험을 기록합니다.
시간이 지나서 이또한 웃으면서 예기할수 있는 프로젝트의 한부분으로 남았으면 하는 개인적인 소망입니다.
프로젝트의 이슈
MSA프로젝트는 블로그에서도 몇번 언급한적이 있는데 기존에 모놀리딕 한부분을 쪼개서 처리한다가 단순하게 예기하면 그런 방향이라
리소스가 처음보다 2~3배정도 된다 라고 예기할수 있을것 같습니다.
현실 프로젝트에서는 사실 이부분 또한 쉽지는 않다고 생각하고 모든 개발자들의 상황이 그런것 같습니다.
MSA에서 진행하는 작업은 프론트에 데이터를 조회해서 제공해주는 부분을 하고있는데 안타까운 부분은 원천데이터를 처리하는데 있어서 내가 컨트롤 가능한 범위에서 가져오는게 아니고 검색API를 통해서 가져오게 됩니다.
모놀리딕으로 혼자다한다면 온전하게 삽질,분석,개발을 내컨트롤 가능한 범위에서 하게되지만 MSA에서 그렇지 않습니다.
여기서!!!
온전히 프로젝트 개발,일정,분석 에서만 오는 스트레스는 감례할수 있는데 사람들과 소통을 해야하는 커뮤니케이션 비용이 발생하는순간이 감정이 소비되고 그럴수 있다는 마음가짐으로는 할수가 없구나 하는 상황이 발생합니다.
이슈 문제점을 객관적으로 접근해보겠습니다.
프론트앤드 개발이슈
최대한 맞춰보고 이해하고 그럴수 있다는 마음이 필요한 상황
프론트의 BFF레이어를 백앤드개발에서 작업하다보니 Api를 제공하는 관점 개발방향 에서 신규로 하는작업이다보니 데이터를 온전히 사용할수 있는 형태로 음식으로 표현하면 소금,후추로 간을 맞춰주는 작업이 필요합니다.
이부분에서 자칫 한끗으로 잘못되면 커뮤니케이션이 상당히 힘들어 질수 있기 때문에 내가 만든 Api를 사용하는 입장에서 최대한 질문이 최소화 될수 있는 방향으로 하려고 노력하는 편인데 그래도 이부분 어느정도 잘소화 된것 같습니다.
이런 여러문제로 인해서 backend에서 작업하기보다는 frontend 에서 컨트롤 가능한 GraphQL같은 Bff레이어를 사용하는것이 이슈를 해소할수 있는 방법인것 같습니다.
backend리소스를 줄이고 원하는 형태의 bff 레이어 구성도 frontend에서 작업하게되면 데이터의 구조도 이해할수 있기 때문에 러닝커브, 직접개발 에대한 선행작업이 필요하지만 이방안이 적합하다고 판단이 되었습니다.
내부 개발이슈와 커뮤니케이션 프로젝트 일정
내부적인갈등은 이번프로젝트에서 해소하지 못했는데..
BFF(backand for frontend)작업하면서 프로젝트에 흐름상 구현이 다되고 전달되면 프론트 개발일정에 이슈가 있기 때문에 Api인터페이스와 Mock데이터를 제공하는방향으로 정리되었는데
문제는 구현이 제대로 되지않은 상황에서 안보이는 변수까지 고민해가며 만들수 있는 프로젝트 일정상황이 아니었기때문에 상당한 시간이 들어갔다는겁니다.
여기서도 문제는 Mcok데이터가 정상적이지 않았다는 부분이있고 이걸 맞추는작업이 백앤드에서 제가 맡고있는 부분만 이슈가 있다는형태로 전달이 되서 힘들었다는점이었고 이부분을 전체로 공유하는 이슈로
백앤드 전체적으로 Mock데이터 검증에 대한 작업이 있었고
내부적으로도 미운오리가 되었던것 같습니다.
아마도 프로젝트 진행하고 3개월만에 그랬건기억이있어 조심스럽게 닉네임을 미운오리꽥꽥 으로 하게되었네요ㅜㅡㅜ
내부에 등가교환으로는 팀내에서 별도로 나와서 개발 +내부 커뮤니케이션을 감례하는것으로 교환되었는데 어쩔수 없는건 받아들여야 하는것 같아 ㅜㅡㅜ 이해하며 하는중입니다.
Api를 제공해주는 관점에서 내가 만든건 이슈가 없고 너가 문제라고 방어적으로 나올때...
프론트에 입맛으로도 충분한 커뮤니케이션 비용이 발생하는데 내부 백앤드에 검색Api를 사용해야하다보니 이번에는 엮으로 내가 개발해야하는 데이터 호출시 기본적인부분이 구현되면 잘만들어보고 최대한 해볼수 있는부분들은 해보자 라는 접근으로 시작했는데
이부분이 서로 잘되지 않았던것 같습니다.
사람들에 성향은 잘바뀌지 않습니다.
사람과 맞춰간다는 부분은 상당히 어려운데
내가 만든건 너무잘 했어 문제가 전혀 없을꺼야 라고 생각하는것 자체가 문제인것 같습니다.
(실제로 자신을 사랑하고 완벽하다는 생각을 하는사람만나면 정말 쉽지가 않습니다.)
초반에 Api를 받았을때!!!
와!!!!!
이거 사용해서 쓰라는건가?! 라는생각이 들었지만
처음 만나서 커뮤이케이션하는 자리에서는 그래도 고생도했고 내가 레거시 너가할부분도 내가 만들었다 이렇게 예기하니 그래 이해하고 블랙박스도 까서 보라고 하니 봐야겠다는 마음으로 정리해보려고 한 4~5일을 Legacy코드를 보면서 진행 했는데도 쉽지가 않아서
Api사용할때 Request, Response라도 좀 알려줘여될거같다 라고해서 성향도 좋으신 개발자분에게 Api가 200이 나올수 있는 Request Jsob Body를 받아서 진행하게되었는데..
이부분이 Request 40~50개를 한클래스에 담아둔 Api를 사용하기란 정말 쉬운부분이 아닌것 같습니다.
Api인터페이스에서 Request, Response필드가 40개 이상이 되면 어느정도 분류에 맞는 구성이 필요합니다.
연동되는 데이터필드가 많은 Big(God) Object 같은 경우는 문제점이 많아지는 구조입니다.
Request, Response를 처리하는 Json 필드가 나눠있지 않고 하나로 작업이 되어있으면 가공해서 사용하는 부분에서 어려운부분이 발생하게됩니다.
40~50개가 넘어가는
God Object 사용시 문제점
1.너무 많은 필드를 가지고 있는 God Object는 초기값 설정이 쉽지 않습니다.
2.하나의 객체에 너무 많은 정보가 있기 때문에 의미전달이 원할하지 않습니다.
3.비지니스 전달시 필요한 정보만 전달되어야하는 (제한된정보) 이부분이 쉽지 않습니다.
4.TDA(Tell don't ask)문제로 인해 절차지향적인 설계를 하게됩니다.
5.큰객체는 다른 객체와 함께 사용하는데 있어서 제한적인 요소들이 발생하게 됩니다.
Tell Don't Ask
소프트웨어의 복잡성은 다루어야 할 정보의 양에 영향을 받으며 다루어야 할 정보가 많아지면 더 많은 정보를 가공해야 하고, 정보의 값에 의한 제어 변경(보통 상태라고 부른다)이 더 자주 발생하게 됩니다.
하지만 꼭 정보의 양만 복잡도를 가늠하는 척도는 아니며 정보를 처리하는 단계가 짧고, 정보를 다루어야 할 객체가 적고, 정보에 대한 처리 과정을 중복되지 않고 간결하게 처리한다면 같은 데이터를 처리하더라도 훨씬 단순한 소프트웨어를 만들 수 있는데 이 과정에서 TDA 원칙의 중요성이 떠오르게 됩니다.
우리 말로 번역해 보자면 "물어보지 말고 그냥 시켜라"가 될 수 있는데!!
이는 객체와 객체가 협력하는 경우, 다른 객체에게 정보를 요구하지 말고 그냥 행위하도록 시키라는 의미이다. 즉 정보 은닉의 중요성을 강조하는 원칙이라고 할 수 있습니다.
이런 문제로 결국 감정적인 소모 발생
이런 이슈들은 같이 일하는 개발자들이 커뮤니케이션 하면서 조율하면서 어느정도 해소 할수 있고 그렇지 않다면 객체에 대해서 각 필요한 비지니스 분석해서 용도에 맞게 작업이 필요합니다. 물론 시간이 많이 들겠지만
프로젝트는 항상 일정, 기능, 커뮤니케이션에서 발생하는 상황이 발생하는데 이런 프로젝트의 풍파을 기록해봅니다.
그래 그럴수 있다는 마음을 다시 잘 머리속으로 기억하면서 살아가도록 하겠습니다.
