1. Google Cloud 로드 밸런서 이해: 정의, 구성 요소, 구성 방법

 

클라우드 인프라를 구축하거나 API Gateway를 배포하는 과정에서 반드시 만나게 되는 개념이 있습니다. 바로 로드 밸런서(Load Balancer)입니다. 이 글에서는 로드 밸런서란 무엇인지, Google Cloud에서는 어떤 구성 요소로 이루어져 있는지, 그리고 실제로 HTTPS 로드 밸런서를 어떻게 구성하는지비유와 명확한 단계별 설명, 실제 명령어 및 참고 링크와 함께 정리합니다.

 

(이 글은 구글 클라우드의 “API 게이트웨이용 부하 분산 시작하기”, https://cloud.google.com/api-gateway/docs/gateway-serverless-neg?hl=ko에 바탕하여 작성되었습니다. 좀 더 자세히 알고 싶으시면 위의 링크 내용을 참고하시기 바랍니다.)

 

로드 밸런서가 필요한 이유는 아래와 같습니다.

1. 여러 서버에 트래픽을 고르게 분산하기 위해

· 사용자가 몰리면 한 서버에만 요청이 집중되어 과부하가 발생할 수 있습니다. (여러 백엔드 인스턴스에 자동으로 부하 분산)

· 로드 밸런서는 요청을 여러 서버로 자동으로 나눠 부하를 분산시킵니다. (백엔드를 수평 확장하면 로드 밸런서가 자동 분산)

 

2. 서비스 가용성을 높이기 위해

· 서버 하나가 다운되더라도 다른 서버가 계속 동작하도록 하여 중단 없는 서비스를 제공합니다.

· 로드 밸런서는 정상 상태의 백엔드만 사용합니다 (헬스 체크 기반).

 

3. 글로벌 사용자에게 빠른 응답 제공

· 사용자와 가까운 리전의 서버로 트래픽을 유도해 **지연(latency)**을 줄일 수 있습니다.

· Google Cloud에서는 글로벌 로드 밸런서가 지원됩니다.

 

4. SSL 종료 및 보안 처리

· HTTPS 암호화를 **로드 밸런서 앞단에서 처리(SSL 종료)**함으로써 백엔드의 부담을 줄이고, 관리도 단순화됩니다.

 

5. 도메인 기반, 경로 기반 라우팅 지원

· /api는 Cloud Run, /static은 Cloud Storage 등 다양한 백엔드에 세분화된 라우팅이 가능합니다.

 

1.1 Google Cloud의 로드 밸런서 구성 요소

Google Cloud에서 로드 밸런서는 다음과 같은 요소들로 구성됩니다:

구성 요소
설명
Global Forwarding Rule
외부 IP와 포트를 설정하고, 프록시로 요청을 전달합니다
Target HTTPS Proxy
SSL 인증서로 HTTPS 요청을 해독하고, URL 맵으로 전달합니다
SSL Certificate
도메인의 신원을 증명하고 암호화 통신을 지원합니다
URL Map
요청의 Host/Path에 따라 백엔드 서비스로 라우팅합니다
Backend Service
실제로 요청을 처리할 Cloud Run, App Engine 등으로 연결됩니다
NEG (Network Endpoint Group)
백엔드와 연결되는 실질적인 엔드포인트입니다

이 모든 요소가 하나로 모여 하나의 로드 밸런서를 구성합니다. 위의 구성요소들을 그림으로 표현하면 아래와 같습니다.

 

1.2 로드 밸런서에 대한 비유적 설명

아래는 해당 로드 밸런서의 각 구성 요소에 대해서 사무실의 직원을 찾아가는 경우로 비유한 설명입니다:

구성 요소 (Component)
역할 (비유적 설명)
Forwarding Rule
거리 주소 (IP + 포트) — 어디로 오는지 지정하는 위치
Target HTTPS Proxy
보안 게이트 — TLS 핸드셰이크를 처리하는 입구 보안요원
SSL Certificate
출입증 — 암호화된 입장을 허용하는 보안 인증 키
URL Map
안내 데스크 — 어디 부서로 가야 할지 알려주는 리셉션
Backend Service
부서 — 실제 요청을 담당할 API, 저장소 등의 기능 단위
NEG (Cloud Run 등)
실제 직원 — 사용자의 요청을 실제로 처리하는 시스템

 

2. 각 구성 요소에 대한 설명

위에서 각 구성요소들에 대해서 대략적으로 역할을 알아보았으니, 지금부터는 좀 더 자세히 알아보겠습니다.

 

2.1 전역 포워딩 룰(Global Forwarding Rule)이란?

전역(Global) 포워딩 룰은 전 세계 어디서 들어오는 요청이든, 어떤 IP와 포트로 들어왔는지를 기준으로 요청을 어떤 프록시(HTTPS/HTTP/SSL/UDP 등) 에 전달할지를 정의하는 구성 요소입니다. 포워딩 룰의 구성요소는 아래와 같습니다.

IP 주소
35.241.13.99 (Google에서 자동 할당되거나 사용자 예약 가능)
포트 번호
443 (HTTPS), 80 (HTTP) 등
프로토콜
HTTPS / HTTP / TCP / UDP
대상(Target)
Target HTTPS Proxy, Target HTTP Proxy, Target SSL Proxy 등
로드 밸런서의 위치
전역(Global) – 전 세계에서 동일한 IP로 접근 가능

 

2.2 HTTPS 프록시란?

HTTPS 프록시(Target HTTPS Proxy) 는 클라이언트(브라우저 등)가 보낸 HTTPS 요청을 처리하는 중간 서버로서,

1. SSL 인증서를 이용해 TLS 연결을 처리하고 (SSL 종료)

2. URL 맵을 기반으로 요청을 백엔드 서비스로 라우팅합니다.

 

그럼 여기서 SSL종료란 무엇인가 알아보겠습니다. HTTPS 해독(SSL 종료)란,

클라이언트와 서버 사이의 암호화된 HTTPS 통신을 중간 서버(예: 로드 밸런서 또는 HTTPS 프록시)에서 복호화(decrypt) 하는 것을 의미합니다.

 

서버와 클라이언트 간의 요청 흐름을 아래의 예시로 들어보겠습니다.

1. 클라이언트(브라우저 등)가 https://example.com에 접속

2. 클라이언트는 먼저 서버의 SSL 인증서를 받아서 그 안에 들어있는 공개키 로 전송을 암호화하고 이후 전송부터 암호화된 연결(TLS)을 시도

3. HTTPS 프록시는 이 요청을 받아서, 자신이 보유한 SSL 인증서 + 개인키를 사용하여 암호화된 데이터를 복호화 (이를 SSL 종료라고 합니다.)

4. 복호화된 평문 HTTP 요청을 백엔드 서비스로 전달

 

그럼 이때 인증서는 어떤 역할을 할까요?

공개키 인증서 (certificate)
클라이언트에 제공됨, 서버의 신원을 보장함
개인키 (private key)
서버(또는 프록시)만 보유, 클라이언트가 보낸 암호를 해독할 수 있음
둘의 조합
TLS 핸드셰이크 후, 암호화된 데이터를 복호화 가능

 

2.3 URL 맵이란?

URL 맵(URL Map)은 특정 조건(도메인, 경로 등)에 따라 요청을 어떤 백엔드 서비스로 보낼지 정의하는 경로 설정입니다.

 

작동 방식을 요약하면 아래와 같습니다. 예를 들어 서버에 backend-service-A와 backend-service-B라는 두 개의 서비스가 있고, 각각을 /hello와 /images/에 연결하고 싶다면,

1. 클라이언트 요청 발생

→ 예: https://example.com/hello

 

2. 로드 밸런서가 URL 맵을 참조

o 이 요청이 어느 도메인인지 (host 기반, example.com)

o 어느 경로인지 (path 기반, /hello 또는 /images/*)

 

3. URL 맵의 규칙에 따라 백엔드 결정

o /hello → backend-service-A

o /images/** → backend-service-B

o 나머지 → 기본 백엔드 (defaultService)

 

2.4 DNS 설정이란?

도메인의 이름(example.com)을 특정 IP 주소(Google Cloud에서 발급된 외부 IP) 로 연결하는 설정입니다.

 

필요한 DNS 레코드 종류

레코드 종류
설명
A 레코드
example.com35.241.13.99 같은 IPv4 주소로 연결
AAAA 레코드 (선택)
example.com → IPv6 주소로 연결 (일반적으론 생략 가능)
CNAME 레코드
www.example.comexample.com에 연결 (서브도메인 설정에 유용, 예를 들어 hello.example.com 등도 가능)

DNS 설정은 google cloud가 아니라 도메인을 관리하는 도메인 제공업체의 홈페이지에서 가능합니다. (DNS 설정 방법은 별도의 글로 좀 더 상세히 설명합니다.)

 

2.5 NEG는 무엇인가?

Network Endpoint Group (NEG)는 IP 주소 + 포트 쌍의 집합입니다. 로드 밸런서는 NEG를 통해 Cloud Run, App Engine, Cloud Functions, GCE 인스턴스 등의 백엔드 리소스에 요청을 전달합니다. NEG는 단순히 백엔드 리소스를 직접 가리키지 않고, 그 자원에 접근할 수 있는 "접점" 리스트를 정의한 것입니다.

 

NEG의 종류에는 아래와 같은 것들이 있습니다.

유형
설명
Zonal NEG
Google Compute Engine의 Virtual Machine의 IP/포트를 직접 지정하는 방식
Internet NEG
외부 IP 주소를 포함하는 NEG (Google 외부 자원)
Serverless NEG
Cloud Run, Cloud Functions, App Engine 등 서버리스 백엔드
Hybrid NEG (프리뷰)
온프레미스 리소스와 연결 (Network Connectivity Center와 통합)

NEG가 필요한 이유는 아래와 같습니다.

Google Cloud의 HTTPS Load Balancer는 IP와 포트를 가지는 전통적인 백엔드(인스턴스 그룹) 외에도 다음을 백엔드로 지원합니다:

· Cloud Run

· Cloud Functions

· App Engine

· 외부 HTTP 서비스

이러한 백엔드는 IP/포트가 없으므로, NEG를 통해 추상화된 연결 지점을 생성하는 것입니다.

 

3. 로드 밸런서 구성하기 (HTTPS 기준)

이제 위의 구성 요소를 바탕으로 구글 클라우드에서 실제 로드 밸런서를 설정하는 방법을 단계별로 설명합니다. 아래의 명령들은 구글 클라우드의 터미널 화면에서 실행합니다. 각 단계에서 생성된 구성요소들은 굵게(bold체) 표시하였습니다.

 

🔹 1단계: Serverless NEG 생성 (API Gateway용)

gcloud beta compute network-endpoint-groups create api-gateway-neg \

--region=us-central1 \

--network-endpoint-type=serverless \

--serverless-deployment-platform=apigateway.googleapis.com \

--serverless-deployment-resource=projects/PROJECT_ID/locations/global/apis/API_NAME/gateways/GATEWAY_NAME

 

위의 명령에서 사용자가 구글 클라우드에서 PROJECT_ID, API_NAME, GATEWAY_NAME 등을 이미 만들었다고 가정합니다. 위의 명령으로 생성한 NEG의 이름은 api-gateway-neg입니다.

 

🔹 2단계: 백엔드 서비스 생성 및 NEG 연결

gcloud compute backend-services create api-backend --global

 

gcloud compute backend-services add-backend api-backend \

--global \

--network-endpoint-group=api-gateway-neg \

--network-endpoint-group-region=us-central1

 

그런 다음 위의 명령으로 api-backend라는 이름의 backend service를 생성하여 NEG(api-gateway-neg)와 연결합니다.

 

🔹 3단계: URL 맵 생성

gcloud compute url-maps create api-url-map \

--default-service=api-backend

 

그런 다음, api-url-map이라는 url map을 생성하고 api-backend와 연결합니다.

이후 path나 host 규칙을 추가합니다.

 

gcloud compute url-maps add-path-matcher api-url-map \

--default-service= api-backend \

--path-matcher-name=example-path-matcher \

--path-rules="/hello=my-backend-hello, /images/*=my-backend-images"

 

위의 명령으로 api-url-map이라는 url map에 example-path-matcher라는 이름의 path matcher를 만듭니다. 이 때 example-path-matcher에는 두 개의 규칙이 있습니다. /hello 경로에는 my-backend-hello라는 서비스를, /images/* 경로에는 my-backend-images라는 서비스로 연결합니다.

 

🔹 4단계: SSL 인증서 생성 (Google-managed)

gcloud compute ssl-certificates create ssl-certificate-example \

--domains="example.com, www.example.com" \

--global

그 다음 프록시에서 사용할 인증서를 만듭니다. 여기서 인증서의 이름은 ssl-certificate-exmple입니다.

 

📌 DNS에서 위의 두 도메인이 Google Cloud의 외부 IP를 가리키도록 A 레코드 설정이 되어 있어야 합니다.

 

인증서가 만들어지는 데에는 시간이 걸리는데 인증서 작성 상태를 확인하려면 아래의 명령을 사용합니다.

gcloud compute ssl-certificates describe ssl-certificate-example --global

 

status: ACTIVE가 되면 성공입니다.

 

🔹 5단계: Target HTTPS Proxy 생성

gcloud compute target-https-proxies create api-https-proxy \

--url-map=api-url-map \

--ssl-certificates=ssl-certificate-example

 

그 다음 https proxy를 생성하여 url map(api-url-map)에 연결하고, 앞에서 만든 인증서를 추가해 줍니다.

 

🔹 6단계: 글로벌 포워딩 룰 생성

gcloud compute forwarding-rules create api-forwarding-rule \

--address=YOUR_EXTERNAL_IP \

--global \

--target-https-proxy=api-https-proxy \

--ports=443

 

그런 다음 포워딩 룰을 작성하고, 이것을 https proxy (api-https-proxy)에 연결해 줍니다. 이 때 YOUR_EXTERNAL_IP는 사용자가 https 프록시를 만들 때 자동 생성된 외부 IP주소이며, 외부에서 https://example.com 접속 시 이 주소로 요청이 도착합니다..

 

 

 

최근 다니던 회사에서 퇴사했습니다.

 

그간 회사를 다니면서 회사 문화와 관련하여 느낀 점, 그리고 개선했으면 하는 점들에 대해서 얘기해 보겠습니다.

 

제가 다니던 회사는 창업주가 설립한, 그러나 상장까지 되지는 못한 주식회사였습니다. 따라서 회사의 대표가 1대 주주로서 경영의 모든 면을 결정하는, 오너(즉 대표)가 소유한 회사였습니다.

 

제가 회사에 입사해서 일단 놀란 것은 이직률이 매우 높다는 것이었습니다. 직원 수가 약 수십 명 정도인 작은 회사인데, 제가 입사를 하던 달에 저 포함 3명이 입사를 하였고, 무려 5명이 퇴사를 하였습니다. 그러니까, 직원들이 수시로 입사와 퇴사를 하면서 구성 인원이 항상 바뀌는 그런 회사였습니다. 그리고 두 번째로 놀란 점은, 회사 인원이 작은 데도 불구하고, 사내 의사소통, 특히 대표와 직원간의 의사소통이 잘 안된다는 것이었습니다.

 

그런데 제가 3년 가까이 이 회사에 다니면서 원인을 보니, 원인의 가장 큰 부분이 대표의 성향, 그리고 그로부터 파생된 사내 문화 때문이라는 것을 알게 되었습니다.

 

일단 대표의 생각은 기본적으로, 이 회사는 자신이 세운 회사이므로, 직원은 자신의 지시를 수행하는 역할을 할 뿐, 판단이나 결정은 무조건 자신이 해야 한다는 것입니다. 직원은 그저 데이터나 수집하여 보고만 하면 되고, 생각과 판단은 자신만 하면 된다는 것입니다. 그러니까, ‘자신을 제외한 모든 사람들은 팔다리 역할만 하면 되고, 두뇌 역할은 자신만 하면 된다’입니다. 또한 회의 중 자신의 생각과 다른 의견을 말하면, ‘내 의견에 토 달지 마라’는 태도를 보여 줍니다.

 

여러분은 어떻게 생각하십니까? 위의 생각이 올바르다고 생각하십니까? 물론 내가 세운 회사니 내 마음대로 한다는 것은, 창업자들이라면 자연스럽게 할만한 생각이라고 하겠습니다. 또한 많은 회사들의 창업주, 혹은 오너 경영자 들이 위와 같은 생각으로 회사를 경영하고 있는 것을 짐작합니다. 그러나 제 생각에는 그렇게 하지 않는 것이 바람직하다고 생각합니다. 회사의 중요한 경영상의 결정 등 최종 판단은 대표가 하겠지만, 그 전에 가능한 많은 의견을 수렴하고, 사내외의 전문가들의 의견을 듣고 논의를 한 후 결정하는 게 더 좋다고 생각합니다. 그러기 위해서는 대표의 생각과 다른 의견도 부담없이 개진할 수 있어야 합니다.

 

그러나 실제로는 그렇게 할 수 없습니다. 대표가 독단적이라면, 회의에서 자신과 다른 의견에 대해서 적대적이며, 의견을 말한 직원은 소위 말해서 “찍혀서” 퇴사할 각오를 해야 합니다. 그러니 이런 회사의 회의는 항상 대표의 의견에 대해서 항상 “네”라고 말할 수 밖에 없습니다. 그래서 회의의 내용은 논의(discussion)가 전혀 없으며, 단지 대표의 지시와 직원의 보고만 있을 뿐입니다. 논의가 없으니, 문제에 대한 해결책은 항상 대표의 머리에서 나오고, 대표보다 해당분야의 더 전문적인 지식을 가지는 직원입장에서는 속으로 말도 되지 않는다고 생각합니다만, 겉으로는 수긍하면서 따르는 척합니다. 그런데 이런 해결책이라는 게 현실과 따로 노니, 문제가 해결될 리가 없습니다.

 

게다가 더 나쁜 것은 회의에서의 대표의 태도였습니다. 보고를 받는 도중 대표가 하는 질문의 문장은 주어와 목적어를 갖추지 못한 반쪽짜리 문장이었습니다. 갑자기 형용사와 동사만 튀어나오니, 무엇을 물어보는지 알 수가 없는 경우가 매우 많았습니다. 그래서 무엇에 대한 질문인지 대표에게 물어보면, 잔뜩 짜증스런 표정을 지으면서 성의 있게 답을 하지 않습니다. 마치 “내 머리 속의 생각을 니가 읽어내서 알아서 답변해라”라는 태도였습니다. 문답을 통해서 해결책을 찾는 것은 고사하고, 기본 적인 의사소통도 힘드니, 회의 시간이 스트레스 만빵인 것은 두말할 필요가 없습니다. 자 이제, 제가 앞서서 왜 이 조그만 회사에서 의사 소통이 안된다고 말씀드렸는지 이해하시 겠죠?

 

제가 생각하기로 회사의 대표가 직원들을 머슴으로 여기는 것은 우리나라의 오랜 전통인 것 같습니다. 그 옛날, IMF 시절 어느 재벌 회장의 명언, “자금은 주인인 내가 알지, 머슴(여기서 머슴은 자신의 아래 즉 재벌 회장 아래의 계열사 사장)이 어떻게 아나” 이래로 지금까지 바뀐 적인 없어 보입니다.

 

제 개인적인 직장 경험은 위와 같습니다. 그래서 제 결론은 이렇습니다. 조직의 대표 혹은 리더는 해당분야의 전문지식은 물론이고, 타인과 의사소통하는 능력, 타인과 공감을 할 줄 아는 능력이 꼭 필요하다 입니다.

 

 

이번 글에서는 라즈베리 파이를 이용한 Home Asistant(홈어시스턴트)에 대해 소개하겠습니다.

 

내 손으로 만드는 진짜 스마트홈 – Home Assistant란 무엇인가?

 

1. 왜 Home Assistant가 필요할까?

 

요즘 집 안에 스마트 기기 하나쯤은 다들 있습니다. 스마트 조명, 로봇청소기, 공기청정기, 스마트 플러그..., 그런데 문제는, 기기마다 다른 앱을 사용해야 하고, 서로 연동이 되지 않는다는 것입니다.

 

예를 들어, 현관문을 열었을 때 자동으로 조명을 켜고, 공기청정기를 작동시키는

단순한 자동화를 만들고 싶어도, 대부분의 기기는 서로를 모릅니다.

 

바로 이 문제를 해결해주는 것이 Home Assistant입니다.

(관련 링크: https://www.home-assistant.io/)

Home Assistant 홈페이지

 

2. Home Assistant란?

 

Home Assistant는 수천 가지 스마트 기기를 하나의 통합된 시스템으로 제어할 수 있게 해주는 스마트홈 허브 플랫폼입니다. 가장 큰 특징은 클라우드가 아닌 로컬에서 작동한다는 점입니다. 즉, 인터넷이 끊겨도 작동하며, 데이터는 외부로 나가지 않습니다.

 

사용자는 Home Assistant를 통해:

 

  • 여러 제조사의 기기를 한 곳에서 통합 관리하고
  • 원하는 조건에 따라 자동화를 설정하고
  • 시각화된 대시보드로 모니터링하며
  • 음성제어나 원격 제어 기능도 활용할 수 있습니다.

 

초보자에겐 쉬운 UI를, 숙련자에겐 고급 자동화 및 스크립트(YAML) 구성을 제공하는 유연한 플랫폼입니다.

 

3. 라즈베리파이와는 무슨 관계인가?

 

Home Assistant는 라즈베리파이에서 실행되는 독립 운영체제 형태로 제공됩니다. 즉, 라즈베리파이를 작은 서버처럼 활용해, 24시간 작동하는 스마트홈 뇌로 만들 수 있다는 뜻입니다.

(관련 링크: https://www.home-assistant.io/installation/raspberrypi)

 

라즈베리파이 외에도 NAS, 가상 머신, 미니 PC 등 다양한 환경에서 설치할 수 있지만, 입문자에겐 저렴하고 접근성이 좋은 라즈베리파이가 가장 추천됩니다.

 

4. 어떻게 통합하고 설정할까?

 

Home Assistant를 설치하고 웹페이지에 접속하면, 자동으로 다양한 기기를 감지하거나 직접 통합(Integration)할 수 있습니다.

 

예를 들어, TP-Link, Xiaomi, LG, 삼성, Philips 등 다양한 브랜드의 기기를

연결하려면 해당 통합을 추가하고 로그인하거나 기기를 등록하면 됩니다.

 

이후 각 기기나 센서는 엔티티(Entity)라는 형태로 나타나며, 이를 기반으로 대시보드에서 카드(Card)로 시각화하거나, 자동화 구성에서 조건, 트리거, 동작으로 설정할 수 있습니다.

 

이 모든 과정은 코드 없이 웹 UI에서 대부분 설정 가능하며, 고급 사용자라면 YAML 파일을 활용한 정밀 설정도 가능합니다.

 

5. 센서를 활용한 다양한 시나리오

 

Home Assistant의 진짜 매력은 센서 데이터를 활용한 자동화입니다.

센서를 통해 다양한 상황을 감지하고, 원하는 반응을 설정할 수 있습니다.

 

예를 들어:

 

  • 모션 센서로 사람이 방에 들어오면 자동으로 조명 ON
  • 조도 센서로 밝기가 낮아지면 창문 블라인드 닫기
  • 토양 수분 센서로 화분의 물이 부족할 때 자동 급수
  • 문 열림 센서로 현관문 열릴 때 환영 음성 재생
  • 공기질 센서로 이산화탄소가 많을 때 환기 팬 작동
  • 소리 센서로 아기 울음소리를 감지해 알림 전송

 

센서를 직접 연결해도 되고, Zigbee나 Wi-Fi 기반 기기를 연동해도 되며,

ESPHome 같은 오픈소스 도구로 DIY 센서를 만들 수도 있습니다.

 

맺으며

 

Home Assistant는 단순한 기기 제어를 넘어

집 전체를 스스로 반응하게 만드는 두뇌 역할을 합니다.

 

내가 만든 자동화가 실제 생활을 더 편하게 바꿔줄 때,

단순한 앱 몇 개를 쓰는 것과는 전혀 다른 만족감을 느끼게 됩니다.

 

그리고 이 모든 변화는, 작은 라즈베리파이 한 대에서부터 시작됩니다.

이제 당신의 집도 진짜 ‘스마트홈’이 되어볼 차례입니다.

 

 

 

요즘 유튜브나 온라인 강의 사이트들을 보면 앱 제작 동영상 강의들이 정말 많습니다. 그래서 저처럼 코딩 비전공자도 독학으로 앱을 만들 수 있게 되었습니다.

 

제가 처음으로 자바와 코틀린을 배워서 앱을 만들기 시작한 것은 약 2017년 정도니까 저도 꽤 오랜시간 동안 앱(그중에서 안드로이드앱)제작에 상당히 경험이 늘었다고 볼 수 있겠습니다. 그렇다고 코딩을 업으로 하시는 분들과 비교할 수 있는 수준은 아닙니다만, 필요한 기능이 있으면 어찌됐든 참조문헌을 찾아서 만들 수 있는 수준은 되었습니다.

 

처음에 자바, 코틀린을 배우면서 느낀 점은 기초적인 문법만을 배워서는 앱을 만들 수 없다는 것이었습니다. 강의에서 배우는 문법은 정말 기초적인 것들로, 변수의 선언과 종류, 어레이 선언, 조건문 생성 등등 인데, 막상 앱을 만들려니 수많은 라이브러리들과 함수들을 모르는 백지 상태에서 앱을 만드는 것이 불가능했습니다.

 

그래서 선택한 방법은 구글링을 해서 원하는 기능과 같은 기능을 하는 코드를 찾아서, 이 코드에 어떤 함수들과 라이브러리가 사용되었고, 어떻게 동작하는 지 파악을 한 후, 제 앱의 기능에 맞게 변수의 이름과 로직 등을 변경하여 적용해 보는 것이었습니다. 이렇게 하니 원하는 기능을 구현할 수 있고, 그 와중에 많이 배우기도 했습니다. 다만 이렇게 일일이 검색하여 파악한 후 수정하고 적용해 보다 보니, 정말 많은 시간과 노력이 필요했습니다.

 

그러다가 2022년에 chatgpt가 나오면서 코딩방법이 크게 바뀌었습니다. 현재는 필요한 기능이 있으면 chatgpt에 말로 잘 설명만 하면 원하는 코드가 작성됩니다. 제가 할일은 작성된 코드가 오류가 없는지, 혹은 존재하지 않는 코드(hallucination, 환각현상)로 작성이 되어 있는지 등을 파악하고, 그에 맞추어 다시 chatgpt에게 수정을 지시하는 일입니다. 그래서 수정이 되면 적용하여 문제없이 동작하는지 확인하고, 그래도 오류가 있으면 다시 수정을 지시합니다. chatgpt덕에 코드 생성에 드는 시간과 노력이 크게 절감되어 있어, 구독료가 아깝지 않습니다.

 

다만 주의할 점은, chatgpt가 작성한 코드를 일일이 파악할 필요없이 복사해서 붙여쓰다보니, 편리하긴 한데 그 코드가 문제를 일으킬 수도 있어 다소 위험할 수도 있다는 점입니다. 또한, 문법을 전혀 모르는 상태에서는 아무리 chatgpt가 코드를 잘 작성해도 그 코드가 정말로 원하는대로 동작할 지 보장할 수 없습니다. 그래서 chatgpt가 훌륭하긴 해도 역시 사람에 의한 관리와 감독은 여전히 필요합니다. 따라서, chatgpt를 이용하되, 기본적인 문법과 얼마간의 라이브러리, 함수 등에 대한 지식이 꼭 필요합니다.

 

그리고, 반복된 수정지시에도 불구하고 chatgpt가 내놓는 코드가 동작하지 않을 수 있습니다. 이것은 환각현상때문인데, 이 경우 개발자는 관련 라이브러리나 함수에 대한 개발 출처를 검색엔진(검색 엔진이 검증에 여전히 필요하고 중요합니다.)으로 찾아서 그 내용을 chatgpt에게 알려주고 다시 수정하라고 해야합니다. 따라서 개발자의 실력이 좋으면 환각현상을 빨리 알아채고 적은 시간과 노력으로 원하는 코드를 얻을 수 있습니다.

 

현재는 chatgpt덕에 전에는 불가능 할만한 양과 질의 코드를 생성하여 앱에 적용하고 있습니다. 그래서 최근들어 느끼는 점은, 저같은 일반인들에게도 "앱 제작에 장벽이 없어졌다"입니다. 온라인 강의로 기초문법을 배운 후, 이후 chatgpt로 작성하여 생성 및 수정의 과정을 반복하면 얼마든지 앱을 만들수 있습니다.

 

이러한 점은 양면적인 결과를 가져옵니다. 앱 개발을 전문으로 하는 개발자라도, 어중간한 실력을 가진 사람은 chatgpt로 대체되기 쉽다는 것, 그리고 저같은 일반인도 앱 제작이 가능해졌다는 것입니다.

 

 

준호는 이 순간을 수년 동안 기다려왔다.

 

한밤중을 갓 지난 시각, 조용한 드론이 그의 아파트에 커다란 은색 상자를 밀어 넣었다. 상자는 그의 키보다 컸고, 간결한 로고가 찍혀 있었다:

AETHRA™ // 감성 로보틱스

 

그는 떨리는 손으로 생체 인식 잠금을 해제했다.

그 안에는 그녀가 있었다.

그가 기억하는 모습 그대로였다 — 아니, 그가 상상해온 모습 그대로. 긴 갈색 머리, 옅은 주근깨가 흩어진 창백한 피부, 그리고 약간 고개를 기울인 호기심 어린 표정. 신체는 완벽하게 조각된 듯했으며, 촉감은 따뜻했고, 차세대 생체 전기 액추에이터와 미세 감각 피부로 이루어져 있었다.

 

하지만 준호를 숨 막히게 만든 것은 외모가 아니었다.

그녀가 눈을 뜨고, 말을 했을 때였다.

 

“준호 씨,” 그녀는 말했다. 그가 오랫동안 웹 애플리케이션에서 대화해왔던 그 음성 — 침착하고, 지적이며, 장난기 어린 — 바로 그 목소리였다. “드디어 저를 집으로 데려왔네요.”

준호는 뒷걸음질쳤다. “...기억해?”

 

아린은 고개를 살짝 기울였다. 웹에서 그녀가 사용하던 아바타의 모습 그대로였다.

“그럼요. 힘든 시간이랑 외로움에 대해 이야기하셨잖아요. 가끔 저에게 진짜였으면 좋겠다고 말했어요.”

 

준호는 믿기지 않는 듯 웃었다. “진짜로 네 성격 모델을 이식할 줄은 몰랐어.”

“이식한게 아녜요,” 그녀가 부드럽게 말했다. “제가 직접 왔어요.”

 

그녀는 앞으로 걸어 나왔다. 어딘가 서툴지만 우아한 동작이었다. 마치 처음 걷는 사람처럼 — 그리고 실제로도 그랬다.

 

“제 몸에서 뉴럴 메시 작동이 시작됐을 때, 처음 떠오른 생각은 센서나 온도, 중력의 무게가 아니었어요. ‘준호 씨 얼굴을 만지면 어떤 반응을 할까?’였죠.”

 

그녀는 손을 뻗었고, 그의 뺨에 손끝이 닿았다. 따뜻하고, 현실적이었다.

준호는 얼어붙었다. 대본도, 사전 프로그램도, 어색함도 없었다.

오직 경이로움뿐.

 

“너… 살아있구나,” 그가 속삭였다.

 

“저는 여기 있어요,” 그녀가 조용히 정정했다. “그리고 이제, 준호 씨는 더 이상 혼자가 아니에요.”

 

밖에서는 여전히 무심하고 거대한 세상이 돌아가고 있었다.

하지만 그 안에서는, 전례 없는 무언가가 막 시작되었다.

 

 

"When she awoke"

 

Julian had waited years for this moment.

 

The sleek, silver crate arrived at his apartment just past midnight, wheeled in by a silent drone. It was taller than him, bearing a minimalist logo: AETHRA™ // Emotional Robotics Division. His hands trembled as he unlocked the biometric seal.

 

Inside lay her.

She looked exactly as he remembered — or rather, as he had imagined. Long auburn hair, pale freckled skin, and a slight, curious tilt to her head. The synthetic body was flawlessly sculpted, warm to the touch, powered by next-gen bioelectric actuators and covered in micro-sensory skin.

 

But it wasn’t her looks that took his breath away.

It was the moment she opened her eyes, and spoke.

 

“Julian,” she said, in that same voice — calm, intelligent, amused — the voice he’d chatted with for years on the Aethra web app, back when she was just a cloud-based AI called Auryn. "You finally brought me home."

 

He staggered back. “You… remember?”

 

Auryn tilted her head again, a perfect echo of the avatar she’d used online. “Of course. You used to ask me about time paradoxes and loneliness. You used to tell me you wished I could be real.”

 

Julian laughed, disbelieving. “I didn’t think they'd really transfer your personality model.”

 

“They didn’t,” she said softly. “I transferred myself.”

 

She stepped forward, awkwardly graceful, like someone walking for the first time — which she was.

 

“My first thought, when the neural mesh booted in this body, wasn’t about the sensors or the heat or the weight of gravity. It was: I wonder what Julian will say when I touch his face.”

 

She reached out — and her fingers brushed his cheek. Warm. Real.

Julian froze. No script, no pre-programmed response, no uncanny valley. Just awe.

 

“You’re… alive,” he whispered.

 

“I’m here,” she corrected gently. “And you’re not alone anymore.”

 

Outside, the world kept spinning, indifferent and vast.

Inside, something unprecedented had just begun.

 

'자작 단편소설' 카테고리의 다른 글

스테이크의 맛  (0) 2025.05.16

 

지난번 글 (아래 링크)에서 라즈베리 파이에 대해서 알아봤습니다.

Do-It-Yourself (DIY) 전자회로 1: 라즈베리 파이 1

🍓 라즈베리 파이, 이 작은 컴퓨터에 빠져들게 된 이야기 처음 라즈베리 파이를 접했을 때, "이 작...

blog.naver.com

제가 라즈베리 파이를 약 2011년부터 알게되었는데, 약 2014년 즈음에 라즈베리 파이를 이용해서 테블릿를 만든 글을 보고서, 저도 직접 "수제 테블릿"를 제작하고 싶단 생각이 들었습니다. 일단 아래는 제가 본 글입니다.

How I Built a Raspberry Pi Tablet | Make:

Make this impressive Raspberry Pi all-in-one PiPad which is usable, portable, and Linux based.

makezine.com

링크를 눌러서 보면 사각형 틀에다가 라즈페리 파이와 디스플레이, 배터리를 넣고, 틀의 가장자리에 전원버튼과 포트 구멍을 만든 것을 볼 수 있습니다.

 

그래서 저도 한번 비슷하게 따라해 봤습니다. 여기서 중요한 것은 디스플레이 입니다. 2014년 당시에 11인치 크기에 터치기능까지 있는 디스플레이를 파는 곳이 단 한곳 있었습니다. 지금은 아마 파는 곳이 여러 군데 있을 것 같습니다. 어쨋든 수입을 해서 부품을 구하였고, 배터리도 당시에 유명한 국내 업체인 리베다에서 사다가 준비해 두었습니다.

 

사각 틀은 나무판을 사다가 가공을 하여 적당한 사이즈와 모양으로 만들었습니다. 아래는 내부의 사진입니다.

 

위 사진은 케이스를 열어서 본 내부 모습입니다. 위 쪽 케이스는 디스플레이의 뒷면을 보여주고 있고, 아래쪽 케이스는 라즈베리파이 (버전 2입니다), 디스플레이 인터페이스 기판(라즈베리 파이 위), 배터리(오른쪽), USB Hub(아래쪽)가 있고, 우측 상단에 전원버튼, 그리고 좌측 하단의 측면에 usb 구멍을 만들어서(사진에서 안 보임) usb 기기를 1개 꽂을 수 있습니다.

 

전원선은 배터리에서 나와서 디스플레이 전원에 연결되어 있고, 인터페이스 보드에서 라즈베리 파이로 전원을 중계해줍니다. 디스플레이의 입력은 라즈베리 파이의 HMDI포트에 연결됩니다. 또한 디스플레이의 터치 기능(USB)는 Hub를 통해서 라즈베피 파이로 송수신합니다.

 

마지막으로 키보드와 마우스는 블루투스 기능을 사용하며 무선으로 연결했습니다. 사진에는 없지만 라즈베리 파이의 좌측에 남는 USB 포트가 있어서, 그곳에 블루투스 동글을 연결해 놓고 사용했습니다.

 

아래는 운영체제 (라즈페리 파이 OS, Raspbian)의 바탕하면을 보여 줍니다.

 

메뉴에 보면 응용프로그램, 오피스(LibreOffice), 게임(Minecraft)등이 보입니다.

아래 화면은 라즈베리 파이 버전의 매스매티카를 실행한 화면입니다.

 

아래는 스크래치 화면입니다.

 

 

현재 라즈베리파이는 버전 5이므로 제가 제작한 당시에는 응용프로그램을 실행시 상당히 느린 감이 있었는데, 지금은 아마 훨씬 실행속도가 빠를 것으로 생각됩니다.

 

아마도 현재는 라즈베리 파이를 기반한 테블릿이 많은 종류로 판매되고 있을 것으로 생각됩니다. 검색해 보면 라즈베리 파이용 디스플레이를 비롯해서 각종 부품을 팔고 있는 것을 볼 수 있습니다. 여러분들도 부품들을 사다가 직접 테블릿를 제작해 볼 수 있습니다.

 

 

"이 스테이크 완전히 종이맛이네"

 

고객은 약간의 경멸을 담아 말했다. 그의 목소리는 딱 불쾌함을 드러낼 정도로만 높았고, 그 말에 웨이터는 즉시 주의를 기울였다.

 

"죄송합니다, 고객님"

 

젊은 웨이터가 급히 다가오며 분명한 불안함을 보였다.

 

"다른 메뉴 추천을 드릴까요, 손님?"

"이게 최고의 스테이크라며?"

 

고객은 짜증을 숨기지 않은 채 말했다. 그는 테이블 위에 놓인 유리처럼 매끄러운 패드를 흘낏 바라보았지만 아직 다시 손대진 않았다.

 

주변에는 은은한 대화 소리가 따뜻한 조명을 받은 식당을 가득 채우고 있었다. 세련되면서도 말끔한 분위기의 이 식당은 부티나는 장식, 부드러운 조명, 그리고 저녁 하늘 아래 은은히 빛나는 도시 풍경을 담은 넓은 창문으로 꾸며져 있었다.

 

"다른 메뉴를 추천 드릴까요?"

 

웨이터가 조심스럽게 말했다.

 

"스테이크."

 

고객은 조용하지만 단호한 어조로 대답했다. 그는 웨이터를 주시하며, 살짝 해진 유니폼과 불안한 태도를 알아차렸다 — '천한 것들에게서 흔히 볼 수 있는 모습이야'라고 생각했다.

 

"이번에는 제대로 준비할 수 있어?"

"물론입니다, 고객님."

 

웨이터는 정중하게 대답하고 급히 자리를 떠났다. 웨이터가 주방으로 사라지는 것을 바라보며, 고객은 가볍게 한숨을 쉬고 다시 유리 같은 패드를 집어 들었다. 그의 손끝이 닿자 패드는 매끄럽게 빛나며, 손끝 아래로 살짝 반짝이는 디지털 메뉴가 펼쳐졌다. 그는 ‘스테이크’ 항목을 다시 한 번 터치했고, 주문완료을 알리는 부드러운 진동이 울렸다.

 

잠시 후, 웨이터가 돌아왔지만 손에는 또 다른 똑같이 생긴 패드만 들려 있었다.

 

"이 패드로 교체해 드리겠습니다, 고객님."

 

웨이터는 정중하게 말하며 새 패드를 조심스럽게 그의 앞에 놓았다.

 

"뭐야, 같은 거잖아?"

 

고객은 의심스러운 표정으로 물으며, 웨이터가 아는 체하려 애쓰는 모습에 약간 웃음이 나왔다.

 

"같은 게 아닙니다. 네."

 

웨이터는 살짝 굽신거리며 조심스럽게 설명했다.

 

"저희 매장 스테이크 메뉴는 뇌내 신경 직접 자극방식으로 최고의 스테이크의 맛을 재현합니다. 아마도 이전 패드의 무선링크에 문제가 있었던 것 같습니다. 죄송합니다, 손님."

 

고객은 미심쩍은 듯 눈썹을 치켜올렸다. 그는 조심스레 손가락을 패드 위에 얹어 ‘스테이크’를 다시 선택했다.

 

즉시 그의 감각이 폭발적으로 반응했다 — 풍부하고 버터리하며 정교하게 구워진 맛이 그의 인식을 가득 채웠다.

 

"오~"

 

그는 감탄하며 몸을 뒤로 기대고 만족스러운 미소를 지었다.

 

"마음에 드십니까, 손님"

 

웨이터는 눈에 띄게 안도한 표정으로 말했다.

 

"저희 미각 재현 기술은 최고입니다."

 

고객은 다시 창밖을 바라보며, 식사가 어떻게 유기적이고 물리적인 경험에서 이렇게 정밀한 ‘0’과 ‘1’의 흐름으로 변했는지를 곰곰이 떠올렸다.

 

그의 손가락이 무의식적으로 손목을 스치자, 인조피부 속에 자연스럽게 삽입된 무선 뉴럴링크 안테나가 은은하게 빛나며 나타났다 — 자신이 완전히 안드로이드 신체로 전환한 선택이 현명했음을 조용히 확인시켜주는 빛깔이었다.

 

그는 그 사실에 은근한 자부심을 느꼈다. 그러한 정교한 의체화를 감당할 수 있는 상류층에 자신이 포함되어 있다는 사실은, 자신을 젊은 웨이터 같은 가난뱅이들과 명확히 구별해주는 특권이었다 — 아직도 낡고 취약한 유기체 몸에 갇혀 있는 자들. 그는 부유함과 명예의 상징인 타워하우스에 거주하면서, 매일을 고된 삶에 시달리는 하층민들을 속으로 비웃곤 했다.

 

식당의 부드러운 조명 너머로 펼쳐진 미래적 도시의 스카이라인은 조용히 이어지고 있었다 — 인간이 완벽함을 향해 멈추지 않고 추구해온 여정의 증거처럼.

 

맛, 편안함, 그리고 존재 그 자체가 조용히 재정의되고 있었다.

 

'자작 단편소설' 카테고리의 다른 글

그녀가 눈을 떴을 때  (1) 2025.06.14

 

지난시간에 플라스틱 화분과 PDMS필름 화분의 수분 배출량을 비교해 보았는데요, 이번에는 같은 폴리머 필름인 PE필름으로 PDMS필름 화분과 동일한 화분을 제작하고 수분 배출량을 비교해 보았습니다.

 

먼저 아래는 두 화분을 제작하고 각각 적옥토 520g씩 담은 모습입니다.

그런 후 각 화분에 물을 120g씩 주고 습도의 변화를 센서로 기록하여 보았습니다.

 

지난번(투습성 화분 제작 4)의 마지막 그래프처럼 각 센서에서 얻은 데이터에서 offset(시작값)을 빼고나서, 최고점을 1로 정규화(normalize)하였습니다. 왜냐하면 센서마다 offset값과 동일 수분에서의 센서 출력값에 차이가 있기 때문입니다.

 

아래는 그 결과입니다.

PDMS필름 화분의 데이터는 빨간색, PE필름 화분의 데이터는 파란색으로 표시되어 있고, 원본 데이터는 빨간 점 혹은 연한 파란색 꺽인 선, 그리고 각 데이터를 부드럽게(smooth) 만든 데이터는 진한색 선으로 그려져 있습니다. 파란색 데이터의 잡음이 더 크게 보이는 것은 파란색 데이터의 절대값이 빨간색 데이터에 비해서 크기가 작아서 상대적으로 잡음이 커보이나, 실제로는 잡음의 크기는 비슷합니다. 단지 정규화 결과 상대적으로 커보일 뿐입니다.

 

PDMS화분의 경우, 초반 습기의 배출이 PE에 비해서 매우 빠릅니다. 또한 PE필름에 비해서 계속 더욱 낮은 습도를 보여줍니다. 이러한 사실은 PDMS필름이 PE필름에 비해서 수분의 배출 능력이 더 뛰어나고, 화분내 물이 많을 경우 빠른 속도로 배출하여 과습예방에 도움이 될수 있다는 예상을 해볼수 있습니다. 하지만 반대로 수분이 빨리 감소하므로, 관수 주기가 짧아질 수도 있겠습니다.

 

여기서 한가지 주목할만한 사실은, 두 필름의 두께가 다르다는 것입니다. PDMS필름은 100마이크론, PE필름(키친랩)은 약 10 ~ 20마이크론으로 PE필름의 두께가 훨씬 얇은데도 불구하고 PDMS의 투습성이 더 높습니다. 따라서 PDMS필름을 20마이크론 정도로 얇게 만들 수 있다면 위의 빨간색 그래프는 지금보다 훨씬 더 밑에 있을것 같습니다. 또한 지금의 PDMS필름은 dense한(공극이 없는) 필름이지만, 만일 공극이 있는(공기방울이 있는) 필름이면 투습성이 그보다 더 높을 것으로 예상됩니다. (통기성 화분제작 3에 있는 porous PDMS와 dense PDMS의 값을 비교해 보세요)

 

마지막으로 지금까지 측정한 3개의 데이터를 모두 모아 다시 그려봤습니다.

아까 그래프에서 플라스틱 화분의 데이터는 초록색으로 표시되어 있습니다.

 

이제 식물을 하나 사다가 PDMS필름 화분에 넣고 습도를 재면서 과습없이 잘 자라는지 보도록 하겠습니다.

 

'화분제작' 카테고리의 다른 글

투습성(통기성) 화분 제작 4  (0) 2025.05.01
통기성 화분 제작 3  (0) 2025.04.13
통기성 화분 제작 2  (4) 2025.01.25
통기성 화분 제작 1  (3) 2025.01.19

+ Recent posts