기록

선택의 집합체

Re::cord — Tue, 19 Nov 2024 00:09:40 +0900

평소에 잡생각을 많이 하는 편이다.

잡생각의 주제별 빈도는 7~10일에 한 번인 것 같다.

어느 날 '강아지가 착한 이유'에 대해 생각했다면,

이틀 후엔 '지구상 최초의 개발자'에 대해 생각하고,

이틀 후엔 '우주 및 생명의 본질'에 대해 생각한 뒤,

이틀 후에 다시 '강아지가 착한 이유'로 돌아온다.

일주일마다 나만의 가치관이 다져지는 기분

그리고 바로 오늘

내 긴 연애기간 동안 풀리지 않던

'사랑이란 무엇인가' 에 대한 가치관이 확립됐다.

나의 모든 잡생각에 해당되는 말인데

'~인가?'에 대한 생각이

'~이다.'로 매듭지어지지 않았던 게 늘 고민이었다.

특히나 사랑이나, 인간의 행동 심리? 같은 게

내면에서는 평서문으로 깔끔하게 떨어지지 않았다.

어릴 때 책 좀 많이 읽을걸

'사랑'을 떠올리면, 나는 나도 모르게 이성을 떠올리곤 한다.

그러다 가족으로 넘어가고, 친구로 넘어간다.

친구로 생각이 넘어간 뒤로는, '친구'라는 범위를 정의하느라 바쁘다.

10대 ~ 대학생 까지는 같은 집단 내 동갑만이 친구라고 생각했다 보니

'친구'를 떠올리면 동갑 친구들이 떠오른다.

하지만 지금은 삶을 살아가면서 만나는 모든 주변인들이 나에게 친구라,

출근길에 인사하는 버스 기사님, 지하철에서 좀 들어가라고 짜증 내는 아저씨들

게임에서 만나는 사람들, 산책 중에 가볍게 인사하는 사람들을 떠올린다.

나는 이성이 차지하는 사랑의 비율이 제일 크다.

단순히 여자친구의 존재만 사랑하는 게 아니라

여자친구의 주변에서 일어나는 모든 일을 사랑한다.

함께 지내는 순간들, 함께 알아가는 사람들

똥고집인 나의 가치관이 너로 스며드는 순간들을 사랑한다.

사랑의 형태는 비슷하다.

5살이든, 중학생이든, 대학생이든, 중년이든 인간의 모습이 어떠하든

나의 모든 사랑엔 항상 목적이 있었다.

10대 때는 그 목적을 자각하지 못해서, 그저 설렘만 가득했다.

지금 생각해 보면, '여자친구'라는 존재와 '특별한 무언가'를 하는 게 내게 행복을 줬던 것 같다.

사랑할 때는, 너무 깊이 빠져버려서

내가 무슨 생각을 하는지 조차 잊어버린 채

내 마음의 질문이 뭔지도 모른 채 해답만 찾곤 했었다.

지금의 내 사랑도 형태는 그때와 비슷하다.

비슷한 환경에서 비슷한 사랑을 하고 있다.

그때와 다른 건, 목적이 없는 사랑을 하고 있다는 건데

목적이 처음부터 없진 않았고, 중간에 사라졌다.

지금의 목적은, 그리고 나에게 '사랑'이란 '그 사람 대신 살아가는 것'이다.

문장만 보면 폭력적이지만

'그 사람이라면 뭐든 해줄 수 있다' 식의 행위적 희생이 아니라 정신적 희생을 의미한다.

만날 수조차, 만날 이유조차 없던 두 사람이 만나

서로의 시간을 깎으며 살아간다.

생존이 1순위인 인간이다 보니

각자 상처받지 않을 가면을 쓴 채

방패로 막고, 방패로 때리며 시간을 함께한다.

지난날 나를 돌아보니, 내가 나를 사랑하지 못했던 시절에 가장 많이 다퉜다.

'나는 너에게 멋진 사람이 될 거야'로 시작했던 마음이

'나는 너에게 멋지지 않으면 안 돼'로 변하고

'멋지지 않은 나는 숨겨야 돼'가 되어갔다.

그러다 보니 내 내면과 외면의 간극은 커져갔고

그 간극의 말단을 양손으로 붙잡고 있던 너만 힘들게 했었던 것 같다.

그리고 가장 허무한 건,

이 모든 감정은 '철없던 때였다'로 함축되곤 한다.

그 사람 대신 살아간다는 건, 선택의 집합체인 나라는 인간이

너를 위한 선택을 하겠다는 것이고

그 마음보다 큰 마음은 없다고 확신한다.

내가 나를 사랑하기에, 지금의 나를 있게 해 준 너를 사랑한다.

지금의 내가 볼품없어도, 나는 내가 찬란하고

지금의 너를 스스로 볼품없다 해도, 나는 네가 빛나는 순간으로 가득하다.

오히려 너의 소중함을 알려줄 수 있을 테니

볼품없는, 볼품 없어질 너의 모습을 사랑한다.

가족, 친구, 자연 모두에 해당되는 사랑을 드디어 찾았다.

그 존재 대신 살아간다는 것

어우 이거지

Spring? ? ? ? ? ? ? ?

Re::cord — Mon, 18 Nov 2024 23:29:23 +0900

.NET C# 개발 업무로 입사해서, 요즘은 Spring을 제일 많이 다루고 있다.

Spring 기본기가 부족한 상태로 실무를 먼저 접하다 보니,

다른 업무 & Spring 및 부족한 CS지식 공부와 병행해야 해서 일정 관리가 너무 힘들다..

JAVA를 1도 모르는 내가 스프링이라는 자동차를 운전하자니

쓰잘데기 없는 브레이크가 너무 많았다랄까

필요한 어노테이션을 바로바로 떠올리는 선배분들이 그저 신기하다..

JAVA 기초를 인프런, 구글링 등으로 접하고 있지만, 실무와 크게 가깝지가 않은게 흠이다.

JAVA 라는 언어를 사용한다는건 같지만,

내부 비즈니스 로직이나, 운영 환경, 라이브러리, 의존성 등이 다 다르다 보니

그냥 실무하면서, 그때 그때 필요한걸 빨리 찾아서, 빨리 이해하고 빨리 활용하는게 베스트라고 느낀다.

근데 동시에, 실무 시간에 내 부족한 지식 때문에 내 예상보다 업무 소요시간이 늘어나다보니

조바심 & 약간의 자괴감 & 새 지식에 대한 설렘 등이 생겨서

참 마음이 복잡하다.

본문은 하소연 & 약 1달동안 60%만 이해됐던 개념들을 리스트로 쭉 뽑고

프로젝트 끝나고 이 글로 돌아와서 하나씩 정리할 글이다.

1.Setter, Builder 차이

- 단순 개념적 차이 외, 성능 및 가독성

- case별 장단점(A의 경우, B의 경우 대조)

2.RestController, NotBlank, PutMapping ... 등 어노테이션 동작 원리

- 어노테이션 별 어떤 역할을 하는지는 이해 O

- 프로그램 실행되고부터 어노테이션까지 오는 실행되는, 그 이후 과정까지 전체적인 시퀀스 궁금

(얘는 실무(프로젝트의 완성도)와 멀다고 생각해서 깊게 공부하지 않았음)

3.Gradle 사용 이유

- 빌드 자동화 역할인건 이해 O

- 왜 쓰는지, 안썼을 때 대체 케이스 및 장단점

(얘도 실무(프로젝트의 완성도)와 멀다고 생각해서 깊게 공부하지 않았음)

4.Spring Boot 특징

- 구글링&강의에 정보가 있긴 한데, 특정 프레임워크의 특징, 장단점은

그 전 프레임워크나 최신 기술을 익숙하게 사용해봐야 느낄 수 있다고 생각해서인지 잘 안와닿음

5.Http 메소드(CS지식)

- PUT, POST 차이(그놈의 멱등성이 이해가 안감)

- PUT이든 POST든 비즈니스 로직은 Service단에서 실행되는데

왜 PUT은 리소스가 그대로 덮여씌여진다하고

왜 POST는 리소스가 일부만 수정된다 하는지? -> 비즈니스 로직을 수정하면 되는거 아닌가..?

Kubernetes

Re::cord — Mon, 26 Aug 2024 20:36:11 +0900

1.Kubernetes란?

- 컨테이너 관리 도구(컨테이너 오케스트레이션 도구)

- 빌드된 도커 이미지들을, 실질적으로 다루는 도구

2.Kubernetes 장점?

- Pod, Service, Deployment 등 k8s의 객체별 다양한 기능 제공

- 무중단 배포, POD간, POD내 컨테이너간 통신 가능

아직 많이 안써봐서, 느낀게 별로 없다

Docker랑 같이 스터디 하면서 이 글에 채워야겠다

Docker

Re::cord — Mon, 26 Aug 2024 20:30:43 +0900

처음 접하게되는 개념들을

자꾸만 외우려 하는 습관이 남아있다.

최근들어 Docker 와 Kubernetes에 대해 공부중인데

자꾸 같은 개념만 반복해서 이해하려 하다보니

내가 어디까지 이해했는지 놓친 채 지식 습득만 하고있는 것 같다

내가 이해한 수준을 기록한 뒤

다음에 다시 읽고, 수준에 맞게 다시 공부하고 할 예정이다

그만큼 아직 도커 & 쿠버네티스가 확 와닿지 않는다 ㅠ

1.Docker란?

- 런타임, 라이브러리 등 실행환경이 다른 소스들을, 컨테이너화 하게 도와주는 가상화 플랫폼

컨테이너화 : 일차원적으로 드는 생각 그대로, 프로그램을 특정 틀에 담는 행위
컨테이너 : 런타임, 라이브러리, OS 등이 정의된 환경
가상화 : OS 환경을 임의로 세팅하는 행위 (물리적 리소스를 분할)

2.Docker Image란?

- 런타임, 라이브러리 등 소프트웨어가 실행되는데 필요한 환경

Dockerfile로 정의
Dockerfile은, 세팅할 소프트웨어와 같은 디렉토리에 생성 ex) C:\Users\USER\source\repos\my-software\Dockerfile
Dockerfile내에 OS, 실행할 소프트웨어, 실행 조건 등 다양한 설정 가능

3.Docker 사용 시 장점?

- 자원 낭비 최소화, Kubernetes같은 컨테이너 오케스트레이션 도구와의 강한 연동성

- 개발자의 개발 환경 세팅이나, 배포 과정을 너무 간편하게 도와준다. 안 쓸 이유가 없다?

- Docker없이 linux ubuntu OS, window OS 가 동시에 요구되는 경우, 불필요한 물리적 자원이 요구됨

- 자원문제와 더불어, 서로 다른 OS에 있는 프로그램간의 호환 문제 발생

출처 : https://seosh817.tistory.com/345

도커의 구조를 설명한 그림중, 내 기준 가장 이해가 잘되는 그림이다.

가상화 환경에서는, App마다 OS가 별개로 필요하지만

Docker 환경에서는 Host OS가 하나있고, 컨테이너에 필요한 커널을 공유한다.

C# 선그래프

Re::cord — Tue, 2 Apr 2024 22:31:17 +0900

C# 윈폼을 활용해서 동적차트를 만들어보았다.

차트 내에 여러개의 그래프가 있고,

그래프의 데이터는 List로 관리

데이터 저장 기능까지 구상하고 시작했다.

3종류의 데이터를 받아서, 차트로 표현했다.

x축은 총 10개의 데이터가 나타나고

1초마다 값이 업데이트된다.

윈폼이 실행되면, 로딩이 완료된 뒤 Start 이벤트를 발생시킨다.

Start이벤트는 차트 관련 설정들을 세팅하고

데이터 생성 스레드를 실행한다.

차트와 관련된 설정들을 기입했다.

아래 사진처럼 윈폼상에서 미리 설정해둬도 되지만,

프로그램을 실행하면서

유동적으로 값을 변경하기 위해, 코드상으로 정의해뒀다. ( 나중에 수정할 부분을 찾기 편하도록 )

GenerateData() 함수는, 랜덤 데이터를 생성하는 함수다.

지금은 데이터가 없어서 임의로 데이터를 생성하고,

그 데이터들을 List에 저장 후

그래프 업데이트 로직에서 List의 데이터를 꺼내 화면에 표현한다.

추후에 다른 화면에 차트기능을 넣을때는

직접 장비의 데이터를 읽어서 List에 넣고, 그 List로 차트에 표현할 예정이다.

파란색 그래프(유효전력)의 데이터를 생성하는 함수다.

나머지 그래프들도 동일한 모듈로 동작한다.

데이터 생성이 완료되면,

DrawGraph()를 실행하는데,

윈폼 UI를 외부 스레드에서 변경 시 충돌이 발생해

BeginInvoke()를 활용해서 비동기적으로 처리했다.

그래프별 초기값을 세팅하고,

List(graphData_blue)의 데이터를 차트(Series)에 세팅한다.

세팅 완료 후, 각각 그래프를 chart1 객체에 추가한다.

이건 플래그 관리 함수 및

데이터 저장 함수다.

사실 기능구현 보다는, UI 크기 조절 시

유동적으로 컴포넌트들의 위치와 크기를 조절하는게 애먹었다.

윈폼을 많이 안다뤄보기도 했고,

Panel의 역할을 정확히 이해하지 못했기 때문이다.

애초에 윈폼은 대부분의 기능을 구현할 수 있도록 설계되어있어서

기능 구현은 크게 어렵지 않았다.

다만 예외처리나, 사용자의 입장에서 생각하는 설계? 적인 부분이

아직까지도 너무 어렵고 바로바로 떠오르지 않는다.

Modbus TCP 제어 ( 패킷 과수신 대비 )

Re::cord — Wed, 6 Mar 2024 21:38:05 +0900

Modbus TCP 통신을 사용해서

실제 장비를 제어하는 로직을 사용중이었다.

하나의 프로그램에 프로세스가 총 3개 동작하고

1.MQTT 패킷을 수신

2.제어부 프로세스까지 전달(Socket)

3.실 제어 및 상태값 검증

위와 같이 제어를 하도록 개발했다.

하지만 곰곰히 생각해보니

내가 개발한 코드는, 단순히 '제어'만을 목적을 둔 단순한 코드고

예외상황을 생각하지 못한 안좋은 코드같았다.

수정 전

간단히 시퀀스 다이어그램을 제작했다.

Process A 에서, MQTT 브로커로부터

제어 메시지를 수신받는다.

수신받은 메시지를, Process A & B 를 관리하는

Main Process에게 전달.

Main Process 는 실 제어부 동작을 하는

Process B 로 패킷을 전달한다.

Process B 는 Modbus TCP 통신을 통해

실제 장비를 Write & Read 한다.

Process B는 제어한 뒤,

최초 전달받은 제어 패킷의 데이터 ( on/off ) 값과

제어한 뒤 상태값 ( on/off ) 를 비교하여

성공여부를 판단한다.

문제점

얼핏 보면 문제가 없어보인다.

제어 패킷 프로토콜 검증도 하고,

제어한 뒤 상태값도 검증하니까 괜찮아 보이는데

제어 패킷을 '1회' 수신받았을 때는 매우 정상적으로 동작하는 코드다.

요즘 개발하면서, 회사 규모가 크진 않아도

내가 개발하는 서비스는 사용자가 많다고 상상하고 개발하려고 노력중이다.

그러다 보니 문제점을 떠올릴 수 있었던 것 같다.

만약, 누군가 시스템을 해킹해서

MQTT Broker가 노출되었고,

1초동안 제어 패킷이 10000회 수신된다면 어떻게할래? 하고 스스로 물었을 때

'고장내고 욕먹을래' 라는 대답밖에 떠오르지 않아서

당장 코드를 수정하기로 했다.

10000회는 오바일수도 있지만, 당장 1초에 5개? 만 들어와도

Process B가 제어중일 때, Process A 가 제어메시지를 또 수신받아서

이미 Write 중인 Process B에게 또 Write명령을 내리면

통신 오류가 발생할 가능성이 높다.

문제 단계별 해결법

여러가지 문제들이 떠올랐고,

각 문제별로 어떻게 해결할지 상상해봤다.

1.메시지 과수신

i) 메시지 차단 ( 일정횟수 이상 수신 시 )

일정횟수 이상을 차단하는건 간단하고 좋지만,

중요한 제어 메시지를 휙 하고 버려버릴 수 있는 위험한 로직이라고 생각했다.

ii) 메시지 수신 보안 강화 ( 3 way hand-shake 처럼, 제어 메시지에 대한 응답값 송/수신 후 실 제어 )

확실하고, 안전한 제어가 가능할 것 같지만, 송/수신 사이에 네트워크 문제가 발생했을 때

과거 패킷 관리, 재연결 시 제어 등의 문제가 까다로웠다.

2.비순차적인 제어 로직

i) flag 활용 ( flag = false 일때만 제어 시도 )

간단해서 바로 떠오른 방법인데, flag 세우는건 좋지만

제어 도중에 또다른 제어 명령이 들어왔을 때, 나중에 들어온 명령을 관리하는게 불가피했다.

flag 세우는것 만으로는 제어 로직을 순차적으로 관리하기 힘들어보였다.

ii) 자료구조 활용 ( Queue를 활용한 패킷 관리 )

이게 제일 좋아보였다. 메시지 수신 시, Queue에 패킷을 Enqueue하고

또 다른 프로세스 or 스레드에서 Queue 를 Dequeue 및 실 제어를 하면

깔끔하고, 안전하게 제어를 할 수 있을거라 생각했다.

안그래도 Queue가 선입선출 방식이니, 제어 명령도 순차적으로 진행할 수 있을 것 같았다.

수정 후

로직을 위와같이 수정했다.

(1) 에서, 초당 10회만 수신하도록 처리했다.

MQTT 수신 이벤트 발생 시, count를 증가시켰고

ctrlRcvCount는, 타이머에 의해 1초마다 초기화된다.

즉, 1초동안 10회이상 수신되면

10회 이상값부터는 제어 명령이 아니라 판단하고 무시한다.

10회 미만일때만 OnRecived 이벤트를 Invoke() 한다.

(2) 스레드 소스

Process B에 (2)스레드를 추가했다.

해당 스레드는, Queue 크기를 3초마다 확인하며

Queue 크기가 0 이상일 때 ( 제어 명령이 있을 때 )

Dequeue 후 제어 패킷에 맞게 실 제어부를 동작시킨다.

(3) 제어 메시지 수신

수정 전에는, (3) 처럼 Queue저장 과정이 없이,

제어 메시지 수신 하자마자 바로 제어를 했다.

수정 후에는, 제어 메시지 수신 시

실 제어 하지않고, Queue에 패킷을 저장한다.

lock 처리를 해서, 실 제어부 동작과 충돌나지 않게 분리시켰다.

또한, 제어 log 파일을 따로 관리해서

기존 log 파일과 별개로 영구보관했다.

아무래도 실제 산업현장의 장비를 제어하다보니

문제가 생길 가능성이 있기 때문에

기록용? 보험? 느낌으로 영구저장 하려한다.

테스트 결과는 성공~

수정하고 나서 더 안전하고 효율적으로 제어가 가능해졌다.

자료형 크기

Re::cord — Wed, 21 Feb 2024 22:36:48 +0900

대학생 시절

연구실에서 개발할때는

자료형에 대해 딱히 신경 안썼었다

직접 이슈가 생긴적이 없었고

기능 개발만 우선시 했던 습관 때문이다

오늘 자료형 때문에 발생한 이슈를 정리해야겠다

시퀀스 다이어그램

Process A, Main Process, Process B 는 하나의 exe 내 프로세스다.

Process Z 도 하나의 exe 내 프로세스다.

실행 프로그램 별로 색으로 구분했다.

Azure Cloud는 상위 서버다.

노란색 프로세스 3개를 가진 프로그램과,

코랄색 프로세슬를 가진 프로그램은

같은 PC 환경에서 동작하고있다. ( local )

따라서 1번 MQTT 는 local

2번 MQTT는 Azure 서버를 사용한다.

이슈

A구간에서 local 로 받아온 MQTT 데이터 크기가 94326 이었다.

B구간에서 Socket으로 넘겨주는데,

수신받은 Main Process에서 데이터가 잘리는 현상이 발생했다.

B구간에서 수신받는 로직이다.

빨갛게 표시한 2줄에서

버퍼에 대한 크기가 선언되는데

버퍼의 크기는 int 형으로 선언되어있다.

난 여기서, 무작정 16비트 int 형이겠거니 하고

ReceiveBufferSize 에 65535를 설정했다.

MQTT 로 수신받은 94326 크기의 데이터가,

65535 로 1회

28791 로 1회

데이터가 잘려서 2회 나눠서 수신됐다.

수정 1

MQTT 데이터를 수신받은 뒤,

수신받은 데이터 readString을 검사해서

데이터가 다 들어왔음을 확인한다.

일단 현재 프로세스가 관리하는 데이터들은

전부 Json 방식의 데이터다.

MQTT 로 넘어오는 데이터만 유일하게 JArray 방식이라

[ ] 대괄호로 데이터를 구분할 수 있었다.

1.데이터 수신 후, " [ " 가 있고, " ] " 가 없음 ( 데이터가 잘림 ) 을 확인

2.데이터를 oldString에 저장, 카운터 증가 및 continue ( while 문 다시 반복 )

3.새로운 데이터 수신, 잘린 데이터이므로 " [ " 가 없음.

4.카운터가 1 이상이고, " ] " 가 있을 시, ( 잘린 데이터의 마지막 부분 )

5.oldString와 현재 데이터 합침, 카운터 초기화

즉, 데이터가 잘려서 여러번 수신됐을 때

잘린 데이터를 합치는 로직을 추가한 것이다.

근데 곰곰히 생각해보니

내 생각이 잘못됨을 알게됐다

A 구간에서, local MQTT로 수신받은 데이터는 94326 이다.

수신받은 Process B 에서 log로 데이터의 size를 확인한 값이다.

B 구간에서, 데이터가 깨져서 수신된다.

그러니, 깨진 데이터를 합쳐서 처리한다.

이걸 잘 생각해보면 모순이 있다.

A 구간에서 크기 65535 이상 데이터를 잘 받아놓고,

B 구간에서 크기 65535 이상이면 잘리는걸까?

A 구간에서, MQTT 메시지 수신 이벤트 함수다.

메시지를 수신받으면

UTF8 인코딩 후

이벤트를 발생시킨다.

내가 사용중인 MQTT 라이브러리의

기본 버퍼 사이즈는 256*1024다.

따라서, 크기가 65535 가 넘는 값이 들어와도

정상적으로 A 구간에서 데이터를 넘겨준 것이다.

B 구간도, 단순하게 버퍼 사이즈를 늘려주면 되는거였다 ㅠ

수정 2

ReceiveBufferSize와, SendBufferSize를 다시 꼼꼼히 확인해봤다.

내가 지정한 크기값, int 형으로 65535를 설정했다.

int 형을 들여다보니

32비트형 int였다...

4,294,967,295 까지 표현 가능...........................

256*1024로 살짝 늘려주고

모든 오류가 해결됐다. ㅠ

패킷 나눠서 수신받는 경험을 할 수 있어서 좋았지만

생각보다 단순하고 허무한 해결책이 있는걸 깨달았을때는

순간 시간이 너무 아까웠다 라는 생각이 들었다.

처음 이슈 났을 때, Exception로그만 봤을때는 정확한 원인을 알 수 없어서

데이터 크기가 원인인줄 몰랐다.

한두시간을 헤맸었는데

그 시간이 아깝다는 생각이 들었었다.

근데 또 시간이 지나니까 오히려 좋은 경험인 것 같다.

자료형을 더 꼼꼼히 신경쓰게되고

내가 정말 잘 모르는구나를 더 와닿게 느낄 수 있었다.

이런 기본적인 개념에 관한 글을 쓰는게 부끄러워 숨기고싶긴한데

드러내야 발전이 있을거라 생각해서 흑

자료형 더 꼼꼼히 신경쓰고 관심 가져야겠다

Encoding

Re::cord — Wed, 14 Feb 2024 22:14:29 +0900

개발을 하면서, UTF나 유니코드 등의 용어를 자주 접하지만

깊게 알아보거나 궁금한 적이 없었던 것 같다

오늘 업무하면서

Encoding관련 에러가 발생해서

이참에 궁금해서 알아보았다

유니코드

초창기 컴퓨터는 '영어'와 '특수문자'를 사용했다

시간이 흘러 다양한 국가의 언어를 지원하게 되면서

국제 표준이 만들어졌고, 그게 유니코드

UTF-7, UTF-8, UTF-16, UTF-32

인코딩 방식.

유니코드를 어떻게 컴퓨터에 저장할 것인가에 대한 내용

에러 원인

private void MQTTOnReceived(byte[] recv)
{
    string recvData = Encoding.Default.GetString(recv).Replace("\u0000", System.String.Empty);
}

MQTT 데이터 수신 이벤트다.

불필요한 코드는 삭제했다.

Encoding.Default로 데이터를 받아올때,

데이터 안에 한글이 있으면 에러가 발생한다.

FactoryName 값에 한글이 저장돼서

인코딩 과정에 오류가 발생했다.

왜 Encoding.Default는 오류가 발생하는지 이해가 안돼서

Encoding.Default가 뭔지 알아봤다.

Encoding.Default 방식

public static Encoding Default
{
    [SecuritySafeCritical]
    get
    {
        if (defaultEncoding == null)
        {
            defaultEncoding = CreateDefaultEncoding();
        }

        return defaultEncoding;
    }
}

[SecurityCritical]
private static Encoding CreateDefaultEncoding()
{
    int aCP = Win32Native.GetACP();
    return aCP switch
    {
        1252 => new SBCSCodePageEncoding(aCP),
        65001 => s_defaultUtf8EncodingNoBom,
        _ => GetEncoding(aCP),
    };
}

[SecuritySafeCritical]
[__DynamicallyInvokable]
public static Encoding GetEncoding(int codepage)
{
    Encoding encoding = EncodingProvider.GetEncodingFromProvider(codepage);
    if (encoding != null)
    {
        return encoding;
    }

    if (codepage < 0 || codepage > 65535)
    {
        throw new ArgumentOutOfRangeException("codepage", Environment.GetResourceString("ArgumentOutOfRange_Range", 0, 65535));
    }

    if (encodings != null)
    {
        encoding = (Encoding)encodings[codepage];
    }

    if (encoding == null)
    {
        lock (InternalSyncObject)
        {
            if (encodings == null)
            {
                encodings = new Hashtable();
            }

            if ((encoding = (Encoding)encodings[codepage]) != null)
            {
                return encoding;
            }

            switch (codepage)
            {
                case 0:
                    encoding = Default;
                    break;
                case 1200:
                    encoding = Unicode;
                    break;
                case 1201:
                    encoding = BigEndianUnicode;
                    break;
                case 1252:
                    encoding = new SBCSCodePageEncoding(codepage);
                    break;
                case 65001:
                    encoding = UTF8;
                    break;
                case 1:
                case 2:
                case 3:
                case 42:
                    throw new ArgumentException(Environment.GetResourceString("Argument_CodepageNotSupported", codepage), "codepage");
                case 20127:
                    encoding = ASCII;
                    break;
                case 28591:
                    encoding = Latin1;
                    break;
                default:
                    encoding = GetEncodingCodePage(codepage);
                    if (encoding == null)
                    {
                        encoding = GetEncodingRare(codepage);
                    }

                    break;
            }

            encodings.Add(codepage, encoding);
            return encoding;
        }
    }

    return encoding;
}

모든 코드를 볼 수 없어서

보이는 내용만 요약해보자면

윈도우 운영체제의 기본 인코딩 방식을 반환하는 것 같다.

찾아보니 윈도우는 ANSI? 라는 인코딩 방식을 기본으로 사용하고,

이 방식은 영어를 지원, 한글은 지원하지 않는다.

UTF-8로 수정

private void MQTTOnReceived(byte[] recv)
{
    string recvData = Encoding.UTF8.GetString(recv).Replace("\u0000", System.String.Empty);
}

한글을 지원하는 UTF-8방식으로 수정 후,

FactoryName 한글 관련 오류가 사라졌다.

그 외에도, EUC-KR, CP949 등 한글지원 인코딩 방식이 있다고 한다.

개발 언어, 로직 등에만 관심을 갖다가

이런 기본 컴퓨터 개념을 놓치고 개발을 하고 있었다

기본기를 잘 다지자 ㅠ

C# - class & structure

Re::cord — Sat, 10 Feb 2024 14:20:05 +0900

사내에서 지금까지 개발한 데이터 수집 엔진( 프로그램 )이

총 3가지 있다.

요약하자면 A->B->C 순으로 업그레이드 됐는데,

여전히 A, B 엔진이 적용된 곳이 있어서

그 중에서 B 엔진을 C 엔진에 맞게 업그레이드? 병합? 하는 작업을 진행했다.

병합 작업을 진행하면서, 나의 부족한 C# 개발 지식으로 다양한 오류를 접하게 됐다.
참조한 reference가 null 오류

컬렉션 수정 오류 등

너무 오류가 많아서 골치아팠다.

오류의 원인을 찾아보았다.

1. 비효율적인 class 사용

코드를 작성할 때

최소한의 class 단위로 구분해서 작성하라는

입사 초반 지시에 맞게 개발을 진행해왔다.

그러다보니 아무이유없이

무조건 class만 사용해서 개발해왔다.

변수 선언이나 구조를 잡을때도 무조건 class만 사용해왔다.

그러다보니 자연스레 문제점이 발생했다.

B엔진에서 외부 데이터를 MQTT로 수신
외부 데이터를 병합할 C 엔진 구조에 맞게 파싱

엔진을 병합하는 기준을 위처럼 크게 2가지로 나눌 수 있는데

외부 데이터를 MQTT로 수신 후,

값만 저장해서 Parsing 및 저장하는 로직을 개발중이었다.

즉, 외부 데이터를 MQTT로 수신할때마다

데이터를 갖고있는 class 객체를 매번 생성해주면서

새로운 객체를 계속 갖고있게끔 개발을 했다.

객체 생성이야 문제는 없지만

그 생성된 객체가, 값 저장 외에는 별다른 역할이 없기 때문에

아주 비효율적이라고 생각이들었다.

하지만 해결책이라고 떠오른 아이디어도
틀에박혀서 class 사용을 벗어나지 못했다.

해결책 1

-객체를 1개만 생성, 외부 데이터 수신마다 값만 update

객체를 매번 new 하지 않고, 객체를 최초 1회 생성 후,

객체가 필요한 class들이 생성될때마다

최초 생성된 인스턴스를 전달해주는 방식으로

해결책을 적용해보았다.

하지만

인스턴스가 필요한 DevicePacketClass가 매번 new 되기 때문에

인스턴스를 1개만 갖고있는다고 해도

결국 여러개의 DevicePacketClass 들이

동일한 인스턴스 1개를 공유하는 셈이다.

물론 class라서 힙 메모리에 저장되니까

reference가 참조되어

원본값을 그대로 갖고있는게 또 문제긴 하다.

실패

해결책 2

-struct 사용

몇시간 고민한 끝에,

몇시간 틀에박힌 생각을 거듭한 끝에서야

class를 벗어날 수 있었다.

현재 내가 처한 오류의 근본적인 원인을 찾지 못했기 때문에

문제가 뭘까? 라는 생각을 버리고

내가 필요한 경우가 뭘까? 로 생각을 바꿔봤다.

내가 필요한건,

1.외부 데이터 MQTT 수신

2.수신한 데이터 값 저장 및 Parsing

난 "값"만 필요한 것이기 때문에

굳이 class로 선언해서,

그 class 안에 list를 만들고

그 list를 참조할 수 있게,

class 인스턴스를 new 하고, 등의 과정이 필요없는것이다.

그냥 structure로 파싱할 데이터 구조만 static으로 잡고,

그 structure에 값만 저장하고, 참조하면 되지 않을까? 로 결론이 났다.

해결책2 적용, 성공

structure 데이터를 List에 저장, static 선언

선언한 List를 가져오는 메소드 호출

다른 class에서 참조할 List를

static으로 선언,

List안의 값들이 가진 structure를 선언해서

굳이 class의 인스턴스를 만들 필요없게끔 수정했다.

많이 반성할 수 있었던 시간이었다.

물론 알 수 없는 원인을 찾는게 힘들었지만

어쨋든 개발하면서 코드상으로 가장 중요한건

한 줄 한 줄 마다

내가 '왜' 이 코드를 사용했는지

이유를 명확히 알고있는게 굉장히 중요하다는걸 다시 느낄 수 있었다.

원래 알고 있었지만,

chatGPT를 사용하면서

AI가 제공해주는 코드를 한 줄 한 줄

다시 구글링해보며 사용해왔지만

이번일처럼 나도 모르게
'그냥' '지금껏 그랬으니까' 식의 개발습관이 들어서는 절대 안되겠다고 다짐했다.

소프트웨어 설계 수정

Re::cord — Mon, 8 Jan 2024 20:50:52 +0900

2024.01.01 - [개발/C#] - 모니터링 자동화 - API Parsing

모니터링 자동화 - API Parsing

2023.12.24 - [개발/C#] - 모니터링 자동화 - 비동기 변경 모니터링 자동화 - 비동기 변경 2023.12.21 - [개발 기록/C#] - 모니터링 자동화 - Excel Write 모니터링 자동화 - Excel Write 2023.12.18 - [개발 기록/C#] - 모

iruk.tistory.com

지금까지는 자동화 개발을 할 때

하나의 C# 윈폼 프로그램에서 진행했다

프로그램이 어느정도 개발은 됐는데

고도화를 진행하다보니 많이 수정이 필요해졌다

구조 변경

기존엔 하나의 프로그램에서

API 호출, DB 저장, 조회 등을 수행했는데

지금은 2가지 종류로 분리하려한다.

API 호출 & DB 저장을 하나의 프로그램에서 진행

데이터 조회 & 파일 Write를 다른 프로그램에서 진행한다.

데이터 수집 프로그램은 백그라운드에서 동작하며

주기적으로 API 호출 및 DB에 값을 Insert한다.

굳이 분리한 이유는

데이터 수집 그 자체가 목적이기 때문에

사용자가 데이터 수집 관련된 동작을

프로그램 화면 내에서 하지 않도록 하기 위함이다.

결국 사용자가 더 편리하고 직관적으로 프로그램을 사용할 수 있도록?

지금은 DB ERD 를 깔짝 만들고 있는데

이번에 개발하면서

초반 설계와 무수한 고뇌의 시간들이

개발 시간을 단축시켜주고

버그도 많이 잡아준다고 느껴서

너무 힘들지만 최대한 많은 생각을 하려고 노력중이다