Jasmin Time

육아휴직 후 복직, 나는 다시 일을 잘할 수 있을까?

FreeBear — Wed, 27 May 2026 15:04:34 +0900

육아휴직 중 문득 이런 생각이 들었다.

“복직해서 내가 예전처럼 일을 잘할 수 있을까?”

개발자로 일하다가 육아휴직에 들어오면, 단순히 회사에 잠시 쉬다 오는 느낌이 아니다.
매일 코드를 보고, 이슈를 확인하고, 회의하고, 배포하던 리듬에서 벗어나 완전히 다른 생활을 하게 된다.

아이를 돌보는 시간은 분명 소중하지만, 한편으로는 불안도 생긴다.

기술이 바뀌었으면 어쩌지?
프로젝트 구조가 많이 달라졌으면 어쩌지?
내가 예전만큼 집중하지 못하면 어쩌지?
육아와 일을 병행하면서 회사에 민폐가 되지는 않을까?

이 글은 복직을 앞두고 내가 느낀 불안과, 그 불안을 줄이기 위해 어떤 준비를 하면 좋을지 정리한 글이다.

복직 후 바로 예전처럼 일하지 못해도 괜찮다

육아휴직 후 복직을 생각하면 가장 먼저 드는 걱정은 이것이다.

“내가 일을 잘할 수 있을까?”

결론부터 말하면, 할 수 있다고 생각한다.
다만 복직 첫날부터 예전과 같은 속도와 집중력을 기대하는 것은 현실적이지 않다.

개발자는 단순히 코드를 치는 사람만은 아니다.
프로젝트 구조, 도메인 지식, 업무 히스토리, 팀의 개발 방식, 배포 흐름, 사람들 사이의 암묵적인 규칙까지 함께 이해해야 일을 할 수 있다.

육아휴직으로 잠시 그 흐름에서 떨어져 있었다면, 복직 직후 느려지는 것은 당연하다.
그건 실력이 사라진 것이 아니라, 업무 컨텍스트를 다시 복구하는 과정이다.

그래서 복직 초기에는 스스로를 이렇게 평가해야 할 것 같다.

예전 속도로 바로 일하고 있는가?
하루하루 프로젝트 감각을 회복하고 있는가?
모르는 부분을 정리하고 질문하고 있는가?
작은 업무를 끝까지 완료하고 있는가?
실수를 줄이는 방식으로 일하고 있는가?

복직 직후의 기준은 속도가 아니라 회복력이어야 한다.

육아휴직 후 복직이 더 어렵게 느껴지는 이유

복직이 불안한 이유는 단순히 기술 감각이 떨어졌을까 봐서만은 아니다.

육아 후 복직은 생활 전체가 바뀌는 일이다.
예전에는 야근을 하거나, 퇴근 후 공부를 하거나, 주말에 부족한 부분을 메울 수 있었다. 하지만 육아를 하면서는 그런 방식이 쉽지 않다.

아이의 등하원, 병원, 갑작스러운 열, 수면 부족, 집안일, 체력 저하가 모두 업무에 영향을 준다.

그래서 복직 후에는 예전처럼 “시간을 많이 써서 해결하는 방식”이 통하지 않을 수 있다.
이제는 더 체계적으로 일해야 한다.

많이 일하는 것보다 중요한 것은 다음과 같다.

우선순위를 명확히 정하기
작은 단위로 업무를 쪼개기
진행 상황을 자주 공유하기
모르는 것은 오래 붙잡지 않고 질문하기
육아 변수를 미리 대비하기
무리해서 버티지 않기

육아 후 복직은 능력이 부족해서 어려운 것이 아니라, 관리해야 할 변수가 많아졌기 때문에 어려운 것이다.

복직 전 준비 1: 기술 감각 다시 깨우기

복직 전 가장 먼저 하고 싶은 준비는 개발 감각을 다시 깨우는 것이다.

다만 너무 많은 것을 한 번에 공부하려고 하면 오히려 불안만 커질 수 있다.
목표는 최신 기술을 완벽하게 따라잡는 것이 아니라, 내 손이 다시 코드를 기억하게 만드는 것이다.

C# WPF 개발자라면 다음 항목들을 가볍게 복습해두면 좋을 것 같다.

C# 기본 문법
async / await
Task
LINQ
예외 처리
파일 입출력
INotifyPropertyChanged
ICommand
ObservableCollection
데이터 바인딩
MVVM 구조
이벤트 구독과 해제
null 처리
nullable reference types

특히 WPF는 View, ViewModel, Command, Service의 흐름을 다시 손에 익히는 것이 중요하다.

복직 전 거창한 프로젝트를 만들 필요는 없다.
작은 미니 프로젝트 하나면 충분하다.

예를 들어 이런 정도면 좋다.

간단한 할 일 관리 앱
파일 선택 후 목록을 표시하는 앱
설정값을 저장하고 불러오는 앱

이 작은 프로젝트 안에 다음 요소를 넣어보면 감각 회복에 도움이 된다.

MVVM 구조
버튼 Command
TextBox 바인딩
ObservableCollection 사용
파일 저장/불러오기
예외 처리
간단한 로그
비동기 처리

중요한 건 완성도 높은 앱을 만드는 것이 아니다.
코드를 다시 읽고, 쓰고, 실행해보는 경험을 하는 것이다.

복직 전 준비 2: 회사 프로젝트 상황 파악하기

기술 감각만큼 중요한 것이 회사 업무 감각이다.

복직 전 가능하다면 현재 프로젝트 상황을 조금이라도 파악해두는 것이 좋다.

확인하면 좋은 것은 다음과 같다.

내가 맡았던 프로젝트가 지금도 유지되고 있는지
주요 기능이 바뀌었는지
사용 중인 .NET 버전이 바뀌었는지
WPF 구조가 변경되었는지
배포 방식이 바뀌었는지
Git 브랜치 전략이 바뀌었는지
이슈 관리 도구가 바뀌었는지
팀원이 바뀌었는지
복직 후 맡을 가능성이 높은 업무가 무엇인지

복직 1~2주 전쯤 팀장이나 동료에게 가볍게 물어볼 수 있다.

복직 전에 업무 적응을 위해 현재 프로젝트 상황을 간단히 파악하고 싶습니다.
제가 복직 후 우선 확인하면 좋을 문서나 최근 변경된 주요 내용이 있을까요?

이렇게 물어보는 것은 부담스럽지 않으면서도, 복직을 진지하게 준비하고 있다는 인상을 줄 수 있다.

복직 전 준비 3: 첫 달 목표를 낮고 현실적으로 잡기

복직 첫 달은 성과를 크게 내는 달이라기보다, 다시 시스템에 연결되는 달이라고 생각하는 것이 좋다.

첫 주의 가장 중요한 목표는 이것이다.

“내 로컬 환경에서 프로젝트가 정상적으로 빌드되고 실행되는 것.”

이를 위해 확인해야 할 것들이 있다.

개발 PC 세팅
계정 권한
Git 접근
프로젝트 빌드
로컬 실행
DB/API 접근
배포 문서
최근 커밋
진행 중인 이슈 목록

처음부터 큰 기능을 맡으려고 하기보다, 작은 업무부터 시작하는 것이 좋다.

복직 직후 맡기 좋은 업무는 이런 것들이다.

간단한 버그 수정
UI 텍스트 수정
유효성 검사 추가
로그 추가
작은 화면 수정
기존 기능의 작은 개선
재현 가능한 오류 수정

작은 업무를 안정적으로 끝내면서 다시 신뢰와 감각을 쌓아가는 것이 중요하다.

복직 전 준비 4: 육아 변수에 대한 대비

복직 후 가장 큰 변수는 기술보다 육아일 수 있다.

아이가 갑자기 아플 수도 있고, 어린이집에서나 아이를 대신 봐주고 계신 어머니 혹은 이모님에게서 긴급 연락이 올 수도 있다.
밤잠을 설쳐 다음 날 집중이 어려울 수도 있다.

그래서 복직 전에는 육아와 관련된 긴급 대응 계획을 최대한 구체적으로 정해두는 것이 좋다.

미리 정해야 할 것들은 다음과 같다.

아이가 아플 때 1차 대응자는 누구인지
병원은 누가 데려가는지
등원과 하원은 누가 맡는지
야근이 필요한 날은 어떻게 조율할지
긴급 상황에서 도움을 요청할 사람이 있는지
가족, 배우자, 도우미, 어린이집과 역할 분담이 되어 있는지

막연히 “그때 가서 어떻게든 하자”라고 생각하면 대부분의 부담이 나에게 몰릴 수 있다.

가능하면 이렇게 구체적으로 정하는 것이 좋다.

아이가 열이 나면 오전 병원은 배우자가 담당한다.
하원은 기본적으로 배우자가 맡고, 불가피한 날은 미리 공유한다.
중요한 배포일에는 사전에 가족에게 도움을 요청한다.
야근 가능일은 주 1회 이하로 제한한다.

육아와 일을 병행하려면 개인의 정신력보다 시스템이 필요하다.

복직 전 준비 5: 체력과 생활 리듬 맞추기

복직은 마음의 문제이기도 하지만, 실제로는 체력의 문제인 경우가 많다.

수면이 부족하면 집중력이 떨어진다.
아침 준비가 꼬이면 출근 전부터 지친다.
퇴근 후 집안일과 육아가 이어지면 공부할 힘이 남지 않는다.

그래서 복직 1~2주 전부터는 실제 복직 후 생활에 맞춰 리듬을 조정해보는 것이 좋다.

기상 시간 맞추기
아이 등원 준비 시간 체크하기
출근 준비 시간 체크하기
출근 또는 재택 시작 시간에 맞춰 리허설하기
저녁 루틴 정리하기
다음 날 준비물을 전날 밤에 챙기기

복직 초기에 퇴근 후 공부를 무리하게 계획하지 않는 것도 중요하다.

현실적인 계획은 이 정도가 좋을 것 같다.

평일: 하루 20~30분 정도 코드 감각 유지
주말: 1~2시간 정도 정리 또는 미니 프로젝트
복직 첫 달: 무리한 추가 공부 금지

처음부터 모든 것을 잘하려고 하면 금방 지칠 수 있다.
복직 초기에는 지속 가능한 리듬을 만드는 것이 먼저다.

복직 후 첫 주에 물어보면 좋은 질문들

복직 후에는 머릿속이 복잡할 수 있다.
그래서 미리 질문 리스트를 만들어두면 도움이 된다.

현재 가장 우선순위가 높은 프로젝트는 무엇인가요?
제가 먼저 확인해야 할 문서나 이슈가 있을까요?
최근 주요 구조 변경이 있었나요?
빌드나 배포 방식이 바뀐 부분이 있나요?
제가 처음 맡으면 좋을 작은 업무가 있을까요?
코드 리뷰 방식에 변경이 있나요?
최근 자주 발생한 장애나 버그가 있었나요?
제가 휴직 전 담당했던 기능 중 변경된 부분이 있나요?

이런 질문은 내가 모른다는 것을 드러내는 것이 아니라, 업무를 체계적으로 다시 파악하려는 태도를 보여준다.

모르는 것을 숨기는 것보다, 정확히 확인하고 정리하는 사람이 더 신뢰를 준다.

복직 후 일 잘하는 방법

복직 후에는 “많이 하는 사람”이 되려고 하기보다, “예측 가능하게 일하는 사람”이 되는 것이 중요하다.

육아와 일을 병행하면 예상치 못한 변수가 생길 수 있다.
그럴수록 업무 진행 상황을 잘 공유하고, 작은 단위로 일을 끝내는 방식이 필요하다.

복직 후 도움이 될 만한 업무 습관은 다음과 같다.

오늘 할 일은 3개 정도만 정하기
모르는 것은 오래 붙잡지 말고 질문하기
질문 전 내가 확인한 내용을 정리하기
진행 상황을 짧게 공유하기
마감이 어려우면 빨리 말하기
작은 단위로 PR 올리기
테스트 결과를 함께 남기기
퇴근 전 다음 날 할 일을 적어두기

질문할 때도 단순히 “이거 모르겠어요”라고 하기보다, 내가 확인한 내용을 함께 전달하면 좋다.

A 기능에서 오류가 발생해 확인 중입니다.

현재까지 확인한 내용은 다음과 같습니다.

1. B 조건에서만 재현됩니다.
2. 로그상 C 메서드에서 예외가 발생합니다.
3. 최근 D 커밋 이후 발생한 것으로 보입니다.

제가 보기에는 E 방향으로 수정하면 될 것 같은데,
혹시 이 부분과 관련해서 제가 놓친 배경이 있을까요?

이렇게 질문하면 업무를 체계적으로 보고 있다는 인상을 줄 수 있다.

복직 전 4주 준비 플랜

복직 준비를 막연하게 생각하면 불안해진다.
그래서 4주 정도로 나누어 준비하면 좋을 것 같다.

복직 4주 전: 개발 감각 깨우기

C# 기본 문법 복습
WPF MVVM 기본 구조 다시 보기
RelayCommand 직접 작성해보기
간단한 ViewModel 작성하기
하루 30분 정도 코드 읽기

복직 3주 전: 작은 프로젝트 만들기

간단한 WPF 앱 하나 만들기
TextBox, Button, ListBox 바인딩하기
ObservableCollection 사용하기
파일 저장/불러오기 추가하기
예외 처리 추가하기

복직 2주 전: 업무 상황 확인하기

회사 프로젝트 변경 사항 확인 요청하기
사용 기술 버전 확인하기
Git, 이슈 관리 방식 변경 여부 확인하기
복직 후 맡을 업무 대략 확인하기
육아 긴급 대응 플랜 정리하기

복직 1주 전: 컨디션 조절하기

수면과 기상 루틴 맞추기
등원과 출근 리허설하기
공부량 줄이기
불안한 점 목록화하기
복직 첫 주 질문 리스트 만들기

복직을 앞둔 나에게 해주고 싶은 말

복직을 생각하면 여전히 불안하다.

하지만 불안하다는 것은 그만큼 일을 잘하고 싶다는 뜻이기도 하다.
대충 하고 싶었다면 이렇게 고민하지 않았을 것이다.

육아휴직은 일을 쉰 시간이기도 하지만, 동시에 완전히 다른 종류의 책임을 감당한 시간이기도 하다.
그 시간 동안 내가 부족해진 것이 아니라, 다른 방식으로 많은 것을 해내고 있었던 것이다.

복직 후 처음부터 예전의 나를 증명하려고 하지 말자.
대신 매주 조금씩 업무 감각을 회복하는 나를 만들어가면 된다.

처음부터 완벽하지 않아도 된다.
작은 업무를 끝까지 해내고, 모르는 것을 정리해서 질문하고, 실수를 줄이는 방식으로 일하면 된다.

복직은 다시 시작하는 일이 아니라,
잠시 멈춰 있던 흐름에 다시 연결되는 과정이다.

나는 다시 할 수 있다.
다만 예전처럼 모든 것을 혼자 버티는 방식이 아니라, 더 체계적으로 일하고, 육아 변수도 시스템으로 관리하고, 작은 성공을 쌓아가며 복귀하면 된다.

스니핑(Sniffing)과 스푸핑(Spoofing), 왜 자꾸 헷갈릴까

FreeBear — Wed, 27 May 2026 14:44:07 +0900

컴퓨터나 네트워크 관련이나 정보보안 공부를 하다 보면 꼭 등장하는 두 단어가 있습니다.

바로 스니핑(Sniffing) 과 스푸핑(Spoofing) 입니다.

이름도 비슷하고 둘 다 해킹에서 함께 다루다 보니 처음 공부할 때 정말 많이 헷갈립니다.
저도 처음에는 자꾸 “둘 다 뭔가 가로채는 거 아니었나?” "스니핑이 스푸핑이었나? 아닌가?" 싶었습니다.

하지만 핵심 차이만 이해하면 생각보다 쉽게 구분할 수 있습니다.

오늘은 두 개념을 한 번에 기억할 수 있도록 정리해보겠습니다.

스니핑(Sniffing)이란?

스니핑은 쉽게 말해

네트워크 데이터를 몰래 엿보는 행위

입니다.

네트워크를 통해 오가는 패킷(Packet)을 가로채서 내용을 확인하는 방식입니다.

예를 들어,

로그인 ID/PW 탈취
공용 와이파이 패킷 감청
이메일 내용 도청

같은 공격이 스니핑에 해당합니다.

핵심 특징

데이터를 몰래 본다
상대를 속이지 않는다
주로 수동적 공격(Passive Attack)

즉, 조용히 숨어서 정보를 훔쳐보는 느낌입니다.

왜 이름이 스니핑일까?

“Sniff”는 영어로

냄새를 맡다

라는 뜻입니다.

강아지가 냄새 맡듯이 네트워크를 킁킁 탐색한다는 이미지로 이해하면 기억하기 쉽습니다.

암기 포인트

“스니핑 = 몰래 냄새 맡듯 엿보기”

스푸핑(Spoofing)이란?

스푸핑은

자신을 다른 대상으로 속이는 행위

입니다.

즉, 신분을 위조해서 상대를 믿게 만드는 공격입니다.

대표적인 예시는 다음과 같습니다.

IP Spoofing
ARP Spoofing
DNS Spoofing
이메일 주소 위조
가짜 사이트(피싱)

예를 들어 공격자가

“나는 정상 서버야”

라고 속여서 사용자의 정보를 탈취하는 방식입니다.

스푸핑의 핵심 특징

상대를 속인다
신분을 위장한다
직접 개입하는 능동적 공격(Active Attack)

즉, 단순히 보는 것이 아니라 적극적으로 개입해서 속이는 공격입니다.

둘의 차이를 한 번에 이해하기

구분	스니핑	스푸핑
의미	몰래 보기	속이기
목적	정보 탈취	신뢰 위장
공격 형태	수동적	능동적
핵심 이미지	도청	사기/위장
기억 키워드	냄새 맡기	신분 위조

같이 사용되는 경우도 많다

실제 공격에서는 두 기술이 함께 사용되기도 합니다.

대표적으로

스푸핑으로 사용자를 속이고
스니핑으로 데이터를 가로챔

이런 흐름이 자주 등장합니다.

예를 들어 ARP 스푸핑으로 중간자(MITM) 위치를 만든 뒤, 패킷을 스니핑해서 계정 정보를 훔치는 방식입니다.

즉,

“속이고 → 훔쳐본다”

라고 이해하면 훨씬 기억에 남습니다.

가장 쉽게 외우는 방법

저는 아래처럼 외우는 게 가장 직관적이었습니다.

스니핑

“조용히 본다”

스푸핑

“대놓고 속인다”

이 두 문장만 기억해도 시험이나 면접에서 헷갈릴 일이 거의 없습니다.

마무리

보안 용어는 처음에는 이름이 비슷해서 헷갈리지만, 핵심 행동만 구분하면 생각보다 단순합니다.

스니핑 → 몰래 보기
스푸핑 → 속이기

이렇게만 기억해도 대부분의 상황에서 정확히 구분할 수 있습니다.

혹시 여러분만의 암기법이 있다면 댓글로 공유해주세요

종합소득과세표준확정신고 및 납부계산서 조회 및 출력 방법

FreeBear — Wed, 27 May 2026 13:59:26 +0900

1. 국세청 홈택스 에 접속하기

1-1. 홈택스 신고안내 임시페이지일 때는 홈택스 바로가기 선택

2. 홈택스 로그인

2-1. 로그인 위치1

2-2. 로그인 위치2

3. 세금신고 메뉴 - 전자신고 결과 조회

4. 전자신고 결과 조회에서 종합소득과세표준확정신고 및 납부계산서 조회하기

① 세목에서 종합소득세를 선택

② 사업자 또는 주민등록번호 입력

③ 신고일자는 최대 2년 단위로 선택한다.

④ 조회하기

그러면 해당 기간에 신고내역이 있으면 결과를 확인할 수 있다.

여기서 조회 및 출력해야 하는 ⑤ 과세연월에 해당되는 것을 확인하고,

⑥ 접수번호(신고서보기)에 있는 번호를 클릭하면 종합소득과세표준확정신고 및 납부계산서를 볼 수 있다.

5. 개인정보 공개여부

종합소득과세표준확정신고 및 납부계산서 자체가 소득을 정확하게 확인하기 위해서 주로 은행에서 요구 하는 서류이므로 대부분은 개인정보 공개를 선택하고 적용하여 조회하면 되고, 단순 조회용이면 개인정보 비공개 선택 후 적용하면 된다.

6. 종합소득세 신고서 미리보기 화면

여기서 출력 버튼을 클릭하면 조회한 종합소득과세표준확정신고 및 납부계산서를 출력할 수 있다.

이때, 신고서 목록에 여러개가 있을 수 있는데 첫번째에 위치한 종합소득세·(지방소득세) 과세표준확정 신고 및 납부계산서는 필수로 선택하고 그 아래에 있는 것은 필요한 것만 선택하여 출력하면 된다.

대부분은 전체가 필요하므로 일괄출력 버튼 클릭 후 출력 버튼을 클릭하여 출력하면 된다.

SQL COALESCE 함수 A to Z: NULL이 아닐 때까지 대체값 찾기

FreeBear — Thu, 3 Jul 2025 11:24:43 +0900

들어가며

데이터를 처리하다 보면 여러 컬럼 중 첫 번째로 값이 존재하는(≠NULL) 컬럼을 골라 쓰고 싶을 때가 있습니다. 이럴 때 쓰기 좋은 함수가 COALESCE입니다. 이번 글에서는 COALESCE의 역할, 문법, 다양한 예제를 통해 활용법을 정리합니다.

1. COALESCE란?

COALESCE(expr1, expr2[, expr3, …]) 함수는 인자들을 왼쪽부터 순서대로 검사하여,

첫 번째로 NULL이 아닌 값을 반환
모두 NULL이면 → NULL 반환

하는 함수입니다.

2. 기본 문법

COALESCE(값1, 값2, 값3, …)

3. 실전 예제

예제 테이블: orders

3-1) 우선순위 메모 가져오기

SELECT
  order_id,
  COALESCE(customer_memo, admin_note, default_note) AS final_note
FROM orders;

해설
1. customer_memo가 있으면 → 그 값 사용
2. 없으면 admin_note 사용
3. 그래도 없으면 default_note 사용
4. 모두 없으면 → NULL

3-2) 실행 결과

4. 고급 활용

NULLIF와 조합
- COALESCE(NULLIF(col, ''), '기본값') → 빈 문자열을 NULL화 후 기본값으로 대체

SELECT
  u.user_id,
  COALESCE(
    NULLIF(p.profile_pic, ''),  -- 빈 문자열을 NULL로 바꿈
    'default.jpg'               -- NULL일 때만 이 값을 사용
  ) AS profile_image
FROM users u
LEFT JOIN profiles p
  ON u.user_id = p.user_id;

이렇게 하면,

프로필 이미지가 실제 URL인 경우 → 그대로
빈 문자열('') 또는 NULL인 경우 → 'default.jpg'로 대체
하여 원하는 “빈 문자열도 기본값으로 바꾸는” 로직을 구현할 수 있습니다.

마치며

COALESCE는 NULL 처리에서 거의 필수적인 함수입니다. 간단하지만 논리적으로 깔끔하게 여러 대체값을 지정할 수 있어, SQL 문을 한결 읽기 쉽고 유지보수하기 좋게 만들어줍니다. 두 함수(NULLIF + COALESCE)를 잘 조합하여 실무에서 NULL 처리 로직을 단순화해보세요!

SQL NULLIF 함수 완벽 가이드: 특정 값을 NULL로 대체하기

FreeBear — Thu, 3 Jul 2025 11:18:16 +0900

들어가며

SQL을 다루다 보면 “특정 값(예: 빈 문자열, 특정 코드 등)을 NULL로 간단히 바꾸고 싶다”는 경우가 자주 발생합니다. 이때 유용하게 쓰이는 함수가 바로 NULLIF입니다. 오늘은 NULLIF의 기본 개념부터 실전 예시까지 살펴보겠습니다.

1. NULLIF란?

NULLIF(expr1, expr2) 함수는 두 인수 expr1과 expr2를 비교하여,

expr1 = expr2 이면 → NULL 반환
그렇지 않으면 → expr1 반환

하는 아주 단순하지만 강력한 기능을 제공합니다.

2. 기본 문법

NULLIF(비교할_값1, 비교할_값2)

3. 실전 예제

예제 테이블: employees

3-1) 빈 문자열을 NULL로

SELECT
  id,
  name,
  NULLIF(bonus_code, '') AS bonus_code_nullified
FROM employees;

해설
- bonus_code가 빈 문자열('')인 경우 → NULL
- 나머지(‘A1’, ‘C3’, 실제 NULL)는 그대로

3-2) 실행 결과

4. 활용 포인트

빈 문자열, 특정 값('UNKNOWN', 'N/A' 등)만 NULL로 바꾸고 싶을 때
복잡한 CASE WHEN ... END 없이 간단히 처리 가능
다른 함수(COALESCE, ISNULL, NVL)와 조합해서 더욱 강력하게 활용

마치며

오늘은 NULLIF의 개념과 간단한 예시를 살펴봤습니다. 참고로 다음 글에서는 이와 매끄럽게 연계해 사용할 수 있는 COALESCE 함수를 다뤄볼 예정입니다!

C# 이중 반복문(중첩 루프) 개선 방법

FreeBear — Mon, 30 Jun 2025 13:23:29 +0900

개발을 하다 보면 이중 반복문을 통해 문제를 해결하는 상황이 종종 발생합니다.

foreach (var item in lists)
{
    foreach (var relation in item.Relations)
    {
        relation.Status = Common.Enums.DataStatus.Unchanged;
    }
}

위와 같은 이중 foreach 문이 기능상 문제가 있는 건 아니지만, 좀 더 깔끔하고 현대적인 C# 코드로 바꾸는 방법에 대해 알아보도록 하겠습니다.

1. SelectMany로 한 줄에 쭉 펼치기

LINQ의 SelectMany를 이용하면 중첩된 컬렉션을 평탄화(flatten)해서 단일 foreach로 처리할 수 있습니다.

foreach (var relation in lists.SelectMany(f => f.Relations))
{
    relation.Status = Common.Enums.DataStatus.Unchanged;
}

장점: ‘모든 Relation’을 한 번에 처리한다는 의도가 명확해집니다.
단점: LINQ가 익숙하지 않은 팀원에게는 다소 낯설 수 있어요.

2. List<T>.ForEach 체이닝

만약 Functions와 Relations가 List<T> 타입이라면, ForEach 메서드를 중첩해서 사용할 수도 있습니다.

lists.ForEach(f =>
    f.Relations.ForEach(r =>
        r.Status = Common.Enums.DataStatus.Unchanged
    )
);

장점: 코드가 아주 간결해집니다.
단점: List<T> 전용이고, 중첩 람다가 가독성을 해칠 수 있어요.

3. 평탄화 후 리스트로 변환하고 ForEach 사용

SelectMany로 평탄화한 뒤 ToList()로 즉시 컬렉션을 만들고, List<T>.ForEach를 이어붙이는 방법입니다.

lists
  .SelectMany(f => f.Relations)
  .ToList()
  .ForEach(r => r.Status = Common.Enums.DataStatus.Unchanged);

장점: IEnumerable<T>에도 적용 가능하고, 코드가 플루언트하게 흘러갑니다.
단점: 중간에 임시 리스트가 하나 더 생성됩니다.

4. 범용 ForEach 확장 메서드 만들기

프로젝트 전반에서 IEnumerable<T>에 ForEach를 쓰고 싶다면, 확장 메서드를 정의해두세요.

public static class EnumerableExtensions
{
    public static void ForEach<T>(this IEnumerable<T> source, Action<T> action)
    {
        foreach (var item in source)
            action(item);
    }
}

이제 이렇게 쓸 수 있습니다.

lists
  .SelectMany(f => f.Relations)
  .ForEach(r => r.Status = Common.Enums.DataStatus.Unchanged);

장점: List<T>뿐 아니라 모든 IEnumerable<T>에 일관된 스타일 적용 가능!
단점: 초기 설정(확장 메서드 추가)이 필요합니다.

5. 병렬 처리로 속도 높이기

데이터 양이 매우 많아서 성능이 관건이라면 PLINQ를 활용해 병렬 처리도 고려해볼 수 있습니다.

lists
  .AsParallel()
  .SelectMany(f => f.Relations)
  .ForAll(r => r.Status = Common.Enums.DataStatus.Unchanged);

장점: 멀티코어 CPU를 활용해 처리 속도를 끌어올릴 수 있습니다.
단점: 동시성 이슈(스레드 세이프티)를 반드시 검토해야 하고, 소규모 데이터에는 오히려 오버헤드가 될 수 있어요.
같이 보면 좋을 내용: 작은 루프 본문 속도 개선

방법: 작은 루프 본문 속도 개선 - .NET

자세히 알아보기: 방법: 작은 루프 본체 속도 향상

learn.microsoft.com

마무리: 내 프로젝트에는 어떤 방법이 좋을까?

가독성과 간결함을 최우선으로 한다면 → 방법 1 (SelectMany + 단일 foreach)
람다 체이닝이 편하고 List<T>만 사용한다면 → 방법 2 (List.ForEach)
함수형 스타일을 전사적으로 도입하고 싶다면 → 방법 4 (확장 메서드)
대량 데이터 성능이 중요하다면 → 방법 5 (병렬 처리)

늘 그렇듯, <정답>은 없지만

팀의 코드 스타일, 프로젝트 특성, 성능 요구사항 등을 고려해 가장 적합한 방법을 선택하면 되지 않을까 싶습니다.

C# Dictionary와 LINQ로 구현하는 고객 유형별 상품 타입 필터링 패턴

FreeBear — Mon, 30 Jun 2025 11:56:48 +0900

1. 개요

고객 유형(CustomerType)에 따라 시스템에서 제공해야 하는 ItemType 목록을 동적으로 필터링하는 로직을 구현한 경험을 공유합니다.

목표: VIP, Regular 등 고객 유형별로 기본 제공되는 상품 타입을 정의하고, 특정 권한(Permission) 값에 따라 필터링 규칙을 적용
장점: 타입 안전성 보장, 유지보수성 향상, 코드 가독성 및 확장성 확보

2. 요구사항

고객 유형별 기본 상품 타입
- Regular: A, B, C, D
- VIP: A, B, E, F, G, H, I, J
Permission이 “20”인 경우
- 위 허용 목록에 포함된 ItemType만 노출
그 외 Permission
- 전체 ItemType 노출
향후 고객 유형 추가나 허용 항목 변경이 용이해야 함.

3. 설계 아이디어

고객 유형별 허용 ItemType을 Dictionary<CustomerType, HashSet<ItemType>>로 중앙집중 관리
데이터베이스에서 가져온 Code 객체(CodeID: string, Permission: string)를 LINQ로 간단히 필터링
Enum.TryParse + HashSet.Contains 조합으로 엄격한 타입 검증 및 빠른 조회
조건문(Permission != "20" || …) 하나로 “그 외” 케이스도 자연스럽게 처리

4. 주요 코드 예시

/// <summary>
/// 고객 타입별 기본 상품 타입 목록을 정의합니다.
/// </summary>
private readonly Dictionary<CustomerType, HashSet<ItemType>> _allowedItemTypes;

public MyServiceConstructor()
{
    _allowedItemTypes = new()
    {
        [CustomerType.Regular] = new HashSet<ItemType>
        {
            ItemType.A, ItemType.B, ItemType.C, ItemType.D
        },
        [CustomerType.Vip] = new HashSet<ItemType>
        {
            ItemType.A, ItemType.B, ItemType.E, ItemType.F,
            ItemType.G, ItemType.H, ItemType.I, ItemType.J
        }
    };
}

public IEnumerable<ItemType> GetItemTypeList(CustomerType customerType)
{
    // 1) DB에서 전체 코드 리스트 조회
    IEnumerable<Code> codes = _codeService.Value
        .SelectCode(SystemConstants.ModuleTypeA, SystemConstants.CodeTypeA);

    // 2) 고객 유형에 매핑된 허용 목록이 있으면 필터링 적용
    if (_allowedItemTypes.TryGetValue(customerType, out var allowedEnums))
    {
        codes = codes.Where(x =>
            // Permission이 "20"이 아니면 모두 포함
            x.Permission != "20"
            // Permission이 "20"이면, 파싱 성공 & 허용 목록에 포함된 항목만 포함
            || (Enum.TryParse<ItemType>(x.CodeID, ignoreCase: true, out var parsed)
                && allowedEnums.Contains(parsed))
        );
    }

    // 3) Code → ItemType 변환
    var result = codes
        .Select(code => (ItemType)Enum.Parse(typeof(ItemType), code.CodeID, ignoreCase: true))
        .ToList();

    return result;
}

5. 코드 설명

맵 초기화
- 생성자에서 Dictionary<CustomerType, HashSet<ItemType>>를 초기화
- 신규 고객 유형 추가 시 이곳만 수정하면 됨
필터 로직
- TryGetValue로 고객 유형에 대한 허용 목록을 가져옴
- LINQ Where 내부에서 한 줄로 두 가지 케이스를 처리
  - x.Permission != "20": 모든 코드 통과
  - x.Permission == "20": Enum.TryParse로 CodeID를 ItemType으로 변환 후, 허용 목록 검사
최종 반환
- 필터링된 Code 리스트를 ItemType 리스트로 변환

6. 장단점 및 확장 포인트

구분장점유의/확장 포인트

유지보수성	중앙집중형 맵으로 허용 항목 관리 → 변경 시 한 곳만 수정 가능	맵이 커지면 초기화 코드가 길어질 수 있음
성능	HashSet → O(1) 포함 검사, Enum.TryParse 오버헤드 최소화	아주 큰 규모(수만 건 이상)라면 DB 레벨 필터링 고려
타입 안정성	string → enum 파싱 후 검사 → 잘못된 값 걸러짐	Enum.Parse 실패 시 예외 방지 로직 추가 고민 가능
확장성	신규 CustomerType 추가/허용 목록 변경 손쉽게 대응	고객별 커스텀 로직이 복잡해지면 전략 패턴 도입 고려

7. 결론

이 방식은 간단한 사전(Dictionary) + LINQ 조합만으로도 복잡한 비즈니스 로직을 깔끔하게 표현할 수 있었습니다.

소규모 프로젝트: 코드 한 줄, 맵 수정만으로 요구사항 반영 가능
대규모 시스템: 이후 DB 매핑 테이블이나 Specification 패턴 등으로 리팩토링해도 기반 아이디어는 동일

Visual Studio 2022를 사용할 때 발생하는 오류, 'VsPackage' 패키지가 제대로 로드되지 않았습니다.

FreeBear — Wed, 25 Sep 2024 10:38:56 +0900

어제 잘만 사용하던 비주얼 스튜디오가, 오늘도 사용하려니 이런 메시지가 뜬다.

'VsPackage' 패키지가 제대로 로드되지 않았습니다.

이 오류가 떠도 메시지를 무시하고 프로젝트 열어서 코딩하고, 빌드하고, 디버깅 하는 것에는 문제가 없다.

다른 문제가 있다면, 확장 프로그램으로 다국어 리소스 파일을 만드는데 도움이 되는 ResX Manager를 사용 중인데 이게 열리지 않는다.

없으면 없는대로 언어별로 리소스파일 열어서 수정하면 되지만 그것은 너무 불편하다.

문제를 해결하는 것이 좋겠다.

메시지에 나온 로그 파일을 검토하면 자세한 내용을 확인할 수 있다고 하여 열어 보았다.

비주얼 스튜디오를 열때 당시의 작업 로그들을 볼 수 있다. 그 중에서 노란색은 경고지만 이게 원인은 아니니까 무시해도 될 것 같고, 빨간색을 본다.

이 메시지만 봐서는 어떻게 해결해야할지 모르겠다.

오류 메시지 부분만 긁어서 챗지피티에게 물어보자!

이 오류는 Visual Studio 확장을 로드하는 동안 어셈블리 참조 문제가 발생했음을 나타냅니다. 주로 System.Composition.AttributedModel, Version=8.0.0.0 어셈블리 또는 해당 종속성이 제대로 로드되지 않아 생기는 문제입니다. 이 오류는 어셈블리의 버전 불일치, 어셈블리 파일의 손상 또는 누락된 참조에서 발생할 수 있습니다.

해결을 위해 다음 방법을 시도할 수 있습니다.

1. NuGet 패키지 확인 및 업데이트

o 프로젝트에서 System.Composition.* 관련 패키지가 제대로 설치되었는지 확인하세요. 최신 버전으로 업데이트하거나 필요한 경우 적절한 버전으로 다운그레이드하세요.

o Visual Studio에서 Tools > NuGet Package Manager > Manage NuGet Packages for Solution으로 이동하여 설치된 패키지를 확인하고 업데이트하세요.

2. 패키지 캐시 삭제

o NuGet 패키지 캐시를 삭제해보고, System.Composition.* 패키지를 다시 설치하세요. 패키지 캐시는 명령 프롬프트에서 다음 명령으로 삭제할 수 있습니다.

nuget locals all -clear

3. 어셈블리 바인딩 재지정

o app.config 또는 web.config 파일에서 어셈블리 바인딩을 추가하여 버전 불일치를 해결할 수 있습니다.
예시:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Composition.AttributedModel" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

4. Visual Studio 재설치

o Visual Studio에 설치된 확장이 문제일 수 있으므로, 해당 확장을 제거 후 다시 설치하거나 Visual Studio 자체를 재설치해보세요.

이 문제를 해결하는 과정에서 위 단계를 순서대로 시도해보면 원인을 좁혀 나갈 수 있을 것입니다.

이런 답변을 얻을 수 있었다.

안 되는 확장 프로그램 ResX Manager를 제거하고, 다시 설치했다.

오류 메시지가 뜨지 않고, ResX Manager도 잘 열린다.

'VsPackage' 패키지가 제대로 로드되지 않았습니다. 오류 메시지가 발생될 때는 로그 파일을 확인해서 원인이 되는 패키지나 확장 프로그램을 확인하고 해당 프로그램을 제거하고 다시 설치하면 해결되는 것을 알 수 있었다.

WPF에서 DevExpress의 RichEditControl에서 작업한 데이터를 Spire.Doc을 통해서 문서 파일로 변환 할 때 일어나는 현상 및 해결 방법

FreeBear — Wed, 28 Aug 2024 17:38:54 +0900

DevExpress에서는 MS의 워드 프로그램에서 작업하는 것처럼 본인이 WPF로 만드는 프로그램에서도 비슷한 작업을 할 수 있게 해주는 기능을 제공한다.

RichEditControl을 사용하면 되는 것.

사실 RichEditControl을 통해서 내용을 바로 문서 파일로 저장할 수 있기 때문에 RichEditControl을 통해서만 텍스트 편집 작업을 하면 Spire.Doc과 같은 문서 작업 전용 라이브러리는 필요 없다.

그러나 내가 현재 유지보수 중인 프로그램은 여러 화면에서 작업한 내용을 취합해서 하나의 문서 파일로 만들어 내어야 한다. 문서 파일은 워드 뿐만 아니라 파워포인트, 엑셀, PDF 등일 수 있다.

그렇게 상용 라이브러리 중에서 Spire.Doc을 사용 중이다.

문제 발견

이때 내용은 단순 문자열로 되어 있으면 문제가 되지 않는다.

데이터가 HTML로 되어 있을 때 문제가 된다.

RichEditControl에서 반환되는 HTML 데이터 htmlContent

paragraph.AppendHTML(htmlContent); 와 같이 Spire.Doc에서 사용을 하면 스타일 변경이 제대로 되지 않는 문제들이 있다.

해결 방법

스타일 적용이 제대로 안 되는 경우는 글머리 기호나 번호 매기기를 한 경우였다.

처음에는 어떻게 해결해야 할지 아이디어가 떠오르지 않아서 정말 단순하게 접근하여 일부 하드코딩하며 HTML 데이터의 스타일에서 margin의 값을 문자열 파싱했다.

바로 될 줄 알았는데, ol 태그가 두번 반복되는 경우에는 잘 안 되었다.

그러다 떠오른 것!

RichEditControl을 통해서 파일로 저장한 것은 서식 스타일이 틀어지지 않음을 확인하고, 이것을 활용하면 되겠구나 생각했다.

private void ParsingHtml(string html, Section section)
{
    string path = Util.TempPath;
    string fileName = $"Temp_{Util.NewKey()}.docx";
    string filePath = Path.Combine(path, fileName);

    // RichEditControl에서 작업된 데이터는 워드파일로 임시 저장한다.
    var control = new DevExpress.Xpf.RichEdit.RichEditControl();
    control.HtmlText = html;
    control.SaveDocument(filePath, DocumentFormat.OpenXml);

    // 방금 저장된 워드파일을 Spire.Doc을 통해서 가져온다.
    var doc = new Document();
    doc.LoadFromFile(filePath);

    using (MemoryStream htmlStream = new MemoryStream())
    {
        // 문서 내용을 HTML로 변환
        doc.SaveToStream(htmlStream, FileFormat.Html);
        
        htmlStream.Position = 0;

        StreamReader reader = new StreamReader(htmlStream);
        string htmlContent = reader.ReadToEnd();

        // HTML을 새 단락으로 추가
        Paragraph newParagraph = section.AddParagraph();
        newParagraph.AppendHTML(htmlContent);
    }
    
    // 임시 저장한 워드파일 삭제
    Util.RemoveFile(path, fileName);
}

이렇게 코딩을 하여 사용 하니 스타일이 틀어지는 것 하나 없이 잘 변환 된다.

여기서 더 수정할 게 있을까 고민해 보았지만 이것이 최선인 것 같다.

ISO 26262 기능 안전

FreeBear — Mon, 15 Jul 2024 14:11:22 +0900

ISO 26262는 도로 차량의 기능 안전을 위한 국제 표준입니다. 이 표준은 자동차의 전기 및 전자 시스템의 안전성을 보장하기 위한 지침과 요구 사항을 제공합니다. 다음은 ISO 26262에 대한 상세 개요입니다:

개요

제목: ISO 26262 - 도로 차량 - 기능 안전
범위: 이 표준은 승용차에서 생산되는 전기 및 전자 시스템의 기능 안전을 다룹니다.
목적: 시스템 고장 및 오작동으로 인한 위험을 허용 가능한 수준으로 줄이기 위해 적절한 프로세스와 지침을 제공합니다.

ISO 26262의 주요 구성 요소

V-모델 프레임워크:
- 표준은 시스템 개발을 위한 V-모델을 따르며, 각 단계에서 철저한 검증 및 검토를 보장합니다.
안전 수명 주기:
- 기능 안전 관리: 수명 주기 전반에 걸쳐 기능 안전을 관리하기 위한 요구 사항을 설정합니다.
- 개념 단계: 위험 식별 및 평가와 안전 목표 설정을 포함합니다.
- 시스템 레벨: 시스템 요구 사항에서 안전 목표를 충족하는지 확인합니다.
하드웨어 및 소프트웨어 개발:
- 하드웨어 개발: 하드웨어의 안전 관련 요구 사항을 정의하고, 안전 목표를 충족하는지 확인합니다.
- 소프트웨어 개발: 소프트웨어의 안전 요구 사항을 정의하고, 안전 목표를 충족하는지 확인합니다.
생산 및 운영:
- 생산: 안전 요구 사항이 생산 과정에서도 유지되는지 보장합니다.
- 운영 및 서비스: 차량 운용 중 안전을 유지하기 위한 절차를 포함합니다.
지원 프로세스:
- 확인 및 검증: 안전 요구 사항이 올바르게 구현되고 검증되는지 확인합니다.
- 문서화: 모든 개발 과정과 결정 사항을 문서화하여 추적 가능성을 확보합니다.
ASIL (Automotive Safety Integrity Level):
- 위험 평가를 통해 시스템의 위험성을 평가하고, 이에 따라 안전 무결성 수준(ASIL)을 할당합니다.
- ASIL은 A부터 D까지 등급이 있으며, D가 가장 높은 안전 요구 사항을 의미합니다.

ISO 26262는 자동차 산업에서 전기 및 전자 시스템의 안전성을 보장하기 위한 중요한 표준으로, 시스템 개발 초기 단계부터 전체 수명 주기 동안 안전을 고려하도록 돕습니다.

ASIL

ASIL(Automotive Safety Integrity Level)은 ISO 26262에서 사용되는 개념으로, 자동차 전기/전자 시스템의 안전성 요구 사항을 정의하고 분류하는 데 사용됩니다. ASIL은 위험 분석을 기반으로 시스템의 고장 또는 오작동이 초래할 수 있는 잠재적인 위험 수준을 평가하여 할당됩니다. ASIL 등급은 A부터 D까지 있으며, D가 가장 높은 안전 요구 사항을 의미합니다.

ASIL의 구성 요소

ASIL은 다음 세 가지 요소를 기반으로 결정됩니다:

Severity (심각도): 고장이 발생했을 때의 잠재적인 피해의 심각도를 평가합니다.
- S0: 무시할 수 있음
- S1: 경미한 부상
- S2: 중간 정도의 부상
- S3: 생명에 위협이 되는 부상 또는 사망
Exposure (노출도): 고장이 발생할 가능성 또는 빈도를 평가합니다.
- E0: 거의 발생하지 않음
- E1: 매우 드물게 발생
- E2: 드물게 발생
- E3: 자주 발생
- E4: 매우 자주 발생
Controllability (제어 가능성): 운전자나 시스템이 고장을 제어하거나 회피할 수 있는 능력을 평가합니다.
- C0: 제어 가능함
- C1: 대부분 제어 가능함
- C2: 일부 제어 가능함
- C3: 거의 제어 불가능함

ASIL 등급

위의 세 가지 요소를 조합하여 ASIL 등급을 결정합니다. ASIL 등급은 다음과 같이 정의됩니다:

QM (Quality Management): 기능 안전과 관련이 없는 시스템 (최소한의 안전 요구 사항)
ASIL A: 낮은 안전 요구 사항
ASIL B: 중간 수준의 안전 요구 사항
ASIL C: 높은 안전 요구 사항
ASIL D: 매우 높은 안전 요구 사항

ASIL 평가 예시

예를 들어, 브레이크 시스템의 고장을 평가할 때:

심각도 (Severity): 브레이크 고장은 심각한 사고로 이어질 수 있으므로 S3 (생명에 위협이 되는 부상 또는 사망)
노출도 (Exposure): 차량이 주행 중에 브레이크 고장이 발생할 확률은 E4 (매우 자주 발생)
제어 가능성 (Controllability): 고속 주행 중 브레이크 고장은 운전자가 제어하기 매우 어렵기 때문에 C3 (거의 제어 불가능함)

이 경우, 브레이크 시스템의 ASIL 등급은 ASIL D로 평가될 가능성이 큽니다.

ASIL 등급에 따른 요구 사항

각 ASIL 등급은 시스템의 개발, 검증, 검토 과정에서 요구되는 안전성 활동과 절차의 수준을 정의합니다. 등급이 높을수록 더욱 엄격한 요구 사항이 적용됩니다. 예를 들어, ASIL D 시스템은 다음과 같은 활동이 필요할 수 있습니다:

철저한 위험 분석 및 안전 목표 설정
다중 오류 검출 및 대처 메커니즘 설계
광범위한 검증 및 검토 활동
엄격한 문서화 및 추적 관리

ISO 26262는 이러한 ASIL 등급을 통해 차량 전기/전자 시스템의 안전성을 체계적으로 관리하고, 고장 또는 오작동으로 인한 위험을 최소화하는 것을 목표로 합니다.

ISO 26262의 최신동

ISO 26262의 최신 동향은 자동차 산업의 빠르게 변화하는 기술과 요구에 따라 지속적으로 발전하고 있습니다. 주요 최신 동향은 다음과 같습니다:

1. 전기 및 자율주행 차량에 대한 초점 확대

**전기차(EV)**와 **자율주행차(AV)**의 증가로 인해 ISO 26262는 이러한 새로운 기술의 특수한 요구 사항을 반영하도록 업데이트되고 있습니다. 특히, 자율주행 시스템의 복잡성과 고도화된 전기 시스템에 대한 안전 요구 사항이 강조되고 있습니다.
배터리 관리 시스템(BMS): 전기차의 핵심인 배터리 관리 시스템의 안전성 평가와 관리를 위한 요구 사항이 강화되고 있습니다.
센서와 알고리즘: 자율주행차의 센서와 인공지능 알고리즘의 신뢰성과 안전성을 보장하기 위한 새로운 지침이 추가되고 있습니다.

2. 사이버 보안과 기능 안전의 통합

ISO/SAE 21434와의 연계: 사이버 보안 표준인 ISO/SAE 21434와의 연계를 통해 기능 안전과 사이버 보안의 통합적인 접근이 강화되고 있습니다. 이는 차량 시스템이 사이버 공격에 대한 저항력을 갖추도록 하기 위함입니다.
보안 위협 모델링: 기능 안전 분석에 보안 위협 모델링을 포함시켜, 시스템이 잠재적인 사이버 공격으로부터 안전하도록 설계하는 것이 중요해지고 있습니다.

3. 소프트웨어 업데이트 및 무선 통신(OTA) 기능 강화

무선 업데이트(OTA): 차량 소프트웨어의 무선 업데이트 기능이 중요해짐에 따라, ISO 26262는 OTA 업데이트의 안전성을 보장하기 위한 요구 사항을 강화하고 있습니다.
실시간 소프트웨어 검증: 소프트웨어 업데이트 후 실시간으로 시스템의 안전성을 검증하고, 문제가 발생할 경우 신속하게 복구할 수 있는 메커니즘이 중요해지고 있습니다.

4. 기능 안전과 시스템 엔지니어링의 통합

모델 기반 개발(MBD): 시스템의 복잡성이 증가함에 따라 모델 기반 개발 접근법이 강조되고 있습니다. 이는 시스템 설계와 안전 분석을 통합하여 개발 효율성을 높이고, 오류를 조기에 발견할 수 있도록 합니다.
디지털 트윈: 물리적 시스템의 디지털 트윈을 사용하여 시스템 동작을 시뮬레이션하고, 기능 안전 요구 사항을 검증하는 방법이 발전하고 있습니다.

5. 국제적 협력과 표준의 조화

글로벌 표준화: ISO 26262는 다른 국제 표준과의 조화를 통해 글로벌 자동차 제조사들이 다양한 지역의 법규를 준수할 수 있도록 돕고 있습니다. 이는 글로벌 시장에서의 호환성과 규정 준수를 촉진합니다.
지속적인 업데이트: 최신 기술 발전과 산업 요구 사항을 반영하기 위해 표준은 주기적으로 업데이트되고 있습니다. 새로운 판이 발행되면서 최신 기술과 방법론이 포함되고 있습니다.

6. 기능 안전 문화의 확산

교육 및 훈련: 기능 안전에 대한 교육과 훈련 프로그램이 강화되어, 모든 관련자가 표준을 이해하고 준수할 수 있도록 하고 있습니다.
기업 문화: 기능 안전을 기업 문화의 일환으로 내재화하여, 제품 개발 전 과정에서 안전성을 최우선으로 고려하는 접근법이 확산되고 있습니다.

이러한 최신 동향은 ISO 26262가 계속해서 변화하는 자동차 산업의 요구를 반영하고, 안전성을 유지하며, 새로운 기술을 통합할 수 있도록 발전하고 있음을 보여줍니다.

분석 기법

ISO 26262은 자동차 산업을 위한 기능적 안전성 표준으로, 여러 가지 분석 기법을 요구합니다. 주요 분석 기법들은 다음과 같습니다:

위험 분석과 평가 (Hazard Analysis and Risk Assessment, HARA):
- 시스템에서 발생할 수 있는 위험 요소를 식별하고 그 위험을 평가하는 과정입니다. ISO 26262에서는 이 과정을 통해 가능한 모든 위험을 분류하고, 이들 위험에 대한 필요한 안전 기능을 정의합니다.
기능적 안전성 요구 사항 (Functional Safety Requirements):
- HARA를 통해 도출된 위험 요소들에 대한 안전 기능을 명시하고, 이를 시스템 설계와 개발 과정에 반영합니다.
결함 트리 분석 (Fault Tree Analysis, FTA):
- 시스템의 결함이나 장애가 발생할 수 있는 원인을 시각적으로 분석하고, 이로 인해 발생할 수 있는 잠재적인 결과를 평가합니다. 이는 시스템의 결함 처리 전략을 개발하는 데 중요한 기법입니다.
실증적 안전성 (Empirical Safety):
- 실제로 시스템이나 컴포넌트를 실험하거나, 테스트하거나, 분석하여 안전성을 평가하는 기법을 포함합니다. 예를 들어, 기능적 안전성 시험 (Functional Safety Testing)과 같은 방법이 있습니다.
변별력 분석 (Determination of Safety Integrity Level, SIL Determination):
- SIL 결정은 시스템이나 컴포넌트에 요구되는 안전성 수준을 평가하고 정의하는 과정입니다. SIL은 장애나 결함에 대한 예방, 탐지, 제어 기능의 중요성을 반영합니다.
심리적 실험 (Psychological Testing):
- 운전자나 사용자의 행동, 반응, 능력을 평가하여 기능적 안전성과 관련된 설계 결정을 지원하는 기법입니다. 이는 사용자 경험과 안전성 간의 관계를 이해하는 데 도움이 됩니다.

이러한 분석 기법들은 ISO 26262에서 시스템의 기능적 안전성을 평가하고 개발하는 데 중요한 역할을 합니다. 각 기법은 특정 단계에서 필요한 정보를 제공하며, 전체적으로 시스템의 안전성을 보장하기 위해 조합하여 사용됩니다.

ISO 26262 표준을 위한 지원 서비스

컨설팅 및 교육: ISO 26262 표준을 이해하고 적용하는 데 필요한 전문 지식을 제공합니다.
안전 분석 도구: HARA, FMEA, STPA 등 안전 분석을 지원하는 소프트웨어 도구.
시뮬레이션 및 테스트: 시스템의 안전성을 검증하기 위한 HIL 및 시뮬레이션 솔루션.
인증 서비스: 시스템이 ISO 26262 요구 사항을 충족하는지 확인하고 인증을 제공합니다.

ISO 26262 표준을 준수하려는 기업들은 이러한 지원 서비스를 활용하여 시스템의 기능 안전성을 보장하고, 개발 과정에서의 위험을 최소화할 수 있습니다.

몇 가지 ISO 26262 도입 사례

1. 현대자동차 (Hyundai Motor Company)

현대자동차는 ISO 26262를 안전 및 신뢰성 평가의 중요한 기준으로 채택하고 있습니다. ISO 26262의 접근법을 통해 차량의 전기/전자 시스템에 대한 안전성을 평가하고, 잠재적인 위험을 분석하여 안전한 제품을 개발하고 있습니다.

2. 벤츠 (Mercedes-Benz)

메르세데스-벤츠는 자사의 차량 전기 및 전자 시스템에 ISO 26262를 적용하여 안전성을 최적화하고 있습니다. ISO 26262는 메르세데스-벤츠의 차량 개발 및 생산 과정에서 중요한 요소로 포함되어 있습니다.

3. 일본의 자동차 제조업체들

일본의 다양한 자동차 제조업체들도 ISO 26262를 적극적으로 도입하고 있습니다. 토요타, 닛산, 혼다 등 주요 자동차 제조업체들은 ISO 26262를 통해 차량의 안전성을 향상시키고, 국제 시장에서의 경쟁력을 유지하고 있습니다.

4. 자동차 부품 제조업체들

ISO 26262는 자동차 부품 제조업체들 사이에서도 널리 적용되고 있습니다. 예를 들어, 자동차의 브레이크 시스템, 제동 시스템, 주행 보조 시스템 등에 사용되는 부품들은 ISO 26262를 준수하여 안전성을 보장하고 있습니다.

5. 전자 제조업체들

ISO 26262는 전자 제조업체들에게도 중요한 기준으로 작용하고 있습니다. 예를 들어, 차량 내부의 전자 제어 장치(ECU) 제조업체들은 ISO 26262를 준수하여 제품의 안전성을 검증하고 있습니다.

이러한 ISO 26262 도입 사례들은 자동차 산업 전반에서 기능 안전성을 강화하고, 고객들에게 안전하고 신뢰할 수 있는 제품을 제공하기 위한 중요한 노력의 일환으로 볼 수 있습니다.

ISO 21434 표준 자동차 사이버 보안

FreeBear — Mon, 15 Jul 2024 11:16:33 +0900

ISO 21434는 자동차 사이버 보안의 요구사항과 지침을 제공하는 국제 표준입니다. 이 표준은 자동차 산업에서 사이버 보안 리스크를 관리하고, 보안 사고를 방지하며, 자동차의 전자 시스템을 보호하기 위한 체계적인 접근 방식을 정의합니다. ISO 21434는 자동차의 전자제어장치(ECU), 소프트웨어, 네트워크 통신 등을 포함한 전체 라이프사이클 동안의 사이버 보안을 다룹니다.

주요 내용

범위와 목적:
- 자동차 전자 시스템의 사이버 보안 리스크를 관리하기 위한 프레임워크 제공.
- 보안 요구사항을 식별하고, 리스크를 분석하며, 적절한 보안 대책을 마련.
용어와 정의:
- 표준에 사용되는 주요 용어와 정의를 설명하여, 사이버 보안에 대한 공통 이해를 도모.
사이버 보안 관리:
- 사이버 보안 정책, 조직 내 책임 분담, 보안 계획 수립 등을 포함한 사이버 보안 관리 시스템을 정의.
위험 평가와 분석:
- 위협 분석, 취약점 평가, 리스크 평가를 통해 시스템의 사이버 보안 리스크를 식별하고 분석.
제품 개발 보안:
- 제품 개발 과정에서 보안 요구사항을 정의하고, 보안 설계, 구현, 테스트를 포함한 보안 활동 수행.
운영 및 유지보수 보안:
- 제품 출시 후 운영 중 발생할 수 있는 사이버 보안 리스크 관리 및 보안 업데이트 절차.
보안 사건 대응:
- 보안 사건 발생 시 대응 절차, 사고 보고, 조사, 해결 방안을 포함.

ISO 21434의 중요성

자동차의 복잡성 증가: 현대 자동차는 수많은 전자 시스템과 소프트웨어로 구성되어 있어 사이버 공격의 표적이 되기 쉽습니다.
안전과 보안: 자동차의 보안 취약점은 안전 문제로 직결될 수 있어, 사이버 보안은 자동차 안전의 필수 요소로 자리잡았습니다.
규제 준수: 많은 국가와 지역에서 자동차 사이버 보안에 대한 규제를 강화하고 있으며, ISO 21434는 이러한 규제를 충족시키는 데 도움을 줍니다.

ISO 21434는 자동차 제조사, 부품 공급업체, 소프트웨어 개발자 등 자동차 생태계 전반에 걸쳐 사이버 보안을 강화하기 위한 표준으로, 자동차 산업의 신뢰성과 안전성을 높이는 데 기여합니다.

서비스

ISO 21434 표준을 준수하기 위해 다양한 서비스가 제공됩니다. 이러한 서비스는 주로 자동차 제조사, 부품 공급업체, 소프트웨어 개발자 등을 대상으로 하며, 사이버 보안 리스크를 효과적으로 관리하고 대응할 수 있도록 돕습니다. 주요 서비스는 다음과 같습니다.

1. 컨설팅 서비스

사이버 보안 전략 수립: 기업의 사이버 보안 전략을 수립하고, ISO 21434 요구사항을 충족시키기 위한 맞춤형 계획을 제공합니다.
위협 분석 및 리스크 평가: 자동차 시스템의 위협을 식별하고 리스크를 평가하여, 필요한 보안 대책을 제안합니다.

2. 교육 및 훈련

ISO 21434 교육 프로그램: 표준에 대한 이해를 높이기 위해 전문가들이 제공하는 교육 과정입니다.
사이버 보안 인식 교육: 직원들이 사이버 보안의 중요성과 기본 원칙을 이해할 수 있도록 교육합니다.

3. 보안 아키텍처 및 설계 서비스

보안 설계 검토: 자동차 시스템의 보안 설계를 검토하고, 취약점을 식별하여 개선 방안을 제시합니다.
보안 요구사항 정의: 시스템 개발 초기 단계에서 보안 요구사항을 정의하고, 이를 설계에 반영합니다.

4. 보안 테스트 및 평가

침투 테스트 (Penetration Testing): 자동차 시스템의 취약점을 발견하기 위해 모의 해킹 테스트를 수행합니다.
보안 검증: 시스템이 보안 요구사항을 충족하는지 확인하기 위해 다양한 보안 검증 테스트를 실시합니다.

5. 위협 탐지 및 대응 서비스

실시간 위협 모니터링: 자동차 시스템의 보안 상태를 실시간으로 모니터링하고, 이상 징후를 탐지합니다.
사이버 사건 대응: 보안 사고 발생 시 신속하게 대응할 수 있도록 사건 대응 계획을 수립하고 실행합니다.

6. 보안 업데이트 및 유지보수

보안 패치 관리: 발견된 보안 취약점을 해결하기 위해 보안 패치를 관리하고, 배포합니다.
정기 보안 점검: 주기적으로 시스템의 보안 상태를 점검하고, 최신 보안 트렌드에 맞게 업데이트합니다.

7. 컴플라이언스 지원

규제 준수 평가: ISO 21434 및 관련 규제 요구사항에 대한 준수 여부를 평가합니다.
감사 준비: 외부 감사나 인증을 준비하기 위해 필요한 문서화 작업과 내부 감사 서비스를 제공합니다.

8. 제품 수명주기 관리

보안 수명주기 관리: 제품의 전체 수명주기 동안 보안 요구사항을 관리하고, 각 단계에서 필요한 보안 활동을 수행합니다.
보안 사후 관리: 제품 출시 후 발생하는 보안 문제를 지속적으로 모니터링하고, 대응합니다.

이러한 서비스를 통해 자동차 제조사와 관련 업체들은 ISO 21434의 요구사항을 효과적으로 준수하고, 자동차 시스템의 사이버 보안을 강화할 수 있습니다.

TARA

TARA(Threat Analysis and Risk Assessment)는 사이버 보안 분야에서 중요한 개념으로, 특히 ISO 21434 표준에 따라 자동차 산업에서 널리 사용됩니다. TARA는 시스템의 보안 리스크를 체계적으로 식별하고 평가하는 방법론을 제공하여, 보안 위협에 대한 대응 전략을 수립하는 데 도움을 줍니다.

TARA의 주요 요소

자산 식별 (Asset Identification)
- 보호해야 할 자산(예: 데이터, 소프트웨어, 하드웨어)을 식별합니다.
- 자산의 중요성을 평가하여 보호 우선순위를 결정합니다.
위협 식별 (Threat Identification)
- 자산에 대해 발생할 수 있는 잠재적 위협을 식별합니다.
- 위협 목록을 작성하고, 각 위협의 특성과 발생 가능성을 분석합니다.
취약점 식별 (Vulnerability Identification)
- 시스템 내 존재하는 보안 취약점을 식별합니다.
- 취약점이 위협과 어떻게 연결되는지 평가합니다.
위험 평가 (Risk Assessment)
- 식별된 위협과 취약점을 기반으로 리스크를 평가합니다.
- 리스크 평가 모델을 사용하여 각 위협의 영향을 정량화하고 우선순위를 정합니다.
대응 전략 수립 (Mitigation Strategy)
- 평가된 리스크에 대해 적절한 대응 전략을 수립합니다.
- 보안 대책을 설계하고, 구현 계획을 수립합니다.

TARA의 절차

준비 단계
- 프로젝트의 범위와 목적을 정의하고, TARA 수행을 위한 팀을 구성합니다.
- 필요 시 외부 전문가의 도움을 받을 수도 있습니다.
자산 및 시스템 이해
- 시스템 아키텍처와 주요 자산을 분석합니다.
- 자산의 중요성과 가치를 평가합니다.
위협 모델링
- 자산을 대상으로 위협 모델을 개발합니다.
- 위협 시나리오를 작성하고, 각 시나리오의 위협 요인을 분석합니다.
취약점 분석
- 시스템의 취약점을 분석하고, 이를 위협 시나리오와 연결합니다.
- 취약점의 심각도와 영향을 평가합니다.
리스크 평가
- 각 위협 시나리오의 리스크를 평가하고, 발생 가능성과 영향을 기반으로 우선순위를 정합니다.
- 리스크 매트릭스나 기타 평가 도구를 사용하여 시각적으로 표현합니다.
대응 및 완화
- 고위험 위협에 대한 대응 전략을 수립하고, 보안 대책을 제안합니다.
- 대책의 효과를 평가하고, 필요한 경우 보완 조치를 계획합니다.
보고 및 문서화
- TARA 결과를 문서화하고, 주요 이해관계자에게 보고합니다.
- 지속적인 모니터링과 주기적인 재평가를 위한 계획을 수립합니다.

TARA의 중요성

체계적 접근: TARA는 체계적인 방법론을 제공하여, 보안 리스크를 종합적으로 관리할 수 있게 합니다.
사전 예방: 잠재적인 보안 위협을 미리 식별하고 대응함으로써, 보안 사고를 예방할 수 있습니다.
비용 절감: 사전 대응을 통해 보안 사고로 인한 비용을 줄이고, 효율적인 보안 투자 계획을 수립할 수 있습니다.
컴플라이언스: ISO 21434 등의 표준과 규제 요구사항을 충족하는 데 도움을 줍니다.

TARA는 ISO 21434를 준수하는 데 필수적인 도구로, 자동차 산업에서 사이버 보안을 강화하는 데 중요한 역할을 합니다.

NullReferenceException, Null 참조 오류 등 Null 예외 처리에 대한 고찰과 지침서

FreeBear — Fri, 12 Jul 2024 11:26:11 +0900

NullReferenceException 에러가 발생 할 때마다 아, 다음에는 좀 더 꼼꼼하게 확인해야지 해도 시간이 지나면 같은 문제를 겪고는 한다.

그래서 매 테스트 때마다 하나 씩 확인하고, 잊지 않기 위해 이렇게 지침서를 작성한다.

Visual Studio2022에서의 NullReferenceException 오류 메시지 팝업 화면

그리고 문득 이런 고찰을 하게 된다.

왜 프로그램은 Null인 것을 참조하면 그냥 넘어가지 않고, 기어이 오류 메시지를 뱉어내는 걸까?

왜 Null 참조 오류를 무시 하지 못 하게 하는 걸까?

○ 그 이유

Null 객체에 접근하려고 하면 메모리 접근 오류가 발생하여 프로그램이 비정상적으로 종료되거나 프로그램의 성격에 따라서 데이터 손실, 보안 문제 등을 일으킬 수 있다. 이러한 문제는 심각한 버그를 야기한다. 이를 방지하고 예방하기 위해 개발자에게 문제를 인지시키는 방법이자, 오류 메시지를 출력하고 그 이후의 동작을 중단시킨다.

만약, 이 오류가 메시지 조차 뜨지 않고 무시가 된 채로 프로그램이 정상적으로 실행이 된다면 Null 참조가 일어나는 곳에서 데이터 누수가 일어난다거나 생각치 못 한 문제들이 연쇄적으로 발생하면서 프로그램을 사용하는 사용자들뿐만 아니라 해당 프로그램을 통해 이익을 얻는 사람들에게 불행이 닥쳐올 것이고, 이는 비용 손실 또한 일어날 수 밖에 없다.

데이터베이스를 배울 때 무결성의 중요함을 배운다. 이는 데이터를 다루는 프로그램과 그 프로그램을 만드는 개발자 또한 무관한 영역이 아니다.

Null 참조는 무결성을 해치는 심각한 버그이므로, 이 버그가 나타났을 때 프로그램에서 오류를 뱉어내어 개발자가 이를 절대 무시할 수 없게 만들어진 시스템은 개발자 입장에서는 정말 감사한 일이다.

이 버그를 단순히 try catch로 오류를 무시로 일관하는, 조치를 취하는 누를 범하지 말자.

문제를 인지하고 근본적인 것에 다가감으로써 적절한 조치를 취하도록 하자.

using System;

class Program
{
    static void Main()
    {
        MyClass obj = null;

        // Null 참조 오류를 무시하고 프로그램 계속 실행
        try
        {
            obj.Method();
        }
        catch
        {
            // 오류를 무시하고 넘어감
        }

        Console.WriteLine("Program continues execution.");
    }
}

class MyClass
{
    public void Method()
    {
        Console.WriteLine("Method called");
    }
}

이 경우, 프로그램은 Null 참조 오류를 무시하고 계속 실행되지만, 실제로는 예기치 않은 동작이 발생할 수 있다.

using System;

class Program
{
    static void Main()
    {
        MyClass obj = null;

        // Null 참조 오류를 처리하고 프로그램 중단
        try
        {
            obj.Method();
        }
        catch (NullReferenceException ex)
        {
            Console.WriteLine($"NullReferenceException caught: {ex.Message}");
            // 필요한 경우 프로그램 중단
            Environment.Exit(1);
        }

        Console.WriteLine("This line will not be executed if an exception occurs.");
    }
}

class MyClass
{
    public void Method()
    {
        Console.WriteLine("Method called");
    }
}

이 경우, 프로그램은 Null 참조 오류를 감지하고 적절한 메시지를 출력하며 필요 시 프로그램을 중단하여 이후의 예기치 않은 동작을 방지한다.

● 요약

Null 참조 오류를 무시하지 않고 오류 메시지를 출력하는 것은 프로그램의 안정성과 안전성을 보장하기 위한 중요한 방법이다. 이를 통해 개발자는 문제를 신속하게 파악하고 해결할 수 있으며, 프로그램의 예측 가능한 동작을 유지할 수 있다.

○ Null 참조 오류 해결 방법

● Null 참조 오류를 해결하기 위한 선행 학습, 발생 조건 알기

1. 객체가 null일 때 인스턴스 멤버에 접근

MyClass obj = null;
obj.Method(); // NullReferenceException 발생

2. 컬렉션이 null일 때 접근

List<int> list = null;
int count = list.Count; // NullReferenceException 발생

3. 배열 요소가 null일 때 접근

MyClass[] array = new MyClass[10];
MyClass item = array[0];
item.Method(); // NullReferenceException 발생

4. 메서드 반환 값이 null일 때 접근

MyClass obj = GetMyClass();
obj.Method(); // GetMyClass가 null을 반환하면 NullReferenceException 발생

● 해결 방법

1. null 확인: 모든 객체 접근 전에 null인지 확인

if (obj != null)
{
    obj.Method();
}

2. Null-conditional 연산자 "?.": 객체가 null인 경우 null을 반환하고, 그렇지 않으면 멤버에 접근

obj?.Method();

3. Null-coalescing 연산자 "??": 객체가 null일 경우 기본 값을 제공

MyClass obj = GetMyClass() ?? new MyClass();

4. Null-coalescing 할당 연산자 "??=": 객체가 null인 경우 기본 값을 할당

obj ??= new MyClass();

5. nullable 타입과 null 병합 연산자 사용: nullable 타입을 사용할 때 기본 값을 설정

int? number = null;
int value = number ?? 0;

6. Optional Chaining 사용: "?." 연산자를 사용하여 객체가 null인지 확인한 후 null이 아니면 멤버에 접근하는 기능

public class Person
{
    public string Name { get; set; }
    public Person? Parent { get; set; }
}

var child = new Person { Name = "Child" };
var parent = child.Parent?.Name ?? "Unknown";

7. try-catch 블록 사용: 예외가 발생할 수 있는 코드 블록을 감싸서 처리

try
{
    obj.Method();
}
catch (NullReferenceException ex)
{
    // 예외 처리 코드
    Console.WriteLine("NullReferenceException caught");
}

추가적으로 null 참조 문제를 방지하기 위해 확인하거나 테스트할 수 있는 몇 가지 사항과 방법이 더 있다.

○ 추가적인 확인 및 테스트 방법

1. Nullable Reference Types 사용: C# 8.0부터는 Nullable Reference Types를 사용하여 컴파일 타임에 null 참조 문제를 방지할 수 있다.

#nullable enable
public class MyClass
{
    public string? NullableProperty { get; set; }
    public string NonNullableProperty { get; set; }

    public MyClass(string nonNullableProperty)
    {
        NonNullableProperty = nonNullableProperty;
    }
}

2. Data Annotations 및 Code Contracts 사용: Data Annotations와 Code Contracts를 사용하여 메서드와 속성의 유효성을 검사할 수 있다.

using System.ComponentModel.DataAnnotations;

public class MyClass
{
    [Required]
    public string NonNullableProperty { get; set; }
}

3. Unit Tests 작성: Unit Test를 작성하여 null 참조 예외가 발생하지 않도록 테스트할 수 있다.

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public class MyClassTests
{
    [TestMethod]
    public void TestMethod_NullCheck()
    {
        MyClass obj = null;

        Assert.ThrowsException<NullReferenceException>(() => obj.Method());
    }
}

4. Defensive Programming: 가능한 모든 경로에서 null이 발생하지 않도록 방어적인 코딩을 수행한다.

public void Process(MyClass obj)
{
    if (obj == null)
    {
        throw new ArgumentNullException(nameof(obj));
    }

    obj.Method();
}

5. Guard Clauses 사용: 메서드 시작 부분에서 인수의 유효성을 검증하는 Guard Clauses를 사용한다.

public void Process(MyClass obj)
{
    _ = obj ?? throw new ArgumentNullException(nameof(obj));
    obj.Method();
}

2024년 1회 정보처리기사 실기에 합격하여 쓰는 일기겸 리뷰

FreeBear — Mon, 24 Jun 2024 16:11:10 +0900

일기

4월 27일에 정보처리기사 1회 실기시험을 보고 수제비카페에 올라온 자료를 통해 가채점 했을 때에는 60점이 되지 않아서 2회 준비나 해야지 마음먹고 있었다. 합격/불합격 결과날인 6월18일에는 내 주변에 합격한 사람들은 카톡으로 합격 메시지를 받았는데 난 받지를 않아서 아, 역시 불합격이구나 하고 그냥 확인차 큐넷에 들어가서 시험결과를 보았다.

시험결과에 써있는 것은 분명 합격이었던 것이었다. 이 글자가 너무나 낯설었다.

수험번호를 클릭하니 점수를 확인할 수 있었다.

와 68점이나!

뭔가 운이 작동한 것 같다.

내 개발자 연차가 8년차인데, 궁극적으로 정보처리기사를 이제서야 딴 이유는 지금 다니는 곳이 기업부설연구소이고, 전담연구요원이 되면 월급에서 비과세 20만원이 추가가 되는 혜택이 있는데 전담연구요원이 되는 자격을 위해 필요해서였다.

중소기업 기준으로 자격이 되는 게 더 있긴 한데, MCP와 네트워크관리사2급, 운전면허증이 전부인 내가 전담연구요원이 되는 확실한 방법은 학사 또는 기사 자격이다. 학사는 아직 방통대 3학년이라 멀었고, 당장 가까운 시일에 얻을 수 있는게 기사자격증 중에서도 그나마 만만한 정보처리기사였다.

실기 시험을 보고나서 느낀 것은 날로 어려워질 것 같은 예감이었기에 올해 무슨 일이 있어도 따겠다는 생각만 했지 한번에 합격할 줄은 몰랐는데, 천만다행이라고 해야 할지 운이 좋았다고 해야 할지.

일기는 여기까지 하고 혹시나 이 글을 읽는 사람에게 조금이나마 도움이 되는 정보처리기사 실기에 대한 리뷰를 작성해야겠다.

리뷰

필기는 기출문제에서 반 이상 나오기 때문에 책을 따로 살 필요는 없었다. 인터넷에서 쉽게 구할 수 있는 핵심내용위주의 자료들만 보고, 기출문제 5년 이내 전부를 보았을 때 참 쉽다는 생각을 했다.

실기는 기출문제보다는 중요도가 높은 파트 위주로 공부하라는 조언들을 보며 C언어, 자바, 파이썬, SQL 위주로 공부했다. 그러다 작년 합격자 리뷰 중에 지난 기출문제 중에 나온 게 있다라는 글을 보고 필기 때와 같이 5년 이내의 기출문제들을 꼼꼼히 풀면서 오답노트까지 했었다.

결과적으로 2024년 1회 정보처리기사 실기에서는 지난 기출문제에서 완전 동일한 문제 하나(SQL)와 인덱스 바꿔서 풀어야 하는 문제(파이썬) 이렇게 두 문제가 나와서 매우 도움이 되었다고 할 수 있다.

강의는 수제비 책을 산 김에 수제비에서 강의까지 끊어서 3분의 2이상 들었다. 지금 생각해보면 수제비 강의 보다는 흥달쌤 강의가 더 좋았을 것 같다. 분명 코딩 문제를 푸는 방법들, 노하우에 대한 강의들은 도움이 된 건 사실이나 개념 부분에서는 귀에 쏙쏙 익혀지지가 않아서 기출문제 위주로만 보게 되었기 때문이다.

흥달쌤 강의는 유튜브를 통해서 무료로 올라온 강의만 보았는데 그것만으로도 충분히 많은 도움을 받았다. 라이브 강의까지 해주셨는데 거기서 나온 내용들(서브넷 마스크 계산법 등등)만 공부해도 3문제 이상 맞출 수 있었다. 파이썬에서 인덱스 세는 법도 흥달쌤이 말해준 것이 그냥 자동으로 떠올라서 따라하며 계산했다. 강의가 아무리 내용이 좋아도 강의자가 하는 말이, 그 내용이 귀에 쏙쏙 들어오는게 중요한 것 같다.

(만약 불합격 헀으면 흥달쌤 유료 강의를 결제해서 볼 생각 이었지만... 합격해서 크흠. 아무튼 감사합니다.)

그다음 수제비 책과 강의들 모두 내돈내산이었기에 수제비 카페를 자주 들어갔는데 거기서 올라온 모의고사 문제와 데일리 문제, 그리고 책에 있던 기출문제들을 푼 것도 도움이 되었다.

아무리 외워도 외워지지 않는 개념들, 단어 같은 거랑 꼭 외워야 하는 영단어 위주의 것들을 VOCA 앱을 설치해서 일일이 책을 보며 적었는데, 그걸 스마트폰에서 시간 확인할 때마다 보고, 그냥 쉴 때마다 보고, 스마트폰으로 게임이나 소설보기 전에 보고 또 보았다.

이것도 참 많은 도움이 되었다.

덕분에 디자인패턴은 확실하게 외웠고, 응집도와 결합도도 외웠다. 실제 코딩할 때 이부분을 신경쓰며 하게 되기도 했다.

시간이 많았다면 대학교에서 배운 것들, 정보처리기사 시험과목과 겹치는 것들 위주로 교재들을 한번씩 보면서 배운 내용들을 상기하는 것도 도움이 되었을 것 같다.

한줄평

현실적으로 도움이 되는 자격증이라는 것을 차치하더라도, 정보처리기사 시험이 여전히 실무와 동떨어지는 문제들이 있다곤 하나, 내 경험상 나에게는 시험 준비를 하면서 부족했던 기본기를 조금이나 채울 수 있었고, 개발일을 하며 같은 실수를 반복하는 일에 대해 테스트를 어떻게 해야할지 막막했던 게 사실인데 정보처리기사 시험과목에 테스트에 대한 게 있어서 세세하게 공부한 덕분에 실무에도 도움이 된 것은 사실이므로 개발자로 살아가기 위해 공부를 어떻게 해야할지 모르는 사람들에게는 학습을 위해서, 대학을 졸업하는 이들에게는 그동안의 학습 한 것들에 대한 테스트 겸 보면 좋을 자격증이지 않나 싶다.

WPF DevExpress LayoutPanel의 header에 custom button 놓기

FreeBear — Mon, 22 Apr 2024 15:58:00 +0900

DevExpress LayoutPanel의 header에 custom button 놓기

참고 자료

https://supportcenter.devexpress.com/ticket/details/t919567/add-new-buttons-to-layoutpanel-header-that-has-look-and-feel-of-pin-and-close-buttons

https://docs.devexpress.com/WPF/DevExpress.Xpf.Docking.LayoutPanel

https://docs.devexpress.com/WPF/DevExpress.Xpf.Docking.LayoutPanel._members

https://docs.devexpress.com/WPF/DevExpress.Xpf.Docking.BaseLayoutItem.ControlBoxContent?utm_source=SupportCenter&utm_medium=website&utm_campaign=docs-feedback&utm_content=T665596

예시

<dxdo:LayoutPanel.ControlBoxContentTemplate>
    <DataTemplate>
        <dxve:DockPaneControlBoxButton ToolTip="이미지 새창 열기"
                                        Command="{DXBinding '@FindAncestor($UserControl).DataContext.ShowImageWindowCommand'}">
            <Image Source="{dx:DXImage 'Images/Actions/ImportImage_16x16.png'}" />                                       
        </dxve:DockPaneControlBoxButton>
    </DataTemplate
</dxdo:LayoutPanel.ControlBoxContentTemplate>

C# WPF, WinForm DevExpress GridControl 붙여넣기 기능

FreeBear — Mon, 22 Apr 2024 15:49:26 +0900

devexpress GridControl에 복사한 것 붙여넣기 Clipboard 관련

1. WinForm

https://docs.devexpress.com/WindowsForms/DevExpress.XtraGrid.Views.Grid.GridView.ClipboardRowPasting

2. WPF

1) 클립보드 데이터를 그리드컨트롤 칼럼과 로우에 맞춰서 데이터 들어가는 형식으로 전달 받아 사용 할 수 있음, 붙여넣기 아예 취소 가능
https://docs.devexpress.com/WPF/DevExpress.Xpf.Grid.TableView.ClipboardRowPasting

2) 붙여넣기 완료 후 데이터별 처리할 때
https://docs.devexpress.com/WPF/DevExpress.Xpf.Grid.TableView.ClipboardRowCellValuePasting

https://docs.devexpress.com/WPF/119756/controls-and-libraries/data-grid/data-editing-and-validation/clipboard-management/paste-operations

WPF Binding Path에 관하여 (바인딩 경로)

FreeBear — Mon, 8 Apr 2024 22:02:22 +0900

2023.04.07 - [닷넷/WPF] - C# WPF에서 Binding(바인딩)이란?

C# WPF에서 Binding(바인딩)이란?

WPF에서는 MVVM 패턴을 지키는 게 중요합니다. 개인적으로 생각하기에는 이 MVVM 패턴대로 만들지 않을 것이라면 개발 속도로 봤을 때나 유지보수 적으로 봤을 때나 그냥 윈폼(WinForms)으로 만드는게

jasmintime.com

이전글을 통해서 WPF에서 데이터 바인딩은 UI 요소와 데이터 소스 간의 연결을 쉽게 설정할 수 있는 기능임을 알 수 있습니다. 이 바인딩을 잘 쓰기 위해서는 바인딩 구문을 아는 것이 중요합니다.

그 중에서 바인딩 경로는 몇 가지 유형이 있으며,

경로 지정을 어떻게 하느냐에 따라서 자기 자신의 뷰모델이 아닌 부모 요소 혹은 그 외 기타와 연결지을 수 있고, 코드 비하인드 없이 xaml에서 충분히 이벤트 처리를 할 수도 있습니다.

바인딩 경로 유형

1. 속성 바인딩

앞서 이전글에서도 설명한 유형으로 가장 일반적으로 사용되는 유형입니다.

Path는 생략 가능합니다.

<TextBlock Text="{Binding PropertyName}" />
<!-- 혹은 -->
<TextBlock Text="{Binding Path=PropertyName}" />

2. 속성 경로

복합 객체 내의 속성에 바인딩할 때 사용됩니다.

Path는 생략 가능합니다.

public class MyViewModel : ViewModelBase
{
    private Person _person;
    public Person Person
    {
    	get => _person;
        set => SetProperty(ref _person, value);
    }
}


public class Person
{
	public string Name {get; set;}
}

<TextBlock Text="{Binding Person.Name}" />
<!-- 혹은 -->
<TextBlock Text="{Binding Path=Person.Name}" />

3. 인덱서

배열이나 딕셔너리와 같은 인덱스를 사용하여 바인딩 할 수 있습니다.

<ListBox ItemsSource="{Binding Persons}">
    <ListBox.ItemTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding Path=[0]}" />
        </DataTemplate>
    </ListBox.ItemTemplate>
</ListBox>

4. RelativeSource

상대적인 소스를 참조하여 바인딩할 때 사용됩니다.

<TextBlock Text="{Binding RelativeSource={RelativeSource Mode=FindAncestor, AncestorType={x:Type ListBox}}, Path=DataContext.Persons[0].Name}" />

바인딩 선언 개요

PropertyPath XAML 구문

바인딩 경로에 대한 자세한 내용은 위 링크에서 확인할 수 있습니다.

바인딩 경로 오류

WPF에서는 바인딩 경로가 잘못 되었을 때 런타임이 실패하지는 않습니다. 따라서 모르고 넘어갈 수도 있는 일을

Visual Studio 2022에서 WPF를 개발한다면, 바인딩 경로가 잘못 되었을 때 쉽게 알 수 있습니다.

위 이미지와 같이 프로젝트를 빌드하여 실행 하면 바인딩 오류가 있을 때 빨간색 버튼으로 바뀌고, 바인딩 오류 수를 알려줍니다.

이를 클릭하면

어디에서 오류가 있는지 알 수 있습니다.

사이트에서 접속 대기 화면 넘기는 방법 (티켓팅, 원서 접수 할 때 등등)

FreeBear — Mon, 1 Apr 2024 14:21:33 +0900

1. 웹브라우저는 엣지(Microsoft Edge)를 사용합니다.

2. 키보드에서 F12를 눌러 DevTools를 엽니다.

3. DevTools에서 콘솔을 선택합니다.

4. 사이트에서 접속 대기가 뜰 때 콘솔에 복사+붙여넣기는 안 될 수 있으므로 직접 타이핑하여

NetFunnel.gControl.next.success({},{data:{}})

을 그대로 입력하고 엔터합니다.

5. 접속 대기가 사라지고 다음페이지가 뜹니다.

6. 접속 대기를 뚫고 페이지에 접근에 성공해도 사이트의 서버가 트래픽을 감당을 못 하는 경우에는 타임아웃 페이지가 나올 수 있습니다. 이때는 페이지가 정상적으로 나올 때까지 페이지 새로고침(F5)을 합니다.

7. 4~6번은 사이트의 접속 대기 페이지마다 반복 될 수 있습니다.

Sourcetree(소스트리)에서 깃랩의 리포지토리를 Clone 하는 방법

FreeBear — Mon, 1 Apr 2024 14:05:03 +0900

소스트리에서는 깃랩의 HTTPS URL을 그대로 복사해서 사용하면 '유효한 소스 경로/URL이 아닙니다' 라고 나오는 경우가 있습니다.

보통은 소스트리에 깃랩의 계정 정보가 없는 경우 혹은 정보가 다른 경우에 해당 URL에 접근할 수 없어서입니다.

계정 정보를 다시 입력해야 하는 경우에는

먼저

기존의 계정 정보가 있는지 확인하고, 다음의 파일들을 삭제합니다.

1. C:\Users\{컴퓨터 혹은 계정명}\AppData\Local\Atlassian\SourceTree 폴더에서

2. passwd 파일 삭제

3. userhosts 파일 삭제

그다음

4. Clone하려는 깃랩에 있는 리포지토리에서 Code > HTTPS URL을 복사합니다.

5. 복사한 URL에서 계정명을 추가해서 소스트리에 URL을 입력합니다.

예시)
복사한 URL: https://gitlab.com/MySite/repository.git
소스트리에 입력할 URL: https://gitlabusername@gitlab.com/MySite/repository.git

6. 계정 비밀번호를 입력하라고 나오는데 로그인을 하면 클론 버튼이 활성화되면서 클론을 할 수 있게 됩니다.

참고로 이때, 비밀번호를 잘못 입력하여 로그인이 실패된 경우에는 1번부터 다시 하시면 됩니다.

WPF DevExpress 뷰가 로드될 때 특정 컨트롤(TextBox, TextEdit 등등)에 Focus 주는 방법

FreeBear — Mon, 1 Apr 2024 13:32:09 +0900

<UserControl ...
    xmlns:dxmvvm="http://schemas.devexpress.com/winfx/2008/xaml/mvvm">
    <Grid>
        <TextBox>
            <dxmvvm:Interaction.Behaviors>
                <dxmvvm:FocusBehavior/>
            </dxmvvm:Interaction.Behaviors>
        </TextBox>
    </Grid>
</UserControl>

이렇게 하면 코드 비하인드 없이 포커스를 설정할 수 있습니다.

이 외의 자세한 내용은 Devexpress의 문서를 확인합니다.

FocusBehavior Class

Visual Studio 2022 C# 빌드 오류, System.BadImageFormatException: 'Corrupt .resources file. Unable to read resources from this file because of invalid header information. Try regenerating the .resources file.'

FreeBear — Mon, 1 Apr 2024 13:22:59 +0900

System.BadImageFormatException: 'Corrupt .resources file. Unable to read resources from this file because of invalid header information. Try regenerating the .resources file.'

해결 방법

1. 솔루션 탐색기에서 [솔루션] 혹은 [프로젝트] 우클릭

2. 솔루션에서는 [솔루션 정리], 프로젝트에서는 [정리] 클릭

3. 프로젝트 우클릭 후 [다시 빌드] 클릭