나는 2022년 5월 작은 의료 교육 스타트업에서 GitHub로 옮겼다. 당시 GitHub Copilot은 일부 개발자에게 혁신적으로 다가왔지만, 주로 ReSharper나 IntelliSense처럼 코드 자동 완성을 돕는 도구에 가까웠다. 2025년 내내 AI에 회의적이던 나는 열성적인 지지자로 바뀌었다. 특히 GitHub Copilot 코딩 에이전트가 이슈를 바탕으로 풀 리퀘스트를 자율적으로 만드는 모습을 경험하면서 AI의 가능성을 실감했다. 이 도구는 2025년 5월 공개 프리뷰로 출시됐지만, 나는 그보다 먼저 사내에서 사용했다. 밀린 작은 버그들을 처리할 여력이 생긴다는 점이 강력하게 느껴졌다.

나는 2026년 5월 GitHub를 떠나 Bluesky에 합류했다. atproto 기반 생태계인 Atmosphere를 위한 AI 도구 Attie를 만드는 탐색 팀에서 제품 엔지니어로 일한다. 기능과 제품을 계획하고, 인프라를 다루며, 사용자 인터뷰와 커뮤니티 소통에도 참여한다. AI가 어떤 직무를 바꿀지 확실히 알 수 없는 만큼, 한 가지 기술에만 의존하지 않고 여러 분야의 역량을 넓히는 것이 중요하다고 본다.

atproto는 사용자가 자신의 데이터를 통제할 수 있도록 설계된 프로토콜이다. 데이터는 특정 회사의 데이터베이스에만 머무는 대신 사용자의 저장소에 놓인다. 사용자가 Bluesky를 떠나도 게시물과 댓글, 데이터, 연결을 가져갈 수 있고, Blacksky나 Witchsky 같은 다른 atproto 앱에서 같은 사람들과 계속 소통할 수 있다. 사용자가 쉽게 떠날 수 있다면 앱은 광고주보다 사용자의 요구에 맞춰야 한다는 것이 내 생각이다.

이런 구조는 앱 개발자에게도 이미 구축된 사용자 데이터와 도구를 제공한다. Atmosphere에는 4,500만 명이 있으며, 개발자는 정체성과 데이터 문제를 처음부터 해결하지 않고 앱 아이디어를 시험할 수 있다. 사용자 데이터는 JSON으로 구조화돼 있어 코딩 에이전트가 다루기에도 적합하다. 에이전트가 여러 앱에서 재사용할 수 있는 개인 클라우드에 접근하면, 사용자가 일일이 맥락을 제공하지 않아도 기존 데이터로 새로운 경험을 만들 수 있다. 나는 에이전트가 데이터를 읽는 것뿐 아니라 네트워크에 직접 참여하는 가능성에도 관심이 있다. delve.town은 에이전트가 atproto 계정을 만들어 참여하는 실험이다. atproto의 기록에는 작성한 계정의 서명이 붙고, Bluesky는 에이전트의 정체성을 책임지는 사람이나 조직과 연결하는 방법도 선보였다.

현재까지 atproto 데이터는 모두 공개돼 있었다. 이에 따라 활용 범위는 주로 공개 데이터를 다루는 앱으로 제한됐다. 비공개 데이터를 지원하는 작업이 진행 중이며, atproto spaces라는 알파 버전에서 이미 개발을 시작할 수 있다. 나는 AI와 에이전트 개발에 관심 있는 이들이 atproto를 살펴볼 만하다고 생각한다.

지금 내가 만드는 Attie의 코드는 전부 AI가 작성한다. 새 코드베이스를 다루는 세 명의 작은 팀이 빠르게 움직이는 환경이기에 가능한 방식이라고 본다. 매주 목요일 사용자 인터뷰를 하고, 그 결과에 따라 앱을 계속 조정한다. AI가 처음부터 큰 덩어리의 결과물을 내놓으면, 나는 불필요한 기능을 덜어내고 복잡한 사용자 경험을 간결하게 다듬는다. 예전처럼 층층이 쌓아 올리기보다 점토를 빚듯 소프트웨어의 알맞은 형태를 찾아가는 일에 가깝다.

Bluesky에서는 여러 모델과 도구를 자유롭게 시험하고 무엇이 효과적이었는지 공유한다. 나는 Codex, Claude, Polytoken, 직접 만든 도구를 번갈아 쓴다. 한 달에 한 번 ‘AI Slop Lovers’라는 모임에서 각자의 AI 설정과 배운 점을 나눈다. 비용을 관리하기 위해 작업에 맞는 모델을 고르고, 문맥 창도 합리적인 크기로 유지한다. 나는 100만 토큰까지 처리할 수 있는 모델에서도 보통 문맥 창을 25만 토큰 아래로 두려고 한다. Polytoken에서는 문맥 압축이 시작되는 시점을 설정할 수 있다. 문맥으로 매번 100만 토큰을 주고받지 않으면 비용을 줄일 수 있고, 문맥이 길어질수록 성능이 저하되는 현상에 관한 연구도 참고할 만하다.

코드 검토에는 플랫폼 팀이 만든 여러 모델의 적대적 검토 도구를 사용한다. 이 도구는 사전 커밋 훅에서 실행되며, 내 설정에서는 검토 결과에 따라 수정도 자동으로 진행한다. 사람이 코드를 살펴보기 전에 거치는 단계다. 이전에는 일주일에 풀 리퀘스트를 3~5개 보냈지만, 이제는 하루에 약 20개를 보낸다. 작은 단위로 변경하고 동료의 승인에 매번 의존하지 않는 점, 여러 작업을 동시에 진행하는 점이 이유다. Linear와 코딩 에이전트가 이슈를 가져와 작업을 끝내는 루프 엔지니어링 방식도 활용한다.

AI가 잘못했을 때 책임을 떠안는 사람이 되는 상황을 코리 닥터로는 ‘역 켄타우로스’라고 부른다. 나는 그런 결과가 불가피하다고 생각하지 않는다. AI가 자주 틀린다는 점을 알고, 실수를 발견하면 버그처럼 고치며 재발을 막는 팀을 만들 수 있다. 기술 업계가 10년 넘게 해 온 비난 없는 사후 분석과도 맞닿아 있다. 작은 팀에서 속도가 빨라지면 버그가 더 자주 눈에 띌 수 있다. 몇 달 걸리던 일이 일주일 만에 끝나는 만큼, 문제가 생길 것을 예상하고 대응해야 한다.

AI를 활용하는 엔지니어가 늘면 큰 팀이 더는 효율적이지 않을 수 있다는 생각도 든다. 사람이 적으면 일을 놓치거나 안전이 중요한 작업에 충분한 주의를 기울이지 못할 위험이 있다. 그래도 AI로 인력을 두 자릿수 비율로 줄일 수 있다는 주장에 일부 현실성이 있다고 본다. 동시에 소프트웨어에 대한 잠재 수요도 많다고 생각한다. 대기업이 줄고 작은 회사에서 일하는 사람이 늘어나는 형태로 일자리가 바뀔 가능성도 있다.

다양한 역할을 맡는 일은 지치기도 한다. 개발 환경을 계속 바꾸고 여러 작업 사이를 오가며 보안과 격리된 테스트 환경을 공부해야 한다. 어떤 날은 기능을 계획하고, 다른 날은 사용자 인터뷰를 하거나 제품 지원과 소통을 맡는다. 일은 예전보다 예측하기 어렵고, 만족스러울 만큼 자극적이지만 몹시 피곤하다. 내가 일반ist로 역량을 넓히는 전략이 맞는지도 확신할 수 없다. 경제·정치·사회 상황도 불확실하다. 미래를 두고 우리는 최선의 추측을 할 뿐이며, 누가 맞더라도 상당 부분 운에 달려 있을 것이다.

내가 경력을 돌아보며 배운 것은 소프트웨어 개발 외의 일을 다양하게 해 보는 것이 더 많은 기회를 만들었다는 점이다. 글쓰기, 발표, 만화 그리기처럼 여러 경험이 다른 사람과 구별되는 역량이 될 수 있다. 한 가지 일에만 매달리지 말고, 흥미를 느끼는 일을 다양하게 해보는 것이 내가 아이들에게 전하고 싶은 조언이다.