tWIL 2022.12 1주차

호주 TV 시리즈에서 사람12사람의 음원 싱크 라이센스를 요청해왔다. 월드와이드 배포에 무기한 그리고 거의 모든 매체를 사용하는 조건이었다. 영화 음악 슈퍼바이저 지인에게 물어보니 이러한 조건은 비용이 꽤 크다고 한다. 음원을 발매한지 대략 10년이 지난 것 같은데 당시엔 음악으로 수익을 낼 수 있다는 생각을 해본 적이 없었다. 음반도 CD와 LP를 모두 발매했지만 모두 팔아야 손익분기점 조금 넘는 수준이었다. 영혼과 집중력을 갈아넣어 얻는 노력에 비해 성과는 불확실성이 매우 컸기에 적극적인 음악 만들기에 시간을 많이 투자하지 못했다. 발매 했을 때도 그랬지만 이렇게 오래된 음원도 관심을 가져주는 세계인들이 많다는 것을 새삼 느낀다. 이제 부터라도 관심을 좀 더 가져볼까...

Apollo Rover vs Apollo Server

Apollo server v4 업그레이드 이후 rover graph introspect가 오류를 내고 있었다.

variables in a POST body must be an object if provided

이로 인해 클라이언트의 GraphQL generator가 동작할 수 없게 되었는데 원인은 rover dev not working with Apollo Server 4 subgraph에서 처럼 variables에 null값을 보내고 있었다. @apollo/server@4.2.0부터는

If a POST body contains a non-string operationName or a non-object variables or extensions, fail with status code 400 instead of ignoring the field.

이라고 되어있었다. @apollo/server는 4.2.0으로 11월23일에 업데이트를 단행했고, @apollo/rover는 11월14일 0.10.0을 배포하고 변동이 없었다. 이슈가 있으니 언젠간 업데이트가 되겠지만, 테스트도 없이 @apollo/server를 업그레이드 하면서 다른 제품을 체크하지 않는다는 부분이 좀 거슬린다.

우리 개발자들은 뜬금없는 오류에 맞닥뜨리는 상황이 되어 반나절을 이 오류를 잡고 있었다. 일단 이슈를 남겼고, 아폴로팀은 아래와 같은 답장을 보내왔으며, 바로 픽스한 이슈를 올려주었다. apollographql/apollo-server/issue#7200

Right, this was an unintentional regression in v4.2. We added some reasonable type validation in that change but banning variables: null should not have happened (even according to the spec). Going to first improve the spec test suite graphql/graphql-http#26 and then fix. Thanks all.

대략 1년전에도 Apollo Studio에서 발생한 오류에 대하여 이슈 티켓을 남겼는데 굉장히 빠른 피드백을 주면서 바로 해결할 수 있도록 집요하게 이슈를 잡아주는 팀에 조금 감동을 받긴했다. 이번 경우에도 아폴로팀은 꽤 좋은 개발자 커뮤니티 경험을 제공해 주는 팀인 것 같다.

유연함에 대해

이번 주는 비즈니스 로직에 필수적인 별개의 SDK를 분석하는 시간을 주로 보냈다. 그리고 별개로 인프라와 Third party 애플리케이션을 사용하는 데 있어 유익함과 한계성을 어느정도 트레이드 오프를 할 것이냐에 대한 문제로 고민이 귀결되었다.

나는 프로젝트를 시작함에 앞서 이 프로젝트가 어느정도까지 확장이 될지 가늠해 보는데 여러 서비스들을 분리해서 마이크로 서비스 아키텍쳐를 가져간다고 해도 확장 가능성은 항상 미리 염두해 두어야만 분리한 스키마를 설계할 때도 고려가 된다. 솔직히 API를 띄우고 애플리케이션을 만드는 단계는 사실 그다지 복잡하지 않다. EC2 서버 하나 띄우고 거기에 모든 기능을 몰아넣으면 된다. 체계적으로 인프라를 배포하고 관리할 필요도 없다. EC2 까지도 갈 필요 없을지도 모른다. 서버를 한대 사서 거기에 앱을 올려도 문제 없을 수 있다. 인증/인가도 crypto와 json-web-token으로 만들면 그만이다. 크게 어려운 것도 없다. 본인인증, 간편로그인, Open ID access, 아이디 찾기, 비밀번호 찾기 등도 그냥 만들면 된다. 이미 과거에 언급한 모든 기능을 만들어 봤었다. 확장을 고려하지 않는다면 그리고 직접 개발해서 만드는 기능이 ThirdParty를 쓰는 것보다 원래 요청했던 기획을 수정하지 않도록, 분쟁이 발생하지 않도록 만들어야 한다면, 그냥 만들면 된다. ThirdParty 앱을 고려하지 말고 말이다. 하지만 포기해야할 기능들도 있다. SAML기능이나 SSO 기능은 만들기엔 규모가 커질 수 밖에 없으니 안되는 것으로 생각해야하고(MSA에서는 기본이지만 현 프로젝트에서 마이크로 서비스가 필요한지 모르겠고 이 기능이 필요한지도 모르겠다), 그리고 보안에 있어 위협요소들 예를들어 토큰 탈취(Thefted token) 같은 위협을 감지하기 위해 많은 개발 시간을 투자해야한다. 사실 개발을 리딩하면서 이러한 위협에 대한 방어는 기본이 아닌가 되물을 수 있는데 그건 아니다. 여기에 많은 자원이 투입이 되어야 한다.(일명 개발자가 뭘 하고 있는지 모르는 작업) 그러나 그 한계를 어디까지 둘 것이냐에 그 범위를 더 특정할 수 없다. 결론은 결국 그러한 고민들을 하지 않으면 된다. 모든 기능을 직접 개발하고 우리한텐 그런 위협이 되는 요소들은 일어나지 않을꺼야 생각하면 편하다.

현재 팀에 합류하며 큰 그림을 많이 그렸다. 이 프로젝트의 규모를 키우고 리소스의 문제 없이 그리고 개발에 유연하도록 개발자 경험을 챙기고, 기존의 경험을 살려 장기간의 계획으로 프로젝트 그리고 인프라 설계를 했다. 그러나 최근 몇 주간 이 동력을 좀 상실했다. 나는 여기에 얼마나 머무를 것이냐, 괜히 쓸데없는 확장성 고려로 나를 갉아먹고 있지 않나, 아니면 팀을 본부를 갉아 먹고 있는 것은 아닌지 고민해본다. 개발팀을 리딩하는 입장으로 원하는 기능만 문제 없이 동작하는 상태에 머무른다는 것 그리고 그 상태를 요구 받는 것 매우 불편하다.

의견 합의를 내었다는 것은 내가 그렇게 주장했다는 것이 아니다. "그럼 이렇게 하시죠"라는 말은 내가 제일 경계하는 말이다. 그래서 내가 했을리가 없다. 결정 장애처럼 보이겠지만 "이건 어떨까요?" 라는 제안의 의문문이 대부분이었다고 생각한다. 그리고 어떤 기능과 도입을 위해 독단적으로 결정한 일도 없다. 개발관련 일은 개발팀과 상의를 하고 테스트 하고 결론으로 다가갔었다. 그리고 합의되지 않은 내용이 이렇게 될 것이다라는 추측으로 문서화 되어있는 경우 나는 의견을 제시할 수 있는 것 아닌가? 이것이 마치 앞서 말한 합의된 내용이 내가 주장했기 때문이다로 돌아오는 상황이 매우 불편하다.

프로젝트 진행에서 유연함은 특정한 상태로 결정 짓는 것이 아니라고 본다.