C#에서 JSON 처리 : Class 정의의 비효율성과 그 대안에 관해 (Newtonsoft.Json)

⁉️ 프로그래밍 언어 Q&A C# Q&A
21

전 이 글의 전체적인 내용에 반대하는 입장입니다
개발을 편하게 하고 유지보수를 어렵게 하자는 내용과 마찬가지라고 봐서요.

json - class 로의 변환시에는 변환만 잘되면 나머진 개발자가 코드만 보고 따라갈수 있습니다만
json - object 라면 실제 데이터에 대한 분석이 선행된 후에 코드를 따라가야합니다
또 데이터 형변환 이슈가 발생할 확률이 매우 높고 모든 데이터를 문자열 기반으로 접근해야하므로 json 스펙의 변화에 따른 유지보수가 굉장히 어려워집니다

같은 논리로 DataTable의 사용또한 지양해야한다고 보고 이 역시 컬럼명, 데이터타입을 개발자가 모두 이해하거나 디비툴을 별도로 띄워놓고 개발해야한다는 점이 문제라고 봅니다

json 에서 데이터 한두개 꺼내오는 수준의 단순 작업이외에는 제 기준에서는 리젝 사유입니다

11 Likes
22

와우! 이런 기능이 있었군요… 지금까지 얼마나 시간적 손해를보고 있던건지 ㅋㅋㅋ
감사합니다!!

4 Likes
23

동감합니다. 혼자서 모든 사항을 이미 파악하고 있고, 모든걸 혼자 하고있을때나 겨우 유효한 방법이죠, 선언되지 않은 구조를 다룬다는건 신뢰할수 없는 데이터를 다룬다는것이고, 그러한 절차는 필연적으로 온갖 방어적 코드와 끝없는 런타임디버깅에 빠지게 되있습니다.

json구조가 복잡해서, class 선언할게 많아서 불편하다면, 그건 복잡한 json을 고쳐야 하는 문제이지, 선언하지말고 dynamic으로 퉁치자는건 그저 해소되지않은 복잡성을 은닉하고 부패시키는 행위에 불과해보입니다.

지금 C#은 과거에 유행하던 리플렉션/동적코드들을 하나하나 걷어내고 있으며 웹마저도 강타입 언어를 도입하고있는 추세입니다. 소개해주신 방식이 가장 선호되던 시절이 이미 있었으며, 지금은 아닙니다.

6 Likes
24

뭐 제가 지금 처한 상황을 다 말씀드린건 아니니까. 일반적인 관점에서 이렇게 말씀하실 수 있다고 봅니다. 저도 말씀하신 내용엔 동의하고요.

다만 하나 꼭 말씀드리고 싶은건 json구조가 복잡해서, class 선언할게 많아서 불편하다면, 그건 복잡한 json을 고쳐야 하는 문제라고 말하는 부분에서 큰 시각에 차이가 있는거 같습니다.

보통 JSON을 저희가 정의하거나 수정 할 수 없는 경우가 대부분이죠. 외부에서 자기내들이 멋대로 정의한 JSON을 저희가 필요에 맞게 가공해서 사용하는 것입니다.

중복되는 필드, 불합리한 구조, 불필요하게 많은 Request 필드 등등 만일 저희 회사에 신입직원이 이랬다면 “이따위로 구조를 잡아놨어?” 하면서 한소리할 만한 구조라도 어쩌겠습니까?

"을"의 위치에서 주어진 데이터를 필요에 맞게 고민고민 해가며 가공해 놨는데 우리 "갑"님들 께서는 무심하게도 갑자기 그리고 어떤 원칙이나 의도도 모르겠는 구조로 바꿔놓는단 말이죠. 소위 “리뉴얼”, “V2.0” 이런 타이틀을 달고 말이죠.

또 우리 "갑"님들이 한 두분도 아닙니다. 서문에서도 말했지만 갈수록 많아지지요?
현재 저희 회사 서비스에서 모시는 "갑"님만 10분이 넘어 가는데 이분들이 변덕이 너무 심해요. 보통 한달에 "갑"님 중 2~3분은 뭔가를 바꿔 놓으니까요.

이는 결국 서비스 운영에 지속적인 작업(비용)을 발생시키는 요소입니다. 문제는 "우리"가 컨트롤 하는게 아니니 구조를 바꾸니 뭐니 해봐야 개선 되는게 아니라는 것이죠.

이런 상황에서 어떻게 하면 운영 비용을 줄일 수 있을까? 라는 관점에서 시작된 이야기 입니다.

혹시 저희가 처한 상황에 괜찮은 다른 대안이 있다면 말씀해주시면 감사하겠습니다. :man_bowing: :man_bowing:

3 Likes
25

그런 경우라면 더욱 더, '정보 은닉’의 이점을 누리시기 바랍니다.

1 Like
26

저는 선언적 코드가 말씀하시는 상황에서 가장 절실하다고 봅니다.
내가하는일이 남일이 아닌이상, 그 뭣도 모르는 갑들이 내뱉은 잘못된 요구사항들의 모순과 부조리를 누군가는 직시하고 통제해야하기 때문입니다. 유연한 처리는 말하자면 처하신 상황을 구조적으로 외면하려는 시도입니다. 여러 개발자들이 처한 안타까운 비극이 시스템에까지 영향을 끼치는거죠. 공감은 하지만 긍정해서는 안되는 접근법이라고 봅니다.

3 Likes
27

외부 데이터 모델이 변경되는 것이 우리가 통제할 수 없는 변수라면, 어떤 식으로든 우리 시스템에 문제가 발생하여 치유하는 비용이 들어가는 것은 피할 수 없습니다.

이 경우, 명시적 형식을 사용하느냐, 묵시적 형식을 사용하느냐 보다는, 발생한 문제가 빨리 치유될 수 있도록 문서화를 잘 해 놓는 게 비용을 줄이는 길이라 생각합니다.

코드 문서

명시적 형식을 정의하기로 했다면,

/// <summary>
/// GET https://.../.../..
/// 개발 요구서 3.2
/// </summary>
record ScreeningInfo(
   // ...
);

묵시적 형식으로 처리하기로 했다면,

namespace 갑;

/// <summary>
/// GET https://.../.../..
/// 개발 요구서 3.2
/// </summary>
class ScreeningInfoService : IScreeningInfoService<갑>
{
}

별도 문서

Mapping Guides

…

3. 화면 정보

4. 갑

출처

GET https://.../.../..

요청

{
   ...
}

응답

{
   ...
}

모델

/Externals/갑/ScreenInfo2.cs

/Services/ScreenInfoServices/갑/ScreeningInfoService2.cs

히스토리

2024.8.1 : Url 이 변경됨.
https: … => https: …

2024.3.3 : ScreeningDataList 가 empty. 갑 측에서 ScreeningDataList => ScreeningList 로 rename 한 것이 원인.

이를 반영한 ScreenInfo2 도입 (ScreeningInfoService2 도입)

3 Likes
28

역시 물어보길 잘했다는 생각이 드네요.
여러분들의 많은 답변과 조언덕에 몰랐던것들도 배워가고 지금의 상황에 대해 생각지 못했던 부분들을 발견하면서 한층 더 발전할 수 있는 시간이 였습니다.

다들 정말 감사합니다. :smile:

8 Likes