wnsl2002ok 님의 블로그

질문을 잘 해도 틀릴 수 있다: 포트원 인증 이슈로 본 LLM의 한계

wnsl2002ok — Tue, 21 Apr 2026 20:31:57 +0900

1. 글을 쓰게 된 이유

새 기술을 익힐 때 LLM은 굉장히 편하다.
그래서 사실 프로젝트를 하던 중 시간에 쫓기면 내 스스로 학습을 하지 않고,
학습은 나중으로 미룬 채 일단 LLM으로 개발을 먼저 할 때가 있다.

문서 요약도 빠르고 개발도 빠르다. 쓰지 않을 이유가 없다.
이번 문제는 내가 프론트엔드에서 인증 부분을 맡게 되면서 생기게 된 문제다.
우리는 핀테크 프로젝트를 개발 중이었고, 금융권인 만큼
인증 부분이 중요하다고 판단했다.

포트원 인증을 개발하며 LLM을 이용한 코딩을 시작했다.
웹으로 하는 것은 빠르고 상당히 타당해 보였으며,
무엇보다도 React 기반으로 인증 창을 여는 것은 빌드 방식을 바꿔야 하는데 이것이 여간 오래 걸리는 방식이라서, 간단하고 빠르게 구현하기 위해 인증을 웹에서 하는 식으로 구현했다.

하지만 실제로는 그렇지 않았다.

2. 문제가 없는 줄 알았다.

내가 아이폰 사용자이다 보니
갤럭시는 내 것으로 사용하는 게 아니라 공기계 테스트 폰을 따로 사용했다.

문제는 이때 공기계로 인증을 할 때는 앱을 계속 띄워놓고 인증을 하다 보니, 이때는 문제를 알아채지 못했다.

실제 문제는 안드로이드에서 발생했다.
웹에서 인증을 시작한 뒤 외부 앱으로 이동하고, 다시 복귀하면 인증 진행에 필요한 중간 페이지가 유지되지 않았다.
그 결과 계정 생성과 계좌 생성이 실패했다.

이 때문에 계정 생성이나 계좌 생성이 불가능한 문제가 생겼다...

그래서 내가 이 문제를 해결하기 위해 질문을 했다.

3. 내가 질문을 잘못한 줄 알았다

내 스스로도 처음 질문은 추상적이었다.

LLM이 이를 다르게 해석할 여지가 있을 수 있다고 생각했다.
그래서 상황과 증상을 더 자세히 설명해 다시 질문했다.
하지만 두 번째 질문을 했는데 잘 되지 않았다.

그런데도 LLM은 기존의 대답에서 빙빙 돌았다.

문제를 분석하기보다는 자신이 익숙한 해결 방식으로 밀어붙인 것이다.

4. 여기서 깨달은 점

이 경험으로 알게 된 것은 단순하다.
내가 기술을 알지 못하면 오답을 거를 수 없다.
LLM은 "그럴듯한 정답"은 잘 만들지만, 내가 그 기술에 대해서 잘 알지 못하면 그 답이 진짜인지 아닌지 검증이 불가능하다.

이번 사례에서는 나름 잘 준비를 했다고 생각했지만
결국 잘못된 길로 간 사례다.
React 웹에서도 가능하다고 했으며 해결책도 명확히 제시했다.
문제는 그 답변이 내가 실제로 겪고 있는 현상과 맞물리는지 따지지 않았다.

5. 그렇다면 새 기술에서는 어떻게 쓸까?

이후에 나는 순서를 바꾸었다.

1. 공식 문서를 통해 기술의 제약 조건을 확인 한다.
2. 기술의 한계점이나 현재 프로젝트에서 어떻게 기술을 사용할지 파악한다
3. 그다음으로는 내가 파악한 기술이 맞는지 요약해서 검증한다.
4. 상황 정리 및 해석, 혹은 내가 빠뜨린 것을 체크한다
5. 답을 가져와서 소규모로 내가 생각한 게 맞는지 테스트를 반복하며 개발을 이행한다.

학습 - 질문 - 확인 - 검증
순서로 이어지게 했다.

어느 정도 시간을 쓰더라도
기술에 대해서 이해를 하고 그다음 단계를 진행하는 것이 결국에는 시간을 적게 쓰는 것이라는 것을 알 수 있었다.

6. 결론

LLM은 강력하다.
모르는 기술을 쓸 때 LLM을 정답 생성기처럼 그냥 사용해버리면 그럴듯하지만
결국 좋지 못한 결과물이 나온다고 생각한다.

질문을 잘하는 것도 중요하다.
하지만 자세한 질문을 하더라도 분명 틀릴 가능성은 존재한다.

특히 복잡하고 전문적인 과정으로 들어갈수록 문제이며, 가장 큰 문제는 틀렸을 때의 리스크이다.
잠깐은 빠르지만

결국 느려진다

모르는 기술일때는 LLM을 바로 사용하는 것 보다는 최소한의 기술을 이해한 뒤에
LLM에게 질문을 하는 것이 결국 시간을 아끼는 길이다.

LLM은 정답 생성기가 아니다.
검증 보조 도구이다.

API 응답(Response)에 관하여

wnsl2002ok — Wed, 8 Apr 2026 02:55:30 +0900

1. API response를 처음 보았을 때

웹을 처음 시작하며 프론트 그리고 백엔드로 요청을 서로 주고받을 때는

그냥 json 형태로 필요한 것만 보내면 되겠지라고 생각하던 시절이 있었다

하지만 json을 보낼 때 단순히 당장 필요한 API 데이터만 보내는 것이 아니라

다른 인증, 성공 실패, 실패에 대한 처리 등이 생각 이상으로 중요 함을 알게 되었다.

그리고 그것을 어느 정도 규격화해 자동화 해야 하는 것 까지도

2. API 응답(Response)란?

API 응답은 클라이언트의 요청에 대해 서버가 작업 결과를 담아 돌려주는 데이터 꾸러미입니다

이 꾸리미에는 두 가지의 중요한 정보가 들어있습니다

1. HTTP 상태 코드 : 이 요청이 성공했는지 실패했는지 알려주는 부분

2. 데이터 본문 : 우리가 실제로 화면에 보여줘야 할 진짜 데이터가 있는 부분

3. API 응답의 본질

여기서의 개념을 잡았을 때 이해가 안 되는 부분이 있었습니다.

굳이 성공 실패에 대한 상태 코드를 보내지 않고

어디로 이동할지 모두 서버단에서 조절을 해주는 게 훨씬 편하지 않을까?라는 생각이 강하게 들었습니다.

하지만 이 생각이 이번에 모바일 관련 프로젝트를 하면서 생각이 바뀌게 되었습니다.

일단 첫 번째로 웹을 사용하는 경우에도 유연성이 떨어지기 때문에 상태 값을 넣는 것이 유연성 그리고 독립성 측면에서 유리합니다

로그인 페이지 주소가 /auth/login 에서 /signin으로 바뀌었다고 가정하면

서버가 담당할 경우에는 서버 개발자가 수정하고 다시 재 배포를 해야 한다고 하면

프트 담당이라면 프론트 앤드 코드만 수정하면 됩니다

UI/UX는 사용자의 피드백에 따라서 빈번하게 바뀌지만

데이터의 논리 즉 서버의 영역은 잘 바뀌지 않기 때문에 화면의 변화를 서버로부터 독립시키는 것이 더 효율적인 프로젝트 진행이 될 수 있다고 생각합니다.

이는 곧 결합도를 낮출 수 있게 되어 서버에서 코드 수정 시 발생하는 이상 상황을 줄일 수 있습니다.

마지막 이유는 기기에 따라서 대답이 달라야 하기 때문입니다.

처음에는 웹만 생각했지만 모바일까지 같이 생각했을 때는 선택이 아니라 필수임을 알 수 있었습니다

웹 사이트 : 에러 발생 시 특정 주소로 이동

아이폰 : 주소 개념이 없어서 따로 화면 객체를 띄워줘야 함

갤럭시 : intent 이용해 새로운 화면 실행

워치 : 메시지 띄우기

등 기기별로 화면을 전환하고 처리하는 방식이 다르기 때문에 error 코드를 보내서 기기에 따라서 각각 대응이 가능하도록 해야 한다.

그래서 API에 따른 서버 클라이언트 역할을 정리해보았습니다.

서버의 역할 (상태 전달): 현재 상황이 어떤지(200: 성공, 401: 인증 실패, 404: 없음 등) 명확한 "상태"만 전달
클라이언트의 역할 (행동 결정): 401이면 로그인 화면으로, 404면 에러 페이지로 사용자를 안내

4. 우리 프로젝트의 응답 설계

우리 프로젝트에서는 모든 응답을 status, message, data 3개 필드로 표준화하여 클라이언트와의 통신 효율을 높였습니다.

성공 케이스 (예: 소비 리포트 조회)

성공 시에는 명확한 안내 문구와 함께 필요한 데이터를 담아 보냅니다. AiTransactionController.java에서 처리되는 응답 예시는 다음과 같습니다.

JSON

{
  "status": "SUCCESS",
  "message": "소비 리포트 조회가 완료되었습니다.",
  "data": {
    "yearMonth": "2026-03",
    "totalSpent": 1943800,
    "spendingPersona": "쇼핑족",
    "aiOverallFeedback": "이번 달은 계획 대비 지출이 많은 편입니다."
  }
}

실패 케이스 (전역 예외 처리)

인증 실패나 잘못된 요청 시, GlobalExceptionHandler.java를 통해 일관된 에러 포맷을 제공합니다. 클라이언트는 이 FAIL 신호와 message를 보고 사용자에게 적절한 안내를 띄웁니다.

JSON

{
  "status": "FAIL",
  "message": "인증이 필요합니다.",
  "data": null
}

5. 실패를 대비한 "Fallback" 설계

이번엔 원래 기술의 의도는 아니지만 시연 시 안될 경우를 방지하여 fallback 설계를 이용했습니다.

서버에서 오류가 뜨더라도 fallback 로직을 이용해 저장된 값을 보여주는 형식입니다.

좀 더 다르게 이용한다면 사용자가 서비스를 끊김 없이 이용할 수 있도록 하는 좋은 서비스를 만들 수 있다고 생각합니다.

6. 마치며

API 응답에는 단순히 데이터를 보내기만 하면 되고 error는 애초에 안 나면 되지라는 편리한 생각을 했었는데요

error는 단순히 코드를 잘 짠다고 생기는 것이 아니라

다양한 상황

다양한 문제들이 생길 수 있기 때문에

반드시 필요하며 다양한 기기에 대응을 해야 한다는 점을 알 수 있었습니다.

SDK는 어떤 것 일까?

wnsl2002ok — Wed, 18 Mar 2026 21:14:02 +0900

SDK는 Software Development Kit의 줄임말로, 특정 플랫폼이나 서비스를 개발자가 더 쉽게 사용할 수 있도록 제공되는 개발 도구 모음이다.

이 정도로만 알고 자주 보기만 한 단어였다.
프로젝트를 할 때 쓰면 좀 더 빠르게 개발할 수 있다는 말만 들어보고
그 이상은 잘 몰랐다.

그렇다고 아예 낯선 개념인가?
분명히 어디선가 많이 들어본 개념이고, 대략적인 느낌은 알고 있었다.
개발자를 위한 키트 정도로 이해하고 있었다.

처음에는 그냥 가져다 쓰는 코드 뭉치 정도로 생각 했었다.
하지만 찾아보려고 하니 뭔가 지나치게 간단하게 이야기 하거나
제가 이해하기에는 조금 어려운 부분이 있어 제 스스로 간단히 정리하며
저와 같은 입장이신 분들이 편하게 읽었으면 좋겠습니다.

SDK를 사용하는 이유

SDK를 쓰는 이유는 단순히 코드를 덜 쓰기 위해서만은 아닙니다.
로그인, 결제, 지도, 인증 같은 기능은 직접 구현하려고 하면 사실 많은 시간과 노력이 들어갑니다.
하지만 SDK는 이런 복잡한 과정을 조금 더 쉽게 시작할 수 있도록 도와줍니다.

SDK와 API의 차이점

대부분의 SDK에서는 애플리케이션이나 프로젝트를 커맨드라인으로 연결 하기 위해서
대부분의 SDK에 는 API가 포함 되어 있습니다.

SDK는 앱으로 개발 하는 전체 환경을 제공하며
API는 그 SDK 안에 포함되거나 단독으로
사용되는 '소프트웨어 간 통신 창구 입니다'
API는 특정 기능의 호출에 집중합니다.

SDK와 API 차이점 요약

특징	SDK (Software Development Kit)	API (Application Programming Interface)
정의	소프트웨어 개발을 위한 도구 모음(박스)	소프트웨어 간 통신을 위한 규칙(창구)
구성 요소	API, 라이브러리, 문서, 예제 코드, 디버거 등	함수, 프로토콜, 엔드포인트
목적	특정 플랫폼용 앱 전체 생성	다른 서비스의 기능/데이터 활용
포함 관계	SDK 내부에 하나 이상의 API 포함	SDK의 구성 요소 중 하나
비유	요리 재료와 도구가 다 든 요리 키트	식당에서 음식을 주문하는 메뉴판

왜 회사들은 SDK를 제공할까?

회사들이 SDK를 제공하는 이유도 분명합니다.
개발자가 자사 서비스를 더 쉽게 연동할 수 있게 만들고,
복잡한 인증이나 요청 흐름을 어느 정도 표준화하며,
반복해서 발생하는 실수를 줄이기 위해서입니다.

결국 SDK는 개발자를 돕는 도구이면서도,
자사 서비스를 더 쉽게 확산시키기 위한 방식이기도 합니다.

SDK 규칙 및 고려 사항

SDK를 사용할 때는 문서와 샘플 코드를 함께 보는 것이 중요합니다.
가이드 그리고 코드 샘플을 활용하여 구현 속도를 올리고 오류를 줄입니다.

정책을 준수하며 Google Play 등 앱 스토어 개발자 정책을 위반하지 않는 SDK를 사용해야 합니다.

버전 관리
정기적으로 SDK 버전을 확인 하고 최신 취약점 패치 혹은 기능 향상이 포함된 버전 사용

호환성
적용시 앱이 구형이나 최신 기기에서도 사용가능한지 확인

종속성 관리
기존 라이브러리와 충돌하는지 확인

성능 영향
기존의 기기에 메모리, 배터리 영향 테스트

글을 마무리 하며

이런 점들을 보면 SDK는 단순히 기능 몇 개를 묶어 둔 코드라기보다,
외부 기능을 내 서비스에 조금 더 쉽게 붙이도록 만든 개발 패키지에 가깝습니다.

분명 편리한 도구이지만, 그만큼 설정, 버전, 호환성, 종속성 같은 제약도 함께 따라옵니다.
그래서 SDK를 쓴다는 것은 단순히 기능 하나를 가져오는 일이 아니라,
편리함과 함께 일정한 방식과 제약을 받아들이는 선택이라고 생각합니다.

멀티스레딩과 멀티프로세싱의 차이

wnsl2002ok — Thu, 12 Mar 2026 00:46:30 +0900

부제 : 이것들은 왜 나오게 되었는가

0.글을 시작하며

멀티프로세싱과 멀티 쓰레딩을 처음 알았을 때는 굉장히 가슴이 설레었습니다.
하나로 처리하던 것을 두개로 처리를 하면 단순히 생각하면 2배로 빨라지니까요
개발자로써 어서 성장해서 이것들을 제어해서 한순가에 프로그램을 빨리 돌릴 생각에 설레던 날이 있었습니다.

하지만 그것이 녹록지 않음을 깨달은 것을 얼마 걸리지 않았습니다.

생각 이상으로 이것들을 제어하는 것은 어려웠으며 오히려 생각만큼 효율적이지도 않을 때도 있었습니다.

이번 글에서는 멀티프로세싱 멀티스레딩을 이야기해보며 왜 나왔고 장단점은 어떠하며
어떤 상황에 써야 효율적으로 사용할 수 있는지를 학습하며 글로 정리해 보려고 합니다.

CPU와 운영체제의 발전
멀티프로세스와 멀티스레드는 왜 나왔는가
멀티프로세스와 멀티스레드의 구조적 차이
어떤것이 더 좋은가?
실제 코드로 실험 해보기
멀티프로세스의 장단점
멀티스레드의 장단점
그렇다면 뭐가 좋은 걸까?
마무리

1.CPU와 운영체제의 발전

1-1 한번에 하나씩

초기에 컴퓨터는 한 번에 하나의 프로그램을 실행하며 순차 실행하였습니다.

따라서 어떻게 하면 하나의 프로그램을 빠르게 처리할지를 생각했을 때

CPU의 클럭을 높여서 성능을 높이는 게 주요 발전 방향이었습니다.

1-2 발전에 따라서 프로그램은 여러가지의 일을 하게 되었습니다.

- 음악 프로그램을 재생하며 사용자 입력받기
- 브라우저가 화면을 보여주며 네트워크 응답 기다리기
- 서버는 다수의 사용자의 요청을 처리해야만 함

이런 식으로 여러 요구를 동시에 처리를 하다 보니 문제가 발생합니다.
이는 곧 시분할 처리 방식이 나오게 된 계기가 됩니다.

시분할 처리 방식으로 CPU의 시간을 잘게 나누어서 여러 작업이 동시에 실행 되도록 하였고

실제로 CPU는 빠르게 A, B, C 작업을 번갈아가며 처리하지만
사용자는 동시에 처리되는 것처럼 느낍니다

1-3 단일 코어의 속도 향상의 한계

단일 CPU 성능을 올리는 것에는 한계가 존재합니다.
- 발열
- 전력 소모
- 메모리 병목
- 설계 복잡도 증가

등의 이유로 CPU의 발전 방향은 한 코어를 빠르게 만들 자에서 여러 코어를 두고 병렬로 처리하는 방향으로 발전하게 됩니다.
이 지점부터 멀티 프로세스와 멀티스레드가 점점 의미가 있어집니다.

2. 멀티프로세스와 멀티스레드는 왜 나왔는가

2-1 멀티 프로세스

프로세스는 실행 중인 프로그램의 인스턴스

운영체제는 각 프로세스에 독립된 메모리 공간 제공
프로세스 A, 프로세스 B는 독립된 메모리를 가지며 서로 직접 간섭 불가능

장점
- 서로 간 메모리 간섭 어렵다
- 하나가 문제 생겨도 다른 하나에 영향이 적다
- 보안과 격리에 유리

단점
- 프로세스 생성 비용이 큼
- 메모리를 더 사용
- 서로 데이터를 주고받으려면 IPC 필요

정리 : 안전하지만 무겁다

2-2 멀티스레드

하나의 프로그램에서 여러 흐름을 동시에 처리하고 싶은데, 매번 프로세스를 만드는 건 부담일 때

스레드 : 같은 프로세스 내에서 동작하는 실행 흐름

- 프로세스 내부의 스레드들은 코드, 데이터, 힙 영역 공유
- 하지만 각 스레드는 자기만의 스택과 레지스터를 가짐

장점
- 생성 비용 적음
- 같은 데이터 공유 쉬움
- 빠른 협업 가능

단점
- race condition
- deadlock
- 동기화 비용
- 디버깅 난이도 증가

정리 : 가지만 빠르다

3. 멀티프로세스와 멀티스레드의 구조적 차이

간단히 표로 정리하면 다음과 같습니다.

멀티프로세스 vs 멀티스레드 비교

항목	멀티프로세스	멀티스레드
메모리 공간	각자 독립	같은 프로세스 안에서 공유
생성 비용	큼	상대적으로 작음
문맥 전환 비용	큼	상대적으로 작음
데이터 공유	IPC 필요	메모리 공유 가능
안정성	높음	낮음
장애 영향 범위	비교적 분리됨	한 스레드 문제로 전체 프로세스 영향 가능
디버깅	상대적으로 단순	어려움
대표 사용 예	브라우저 탭 분리, 워커 프로세스, 독립 서비스	웹 요청 처리, 백그라운드 작업, UI + 작업 분리

4. 어떤것이 더 좋은가?

둘 다 모두 좋다 나쁘다 할 수 없습니다.
작업 종류에 따라 달라집니다

CPU Bound 작업 CPU 계산이 대부분인 작업

- 대량 수학 연산
- 이미지 처리
- 암호화/복호화
- 해시 계산
- 대규모 데이터 변환

CPU를 실제로 얼마나 병렬로 활용한 지가 중요

I/O Bound 작업

CPU 계산보단 기다리는 게 많은 작업

- 파일 읽기/쓰기
- 네트워크 요청
- DB 응답 대기
- 사용자 입력 대기

이경우에는 기다리는 동안 다른 작업을 얼마나 처리 하느냐가 중요합니다.

5. 실제 코드로 실험 해보기

앞에서 이야기드린 것처럼 멀티스레딩 그리고 멀티프로세싱의 가장 큰 차이는 메모리 공간의 공유 여부입니다.
이해를 돕기 위해 자바 코드로 두 가지 방식의 차이를 구현해 보았습니다.

5-1. 멀티스레딩 예시

스레드들은 같은 메모리를 공유할 수 있다는 것을 보여주는 예시입니다. 하나의 공유 객체를 두 개의 스레드가 동시에 접근하여
값을 변경합니다.

class SharedVault {  
    // 두 스레드가 공유할 공통 변수 (금고)  
    private int money = 0;  

    // 의도적으로 synchronized(동기화 자물쇠)를 걸지 않음  
    public void addMoney() {  
        money++;   
    }  

    public int getMoney() {  
        return money;  
    }  
}  

public class MultiThreadExperiment {  
    public static void main(String\[\] args) throws InterruptedException {  
        SharedVault vault = new SharedVault();  

        // 스레드 A: 금고에 1원씩 10,000번 넣기  
        Thread threadA = new Thread(() -> {  
            for (int i = 0; i < 10000; i++) vault.addMoney();  
        });  

        // 스레드 B: 금고에 1원씩 10,000번 넣기 (스레드 A와 동일한 금고 공유)  
        Thread threadB = new Thread(() -> {  
            for (int i = 0; i < 10000; i++) vault.addMoney();  
        });  

        threadA.start();  
        threadB.start();  

        threadA.join();  
        threadB.join();  

        // 예상 결과는 20,000원이지만, 실제로는 13,421원 등 매번 부족한 금액이 출력됨  
        System.out.println("최종 금고 잔액: " + vault.getMoney() + "원");  
    }  
}

위 예시 코드의 결과입니다.

멀티 스레드는 하나의 프로세스 내에서 메모리를 공유하기 때문에 이는 데이터를 주고받기 매우 쉽다는 장점이 존재하지만
동시에 여러 스레드가 하나의 데이터에 접근할 때 데이터가 오염되는 경쟁 상태를 유발할 수 있습니다.

왜 20000이 나오지 않을까?

스레드가 +1을 하려고 할 때 최신의 값을 가지고 더한 것이 아니라 아직 갱신되지 않은 옛날의 값을 이용했기 때문
결론 : 스레드는 데이터를 공유하기 때문에 통신 비용이 거의 들지 않아 빠릅니다.
하지만 synchronized 같은 동기화 장치를 마련하지 않으면 치명적인 버그를 낳습니다.

5-2. 멀티프로세싱 예시

프로세스별로 나뉘기 때문에 안전하다는 장점이 존재하지만
프로세스 간 통신(IPC)이라는 번거로운 단점 또한 존재

import java.io.BufferedReader;  
import java.io.InputStreamReader;  
import java.io.IOException;  

public class MultiProcessExperiment {  
    public static void main(String\[\] args) {  
        System.out.println("부모 프로세스: 자식 프로세스를 생성합니다.");  

        try {  
            // 완전히 독립된 새로운 프로세스(OS 명령어)를 실행  
            // 맥/리눅스: "echo", "Hello Process!" | 윈도우: "cmd.exe", "/c", "echo Hello Process!"  
            ProcessBuilder pb = new ProcessBuilder("echo", "Hello Process!");  
            Process childProcess = pb.start(); // 자식 프로세스 탄생  

            // ★ 핵심: 메모리를 공유하지 않으므로, 자식의 데이터를 변수로 읽을 수 없음!  
            // 파이프(Stream)를 연결해서 자식 프로세스가 출력한 데이터를 직접 빨아들여야 함 (IPC)  
            BufferedReader reader = new BufferedReader(  
                new InputStreamReader(childProcess.getInputStream())  
            );  

            String result;  
            while ((result = reader.readLine()) != null) {  
                System.out.println("자식 프로세스로부터 받은 메시지: " + result);  
            }  

            // 만약 자식 프로세스 내부에서 치명적 에러가 발생해 강제 종료되더라도,  
            // 부모 프로세스(현재 코드)는 전혀 영향을 받지 않고 끝까지 실행됨 (격리성)  
            int exitCode = childProcess.waitFor();  
            System.out.println("부모 프로세스: 자식 프로세스가 안전하게 종료되었습니다. (코드: " + exitCode + ")");  

        } catch (IOException | InterruptedException e) {  
            e.printStackTrace();  
        }  
    }  
}

위 예시 코드의 결과입니다

bufferedReader를 쓴 이유 프로세스 끼리는 메모리를 들여다볼 수 없어서
따라서 스레드처럼 같이 메모리를 쓰는 것이 아니라 데이터 스트림 혹은 소켓으로 데이터를 명시적으로 전송

결론 : 멀티 프로세스는 생성 비용이 크고 데이터를 주고받기 까다 롭다.
다만 자식 프로세스가 오류 나거나 악성코드가 돌아도 부모의 프로세스는 오염되지 않는 안정성을 가짐

6. 멀티프로세스의 장단점

이를 통해 멀티 프로세스 장단점을 정리하겠습니다.

장점

메모리 공간이 독립적이라 안정성이 높습니다
하나의 프로세스가 문제가 생겨도 다른 프로세스에 영향이 비교적 적습니다.

보안과 격리에 유리합니다

서비스를 분리하거나, 워커를 분리하거나, 장애 전파를 막는 데 좋습니다.

CPU Bound 작업에서 강력할 수 있습니다

여러 코어를 분리된 프로세스로 활용하기 쉽습니다. 단점

생성 비용이 큽니다

프로세스를 새로 띄우는 것은 스레드를 만드는 것보다 무겁습니다.

메모리 사용량이 큽니다

같은 프로그램이라도 프로세스를 나누면 중복 비용이 생깁니다.

통신이 번거롭습니다

서로 데이터를 주고받으려면 파이프, 소켓, 공유 메모리 같은 IPC가 필요합니다.

단점

동기화 문제가 생깁니다
공유 자원을 여러 스레드가 동시에 건드리면 충돌이 발생할 수 있습니다.

버그가 재현되기 어렵습니다

멀티 스레드 버그는 실행 순서에 따라 나타났다 안 나타났다 할 수 있습니다.

하나의 문제로 전체 프로세스가 영향을 받을 수 있습니다
같은 메모리를 공유한다는 장점은 동시에 위험이기도 합니다.

7. 멀티스레드의 장단점

장점

생성과 전환 비용이 상대적으로 작습니다
같은 프로세스 안에서 실행 흐름만 나누기 때문입니다.

데이터 공유가 쉽습니다

같은 메모리 공간을 사용하므로 협업이 자연스럽습니다.

I/O Bound 작업에서 효율적입니다
대기 시간 동안 다른 흐름을 처리하기 좋습니다.

단점

동기화 문제가 생깁니다
공유 자원을 여러 스레드가 동시에 건드리면 충돌이 발생할 수 있습니다.

버그가 재현되기 어렵습니다

멀티스레드 버그는 실행 순서에 따라 나타났다 안 나타났다 할 수 있습니다.

하나의 문제로 전체 프로세스가 영향을 받을 수 있습니다
같은 메모리를 공유한다는 장점은 동시에 위험이기도 합니다.

8. 그렇다면 뭐가 좋은 걸까?

선택의 기준은 내가 풀고자 하는 혹은 해결하고자 하는 문제가 무엇이느냐입니다.

멀티 프로세스가 잘 맞는 경우

안정성과 격리가 중요할 때

워커를 독립적으로 실행하고 싶을 때

CPU 연산이 많고 병렬 처리가 필요할 때

하나가 죽어도 전체 시스템이 같이 죽으면 안 될 때

예:

- 대규모 작업 큐 워커

- 독립 실행형 서비스

- 이미지/영상 처리 파이프라인

- 브라우저 탭/렌더러 분리

- 멀티 스레드가 잘 맞는 경우

- 같은 데이터를 자주 공유해야 할 때

- I/O 작업을 많이 동시에 처리할 때

- 빠른 반응성이 중요할 때

- 프로세스 분리 비용이 부담될 때

예:

- 웹 서버 요청 처리

- 네트워크 클라이언트

- UI 프로그램의 백그라운드 작업

- 게임 내 일부 비동기 작업

9. 마무리

멀티 프로세스 그리고 멀티 스레드는 결국 누가 더 뛰어나다 좋다 할 수 없습니다.

둘의 목적은 비슷하나 그 방법 그리고 그것을 실행하기 위한 비용이 다릅니다.

중요한 것은 이 작업이 어떤 게 중심이고 만드는 사람 입장에서 어떤 관점이 더 중요한지라고 생각합니다.

기술에는 뛰어난 기술 못난 기술보다는 문제를 해결하기 위한 도구라고 생각합니다.
문제의 비용과 구조를 보고 어떤 기술을 써야 할지 판단하는 게 더 중요하다고 생각합니다.

추가 개념

1. 시분할
운영 체제가 CPU 시간을 매우 짧게 나누어 여러 작업을 번갈아 처리하는 방식으로
실제로는 순차 처리에 가깝지만 사용자 입장에서는 동시 처리처럼 느껴지게 함

2. IPC
서로 다른 프로세스가 데이터를 주고받기 위한 통신 방식, 파이프, 소켓, 메시지 큐, 공유 메모리 등

c++ 과 java의 메모리 다루는 차이

wnsl2002ok — Tue, 24 Feb 2026 11:42:53 +0900

0. 글을 시작하며

C++ , JAVA 모두 객체 지향 언어인데 하나만 쓸까?

에 대한 이유를 막연히 메모리 관리, JAVA가 더 편하고 여러 환경에서 사용이 가능해서?

그렇다면 좀 더 구체적으로 이게 왜 저런 이유가 나오는지

그리고 두 언어는 단점 혹은 장점을 그대로 두거나 살리거나 어떻게 변했는지에 대해서 글을 적어보려고 합니다.

1. 두 언어는 어떻게 빌드 되는가

1-1. c++의 빌드 과정

컴파일 단계에서 특정 운영체제(OS)와 하드웨어 아키텍처가 바로 알아들을 수 있는 기계어로 직접
번역되어서 AOT(Ahead-of-Time) 컴파일을 통해 컴파일 합니다.

AOT 란 프로그램을 실행하기 이전, 즉 개발자가 배포할 때 이미 기계어로 번역된 상태

장점 : 실행하면 번역 과정 없이 바로 실행, 빠른 속도 적은 메모리 사용

단점 : 빌드 한 운영체제나 CPU 구조가 다르면 실행 불가

1-2.java의 빌드

기계어 대신 바이트코드(Bytecode)라는 중간 언어로 번역 os에 설치된 JVM이 실시간으로 읽어 기계어로 변환

장점 : JVM이 있으면 어느 환경에서든 똑같이 돌아감

단점 : 실행 시 JVM을 거치기 때문에 약간의 성능 오버헤드 발생

단점에 대한 해결 책 JIT 컴파일러

JVM은 프로그램을 실행하면서 자주 반복해서 실행되는 코드 구간(Hotspot)을 추적합니다. 그리고 이 자주 쓰이는 바이트코드를 아예 기계어로 직접 컴파일하여 캐싱(Caching)해 둡니다. 다음번에 같은 코드를 실행할 때는 번역 과정을 생략하고 캐싱 된 기계어를 바로 실행하기 때문에, 실행 속도가 비약적으로 향상됩니다.

2.C++의 메모리 영역

프로그램의 5대 메모리 영역

1. Code(Text): 컴파일된 기계어 코드가 저장되는 읽기 전용 구역

특징

읽기 전용 구역, 동작 변조를 방지하기 위해 운영체제(OS)가 쓰기를 금지

예시

void cal(int *a, int *b) { p->hp -= 10; } 함수의 작동 지시 내용 자체가 Code 영역에 속함

특징

프로그램 시작부터 끝까지 메모리에 남아있다

예시

int max_players = 100; // main 밖의 전역변수라 가정
static int server_port = 8080; // 초기화된 정적 변수 -> Data 영역

3.Stack 영역 : 지역 변수, 매개 변수

특징

함수의 호출과 함께 할당, 함수가 완료되면 함께 소멸
컴파일 시 이미 크기가 정해짐
메모리 주소가 높은 곳에서 낮은 곳으로

4.heap 영역 : 사용자에 의해 동적 할당

특징 : 사용자가 다 쓰면 delete 혹은 free로 반환

메모리의 주소의 낮은 곳에서 높은 곳으로 증식
런타임에 메모리를 찾아서 할당해야 해서 Stack에 비해 속도가 느리다
Player* newPlayer = new Player();

5. BSS(Block Started by Symbol) 영역 초기화되지 않은 전역 변수와 정적 변수

특징

프로그래머가 아직 값을 넣지 않은 변수들을 0으로 초기화

C++ 메모리 구조

data와 BSS를 나눈 이유

int inventory[10000];처럼 엄청나게 큰 전역 배열을 초기화하지 않고 선언했다고 가정
이만 개의 0을 실행 파일(.exe)에 일일이 다 써놓으면 파일 용량이 뻥튀기
따라서 "실행할 때 OS가 메모리 잡아주고 0으로 채워라"라고 기록

실행 파일의 크기를 줄이기 위함

그렇다면 자바 그리고 c++의 메모리 정리에는 어떤 차이가 있을지 간단하게 비교해 보겠습니다.

특징	C++ (메모리 구조)	Java (JVM 구조)
지역 변수 (int a)	Stack	Stack
객체 (Player p)	Stack (기본) / Heap (`new` 시)	무조건 Heap (Stack은 주소만)
전역/정적 변수	Data (초기화) / BSS (미초기화)	Method Area (Static 영역)
메모리 해제	수동 (`delete` 필수)	자동 (Garbage Collector)
포인터	실제 메모리 주소 제어 가능	주소 제어 불가능 (참조만 가능)

거의 비슷하지만 new 키워드가 없는 상태라면 함수가 끝나면 사라지게 됩니다.

3. C++의 특징

3-1. 포인터 - 다른 변수의 주솟값을 담기 위해 메모리 공간을 따로 차지하는 독립적인 변수

독립된 메모리 : 포인터 변수 자신도 메모리 상에 자기만의 8바이트 공간을 가진다
실행 중에 가리키는 대상 변경 가능
NULL 허용
위험성 쓰레기 주소 ^[각주:1] 나 이미 해제된 주소를 가리키고 있을 때 접근하면 프로그램 비정상 종료 가능

int a = 10;
int b = 20;

int* ptr = &a; // ptr은 a의 주소를 담음
ptr = &b;      // 언제든 b의 주소로 타겟 변경 가능
ptr = nullptr; // 아무것도 가리키지 않음 (이 상태에서 *ptr을 호출하면 프로그램 크래시!)

3-2. 참조자 (Reference, &) 이미 존재하는 메모리 공간에 새로운 이름
- 독립된 공간 없음
- 선언 즉시 초기화
- 변경 불가능
- NULL 불가

int a = 10;
int b = 20;

int& ref = a; // ref는 a의 또 다른 이름. (선언 시 반드시 초기화)
// int& ref2; // 에러! 누구를 참조할지 안 정했음.

ref = b;      // 이것의 의미는? 
              // "ref가 b를 참조해라"가 아니라, "ref(즉, a)의 값에 b의 값(20)을 덮어써라"입니다.
              // 결과: a가 20으로 바뀜.

간단하게 표로 한번더 비교 해보겠습니다.

특징	포인터 (*)	참조자 (&)
타겟 변경	가능 (다른 대상을 가리킬 수 있음)	불가능 (한 번 정해지면 끝까지 고정)
NULL 여부	가능 (`nullptr` 할당 가능)	불가능 (무조건 유효한 대상이 필요함)
표기법	`*`, `->` 등 복잡한 기호 필요	일반 변수와 똑같이 사용 (매우 깔끔함)
주 사용처	동적 할당, 배열 관리, NULL 처리가 필요할 때	함수 매개변수 전달, 객체 복사 방지 (권장)

포인터를 이야기드린 이유는 java 그리고 C++의 가장 큰 차이는 메모리에 대한 제어이고
포인터는 그 부분에서 핵심적인 차이를 보이는 개념입니다.

포인터를 사용하면 메모리의 주소를 직접 제어를 할 수 있게 됩니다.

포인터가 가지고 있는 데이터가 간단하게
int, double 같은 간단한 수준의 데이터 라면 큰 의미가 없을 수 있겠지만

만약 좀 더 큰 크기의 데이터를 옮긴다면

데이터를 옮기는 것보단

그 데이터의 위치가 적인 주소를 옮기는 것이 압도적으로 쉽고 빠르기 때문입니다.

특히나 컴퓨터에서 주솟값의 크기는 32비트는 4바이트
64비트는 8바이트로 고정되어 있으며

데이터의 값은 얼마든지 커질 수 있습니다.

만약 이 정도 크기의 데이터를 수정하거나 혹은 정렬을 하게 된다면
이 값을 일일이 옮기게 되면 상당히 오랜 시간을 소요할 수밖에 없습니다.
하지만 이중 포인터를 사용해서 주소만 갈아 치우면 8바이트만 움직이면 됩니다.

즉 데이터값이 커지면 커질수록 높은 효율성을 만들고
이는 곧 속도의 빠름으로 이어집니다.

4. C++ 속도 의 함정

4-1. 업 캐스팅(Upcasting) : 부모의 껍데기를 쓰는 이유

Base \*obj = new Derived();

자식 객체를 만들면서 부모젝체 담는 이유 -> 관리의 편의성

Unit*이라는 부모 포인터 배열 하나에 다 쓸어 담고 unit->attack() 한 줄로 명령을 내리기 위함

4-2 vtable과 vptr의 마법

그렇다면 컴파일러 입장에서는 부모의 attack()을 실행할지 혹은
자식의 attack()을 실행해야 할지 헷갈리는 상태

C++ 컴파일러는 두 개를 실행

vtable (가상 함수 테이블): 클래스마다 '이 클래스가 호출해야 할 진짜 함수들의 메모리 주소'를 적어둔 비밀 지도(배열)를 만듭니다.

vptr (가상 함수 포인터): 생성된 객체 내부에 몰래 포인터 변수(vptr)를 하나 쓱 집어넣습니다. 이 포인터는 자기 클래스의 vtable을 가리킵니다.

4-3 소멸자 누락 시 생기는 문제

객체를 다 썼으니 delete obj;를 호출해서 메모리를 해제
만약 Base 클래스의 소멸자(~Base())에 virtual을 안 붙였다면?
부모의 소멸 자만 실행하고 객체를 파괴 -> 자식의 소멸자가 실행되지 않아서 메모리 누락 발생

해결책
부모 클래스를 설계할 때 소멸자 앞에 virtual

class Base {
public:
    virtual ~Base() {} // 황금률: 상속될 클래스의 소멸자는 무조건 virtual!
};

4-4 C++이 찾은 해결책 스마트 포인터

std::unique\_ptr 입니다. 이 외에도 몇가지가 더 있으나 너무 길어져서 간단히 하나만 소개 하겠습니다.
하나의 메모리 주소는 오직 하나의 unique\_ptr만 가질 수 있습니다. 복사(Copy)가 엄격하게 금지됩니다.
다른 곳에 넘겨주고 싶다면, 내 권리를 포기하고 '이동(std::move)'시켜야만 합니다.

#include #include // 스마트 포인터를 쓰기 위한 헤더

class Player {
public:
Player() { std::cout << "플레이어 생성\n"; }
~Player() { std::cout << "플레이어 소멸 (자동!)\n"; }
void attack() { std::cout << "공격!\n"; }
};

void play_game() {
// new 대신 std::make_unique를 사용합니다.
std::unique_ptr p1 = std::make_unique();
p1->attack();

// std::unique_ptr<Player> p2 = p1; // 에러! 복사 불가능! (컴파일 단계에서 막아줌)

std::unique_ptr<Player> p3 = std::move(p1); // 성공! p1의 소유권을 p3로 넘김. (이제 p1은 텅 빔)

} // <--- 함수가 끝나는 이 순간! p3가 소멸되면서 내부적으로 알아서 delete를 호출함.

요약하자면 delete를 통해서 메모리를 반환하는 방식이
함수가 끝나면 자동으로 반환되는 방식으로 되어있어서
더 이상 실수로 delete를 빼먹어서 메모리 누수가 발생할 일이 없습니다.

5. C++의 해결책 그리고 vs Java의 해결책

JAVA 개발자는 비즈니스 로직만
가비지 컬렉터(Garbage Collector, GC)를 사용하여
Heap 메모리가 꽉 차면, 백그라운드에 숨어있던 GC가 나타나 참조되지 않는 쓰레기 객체들을 싹 쓸어 담습니다. 개발자는 new만 delete는 안 해도 된다.

단점 : 청소를 하는 동안 프로그램이 아주 잠깐 멈추는 Stop-The-World 현상이 발생
C++의 선택 스마트 포인터를 이용한 (RAII 패턴 제시 ^[각주:2])

게임 렌더링처럼 1프레임의 드롭도 용납할 수 없는 분야에 사용
GC의 멈춤 현상은 용납 불가

unique\_ptr / shared\_ptr: 이들은 포인터를 객체로 감싼 형태입니다. 함수나 블록의 스코프({ })가 끝나는 **단 0.0001초의 오차도 없이, 객체의 소멸자가 호출되며 메모리를 스스로 해제(자폭)**합니다.

C++은 런타임 오버헤드(GC) 없이도 안전한 메모리 관리를 이뤄냈습니다. (물론 shared\_ptr의 순환 참조 문제^[각주:3]는 weak\_ptr을 통해 개발자가 직접 고리를 끊어주어야 하는 책임이 따릅니다.)

즉 스마트 포인터도 이전보다 문제는 적지만 여전히 순환 참조 등의 문제를 통해서 문제가 발생할 수 있습니다.

6. 도메인의 차이

C++, JAVA는 결국 어떤 문제를 해결할 것인가에 따라서 정답이 달라질 뿐입니다.

C++의 무대: 미세한 메모리 지연이나 GC의 개입이 치명적인 대규모 3D 게임 클라이언트, 자체 물리 엔진 개발(Netmarble, Pearl Abyss 등에서 요구하는 역량), 자율주행, 임베디드 시스템에서는 C++의 하드웨어 통제력이 필수적입니다.

Java의 무대: 안정적인 유지 보수와 높은 생산성이 요구되는 대규모 엔터프라이즈 백엔드 서버(Spring Boot 기반의 플랫폼 등)에서는 Java의 JVM과 가비지 컬렉터가 압도적인 안정성을 제공합니다.

어떤 도메인을 선택하느냐에 따라서 아예 안 쓰는 언어가 될 수도 있습니다만

왜 이 언어가 존재하고
왜 이 언어가 선택되는지를 알면

향후 기술의 발전에 따라서 사용되는 언어가 달라지거나
기술 스택이 달라질 때 능동적으로 기술을 선택할 수 있는 계기가 되지 않을까 생각합니다.

쓰레기 주소
메모리가 이미 해제(delete)되었음에도 불구하고 포인터가 여전히 그 주소를 가리키고 있는 상태(Dangling), 혹은 포인터를 선언만 하고 초기화하지 않아 임의의 메모리 공간을 가리키는 상태(Wild)를 말합니다. 이 주소에 접근해 값을 읽거나 쓰려 하면 치명적인 런타임 에러가 발생합니다. [본문으로]
RAII 패턴 자원의 획득은 초기화다"라는 뜻으로, 객체가 생성될 때(생성자) 자원을 할당받고, 객체가 스코프를 벗어나 소멸할 때(소멸자) 자원을 자동으로 반환하도록 설계하는 C++의 핵심 프로그래밍 기법입니다. 스마트 포인터가 이 패턴을 완벽하게 따릅니다. [본문으로]
순환 참조 문제 두 개 이상의 shared\_ptr 객체가 서로를 포인터로 가리키고 있는 상태입니다. 서로가 서로를 참조하고 있기 때문에 참조 카운트(Reference Count)가 절대 0이 되지 않아, 스코프를 벗어나도 영원히 메모리에서 해제되지 않는 메모리 누수(Memory Leak)가 발생합니다. 이를 해결하기 위해 참조 카운트를 올리지 않고 관찰만 하는 weak\_ptr을 사용합니다. [본문으로]

무조건 쓰던 MVC 왜 쓸까?

wnsl2002ok — Wed, 18 Feb 2026 17:32:50 +0900

mvc 패턴을 사용하다 보니 모든 곳을 수정할 필요 없이
특정 구간만 수정하면 된다는 것을 알게 된 후에는 코드의 수정이나 기능 추가가 빨라짐을 알게 되었습니다.

MyBatis 쿼리 문에서 따로 파라미터 수정이 필요한 케이스가 아니라면 MyBatis의 수정만 이루어지면 되기 때문에
빠르게 수정이 가능했습니다.

파일을 나눈 이유가 형식적으로 나눈 것이 아니라 서로에게 영향을 주지 않기 위한 격리 임을 깨닫는 순간이었습니다.

3. mvc는 왜 필요할까

그래서 mvc와 관련돼 소프트웨어 아키텍처는 무엇이고 왜 좋은지에 대해서 추가적으로 학습해 보았습니다.

아티택쳐는 크기에 따라 조금씩 나뉩니다.

시스템 아키택쳐(client-server, layered, MSA)
시스템을 어떻게 설계할지
서버와 클라이언트 연결 및 DB는 어떻게 둘지

애플리케이션 아키택쳐(MVC, MVVM)
애플리케이션 설계
프로그램 안에서 화면 및 데이터를 어떻게 주고받을지

구현 및 디자인 패턴 GOF(singleton, strategy)
코드를 실제적으로 어떻게 구현할지에 대한 방식

이 중에서는 저희는 애플리케이션 아키택쳐인 MVC를 사용했습니다.
특히 가장 흥미로웠던 것은 과거의 MVC와 현재의 MVC가 조금은 다르다는 점입니다.
이 중에서 애플리케이션 아키택쳐에 대해서 학습을 해보도록 하겠습니다

우선 종류로는 과거의 mvc, 현재의 mvc, mvvm, mvp
이부분에 대해서는 자세히 설명하면 현재 글이 너무 길어져서 이후에 따로 글로 정리 해보려고 합니다.

패턴	핵심 로직 담당	화면 갱신 방법	View-Model 관계	비고
과거 MVC	Controller	서버에서 HTML 전체 새로고침	강한 결합 (직접 연결)	JSP 시절
현재 MVC	Controller	클라이언트가 알아서 (JSON)	약한 결합 (연결 끊김)	Spring Boot 표준
MVP	Presenter	Presenter가 명령 (수동)	분리됨 (Interface)	안드로이드 초기
MVVM	ViewModel	데이터 바인딩 (자동)	분리됨 (관찰)	모던 프론트엔드

이를 통해서 왜 mvc를 사용하고 동시에 왜 mvc가 좋았는지를 이해할 수 있었습니다.

4. 향후 발전 방향

처음에는 생소하고 이해가 안 되었지만 이 아키텍처를 왜 학습 시켰는지 이제야 몸소 이해할 수 있었습니다.
앞으로 프로젝트에서도 mvc뿐만 아니라 다른 아키텍처도 적용 가능한지
혹은 더 적절하다면 이유가 무엇인지를 좀 더 능동적으로 선정하고 학습하며 성장하고 싶습니다.

기술 부채 나쁘기만 할까요?

wnsl2002ok — Tue, 10 Feb 2026 15:40:24 +0900

글을 시작하며

이 글을 쓰게 된 이유는 다음과 같습니다

모든 개발자들은 학습에 목마른 사람 그리고 새로운 기술을 배우고 싶고
또한 그것을 사용하고 싶은 사람 임을 가정하고 이 글을 시작해 보고자 합니다.

이글은 저의 개인적인 의견이 담긴 글이며 혹시나 틀린점이 있다면 언제든지 지적 해주시면 감사하겠습니다.

개발자는 왜 새로운 기술을 사랑할까?

개발자들은 왜 항상 새로운 기술에 목말라하고 왜 항상 새로운 기술을 써보고 싶어 할까요?
저의 주관적인 생각으로는 개발자들은 학습에 목마르고 새로운 기술을 써보고 싶어 하는 성향을 가졌다고 생각합니다.

저 또한 그렇습니다.

그렇다면 개발은 무엇일까요?

개발이란?

"소프트웨어 개발의 목표는 효율적이고 반복 가능하며 안전한 방식으로 사용자 요구와 비즈니스 목표를 충족하는 제품"

정의 내에서 제가 한 생각은 개발에서 가장 중요한 것은 도덕적인 범주 내에서 안전하게 작동한다.
그리고 사용자의 요구 그리고 비즈니스의 목표에 충족하는 것이라고 생각합니다.

사용자의 요구 그리고 비즈니스의 목표 두 가지의 목표로 분리하고 아래의 글을 쓰며 두 가지에 대해서 이야기하겠습니다.

실제로 있었던 사례 하나

일례로 싸피에서 약 6주간 간단한 프로젝트를 진행해 본 적이 있었습니다.
같은 팀원 분께서 코드를 계속 고치시는데 상당히 오랜 시간이 소요되어서 여쭤본 적이 있었습니다.
그도 그럴 것이 test 코드도 문제가 없고 빌드도 문제가 없어서 아무 문제가 없는데 왜 그러신지 여쭤보았습니다.
deprecated된 함수여서 바꾸어야 한다고 이야기를 하셨었습니다.

실제로 저희 프로젝트에 떴었던 이미지 입니다
deprecated란 기대하는데로 작동은 할 수 있으나 곧 사라질 예정인 코드를 의미 하는데요.

바꾸시는 이유에 대해서 조금더 대화를 해보았습니다.
기술 부채를 이유로 꼽으시며 코드를 고쳐야한다고 이야기 하셨습니다.
그것이 이글을 쓰게 하는데 시작점이 되었습니다.

기술 부채란?

본격적으로 이야기 하기전에 기술 부채에 대해서 설명하겠습니다.

소프트웨어 개발에서 장기적인 고품질 솔루션 대신, 당장의 빠른 납기나 쉬운 구현을 위해 단기적이고 제한적인 임시 방편을 선택함으로써 향후 추가적인 재작업 비용과 위험을 부담하게 되는 현상을 의미 합니다. 1992년 와드 커닝햄이 처음 사용한 비유로, 당장의 빠른 개발이라는 '대출'을 통해 나중에 '이자'를 포함한 더 많은 수정 작업을 해야 하는 상황을 말합니다.

"한컴 테크 발췌"

이처럼 기술 부채란 재작업 비용과 위험을 부담하게 되기 때문에 사실 장기적으로 보면 좋은 개발 방법은 아닙니다.
하지만 이러한 기술 부채가 꼭 나쁘기만 한것 일까요?

잠시 deprecated된 함수 이야기를 계속 하겠습니다.

곧 사라질 코드이기에 사용하는건 올바르지 않다고 여길 수 있으나

이것을 고치기 위해서는 두가지가 필요합니다.

첫 번째는 그 코드를 고치기 위해서 학습을 해야 하는 학습 비용
두 번째는 그 코드를 고치기 위해서 개선하는 데 시간을 써야 하는 개선 비용
개선에는 그 코드를 고치는 것뿐만 아니라 그 코드를 고쳐서 발생하는 side effect까지 고려해야 합니다.

상황을 정리해 보겠습니다.
여기서 저희 팀원 분께서는 나중에 이 코드가 작동하지 않았을 때의 기술 부채를 걱정하신 것이고
저의 의견 속에는 학습 비용 및 개선 비용 이 기술들을 사용하기 위해서 팀 혹은 개인이 사용해야 하는 시간을 이야기한 것입니다.

아까 가장 처음에 이야기드린 것처럼 프로그램에서 가장 중요한 것은 안전하게 반복 작업을 하는 것
이는 당장 써야 할 코드에 기술 부채에 비해서 팀은 학습 비용 그리고 개선 비용까지 지불한 것입니다.

6주 내의 프로젝트 내에서 기술 부채를 가지고 개발을 할지?
혹은 학습 비용이나 개선비용까지 지불을 할지는 프로젝트의 목적에 따라 달라질 수 있습니다.

하지만 6주 내 동안 진행하는 프로젝트의 목적은 무엇일까요?
프로젝트 시작 전 많은 개발자들은 처음에 생각합니다. 깔끔한 코드, 최신 기술, 깔끔한 git commit
하지만 6주 동안 프로젝트를 진행하면서 가장 목표로 삼아야 하는 것은 프로젝트의 완성도입니다.

하지만 이로 인해 핵심 기능이 부재하다면 핵심 기능이 부재함으로써 오는 기회비용에 대한 손실이 더 크다고 판단됩니다.
방향성 자체가 틀린 것은 아니고 무엇을 더 중점을 두느냐의 차이라고 생각합니다.

그렇다면 무조건 옛날 기술만 써야 할까요?
그런 것은 아닙니다.
적정 기술이라는 개념이 있습니다.

적정 기술이란?

고사양·고비용 대신, 사용자의 환경(저사양 기기, 느린 인터넷, IT 문해력 등)과 문화적 배경에 맞춰 지속 가능하고 저렴하게 실제적인 문제를 해결하는 기술을 의미합니다.

저희가 서버를 배포할 때 쿠팡이나 아마존 같은 큰 기업과 똑같은 수준의 서버를 만들어서 배포를 하지 않습니다.
그렇듯이 코드도 완벽에 가까운 코드를 만들면 좋겠지만 적정 선을 두어서 개발 속도를 유지할 필요가 있다고 생각합니다.

실제로 예로든 프로젝트에서 저희는 올바르게 적정 기술의 수준을 설정하지 못했고
큰 줄기로 보았을 때 두 가지의 기능이 목표였지만 그중 하나만 개발할 수 있었습니다.
이점이 아직도 두고두고 아쉽습니다.

마찬가지입니다.
비즈니스의 입장에서도 기술을 개선하지 않는 이유는 학습 비용 그리고 개선 비용이 기술 부채를 아득히 초월하는 경우가 있습니다.

비즈니스적인 관점에서 보았을 때 시장은 항상 변화하고 우리를 기다려주지 않습니다.

적절한 타이밍의 배포가 주요하며 이는 기술 부채를 감수하고도 서비스를 배포하고 고객의 피드백을 받는 것이
출시가 늦어진 서비스 보다 훨씬 값진 데이터를 제공하기 때문입니다.
결국 개발이란 한정된 자원 속에서 최적의 가치를 만들 내는 과정이라고 생각합니다.

완벽한 코드 보다 한정된 자원 속에서 최적의 가치를 만들어 내는 것이 더 좋은 개발자라고 생각합니다.

웹 개발 공부 시작

wnsl2002ok — Tue, 27 Jan 2026 22:18:10 +0900

웹 개발 공부를 시작 하기로 했습니다.

블로그를 쓰게 된 계기는 멘토님의 추천도 있었고 정리를 해두면 좋을것 같은 생각이 들어서 블로그를 작성 하게 되었습니다.

우선 첫날에 간단하게 정리 해둔 부분을 기록 해두려고 합니다.

기록은 아마 주에 한번? 혹은 공부하고 마지막 날에 기록을 해두려고 합니다.

오늘은 멘토님과 함께 공부를 한 날이었습니다.

우선적으로는 도메인을 구매 했습니다.

도메인을 구매 하기에 앞서 도메인에 대하여 설명을 하도록 하겠습니다.

웹 사이트에서의 도메인 이란?

웹사이트 도메인 (Website Domain)

웹사이트 도메인은 인터넷에서 특정 웹사이트에 접근할 수 있는 주소(URL)의 핵심 부분이에요.

예를 들어, www.google.com에서 google.com이 도메인입니다.

웹 도메인의 구성

서브도메인(Subdomain): www.google.com에서 www 부분 (필수는 아님)
도메인 이름(Domain Name): google (사이트의 고유한 이름)
최상위 도메인(TLD, Top-Level Domain): .com, .net, .org 등
국가 코드 도메인(ccTLD, Country Code TLD): .kr(한국), .jp(일본) 등

도메인과 관련된 개념입니다.

도메인 관련 개념

DNS (Domain Name System): 사람이 이해하기 쉬운 도메인(google.com)을 IP 주소(예: 142.250.74.206)로 변환해주는 시스템
도메인 등록: namecheap.com, godaddy.com 같은 서비스에서 구매 가능
도메인과 호스팅의 차이: 도메인은 주소, 호스팅은 사이트가 저장된 서버 공간

도메인을 구입하는 방법

도메인등록 업체를 선정하고 -> 원하는 도메인 주소를 선택 합니다. -> 돈을 지불 하고 도메인 구매합니다.(일반적으로는 1년 단위로 구매 합니다) -> 이후 에는 도메인을 서버 혹은 웹 호스팅에 연결 합니다.

저의 경우는 cafe24에서 도메인을 구매 하였습니다.

구입 후 웹 호스팅 서비스를 구매하 연결 하였습니다.

웹 호스팅이란?

웹사이트를 인터넷에 공개할 수 있도록 서버 공간을 제공하는 서비스예요.

즉, 내가 만든 웹사이트의 파일(HTML, CSS, 이미지, DB 등)을 서버에 올려서 사람들이 인터넷에서 접속할 수 있게 해주는 것 입니다.

웹 호스팅 후 그누보드를 추가하여 줍니다.

그누보드란?

그누보드는 PHP와 MySQL을 기반으로 하는 오픈소스 게시판 및 CMS(Content Management System)입니다.

쉽게 말해, 웹사이트(특히 커뮤니티, 회사 홈페이지 등)를 만들 때 유용한 무료 프로그램 입니다.

그누 보드는 웹 사이트를 처음부터 만드는것이 아니라 어느정도 기능들을 만들어두고 빠른 개발이 가능토록 하는 프로그램입니다.

그누보드를 추가한 후 의 현재 저의 사이트 상태 입니다.

내용은 없지만 사이트 처럼 생긴것을 알 수 있습니다.

다음은 FTP 및 클라이언트 및 서버 프로그램인 파일 질라를 다운로드 해줍니다.

파일질라란?

FTP(File Transfer Protocol) 클라이언트 및 서버 프로그램으로, 웹 서버와 파일을 주고받는 데 사용되는 프로그램

대표사진 삭제

AI 활용 설정

사진 설명을 입력하세요.

파일 질라 다운로드가 완료되었다면

완료된 파일질라를 열고 -> 파일 -> 사이트 관리자 클릭

사이트 관리자를 클릭하면 아까 만드신 도메인과 파일질라를 연결하기 위해서 정보를 입력하는 창이 띄워집니다.

프로토콜은 ssh

호스트는 구매하신 도메인 이름을

사용자 및 비밀번호는 도메인 구매시 사용하신 아이디 그리고 비밀번호가 있습니다.

그것을 잘사용해주시면 됩니다.

비밀번호 같은 경우는 주의 해야하는 것이 잊어 버리면 상당히 고통을 수반 하기 때문에 잊어버리는 않는 것이 좋습니다.

이렇게 연결을 눌러 주시면...

이러한 형태로 바뀝니다.

이제 왼쪽이 로컬 즉 내 컴퓨터에 있는 파일이고 오른쪽의 파일들은 현재 웹 사이트에 있는 파일들입니다.

여기서 html 파일을 만들어서 건너편으로 넣어주면

대표사진 삭제

AI 활용 설정

사진 설명을 입력하세요.

이런 식으로도 제가 만든 웹 사이트 또한 만들 수 있습니다.

물론 html 하나만 있어서 현재 글자외엔 다른 것은 없습니다.

이제 필요한 기본적인 것들을 갖추었다고 생각 합니다만..

아직 부족한 부분들이 많습니다. 그중에서도 DB즉 서버에 데이터를 저장하고 불러오는 과정인

SQL이 필요합니다. 이를 위해 sql 프로그램 중 HeidiSQL을 다운로드 해주겠습니다.

HeidiSQL이란?

HeidiSQL은 MySQL, MariaDB, PostgreSQL, Microsoft SQL Server와 같은 관계형 데이터베이스 관리 시스템(RDBMS)을 관리할 수 있는 그래픽 사용자 인터페이스(GUI) 클라이언트입니다. 이를 통해 데이터베이스를 쉽게 조회하고, 수정하며, 다양한 데이터베이스 작업을 수행할 수 있습니다.

HeidiSQL은 Windows에서 주로 사용되며, Linux와 macOS에서도 Wine을 통해 사용할 수 있습니다. 이 프로그램은 SQL 쿼리를 작성하고 실행하거나, 데이터베이스 구조를 관리하는 데 유용하게 사용됩니다.

마지막으로 중간에 ssh 설정을 했는데 마지막에 생각하니 빼 놓아서 ssh에 대한 설명만 적고 오늘은 마치겠습니다.

SSH의 주요 특징

암호화된 통신

SSH는 모든 데이터를 암호화하여 전송하므로 인터넷을 통한 원격 접속 시 보안이 매우 강력합니다.
패스워드, 명령어, 파일 전송 내용 등이 모두 암호화되어, 중간에서 도청하거나 해킹이 어려워집니다.

원격 접속

SSH는 주로 리눅스 서버나 유닉스 시스템에 접속할 때 사용되며, 윈도우 서버에도 사용할 수 있습니다.
사용자 이름과 비밀번호 혹은 SSH 키를 사용하여 원격 서버에 접속할 수 있습니다.

명령어 실행

원격 서버에 접속한 후, 서버에서 직접 명령어를 실행할 수 있습니다. 예를 들어, 파일 관리, 프로그램 실행, 서버 설정 등을 할 수 있습니다.
명령어를 통해 서버의 상태를 점검하거나 서비스를 제어할 수 있습니다.

파일 전송

**SCP (Secure Copy Protocol)**나 **SFTP (SSH File Transfer Protocol)**를 사용하여 SSH를 통해 원격 서버에 파일을 안전하게 전송할 수 있습니다.

✅ SSH의 기본 동작 방식

1️⃣ 클라이언트가 SSH 서버에 접속

클라이언트가 서버의 IP 주소와 포트를 통해 연결을 시도합니다. 기본적으로 22번 포트를 사용합니다.

2️⃣ 서버의 공개키(Public Key)와 클라이언트의 비밀키(Private Key)로 인증

공개키와 비밀키로 서버와 클라이언트 간의 신뢰성 있는 암호화된 연결을 설정합니다. (보안상 중요한 부분)
또는 비밀번호 인증 방식도 사용 가능합니다.

3️⃣ 암호화된 채널을 통해 데이터 전송

이후에는 암호화된 채널을 통해 모든 명령어와 데이터를 안전하게 주고받습니다.

이상으로 공부했었던 웹 개발 부분을 마치겠습니다.

다음에 공부할 부분은

html,css 부분을 공부하고 php로 넘어가보려 합니다.

https://www.w3schools.com/

html그리고 css의 경우는 위 사이트에서 할 예정입니다.

저 사이트에 적절한 예제가 있다고 멘토님께 소개 받아서 저 사이트에 있는 문제를 모두 풀어보고 다음으로 넘어갈 예정입니다. 이상입니다. 감사합니다.

혹여나 이상하거나 틀린 부분 지적해주시면 바로 고치겠습니다.

이상입니다.

wnsl2002ok 님의 블로그

질문을 잘 해도 틀릴 수 있다: 포트원 인증 이슈로 본 LLM의 한계

1. 글을 쓰게 된 이유

2. 문제가 없는 줄 알았다.

3. 내가 질문을 잘못한 줄 알았다

4. 여기서 깨달은 점

5. 그렇다면 새 기술에서는 어떻게 쓸까?

6. 결론

API 응답(Response)에 관하여

1. API response를 처음 보았을 때

2. API 응답(Response)란?

3. API 응답의 본질

4. 우리 프로젝트의 응답 설계

5. 실패를 대비한 "Fallback" 설계

6. 마치며

SDK는 어떤 것 일까?

SDK를 사용하는 이유

SDK와 API의 차이점

SDK와 API 차이점 요약

왜 회사들은 SDK를 제공할까?

SDK 규칙 및 고려 사항

글을 마무리 하며

멀티스레딩과 멀티프로세싱의 차이

부제 : 이것들은 왜 나오게 되었는가

0.글을 시작하며

1.CPU와 운영체제의 발전

1-1 한번에 하나씩

1-2 발전에 따라서 프로그램은 여러가지의 일을 하게 되었습니다.

1-3 단일 코어의 속도 향상의 한계

2. 멀티프로세스와 멀티스레드는 왜 나왔는가

2-1 멀티 프로세스

2-2 멀티스레드

3. 멀티프로세스와 멀티스레드의 구조적 차이

멀티프로세스 vs 멀티스레드 비교

4. 어떤것이 더 좋은가?

5. 실제 코드로 실험 해보기

5-1. 멀티스레딩 예시

5-2. 멀티프로세싱 예시

6. 멀티프로세스의 장단점

7. 멀티스레드의 장단점

8. 그렇다면 뭐가 좋은 걸까?

9. 마무리

c++ 과 java의 메모리 다루는 차이

0. 글을 시작하며

목차

1. 두 언어는 어떻게 빌드 되는가

1-1. c++의 빌드 과정

1-2.java의 빌드

2.C++의 메모리 영역

프로그램의 5대 메모리 영역

1. Code(Text): 컴파일된 기계어 코드가 저장되는 읽기 전용 구역

3.Stack 영역 : 지역 변수, 매개 변수

4.heap 영역 : 사용자에 의해 동적 할당

5. BSS(Block Started by Symbol) 영역 초기화되지 않은 전역 변수와 정적 변수

3. C++의 특징

4. C++ 속도 의 함정

5. C++의 해결책 그리고 vs Java의 해결책

6. 도메인의 차이

무조건 쓰던 MVC 왜 쓸까?

목차

1. 내가 MVC를 쓰게 된 이유

2. MVC가 처음으로 좋다고 느꼈을 때

3. mvc는 왜 필요할까

4. 향후 발전 방향

기술 부채 나쁘기만 할까요?

글을 시작하며

개발자는 왜 새로운 기술을 사랑할까?

개발이란?

실제로 있었던 사례 하나

기술 부채란?

적정 기술이란?

웹 개발 공부 시작