개발 on kenji.blog

'LogicPad 개발 비화'

Wed, 30 Jul 2025 23:51:35 +0900

「코드 작성은 못하지만 논리는 있는 사람」을 위한 도구. LogicPad를 만든 이유

안녕하세요, kenji입니다. 로우코드 도구 ‘LogicPad‘를 만든 개발자입니다. 이번에는 제품 소개가 아니라, “왜 이것을 만들려고 생각했는가?“라는 개발의 이면, 그리고 제 자신의 생각에 대해 조금 개인적인 관점에서 써보려고 합니다.

솔직히, 이것은 단순한 도구 개발이 아니었습니다. 제 과거, 직장에서의 답답함, 스킬셋, 그리고 계속 가슴속에 품고 있던 “언젠가 내 제품을 만들고 싶다"는 마음―― 그 모든 것이 겹쳐진 결과로 탄생한 것이 LogicPad입니다.

즉, 이것은 저에게 “인생의 집대성 프로젝트” 이기도 합니다. 그런 배경을 가능한 한 솔직하게, 열정을 담아 써내려가 보겠습니다.

솔직하게 “이것은 내가 만들었다"라고 가슴을 펴고 말할 수 있는 제품이 갖고 싶었다

솔직히 말하자면, 이것이 가장 첫 번째 동기였습니다.

예전부터 일로나 취미로나 코드 짜는 것을 좋아했습니다. 여러 개발에도 참여해왔습니다. 하지만 어느 날 문득 깨달았습니다. “내 이름으로, 내 책임으로 세상에 내놓은 제품이 없다” 는 것을요.

물론 팀으로 만드는 것에는 가치가 있고, 자랑스러운 일도 많이 있었습니다. 하지만 어딘가에서 “이대로 누군가의 이름 아래서 커리어를 끝내는 걸까"라는 허무함도 있었습니다.

한 번이라도 좋습니다. “이것은 내가 만들었다"라고 당당하게 말할 수 있는 것을 남기고 싶었습니다. 그렇게 생각해서 LogicPad의 구상을 다듬기 시작했습니다. 지금으로부터 약 6년 전(2019년경)의 일입니다. (원래의 아이디어 자체는 언리얼 엔진의 비주얼 프로그래밍 언어인 블루프린트를 알게 된 2015년쯤 전의 일입니다.)

코드를 쓸 수 없어서 손을 댈 수 없다. 그거 너무 아깝지 않나요?

제 직장에는 우수한 사람이 많았습니다.

논리는 짤 수 있습니다. Excel 함수도 자유자재로 다루고, 문제의 본질도 간파할 수 있습니다. 하지만―― ‘코드를 작성한다’는 단계에서 손이 멈춰버립니다.

“이 작업, 매번 매뉴얼을 보면서 하고 있는데, 자동화할 수 없을까요?” “응, 할 수 있어. 하지만… 그러려면 코드를 써야 해…”

그런 대화가 여러 번 있었습니다.

저는 그때마다 생각했습니다. “논리는 아는데, 코드라는 장벽에 막혀버리는 것은 정말로 아깝다"고.

로우코드 에디터라는 선택지

사실 이전 직장에서는 GUI 조작으로 움직이는 2차원 CAD를 개발하고 있었습니다. CAD란 마우스를 사용해 도형을 조립해 나가는 거잖아요. 즉, “조작으로 논리를 조립해 나간다” 는 세계관입니다.

“이거, 로우코드랑 엄청 궁합이 좋겠다"라고 생각했습니다.

더 거슬러 올라가면, 학생 시절부터 계속 화상 처리나 수치 처리, Windows 도구, SNS 자동 게시 도구 등, 생각나면 바로 코드를 짜서 작은 프로그램을 양산하고 있었습니다. 600개 이상은 될 거라고 생각합니다. 지금도 GitHub에 남아있습니다.

당시에는 의미 따위는 생각하지 않았습니다. 그저 “만들고 싶으니까 만든다”. 그것뿐이었습니다.

하지만 지금, LogicPad를 만들고 있으니…

마치, 점과 점이 선으로 연결된 것 같았습니다.

사용하기 쉽지만 강력하다. 밸런스의 어려움

개발을 진행하면서 계속 생각했던 것이 “직관적으로 사용할 수 있으면서도 제대로 강력한 도구로 만든다” 는 것.

기능을 추가하면 할 수 있는 것은 늘어납니다. 하지만 사용하기 어려워집니다. 단순하게 만들면 누구나 다룰 수 있습니다. 하지만 그러면 부족함을 느끼는 사람도 생깁니다.

“로우코드 도구는 장난감이지?“라는 말을 듣지 않도록. 그렇지만 “결국 코드를 작성하지 않으면 안 되잖아"라는 말도 듣지 않도록.

직관과 표현력, 그 아슬아슬한 선에서 계속 싸우고 있었습니다.

몇 번이나 UI를 다시 만들고, 몇 번이나 버리고, 그리고 마침내 “이거라면 괜찮겠다"라고 생각되는 형태에 가까워졌을 때는, 정말 기뻤습니다.

처음으로 ‘사용자’의 한마디에 구원받았다

처음 LogicPad를 건네준 사람은 전 동료였습니다. IT는 서툴고, 코드도 무서워합니다. 하지만 논리는 잘합니다.

조금 설명하고 만져보게 하고… 몇 분 뒤에 했던 한마디를 지금도 잊을 수 없습니다.

“이거라면 나라도 할 수 있을 것 같아!”

정말로 눈물이 날 것 같았습니다. 제가 주고 싶었던 것은 바로 이거였다고.

움직이는 도구가 아니라, “스스로 만들 수 있었다!“는 감각. 그것이야말로 LogicPad의 진정한 가치라고 확신했습니다.

만들 수 있는 사람이 늘어나면, 사회는 더욱 재미있어진다

저는 ‘기술의 민주화’가 정말로 중요하다고 생각합니다.

기술에는 세상을 바꿀 힘이 있습니다. 하지만 그것을 다룰 수 있는 사람은 한정되어 있습니다.

만약 ‘논리를 안다’는 것만으로 앱을 만들 수 있다면?

더 많은 사람이 ‘만드는 쪽’으로 넘어올 수 있게 됩니다. 그리고 그곳에서 탄생하는 것은 지금의 상상을 뛰어넘을 것이라고 생각합니다.

LogicPad가 그 입구가 될 수 있다면. “만들어보고 싶다"를 “만들 수 있다"로 바꾸는 도구이고 싶습니다.

그것이 저의 바람입니다.

마치며

LogicPad는 아직 베타 버전으로 완성되지 않았습니다. 개선점도, 하고 싶은 일도 아직 산더미처럼 있습니다.

하지만 저는 이 도구에 제 인생의 “점"을 전부 쏟아붓고 있습니다. 지금이라면 가슴을 펴고 말할 수 있습니다.

“이것은 내가 만든 제품이다” 라고.

👇 덤: LogicPad로 할 수 있는 일

드래그 앤 드롭으로 처리 구축
조건 분기나 변수 등도 GUI로 다룰 수 있음
다양한 AI 연동 노드 준비
스크립트 삽입으로 상급자용 확장도 가능
고정밀 수학 함수·데이터 처리 (무한 자릿수 정밀도의 수치 연산 등)
상급자를 위한 단축키도 충실
90개국 이상의 언어 지원

앞으로 하고 싶은 일

AI와 연동하여 자연어에서 논리를 생성
사용자가 커스텀 노드를 생성할 수 있는 구조
작성한 노드나 논리를 공유할 수 있는 플랫폼 구축

✍️ 후기

여기까지 읽어주셔서 정말 감사합니다. 이것은 단순한 도구 개발이 아니라, 제 자신의 경험, 열정, 인생의 파편을 쏟아부은 하나의 도전이었습니다.

“코드는 못 짜지만, 논리는 있다” 그런 사람들이 자신의 힘으로 “만들 수 있게” 되는 미래. 그것을 앞으로도 LogicPad를 통해 지향해 나가고 싶습니다.

만약 조금이라도 “사용해보고 싶다"고 생각해 주셨다면, 그것만으로도 매우 기쁩니다. 흥미가 생기신 분은 꼭 LogicPad를 시험해 보세요.

그리고 사용해본 소감이나 깨달은 점이 있다면 어떤 사소한 것이라도 좋습니다. 당신의 목소리가 이 제품의 다음 한 걸음을 만드는 큰 힘이 됩니다.

앞으로도 잘 부탁드립니다.

'AI 개발의 벽'

Sun, 20 Jul 2025 21:52:42 +0900

AI 개발의 벽

〜8부 능선까지 왔지만, 거기서부터가 지옥이었던 이야기〜

안녕하세요, kenji입니다.

최근 “AI에게 부탁했더니 앱을 만들어줬어!“라는 이야기를 엄청 자주 듣게 되었습니다. 노코드나 로우코드의 시대를 넘어, “바이브 코딩(분위기로 코드를 작성하는 것)” 같은 단계에 돌입하고 있습니다.

예를 들어, “이미지를 가공해서 SNS에 게시할 수 있는 앱 만들어줘"라고 하면, AI가 코드와 UI까지 뱉어냅니다. 대단해, 이제 사람은 필요 없는 거 아냐? 하고 생각하게 되잖아요.

하지만 말이죠, 그건 후지산의 8부 능선에 샌들을 신고 내리는 것과 같은 것 입니다.

8부 능선까지는 “식은 죽 먹기"로 보인다

AI를 통한 개발은 처음에는 정말 편합니다. 파일 IO? 일단 작동함. 네트워크? 뭐 연결됨. 데이터베이스? JSON이면 되겠지. UI? ChatGPT가 React 코드를 뱉어줬고. 결제? Stripe API 정도 복붙하면 됨.

여기서 “나, 이미 엔지니어 아닐까?“하고 착각하게 됩니다. 하지만 진짜 지옥은 여기서부터 시작됩니다.

왜 막히는 걸까?

이유는 간단한데, “AI는 그럴싸하게 만들지만, 최종 조정은 사람에게 통째로 맡기기” 때문입니다.

파일 IO에서 데이터가 날아감
DB 정규화가 어설퍼서 검색이 느림
UI가 직관적이지 않음
부하 테스트를 안 해서 접속이 몰리면 크래시
Apple/Google 심사에서 리젝(거절) 당함
법적 요건에 걸려서 염상(비난 쇄도)할 뻔함

즉, AI는 “겉보기에는 완성된 것 같은 프로토타입"을 만드는 것은 잘하지만, “실제로 세상에 내놓고 통용되는 프로덕트"로 마무리하는 것은, 지금도 여전히 사람의 일 입니다.

하지만, 역설이 있다

여기서 하나의 역설 을 깨닫게 됩니다.

장래에 AI가 정말로 전부 다 할 수 있게 된다면? 즉, “보안도, 결제도, 설계도 전부 AI가 완벽하게 처리해 주게” 된다면?

그때는, 인류가 앱을 만들 필요 자체가 없어질 지도 모릅니다.

왜냐하면, 사용자가 AI에게 직접 “이런 걸 하고 싶어"라고 말하면, 앱 없이 즉시 작업이 실행될 것이기 때문입니다.

🌀예를 들어

옛날에는 “계산을 하기 위해 계산기 앱을 실행"했었지만, 지금은 “Hey Siri, 12×32는?“이라고 말하면 끝납니다.

마찬가지로, “AI야, 사진을 가공해서 공유해 줘"라고 말하면, 앱의 UI나 API를 거치지 않고 처리 작업이 끝나 있을지도 모릅니다.

즉, “AI로 앱을 만든다"라는 목표가 실현되었을 때, 앱 자체가 필요 없는 세상이 올 지도 모른다는 것입니다.

결국, 지금 우리가 할 수 있는 일

그럼, 어떻게 하면 될까요.

지금은 아직 “8부 능선 위"가 사람의 영역이므로, 그곳을 갈고닦는다
본질적인 사용자 이해나 서비스 설계에 집중한다
“만들 수 있는 것"보다 “가치 있는 것"을 생각한다
오히려, “앱이라는 형식에 얽매이지 않는” 가치 제공의 방식을 모색한다

AI는 도구이며, 리프트이고, 때로는 경쟁자입니다. 하지만, “무엇을 만들 것인가"나 “왜 만드는가"는, 아직 우리 인간의 질문으로 남아 있습니다.

요약：

AI 개발의 벽이란, 기술이 아니라 구조의 역설이다

후지산의 8부 능선까지 누구나 갈 수 있는 시대. 하지만 거기서부터가 진짜 실전.

그리고, 산 정상에 다 올랐을 무렵에는, “산, 오를 필요가 있었나?“라고 다시 묻게 되는 미래가 기다리고 있을지도 모릅니다.

'마켓 인과 프로덕트 아웃'

Tue, 15 Jul 2025 20:18:22 +0900

마켓 인과 프로덕트 아웃

안녕하세요, kenji입니다.

가끔 비즈니스 서적이나 기획서 등에서,

“저희는 마켓 인 전략입니다” “이것은 프로덕트 아웃 형이네요”

같은 말을 하는 것을 보게 되는데요…….

아니, 마켓 인? 프로덕트 아웃? 어느 쪽이 더 대단한 건데???

라고 생각하게 되지 않나요?

그래서 이번에는 이 ‘마켓 인’과 ‘프로덕트 아웃’이라는 것에 대해, 최대한 알기 쉽게 풀어서, 조금은 신랄하게 살펴보려고 합니다.

간단히 말하자면…

마켓 인: 시장(마켓)의 소리를 듣고, 그에 맞춰 상품을 만든다
프로덕트 아웃: 자신들이 좋다고 생각하는 것(프로덕트)을 만들어, 세상에 내놓는다

이게 전부입니다. 심플하죠.

예를 들어 라면 가게로 치면…

마켓 인 방식의 라면 가게는, “요즘은 이에케 라면이 유행이네. 좋아, 지방과 마늘 듬뿍 가자!“라는 느낌.

프로덕트 아웃 방식의 라면 가게는, “내가 만든 이 두유 바질 소금 라면, 진짜 최고니까 먹어봐"라는 느낌입니다.

어느 쪽이 정답이냐면… 둘 다 정답입니다

마켓 인은 고객의 니즈에 맞추기 때문에 ‘팔릴 확률이 높지만’, 특출난 아이디어나 브레이크스루(돌파구)는 태어나기 어렵습니다.

프로덕트 아웃은 ‘자신들이 믿는 정의를 형태화’하기 때문에 뾰족하고 매력적이지만, 어긋나면 아무에게도 울림을 주지 못합니다.

iPhone은 프로덕트 아웃 느낌

“스마트폰 따윈 필요 없어"라고 말하던 시대에, iPhone을 출시한 Apple.

이것은 그야말로, 완전한 프로덕트 아웃 의 성공 사례입니다.

사용자의 목소리를 들었다면, “키보드 없는 휴대폰? 무리무리"라는 말을 듣고 끝났을 겁니다.

하지만 프로덕트 아웃은 ‘자기만족’이 되기 쉽다

가끔, “우리는 프로덕트 아웃 형이니까"라고 말하는 기업이나 사람이 있는데,

아니, 그건 그냥 사용자 무시 아닌가?

라고 생각할 때도 있습니다.

“만들고 싶어서 만들었다. 하지만 팔리지 않았다"는, 프로덕트 아웃이 아니라 ‘독단적 아웃’인 거죠.

마켓 인에도 함정은 있다

한편으로, 마켓 인 역시 만능은 아니어서.

“사용자가 원하니까 다 할게요!“라고 말하다 보면, 프로덕트의 중심이 흔들려, 결국 아무에게도 꽂히지 않는 경우도 있습니다.

점점 기능을 추가하다가, 정신 차려보니 카오스 같은 툴이 되어 있는, 그런 거 말이죠.

정말 대단한 것은, ‘둘 다 하는 사람’

대단한 프로덕트는, ‘사용자가 정말로 원했지만, 언어화하지 못했던 것’을, 딱 짚어서 제시해 주거든요.

즉, ‘프로덕트 아웃의 발상으로, 마켓 인적인 공감을 얻는다’는 것.

이거, 쉽게 말하지만 엄청나게 어렵습니다. 하지만, 이것이 가능해지면 단숨에 ‘신급 프로덕트’가 됩니다.

결론: 말보다, 사용자의 반응이 전부

마켓 인인가, 프로덕트 아웃인가. 어느 쪽이 옳은지 같은 건, 별로 의미 없는 질문이라.

“사용자의 마음에 제대로 닿고 있는가?“가 전부 라고 생각합니다.

“어느 쪽에 가까운 전략으로 하고 있습니다” 같은 건, 나중에 마케팅 자료에 쓸 수 있으면 그걸로 족하지 않나, 정도로 생각하고 있습니다.

그래서, 마켓 인과 프로덕트 아웃 이야기였습니다!

이상한 가로쓰기 말(외래어)에 현혹되지 않고, “결국 어떻게 하면 사람들이 기뻐할까?“를 생각해 나가는 것이, 가장 건전하지 않나 싶습니다.

그럼 이만～.

'Gemini CLI를 Windows 환경에 설치하는 방법'

Sun, 13 Jul 2025 23:49:56 +0900

【초보자용】 Windows에 Gemini CLI를 설치하는 방법

Google의 생성형 AI ‘Gemini’를 커맨드라인에서 사용할 수 있게 해주는 ‘Gemini CLI’. 이 글에서는 Windows 환경에 Gemini CLI를 설치하는 과정을 최대한 알기 쉽게 설명합니다.

1. 사전 준비: Node.js 및 npm 설치

먼저, Gemini CLI는 ‘Node.js’라는 환경에서 작동하므로 다음 항목들을 설치해야 합니다.

Node.js
npm (Node.js에 포함된 패키지 관리 도구)
npx (npm에 포함된 명령어 실행 도구)

아래의 공식 웹사이트에서 Windows용 Node.js를 다운로드하세요 (LTS 버전을 권장합니다):

👉 Node.js 공식 웹사이트

설치가 완료되면 다음 명령어로 제대로 설치되었는지 확인해 봅시다.

1
2


node -v
npm -v

2. PowerShell 실행하기

Windows에서 Gemini CLI를 사용하려면 PowerShell을 이용해 조작하는 것이 일반적입니다. 시작 메뉴에서 ‘PowerShell’을 입력하여 실행하세요.

3. Gemini CLI 설치하기

아래 명령어를 PowerShell에 복사하여 붙여넣고 실행합니다:

1

npx @google/gemini-cli

이 명령어는 Google이 공개한 Gemini CLI 패키지를 임시로 실행하기 위한 것입니다. 필요에 따라 초기 설정이나 로그인이 요구될 수도 있습니다.

※ 처음에는 몇 분 정도 걸릴 수 있습니다. 오류가 발생할 경우 Node.js나 네트워크 환경을 다시 확인해 보세요.

4. 설치 완료! 다음으로 할 일

이것으로 Windows에 Gemini CLI가 설치되었습니다. 앞으로는 커맨드라인에서 Gemini를 사용하여 텍스트 생성이나 코드 완성 등 다양한 작업이 가능해집니다.

공식 문서나 도움말을 확인하고 싶다면 아래와 같은 명령어도 활용할 수 있습니다.

1

npx @google/gemini-cli --help

마무리

Windows에 Gemini CLI를 도입하는 과정을 복습해 보겠습니다.

Node.js 및 npm 설치
PowerShell 실행
npx @google/gemini-cli 실행

이것으로 준비 완료입니다! 생성형 AI를 로컬에서 사용하고 싶은 분은 이 과정을 참고하여 도전해 보세요.

Win32API + C++로 프로그램을 만드는 장점과 단점

Sat, 12 Jul 2025 12:30:35 +0900

Win32API + C++로 개발하는 매력과 과제

Windows 앱 개발을 끝까지 파고들고 싶은 사람에게, Win32API + C++ 은 여전히 강력한 선택지입니다. OS와 가장 가까운 거리에서 상호 작용할 수 있는 이 조합은 고속성과 유연성을 겸비하고 있습니다.

반면에 현대의 개발 스타일과는 크게 다르기 때문에 습득에는 각오도 필요합니다.

이 페이지에서는 현직 Windows 앱 개발자의 관점 에서 그 장점과 단점을 알기 쉽게 해설합니다.

장점

초고속 네이티브 실행

C++와 Win32API는 OS에 가장 가까운 레이어에서 동작하기 때문에 불필요한 오버헤드가 거의 없습니다. CPU나 메모리 사용 효율이 매우 높아 압도적인 실행 속도 를 자랑합니다.

높은 유연성과 자유도

창 제어, 비동기 처리, COM 연동, 프로세스 관리 등 앱의 모든 동작을 스스로 세밀하게 제어 할 수 있습니다. 목적에 특화된 도구나 자작 독자 프레임워크 등도 구축 가능합니다.

런타임이 필요 없어 배포하기 쉬움

.NET이나 Java와 같은 외부 런타임이 필요하지 않으므로 실행 파일 1개만으로 배포 가능 합니다. 재배포 시 트러블이 잘 일어나지 않아 인스톨러 없이도 동작시키기 쉬운 것이 매력입니다.

가벼운 앱을 만들 수 있음

필요 최소한의 구성으로 끝나기 때문에 메모리 풋프린트가 매우 작다 는 것이 특징입니다. 사양이 낮은 PC나 가상 머신 환경에서도 쾌적하게 동작합니다.

OS 수준의 고도화된 제어가 가능

마우스 및 키보드의 글로벌 후킹, 윈도우 스타일 미세 조정, 시스템 메뉴 조작 등 일반적인 언어나 라이브러리로는 어려운 제어 도 실현할 수 있습니다.

단점

개발 효율이 낮음

GUI 구축도 완전히 코드로 수행해야 하며, 버튼 하나 만드는 데 수십 줄의 코드 가 필요한 경우도 있습니다. 설계 변경 시 수정도 번거로워 UI 프레임워크를 사용한 개발에 비해 생산성은 낮은 편입니다.

유지 보수성이 떨어지기 쉬움

메시지 루프나 윈도우 프로시저 등 특수한 구조의 코드 가 많아 가독성이나 재사용성에 어려움이 있습니다. 팀 개발이나 장기 유지 보수에는 적합하지 않은 측면도 있습니다.

모던 UI 대응이 번거로움

고DPI 대응, 터치 인터페이스, 접근성, 다크 모드 등 최근 요구되는 UX 대응이 어렵습니다. 하나하나 수작업으로 대응해야 하므로 수고가 듭니다.

크로스 플랫폼 미지원

완전히 Windows 전용 API이기 때문에 macOS나 Linux로는 이식 불가 합니다. 멀티 플랫폼 전개를 가정할 경우 다른 기술을 선택해야 합니다.

학습 비용이 매우 높음

핸들, GDI, COM, OLE 등 현대에는 잘 사용되지 않는 개념이나 구조 를 이해해야 합니다. 문서도 오래된 것이 많아 학습에는 시간과 끈기가 요구됩니다.

적합한 용도

파일 런처나 단축키 지원 등의 가벼운 도구
클립보드 조작이나 IME 제어 등의 시스템 유틸리티
글로벌 훅이나 창 캡처 등의 네이티브 제어계 앱
하드웨어와 밀접하게 연동되는 드라이버 보조 도구

부적합한 용도

모던 UI·UX가 중시되는 일반 소비자용 앱
속도 우선으로 만드는 프로토타이핑이나 MVP 개발
장기 운용 및 팀 개발을 전제로 한 대규모 프로젝트
여러 OS에 대응할 필요가 있는 크로스 플랫폼 제품

평가 요약

관점	평가
실행 속도	◎ 매우 빠름
메모리 효율	◎ 뛰어남
개발 속도	× 느림
유지 보수성	× 낮음
크로스 플랫폼 대응	× 미지원
모던 UI 대응	× 약함
OS 제어 자유도	◎ 압도적으로 높음

결론

Win32API + C++는 ‘OS의 모든 것을 스스로 다루고 싶은’ 개발자에게 적합한 도구입니다. 그 파워는 매우 크지만 학습과 운용에는 그에 상응하는 각오가 필요합니다.

‘굳이 선택할’ 가치가 있는지는 당신이 목표로 하는 앱의 성격에 달려 있습니다.

GUI 프레임워크나 최신 언어에 의존하지 않고 #include <windows.h>의 세계로 뛰어드는 것―― 그 선택은 지금도 변함없이 의미가 있습니다.