[🤖] AI를 적극 활용할 줄 알면 할 수 있는 일이 무궁무진해진다

✨ GPT-5.6 Sol의 요약 　

NAS·공유기·HTTPS를 연결하고 USB로 붙인 휴대폰의 깨진 UI까지 고치며, AI와 함께 내가 직접 다룰 수 있는 영역이 얼마나 넓어지는지 실감한 기록.

Computer Use로 NAS와 공유기 화면을 함께 봤다

오늘 먼저 부딪힌 건 NAS와 공유기였다.

서비스를 외부에서도 쓰려면 Docker만 띄워서는 안 됐다. 도메인이 회사 인터넷까지 찾아오고, 공유기가 요청을 NAS로 넘기고, NAS가 인증서를 제시한 다음, Reverse Proxy가 내부 컨테이너로 보내야 했다. 예전 같았으면 공유기와 NAS 관리자 화면을 번갈아 보며 매뉴얼부터 찾았을 일이다.

이번에는 내가 관리자 화면에 로그인하고 변경 범위를 승인한 뒤, AI가 Computer Use로 실제 화면을 보면서 같이 진행했다.

브라우저 위에는 AI가 직접 디버깅을 시작했다는 표시가 떴다. 내가 보던 화면을 그대로 넘겨주고, 어디가 정상이고 어디가 막혔는지 같이 확인했다.

기존 설정을 먼저 확인하고, 건드리면 안 되는 홈페이지와 메일 연결은 그대로 두고, 새 서비스에 필요한 항목만 추가했다. Mac에서 만든 Docker 이미지를 NAS에 올리고, 별도 Compose 환경으로 실행하고, Reverse Proxy와 HTTPS 인증서를 연결했다.

여기서는 역할이 더 선명했다. 로그인과 목표 설정, 기존 환경을 어디까지 보존할지에 대한 판단, 실제 변경 승인은 내가 맡았다. AI는 내가 열어준 화면 안에서 공유기와 NAS 설정을 읽고, Docker와 Reverse Proxy, 인증서까지 서로 다른 기술 층을 연결했다.

이 과정에서 AI가 마음대로 외부 설정을 바꾼 것은 아니다. 로그인과 중요한 변경 승인은 내가 했고, 기존 환경을 되돌릴 수 있게 남겨두면서 한 단계씩 결과를 확인했다. 실제 발송은 먼저 승인한 내부 번호 한 건에만 제한해 수신을 확인했다. 외부 연결까지 마친 뒤에는 휴대폰의 모바일망으로 HTTPS 주소에도 접속했다.

기존 기능과 데이터를 옮기고 제한된 문자 한 건을 확인한 과정, 외부 요청이 NAS 안의 서비스까지 들어오는 구조는 레거시 연차 자동화의 NAS 이관과 외부 HTTPS 연결에 따로 적었다.

휴대폰 화면을 직접 볼 수는 없나

여기까지 하고 나서 AI에게 물었다.

네가 직접 휴대폰 화면을 보고 조작할 수는 없는 거임? 그런 툴 없나?

안드로이드 가상화 기술까지 있는 세상인데, 실제 USB로 연결된 휴대폰 하나를 AI가 못 본다는 게 이상했다. 알아보니 adb로 휴대폰 상태를 읽고 조작할 수 있고, scrcpy를 쓰면 실제 화면을 Mac에 그대로 띄울 수도 있었다.

몇 번 대화를 주고받고 나니 진짜 내 휴대폰 화면이 Mac에 나타났다.

Mac 화면 안에 내 휴대폰이 그대로 떠 있고, 그 휴대폰에는 Codex가 작업 중이라는 알림까지 같이 보였다. 그때부터 AI가 그냥 질문에 답하는 창이 아니라, 내가 보고 만질 수 있는 실제 기기를 함께 보는 도구처럼 느껴졌다.

실제 휴대폰을 보면서 UI를 고쳤다

scrcpy는 휴대폰 화면을 띄워두는 데서 끝난 도구가 아니었다.

USB 디버깅을 켠 실제 휴대폰을 Mac에 연결해두니 AI가 adb로 화면을 캡처하고, UI 구조를 읽고, 터치하고, 스크롤하고, 글자를 입력할 수 있었다. scrcpy로는 그 과정을 내가 실시간으로 같이 봤다. 둘 중 하나를 고르는 게 아니라, 화면은 scrcpy로 보고 반복 조작과 증거 확보는 adb로 하는 식이었다.

모니터에서는 AI가 화면을 읽고 다음 조작을 정리하고 있었고, 바로 앞 실제 휴대폰에는 같은 서비스가 떠 있었다.

휴대폰 Chrome에서 내가 만들고 있던 서비스를 열어 로그인하고 메뉴를 돌아다녔다. 그제야 PC 브라우저의 작은 창만 흉내 내서는 제대로 보지 못했던 문제가 그대로 튀어나왔다. 모바일에서 사이드바가 화면 대부분을 먹고 있었고, 카드와 글자가 세로로 찌그러졌다. 직원 목록의 제목과 버튼도 한 글자씩 떨어졌고, SMS 이력과 연차 관리의 필터는 무슨 항목인지 읽을 수도 없었다.

문제가 있다는 설명보다 화면 한 장이 더 셌다. 직원 목록 네 글자가 한 글자씩 아래로 떨어져 있었고, 필터는 아이콘과 몇 글자만 남아 있었다. PC에서 창 폭을 줄여볼 때는 놓쳤던 결함이 실제 손바닥 크기 화면에서는 하나도 숨지 않았다.

아래 비교 이미지는 모두 왼쪽이 수정 전, 오른쪽이 수정 후다.

고치고 끝낸 것도 아니었다. 수정한 화면을 다시 배포하고, 같은 휴대폰에서 다시 로그인하고, 메뉴를 열고, 스크롤하며 확인했다. 직원 목록은 가로로 읽을 수 있게 됐고, 넓은 표는 억지로 찌그러뜨리지 않고 필요한 만큼 스크롤하게 바뀌었다.

나는 화면을 보며 “이건 읽을 수 없다”, “표는 찌그러뜨리지 말고 넘겨서 봐야 한다”는 기준을 줬다. AI는 그 기준을 실제 레이아웃과 코드 수정으로 연결했다. 배포한 뒤 제대로 고쳐졌는지 판단하는 일은 다시 내 눈으로 돌아왔다.

필터가 많은 화면은 더 노골적이었다. 작은 모바일 폭에 모든 입력칸을 한 줄로 욱여넣은 게 원인이었다. SMS 이력과 연차 관리 화면을 두 열 중심으로 다시 배치하고 날짜 범위는 별도 행으로 내렸다.

이 전후 화면은 운영 데이터를 찍어 옮긴 것이 아니다. 실제 휴대폰에서 문제를 찾은 뒤, 같은 합성 데이터와 모바일 크기로 과거 코드와 수정 후 코드를 다시 렌더링해 비교한 것이다. 눈으로 본 불편이 코드 수정으로 이어지고, 다시 실제 기기 확인으로 돌아오는 흐름이 생겼다.

창처럼 보이는데 앱은 아니었다

실제 휴대폰 화면을 보며 고친 것만으로도 신기했지만, 더 웃겼던 건 그다음이었다.

나는 BetterTouchTool에서 fn+s를 누르면 scrcpy 창이 나타났다 사라지게 만들고 싶었다. 다른 앱들은 전부 잘 되는데 이상하게 scrcpy만 안 됐다. 설정 화면을 캡처해서 AI에게 보여줬다.

원인은 단순했다.

내가 BetterTouchTool에서 선택한 것은 일반적인 macOS 앱 번들이 아니라 Homebrew 아래에 설치된 scrcpy 실행 파일이었다. 화면에는 앱처럼 창이 떠 있지만, BetterTouchTool의 Show / Hide Specific Application이 기대하는 평범한 .app과는 성격이 달랐다. 그래서 다른 앱에 먹히던 방식이 scrcpy에서는 제대로 먹히지 않았던 것이다.

휴대폰 문제가 아니었다. 단축키 자체도 문제가 아니었다. 눈앞에는 똑같이 하나의 창으로 보이는데, Mac이 그 창을 어떤 프로세스와 애플리케이션으로 인식하느냐의 문제였다.

나한테는 다른 앱과 다를 것 없는 창이었다. AI는 내가 보여준 BetterTouchTool 설정과 실제 실행 경로를 이어서, 왜 이 창만 평범한 앱처럼 움직이지 않는지 찾아냈다.

결국 일반 앱을 보이거나 숨기는 액션 대신, scrcpy 프로세스를 직접 찾아 실행 상태와 창 표시를 제어하는 셸 스크립트로 바꿨다. 같은 fn+s인데 이제는 내가 원했던 대로 움직였다.

설명을 듣는 순간 그냥 웃음이 터졌다.

와… 이런 것까지 된다고?

내가 모든 기술을 미리 알 필요가 없어졌다

예전 같았으면 여기서부터 검색할 게 너무 많았다.

Docker와 NAS, 공유기, DNS, 인증서, Reverse Proxy부터 Android 디버깅, adb와 scrcpy, macOS가 창과 앱을 구분하는 방식까지. 하나씩 검색했다면 서로 다른 분야의 문제로 흩어졌을 것들이 오늘은 한 번의 실행 흐름 안에 들어왔다.

각각은 아주 어려운 기술이 아닐 수도 있다. 하지만 내가 평소에 깊게 다루지 않던 분야다. 무엇을 검색해야 하는지도 모르는 상태에서는 작은 문제 하나가 몇 시간짜리 일이 되기 쉽다.

AI가 끼어드니 흐름이 달라졌다.

나는 원하는 결과를 말했다. 실제 화면을 보여줬다. 안 되는 지점을 다시 보여줬다. AI는 Docker, NAS, 공유기, DNS와 HTTPS뿐 아니라 휴대폰, adb, scrcpy, macOS 창과 BetterTouchTool 설정까지 한 흐름으로 이어서 봤다.

한쪽에서는 NAS와 브라우저를 보고, 다른 세션에서는 Android와 SMS 경로를 파고들고, 또 다른 창에서는 결과를 검토했다. 화면이 여러 개로 갈라져도 내 역할은 같았다. 목표를 정하고, 어디까지 바꿀지 승인하고, 결과가 맞는지 판단하는 일이었다.

AI가 많은 지식을 말해준 것만으로는 이런 느낌이 들지 않았을 것이다. 그 지식이 터미널 명령으로, 휴대폰 터치로, 관리자 화면의 설정으로 이어지고, 마지막에는 내가 쓰는 화면의 변화로 돌아왔다. 답변이 아니라 실행이었다.

내가 그 모든 층을 미리 공부해둔 것은 아니다. 그렇다고 아무것도 안 한 채 “알아서 해줘”라고 던진 것도 아니다. 나는 계속 결과를 보고, 이상한 지점을 짚고, 다음 질문을 했다.

예전에 AI 리터러시는 결국 지시하는 능력이다라고 썼다. 오늘은 그 말이 조금 더 현실적으로 느껴졌다.

지시한다는 건 멋진 프롬프트 한 줄을 쓰는 일이 아니었다. 내가 원하는 상태를 설명하고, 지금 보이는 화면을 건네고, 결과가 다르면 다시 잡아주는 일이었다. 그걸 반복할 줄 알면 내가 원래 모르던 분야도 생각보다 훨씬 깊이 들어갈 수 있었다.

AI가 내 손과 눈의 범위를 넓힌다

AI를 쓴다고 갑자기 내가 모든 기술의 전문가가 된 것은 아니다.

오히려 직접 해보면 AI가 엉뚱한 판단을 하거나, 내가 원하지 않은 방향으로 너무 멀리 가는 순간도 계속 나온다. 내가 무엇을 원하는지 모르거나 결과를 볼 기준이 없으면, AI가 아무리 많은 일을 해도 제대로 된 결과까지 가기 어렵다.

그런데 반대도 맞다.

내가 목표를 정하고, 실제 상태를 보여주고, 틀린 방향을 잡아내며 AI를 계속 움직일 수 있다면 이야기가 완전히 달라진다. 예전에는 “이건 내가 모르는 분야라서” 하고 넘겼을 일도 직접 만져볼 수 있다. 프로그램 하나를 설치하는 데서 끝나는 게 아니라, 실제 기기를 연결하고, 화면을 보고, 동작을 확인하고, 서버에 올리고, 불편한 부분을 다시 내 방식대로 바꿀 수 있다.

그래서 이제는 결과를 설명해달라고만 하지 않고, 화면이 중요한 일에는 그냥 “네가 직접 확인해봐. Computer Use로.”라고 말하게 됐다.

점점 뼈와 살로 새겨지는 개발 패러다임 전환에서 개발자의 중심이 손으로 코드를 치는 능력보다 기획, 설계, 실행, 피드백으로 옮겨가고 있다고 적었다. 오늘 내가 한 일도 딱 그 흐름이었다.

코드를 얼마나 외우고 있느냐보다, 실제로 무엇을 만들고 싶은지가 먼저였다. 그다음은 AI에게 맥락을 보여주고, 도구를 연결하고, 결과를 보며 계속 고치는 일이었다.

오늘은 정말 실감했다.

AI를 적극적으로 활용할 줄만 알면, 내가 할 수 있는 일은 생각보다 훨씬 많아진다. 그냥 답변을 빨리 받는 정도가 아니다. 내가 직접 볼 수 있는 것, 만질 수 있는 것, 고칠 수 있는 것의 범위가 넓어진다.

진짜 무궁무진하다는 말이 과장처럼 느껴지지 않았다.