LoRa

https://videocodec.tistory.com/2514

IoT 오픈 하우스란?

IoT 오픈 하우스는 디바이스의 개발을 위햇 오픈된 공간입니다. IoT 오픈 하우스는 IoT 생태계 활성화를 위하여 개발자 및 스타트업의 상품 개발부터 서비스 상용화까지 종합적으로 지원하고 개발자를 육성하는 Eco-Player 역할을 수행합니다.

https://ilikethisplus.tistory.com/67

목적기술 지원을 통한서비스 개발 및 상용화 기간 단축개발자 지원을 통한 자생적 개발 환경 조성 및IoT 생태계 활성화지원 대상LoRa, Cat M1, LTE-M 등IoT 단말 및 서비스 상용화를 준비 중인 모든 기업지원 업무컨설팅 : 기획/개발, 디바이스 및 플랫폼, 클라우드 활용 컨설팅개발지원 : 디바이스 HW/SW 및 ThingPlug 연동 개발지원상품화 지원 : 상용 망연동을 통한 상용화 지원교육 : IoT 단말 및 클라우드 상설 교육 과정

• 기술 지원을 통한 서비스 개발 및 상용화 기간 단축
• 개발자 지원을 통한 자생적 개발 환경 조성 및 IoT 생태계 활성화
• LoRa, Cat M1, LTE-M 등 IoT 단말 및 서비스 상용화를 준비 중인 모든 기업
• 컨설팅 : 기획/개발, 디바이스 및 플랫폼, 클라우드 활용 컨설팅
• 개발지원 : 디바이스 HW/SW 및 ThingPlug 연동 개발지원
• 상품화 지원 : 상용 망연동을 통한 상용화 지원
• 교육 : IoT 단말 및 클라우드 상설 교육 과정

패킷 충돌

RAK LoRa 게이트웨이를 사용하시면서 여러 디바이스가 동시에 데이터를 전송할 때 데이터 누락(Packet Loss)이 발생하는 것은 LoRaWAN 네트워크에서 흔하게 발생할 수 있는 현상입니다. 이는 LoRaWAN이 사용하는 CSMA/CA(충돌 회피) 방식이 아닌 ALOHA 방식과 관련이 깊습니다.

데이터 누락이 발생하는 주된 원인은 **패킷 충돌(Collision)**과 게이트웨이의 한계 때문이며, 세부 원인은 다음과 같습니다.

1. 패킷 충돌 (Collision)

LoRaWAN은 비동기식 ALOHA 프로토콜을 기반으로 작동합니다. 이는 디바이스가 데이터를 보내기 전에 채널이 비어있는지 확인하지 않고, 필요할 때 즉시 데이터를 전송하는 방식입니다.

1.1. 동시 전송 (심각한 충돌)

가장 직접적인 원인입니다. **두 개 이상의 디바이스가 완전히 동일한 시간에, 동일한 채널(주파수), 동일한 전송 파라미터(SF, BW)**를 사용하여 패킷을 전송하는 경우입니다.

• 결과: 두 패킷의 전파가 서로 간섭하여 모두 손상되고, 게이트웨이가 두 패킷 중 어느 것도 성공적으로 디코딩(복호화)하지 못하게 됩니다. 이는 데이터 누락으로 이어집니다.

1.2. 동일한 스펙트럼 사용

LoRa 기술은 **확산 인자(Spreading Factor, SF)**와 **대역폭(Bandwidth, BW)**을 다르게 사용하면 동일한 주파수라도 충돌 없이 데이터를 수신할 수 있는 **직교성(Orthogonality)**을 제공합니다.

• 하지만, 디바이스들이 동일한 SF를 사용하는 경우, 주파수가 달라도 **패킷 전송 시간(Airtime)**이 길어지면 충돌 가능성이 높아집니다.
• 원인: 모든 디바이스가 기본 설정값(예: SF12)을 사용하도록 되어 있다면, 충돌이 발생할 확률이 매우 높습니다.

2. 게이트웨이의 한계

RAK 게이트웨이는 일반적으로 8채널 또는 16채널 수신기를 사용하며, 동시에 처리할 수 있는 패킷 수에 물리적 한계가 있습니다.

2.1. 채널 수신 능력의 한계

대부분의 LoRaWAN 게이트웨이는 8개의 병렬 수신 체인을 가지고 있어, 최대 8개의 서로 다른 LoRa 신호를 동시에 디코딩할 수 있습니다.

• 만약 12대의 디바이스가 동시에, 심지어 서로 다른 채널을 사용하더라도, 동일한 순간에 8개를 초과하는 패킷이 도달하면 나머지 패킷은 게이트웨이에 의해 처리되지 못하고 버려지게 됩니다.

2.2. 게이트웨이의 백홀 병목 현상

게이트웨이가 수신한 패킷을 LoRaWAN 네트워크 서버(LNS)로 전달하는 과정(백홀, 보통 인터넷 연결)에서 잠시 지연이 발생하거나 과부하가 걸릴 수 있습니다.

• 원인: 게이트웨이의 CPU 부하가 높거나, 인터넷 연결 상태가 불안정할 경우, 수신된 패킷을 LNS로 보내기 전에 메모리 버퍼가 가득 차서 새로운 패킷을 받아들이지 못하고 드롭(Drop)시킬 수 있습니다.

3. 통신 환경 및 설정 문제

3.1. ADR(Adaptive Data Rate) 미사용

• *ADR(적응형 데이터 전송 속도)**은 LoRaWAN의 핵심 기능 중 하나입니다.
• ADR 기능: 디바이스와 게이트웨이 간의 신호 세기(RSSI)가 좋을 경우, LNS가 디바이스에게 SF 값을 낮추도록(예: SF12 → SF7) 명령을 내립니다.
• 효과: SF 값이 낮아지면 **패킷 전송 시간(Airtime)**이 극적으로 짧아집니다. (SF12에 비해 SF7은 수십 배 빠름). 전송 시간이 짧아질수록 다른 패킷과 충돌할 확률도 낮아지므로 누락률이 감소합니다.
• 누락 원인: ADR이 활성화되지 않거나, 디바이스가 너무 낮은 SF(느린 속도)로 고정되어 있으면 충돌에 취약해집니다.

3.2. 인접 채널 간섭 (Adjacent Channel Interference)

디바이스들이 사용하는 주파수 채널이 너무 촘촘하게 붙어 있어, 한 채널의 강력한 신호가 인접한 다른 채널의 약한 신호를 마스킹(가려버리는) 현상이 발생할 수 있습니다.

해결을 위한 권장 조치

데이터 누락을 최소화하려면 디바이스들이 충돌을 피하도록 설정하고, 게이트웨이의 부하를 줄이는 것이 중요합니다.

1. ADR 활성화 및 관리: 모든 디바이스에서 ADR을 활성화하여, 디바이스가 가능한 한 낮은 SF(빠른 전송 속도)를 사용하도록 유도해야 합니다.
2. 전송 주기 분산: 디바이스들이 동시에 데이터를 보내지 않도록 각 디바이스의 전송 주기를 무작위화하거나 (Random Jitter), 서로 다른 시간에 전송하도록 설정합니다.
3. SF 분산: 만약 ADR이 작동하지 않는 환경이라면, 디바이스들을 수동으로 **다양한 SF 값(SF7, SF8, SF9 등)**으로 나누어 설정하여 충돌 가능성을 줄여야 합니다.
4. 게이트웨이 추가: 디바이스 수가 많고 통신이 중요한 경우, 게이트웨이를 추가로 설치하여 커버리지를 늘리고 패킷을 동시에 수신할 수 있는 능력을 확장하는 것이 가장 확실한 방법입니다.

💡 600미터 거리에서 충돌 최소화 전략

600미터 거리에서는 디바이스들이 **SF7 (DR5)**을 사용하여 통신할 수 있는 환경이 조성됩니다. SF7은 SF12에 비해 전송 시간이 약 30배 이상 짧기 때문에 충돌 확률을 획기적으로 낮출 수 있습니다.

1. ADR 설정의 효과 확인 (가장 중요)
네트워크 서버(LNS) 설정은 이미 Max Allowed TX Data Rate이 DR_5 SF7 BW125로 설정되어 있어, 디바이스가 이 속도를 사용하도록 유도하고 있습니다.

파라미터 현재 설정 600m 환경에서의 기대 효과

2. ADR 마진 조정 (선택적 튜닝)

충돌이 계속 발생한다면, LNS가 더 빠르게 SF를 낮추도록 유도할 수 있습니다.

파라미터 현재 설정 권장 조정 효과

3. DR0 (SF12) 사용 제한

파라미터 현재 설정 권장 변경 이유

LoRa 테스트

https://docs.rakwireless.com/product-categories/wisduo/rak4200-module/at-command-manual/#at-command-syntax

AI로 앱 광고 영상 만들기 경험 정리

앱을 만들고 나면 늘 같은 고민이 생긴다.
“이걸 어떻게 보여줘야 하지?”
스크린샷만으로는 앱의 느낌이 잘 전달되지 않고, 직접 영상을 촬영하자니 시간과 편집 부담이 크다. 그래서 이번에는 AI 동영상 생성 플랫폼을 이용해 앱 광고 영상을 만들어봤다. 결과적으로 느낀 핵심은 하나였다.
AI 영상은 한 번에 완성하는 것이 아니라, 여러 장면을 나눠 만들고 조립하는 방식으로 접근해야 한다.
 
 

0. 만들어진 영상 소개 (일단 결과물부터 보시죠!! ㅋ)

최종 영상은 짧은 앱 광고 형태로 구성했다.
앱의 마스코트 스티커 케릭터가 먼저 보이고, 미션을 수행  색상이 컬러로 바뀌면서 , 마지막에는 앱의 핵심 화면과 메시지가 등장하도록 만들었다.
AI로 만든 영상이라 완벽하지는 않았지만, 아이디어를 빠르게 시각화하는 데는 충분했다. 특히 앱을 아직 홍보 자료로 정리하지 못한 단계라면, AI 영상은 초기 마케팅 소재를 만드는 데 꽤 유용했다.
 
https://youtube.com/shorts/6chVr14hT3Y?feature=share

 
 
https://youtube.com/shorts/n2hgVPwWUqQ?feature=share

1. AI 동영상 생성 플랫폼 찾아보기

먼저 여러 AI 영상 생성 플랫폼을 검색해봤다. 대표적으로 많이 언급되는 서비스는 Runway, Pika, Kling AI, Hailuo AI, Luma Dream Machine, Google Veo 계열이었다.
각 플랫폼마다 강점이 조금씩 달랐다.

• Runway: 영상 품질과 편집 워크플로가 좋지만, 무료 크레딧은 제한적이다. 공식 가격 페이지 기준 무료 플랜은 1회성 125크레딧을 제공한다.
• Pika: 짧은 영상 실험에 적합하고, 무료 플랜에서도 월간 크레딧을 제공한다.
• Kling AI / Hailuo AI: 움직임 표현이나 인물, 제품 느낌을 테스트하기에 좋다는 평가가 많다.
• Luma / Veo 계열: 품질은 좋지만 무료 사용 범위나 접근성이 시점에 따라 달라진다.

검색하면서 느낀 점은 “무료”라고 해도 대부분은 완전 무료가 아니라는 것이다. 크레딧 제한, 워터마크, 해상도 제한, 대기열, 상업적 이용 조건 등을 반드시 확인해야 한다.

2. 무료로 사용할 수 있는 곳 찾기

무료로 테스트할 수 있는 플랫폼은 있었지만, 광고 영상을 완성할 만큼 넉넉한 경우는 많지 않았다.
예를 들어 Runway는 무료 플랜에서 125크레딧을 제공하지만 1회성이다. Pika는 무료 플랜에서 월간 영상 크레딧을 제공한다. 다만 무료 플랜은 해상도나 기능 제한이 있을 수 있다.
그래서 무료 플랜은 “최종 광고 제작용”이라기보다 “어떤 플랫폼이 내 앱 영상에 맞는지 실험하는 용도”로 보는 것이 맞았다.

3. Meta의 Vibes 사용

이번에 특히 관심을 가진 것은 Meta의 Vibes였다.
Vibes는 Meta AI 앱과 meta.ai 안에서 사용할 수 있는 AI 영상 생성 및 공유 기능이다. Meta 공식 발표에 따르면 Vibes는 짧은 AI 생성 영상을 만들고, 피드에서 다른 영상을 발견하고, 기존 영상을 리믹스할 수 있는 기능으로 소개됐다.
Meta AI Vibes 페이지에서도 AI 이미지와 영상을 무료로 생성할 수 있다고 안내하고 있다. 접근성이 좋고, 짧은 광고 영상 아이디어를 빠르게 실험해보기에는 괜찮은 선택지였다.

4. Vibes의 특징

직접 사용하면서 느낀 Vibes의 특징은 다음과 같다.
첫째, 짧은 영상 아이디어를 빠르게 실험하기 좋다.
광고 영상 전체를 한 번에 만들기보다는, 특정 장면이나 분위기를 테스트하는 데 적합했다.
둘째, 이미지 기반 영상 만들기에 잘 맞는다.
앱 광고의 경우 앱 화면, 캐릭터, 제품 이미지, 시작 장면, 끝 장면을 준비해두면 훨씬 결과가 안정적이었다.
셋째, 리믹스 방식의 접근이 자연스럽다.
완전히 빈 화면에서 시작하기보다, 마음에 드는 스타일이나 장면을 참고하고 변형하는 방식이 잘 맞았다.
넷째, 결과물은 반복 수정이 필요하다.
AI가 한 번에 의도한 영상을 완벽히 만들어주지는 않는다. 특히 텍스트, 앱 화면, 손동작, UI 디테일은 틀어질 수 있기 때문에 여러 번 생성하고 고르는 과정이 필요했다.

5. 영상 만드는 방법

내가 사용한 방식은 다음 순서였다.

1. 영상을 만들 재료 선정

먼저 광고에 들어갈 핵심 재료를 정했다.

• 앱의 핵심 화면
• 앱을 사용하는 상황
• 보여주고 싶은 기능
• 시작 장면 이미지
• 끝 장면 이미지
• 영상 분위기
• 짧은 홍보 문구

여기서 중요한 것은 “앱의 모든 기능”을 넣으려고 하지 않는 것이다. 짧은 광고 영상에서는 하나의 메시지만 잡는 것이 훨씬 좋았다.
예를 들어 “AI가 일정을 자동 정리해주는 앱”이라면, 전체 기능 설명보다 “복잡한 하루가 한눈에 정리되는 장면” 하나에 집중하는 식이다.

2. 시작 프레임과 끝 프레임에 이미지 투입

AI 영상은 시작과 끝이 흔들리기 쉽다. 그래서 시작 프레임과 끝 프레임에 사용할 이미지를 준비했다.
시작 프레임은 사용자의 문제 상황을 보여주는 이미지로 잡고, 끝 프레임은 앱이 해결책처럼 보이는 이미지로 잡았다.
예를 들면 다음과 같다.

• 시작: 앱에서 사용할 캐릭터 이미지
• 끝: 앱 화면에서 일정이 깔끔하게 정리된 모습

이렇게 시작과 끝을 정해두면 영상의 방향성이 훨씬 분명해진다.

3. 스크립트 작성

그다음 영상 생성용 스크립트를 작성했다.
처음에는 긴 설명을 넣었는데, 결과가 오히려 흐려졌다. 나중에는 장면 단위로 짧고 구체적으로 작성했다.
예시:

장면 1. 그림의 소년이 고개를 들고 둠칫 리듬에 맞춰 살짝 움직인다. 주변에 노란 별, 핑크 하트, 스티커 효과가 팡 하고 나타난다. 장면 2. 물 마시기 미션 소년이 식탁 쪽으로 걸어간다. 식탁 위에는 물컵이 놓여 있다. 소년이 물컵을 들고 물을 마신다.
장면 3. 흑백 소년이 컬러로 바뀐다.
장면 4. 둠칫 앱 미션 완료 스마트폰 화면이 나타난다. 둠칫 앱 홈 화면에 파란 미션 스티커 "물 마시기"가 보인다.
장면 5. 소년 손가락 또는 스티커 손 아이콘이 미션을 탭한다. 미션 스티커에 "성공!" 도장이 찍히고, 별과 하트가 튄다. 짧은 문구: "작은 성공 완료!"

장면 1. 그림의 소녀가 고개를 들고 둠칫 리듬에 맞춰 스트래칭 운동을 한다.
장면 2. 운동을 마치고 땀을 닦는다. 흑백 소녀가 컬러로 바뀐다.
장면 3. 소녀 이미지가 스티커로 변신한다(움직임 없이). 둠칫 앱 미션 완료 스마트폰 화면이 나타난다.
장면 4. 소년 손가락 미션을 스티커를 1번 탭 한다. 미션 스티커에 "성공!" 도장이 찍히고, 별과 하트가 튄다. 짧은 문구: "작은 성공 완료!” 스마트 폰 화면을 3초 정도 보여준다.

 
 
좋은 스크립트는 길이가 긴 글이 아니라, 장면이 머릿속에 바로 그려지는 문장에 가까웠다.

4. 결과 보기

생성된 결과를 보고 다음 항목을 확인했다.

• 앱 화면이 너무 왜곡되지 않았는가
• 영상의 시작과 끝이 자연스러운가
• 광고처럼 보이는가
• 움직임이 과하지 않은가
• 핵심 메시지가 보이는가
• 다시 사용할 만한 장면이 있는가

만족스럽지 않으면 프롬프트를 조금 바꾸거나, 시작 이미지와 끝 이미지를 다시 조정했다.

6. 한 번에 완성하려고 하면 안 된다

AI 영상 제작에서 가장 크게 배운 점은 이것이다.
전체 영상을 한 번에 만들려고 하면 실패할 가능성이 높다.
처음에는 20초짜리 앱 광고를 한 번에 만들고 싶었다. 하지만 그렇게 하면 장면 전환이 어색하거나, 앱 화면이 이상하게 변형되거나, 메시지가 흐려지는 경우가 많았다.
더 나은 방식은 전체 스토리를 먼저 만들고, 그것을 여러 장면으로 나누는 것이다.
예를 들면 20초 광고라면 이렇게 나눌 수 있다.

1. 문제 상황: 사용자가 복잡한 업무와 알림에 지쳐 있다.
2. 앱 등장: 앱을 실행하자 정보가 자동으로 정리된다.
3. 핵심 기능: AI가 추천, 정리, 요약을 해준다.
4. 결과 장면: 사용자가 여유롭게 하루를 관리한다.
5. 마무리: 앱 이름과 짧은 메시지를 보여준다.

각 장면을 3~5초 단위로 따로 만들고, 마지막에 편집 도구에서 이어 붙이는 방식이 훨씬 안정적이었다.
 
그리고 연속된 장면으로 만들고 싶다면, 
이전 영상의 끝 이미지와 다음영상의 시작 이미지를 같은 이미지 사용 해서 진행 할 수 있었다.
(물론 완벽 하진 않지만 그래도 이어지는 느낌을 줄수 있음)
 
만들고자 했던 것은,
1. 흑백 이미지의 소년이 춤을 추면서 컬러 소년 이미지로 변경
2.  컬러 소년 이미지는 스티커로 변신 하고 앱에 추가 되며 성공 메세지와 함께  앱 화면을 보여줌
 
 

1 번

2번

1번,2번 이미지로 영상 1 제작
2번 3번 이미지로 영상 2 제작
 
타임 라인으로 1번과 2번을 연결해서 하나의 영상으로 제작 했다.
(사실 PC에 영상 제작 툴이 있다면, 그냥 PC에서 작업 하는 것이 더 좋을 수도 있을것 같다.)

7. 느낀점

퀄리티 높은 영상을 만들기는 힘들었지만 AI를 활용하면, 그동안 시도하지 못했던 영상을 만들수 있겠다.
AI 동영상 생성 도구는 앱 광고 제작의 진입 장벽을 낮춰준다. 하지만 버튼 한 번으로 완성도 높은 광고가 나오는 것은 아니다.
직접 해보니 중요한 것은 도구 자체보다 작업 방식이었다.

AI 영상 제작은 “생성”보다 “연출”에 가깝다.
AI에게 한 번에 완성본을 맡기는 것이 아니라, 내가 광고의 흐름을 설계하고 AI를 장면 제작 도구로 사용하는 방식이 가장 효과적이었다.
 
그리고 Vibes로 작업 하면서 불편한점은 
- 느리다.

• 업로드, 영상 생성, 그리고 미디어 삭제  등등 상당히 느렸다.
• 처음 이용할때는 뭔가 반응이 바로 바로 안되어, 에러메세지가 표시되거나 다른 작업하려고 하는데, 나중에 결과가 나와서 화면이 변경되는 등 좀 당황스럽게 만들었다.
• 이 느림에 약간의 적응이 필요함.

- 타임라인을 만들때 항상 음악을 추가해야 만들수 있다.
- 타임라인으로 만든것은 다운로드가 안된다.

• vibes.ai 의 timeline을 사용하여 만든 영상은 다운로드가 안된다.(웹에서 이용)
• 그래서 별도의 다운로드 방법을 찾아야 했다.
• 저같은 경우에는 여길 이용 했다.? (아 갑자기 높임말을 써야 할것 같은..)
• https://savevideoraw.com/vibes

 
 
하지만 Vibes 의 가장 큰 장점은 무료로 사용할 수 있다는 것 가장 큰 매리트 이다.
그리고 영상 만들면 무조건 올리게 되어있으니... 갑자기 누군가가 팔로우 할때도 있었다.
 
 
참고한 공식/검색 출처:

• Meta 공식 발표: Vibes 소개
• Meta AI Vibes
• Runway 가격 페이지
• Pika 가격 페이지

확인해볼 수 있는 앱 : 둠칫 다이어리

https://play.google.com/store/apps/details?id=com.rjlife.pocketa

코드 리뷰는 상당히 귀찮으면서, 동시에 필요하다고 느끼는 부분일겁니다.

다른사람의 코드를 읽는다는 것이 상당한 시간과 노력이 필요한 부분이기 때문에 그만한 열정이 없다면 힘들겠죠.

그런데 만약 당신이 엄청난 열정의 소유자이고 팀원을 위해서 희생을 할 용의가 있다면, 코드리뷰를 시작해봅시다.

코드리뷰 하는 방법

1. 프로그래밍 언어적인 사항들을 리뷰한다.

기본적으로 추천하는 형태의 naming을 사용하는가?

상속,구현, 종속, 인터페이스 등의 요소들이 상황에 맞게 적용 되었는가?

예외 처리는 잘 하고 있는가?

1. 도메인 지식 기반 리뷰를 한다.

도메인은 우리 소스를 기반으로 하면 된다.

불필요 한 것들 , 이상한 것들, 등등.

• 뭔가 수정할때 마다 항상 수정하게 되는 코드 → 안정화가 되지 않았고, 요구사항을 유연하게 반영하기 힘든 부분
• 성능에 영향을 미치는 코드
• 수정 하게 되면 너무 많은 부분을 수정하게 되는 코드.
• ⇒ 결합도가 높은 코드.. 디펜던시가 너무 많은 코드

코드리뷰

https://spikez.tistory.com/31

Dart Coding Guide 참고

https://dart.dev/effective-dart

Coding Idioms

Flutter 는 Dart 언어 기반의 크로스 플랫폼을 지원하는 프레임워크 입니다.

넷 플랜트에서는 아래와 같은 몇가지 규칙들을 정하고자 합니다.

Naming

• class name : 대문자로 시작하는 CamelCase 를 사용합니다.

ex)

[good]

class MyClass
class BtSetUp  // 줄임 단어가 있을경우에 줄임 단어의 첫 글자만 대문자 사용.

• function, variable name : 소문자로 시작하는 camelCase 를 사용합니다.

[good]

getCount()
getBtDeviceCount()  // 줄임 단어가 있을경우에 줄임 단어의 첫 글자만 대문자 사용.

int countDevice;

• const ,상수 : 상수 형태로 정의해서 사용하는경우, 모두 대문자인 SNAKE_CASE 를 사용합니다.

[good]

const MAX_DEVICE_COUNT =10;
final MAX_USER = getAppDefinedMaxUser(); // const로 사용하고 싶지만 그렇지 못하고,시스템에 정의된 파일에서 읽어서 사용하는경우

하기 방식도 가능함.
const maxDeviceCount = 10;
final maxUser = getAppDefinedMaxUser();

[bad]
const mMaxCount = 10; 
	- m prefix 필요없음. (c/c++ 에서 예전에 멤버라는 의미로 사용)
	=> MAX_COUNT
											
const LimitCount = 15;
	=> LIMIT_COUNT 
	or
	=> MAX_COUNT: 보통 list의 개수를 재한을 코드로 표현할때 max를 많이 사용함.
const cntMax = 40;
	=> cnt로 줄여서 사용하지 말자
	=> MAX_COUNT
	

• DB나 서버에 정의된 형태의 데이터를 접근해서 사용하는 경우의 변수명이 경우는 한쪽으로 맞춰서 작업 하는 것이 좋습니다.따라서 snake_case 를 이용하는 것이 좋습니다.
• 보통 서버나 서비스 쪽의 REST API 규칙으로는 camelCase 를 사용하지 않고 snake_case 를 사용합니다.
• 서버나 db에 정의된 field명과 app에서 정의해서 사용하는 변수명이 다르게 되면 혼란의 여지가 생깁니다.

[good]

class MyBookDb{
  int id;
  string title;
  DateTime created_at;
  string author_name;
  string library_name;
}

Application Structure 가이드

File /Folder 구조

• Application 구성을 위한 기본 구조는 다음과 같이 가져간다.

App
 - lib
	 - base : application base 기능 모음
		 - app : 
				 app package
				 update .. etc
		 - config : application configuration
		 - language : translation 및 언어관련 로직
		 - res : app resource 들
				 color table
				 text styles
				 theme
	 - ui : ui 화면 구현, menu tree, 각 화면 page
		 - auth : login
		 - home : 기본 홈 화면
		 - common
			 - widget[folder]
				 - ui common files...
		 - part_name
			 - widget[folder]
				 - part ui files...
			 - controller : getx controller file
			 - page : ui file
	 - backend : backend access apis
		 - model[folder]
			 - model files...
		 - inteface[folder]
			 - interface files...
		 - api[folder]
			 - rest api files...
	 - lab : 개발자 모드 및 테스트 기능
	 

• source file: source code 이름은 class 의 이름과 동일하게 가져간다.대문자로 시작하는 CamelCase로 파일이름을 정한다.
• 만약 source 파일에 메인이 되는 클래스가 없다면, 대표가 되는 이름으로 정한다.
• folder : folder 이름은 ui menu tree의 상위 래벨에서 기능 구분이 가능한 수준으로 정한다.만약 server 인터페이스와 같이 ui 가 없는 경우 해당 entry와 연관된 이름으로 정한다.
• (namespace 가 없으니 규칙을 정하기 애매함.)

[good]

lib/ui/tree_management/TreeListPage.dart // tree 관리 ui
lib/ui/tree_management/widget/WTreeInfoCard.dart // tree info widget

lib/backend/RestApiTree.dart // backend  REST API
lib/auth/AccountManager.dart  // ui 없는 AccountManager 

• Ui 파트의 Naming
  • AppRoute 를 통해서 ui 화면이 전환될 수 있는 것은 post-fix로 Page 라 이름 짖는다.
  • Page 에서 사용하는 Widget의 경우는 해당 성격에 맞는 이름을 붙인다.
    • 해당 기능 밑에 widget folder를 만들고 widget을 모은다.
  • (Custom widget의 경우는 W라를 prefix를 붙이는 것도 좋다.)
  • Page , Widget 과 Controller 가 있는 경우
  • 대화형 ui에 대한 정의 :
    • Popup, Dialog, MessageBox 등 다양한 용어들이 있음
    • 우선은 Popup으로 하자.! (상황에 맞춰서서 변경 가능) / 검토 필요
• Page와 Page가 아닌 것을 구분한다.

[good]

class MyBookViewPage extends StatelessWidget // page
class MyBookViewController extends GetXController // controller

class WMyBookCover extends StatelessWidget // widget
class MyBookPrivacyPopup extends Dialog // dialog [not bad]

[bad]
class MyBookListViwer extends StatlessWidget // page
class MyBookPrivacyPage extends Dialog // dialog 

Dart 에서 권고하는 코딩 가이드

(Effective Dart)

https://dart.dev/effective-dart

유용한 HTML 도구를 만들기 위한 패턴들 (simonwillison.net)

38P by neo 7일전 | ★ favorite | 댓글 2개

• HTML·JavaScript·CSS를 한 파일로 묶어 실행하는 HTML tools 제작 경험을 바탕으로 반복되는 설계 패턴 정리
• 2년간 150개 이상 제작된 소형 도구들이 실제로 어떻게 만들어지고 유지되는지 구체 사례 중심으로 설명
• 빌드 단계 없는 구조와 CDN 활용으로 복사·붙여넣기 기반 개발 흐름이 자연스럽게 형성됨
• URL·localStorage·파일 열기·다운로드·Pyodide·WebAssembly까지 브라우저 기능만으로 가능한 범위 확장
• 프롬프트와 결과 기록, 기존 도구 재조합을 통해 도구 컬렉션 자체가 개발 기반이 되는 흐름 강화

HTML tools 개념과 사례

• HTML 한 파일에 JavaScript와 CSS를 함께 넣어 즉시 실행 가능한 소형 웹 도구들을 HTML tools 라고 부름
• 지난 2년간 150개 이상 제작되었고, 대부분 LLM이 작성한 코드로 구성
• 대표 사례
  • svg-render: SVG 코드를 PNG·JPEG 이미지로 변환
  • pypi-changelog: PyPI 패키지 릴리스 간 변경 diff 생성
  • bluesky-thread: Bluesky 토론 스레드를 중첩 구조로 표시
• 전체 도구 모음은 tools.simonwillison.net에서 확인 가능하며, 월별 보기로 제작 흐름을 살펴볼 수 있음
• 대부분 도구의 GitHub 소스와 프롬프트 또는 트랜스크립트 기록이 함께 공개됨

HTML tool의 기본 구조

• JavaScript와 CSS를 인라인으로 포함한 단일 HTML 파일 구성
• JSX 빌드가 필요한 React를 사용하지 않아 복사·재배포가 단순해짐
• 필요한 라이브러리는 CDNjs나 jsDelivr 같은 CDN에서 직접 로드하고 의존성은 최소화
• 코드 규모를 수백 줄 수준으로 유지해 유지보수 부담을 낮추고, LLM이 빠르게 읽고 수정 가능한 상태 유지

Canvas·Artifacts 기반 프로토타이핑

• ChatGPT Canvas, Claude Artifacts, Gemini Canvas를 이용해 HTML 도구를 즉시 실행하며 초기 형태를 잡는 방식
• “No React” 조건을 넣어 빌드 단계 없이 바로 동작하는 코드 생성
• JSON을 붙여넣으면 YAML로 변환하는 예제
  • ChatGPT Canvas 결과: JSON to YAML (ChatGPT), 전체 대화
  • Claude Artifact 결과: JSON to YAML (Claude), 전체 대화
  • Gemini Canvas 결과: JSON to YAML (Gemini), 전체 대화

더 복잡해지면 코딩 에이전트로 전환

• Claude Code나 Codex CLI를 사용하면 Playwright 등으로 브라우저 테스트를 포함한 반복 작업 자동화 가능
• 더 복잡한 도구(예: Bluesky 스레드 뷰어)에서는 이러한 에이전트로 “업그레이드”하는 방식 사용
• simonw/tools 레포지토리에 직접 PR을 생성해 도구를 추가·업데이트
  • 레포지토리: github.com/simonw/tools
  • 실제 PR 기록: 닫힌 PR 목록
• 웹 기반 에이전트를 활용한 작업 과정은 Claude Code for web 사용 영상에서 확인 가능

CDN 기반 의존성 관리

• 추가 라이브러리를 쓸 때는 CDN에서 로드함
• LLM의 Artifacts/Canvas가 허용하는 CDN allow-list가 있어 “PDF.js 사용” 같은 지시로 URL 구성이 됨
• 필요하면 cdnjs·jsDelivr에서 URL을 찾아 채팅에 붙여넣는 방식 사용
• npm 설치나 빌드 과정 없이 HTML 파일 하나로 동작
  • npm+빌드 스텝은 개별 도구를 빠르게 해킹하고 셀프호스팅하는 생산성을 떨어뜨림
• CDN URL에 버전이 포함되어 장기간 재현 가능성 유지

외부 정적 호스팅

• LLM 플랫폼 내부 호스팅은 샌드박스 제약이 많아 외부 URL 데이터/이미지 로드나 외부 링크 기능이 막히는 경우가 있음
• 사용자 경험 측면에서 경고 메시지·추가 로딩·플랫폼 홍보가 끼는 문제가 생길 수 있음
• “No React + CDN” 조합이 빌드 없이 어디든 올리기 쉬움
• GitHub Pages에 HTML 파일을 올리면 바로 고정 URL로 접근 가능
  • GitHub Pages 안내: docs.github.com/pages
• 대부분 도구가 simonw/tools 레포에서 관리되며 tools.simonwillison.net 으로 제공됨

복사·붙여넣기 중심 입출력

• 많은 도구가 붙여넣은 입력을 변환하고 다시 클립보드로 복사하게 만드는 형태를 핵심 메커니즘으로 사용
• 모바일에서 복사·붙여넣기가 불편해 “Copy to clipboard” 버튼을 자주 추가함
• OS 클립보드가 여러 포맷을 함께 담을 수 있고, JavaScript paste 이벤트에서도 이러한 “리치” 데이터에 접근 가능
• 대표 도구
  • hacker-news-thread-export: HN 스레드를 LLM 입력용 텍스트로 변환
  • paste-rich-text: 붙여넣은 리치 텍스트의 HTML 추출
  • alt-text-extractor: 이미지 붙여넣기 후 alt 텍스트 추출

디버깅 도구

• 브라우저에서 다뤄지는 실제 데이터 구조를 확인하기 위한 전용 도구 제작
• clipboard-viewer: 텍스트·리치 텍스트·이미지·파일 등 클립보드 데이터 전체 표시
• 추가 도구
  • keyboard-debug
  • cors-fetch
  • exif

URL에 상태 저장

• 서버 DB 없이도 URL에 많은 상태를 저장할 수 있음
• 북마크·공유를 염두에 둔 도구에서 이 패턴을 선호
• icon-editor: 24×24 아이콘 편집 상태를 URL에 그대로 보존

localStorage 활용

• localStorage는 사용자 디바이스에 데이터를 지속 저장하며 서버에 노출하지 않는 브라우저 API
• URL에 담기 어려운 큰 상태나 API 키 같은 비밀값 저장에 사용하며, 정적 호스트의 서버 로그 노출 위험을 피하기 위함
• word-counter: 작성 중 텍스트를 자동 저장
• render-markdown: 마크다운 작성 중 내용 유지
• haiku: API 키를 localStorage에 저장해 웹캠 이미지를 바탕으로 하이쿠 생성

CORS 가능한 API 활용

• CORS(Cross-origin resource sharing)는 다른 도메인의 API를 브라우저 JavaScript가 호출할 수 있는지 제어하는 메커니즘
• CORS 헤더가 열린 API는 HTML tools에 유리한 자원이며, 시간이 지나며 목록을 모을 가치가 있음
• iNaturalist, PyPI, GitHub(공개 레포 콘텐츠를 raw.githubusercontent.com로 익명 접근 가능), Bluesky, Mastodon 등 사용
• 도구 사례
  • species-observation-map
  • zip-wheel-explorer
  • github-issue-to-markdown
  • terminal-to-html
  • bluesky-quote-finder

LLM API 직접 호출

• OpenAI·Anthropic·Gemini JSON API를 CORS로 브라우저에서 직접 호출
• API 키를 HTML에 박아두면 탈취와 과금 위험이 있어, localStorage에 저장하는 “secrets 패턴”을 사용
• 사용자 경험 측면에서 API 키 발급·붙여넣기 과정이 마찰이 크지만 동작은 함
• 예제 도구
  • openai-audio-output
  • gemini-bbox

파일 열기 두려워하지 않기

• <input type="file">로 파일을 서버에 업로드하지 않아도 브라우저에서 직접 읽어 활용 가능
• ocr: PDF.js와 Tesseract.js를 이용해 PDF를 페이지 이미지로 바꾸고 브라우저에서 OCR 수행
• social-media-cropper: 이미지 열기/붙여넣기 후 소셜 미디어용 비율(예: Twitter/LinkedIn 2:1, Substack 1.4:1 등)로 크롭 지원
• ffmpeg-crop: 비디오 크롭 ffmpeg 명령 생성

다운로드 파일 제공하기

• 서버 없이도 브라우저에서 파일을 생성해 다운로드로 제공할 수 있음
• JavaScript 생태계에 다양한 포맷 생성 라이브러리가 존재
• 예제 도구
  • svg-render: SVG를 렌더링해 PNG/JPEG 다운로드 제공
  • social-media-cropper: 크롭된 이미지 다운로드 제공
  • open-sauce-2025: 일정표를 만들고, 캘린더에 추가할 수 있는 ICS 파일 다운로드를 제공

Pyodide와 WebAssembly

• Pyodide로 Python을 WebAssembly로 컴파일해 브라우저에서 실행하는 배포판
• CDN에서 깔끔하게 로드 가능해 HTML tools에 쓰지 않을 이유가 없
• micropip을 통해 CORS로 PyPI의 순수 Python 패키지를 추가 로드할 수 있음
• 도구 사례
  • pyodide-bar-chart
  • numpy-pyodide-lab
  • apsw-query

WebAssembly로 더 넓히기

• Pyodide가 가능한 기반은 WebAssembly 덕분이며, 다른 언어로 작성된 소프트웨어도 브라우저에서 로드 가능해짐
• Squoosh.app 은 여러 이미지 압축 라이브러리를 브라우저에서 제공
• 도구 사례
  • ocr : Tesseract.js 는 이미 존재하는 Tesseract OCR 엔진의 웹 어셈블리 포트를 활용
  • sloccount*: David Wheeler의 Perl 과 C로 된 SLOCCount 유틸리티를 브라우저로 포팅. 상세 소개.
  • micropython* : @micropython/micropython-webassembly-pyscript

이전 도구 재조합

• 100개 이상의 단일 공개 컬렉션이 있으면 LLM이 도구들을 쉽게 재조합할 수 있다는 점이 또 다른 장점
• 때로는 이전 도구를 컨텍스트에 복사해 넣고, 코딩 에이전트에서는 이름으로 참조하거나 예시 검색을 시키는 방식 사용
• 동작하는 도구의 소스코드가 편집 라이브러리 사용 패턴까지 포함한 문서 역할을 하며, LLM의 성공 확률을 높임
• pypi-changelog 제작 과정 전체 기록: 프롬프트 트랜스크립트
  • “pypi package explorer” 도구를 보라고 지시한 뒤 zip-wheel-explorer 소스를 읽고, PyPI API로 wheel을 가져와 버전 간 diff를 렌더링하고 Copy 버튼을 제공하는 새 도구를 만들도록 프롬프트를 구성
• 브라우저에서 OCR 실행하기 도 참고

프롬프트·트랜스크립트 기록

• LLM 사용 기록을 저장·공개하는 습관을 통해 스스로의 활용 능력을 키울수 있음
• 채팅형 LLM 플랫폼에서 만든 도구는 share 기능을 기록 수단으로 사용
• Claude Code·Codex CLI 같은 에이전트 사용 시 터미널 전체 트랜스크립트를 복사해 terminal-to-html로 로그를 HTML로 변환하고 Gist로 공유
• 완성 도구를 레포에 저장할 때 커밋 메시지에 트랜스크립트 링크를 포함 - 기록 모음: tools.simonwillison.net/colophon

마무리

• 지난 1년 반 동안 이 방식으로 LLM과 HTML 도구를 탐험하는 과정이 매우 즐거웠고, HTML로 만들 수 있는 범위와 LLM 능력을 이해하는 데 큰 도움이 됐음
• 본인만의 도구 컬렉션을 시작하려면 GitHub 레포를 만들고 GitHub Pages를 켜서 .html 파일을 복사해 넣는 것만으로 시작 가능
• 보너스로 Claude Code와 shot-scraper를 이용해 이 글의 스크린샷을 추가한 트랜스크립트 링크 제공
  • Claude Code + shot-scraper 트랜스크립트

제가 Macbook Air M1 구매후 초기에 사용했던 제품들입니다.
지금은 더 좋은 제품들이 나와있으니 검색해서 사용 하시기 바랍니다.

Mac M1/M2 듀얼 모니터 사용하기

하기비스 USB-C USB 3.0-듀얼 HDMI 호환 4K 디스플레이 어댑터, 애플 M1 M2 윈도우 맥 디스플레이 링크 DL6950 칩 호환

https://ko.aliexpress.com/item/1005006211774496.html?spm=a2g0o.detail.0.0.ee649Kuf9Kufpt&mp=1&gatewayAdapt=glo2kor

https://www.coupang.com/vp/products/7074597623?itemId=17580182654&vendorItemId=88633468548&q=displaylink&itemsCount=36&searchId=cdfbd0c3330044c788a29a1aa079e976&rank=214&isAddedCart=

<aside>
💡 Comment 1

4k 60hz 지원하는 디스플레이 링크 찾느라 고생했는데 결국 찾았습니다. 싼가격에 잘 구매했고 배송도 토요일에 주문했는데(2/3) 수요일에 왔어요.(2/7) 제품 자체에는 전혀 문제 없는데 display link 소프트웨어 자체에는 약간의 한계가 있더군요. 지원하는 해상도가 정해져있어서 평소 사용하는것보다(2560×1440) 더 확대해서 봐야 했어요.(1920×1080) 2560을 지원하긴 하지만 experimental이라 쓰여있어서 그런지 프레임드랍 + 주사율드랍이 체감됐습니다. 또 화면을 송출하는 방식이라 프로그램을 한번 거쳐서 그런지 직접 연결한 디스플레이와 색감이 미세하게나마 달랐습니다. 또 대기화면일때 display link 연결된 모니터만 밝기가 대기모드로 전환되기 전 밝기보다 밝아지는 등 맥 소프트웨어에 최적화되지 못한 사소한 제약들이 있었어요. 그런 몇몇 아쉬운부분에 비해 hagibis 제품으로 프레임드랍 없이 잘 렌더해줬고 꿈꾸던 m1 4k 모니터 두대라 너무너무 만족합니다. 지인중에 고민하는 사람이 있다면 이 제품 소개해줄것 같아요. (m1 에어에 belkin thunderbolt3 minidock 과 연결해서 사용하는데 minidock hdmi에 4k 1대 연결, minidock usb 3.0에 hagibis랑 4k 1대 연결했습니다.) 오랜시간 제품군을 알아본 만큼 큰 아쉬움없이 잘 작동해주어 만족감이 높습니다.

Comment 2

첨에는 dl칩 들어간걸 이돈에..? 하고 의심했는데 외관 보니까 16발 짜리 국내업체꺼랑 비슷해보이길래,, 같은 공장이겠거니 하고 삼. 결론은 개씨이입 만족..! M1에 물려서 쓰고있는데 인식 잘해줘서 기특하다... 배송도 아주착해…

</aside>

썬더볼트 독으로 노트북과 주변기기의 연결을 간단하게

https://www.coupang.com/vp/products/6408824781?itemId=13735032234&vendorItemId=85669730803&src=1042503&spec=10304991&addtag=400&ctag=6408824781&lptag=10304991I13735032234&itime=20240222115232&pageType=PRODUCT&pageValue=6408824781&wPcid=17083159187695045413749&wRef=&wTime=20240222115232&redirect=landing&gclid=CjwKCAiA29auBhBxEiwAnKcSqvjv68DMjBgvh-7JM4WBQ_Fa8VRPr9kztMttWG0ZbpUhnRptmBpTzBoCQewQAvD_BwE&mcid=f2e5cb91955246d99c23e8e38f94e62f&campaignid=20475378677&adgroupid=&isAddedCart=

앱 업데이트를 테스트 하기 위해서 내부 테스트 버전을 계속 올려가면서 테스트를 했었습니다. ㅠ_ㅠ 

그러나, 이렇게 하면 매번 버전을 올리고 테스트하고 올리고 테스트 하고 하는 것을 반복 해야 하는데, 시간이 번거롭고, 고통 스러운 작업입니다. 

그래서 알아보니, 내부 앱 공유를 통한 업데이트 테스트를 할 수 있는 방법이 있더군요.

이걸 해보려고 시도하다 몇시간 동안 끙끙 앓고 있었는데, 드디어 방법을 확실히 알게 되었네요.

1. 내부 앱 공유를 들어가면 이런 화면을 보실수 있습니다.

2. 여기에 링크 보이죠.. app bundle  업로드 할 수 있다고 되어있는 곳 링크를 선택합니다.

3. 높은 버전의 aab 파일과 낮은 버전의 aab 파일을 다 올려놓습니다.

 - 테스트를 위한거니까. 버전 정보만 낮춰서 올리면 됨.

4. 낮은 버전의 링크를 카톡이나, 메일로 공유해서 설치 합니다.

  - 이렇게 하면 공유에 높은 버전이 있어서 업데이트가 있다고 되어야 정상인데, 사실 그렇지 않습니다.

내부 앱 공유(Internal App Sharing)의 '버전 격리' 특성 때문

내부 앱 공유는 일반적인 Play 스토어 트랙(프로덕션, 베타, 내부 테스트)과 버전 관리 체계가 완전히 분리되어 작동합니다.

현재 기기에 설치된 v1이 "내부 앱 공유 링크"를 통해 설치되었다면, 이 앱은 오직 "내부 앱 공유에 올라온 더 높은 버전"만 업데이트 대상으로 인식합니다. Play 스토어 내부 테스트나 프로덕션에 아무리 높은 버전이 올라와 있어도 그것을 인앱 업데이트 대상으로 바라보지 않습니다.

문제는 내부 앱 공유로 올린 높은 버전의 패키지가 자동으로 인식 하는 것도 아니라는 것입니다.

이것 때문에 많은 시간을 허비했습니다.

내부 테스트로 버전을 올려보기도 하고, 프로덕트로 올려보기도 했고, 말이죠.

방법은 간단한데, 내부 앱 공유에 올라와 있는 높은 버전의 앱 링크를 , 카톡이나, 메일로 공유 한다음, 테스트하고자 하는 기기에서 해당 링크를 엽니다. (설치 아닙니다.)

그러면 구글 플레이스토어(기기에 설치된) 가 실행되어 해당 페이지를 열게 되고 높은 버전의 앱 정보를 캐싱하게 됩니다.

이렇게 해서 우리가 이미 설치한 낮은 버전의 앱에서 플레이 스토어 (서비스)가 새로운 버전이 있다고 앱에 알려줄 수 있게 됩니다.

요약하자면: 낮은 버전을 내부 앱 공유로 받으셨다면, 기기의 Play 스토어에 높은 버전 역시 내부 앱 공유 링크를 통해 한 번 '인식(링크 클릭)'시켜 주어야 인앱 업데이트가 작동합니다!

# in app update

AI 에이전트를 제대로 활용하려면: “어떻게 요청할 것인가”가 핵심이다

AI 기술이 빠르게 발전하면서, 이제는 단순한 질의응답을 넘어 업무를 대신 수행하는 AI 에이전트 시대가 열리고 있다. 하지만 많은 사람들이 간과하는 부분이 하나 있다.

바로 **“AI에게 무엇을 시키고, 어떻게 요청해야 하는가”**이다.

AI 에이전트는 사람이 던지는 지시(프롬프트)에 따라 일의 수준이 완전히 달라진다. 그냥 질문을 던지는 것과, 목적을 고려해 구조화된 요청을 하는 것은 결과물의 질에서 큰 차이가 난다.

특히 다음 네 가지 요소를 정리해 요청하면, 에이전트는 훨씬 더 정확하고, 빠르고, 지속 가능한 방식으로 동작한다.

역할(Role) 지침(Guidelines) 목표(Goal) 배경(Background)

---

1. 역할(Role): AI가 어떤 ‘정체성’으로 행동할지를 정한다

AI는 스스로 직업을 선택하지 않는다.

사용자가 어떤 관점과 역할로 생각하길 원하는지 명확히 알려주면 능력이 극대화된다.

예를 들면:

• “너는 지금 세무 전문가야.”
• “너는 경험 많은 CTO라고 생각하고 설명해줘.”
• “너는 영업 코치 역할을 해줘.”

역할을 부여하면, 에이전트는 그 역할의 기준, 용어, 사고방식을 자동으로 반영한다.

마치 회사에서 직책을 정해주는 것처럼, AI에게도 ‘자기 자신이 누구인지’를 먼저 알려줘야 한다.

2. 지침(Guidelines): 일의 방식과 선호 규칙을 설명한다

역할을 정해도, 모든 전문가가 같은 방식으로 일하는 것은 아니다.

따라서 일할 때 따라야 하는 규칙과 스타일을 짧게 제시하면 AI가 훨씬 더 일관적이고 선호에 맞게 작업한다.

예시:

• “설명은 짧고 명확하게.”
• “전문 용어는 쓰되, 처음 등장하는 용어는 풀어서 설명해줘.”
• “결론 → 이유 → 예시 순서로 정리해.”

이런 지침을 통해 AI는 ‘어떻게 해야 내가 원하는 방식으로 일할 수 있는지’를 이해한다.

3. 목표(Goal): 무엇을 얻고 싶은지 명확히 말한다

AI에게 일을 맡길 때 가장 중요한 요소다.

결국 에이전트는 목표가 명확할수록 스스로 더 많은 판단을 대신해준다.

목표가 불명확하면 결과물도 흐릿하다.

반대로 목표가 명확하면, AI는 필요한 정보, 분석 방향, 산출물을 스스로 추론해낸다.

예:

• “10분이면 읽을 수 있는 블로그 글을 작성하는 것이 목표야.”
• “우리 팀이 의사결정을 빨리 할 수 있도록 요약해줘.”
• “실제 개발에 바로 사용할 수 있는 코드가 필요해.”

AI에게 의도와 목적을 공유하는 것만으로도 결과물 수준이 확 높아진다.

4. 배경(Background): 상황·맥락·제약을 알려주기

사람도 상황을 모르면 제대로 일하기 어렵다.

AI도 마찬가지다.

따라서 요청할 때는 왜 이 작업이 필요한지, 현재 어떤 상황인지, 어떤 제약이 있는지 알려주는 것이 좋다.

예:

• “신규 고객을 위한 이메일을 작성해야 하고, 고객층은 40대 자영업자야.”
• “현재 우리 회사는 Flutter + Unreal Engine 구조로 개발 중이야.”
• “한국 기준 법적 요건에 맞춰야 해.”

이런 배경 정보를 주면, AI 에이전트는 단순히 텍스트를 생성하는 것이 아니라 맥락을 이해한 상태에서 판단하게 된다.

왜 이 네 가지가 중요한가?

AI 에이전트는 지시의 구조에 따라 사람처럼 역할을 수행하며 멀티스텝 사고를 한다.

하지만 무엇을 기준으로 판단해야 하는지 모르면, 효율이 떨어질 수밖에 없다.

따라서 역할·지침·목표·배경을 포함한 요청을 하는 방식은 중요한 프레임워크가 된다.

이 구조로 요청하면 무엇이 좋아지는가?

• 결과물이 더 정확하다
• 반복작업에 일관성이 생긴다
• 오해나 불필요한 수정이 줄어든다
• 장기적 프로젝트에서 에이전트가 ‘연속성’을 갖는다
• 사람의 개입 없이도 똑똑하게 판단한다

즉, AI가 ‘내 일을 대신하는 동료’처럼 움직이게 된다.

마무리: AI 에이전트 시대의 핵심 역량은 “요청하는 능력”

AI를 잘 쓰는 사람과 못 쓰는 사람의 차이는 기술 이해도가 아니다.

가장 큰 차이는 AI에게 어떻게 요청하느냐, 즉 ‘지시를 구조화하는 능력’이다.

역할(Role)

지침(Guidelines)

목표(Goal)

배경(Background)

이 네 가지를 의식적으로 구성해 요청하기만 해도,

AI 에이전트는 여러분의 일을 대신해줄 수 있는 강력한 파트너가 된다.