Jasmin Time

무료로 돌잔치 모바일 초대장 만들기 : GitHub Pages 배포

FreeBear — Mon, 3 Aug 2026 17:23:36 +0900

모바일 돌잔치 초대장 만들기부터 GitHub Pages 배포까지

돌잔치를 준비하면서 종이 초대장 대신, 카카오톡이나 문자로 간편하게 전달할 수 있는 모바일 초대장을 직접 만들어 보았습니다.

처음에는 예전에 사용 중이던 웹호스팅을 이용하려고 했지만 생각해보니까 사용을 중지했었기에, 별도의 비용 없이 정적 웹사이트를 배포할 수 있는 GitHub Pages를 활용했습니다.

돌잔치 모바일 초대장 화면 일부

* 일부 데이터는 예시용으로 입력되어 있습니다.

이번 글에서는 크게 두 가지 내용을 정리하려고 합니다.

HTML, CSS, JavaScript로 모바일 돌잔치 초대장을 만든 과정
완성한 초대장을 GitHub Pages에 무료로 배포한 과정

모바일 초대장을 직접 만든 이유

요즘에는 돌잔치 초대장은 대부분 모바일 형태로 만들어서 스마트폰으로 전달하고 확인한다는 얘기들을 들었습니다.

종이 초대장도 의미가 있지만, 아주 가까운 지인들끼리 모여서 하는 잔치에 종이 초대장은 품이 많이 드는데
모바일 초대장은 링크 하나만 보내면 되고 행사 정보가 변경되었을 때도 바로 수정할 수 있다는 장점이 있습니다.

또한 다음과 같은 기능들을 함께 넣고 싶었습니다.

아이 사진과 이름
초대 문구
돌잔치 날짜와 시간
행사 장소와 주소
네이버지도 및 카카오맵 연결
돌잔치까지 남은 시간 표시
사진 갤러리
전화 및 문자 연결
계좌번호 복사
초대장 링크 공유

이번 초대장은 별도의 프레임워크 없이 HTML, CSS, JavaScript만 사용해 제작했습니다.

1. 모바일 돌잔치 초대장 만들기

프로젝트 구성

파일은 다음과 같이 구성했습니다.

posting-invitation/
├─ index.html
├─ README.md
├─ .nojekyll
└─ assets/
   ├─ css/
   │  └─ style.css
   ├─ js/
   │  ├─ config.js
   │  └─ main.js
   └─ images/
      ├─ main.jpg
      ├─ gallery-01.jpg
      ├─ gallery-02.jpg
      └─ ...

파일별 역할은 다음과 같습니다.

index.html

모바일 초대장의 전체 화면 구조를 담당합니다.
초대 문구, 행사 정보, 사진 갤러리, 연락처, 공유 버튼이 들어갈 영역을 구성했습니다.

style.css

초대장의 전체 디자인과 모바일 반응형 화면을 담당합니다.
스마트폰에서 보기 편하도록 콘텐츠 너비를 제한하고, 버튼 크기와 글자 간격도 모바일 기준으로 조정했습니다.

config.js

아이 이름, 행사 날짜, 장소, 연락처처럼 자주 수정하는 정보를 한곳에서 관리합니다.

main.js

설정값을 화면에 표시하고, 카운트다운과 사진 확대, 계좌번호 복사, 공유 기능을 처리합니다.

수정할 정보를 config.js에 모으기

* 일부 데이터는 예시용으로 입력되어 있습니다.

초대장을 만들 때 가장 중요하게 생각한 부분은 유지보수였습니다.

정보를 바꿀 때마다 HTML을 직접 수정하면 실수하기 쉽기 때문에, 변경 가능한 정보는 config.js에 모았습니다.

window.INVITATION_CONFIG = {
  baby: {
    name: "김사랑",
    englishName: "SARANG",
    eventDate: "2026-08-15",
    eventTime: "오후 12시 00분",
    mainImage: "assets/images/main.jpg",
    message: `사랑으로 키운 소중한 아이가
어느덧 첫 번째 생일을 맞았습니다.
기쁜 날 함께 축복해 주세요.`
  }
};

아이 이름이나 날짜가 변경되더라도 이 파일만 수정하면 됩니다.

대표 사진도 파일 경로만 바꾸면 됩니다.

mainImage: "assets/images/main.jpg"

갤러리 사진도 배열로 관리했습니다.

gallery: [
  "assets/images/gallery-01.jpg",
  "assets/images/gallery-02.jpg",
  "assets/images/gallery-03.jpg",
  "assets/images/gallery-04.jpg"
]

이 방식으로 구성하면 사진을 추가하거나 순서를 변경하기도 편합니다.

모바일 중심으로 화면 구성하기

초대장은 PC보다 스마트폰으로 보는 비율이 높기 때문에 모바일 화면을 기준으로 제작했습니다.

전체 콘텐츠 영역의 최대 너비를 제한하고, 화면이 넓은 PC에서도 모바일 초대장처럼 보이도록 구성했습니다.

.page {
  width: min(100%, 680px);
  margin: 0 auto;
  overflow: hidden;
}

버튼은 손가락으로 누르기 쉽도록 충분한 높이를 주었습니다.

.button {
  min-height: 52px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  border-radius: 999px;
}

사진 갤러리는 모바일 화면에서 두 줄로 자연스럽게 보이도록 구성했습니다.

.gallery-grid {
  display: grid;
  grid-template-columns: repeat(2, 1fr);
  gap: 10px;
}

돌잔치 카운트다운 기능

행사일까지 남은 시간을 보여주는 카운트다운 기능도 추가했습니다.

function calculateCountdown(eventDate) {
  const targetDate = new Date(`${eventDate}T00:00:00`);
  const difference = targetDate.getTime() - Date.now();

  if (difference <= 0) {
    return {
      days: 0,
      hours: 0,
      minutes: 0,
      seconds: 0
    };
  }

  return {
    days: Math.floor(difference / 86400000),
    hours: Math.floor((difference % 86400000) / 3600000),
    minutes: Math.floor((difference % 3600000) / 60000),
    seconds: Math.floor((difference % 60000) / 1000)
  };
}

행사 날짜는 설정 파일에서 변경할 수 있습니다.

eventDate: "2026-08-15"

날짜만 수정하면 화면의 카운트다운도 자동으로 변경됩니다.

사진 갤러리와 확대 보기

초대장에는 아이 사진을 여러 장 볼 수 있는 갤러리를 넣었습니다.

사진을 누르면 확대 화면이 열리도록 구현했습니다.

function openLightbox(imageUrl) {
  const dialog = document.querySelector("[data-lightbox]");
  const image = document.querySelector("[data-lightbox-image]");

  if (!dialog || !image) {
    return;
  }

  image.src = imageUrl;
  dialog.showModal();
}

스마트폰에서는 사진을 크게 볼 수 있어 일반 이미지 목록보다 훨씬 보기 좋았습니다.

전화와 문자 연결

부모님 연락처는 전화와 문자 버튼으로 연결했습니다.

<a href="tel:01000000000">전화</a>
<a href="sms:01000000000">문자</a>

스마트폰에서 버튼을 누르면 전화 앱이나 문자 앱이 바로 실행됩니다.

계좌번호 복사 기능

계좌번호는 직접 드래그해서 복사하지 않아도 되도록 복사 버튼을 추가했습니다.

async function copyAccountNumber(accountNumber) {
  try {
    await navigator.clipboard.writeText(accountNumber);
    alert("계좌번호가 복사되었습니다.");
  } catch (error) {
    console.error(error);
    alert("계좌번호를 복사하지 못했습니다.");
  }
}

모바일에서는 이런 작은 기능이 실제 사용성을 많이 높여 줍니다.

참고로 이 부분은 실제 돌잔치에서는 많이 사용하지 않을 것 같은 기능으로 저도 실제 초대장에는 없는 영역이지만, 추후 친인척들 모바일 첩청장 혹은 회비가 필요한 모임장들을 만들어 주거나 도움을 줄때 필요할 듯하여 미리 구상해놓은 부분입니다.

또한 GitHub Pages는 공개 웹사이트이므로 계좌번호와 연락처를 표시할 때는 공개 범위를 고려해야 합니다.

지도 연결하기

행사 장소는 카카오맵과 네이버지도 링크로 연결했습니다.

place: {
  name: "행복한 연회장 3층",
  address: "서울특별시 행복구 사랑로 123",
  kakaoMapUrl: "https://map.kakao.com/...",
  naverMapUrl: "https://map.naver.com/..."
}

지도에서 행사 장소를 검색한 뒤 공유 링크를 복사해 넣으면 됩니다.

초대장 공유 기능

모바일 초대장의 가장 큰 장점은 링크 하나로 공유할 수 있다는 점입니다.

Web Share API를 지원하는 스마트폰에서는 기본 공유 화면을 사용할 수 있습니다.

async function shareInvitation() {
  const shareData = {
    title: "우리 아이의 첫 번째 생일",
    text: "소중한 분들을 첫돌에 초대합니다.",
    url: window.location.href
  };

  if (navigator.share) {
    await navigator.share(shareData);
    return;
  }

  await navigator.clipboard.writeText(window.location.href);
}

공유 기능을 지원하지 않는 브라우저에서는 링크를 복사하도록 처리했습니다.

2. GitHub Pages로 무료 배포하기

모바일 초대장을 완성한 뒤에는 다른 사람이 접속할 수 있도록 웹에 배포해야 합니다.

별도의 웹호스팅 대신 GitHub Pages를 사용했습니다.

참고로 GitHub Pages는 GitHub 저장소에 있는 HTML, CSS, JavaScript 파일을 웹사이트로 공개할 수 있는 기능입니다.

GitHub 사이트에 들어가서 아이디가 없다면 회원가입 후 로그인을 합니다. 로그인을 하면 대시보드가 보입니다.

GitHub · Change is constant. GitHub keeps you ahead.

Join the world's most widely adopted, AI-powered developer platform where millions of developers, businesses, and the largest open source community build software that advances humanity.

github.com

GitHub 저장소 만들기

GitHub 대시보드에서 New버튼을 클릭하여 새로운 저장소(repository)를 만듭니다.

저장소 이름은 다음과 같이 정했습니다.

posting-invitation

파일 업로드하기

완성한 프로젝트 파일을 GitHub 저장소에 업로드합니다.

가장 중요한 점은 index.html이 저장소 최상위에 있어야 한다는 것입니다.

올바른 구조는 다음과 같습니다.

posting-invitation/
├─ index.html
├─ README.md
├─ .nojekyll
└─ assets/

다음처럼 폴더가 한 단계 더 들어가면 페이지가 정상적으로 열리지 않을 수 있습니다.

posting-invitation/
└─ github-pages-test/
   ├─ index.html
   └─ assets/

GitHub Pages 설정

파일 업로드가 끝나면 저장소의 설정으로 이동합니다.

(대시보드에서 방금 만든 저장소 posting-invitation 선택 →) Settings → Pages

Settings 위치

Pages 위치

Build and deployment 항목을 다음과 같이 설정합니다.

Source: Deploy from a branch
Branch: main
Folder: /(root)

설정을 저장하면 GitHub가 자동으로 페이지를 배포합니다.

생성되는 주소 형식은 다음과 같습니다.

https://GitHub사용자명.github.io/저장소이름/

배포했는데 화면이 이상할 때

GitHub Pages 주소는 열리는데 일부 내용이 표시되지 않거나 디자인이 깨지는 경우가 있습니다.

이때는 아래 항목을 확인하면 됩니다.

index.html 위치

저장소 첫 화면에 index.html이 바로 보여야 합니다.

posting-invitation/index.html

JavaScript 파일 위치

이번 초대장은 JavaScript로 내용을 채우기 때문에 다음 파일이 반드시 필요합니다.

assets/js/config.js
assets/js/main.js

파일명 대소문자

GitHub Pages에서는 파일명 대소문자를 구분합니다.

config.js
Config.js

두 파일은 서로 다른 파일로 인식됩니다.

상대 경로 사용

이미지와 CSS, JavaScript 경로는 다음처럼 상대 경로를 사용하는 것이 안전합니다.

assets/images/main.jpg
assets/css/style.css
assets/js/main.js

경로 앞에 /를 붙이면 저장소 하위 경로에서 문제가 생길 수 있습니다.

Pages 설정 확인

Branch: main
Folder: /(root)

캐시 새로고침

수정한 내용이 바로 반영되지 않을 때는 강력 새로고침을 합니다.

Ctrl + F5

모바일에서는 시크릿 모드로 접속해 확인하는 것도 방법입니다.

GitHub Pages를 사용한 이유

GitHub Pages를 사용하면서 느낀 장점은 다음과 같습니다.

별도의 웹호스팅 비용이 필요하지 않음
HTML, CSS, JavaScript 파일만으로 배포 가능
수정한 파일을 다시 올리면 바로 반영 가능
기본 HTTPS 지원
GitHub 저장소에서 파일과 변경 이력을 관리할 수 있음
별도 프로그램 설치 없이 링크로 공유 가능

모바일 초대장처럼 서버 기능이 필요하지 않은 정적 웹사이트에는 잘 맞는 방식이라고 생각합니다.

GitHub Pages의 한계

GitHub Pages는 정적 웹사이트만 지원합니다.

다음 기능은 사용할 수 있습니다.

HTML
CSS
JavaScript
이미지
웹폰트

반면 다음 기능은 직접 사용할 수 없습니다.

PHP
MySQL
ASP.NET
서버 세션
서버 파일 저장

참석 여부나 방명록 데이터를 저장하려면 Google Forms, Firebase, Supabase 같은 외부 서비스를 추가로 연결해야 합니다.

제작 후기

이번 작업은 단순히 초대장 화면을 만드는 것보다, 실제로 링크를 공유할 수 있는 상태까지 배포하는 것이 목표였습니다.

모바일 초대장은 HTML, CSS, JavaScript만으로도 충분히 보기 좋고 편리하게 만들 수 있었습니다.

특히 정보 수정 부분을 config.js로 분리한 덕분에 아이 이름, 행사 날짜, 장소, 연락처, 사진을 비교적 쉽게 변경할 수 있었습니다.

또한 GitHub Pages를 활용해 별도의 웹호스팅 비용 없이 초대장을 공개할 수 있었습니다.

전체 과정을 정리하면 다음과 같습니다.

1. HTML로 초대장 구조 만들기
2. CSS로 모바일 화면 디자인하기
3. JavaScript로 카운트다운과 공유 기능 추가하기
4. 변경할 정보를 config.js로 분리하기
5. GitHub 저장소에 파일 업로드하기
6. GitHub Pages를 main 브랜치의 /(root)로 설정하기
7. 생성된 주소를 카카오톡이나 문자로 공유하기

모바일 초대장처럼 서버 기능이 필요하지 않고 링크로 간단히 전달할 웹페이지라면 GitHub Pages를 활용하는 방법이 좋은 선택이 될 수 있습니다.

최종 결과

완성한 모바일 돌잔치 초대장입니다.

https://yoosple.github.io/posting-invitation/

우리 아이의 첫 번째 생일

소중한 첫돌에 초대합니다.

yoosple.github.io

* 일부 데이터는 예시용으로 입력되어 있습니다.

이렇게 가족이나 지인에게 링크만 전달하면 별도의 앱 설치 없이 스마트폰 브라우저에서 바로 확인할 수 있습니다.

모바일 초대장의 HTML, CSS, JavaScript 등 웹페이지 소스에 대한 자세한 정보는 제 깃허브 브런치에서 확인할 수 있습니다.

https://github.com/yoosple/posting-invitation

GitHub - yoosple/posting-invitation

Contribute to yoosple/posting-invitation development by creating an account on GitHub.

github.com

임신 40주 5일 유도분만 출산 후기｜약 16시간의 과정, 힘주기 7번 만에 만난 2.54kg 아기

FreeBear — Thu, 30 Jul 2026 21:58:25 +0900

미루고 미루었던 출산 기록을 이제야 정리해본다.

출산 직후에는 그날의 일을 잊지 않으려고 시간대별로 꽤 자세하게 기록해두었다. 그런데 시간이 지나 다시 읽어보니 기억이 선명한 부분도 있고, 시간이 지나면서 흐릿해진 부분도 있었다.

그래도 분명하게 기억하는 사실이 있다.

오전 8시쯤 촉진제 투여를 시작했고, 아기가 태어난 시간은 밤 11시 47분이었다.

촉진제 투여부터 아기가 태어나기까지 약 15시간 47분. 거의 16시간이 걸린 셈이다.

다만 실제로 분만실에 들어가 힘을 준 시간은 길지 않았다. 간호사 선생님의 구령에 맞춰 일곱 번 정도 힘을 줬고, 약 15분 만에 아기가 태어났다.

그래서 내 출산 시간을 하나로만 표현하기는 조금 어렵다.

유도분만 전체 과정은 약 16시간.
실제 힘주기는 약 15분.

그리고 내게 가장 힘들었던 시간은 실제로 분만실에서 힘을 줬던 15분이 아니었다.

진진통이 강해지던 시간, 무통주사를 맞기 직전의 진통, 그리고 몸에서는 이미 힘을 주라고 계속 신호를 보내는데 아직 힘을 주면 안 된다고 해서 억지로 참아야 했던 시간이 가장 괴로웠다.

출산 예정일이 지나도록 조용했던 아기

내 출산 예정일은 2025년 10월 8일이었다.

막달이 되면 오늘일까, 내일일까 하며 진통을 기다리게 된다는데 예정일이 되어도 별다른 소식이 없었다.

배가 뭉치는 느낌이 어쩌다 한 번씩 있기는 했지만 규칙적이지 않았다. 이게 가진통인지 단순한 배뭉침인지도 구분하기 어려웠다.

진통이 시작되는 느낌은 어떤지, 이슬은 어떻게 보이는지, 양수가 터지면 바로 알 수 있는지 검색하며 기다렸지만 날짜만 계속 흘렀다.

예정일이 마지막 검진날이었는데 양수가 점점 줄어들고 있다는 이야기를 들었다.

가능하면 자연스럽게 진통이 시작되기를 기다리고 싶었지만 마냥 기다릴 수만은 없었다. 의사 선생님께서는 10월 13일이 미룰 수 없는 데드라인이라고 하셨고, 이때까지 출산 소식이 없으면 유도분만을 진행하기로 했다.

그렇게 임신 40주 5일차 태어날때까지 감감무소식이었다.

유도분만 당일, 새벽부터 시작된 긴장

유도분만 당일 새벽에는 더욱 잠을 제대로 자지 못했다.

자다가 깨기를 반복하면서 혹시 자연진통이 시작되는 건 아닐까 계속 신경을 썼다.

배가 조금만 불편해도

‘이게 진통인가?’

싶어 긴장했고, 다시 잠들었다가도 얼마 지나지 않아 깨곤 했다.

유도분만을 하러 가기로 한 날이었지만, 병원에 가기 전에 자연스럽게 진통이 시작될 수도 있다는 기대와 긴장이 함께 있었다.

오전 6시 50분쯤, 갑자기 새빨간 피가 보였다

아침 6시 50분쯤 화장실에 갔는데 새빨간 피가 나왔다.

그리고 배도 생리통처럼 아프기 시작했다.

출산을 앞두고 이슬이 비칠 수 있다는 건 알고 있었지만, 내가 생각했던 이슬은 점액이 섞인 분홍빛 피였다.

그런데 너무나 선명한 피여서 걱정이 됐다.

혹시 조기태반박리 같은 문제가 생긴 것은 아닐까 불안해졌다.

분만실에서는 원래 아침 8시까지 오라고 했지만, 전화로 상황을 설명한 뒤 조금 더 일찍 출발했다.

그렇게 오전 7시 30분쯤 병원에 도착했다.

검사 결과, 출혈은 이슬이었다

병원에 도착한 뒤 코로나 검사를 하고 분만실에 입실했다.

의료진에게 출혈에 관해 이야기했고 상태를 확인했다.

결과적으로 내가 본 피는 문제가 되는 출혈이 아니라 이슬이었다.

나는 이슬이라면 점액이 섞인 분홍빛 피만 나오는 것으로 알고 있었다.

하지만 배가 맹장염처럼 쥐어짜듯 아프지 않고, 초음파 검사에서도 별다른 문제가 없다면 생리처럼 피가 보이는 것도 이슬일 수 있다고 설명해주셨다.

조기태반박리를 걱정하며 병원에 일찍 왔지만, 다행히 아기와 태반에는 문제가 없었다.

그제야 조금 마음이 놓였다.

오전 8시, 촉진제 투여 시작

환복하고 태동과 자궁수축을 확인하는 장치를 부착했으며, 수액을 연결하고 필요한 처치를 받았다.

그리고 오전 8시쯤 촉진제 투여가 시작됐다.

촉진제를 맞는다고 바로 견디기 어려운 진통이 찾아온 것은 아니었다.

처음에는 배가 조금씩 단단하게 뭉치고 생리통처럼 묵직한 느낌이 오는 정도였다. 통증이 왔다가 사라지기는 했지만 대화도 할 수 있었고 휴대폰을 볼 여유도 있었다.

그래서 처음에는 속으로 생각했다.

‘생각했던 것보다는 할 만한데?’

하지만 시간이 지나면서 상황은 달라졌다.

촉진제가 계속 들어가고 진통 간격이 짧아지면서 통증도 점점 강해졌다. 처음에는 견딜 만했던 통증이 어느 순간부터는 진통이 올 때마다 대화를 멈추고 호흡에만 집중해야 할 정도로 변해갔다.

끝나는 시간을 알 수 없어서 더 힘들었던 기다림

유도분만을 시작하면 몇 시간 안에 빠르게 아기를 만날 수 있을 거라고 막연히 생각했던 것 같다.

그런데 실제로는 자궁문이 열리고 아기가 내려오기를 기다리는 시간이 길었다.

내진을 통해 진행 상태를 확인했지만 생각보다 빠르게 진행되지 않는 것처럼 느껴질 때는 마음도 조급해졌다.

‘오늘 안에는 낳을 수 있을까?’

‘여기까지 고생했는데 결국 수술하게 되는 건 아닐까?’

그런 생각도 들었다.

촉진제는 계속 들어가고 통증은 점점 강해지는데 언제 끝날지는 알 수 없었다.

유도분만은 통증도 힘들었지만, 끝나는 시간을 알 수 없는 상태로 계속 기다리는 과정도 쉽지 않았다.

진통 못지않게 중요했던 배고픔

내 출산 기록에서 배고픔은 절대 빼놓을 수 없는 이야기다.

유도분만이 얼마나 오래 걸릴지 알 수 없고, 상황에 따라 수술로 전환될 가능성도 있었기 때문에 음식을 마음대로 먹을 수 없었다.

아침부터 촉진제를 맞고 밤늦게까지 출산 과정이 이어졌으니 당연히 배가 고팠다. 병실에 있는 TV를 보다가 먹는 것만 나오면 나도 모르게 홀린 듯이 보고는 했다.

출산 전, 열심히 걷는 중

진통이 본격적으로 심해지기 전에는 통증보다 배고픔이 더 신경 쓰일 때도 있었다. 배고픔도 잊고 통증도 잊기 위해 복도를 열심히 걸었다.

나는 임신 후반기에 임당까지 있었기 때문에 오랫동안 먹고 싶은 것을 마음대로 먹지 못했다.

무엇을 먹으면 혈당이 오르는지 신경 써야 했고, 식사 순서도 고민했다. 식사를 마치면 혈당을 낮추기 위해 매번 걷거나 운동해야 했다.

그래서 임신 기간 내내 출산만 하면 먹고 싶은 것을 마음껏 먹겠다고 생각했다.

그런데 출산 당일에는 오히려 아무것도 먹지 못한 채 진통을 견뎌야 했다.

시간이 길어지면서 배고픔은 점점 절박해졌다.

그러다 보니 나중에는 오기가 생겼다.

‘오늘은 무조건 낳는다.’

오늘 아기를 낳지 못하면 다음 날까지 계속 먹지 못할 수도 있었다. 유도분만이 실패하거나 수술로 이어지면 언제 음식을 먹을 수 있을지도 알 수 없었다.

그래서 진통이 아무리 힘들어도 오늘 안에는 반드시 출산하겠다는 일념으로 버텼다.

물론 아기를 빨리 만나고 싶은 마음이 가장 컸다.

하지만 솔직히 말하면,

‘오늘은 꼭 낳고 뭐라도 먹어야 한다.’

는 집념도 나를 끝까지 버티게 한 큰 원동력이었다.

지금 생각하면 웃기기도 하지만 그때는 정말 진지하고 간절했다.

오후가 되면서 강해진 진통

시간이 지나면서 진통은 점점 강해졌다.

처음에는 생리통처럼 묵직한 느낌이었다면, 오후가 되자 진통이 오는 동안 다른 생각을 하기 어려워졌다.

통증이 시작되면 몸에 저절로 힘이 들어갔고, 허리와 골반 쪽까지 아픈 느낌이 이어졌다.

오전에는 걸으면서 참을 수 있었는데, 도저히 참기가 힘들어졌다.

TV 화면도 더이상 눈에 들어오지 않았다.

무통주사를 맞기 전의 진통

오전에 참기 힘들면 자궁 열린 것이 4센치이상이 아니어도 무통주사를 맞을 수 있다고 하셨었는데, 무통주사를 맞기 전까지 엄청 고민을 했다. 아 그래도 좀 참을만한데, 싶다가도 아니 이거를 참아야 하는 건가 하는 왔다갔다하는 마음. 지금 얘기할까 말까. 그러다 오후 5시즈음 결국 무통주사를 놔달라고 얘기했다.

하지만 무통주사를 원한다고 해서 그 순간 바로 맞을 수 있는 것은 아니었다. 마취를 준비하고 기다리는 동안에도 진통은 계속됐다.

나는 이때의 진통이 출산 과정 중에서도 특히 힘들게 기억에 남는다.

이미 통증은 참기 어려울 만큼 강해졌는데 언제 무통주사를 맞을 수 있을지는 알 수 없었다.

진통이 올 때마다 말하기도 어려웠고 호흡에만 집중하려고 했다.

출산 과정에서 가장 아팠던 순간을 꼽으라면 나는 무통주사를 맞기 직전의 진통을 먼저 떠올릴 것 같다.

무통주사 카테터 삽입에 30분이 걸렸다

무통주사를 맞기 위한 카테터 삽입은 보통 10분 정도 걸린다고 들었다.

그런데 나는 척추뼈가 촘촘한 편이었고, 카테터가 들어갈 공간도 좁은 데다 큰 혈관까지 길을 막고 있어 한 번에 삽입되지 않았다.

결국 한 차례 시도한 뒤 다시 위치를 잡아 국소마취를 한 번 더 맞았고, 카테터 삽입이 완료되기까지 총 30분 정도가 걸렸다.

당시에는 배가 너무 아파서 등을 둥글게 말아 자세를 잡는 것도, 국소마취 주사를 맞는 것도 크게 신경 쓰이지 않았다. 오히려 무통주사를 맞기 전 항생제 주사를 맞을 때의 통증이 더 기억에 남는다.

그렇게 무통주사 준비가 끝났고, 무통주사의 약이 돌자, 왜 다들 무통주사를 ‘무통천국’이라고 부르는지 바로 알게 됐다.

무통주사를 맞기 전까지는 진통이 허벅지까지 내려오는 느낌이었고, 걸어 다녀도 통증이 사라지지 않았다. 몸이 떨릴 정도로 배가 아팠는데, 무통주사가 들어가고 나서는 그 통증이 거짓말처럼 사라졌다.

몇 시간 동안 통증 때문에 긴장하고 있던 몸이 잠시 풀리는 느낌이었다.

그제야 숨을 돌릴 수 있었다.

‘이제 좀 살겠다.’

싶었다.

출산 진행을 위해 양수를 터뜨렸다

오후에 내진을 한 번 하시더니 진행이 잘 되고 있다면서 출산 진행을 돕기 위해 의료진이 인공적으로 양막을 터뜨렸다.

자연스럽게 양수가 터진 것이 아니라 처치를 통해 양수를 터뜨린 것이었다.

양막을 터뜨리고 나니 따뜻한 물이 흘러나오는 듯한 느낌이 들었다.

그 순간,

‘이제 정말 출산이 본격적으로 진행되는구나.’

하는 생각이 들었다.

촉진제를 맞고 기다릴 때는 출산이 언제 진행될지 막연하게 느껴졌는데, 양수를 터뜨리고 나니 아기를 만나는 과정이 한 단계 더 진행된 것처럼 느껴졌다.

그렇다고 바로 아기가 나온 것은 아니었다.

자궁문이 더 열리고 아기가 충분히 내려오기를 기다려야 했다.

인공파막 이후에는 진통과 아래쪽 압박감이 엄청 막 아픈 건 아니었지만 무통주사의 효과를 뚫고 느낄 수 있었던 것으로 기억한다.

몸에서는 힘을 주라고 하는데 참아야 했다

내게 출산 과정 중 가장 괴로웠던 순간은 실제로 힘을 줄 때가 아니었다.

밤 9시즈음부터 몸이 저절로 힘을 주려고 했다.

단순히 배가 아픈 느낌과는 전혀 달랐다. 무통때문에 배가 아픈 건 아닌데, 아래쪽으로 힘이 자동적으로 들어가서 식은땀이 났다. 내진으로는 7~8cm가 열렸는데 좀 더 기다리라고 해서 기다려야 했다.

온몸에서,

‘지금 당장 밀어내야 한다.’

는 신호를 보내는 것 같았다.

진통이 올 때마다 아래로 힘이 쏠렸고 본능적으로 힘을 주고 싶었다.

밤 10시 30분즈음 도저히 못 참겠어서 남편에게 간호사 선생님을 불러달라 얘기하고, 나는 변기에 앉아서 막 힘을 주려고 했다.

그런데 간호사 선생님이 오셔서 내 상황을 보시더니 함부로 힘을 주면 안 된다고 했다. 그리고 내진을 하시더니 분만실로 가기위해 준비를 시작했다.

몸은 이미 아기를 낳으려고 하는데, 머리로 그 힘을 억지로 참아야 했다.

그 시간이 정말 괴로웠다.

힘이 들어가려는 순간마다 호흡으로 참아야 했다. 간호사 선생님도 힘을 주지 말고 호흡하라고 했지만 진통이 강해질수록 몸의 반응을 억누르는 게 쉽지 않았다.

차라리 마음껏 힘을 주라고 하면 더 낫겠다는 생각이 들 정도였다.

이미 긴 공복으로 체력도 떨어진 상태였고 진통은 계속 강해졌다.

그런데도 나는 계속 생각했다.

‘여기까지 왔으니 오늘 반드시 낳는다.’

내게는 실제 힘주기 15분보다 이렇게 힘을 주지 않으려고 참았던 시간이 훨씬 더 힘들었다.

밤 11시가 넘어 시작된 분만 준비

밤 11시 무렵이 되자 의료진의 움직임이 분주해졌다.

아기가 많이 내려왔고 출산이 가까워졌다는 분위기가 느껴졌다.

분만실에서

분만 준비가 끝나기를 기다리는 동안에도 몸은 계속 힘을 주라고 신호를 보냈다.

하지만 아직은 마음대로 힘을 줄 수 없었다.

그 시간을 버티고 나서야 드디어 힘을 줘도 된다는 말을 들었다.

드디어 마음껏 힘을 줘도 된다는 말

11시 30분 즈음, 간호사 선생님이 진통이 올 때 맞춰 힘을 주라고 했다.

그 말을 들었을 때는 오히려 안도감이 들었다.

이제는 더 이상 힘을 참지 않아도 됐다.

진통이 시작되면 숨을 크게 들이마시고, 간호사 선생님의 구령에 맞춰 온몸의 힘을 아래쪽으로 모았다.

임신 막달부터 호흡법을 공부했었고, 또 어떤 사람의 출산 후기에서 3번인가 4번만에 힘을 줘서 낳았다는 말에 나도 그렇게 힘줘서 꼭 낳고야 말겠어 라는 결심으로 힘을 냈다.

남편도 옆에서 내 몸을 잡아주면서 호흡법을 잘 해낼 수 있도록 도와줬다.

한 번 힘을 주고 잠시 숨을 고른 뒤, 다음 진통이 오면 다시 힘을 줬다.

총 7번, 약 15분간의 힘주기

그렇게 총 7번의 힘을 줬다.

4번의 힘주기로 안 나왔을 때에는, 실망감이 들면서 힘이 좀 빠질 뻔했지만 분만실 안에 있는 시계를 보며 12시 전까지는 꼭 낳을거야라는 다짐을 하며 힘줄때마다 이번이 마지막이야라는 생각으로 힘을 주었고, 그렇게 7번의 힘을 주게 된 것이다.

실제로 힘주기를 시작한 뒤 아기가 태어나기까지는 약 15분 정도였다.

촉진제를 맞고 기다린 시간, 진통을 견딘 시간, 힘주기를 참아야 했던 시간에 비하면 마지막 과정은 빠르게 진행됐다.

오히려 힘을 참아야 했던 때보다 마음껏 힘을 줄 수 있게 된 순간이 더 낫게 느껴졌다.

밤 11시 47분, 2.54kg 여자아기 출산

그렇게 7번 정도 힘을 준 뒤 아기가 태어났다.

시간은 밤 11시 47분.

임신 40주 5일.

2.54kg의 여자아기였다.

아기가 몸 밖으로 나오는 순간의 느낌은 지금도 정확히 생각난다.

다른 사람들의 후기에서는 수박이나 참외 같이 둥근 딱딱한 과일이 빠져나가는 느낌이고, 그래서 아주 개운해진다고 하는데, 전혀. 무언가 수욱하고 빠져나가는 느낌은 났었지만 개운한 것은 없었다. 계속 몸에 힘이 들어가려고 했던 감각만 남아있었다.

23시 47분 탄생을 알리는 의사선생님의 소리가 들리고, 곧이어 아기의 울음소리가 들렸다. 그리고 내 몸 위에 아기가 놓여졌다. 두눈을 꼭 뜨고 나를 쳐다보려고 하는 것 같았다. 우리 아기는 날때부터 눈을 떴다. 호기심이 많은 아이임을 날때부터 알 수 있던 사항이었다.

내 몸에 올려진 아기가 너무 조그맣다는 생각을 했고, 아기에게 한 나의 첫마디는 "튼튼아 고생했어"였다.

그 후에 남편이 탯줄을 잘랐다고 했는데, 기진맥진해져있던 나는 그 부분만 전혀 기억이 없다.

약 16시간의 유도분만

시간을 다시 계산하면 이렇다.

오전 8시쯤 촉진제 투여를 시작했고, 밤 11시 47분에 아기가 태어났다.

촉진제 투여부터 출산까지 약 15시간 47분.

거의 16시간이었다.

출산 직후 남겨둔 기록에는 출산 시간이 6시간이라고 적혀 있었지만, 지금 다시 계산해보니 촉진제 투여 시점부터 계산한 시간은 아니었다.

아마 본격적으로 진통이 강해진 시점부터 계산했거나 정신없는 상태에서 대략적으로 적었던 것 같다.

내 출산을 정확히 표현하면 다음과 같다.

유도분만 전체 과정은 약 16시간.
실제 분만실에서 힘을 준 시간은 약 15분.
총 7번 정도 힘을 주고 아기를 낳았다.

회음부 통증은 거의 없었다

출산 전에는 회음부 절개와 출산 후 통증도 걱정했다.

그런데 내 경우에는 회음부를 아주 조금만 절개했고, 회음부 탄력도 좋은 편이라고 하셨다.

덕분에 회음부 통증은 거의 없었다.

출산 당일에는 조금 불편한 느낌이 있었지만 그날 이후 회음부 통증 때문에 고생하지는 않았다.

출산 후기를 보면 회음부 통증으로 오랫동안 힘들었다는 이야기도 많았는데, 이 부분은 다행이었다.

오히려 힘들었던 것은 훗배앓이

회음부 통증 대신 나를 힘들게 한 것은 훗배앓이였다.

아기를 낳은 뒤 자궁이 수축하면서 배가 조이듯 아팠다.

이미 유도분만과 출산으로 몸이 지친 상태였기 때문에 훗배앓이 통증이 더 힘들게 느껴졌다.

조금이라도 통증이 나아졌으면 하는 마음에 배를 계속 마사지했다.

얼마나 열심히, 또 세게 마사지했는지 나중에는 배에 멍까지 들었다.

훗배앓이 때문에 아픈 배를 낫게 해보겠다고 마사지하다가 오히려 멍까지 만든 셈이었다.

다행히 훗배앓이는 하루 정도 지나면서 많이 괜찮아졌다.

내 경우에는 출산 후 회음부 통증보다 이 하루 동안의 훗배앓이가 훨씬 더 힘들고 선명하게 기억에 남아 있다.

출산이 끝나자 머릿속은 온통 음식 생각뿐이었다

힘을 줄 때만큼은 아기가 조금이라도 덜 힘들었으면 하는 마음으로 버텼다.

그런데 아기가 태어나 신생아실로 이동한 뒤부터는 머릿속이 온통 음식 생각으로 가득 찼다.

수액을 맞고 있어서 허기가 견디지 못할 정도는 아니었지만, 하루 종일 금식한 상태였기 때문에 정신적인 배고픔이 꽤 컸다.

후처치가 끝난 뒤 자정 30분쯤 입원실로 이동했다. 병실에 도착하니 음식과 입퇴원 안내문을 가져다주셨는데, 내 눈에는 안내문보다 음식만 보였다.

가연관악산부인과 분만직후 식사

결국 새벽 1시가 되어서야 밥을 먹을 수 있었다.

분만 후 4시간 안에 소변을 봐야 한다고 했는데, 새벽 2시 30분쯤 소변을 본 뒤 무통주사 카테터도 제거했다.

그 뒤에는 훗배앓이가 올 때마다 자궁 마사지를 하며 버텼다. 남편과 이야기를 나누다가 새벽 5시쯤에야 겨우 잠이 들었다.

다른 출산 후기를 보면 아기가 나오자마자 몸이 시원해지고 통증이 사라졌다고 하는 경우도 많았다.

하지만 내 경우에는 아래 쪽 통증은 태반이 빠져나갈 때까지 이어졌고, 자궁이 수축하면서 생기는 훗배앓이는 다음 날 아침 식사 전까지 계속됐다.

조금 더 기다렸으면 자연진통이 왔을까

유도분만 당일 이슬이 비쳤던 것을 생각하면 가끔 궁금했었다.

조금만 더 기다렸다면 그날이나 다음 날 자연진통이 시작되지 않았을까.

촉진제를 맞지 않고도 자연스럽게 출산할 수 있지 않았을까.

조금 더 기다려볼 걸 그랬나 하는 아쉬움이 전혀 없다고 하면 거짓말이다.

하지만 당시 나는 예정일을 이미 넘긴 상태였고, 마지막 검진에서는 양수가 줄어들고 있었다.

의사 선생님은 괜히 10월 13일을 기다릴 수 있는 마지노선으로 정한 것이 아니었을 것이다.

이슬이 비쳤다고 해도 실제 진통이 언제 시작될지는 알 수 없었다. 자연진통이 올 가능성만 기다리다가 아기에게 필요한 양수가 더 줄어드는 상황은 만들고 싶지 않았다.

결과적으로 유도분만은 잘 진행됐고, 제왕절개로 전환하지 않은 채 아기를 건강하게 만났다.

그래서 지금의 결론은 이렇다.

조금 더 기다렸다면 자연진통이 왔을지도 모른다는 아쉬움은 있지만, 예정대로 유도분만을 진행해서 다행이었다.

당일 이슬이 비쳤다는 것은 어쩌면 내 몸도 이미 출산할 준비를 시작했다는 의미였을지 모른다.

그 상태에서 촉진제와 인공파막의 도움을 받아 그날 무사히 아기를 만날 수 있었다.

무엇보다 아기가 건강하게 태어났으니 당시의 선택은 잘한 선택이었다고 생각한다.

나의 유도분만 출산을 돌아보며

오전 8시부터 밤 11시 47분까지.

약 16시간 동안 촉진제를 맞고, 기다리고, 진통을 견디고, 힘을 주고 싶은 몸을 억지로 참았다.

실제로 분만실에서 힘을 준 시간은 약 15분.

총 7번 정도 힘을 주고 2.54kg의 여자아기를 만났다.

출산 전에는 아기가 실제로 나오는 순간이 가장 힘들 거라고 생각했다.

하지만 내가 겪어보니 가장 괴로웠던 순간은 무통주사를 맞기 직전의 진통과 몸에서 이미 힘을 주라고 신호를 보내는데 아직 때가 아니라며 그 힘을 참아야 했던 시간이었다.

반대로 막상 힘을 줘도 된다는 말을 들은 뒤에는 해야 할 일이 명확해졌다.

참지 않고 온몸의 힘을 한곳으로 모았다.

그리고 진통 못지않게 절박했던 것은 배고픔이었다.

임당 때문에 임신 후기 내내 먹는 것을 조절했고, 출산 당일에는 온종일 공복으로 버텨야 했다.

그래서 아기를 만나고 싶다는 마음과 함께,

‘오늘은 반드시 낳고 먹는다.’

는 일념으로 끝까지 버텼다.

출산 후 회음부 통증은 거의 없었지만 훗배앓이는 하루 동안 꽤 힘들었다. 통증을 줄여보겠다고 배를 마사지하다가 멍까지 들었다.

유도분만 당일 이슬이 보였던 것을 생각하면 조금 더 기다려볼 걸 그랬나 하는 아쉬움도 남아 있다.

하지만 양수가 줄고 있던 상황에서 의사 선생님이 정해준 마지노선을 따르길 잘했다.

그 긴 시간을 기다리고, 아파하고, 참고, 힘을 준 끝에 우리 아기를 무사히 만났다.

그리고 그날부터 우리 둘의 생활은 정말로 셋의 생활이 되었다.

임신 14~16주 기록, 입덧과 혼인신고

FreeBear — Wed, 29 Jul 2026 20:23:04 +0900

임신 14주쯤이 되면서 조금씩 몸 상태가 달라지기 시작했다.

그동안 가장 힘들었던 건 역시 입덧이었다.

내 경우에는 하루 종일 토하는 정도의 심한 입덧은 아니었지만, 계속되는 울렁거림 때문에 일상생활이 꽤 힘들었다.

먹어도 속이 불편하고,

안 먹어도 속이 불편하고,

괜찮아진 것 같다가도 다시 울렁거리고.

그런 상태가 꽤 오래 이어졌다.

끝난 줄 알았는데 다시 찾아오던 입덧

14주쯤부터는 조금씩 괜찮은 날이 생겼다.

하루 정도 속이 편하면

‘이제 진짜 끝난 건가?’

싶었다.

그런데 또 다음 날이면 울렁거렸다.

괜찮았다가 다시 안 좋아지고,

또 멀쩡했다가 다시 울렁거리고.

14~15주쯤에는 이런 식으로 입덧이 왔다 갔다 했다.

완전히 끝난 건 아닌 것 같은데, 그렇다고 이전처럼 계속 힘든 것도 아니었다.

그래서 조금씩 희망이 생겼다.

‘조금만 더 지나면 정말 괜찮아지려나.’

16주쯤 되니 정말 살 것 같았다

그러다 16주에 가까워지면서 울렁거림이 거의 사라졌다.

아침에 일어나도 속이 괜찮았고,

밥을 먹고 나서도 이전처럼 계속 불편하지 않았다.

회사에서도 컨디션이 훨씬 나아졌다.

무엇보다 피로감이 많이 줄었다.

그제야 내가 임신 초기에 얼마나 힘든 상태였는지 오히려 더 실감이 났다.

몸이 정상에 가까워지니

‘아, 원래 이렇게 사는 거였지.’

싶었다.

임신 초기에는 하루하루 버티는 게 일이었는데, 중기로 넘어가면서부터는 조금씩 일상을 되찾는 느낌이었다.

그리고 이 시기에는 혼인신고도 했다

몸 상태가 조금씩 나아지던 이 시기에는 우리에게 또 하나의 일이 있었다.

혼인신고.

원래 우리 계획은 4월 28일에 혼인신고를 하는 것이었다.

4월 28일은 우리가 사귀기 시작한 날로부터 딱 7년이 되는 날이었다.

그래서 이 날짜에 맞춰 혼인신고를 하면 의미 있겠다 싶었다.

기념일과 혼인신고 날짜가 같으면 나중에도 기억하기 좋을 것 같기도 했다.

그런데 현실적인 이유로 날짜를 조금 앞당겼다

문제는 5월에 예정되어 있던 전주 여행이었다.

우리는 5월 10일부터 일주일 동안 전주로 여행을 가기로 했다.

임신 중기였으니 사실상 태교여행이기도 했고,

아기가 태어나기 전에 남편과 둘이 여유롭게 다녀오는 마지막 긴 여행 같은 느낌도 있었다.

그리고 회사에서는 이 여행에 사용할 연차를 결혼 관련 연차로 처리하려고 했다.

그러려면 혼인관계와 관련된 서류도 미리 준비해야 했다.

4월 28일까지 기다렸다가 혼인신고를 하고 서류를 준비하기에는 조금 빠듯할 것 같았다.

그래서 결국 원래 계획보다 며칠 앞당겼다.

4월 24일, 혼인신고

결국 4월 24일에 혼인신고를 했다.

원래 생각했던 4월 28일은 아니었지만, 그래도 불과 며칠 차이였다.

이미 함께 살고 있었고,

아기도 생겼고,

생활 자체가 갑자기 달라지는 것은 없었다.

그래도 막상 혼인신고를 하고 나니 묘한 느낌은 있었다.

이제 정말 서류상으로도 가족이 된 느낌.

임신까지 하고 있는 상황이라 그런지 더 실감이 났던 것 같다.

혼인신고를 했더니 국기를 받았다

혼인신고를 마치고 나니 국기도 하나 받았다.

전혀 예상하지 못했던 거라 조금 신기했다.

혼인신고를 하러 갔다가 태극기를 들고 집에 돌아오게 될 줄은 몰랐다.

집에 와서 국기를 보면서

‘우리 진짜 혼인신고 했구나.’

싶었다.

7년 동안 연애하고,

같이 살고,

이제 아기까지 생기고,

결국 법적으로도 가족이 되었다.

생각해보면 이 시기가 여러모로 우리 가족의 형태가 하나씩 갖춰지던 때였던 것 같다.

7주년을 며칠 앞두고 부부가 되었다

원래 계획했던 4월 28일은 우리가 만난 지 정확히 7년이 되는 날이었다.

결국 혼인신고는 나흘 빠른 4월 24일에 했지만,

그 의미가 크게 달라진 것은 없었다.

오히려 그때의 우리에게는 조금 현실적인 선택이었다.

곧 전주 여행도 가야 했고,

회사에 제출할 서류도 준비해야 했고,

그 전에 처리할 수 있는 건 미리 처리해두는 게 편했다.

연애 7년.

그리고 임신.

그리고 혼인신고.

지금 생각해보면 꽤 많은 일이 한꺼번에 겹쳐 있던 시기였다.

입덧도 끝나고, 여행을 기다리기 시작했다

몸 상태도 좋아졌고,

혼인신고도 끝냈고,

이제 남은 건 5월의 전주 여행이었다.

임신 초기에는 여행이고 뭐고 그냥 집에 누워 있고 싶은 날이 많았다.

그런데 14주쯤부터는 컨디션이 조금씩 회복되어 가니 여행에 대한 기대도 생겼다.

어디를 갈지 찾아보고,

무엇을 먹을지 찾아보고,

숙소도 보고,

조금씩 여행 준비를 할 수 있었다.

그리고 실제로 5월 10일이 되었을 때는 임신 18주 3일차였다.

지금 돌아봐도 태교여행을 이 시기에 간 건 정말 잘한 선택이었다.

입덧은 끝났고,

배는 아직 너무 무겁지 않았고,

몸도 비교적 편했다.

임신 기간 중 가장 여행하기 좋았던 시기였다.

임신 초기가 끝나고 중기로 넘어가던 시간

14주부터 16주까지를 돌아보면,

내게는 “드디어 조금 살 것 같아진 시기”였다.

입덧이 끝날 듯 말 듯하다가 결국 사라졌고,

몸의 피로도 많이 줄었다.

그리고 개인적으로는 혼인신고까지 하면서

연애하던 둘에서,

아기를 기다리는 부부로,

조금씩 다음 단계로 넘어가고 있다는 느낌도 들었다.

그렇게 몸도 마음도 한결 편해진 상태로 임신 중기에 들어섰다.

그리고 얼마 지나지 않아,

우리는 전주로 태교여행을 떠났다.

다음 기록은 임신 18주, 전주에서 보낸 일주일간의 태교여행 이야기로 이어보려고 한다.

임신 7~13주 기록, 입덧이 시작되고 결국 회사에 임신 조기퇴근을 신청했던 시기

FreeBear — Tue, 28 Jul 2026 20:02:32 +0900

임신 전체를 지나고 나서 돌아보면 나는 임신 초기가 가장 힘들었다.

임신 전에는 배가 많이 나오는 후기가 당연히 제일 힘들 거라고 생각했는데, 직접 겪어보니 내 기준은 달랐다.

임신 초기 > 임신 후기 > 임신 중기

순으로 힘들었다.

특히 7주를 지나고 8주쯤부터 몸 상태가 확실히 달라지기 시작했다.

아직 배도 나오지 않았고, 회사 사람들에게 임신 사실을 제대로 알리지도 않았던 시기였다.

겉으로 보기에는 평소와 다를 게 없었지만 내 몸은 이미 평소와 전혀 달랐다.

8주쯤부터 시작된 입덧

내 경우에는 임신 8주쯤부터 울렁거림이 시작됐다.

처음에는 아주 심하지 않았다.

그냥 평소보다 속이 조금 안 좋은 정도라고 생각했다.

그런데 며칠 지나면서 점점 확실해졌다.

먹어도 속이 불편하고,

안 먹어도 속이 불편했다.

배가 고프면 울렁거리고,

뭔가를 먹으면 또 속이 답답했다.

토할 것 같은 느낌이 계속 있는데 막상 토하지는 않는 날도 많았다.

다른 사람들의 심한 입덧 이야기를 들어보면 나는 비교적 양호한 편이었을지도 모른다.

그래도 그 당시의 나에게는 충분히 힘들었다.

특히 문제는 그 상태로 매일 회사에 출근해야 한다는 것이었다.

겉으로는 멀쩡한데 몸은 하루 종일 힘들었다

임신 초기에는 정말 티가 나지 않는다.

배도 나오지 않았고 걸음걸이가 달라지는 것도 아니었다.

누군가 보기에는 평소의 나와 별 차이가 없었을 것이다.

그런데 나는 하루 종일 피곤했다.

졸리고,

집중도 잘되지 않고,

속은 계속 울렁거렸다.

원래라면 금방 처리했을 일도 오래 붙잡고 있는 날이 생겼다.

나 스스로도

'내가 왜 이렇게 일을 못하지?'

싶을 정도였다.

퇴근할 시간이 되면 정말 모든 에너지를 다 써버린 느낌이었다.

회사에는 아직 임신 사실을 제대로 알리고 싶지 않았다

당시에는 임신 초기이기도 해서 회사 사람들에게 임신 사실을 널리 알리고 싶지는 않았다.

첫 임신이기도 했고,

아직 초반이다 보니 괜히 조심스러운 마음이 컸다.

그래서 가능한 한 평소처럼 생활하려고 했다.

출근도 하고,

업무도 그대로 하고,

몸이 힘들어도 최대한 티를 내지 않으려고 했다.

그런데 생각보다 쉽지 않았다.

특히 입덧이 시작되고 나서는 내가 마음먹는다고 평소처럼 행동할 수 있는 게 아니었다.

결국 임신 조기퇴근을 신청했다

회사생활을 계속하다 보니 어느 순간

'이건 그냥 참는다고 해결될 일이 아니다.'

싶었다.

아침부터 속이 울렁거리고,

오후가 되면 피로가 더 심해졌다.

근무시간을 다 채우고 퇴근하는 것 자체가 너무 힘들게 느껴지는 날도 있었다.

결국 나는 임신 조기퇴근을 신청했다.

처음에는 그것도 조금 망설였다.

괜히 내가 유난인 것 같기도 하고,

다른 사람들은 임신하면서도 다 잘 다니는 것 같은데 나는 왜 이렇게 힘들까 싶기도 했다.

그런데 실제로 내가 임신해보니 알겠더라.

사람마다 임신 증상도 다르고, 힘든 정도도 전부 다르다는 것을.

그리고 힘들면 제도를 이용하는 게 맞았다.

억지로 버티는 게 능사는 아니었다.

조기퇴근을 신청하면서 결국 임신 사실도 알려야 했다

임신 사실을 회사에 널리 알리지 않고 지내고 있었지만, 조기퇴근을 신청하려면 결국 필요한 사람들에게는 임신 사실을 이야기해야 했다.

내가 원래 생각했던 것보다는 조금 이른 시점이었다.

그래도 몸 상태를 생각하면 더 이상 숨기면서 버티기 어려웠다.

조기퇴근을 신청한 뒤부터는 퇴근시간이 조금 빨라진 것만으로도 체감이 꽤 컸다.

회사에 있는 시간이 조금 줄어드는 것만으로도 몸이 덜 지쳤고,

집에 가서 쉴 수 있는 시간이 생긴다는 게 정말 좋았다.

그때 처음으로

'아, 내가 생각했던 것보다 많이 힘들었구나.'

하는 것도 느꼈다.

그래도 회사에서는 계속 아무렇지 않은 척했다

조기퇴근을 신청했다고 해서 회사 사람들이 모두 내 임신 사실을 알고 있었던 건 아니었다.

여전히 모르는 사람들도 있었다.

그래서 몸이 안 좋은 순간마다 설명하기도 애매했다.

울렁거림이 심할 때는 화장실 근처로 가서 잠깐 서 있곤 했다.

혹시 토할 수도 있으니 화장실에서 너무 멀리 떨어져 있고 싶지 않았다.

가만히 서서 속에만 집중하면 더 힘들어서 휴대폰을 보면서 정신을 다른 데로 돌리기도 했다.

웹서핑을 하다 보면 잠깐이라도 울렁거림을 잊을 수 있었다.

조금 괜찮아지면 다시 자리로 돌아갔다.

나에게는 그냥 버티기 위한 시간이었는데,

다른 사람 눈에는 전혀 다르게 보였던 모양이다.

일을 안 하고 노는 것처럼 보였나 보다

어느 날 팀장님을 통해 관련된 이야기를 들었다.

업무시간에 자리를 비우고 휴대폰을 보는 모습이 좋지 않게 보였다는 내용이었다.

솔직히 억울했다.

나는 놀고 싶어서 나가 있던 게 아니었다.

속이 너무 울렁거려서 잠깐이라도 진정시키려고 화장실 근처에 있었던 것이었다.

그런데 아직 내가 임신 중이라는 사실을 모르는 사람 입장에서는 그렇게 보일 수도 있겠다는 생각도 들었다.

당시에는 임신 호르몬 때문이었는지 괜히 눈물이 날 것 같은 기분도 들었다.

몸도 힘든데 이런 이야기까지 들으니 더 서럽게 느껴졌다.

그런데 나도 마음에 걸리는 부분은 있었다

그 당시에는 임신 때문에 집중력이 정말 많이 떨어져 있었다.

업무를 하다가도

'지금 몇 주 차지?'

'이 시기에는 이런 증상이 정상인가?'

궁금해서 회사 컴퓨터로 임신 관련 정보를 찾아보기도 했다.

그리고 5월에는 남편과 전주로 태교여행을 가기로 정해둔 상태라 중간중간 여행 정보를 알아보기도 했다.

그래서 팀장님에게 이야기를 들었을 때

'혹시 이것까지 본 건가?'

싶었다.

그러다 보니 완전히 억울하다고만 하기도 애매했다.

결국 별다른 설명은 하지 않고 앞으로 주의하겠다고 이야기하고 끝냈다.

지금 생각해도 당시의 기분은 참 복잡했다.

억울하기도 했고,

내가 조금 더 조심했어야 했나 싶기도 했고,

그냥 모든 것이 서럽기도 했다.

11주쯤에도 여전히 힘들었다

당시 다니던 산부인과에서는 주차별로 임신 관련 정보를 문자로 보내줬다.

지금도 11주차쯤 받은 문자를 캡처해둔 사진이 남아 있는데, 왜 굳이 캡처했는지는 기억나지 않는다.

다만 그 시기에도 꽤 힘들었다는 기억은 선명하다.

아마 당시의 나는

'지금 이렇게 힘든 게 정상인 건가?'

라는 확인이 필요했던 것 같다.

하루하루 주차가 지나가는 걸 보면서

조금만 더 지나면 괜찮아지겠지,

다음 주에는 나아지겠지,

하고 버텼다.

지금 생각하면 임신하면서 회사 다니는 것 자체가 대단했다

출산까지 모두 지나고 나서 다시 생각해보면,

임신한 상태로 출근해서 하루 종일 일한다는 것 자체가 정말 대단한 일이었다.

특히 임신 초기는 겉으로 티가 거의 나지 않는다.

다른 사람이 보기에는 그냥 멀쩡해 보인다.

하지만 실제로는

속은 울렁거리고,

몸은 피곤하고,

계속 졸리고,

집중은 안 되고,

감정까지 예민해져 있었다.

그 상태에서 평소와 똑같은 업무 효율을 유지하는 것은 내게 쉽지 않았다.

당시에는

'왜 이렇게 못 버티지.'

라는 생각도 했는데,

지금은 그때의 나에게 오히려 말해주고 싶다.

그 정도면 충분히 잘 버텼다고.

그리고 조금씩 끝이 보이기 시작했다

그렇게 13주를 지나면서 아주 조금씩 몸 상태가 나아지는 날이 생겼다.

물론 바로 입덧이 끝난 것은 아니었다.

14주가 되면

'이제 괜찮아졌나?'

싶다가 다시 울렁거리고,

또 하루 괜찮았다가 다음 날 힘들어지는 식이었다.

완전히 괜찮아진 건 15주에서 16주로 넘어갈 즈음이었다.

그때부터 비로소

'아, 이제 좀 살 것 같다.'

는 생각이 들기 시작했다.

다음 기록에서는 끝날 듯 끝나지 않았던 입덧이 드디어 사라졌던 임신 14~16주 이야기를 남겨보려고 한다.

임신 5~6주 기록, 아기집 확인부터 첫 심장소리까지

FreeBear — Mon, 27 Jul 2026 21:59:45 +0900

얼리 임테기로 두 줄을 확인하고 나서도 마음 한편에는 계속 의심이 남아 있었다.

분명 두 줄은 봤지만,

“정말 임신이 맞는 건가?”

하는 생각이 계속 들었다.

그래서 확실하게 확인해보기로 했다.

2025년 2월 6일 목요일.

남편과 나 둘 다 연차를 쓰고 집 근처 산부인과에 갔다.

지금 생각하면 이 날 하루 동안 참 많은 일을 했다.

첫 산부인과에서 걱정을 한가득 안고 나왔다가 다른 산부인과를 다시 찾아갔고,

임신확인서를 받고,

보건소에서 임산부등록까지 했다.

그리고 일주일 조금 뒤에는 처음으로 아기의 심장소리도 들었다.

2월 6일, 임신이 맞는지 확인하러 첫 산부인과로

얼리 임테기로 임신을 확인한 상태였지만 그래도 병원에서 직접 확인을 받고 싶었다.

그래서 2월 6일 목요일, 남편과 함께 연차를 쓰고 집 근처 산부인과에 갔다.

초음파를 봤는데 검은색으로 된 작은 아기집이 보였다.

진짜 임신이구나 싶기도 했는데,

문제는 심장소리가 들리지 않는다는 이야기였다.

당시 병원에서는 심장소리가 들리지 않는다면서 혹시 문제가 있는 경우일 수도 있다는 취지로 이야기를 해주셨다.

그 말을 듣는 순간 갑자기 불안해졌다.

얼리 임테기로 두 줄을 보고 기뻐했던 것도 잠시,

“설마 진짜 문제가 있는 건가?”

싶었다.

임신 사실을 확인한 지 얼마 되지도 않았는데 벌써부터 마음이 덜컥 내려앉았다.

그리고 시작된 남편의 폭풍검색

병원을 나오자마자 남편이 검색을 시작했다.

지금 생각하면 임신 기간 내내 나만 검색을 많이 한 게 아니었다.

남편도 만만치 않았다.

임신 5주,

아기집,

심장소리,

언제부터 들리는지,

다른 산부인과는 어디가 괜찮은지.

정말 열심히 찾아봤다.

그러다 집에서 한 정거장 정도 떨어진 곳에 24시간 분만실까지 운영하는 산부인과가 있다는 걸 알게 됐다.

그곳이 가연관악산부인과였다.

불안한 마음으로 집에 가서 기다리는 것보다는 다른 병원에서도 한번 확인해보자는 생각이 들었다.

그래서 그대로 가연관악산부인과로 향했다.

가연관악산부인과 첫 방문

당일 갑자기 찾아간 거라 미리 예약해둔 상태는 아니었다.

그래서 바로 진료가 가능한 선생님으로 안내를 받았고, 김종오 선생님께 초진을 받게 됐다.

다시 초음파를 확인하고 설명을 들었다.

마미톡 임신 다이어리에서 확인 가능한 5주차 진료 기록

그때 들은 이야기는

현재 임신 5주차 정도이고, 출산예정일은 10월 9일 정도로 보인다는 것이었다.

그리고 내가 가장 걱정했던 심장소리에 대해서도 설명해주셨다.

현재 주차에서는 아직 심장소리를 확인하지 못할 수 있고, 다음 주 정도가 되면 확인할 수도 있다고 했다.

첫 병원에서 걱정을 한가득 안고 왔던 터라 그 말을 듣고 나서야 조금 마음이 놓였다.

물론 출산예정일은 초음파를 보면서 이후에 바뀔 수도 있다고 했다.

그때까지만 해도 10월이라는 날짜가 너무 멀게 느껴졌다.

그리고 처음 받은 임신확인서

이날 처음으로 임신확인서도 받았다.

종이 한 장이었지만 묘한 기분이었다.

임테기 두 줄을 봤을 때와는 또 달랐다.

이제 정말 공식적으로

“내가 임신했구나.”

하는 느낌이 들었다.

마침 남편과 나 둘 다 연차를 쓴 날이기도 했다.

그리고 보건소는 평일에 가야 하니,

“오늘 그냥 할 수 있는 건 다 해버리자.”

하고 바로 보건소까지 가기로 했다.

바로 보건소에서 임산부등록

임신확인서를 들고 보건소에 가서 임산부등록을 했다.

여기서 임산부 뱃지도 받고,

엽산과 철분제도 받았다.

임신 초기검사도 함께 진행했다.

얼마 전까지만 해도 제주도에서 성산일출봉을 올라가고,

감기인 줄 알고 약을 먹고,

임테기 두 줄을 보면서 놀라고 있었는데,

어느새 보건소에서 임산부 뱃지를 받고 있었다.

하루 사이에 갑자기

“나 진짜 임산부구나.”

하는 현실감이 확 생겼던 것 같다.

특히 임산부 뱃지를 받아 들고 있으니 이상하게 더 실감이 났다.

다음 진료를 예약하려는데 담당의를 선택해야 했다

초진을 보고 다음 주에 내원하라고 하셨다.

그래서 병원 앱으로 예약을 하려고 했는데 담당의를 선택해야 했다.

그러자 다시 시작된 남편의 폭풍검색.

이번에는

“가연관악산부인과에서 어느 선생님께 진료를 받아야 하는가.”

였다.

각 선생님 약력도 찾아보고,

후기도 찾아보고,

임신·출산 관련 커뮤니티 글도 찾아봤다.

그러다가 신인환 선생님을 선택했다.

약력도 인상적이었고,

특히 초음파를 정말 잘 보신다는 후기가 많았던 게 결정적이었다.

그래서 2월 15일 토요일로 예약을 잡았다.

2월 15일, 임신 6주 3일

그리고 기다리던 다음 진료.

2월 15일 토요일에 다시 병원에 갔다.

그때는 6주 3일차였다.

다시 초음파를 봤다.

그리고 드디어.

아기 심장소리를 들었다.

정말 신기했다.

며칠 전까지만 해도 아기집이 검은 점처럼 보이는 게 전부였는데,

콩처럼 보이는 태아가 보이고, 그 안에서 심장이 뛰고 있었다.

심장소리로 미리 알아보는 태아의 성별이라는 유튜브 영상들을 봤던 터라

처음 들었을 때는

“이게 말발굽 소리도 아니고, 기차 소리도 아닌 것 같은데”

라고 생각을 했고, 신기하기는 엄청 신기했던 것 같다.

무엇보다 첫 병원에서 심장소리가 들리지 않는다는 말을 듣고 걱정을 많이 했던 만큼,

정상적으로 잘 뛰고 있다는 걸 직접 확인하니 안도감이 컸다.

출산예정일은 10월 8일로 하루 당겨졌다

이날 다시 확인한 출산예정일은 10월 8일이었다.

첫 진료에서는 10월 9일이라고 들었기 때문에 하루 차이가 생겼다.

문제는 이미 전 주에 보건소에서 임산부등록을 하면서 출산예정일이 10월 9일로 되어 있던 상태였다는 것.

그래서 또 걱정이 됐다.

“보건소에 다시 가서 예정일을 수정해야 하나?”

선생님께 물어봤다.

하루 정도 차이는 크게 문제 될 것이 없고,

보험이나 회사에 제출해야 할 서류 등이 있다면 현재 기준으로 변경해서 신청할 수 있을 경우 변경하면 되고,

굳이 바꿀 필요가 없는 경우에는 그대로 두어도 된다는 취지로 설명해주셨다.

결과적으로 나중에도 별문제는 없었다.

임신 초반에는 이런 사소한 날짜 하나도 왜 그렇게 신경이 쓰였는지 모르겠다.

첫 심장소리를 듣고 나서야 조금 마음이 놓였다

임신테스트기에서 두 줄을 본 뒤부터 계속 걱정의 연속이었다.

감기약 먹은 것도 걱정,

엽산을 늦게 챙긴 것도 걱정,

첫 산부인과에서 심장소리가 안 들린다고 한 것도 걱정.

그런데 6주 3일,

직접 아기의 심장소리를 듣고 나니 그제야 아주 조금 마음이 놓였다.

물론 이걸로 내 걱정이 끝난 것은 아니었다.

지금 와서 생각하면 임신 내내 새로운 걱정거리가 계속 생겼다.

그래도 이날만큼은

“아기가 잘 있구나.”

라는 걸 처음으로 확실하게 느낀 날이었다.

그리고 2주 뒤에는 산전검사

진료를 마치면서 2주 뒤에는 산전검사를 할 예정이니 다시 내원하라는 이야기를 들었다.

그렇게 다음 진료 예약을 잡았다.

이때까지만 해도 몸은 2주 전보다는 그래도 버틸 만했다.

그런데 몇 주 지나지 않아 상황이 완전히 달라졌다.

8주쯤부터 입덧이 시작됐다.

속은 먹어도 불편하고 안 먹어도 불편했고,

회사에서는 임신 사실을 제대로 알리지 않은 상태로 평소처럼 일해야 했다.

결국 나는 생각보다 빨리 회사에 임신 사실을 알리고, 임신 조기퇴근을 신청하게 됐다.

다음 기록은 임신 7~13주.

내 임신 기간을 통틀어 가장 힘들었던 임신 초기와 회사생활 이야기를 남겨보려고 한다.

임신 극초기 1~4주 기록, 임신인 줄도 모르고 제주도 여행에 감기약까지

FreeBear — Mon, 27 Jul 2026 21:13:39 +0900

https://blog.naver.com/ahddl38/224357505440

1년이 한참 넘어서야 작성하는 걱정 많았던 나의 임신 기록

임테기 두 줄부터 유도분만 예약까지, 걱정 많았던 나의 임신 기록 미루고 미루다가 이제야 임신 기록을 남...

blog.naver.com

https://blog.naver.com/ahddl38/224358593345

임신 초기·중기·후기, 직접 겪어보니 가장 힘들었던 시기는

직접 겪어보니 가장 힘들었던 시기는 따로 있었다 임신을 하기 전에는 막연히 배가 많이 나오는 임신 후기...

blog.naver.com

나의 네이버 블로그에서 전체적인 임신 기록을 남겼었는데, 방치한지 오래인 네이버 블로그에 작성하는 것보다는 이 내 티스토리 남기는 게 나을 것 같다는 판단하에, 또 임신 기록을 보다 보니 빠진 이야기도 많고 그때그때의 감정들이 새록새록 기억이 나기 시작해서 조금 더 자세하게 남기기 위해 여기서 작성을 이어나가려고 한다.

그 시작은 임신 극초기인 1주~4주.

사실 이 시기의 나는 내가 임신했다는 사실조차 모르고 있었다.
그렇다고 임신이 전혀 예상 밖의 일은 아니었다.

2024년 말, 우리 이제 피임하지 말자

2024년 말쯤 남편과 이런 이야기를 했었다.

이제는 언제 청약에 당첨되어서 집을 구할지 모를 일 때문에 결혼과 임출육을 미루는 일을 그만하고, 아기가 생기면 생기는 대로 둘이 잘 꾸리고 살아보자고.

정확히 몇 월부터 임신 준비를 시작하고, 몇 월까지 꼭 임신을 해야 한다는 식의 계획은 아니었다.

그냥 둘이 마음을 조금 내려놓은 느낌에 가까웠다.

아기가 찾아오면 반갑게 맞이하자.

그 정도였다.

그래서 임신 자체에 대한 거부감이나 당황스러움은 없었다.

오히려 마음 한편에는 언젠가 우리에게도 아기가 오겠지 하는 생각이 자연스럽게 자리 잡고 있었다.

다만 그게 이렇게 빨리일 거라고는 생각하지 못했다.

새해와 생일을 맞아 떠난 제주도

2025년 1월.

새해이기도 했고 내 생일도 있어서 남편과 제주도로 여행을 갔다.

그때까지만 해도 임신했다는 사실은 전혀 모르고 있었다.

그냥 둘이 보내는 평범한 제주도 여행이라고 생각했다.

저녁을 먹고 여기저기 돌아다니다가 카페에 들어갔는데, 카페 한쪽에서 소품과 인형 같은 것도 함께 팔고 있었다.

그러다 눈에 들어온 인형이 하나 있었다.

머리 위에 감귤을 얹고 있는 카피바라 인형이었다.

생긴 것도 귀여웠는데 발바닥 아래에 줄이 하나 달려 있었다.

그 줄을 잡아당기면 꼬리가 빙글빙글 돌아가는 인형이었다.

괜히 귀여워서 한참을 보고 있었는데 결국 하나 샀다.

미래의 우리 아기라고 생각하고 같이 여행하자

그 인형을 사면서 남편과 장난처럼 이런 이야기를 했다.

“얘를 미래의 우리 아기라고 생각하고 데리고 다니면서 여행하자.”

지금 생각하면 참 신기하다.

당시에는 내가 이미 임신했을 가능성은 전혀 생각하지 못했다.

그냥 언젠가 찾아올 우리 아기를 생각하면서 한 말이었다.

그렇게 감귤을 머리에 올린 카피바라 인형이 제주도 여행의 작은 동행이 됐다.

숙소에 들어가니 창문 너머로 성산일출봉이 보였다.

그래서 창가에 카피바라를 올려두고 성산일출봉이 같이 보이게 사진도 찍었다.

그때는 그냥 귀여워서 찍었던 사진이었다.

그런데 지금 다시 보면 기분이 묘하다.

미래의 우리 아기라며 데리고 다녔는데,

어쩌면 그때 이미 진짜 우리 아기도 함께 제주도에 있었던 셈이니까.

지금은 거실 키즈 수납장 위에 잘 지내고 있는 중!

그리고 그날, 성산일출봉 정상까지

다음에는 성산일출봉에 올라갔다.

무료로 갈 수 있는데까지만 가려고 하였지만, 남편이 매표소를 보자마자 후다닥 뛰어 가서는 입장권을 사버렸고, 이렇게 왔으니 한 번은 정상까지 가봐야 하지 않겠냐며 구매한 입장권을 보여주었기에 정말 열심히 올라갔다.

생각보다 꽤 힘들었다.

중간중간 숨도 차고,

'내가 이렇게 체력이 안 좋았나?'

싶기도 했다.

그래도 여기까지 왔는데 정상은 찍고 가야지 하는 마음으로 결국 끝까지 올라갔다. 오르다 보니 새삼 삶도 등산과 같지 하면서 깨닫는 것도 있었다.

정상에서 사진도 찍고 나름 뿌듯하게 내려왔다.

지금 생각하면 임신 극초기에 아무것도 모른 채 성산일출봉 정상까지 다녀온 셈이다.

그런데 그날 숙소에 들어오고 나서 몸이 이상했다

사실 성산일출봉을 오르기 전부터 컨디션이 아주 좋았던 건 아니었다.

그런데 정상까지 다녀오고 숙소로 돌아온 뒤에는 몸 상태가 더 이상하게 느껴졌다.

몸이 으슬으슬했고 기운이 없었다.

딱 감기에 걸렸을 때 같은 느낌이었다.

1월이었고,

제주도 바람도 많이 맞았고,

성산일출봉까지 다녀왔으니,

나는 너무 자연스럽게 결론을 내렸다.

감기 걸렸나 보다.

그때까지만 해도 임신이라고는 전혀 생각하지 못했다.

임신인 줄 모르고 감기약을 먹었다

그래서 평소처럼 감기약을 먹었다.

아무 고민도 없었다.

내가 임신했을 가능성을 전혀 생각하지 못했으니까.

그런데 이상하게 잘 낫지 않았다.

약을 먹으면 조금씩 괜찮아질 줄 알았는데 컨디션은 계속 좋지 않았다.

'감기 걸리기 직전에는 약 한 번만 먹으면 금방 낫던게 왜 안 낫지?'

처음에는 그 정도로 생각했다. 타이레놀만 한 번 더 먹었던 것 같다.

그러다 어느 날 문득 날짜를 생각해봤다.

생리를 할 때가 지났는데 생리를 하지 않고 있었다.

그제야 처음으로

'설마?'

하는 생각이 들었다.

임테기에서 두 줄을 본 순간

혹시나 하는 마음으로 임신테스트기를 해봤다.

결과는 애매하였다.

얼리 임신테스트기도 남편이 사놓았어서 다음날 이걸로 해봤는데, 정확히 두 줄이었다.

와..!

그 순간 정말 여러 감정이 한꺼번에 들었다.

기쁘기도 했고,

신기하기도 했고,

정말 이렇게 빨리 찾아왔다고?

싶기도 했다.

2024년 말에 남편과

'아기가 생기면 생기는 대로 잘 살아보자.'

라고 이야기했던 게 불과 한두달 전이었다.

제주도에서 카피바라 인형을 사면서

'미래의 우리 아기라고 생각하고 데리고 다니자.'

라고 했던 것도 며칠 전이었다.

그런데 정말 아기가 와 있었다.

그것도 어쩌면 그 여행을 함께하고 있었다.

그런데 기쁨과 동시에 떠오른 생각

문제는 기쁜 감정이 오래 가지 못했다는 것이다.

거의 동시에 머릿속에 하나가 떠올랐다.

“나 감기약 먹었는데.”

성산일출봉을 오른 것도 생각났다.

몸이 안 좋은데 여행을 다녔던 것도 생각났다.

그 순간부터 걱정이 시작됐다.

임신인 줄 알았다면 당연히 약을 먹기 전에 한 번 더 확인했을 텐데, 이미 먹은 뒤였다.

무슨 약을 얼마나 먹었는지 생각해보고,

임신 극초기에 감기약을 먹은 사람들의 글을 찾아보기 시작했다.

괜찮았다는 글을 보면 잠깐 마음이 놓였다가도,

다른 이야기를 보면 다시 불안해졌다.

돌이켜보면 내 임신 기간 내내 반복했던 패턴이 이때 시작됐다.

걱정 → 검색 → 잠깐 안심 → 다시 걱정.

엽산도 뒤늦게 생각났다

감기약 다음으로 마음에 걸린 건 엽산이었다.

임신을 준비한다면 미리 엽산을 챙겨 먹는 게 좋다는 이야기는 알고 있었다.

그런데 우리는 본격적으로 임신 계획표를 세우고 준비했던 것은 아니었다.

'생기면 생기는 대로 잘 키워보자.'

정도로 시작했기 때문에 나 역시 임신 전에 꼬박꼬박 엽산을 챙겨 먹고 있지는 않았다. 챙겨 먹고 있던 영양제가 하나 있었지만 꾸준히 먹지는 않았고, 엽산이 들어있던 거긴 하지만 그 양은 임산부용은 아니었다.

임신을 확인하고 나서야 챙겨 먹고 있던 영양제를 중단하고, 부랴부랴 약국에 가서 임산부용 엽산을 사서 챙겨 먹기 시작했다.

그러니 또 걱정이 됐다.

감기약도 먹었고,

엽산도 늦게 시작했고.

혹시 내가 모르고 했던 행동 때문에 아기에게 무슨 일이 생기는 건 아닐까.

이미 지나간 일인데도 마음 한편에 계속 남아 있었다.

지금 다시 제주도 사진을 보면

이 글을 쓰면서 당시 제주도 사진을 다시 보면 제일 먼저 눈에 들어오는 건 카피바라다.

숙소 창가에 앉아 있고,

그 뒤로 성산일출봉이 보이던 사진.

그때는 그냥

'우리 미래의 아기.'

라고 장난처럼 이야기하며 찍었던 사진이었다.

그런데 나중에 임신 사실을 알고 나니 그 사진의 의미가 완전히 달라졌다.

우리는 둘이 여행하고 있다고 생각했는데,

어쩌면 그때부터 이미 셋이었던 건 아닐까.

그래서인지 그 카피바라는 지금 봐도 조금 특별하다.

아, 갤럭시 S25를 구매하면서 잘못된 선택으로 이때의 카톡 기록들이 날아간 게 너무 아쉽다. 남편이랑 언니랑 대화하면서 이때의 감정이나 임신 상태, 태몽 등 얘기들이 다 자세하게 적혀져 있었는데.

그렇게 시작된 나의 임신

2024년 말,

아기가 생기면 생기는 대로 잘 살아보자고 했던 우리.

2025년 1월,

미래의 우리 아기라며 카피바라 인형을 하나 사고,

그 인형과 성산일출봉을 바라보고,

나는 정작 임신한 줄도 모르고 성산일출봉 정상까지 다녀왔다.

그리고 감기인 줄 알고 약을 먹고 나서야 임신테스트기의 두 줄을 확인했다.

지금 생각하면 꽤 우리다운 시작이었다.

ChatGPT·Codex GPT‑5.4 vs GPT‑5.5 vs GPT‑5.6 비교 정리

FreeBear — Sat, 25 Jul 2026 14:47:42 +0900

먼저 보는 핵심 결론

GPT‑5.4: 비용과 성능의 균형이 좋은 안정적인 모델
GPT‑5.5: 긴 작업을 끝까지 수행하는 능력과 도구 사용이 크게 강화된 모델
GPT‑5.5 Instant: 현재 ChatGPT에서 일상적인 질문을 처리하는 기본 고속 모델
GPT‑5.6 Sol: 가장 어려운 추론·코딩·장기 에이전트 작업에 적합한 최신 플래그십
GPT‑5.6 Terra: GPT‑5.5급 성능을 더 낮은 비용으로 제공하는 균형형
GPT‑5.6 Luna: 속도와 사용량 효율을 우선한 경량형

중요한 점은 버전 숫자가 높다고 모든 작업에서 무조건 더 좋은 선택은 아니라는 것이다. 단순 질의나 반복 작업에 GPT‑5.6 Sol을 사용하면 필요 이상으로 느리거나 비쌀 수 있고, 대규모 리팩터링에 Luna를 사용하면 여러 차례 수정이 필요할 수 있다.

GPT‑5.4 vs GPT‑5.5 vs GPT‑5.6 ChatGPT·Codex 모델 비교 정리

1. 세대별 핵심 변화

세대	핵심 방향	대표 특징	가장 적합한 작업
GPT‑5.4	추론과 코딩 능력 통합	GPT‑5.3‑Codex 계열의 코딩 능력을 범용 모델에 통합	일반 코딩, 문서 작성, 비용을 고려한 전문 작업
GPT‑5.5	자율성과 지속성 강화	모호한 목표를 해석하고 도구를 사용해 끝까지 수행	복합 업무, 디버깅, 대규모 코드베이스, 연구
GPT‑5.6 Sol	최고 성능과 장기 에이전트 작업	max, ultra, 멀티 에이전트, 높은 토큰 효율	매우 어려운 설계·코딩·연구·보안 작업
GPT‑5.6 Terra	성능과 비용의 균형	GPT‑5.5에 경쟁력 있는 성능을 더 저렴하게 제공	대부분의 실무 개발, 일상적인 Codex 작업
GPT‑5.6 Luna	속도와 처리량 중심	가장 빠르고 경제적인 GPT‑5.6 등급	반복 수정, 단순 구현, 서브 에이전트, 대량 처리

GPT‑5.4는 범용 추론 모델에 당시 최고 수준이던 GPT‑5.3‑Codex의 코딩 능력을 통합한 첫 메인라인 모델이었다. GPT‑5.5에서는 단순히 답을 잘 생성하는 수준을 넘어, 계획하고 도구를 사용하며 결과를 검증하고 작업을 계속하는 능력이 강화됐다. GPT‑5.6은 이를 다시 세분화해 하나의 세대 안에서 최고 성능, 균형, 속도 중심 모델을 선택하도록 구조를 바꿨다. GPT‑5.4 발표, GPT‑5.5 발표, GPT‑5.6 발표

2. ChatGPT 사용 관점

GPT‑5.4 Thinking

GPT‑5.4 Thinking은 코딩뿐 아니라 조사, 문서, 스프레드시트 및 프레젠테이션 같은 전문 작업에 초점을 맞춘 추론 모델이다.

장점

질문을 오래 생각해야 하는 분석 작업에 적합
GPT‑5.3‑Codex의 코딩 능력이 통합됨
긴 추론 중에도 문맥을 비교적 안정적으로 유지
작업을 시작하기 전에 계획을 보여주고 사용자가 중간에 방향을 조정할 수 있음
GPT‑5.5나 GPT‑5.6 Sol보다 API 단가가 낮음

단점

GPT‑5.5보다 모호한 요구사항을 해석하거나 긴 작업을 지속하는 능력이 약함
복잡한 도구 호출과 컴퓨터 사용에서는 후속 모델보다 성능이 낮음
최신 세대와 비교하면 작업을 너무 일찍 마치거나 추가 지시가 필요한 경우가 상대적으로 많을 수 있음

GPT‑5.5 Instant·Thinking·Pro

ChatGPT에서는 GPT‑5.5가 하나의 사용 방식으로만 제공되는 것이 아니다.

Instant: 빠른 일상 응답
Thinking: 복잡한 문제를 위한 추론
Pro: 높은 정확도가 필요한 어려운 작업

GPT‑5.5의 가장 큰 변화는 단순 지능보다 작업 수행 능력이다. 사용자가 모든 절차를 세세하게 지정하지 않아도 목표를 해석하고, 필요한 도구를 선택하고, 결과를 확인하며 작업을 이어가는 능력이 강화됐다.

장점

복잡하고 정리되지 않은 요청을 더 잘 이해
GPT‑5.4와 비슷한 토큰 생성 속도에서 더 높은 성능 제공
조사, 정보 종합, 데이터 분석, 문서 작업에 강함
더 적은 재시도와 수정으로 결과를 완성하는 경향
GPT‑5.5 Instant는 빠른 일상 대화에 적합
GPT‑5.5 Pro는 비즈니스, 법률, 교육, 데이터 과학 등 고난도 문서 작업에 강함

단점

GPT‑5.4보다 높은 비용 구조
간단한 질문에는 Thinking이나 Pro가 과도할 수 있음
최신 최고 성능은 GPT‑5.6 Sol로 넘어감
오래 작업하는 성향 때문에 요청 범위가 불명확하면 필요 이상으로 일을 확장할 가능성이 있음

GPT‑5.6 Sol

GPT‑5.6 Sol은 GPT‑5.6 세대의 플래그십이다. ChatGPT에서는 일반적으로 Sol이라는 API식 이름보다 Medium·High·Extra High·Pro 같은 추론 단계로 노출된다.

ChatGPT 선택 항목	실제 모델
Instant	GPT‑5.5 Instant
Medium	GPT‑5.6 Sol
High	GPT‑5.6 Sol
Extra High	GPT‑5.6 Sol
Pro	GPT‑5.6 Sol Pro

장점

복잡한 다단계 추론과 장시간 작업에 가장 강함
코드, 연구, 과학, 컴퓨터 사용, 디자인 작업이 전반적으로 향상
긴 작업에서 목표를 잃지 않는 지속성이 강화됨
출력 품질뿐 아니라 토큰 사용 효율도 개선
프런트엔드 레이아웃, 시각적 계층, 디자인 판단 능력이 향상
Pro는 특히 어려운 문제와 장기 워크플로에 적합

단점

간단한 질문에서는 Instant보다 느릴 수 있음
최고 추론 단계는 사용량을 많이 소비할 수 있음
강한 사이버 안전장치 때문에 정상적인 보안 연구 요청도 일부 차단될 가능성이 있음
Free·Go 사용자는 일반 ChatGPT 대화에서 Sol을 사용할 수 없음
모든 사용자가 Extra High나 Pro를 사용할 수 있는 것은 아님

3. Codex 개발 관점 (+ WPF 개발 관점)

GPT‑5.4: 안정적인 기본 실무형

GPT‑5.4는 기존 Codex 전용 모델의 코딩 능력을 범용 추론 모델에 통합했다. 구현, 디버깅, 테스트, 도구 사용을 하나의 모델로 처리할 수 있다는 점이 핵심이다.

강점

명확한 요구사항의 기능 구현
중간 규모 리팩터링
코드 리뷰와 버그 수정
WPF 화면, ViewModel, 서비스 계층 등 구조화된 코드 생성
최신 상위 모델보다 낮은 비용
최대 약 1.05M 컨텍스트 지원

약점

대규모 저장소 전체를 이해해야 하는 작업에서는 GPT‑5.5보다 불리
모호한 장애의 원인을 자율적으로 추적하는 능력이 후속 모델보다 낮음
복수 도구를 오랫동안 조율하는 터미널 작업에서 격차가 큼

적합한 개발 작업

단일 기능 추가
정해진 패턴에 따른 CRUD 구현
ViewModel 분리
테스트 코드 생성
작은 범위의 버그 수정
비용이 중요한 반복 작업

GPT‑5.5: 에이전트형 소프트웨어 엔지니어링

GPT‑5.5는 GPT‑5.4보다 단순 코드 생성 성능의 상승폭보다도 시스템 전체를 파악하고 작업을 끝까지 진행하는 능력이 크게 강화된 모델이다.

강점

큰 코드베이스에서 관련 변경 범위를 더 잘 파악
모호한 오류의 원인을 추적하는 능력 향상
구현 후 테스트와 검증을 스스로 이어갈 가능성이 높음
장시간 작업에서 중간에 멈추지 않는 지속성
브랜치 병합, 대규모 리팩터링, 여러 파일에 걸친 수정에 강함
GPT‑5.4보다 적은 토큰으로 더 좋은 결과를 내는 경향
Codex Fast 모드에서 약 1.5배 빠른 생성 옵션 제공

약점

GPT‑5.4보다 높은 사용 비용
작은 수정에는 성능이 과할 수 있음
요청 경계가 불명확하면 주변 코드까지 광범위하게 변경할 가능성이 있음
최신 GPT‑5.6 Sol과 비교하면 장기 추론, 도구 조율, 토큰 효율에서 밀림

적합한 개발 작업

대규모 리팩터링
재현하기 어려운 오류 추적
솔루션 전체 구조 분석
여러 프로젝트에 걸친 인터페이스 변경
테스트 작성부터 실행·수정까지 포함한 작업
기존 시스템의 아키텍처 개선

OpenAI가 공개한 동일 조건 평가에서 GPT‑5.5는 GPT‑5.4보다 Terminal‑Bench 2.0, SWE‑Bench Pro 및 Expert‑SWE 모두 높은 결과를 보였다. 특히 터미널 기반 장기 작업의 차이가 컸다. GPT‑5.5 코딩 평가

GPT‑5.6 Sol: 최고 난도의 개발 작업

GPT‑5.6 Sol은 코드 한 조각을 잘 생성하는 모델이라기보다, 복잡한 개발 프로젝트를 긴 시간 동안 수행하는 에이전트에 가깝다.

강점

GPT‑5.5보다 높은 코딩 및 터미널 작업 성능
복잡한 문제를 장기간 붙잡고 해결하는 지속성
코드 리뷰에서 더 적은 토큰과 낮은 지연시간으로 높은 성능을 보인 사례
어려운 저장소 분석, 설계 변경, 보안 분석에 강함
max 추론 단계 지원
ultra에서는 여러 하위 에이전트를 이용한 병렬 작업 가능
긴 컨텍스트에서 코드와 문서를 함께 분석하기 적합
프런트엔드 디자인과 시각적 완성도 향상

약점

쉬운 작업에서는 비용과 시간이 낭비될 수 있음
보안 관련 코드를 다룰 때 안전장치가 작업 흐름을 방해할 가능성
자율성이 높은 만큼 수정 범위를 명시적으로 제한할 필요가 있음
ultra는 단순히 “더 오래 생각하는 모드”가 아니라 멀티 에이전트 방식이므로 결과와 비용 특성이 다름

적합한 개발 작업

대형 솔루션 리팩터링
장시간 실행되는 에이전트 작업
복잡한 빌드·테스트 실패 분석
보안 취약점 검토와 방어 코드 작성
아키텍처 변경 영향 분석
고품질 프런트엔드 구현
여러 독립 작업을 병렬로 처리할 수 있는 프로젝트

GPT‑5.6 Terra: 대부분의 개발자에게 현실적인 기본값

Terra는 GPT‑5.6에서 가장 주목할 모델 중 하나다. OpenAI는 Terra를 GPT‑5.5에 경쟁력 있는 성능을 절반 수준의 가격으로 제공하는 등급으로 설명한다.

장점

GPT‑5.5에 가까운 성능
Sol보다 낮은 비용
대부분의 일상적인 Codex 개발 작업에 충분
Sol보다 빠르고 Luna보다 높은 복잡도 대응
Free·Go 사용자의 Codex 기본 GPT‑5.6 모델

단점

최고 난도 추론과 장기 작업에서는 Sol보다 낮은 성능
복잡한 시스템 설계나 매우 어려운 디버깅에서는 재시도가 필요할 수 있음
단순 반복 작업에는 Luna가 더 경제적일 수 있음

GPT‑5.6 Luna: 빠른 반복 작업용

Luna는 GPT‑5.6 계열 중 가장 빠르고 저렴한 등급이다.

장점

빠른 응답
낮은 비용
대량 작업과 반복적인 수정에 적합
서브 에이전트 역할로 활용하기 좋음
간단한 코드 변환과 정형 작업에 효율적

단점

복잡한 설계 판단은 Sol·Terra보다 약함
대형 저장소의 변경 영향을 놓칠 가능성이 상대적으로 높음
애매한 요구사항을 스스로 정리하는 능력이 낮을 수 있음
생성된 코드를 더 철저히 검토해야 함

4. 공개 평가 결과

GPT‑5.4와 GPT‑5.5 비교

평가	GPT‑5.4	GPT‑5.5	평가 대상
Terminal‑Bench 2.0	75.1%	82.7%	터미널 기반 장기 개발 작업
SWE‑Bench Pro	57.7%	58.6%	실제 GitHub 이슈 해결
Expert‑SWE	68.5%	73.1%	장시간 전문 개발 작업
GDPval	83.0%	84.9%	전문 지식 업무
OSWorld‑Verified	75.0%	78.7%	컴퓨터 환경 조작
BrowseComp	82.7%	84.4%	검색 및 정보 탐색

GPT‑5.5는 모든 항목에서 GPT‑5.4를 앞섰지만, 특히 Terminal‑Bench와 Expert‑SWE처럼 오랫동안 계획하고 도구를 사용해야 하는 작업에서 차이가 크다.

GPT‑5.6 세대 코딩 평가

평가	GPT‑5.5	5.6 Luna	5.6 Terra	5.6 Sol
Coding Agent Index	76.4	74.6	77.4	80.0
SWE‑Bench Pro	59.4%	62.7%	63.4%	64.6%
DeepSWE 1.1	67.0%	67.2%	69.6%	72.7%
Terminal‑Bench 2.1	85.6%	84.7%	87.4%	88.8%
Terminal‑Bench 2.1 Ultra	—	—	—	91.9%

이 표에서 눈에 띄는 점은 다음과 같다.

Terra가 여러 평가에서 GPT‑5.5보다 높다.
Luna도 일부 코드 수정 평가에서 GPT‑5.5와 비슷하거나 높다.
Sol은 전반적으로 가장 높은 성능을 보인다.
Sol Ultra는 장기 터미널 작업에서 가장 높은 결과를 기록했다.

단, GPT‑5.5 발표 당시와 GPT‑5.6 발표 자료의 SWE‑Bench 수치는 각각 58.6%, 59.4%로 다르다. 이는 평가 시점이나 실행 설정이 다르기 때문일 수 있으므로, 서로 다른 발표 자료의 숫자를 완전히 동일한 실험처럼 비교하면 안 된다. 위 GPT‑5.6 표는 GPT‑5.6 발표 자료 안에서 함께 측정된 결과만 사용했다. GPT‑5.6 평가표

5. 속도·품질·비용 관점의 상대 비교

모델	품질	속도	비용 효율	장기 작업	추천 위치
GPT‑5.4	높음	보통~빠름	매우 좋음	보통	경제적인 전문 작업
GPT‑5.5 Instant	보통~높음	매우 빠름	좋음	낮음	일반 ChatGPT 기본
GPT‑5.5	매우 높음	보통	좋음	매우 좋음	복합 업무와 개발
GPT‑5.6 Luna	높음	가장 빠름	매우 좋음	보통	반복·대량 작업
GPT‑5.6 Terra	매우 높음	빠름	매우 좋음	매우 좋음	Codex 실무 기본값
GPT‑5.6 Sol	최고	상대적으로 느림	고난도 작업에서 좋음	최고	어려운 프로젝트
GPT‑5.6 Sol Pro/Ultra	최고	가장 느릴 수 있음	작업에 따라 다름	최고	실패 비용이 큰 작업

이 표의 속도와 품질 평가는 공식적인 포지셔닝과 공개 평가를 바탕으로 한 상대적 해석이다. 실제 체감 속도는 추론 단계, 입력 크기, 도구 호출 횟수 및 서버 상태에 따라 달라진다.

6. 어떤 모델을 선택해야 할까?

ChatGPT 추천

작업	추천
간단한 질문, 번역, 문장 다듬기	GPT‑5.5 Instant
기술 설명, 일반 분석	GPT‑5.6 Sol Medium
복잡한 보고서, 비교 분석	GPT‑5.6 Sol High
중요한 의사결정, 어려운 연구	GPT‑5.6 Sol Extra High 또는 Pro
비용을 고려한 전문 작업	사용 가능하다면 GPT‑5.4
빠른 일상 응답	GPT‑5.5 Instant

Codex 추천

개발 작업	추천
간단한 클래스·DTO·테스트 초안	GPT‑5.6 Luna
일반적인 기능 구현	GPT‑5.6 Terra
WPF 화면과 MVVM 기능 개발	GPT‑5.6 Terra
복잡한 버그 분석	GPT‑5.6 Sol High
솔루션 전체 리팩터링	GPT‑5.6 Sol High 또는 Max
여러 독립 작업의 병렬 처리	GPT‑5.6 Sol Ultra
비용을 낮춘 안정적인 개발	GPT‑5.4
기존 장기 작업을 안정적으로 수행	GPT‑5.5 또는 GPT‑5.6 Terra
보안 코드와 취약점 검토	GPT‑5.6 Sol, 단 안전 제한 고려

7. WPF 개발자를 위한 현실적인 선택

C# WPF 프로젝트에서는 다음과 같이 나누는 것이 효율적이다.

GPT‑5.6 Luna

모델·DTO 생성
단순 Converter 작성
반복되는 Command 작성
XML 주석과 테스트 초안
코드 형식 통일

GPT‑5.6 Terra

MVVM 기능 구현
ViewModel과 Service 분리
DI 구성
비동기 명령과 예외 처리
Validation 구조
일반적인 리팩터링
단위 테스트 작성 및 수정

GPT‑5.6 Sol

대규모 ViewModel 분해
복잡한 상태 동기화 문제
UI 스레드와 비동기 교착 분석
메모리 누수와 이벤트 구독 문제
여러 프로젝트에 걸친 아키텍처 변경
기존 동작을 보존하는 대규모 리팩터링
빌드부터 테스트까지 포함한 장기 작업

실무적으로는 Terra를 기본 모델로 사용하고, 해결이 어렵거나 변경 영향이 큰 작업만 Sol로 올리는 방식이 가장 합리적이다. 단순 작업은 Luna로 낮추면 속도와 사용량을 절약할 수 있다.

8. 주의사항

GPT‑5.6은 단일 모델이 아니다.
Sol·Terra·Luna라는 세 가지 지속적인 성능 등급으로 나뉜다.
ChatGPT의 Instant는 GPT‑5.6이 아니다.
현재 Instant는 GPT‑5.5 Instant이며, Medium 이상부터 GPT‑5.6 Sol을 사용한다.
ChatGPT와 Codex의 모델 목록은 다르다.
Terra와 Luna는 일반 ChatGPT 대화에서는 선택할 수 없지만, ChatGPT Work·Codex·API에서는 제공된다.
벤치마크 점수는 실제 프로젝트 성능과 같지 않다.
저장소 구조, 프롬프트, 테스트 환경, 도구 권한에 따라 결과가 달라진다.
높은 추론 단계가 항상 최선은 아니다.
단순 작업에서는 응답 시간과 사용량만 증가할 수 있다.
모델보다 작업 지시가 여전히 중요하다.
수정 범위, 완료 조건, 테스트 명령, 금지 사항을 명시해야 자율성이 높은 모델의 과도한 수정을 방지할 수 있다.

9. 최종 요약

GPT‑5.4에서 GPT‑5.5로의 변화가 “더 똑똑한 모델”에서 “일을 끝까지 수행하는 모델”로의 발전이었다면, GPT‑5.6은 그 능력을 Sol·Terra·Luna라는 세 가지 등급으로 나누어 성능과 비용을 작업에 맞게 선택할 수 있도록 한 세대다.

일반 ChatGPT 사용자는 빠른 일상 대화에 GPT‑5.5 Instant를 사용하고, 복잡한 분석에는 GPT‑5.6 Sol의 Medium 이상을 선택하면 된다. Codex 개발자는 Terra를 기본 모델로 두고, 단순 반복 작업은 Luna, 대규모 리팩터링이나 어려운 디버깅은 Sol로 처리하는 구성이 가장 현실적이다.

결국 GPT‑5.6 시대의 핵심은 “가장 높은 모델을 항상 사용하는 것”이 아니라, 작업 난도에 맞는 등급과 추론 수준을 선택하는 것이다.

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

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 앱을 설치해서 일일이 책을 보며 적었는데, 그걸 스마트폰에서 시간 확인할 때마다 보고, 그냥 쉴 때마다 보고, 스마트폰으로 게임이나 소설보기 전에 보고 또 보았다.

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

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

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

한줄평

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