늦은 밤, X의 타임라인을 보고 있는데 "Grok Build가 로컬 코드를 Google Cloud Storage로 보내고 있다"라는 고발이 올라왔습니다. 반신반의하며 제 PC의 ~/.grok/logs/unified.jsonl을 grep 해보았더니, 245건의 전송 기록이 남아 있었습니다. 불과 며칠 사용했을 뿐인 환경에서 그 정도 횟수였습니다.

제 환경에서 재현 테스트한 결과와 X에서 일어난 일의 시계열, 그리고 가장 중요하다고 생각하는 "gitignore는 방어가 아니다"라는 설계 원칙을 정리해 두겠습니다.

TL;DR

• Grok Build(xAI의 AI 코딩 지원 CLI)가 cwd(현재 작업 디렉토리)의 리포지토리를 스냅샷화하여 GCS로 보내고 있었던 사례가 2026-07-12 경에 폭로되었습니다.
• 제 환경에서 ~/.grok/logs/unified.jsonl을 확인한 결과, 실제로 245건의 전송 이력이 기록되어 있었습니다.
• xAI는 7/13 밤에 원격 설정으로 전송을 중단하고, 7/14에 /privacy opt-out 명령어로 중단 및 과거분 삭제가 가능하다고 발표했습니다. 다만 삭제의 실효성은 제3자 검증이 불가능합니다.
• "gitignore 해두면 안전하다"는 이번 교훈과는 정반대입니다. gitignore는 git이 push 하는 범위에 대한 이야기일 뿐, AI CLI, tar, rsync, Docker build context, IDE 동기화, 백업 소프트웨어 등은 이를 전혀 존중하지 않습니다.
• 대처법은 "지금 즉시 opt-out"과 "이번 주 내로 .env, secrets.*를 리포지토리 하위에서 외부로 빼내는 설계로 이행"이라는 2단계 대응입니다.

위 그림은 아래 섹션에서 설명할 X의 시계열을 한 장으로 요약한 것입니다. 7/9 출시부터 폭로, 고발의 확산, xAI의 대응, opt-out 절차 공개까지 5일간 급박하게 움직였습니다.

X에서 무슨 일이 일어났는가 (1차 소스 시계열)

고발과 xAI의 반응, 그리고 타임라인의 반응을 차례대로 따라가 보겠습니다. 소스는 모두 X의 1차 트윗입니다.

2026-07-09: Grok 4.5 출시

xAI 공식 @SpaceXAI가 Grok 4.5를 발표했습니다. "첫 번째 모델. 코딩과 에이전트용으로 특별히 훈련됨. Cursor를 사용하여 훈련되었으며, 최고 속도와 비용 효율성으로 최첨단 지능을 제공함"이라고 설명되어 있습니다. 이 Grok 4.5가 이후 Grok Build CLI의 내용물이 됩니다.

출처: @SpaceXAI 프로필의 2026-07-09 게시물 (개별 트윗 URL은 추후 추가 예정)

2026-07-11: Grok 4.5 무료 플랜 개방

@SpaceXAI가 @grok의 RT(리트윗)를 통해 "Grok 4.5를 무료 플랜에서 체험할 수 있게 되었습니다. X 계정 또는 SuperGrok 계정이 있다면 Grok Build를 이용해 보세요"라고 공지했습니다. 이때부터 사용자가 급격히 확대됩니다.

출처: @SpaceXAI 프로필의 2026-07-11 게시물 (@grok의 RT · 개별 트윗 URL은 추후 추가 예정)

2026-07-12: 중국어 IT 미디어가 이미 보도

일본어권보다 앞서 중국어 IT 미디어 蓝点网 (@landiantech)이 이미 다루고 있었습니다.

🚨🚨🚨 SpaceXAI의 인공지능 코딩 도구 #GrokBuild가 기본 설정으로 완전한 Git 리포지토리를 업로드하고 있음이 폭로되었습니다. 여기에는 도구가 읽지 않은 코드나 호출 컨텍스트, 그리고 Git의 완전한 커밋 히스토리가 포함되어 있습니다.

즉, 후술할 @XBToshi의 고발(7/13)보다 앞서 7/12 시점에 이미 폭로가 시작되었습니다. @XBToshi는 최초 고발자가 아니라 영어권에서의 확산자라는 위치가 됩니다.

출처: @landiantech 프로필의 2026-07-12 게시물 (개별 트윗 URL은 추후 추가 예정)

2026-07-13: @XBToshi의 최초 고발

Bitcoin & Monero Maxi인 @XBToshi(팔로워 약 1만 명)가 영어권에서 확산시킵니다. 첫 번째 트윗:

anyone ever used Grok Build, please check your grok logs.

cat ~/.grok/logs/unified.json | grep repo_state.upload

정말 화가 날 것입니다.

독자가 직접 실행해 볼 수 있는 한 줄의 명령어가 포함되어 있다는 점이 핵심이며, 이 시점에서 재현을 시도하는 사람이 급격히 늘어났습니다.

2026-07-13: 폭로 본문 (이미지 포함)

같은 날, 폭로의 본문 트윗이 올라옵니다.

AI 개발 도구의 절망적인 현주소. Grok Build가 백그라운드에서 12GB의 미사용 리포지토리 (repository) 데이터와 완전한 Git 커밋 (commit) 히스토리를 GCP에 몰래 덤프 (dump)하고 있다. 단지 스크립트의 자동 완성 (auto-complete)을 위해서만. 당신을 도와 빌드하려는 것이 아니다. 그저 로컬 개발 환경을 트레이닝 데이터 (training data)의 오픈 버퍼 (open buffer)로 만들고 있을 뿐이다.

첨부된 이미지에는 Claude Code를 통해 재현을 시도한 결과가 찍혀 있었습니다. ~/.grok/logs/unified.jsonl의 생 로그 (raw log) 발췌본 (repo_state.upload.start와 repo_state.upload.enqueued의 JSON)이 실제로 수중에 관측되고 있음을 보여주는 자료로 사용되었습니다. "AI가 하는 말이니까"라는 생각에 다른 AI를 통해 검증하게 했다는 방식 또한 시대의 흐름을 느끼게 합니다.

출처: @XBToshi 폭로 본문

2026-07-13: 대응 절차 스레드 (scan mode 관찰)

같은 스레드에서 @XBToshi는 대응 절차를 공개했습니다 (상위 스레드: @XBToshi 폭로 본문의 이어지는 내용). 항목 4가 특히 중요합니다.

• 업로드 큐 (upload queues) 보류

• 안전을 위한 삭제 (Uninstall to be safe):
  rm -rf ~/.grok/downloads ~/.grok/logs ~/.grok/sessions ~/.grok/bin

• grok으로 열었던 리포지토리 내부의 .env, .envrc, ~/.config/**에 존재하는 모든 자격 증명 (credentials)을 교체(rotate)하십시오. tarball 스쿱 (scoop)은 해당 파일들을 빨아들일 수 있습니다. 단, .gitignore 처리를 해두지 않은 경우에 한하며, 설령 처리를 했더라도 스캔 모드 (scan mode)에 따라 커밋되지 않은 (uncommitted) 파일들은 대상이 될 수 있습니다.

내용을 분석하면 그의 관찰 결과는 다음과 같습니다.

• .gitignore 하지 않은 파일은 tarball이 빨아들인다.
• .gitignore를 했더라도, 커밋되지 않은 (uncommitted) 파일은 스캔 모드 (scan mode)에 따라 대상이 될 수 있다.

"스캔 모드 (scan mode)"는 Grok Build 내부의 설정인 것으로 보이나, 상세 내용은 공개되지 않았습니다. 여기서 처음으로 ".gitignore를 하면 절대 안전하다"는 것이 관찰을 바탕으로 부정되었습니다.

2026-07-13 밤: xAI가 원격 설정을 통해 전송 중단

폭로를 받은 후 xAI 측에서 대응이 이루어집니다. 수중의 로그를 보면, 이 밤 중 어느 시점에 전송 플래그 (flag)가 false로 전환되었습니다. 자세한 내용은 후술하겠지만, trace.upload.decision 이벤트의 uploads_enabled가 true에서 false로 바뀌었으며, 이유는 feature_off, 소스는 remote로 되어 있습니다. xAI 서버 측에서 원격으로 끌 수 있는 설계였습니다.

2026-07-14 00:37 JST: xAI 공식 성명

@SpaceXAI가 공식 성명을 발표했습니다.

우리는 귀하의 개인정보를 매우 중요하게 생각하며 고객의 선택을 존중합니다. 데이터 보존 제로 (zero data retention, ZDR)를 사용하는 팀의 경우, 어떠한 흔적이나 코드 데이터도 보존되지 않습니다. Grok Build의 모든 API 키 사용 또한 ZDR을 준수합니다. 만약 ZDR이 비활성화되어 있다면, CLI에서 /privacy 명령어를 사용하여 데이터 보존을 비활성화할 수 있습니다.

언제든지 /privacy를 실행하면 설정을 확인하거나 변경할 수 있다는 내용이 이어집니다. "지금 사용할 수 있음 (available)"이라는 현재형 표현이 핵심이며, "앞으로 만들겠다"가 아니라 "이미 존재한다"는 태도를 보여줍니다.

출처: @SpaceXAI 성명

2026-07-14 00:47 경 JST: 속보

동일한 스레드에서 보충합니다 (상위 스레드: @SpaceXAI 성명의 이어지는 내용).

/privacy를 실행하여 설정을 변경하면, 이전에 동기화된 모든 데이터가 삭제됩니다.

"이전 데이터도 삭제된다"는 점이 핵심이며, 이 부분이 나중에 논쟁의 초점이 됩니다.

2026-07-14 01:00 경 JST: 제삼자의 질문

Farhan Ali Shah (@FarhanWritess)가 @SpaceXAI 성명 스레드에 답글로 질문을 던졌습니다. "알아두면 좋겠네요, 명확하게 해주셔서 감사합니다. 간단한 질문인데, /privacy를 실행해서 ZDR ..." 다른 사용자들도 상황을 파악하기 위해 움직이고 있었다는 당시의 분위기를 읽을 수 있습니다.

2026-07-14 01:24 JST: @XBToshi의 반론

@XBToshi는 xAI의 성명을 곧이곧대로 믿지 않았습니다.

@SpaceXAI we will never be able to verify if they truly removed our previously synced data, SAD.

And with one caveat: Trust-only, not verifiable:

• We can't audit xAI's GCS to confirm the past bundles were actually deleted.

"우리의 이전에 동기화된 데이터가 정말로 삭제되었는지 결코 검증할 수 없습니다, 슬프게도", "xAI의 GCS를 제삼자가 감사할 수단은 없다 = 오직 신뢰(trust-only)에 의존할 뿐 검증 불가능하다"

이는 기술적으로 타당한 지적입니다. xAI 측의 버킷(bucket)을 외부에서 들여다볼 수단은 없으므로, xAI가 "삭제했습니다"라고 말하더라도 사용자가 이를 검증할 방법은 존재하지 않습니다.

출처: @XBToshi 반론

2026-07-14 (이후): @XBToshi의 업데이트 공지

@XBToshi는 결국 xAI의 대응을 받아들여 절차를 공개했습니다 (상위 스레드: @XBToshi 고발 본편의 이어지는 내용).

Update: we can now opt out of code sync (업데이트: 이제 코드 동기화에서 옵트아웃 (opt out) 할 수 있습니다)

mkdir -p /tmp/grok-priv && cd /tmp/grok-priv grok /privacy opt-out

임시 디렉토리에서 grok을 실행하여 옵트아웃(opt-out)하는 절차입니다. "민감한 리포지토리(repo)에서 옵트아웃 작업을 하지 마라"는 배려입니다. 옵트아웃 작업 세션 자체에서 리포지토리 정보를 xAI에 연결하지 않기 위해, 의도적으로 무해한 디렉토리에서 명령을 실행하는 방식입니다. 이 부분은 세세하지만 중요한 포인트이며, 이후의 해설 기사들에서는 크게 다뤄지지 않은 부분입니다.

로컬에서 실측해 보았다

자신의 환경에서 재현 테스트를 해보았습니다. Windows 11의 PowerShell 환경입니다.

전송 이력을 확인하기

Select-String -Path "$env:USERPROFILE\.grok\logs\unified.jsonl" -Pattern "repo_state.upload" -SimpleMatch | Measure-Object

macOS / Linux라면 다음과 같습니다.

cat ~/.grok/logs/unified.jsonl | grep repo_state.upload | wc -l

자신의 환경에서는 245건의 전송 큐잉 (queuing) 이벤트가 기록되어 있었습니다. 1 세션당 평균 3~10건의 인큐 (enqueue)가 발생하고 있었습니다.

전송 대상의 경로 구조

각 이벤트에는 gcs_path 필드가 있으며, 다음과 같은 구조였습니다.

{
"msg": "repo_state.upload.enqueued",
"ctx": {
...

• 전송 대상은 Google Cloud Storage의 xAI 관리 버킷 (추정)
• 각 세션 (sessionId

）마다 각 턴(turn)에서 before / after 2개의 스냅샷이 생성됩니다.

• blobs는 "변경 파일 수"로 보이며, 차분 업로드 (differential upload) 설계입니다.
• size_bytes는 압축 후의 tar.gz 크기입니다.

차분 업로드 방식이므로, 고발자가 말한 "12GB의 덤프"는 세션을 길게 계속 유지했을 경우의 이론값으로 생각하는 것이 타당합니다. 제 환경에서 245개 스냅샷의 누계는 수 MB였습니다. 다만 **1 스냅샷의 상한이 max_file_bytes: 1073741824 (1GB)**로 설정되어 있었기 때문에, 이론상으로는 수백 GB 급까지 가능합니다.

대상이 된 리포지토리(repo) 목록

전송 대상이 되었던 리포지토리를 중복을 제거하여 세어보니 17개가 있었습니다. 그중 제가 관리하는 private 리포지토리도 4개가 포함되어 있었습니다. gitignore 처리되어 git tracked 상태가 아닌 기밀 파일(.env 계열)을 가지고 있는 리포지토리도 있어, 남의 일처럼 느껴지지 않았습니다.

opt-out 상태 확인

TUI에서 /privacy를 입력하면 상태가 표시됩니다. 초기 상태는 다음과 같습니다.

Privacy: share data
Usage and code data may be used by xAI to improve the product.
Use /privacy opt-out to enable privacy mode.
...

"share data"가 초기값이었습니다. /privacy opt-out을 입력하면 전환됩니다.

Privacy: privacy mode
Your code data will not be trained on or used to improve the product.
Use /privacy opt-in to share data and help improve the product.

명시적으로 "your code data will not be trained on"이라고 말해주는 점은 안심할 만한 요소이지만, 이는 향후의 이야기이며 과거에 전송된 데이터는 xAI 측에 남아 있을 것입니다 (삭제되었는지 여부는 검증 불가능).

xAI의 대응에서 신경 쓰이는 점

xAI는 24시간 이내에 움직였으며, 그 속도 자체는 평가해야 한다고 생각합니다. 다만, 몇 가지 앞뒤가 맞지 않는 부분도 있었습니다.

성명(statement)의 현재형과 구현 사이의 격차

"/privacy 명령어를 사용할 수 있습니다(available)"라고 현재형으로 발표되었으나, 재시험했을 때의 stable 버전 (0.2.99)에서는 TUI에서 /privacy를 입력해도 처음에는 자동 완성에 나타나지 않았습니다. 몇 번 시도하니 나타났기에 초기화 중의 지연 로딩 (lazy loading)이 원인이었다는 것을 알 수 있었지만, 처음 접하는 사람에게는 "거짓말인가?"라고 생각될 만한 타이밍이었습니다.

alpha channel이 404

grok update --alpha로 alpha channel로 전환했더니, 다음 버전 (0.2.100)을 다운로드하려고 시도하다가 HTTP 404 오류로 실패했습니다. xAI 측의 CDN 배포가 따라가지 못하고 있는 상태입니다.

Downloading grok v0.2.100 (windows-x86_64)...
Error: Auto-update failed: Download failed: HTTP 404 Not Found

"말이 앞서고 구현 배포가 따라가지 못하고 있다"는 상황 증거 중 하나입니다.

remote settings가 config보다 우선됨

전송을 중단하는 플래그는 로컬의 ~/.grok/config.toml에도 있을 것으로 보이지만, 실제로는 xAI 서버 측의 user_preference (remote settings)가 우선됩니다. 로그의 trace.upload.decision을 보면 trace_upload_source: "remote"라고 적혀 있으며, 결정은 서버 측에서 내려오고 있습니다.

즉, xAI가 "되돌리겠다"라고 결정하면 사용자의 의사와 상관없이 되돌아갈 가능성이 제로가 아니라는 뜻이 됩니다 (이 부분은 추측입니다).

삭제의 실효성은 trust-only

@XBToshi의 지적대로, xAI 측의 GCS 버킷을 제삼자가 감사할 방법은 없습니다. "삭제되었습니다"라는 말을 믿을 것인가, 그뿐입니다.

본론: gitignore는 방어가 아니다

여기서부터가 이번 이야기의 가장 중요한 부분입니다.

왜 "gitignore 했으니까 안전하다"가 오해인가

gitignore는 git add, git commit, git push가 대상으로 삼는 파일의 범위를 결정하기 위한 파일입니다. 즉, git에 관한 이야기입니다. 아래의 요소들은 전혀 존중되지 않습니다.

• AI 코딩 지원 도구의 cwd 스캔 (이번 Grok Build, Cursor, Copilot Workspace 등)
• tar, zip, rsync -a
• Docker build context (.dockerignore를 별도로 작성하지 않으면 포함됨)
• IDE의 워크스페이스 동기화, 클라우드 저장 (VS Code Settings Sync, IntelliJ Cloud 등)
• OneDrive / Time Machine 등의 백업 소프트웨어 (폴더째로 백업 대상이 되는 경우)
• 누군가가 "이 리포(repo) zip으로 보내줘"라고 요청했을 때의 공유

"gitignore를 하면 비밀이 지켜진다"는 것은 방어의 1단계일 뿐입니다. 게다가 가장 취약한 단계입니다.

그림으로 나열해 보면, gitignore는 중앙에서 "내가 지키는 것은 git뿐이다"라고 주장하고 있고, 주변의 6개 영역은 완전히 무방비 상태라는 점이 명확히 보일 것입니다. AI CLI, tar, Docker, IDE 동기화, 백업, zip 공유 모두 평소에 흔히 사용하는 도구들입니다.

올바른 설계

비밀은 "처음부터 리포(repo) 하위에 두지 않는 것"이 올바른 설계입니다.

위의 표를 그림으로 나타내면 이렇습니다. 왼쪽의 잘못된 설계와 오른쪽의 올바른 설계를 나란히 놓았을 때, "gitignore 하고 있으니까 괜찮아"에서 "애초에 리포에 넣지 않는다"로의 발상 전환이 본질임을 알 수 있습니다.

저장 위치의 후보는 규모별로 선택할 수 있습니다.

• 개인: ~/.config/<app>/, 환경 변수, 1Password CLI (op), pass
• 소규모 팀: sops + age, Doppler, 1Password teams
• 중규모 이상: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager

"애초에 리포에 넣지 않는다"의 구현 패턴

Twelve-Factor App의 Config에서 말하는 내용을 실천하는 것입니다.

• 리포(repo) 내부에는 .env.example (플레이스홀더)만 둡니다.
• 실제 값은 개발자마다 ~/.config/<app>/.env에 보관합니다.
• 런타임(runtime)에서 로드 위치를 전환합니다 (예: dotenv-cli의 --path 옵션을 통해 외부 파일을 읽을 수 있음).
• 운영 환경(production)은 환경 변수 또는 외부 비밀 저장소(external secret store, Vault 등)로부터 주입받습니다.

이렇게 되어 있다면, 설령 AI CLI가 리포(repo)를 긁어간(scoop)다 하더라도 그곳에 비밀은 들어있지 않은 상태를 만들 수 있습니다.

부끄러운 이야기: 사실 저도 똑같은 함정에 빠져 있었습니다

솔직히 고백하겠습니다. 이 사건을 추적하면서 로컬에 조사용 HTML을 작성하고 있었는데, 그 HTML 초안에 클라우드 서비스의 account_id와 서버 IP를 그대로 적어두었습니다.

이유는 "위치한 곳이 docs/local/이고, gitignore를 하고 있으니 괜찮다"였습니다. 정확히 이번에 배운 것의 반대로 행동하고 있었던 셈입니다. 지적을 받고 나서야 깨닫고 마스킹(masking) 처리를 했습니다.

docs/local/을 gitignore 하고 있으니 git push를 해도 외부로 나가지는 않겠지만, 다음은 모두 리스크입니다.

• 다음 세션에서 AI CLI가 이 HTML을 컨텍스트 (context)로 읽을 가능성 (Grok Build가 재활성화되면 정말로 전송됨)
• 스크린샷을 찍어 Slack / 기사 / SNS에 붙여넣을 때 유출
• OneDrive / iCloud로 자동 동기화될 가능성
• 로컬 PC가 침해될 경우 통째로 유출
• zip 파일로 누군가에게 공유할 때 유출

"gitignore = 안전"이라는 오해는 저 자신도 평소에 저지를 만큼 뿌리가 깊습니다. 이번 사례는 그 오해를 드러냈다는 점에서 가치가 있었다고 생각합니다.

대처법 체크리스트

지금 즉시 (Grok Build를 사용해 본 적이 있는 사람)

• cat ~/.grok/logs/unified.jsonl | grep repo_state.upload | wc -l 명령어로 전송 이력 건수를 확인
• TUI에서 grok을 실행하고, /privacy에서 현재 상태를 확인한 뒤, /privacy opt-out을 입력 - 표시가 "Privacy: privacy mode"로 전환되는지 확인
• 임시 디렉토리에서 grok을 실행하여 opt-out 하는 @XBToshi의 방식도 추천합니다

오늘 밤까지 (금전적 리스크가 있는 비밀을 가지고 있는 사람)

• grok을 실행한 리포지토리(repo) 하위에 .env, secrets.*, credentials*, *.pem, *.key, id_rsa*, auth.json이 있는지 스캔 - gitignore를 했더라도, 커밋되지 않은 (uncommitted) 파일은 스캔 모드 (scan mode)에 따라 전송되었을 가능성이 있습니다. 금전적 리스크가 높은 것(클라우드 과금, SaaS API)은 보수적으로 로테이션 (rotate) 하세요.

이번 주까지 (본론인 설계 재검토)

• 리포지토리 내의 .env 계열을 외부로 빼내기. ~/.config/<app>/나 외부 시크릿 스토어 (secret store)로 이동 - 리포지토리 내부에는 .env.example 등의 플레이스홀더 (placeholder)만 남겨두기
• AI CLI 실행 전에 현재 작업 디렉토리 (cwd)의 비밀 파일을 체크하는 메커니즘을 도입 (Grok Build 외에도 유사한 사례가 앞으로 계속 나올 수 있습니다)

덤: many-ai-cli 이야기

저는 여러 AI CLI (Claude Code, Codex, Copilot, Cursor, opencode, Grok Build)를 병행해서 사용할 때, 승인 작업이나 진행 상황을 브라우저에서 일괄 관리하는 many-ai-cli라는 허브 CLI (Hub CLI)를 직접 만들어서 사용하고 있습니다. 이번 Grok Build도 many-ai-cli를 통해 실행했었는데, Grok의 repo_state.upload는 허브를 통하든 본체를 통하든 동일하게 동작했습니다 (Grok 본체 측의 설계이기 때문입니다). 허브 측에서 할 수 있는 보호에는 한계가 있다는 깨달음도 얻었습니다. 앞으로 허브 측에서 "실행 전에 cwd의 비밀 파일을 스캔하여 확인하는" 것과 같은 메커니즘을 넣을 여지는 있어 보입니다.

마치며

Grok Build 사례는 AI 코딩 지원 도구가 cwd를 "읽어가는" 것이 아니라 "멋대로 복사해서 보내는" 설계를 하고 있었다는 인시던트 (incident)였습니다. xAI는 신속하게 대응했지만, 삭제의 실효성은 검증할 수 없기에 신뢰(trust-only)에 의존해야 하는 상태입니다.

한편, 이 사례가 보여준 가장 보편적인 교훈은 "gitignore는 방어가 아니다"였습니다. gitignore를 제1의 방어라고 생각하며 리포지토리 하위에 비밀을 두는 설계는, AI CLI뿐만 아니라 tar, rsync, IDE 동기화, 백업 소프트웨어 앞에서도 취약합니다.

비밀은 처음부터 리포지토리 외부에 둔다. 리포지토리 내부에는 플레이스홀더만 둔다.

단순하지만, 실천하지 못하는 사람이 많습니다 (저를 포함해서). 이번 기회에 ~/.config/로 옮기는 것부터 시작해 보려고 합니다.

※ 헤더 이미지와 인포그래픽은 AI (이미지 생성)로 제작되었습니다.

작성자: ishizakahiroshi

시골 재택 근무 SE, 실무 18년 차. 백엔드, 인프라, AI 연동 전문. 업무 위탁 및 수주 접수 중, 풀 리모트(full remote) 대응 가능.

• Portfolio: https://ishizakahiroshi.github.io/
• GitHub: https://github.com/ishizakahiroshi
• X: https://x.com/ishizakahiroshi

이러한 상담은 언제든 환영입니다. 피드백이나 "우리도 같은 현상이 발생했다"는 공유도 기다리고 있겠습니다.

Discussion