우에하라 마사요시(上原正吉) (EarthLink Network Co., Ltd.). Claude Code를 개발의 주체로 삼아 20개가 넘는 제품을 혼자서 동시에 개발하고 운영하고 있습니다. 이 글은 현장에서 직접 측정한 기록입니다.
이 글은 연재 '자신의 서비스를 스스로 지키기 ── AI 시대의 자위 보안'의 제4회차입니다. 스스로 할 수 있는 검사는 스스로 하고, 어려운 부분은 EarthLink Network가 대행하여 검사하고, 수정할 수 없는 약점은 저희가 수정합니다.
연재 목차
- AI로 누구나 공격할 수 있는 시대 ── 당하기 전에 자신의 사이트를 스스로 검사하기
- 공격하는 측이 가진 도구 ── AI가 스스로 공격을 진행한다는 것은
- 검사를 시작하기 전에 ── 검사의 전체적인 그림과, 본판을 망가뜨리지 않는 선 긋기
외부에서 공격하며 검사하기 ① ── 준비와 첫 실행까지 (본 기사) - 외부에서 공격하며 검사하기 ② ── 공격 도구와 정규 도구로 발견되는 것은 다르다 (예정)
- 자신이 작성한 코드를 검사하기 ── 정적 분석(Static Analysis) (예정)
- 사용하고 있는 부품의 약점을 검사하기 ── 의존 라이브러리 (Dependency Library) (예정)
- 인프라 설정 오류를 검사하기 (예정)
- 검사 결과를 한곳에 모아, 무엇부터 고칠지 결정하기 (예정)
- 발견된 약점의 수정 방법 ── 세 가지 길 (예정)
- 스스로 고치기 어려울 때 ── 유지보수 계약이라는 선택 (예정)
- 매일 자동으로 계속 검사하기 ── 만드는 시대에서, 지키는 시대로 (예정)
지금까지의 이야기를 이번부터 실제로 진행합니다. 공격하는 측이 실제로 사용하는 방식과 동일한 방식으로 저희 서비스인 promptflow를 스스로 검사했습니다. 이번 회차와 다음 회차에는 자료를 보면서 직접 같은 것을 재현할 수 있도록, 입력 내용과 그 결과 화면을 하나씩 나란히 보여드릴 예정입니다. 이번에는 준비 단계부터 최초 실행까지입니다.
사용하는 도구는 두 가지 성격의 것을 나열합니다. 하나는 정규적이고 허가된 용도로 배포되는 검사 도구입니다. 다른 하나는 공격하는 측이 실제로 사용하는, 제한 없는 도구입니다. 같은 방식이지만, 정식 버전과 실제 수준이라고 할 수 있습니다. 둘 다 스스로 다음 단계를 결정하며 진행하는 '자율형'이며, 고기능적이고 고가인 AI는 사용하지 않습니다. 저렴한 모델이나 무료 도구를 이용해 구동합니다.
단 하나만 미리 약속드립니다. 이 검사는 본 서비스에는 적용하지 않고, 본 서비스에 일절 닿지 않는 자사 코드의 복사본을 대상으로 진행했습니다. 왜 그렇게 하는지, 어디까지가 스스로 검사할 수 있는 범위인지라는 선 긋기는 지난번(제3회차)에서 정리했습니다. 이번에는 그 선을 지킨 상태에서 실제로 구동하는 부분만 보여드립니다.
결과를 먼저 말씀드리겠습니다. 정규 버전의 검사 도구를 저렴한 모델로 구동하고, 인증(로그인)의 4가지 진입점에 범위를 한정하여 검사했을 때, 감사(누가 무엇을 했는지 기록)와 세션(로그인 상태)과 관련된 실제 약점 3건이 발견되었습니다. 심각한(critical/high) 문제는 없었으며, 기계의 평가는 중간 정도(MEDIUM)가 2건, 정보 수준(INFO)이 1건입니다. 사용된 AI 이용료는 **약 68엔($0.45)**이었습니다. 게다가 실제 수준의 공격 도구와 정규적인 외부 테스트 도구도 구동 중인 복사본에 외부에서 실행했습니다. 발견된 것이 도구별로 어떻게 다른지, 그 내용 비교는 다음 회차에 맡기고, 이번에는 '어떻게 준비하고, 어떻게 구동하는가'를 하나씩 보여드리겠습니다.
사람의 손으로도 검사는 가능합니다. 하지만 지금 이것을 AI 도구로 하는 것에는 명확한 이유가 두 가지 있습니다.
첫째는 속도와 범위입니다. promptflow에는 외부에서 접근할 수 있는 진입점(API)이 231개 있습니다. 이것을 하나하나 사람이 손으로 조사한다면 며칠이 걸립니다. 그 사이에도 공격하는 측은 자동으로 쉬지 않고 조사하고 있습니다. 지키는 쪽만으로는 따라잡기 어렵습니다. AI 도구라면, 어느 진입점을 어떤 순서로 조사할지 스스로 결정하여 한 번에 파악합니다. 공격하는 측이 AI에게 계획을 세우게 한다면, 지키는 측도 같은 AI에게 계획을 세우게 하는 것입니다. 이것이 제2회차에서 작성한 '지키는 쪽에도 똑같은 AI가 있습니다'의 실제 모습입니다.
둘째는 혼자서는 파악할 수 없는 넓이를 커버할 수 있다는 점입니다. 현재 웹 서비스는 많은 외부 부품이나, 연결된 사후 서비스와 복잡하게 얽혀 있습니다. 자신의 코드만 완벽하더라도, 사용하고 있는 부품이나 연결된 곳이 약하면 그곳이 진입점이 됩니다. 이 얽힘을 사람이 머리로 전부 추적하는 것은 이미 불가능합니다. 그렇기 때문에 도구에 넓게 봐달라고 요청하여 관련 정보까지 모으고 자동으로 조사하는 것이 현실적인 방법이 되었습니다.
여기서는 실제 절차를 설명합니다. 먼저 정식 검사 도구를 처음부터 끝까지 한 번 실행합니다. 자료를 보면서 똑같이 재현할 수 있도록 작성하겠습니다.
먼저 사용하는 것은 Strix라는 오픈소스 AI 자율 검사 도구입니다. 2회차에서 이야기했던 '자신의 앱 약점을 찾기 위한' 방어 측면의 도구 중 하나이며, 공격자가 사용하는 자율형 도구의 정식 버전이라고 할 수 있습니다. 명령어 한 줄만 입력하면 되므로 특별한 장비는 필요 없습니다. 평소에 사용하던 컴퓨터에서 구동됩니다.
설치 후에는 strix --version을 입력하여 버전 번호가 표시되면 성공입니다. 만약 command not found(명령어를 찾을 수 없음)라고 표시된다면, 설치된 위치가 컴퓨터가 명령어를 찾는 경로(PATH)에 포함되지 않은 것입니다. which strix로 위치를 확인하고, 그 위치를 PATH에 추가해야 합니다. 검사는 격리된 Docker 컨테이너(컴퓨터 안에 만들고 외부와 분리한 공간. Docker는 이를 구동하는 소프트웨어입니다) 내에서 실행되므로, 먼저 Docker를 켜 두어야 합니다. Docker가 작동하지 않으면 나중에 검사를 시작해도 멈춥니다.
이 도구는 내부적으로 하나의 AI 서비스를 구동합니다. 이는 공격자가 AI에게 계획을 세우도록 하는 것과 같은 원리입니다. 여기서 중요한 것은 비싸고 고기능인 모델을 선택하지 않는 것입니다. 보안 검사는 복잡한 추론보다는, 진입점을 하나하나 꾸준히 시도하는 단순 작업의 누적입니다. 따라서 저렴한 모델로 양을 채우는 것이 실제로 공격자가 하는 행위에 더 가깝습니다. 이번에는 DeepSeek라는 저가 모델을 선택하고 해당 사용 키를 설정했습니다.
여기서 한 가지, 막히기 쉬운 부분이 있습니다. 모델과 도구 연결 설정을 맞추지 않으면 검사가 시작되기 전에 '연결할 수 없습니다'라고 표시되며 멈춥니다. 저 역시 처음에는 거기서 멈췄습니다. 저가 모델을 OpenAI 호환 방식으로 지정하고 연결 지점(API 주소)을 명시했더니 작동했습니다. 잘 안 될 때는 먼저 사용 키가 정확한지, 연결 주소가 맞는지 확인해 보세요. 설정을 하나 고치면 작동합니다. 아울러, 실행 전에 모델의 잔액을 확인해 두는 것이 좋습니다. 나중에 다시 잔액을 보면 실제로 얼마를 썼는지 정확히 알 수 있기 때문입니다.
지난번 기준과 마찬가지로, 검사 대상은 운영 환경(Production)이 아닙니다. 자신의 코드 사본을 만들어서 그곳에 적용합니다. 사본이라면 검사 도구가 무엇을 하더라도 실제 운영 환경에는 전혀 영향을 주지 않습니다.
사본을 만들었다면, 검사 범위를 좁힙니다. 서비스 전체에는 231개의 진입점이 있지만, 이번에는 그중 인증(로그인 키를 주고받는 부분)의 4개 진입점으로만 한정했습니다. 키 교환・로그아웃・본인 확인・키 업데이트입니다. 범위를 좁히면 비용이 적더라도 표면만 훑고 지나가는 것이 아니라 하나하나 깊게 조사하는 곳까지 도달할 수 있습니다. '넓고 얕기'보다 '좁고 깊기'가 첫 단계로는 더 확실합니다.
준비가 되면, 검사 대상과 조사하고 싶은 내용을 지정하여 실행합니다. 여기서 가장 중요한 것은 비용 상한선을 함께 지정하는 것입니다. 너무 많이 사용하면 거기서 자동으로 멈춥니다. 이것이 없으면 예상치 못한 금액이 나올 위험이 있습니다.
지정한 내용은 한마디로 '이것은 내 코드에 대한 허가된 자체 검사입니다. 결과만, 어느 파일의 어디에서 알 수 있는 형태로 보고해 주세요'라는 것입니다. 실제로 공격을 가하는 것이 아니라, 약점을 찾아보고서하게 한다는 지시입니다. 비용 상한선은 이번에 $1.00로 설정했습니다. 실제로는 그 정도까지 도달하지 못하고 자동으로 종료되었습니다.
실행하면 먼저 격리된 환경(Docker 컨테이너)이 구동되고, 검사에 사용되는 스킬이 로드되며, AI가 스스로 검사 계획을 세우기 시작합니다. 사람이 '다음은 이것을 조사해라'라고 지시하지 않아도, 이전 결과를 보고 다음에 무엇을 조사할지 스스로 결정합니다.
로드된 스킬 중에는 counterevidence(반증)라는 이름의 것이 있습니다. 이는 '이 진입점이 위험할지도 모른다'고 발견했을 때, 일부러 반대 증거를 찾아보고 정말로 위험한지 스스로 검증하는 장치입니다. 이 반증 메커니즘이 나중에 나올 '발견했다고만 끝내지 않는' 행동으로 이어집니다. 2회차에서 공격자의 도구가 스스로 계획을 진행한다고 말씀드렸는데, 그것을 정식 버전의 도구로 자신의 서비스에 적용하고 있는 것입니다. 계획을 AI가 스스로 결정하여 진행하는 방식은 공격자 도구와 같습니다. 다른 점은 검사 대상이 자신이라는 점입니다.
얼마 지나지 않아 AI는 스스로 검사를 완료합니다. 끝나면, 실행 기록과 절차 ②에서 준비한 잔액을 비교하여 실제로 얼마가 사용되었는지 확인합니다.
실제 비용은 $0.45로 일본 엔화로 약 68엔이었습니다. 처리 건수는 235회였고 시간은 약 9분이 소요되었습니다. 이전에 고가의 모델(gpt-4.1)을 사용하여 앱 전체(231개의 진입점)를 한 번에 조사했을 때는 $3.04가 사용되었으나 상한선에 도달하여 중단되었고, 깊숙한 곳까지 도달하지 못해 취약점을 하나도 확정할 수 없었습니다. 이번에는 범위를 인증의 4개 진입점으로 좁히고 저렴한 모델로 교체했더니, $0.45만으로 끝까지 완료되었고, 실제 취약점 3건을 발견했습니다. '비싼 모델이 아니면 검사할 수 없다'는 것은 아닙니다. 오히려 저렴한 모델로 양을 늘려가는 것이 이러한 종류의 작업에는 적합합니다.
이번 검사를 통해 인증의 4개 진입점에서 실제 취약점 3건이 발견되었습니다. 이들은 모두 당장 서비스가 탈취될 정도의 심각도(critical・high)는 아니며, 기계적 평가는 중간 수준(MEDIUM)이 2건, 정보 수준(INFO)가 1건입니다. 다만, 인증에서 가장 중요한 두 가지 기반인 감사(누가 무엇을 했는지 기록)와 세션(로그인 상태)에 균열이 있다는 지적입니다.
세 가지를 일상적인 말로 풀어서 설명하겠습니다.
로그아웃 시, 로그인이 제거되었는지 확인하지 않고 '성공'으로 반환함 (정보 수준): 로그아웃 진입점은 로그인 제거 요청을 상대에게 보내지 않은 상태에서, 상대가 거부하든 연결되지 않든 상관없이 '성공했습니다'라고 응답하고 기록에도 '세션을 삭제했다'고 작성했습니다. 시도한 8가지 중 7가지가 이와 같았습니다. 기계적 평가는 가장 낮은 정보 수준입니다. 이는 키 업데이트에 사용되는 키 사본을 먼저 얻은 상대방이, 이용자가 로그아웃했다고 생각한 후에도 새로운 로그인 키를 계속 생성할 수 있다는 위험의 씨앗입니다.
감사 기록에서 '누가'를 확인하지 않고 신뢰함 (중간 수준): 누가 무엇을 했는지 기록하는 부분 중 '누가'에 해당하는 부분을, 서명(위조되지 않았음을 증명하는 표시)을 확인하지 않은 키의 내용으로부터 읽어내고 있었습니다. 즉, 로그인하지 않은 상대방이라도 원하는 이름을 기록에 끼워 넣을 수 있다는 것입니다. 기록이 나중에 증거로 사용될 수 없게 됩니다.
키 조각이 로그에 유출됨 (중간 수준): 키 업데이트가 실패했을 때, 받은 키의 처음 12글자와 길이, 상대방으로부터 돌아온 오류 메시지를 그대로 로그에 작성하고 있었습니다. 해당 도구는 로그를 볼 수 있는 사람이 키 금고를 볼 수 있는 사람보다 많다고 판단하여, 여기서 유출될 위험이 있다고 평가했습니다. 게다가 두 줄 위에는 '오류 내용과 키는 이용자에게 반환하는 화면에 넣어서는 안 된다'라는 규칙이 적혀 있습니다. 이용자에게 반환하는 쪽은 이를 지키고 있지만, 로그를 작성하는 쪽만 지키지 않았습니다.
중요한 것은 기계가 '발견했을지도 모른다'에서 멈추지 않고, counterevidence (반증) 메커니즘을 통해 하나씩 재시도하여 실제로 발생하는 것만을 3건으로 좁혔다는 점입니다. 로그아웃과 키 조각의 2건은 Strix가 격리한 컨테이너 안에서 통신 상대나 기록 쓰기 대상을 대체품으로 교체하여, 수정하기 전 코드를 실제로 구동해보고 발생하는 것을 확인했습니다. 감사 관련 1건은 코드 흐름을 추적하여 보여주었습니다. 발견했다고만 말하는 것이 아니라, 진짜인지 스스로 확인합니다. 이곳이 단순히 경고 목록만 나열하는 오래된 검사와 다른 점입니다. 3가지 각각에 대해 어떤 파일의 어느 부분에서, 어떻게 재현할 수 있는지, 그리고 어떻게 수정해야 하는지까지 제공됩니다.
한편, 이 도구는 '여기에 이러한 종류의 위험은 없다'라는, 없다는 증명도 해 주었습니다. 데이터베이스나 명령어 삽입(Injection) 또는 SSRF (서버를 속여 다른 곳으로 통신하게 만드는 공격)와 같이 자주 언급되는 몇 가지 위험들이 이 범위에서는 구조적으로 발생할 수 없음을 보여줍니다. 발견된 취약점만큼이나 이 '없음'의 증명도 중요하지만, 그 해석 방법과 왜 그것이 가치가 있는지에 대해서는 다음번에 자세히 다루겠습니다.
여기까지는 정식 버전의 도구가 코드를 읽어서 취약점을 찾았습니다. 다음은 공격자가 실제로 사용하는, 본물급 도구입니다. 제3회에서 이름을 언급했던 HexStrike가 그것입니다. 이 도구는 코드를 읽지 않습니다. 실행 중인 서비스를 외부에서, 낯선 타인의 입장에서 시도합니다. 그러기 위해서는 검사 대상 서비스가 실제로 구동되어 있어야 합니다.
하지만 실제로 구동한다고 해도 본 서비스는 아닙니다. 외부에서는 접근할 수 없는 전용 환경 안에, 자신의 서비스 로그인 처리 로직만 복사한 일회성 복사본을 띄웁니다. 검사는 이 복사본에만 통신을 집중합니다.
이 전용 환경에서 작동하는 것은 세 가지입니다. 테스트 대상(자신의 로그인 처리 로직 복사본), 본인 인증을 대신 수행하는 간이 서버, 그리고 공격 도구입니다. 상대방은 오직 이 일회성 복사본뿐이며, 실제 서비스나 타인의 사이트에는 전혀 영향을 미치지 않습니다. 이번 연재에서 다루는 것은 어디까지나 스스로를 검사하는 것에 한정됩니다.
먼저, 공격 측에서 사용하는 실제 수준의 도구에 대해 알아보겠습니다. 흥미로운 점은 여기에 전달하는 것이 오직 서비스의 위치(주소)뿐이라는 것입니다. 나머지는 저렴한 AI가 '다음으로 무엇을 시도할지' 스스로 결정합니다. 사람이 절차를 작성하는 것이 아닙니다.
왼쪽 숫자는 몇 번째 시도인지를 나타냅니다. 오른쪽 숫자는 그 시점까지 사용된 AI 양을 계산하여 산출된 비용입니다. 1번째 시도에서 AI는 '먼저 서비스가 작동하는지 확인하고 응답 헤더를 살펴보자'라고 생각하며 스스로 검사 도구를 선택했습니다. 4번째 시도에서는 어떤 값을 보내든 로그인 키(토큰)가 나온다는 내용이 있어 침투할 수 있을 것 같다는 취지로 작성했고, 5번째 시도에서 이를 심각한 후보로 기록했습니다. 이렇게 24번째 시도까지 진행하여 시도의 상한선에 도달해 멈췄습니다. 총 제시된 후보는 6건입니다. 여기까지 소요된 비용은 약 3센트, 일본 엔화로 5엔 정도입니다(사용량 계산 기준이며, 잔액은 센트 단위에서는 변동이 없었습니다). 고기능의 최신 AI가 아닙니다. 그저 저렴한 AI를 많이 구동했을 뿐입니다.
여기서 중요한 점을 하나 말씀드립니다. 이 6건은 아직 '후보'일 뿐입니다. 저렴한 AI를 많이 구동하면, 실제 취약점과 함께 자신감 넘치는 오해들 또한 많이 발생합니다. 실제로 이번 후보 중에도 자세히 조사해보면 자신의 코드의 약점이 아니라 간이 서버나 테스트 방식에서 비롯된 오해가 섞여 있었습니다. 어떤 것이 진짜이고 어떤 것이 오해인지를 하나하나 분류하는 과정은 다음 시간에 상세하게 보여드리겠습니다. 이번에는 '위치를 전달하기만 하면, 저렴한 AI가 스스로 공격적인 시도를 진행하고 몇 센트의 비용으로 후보들을 제시한다'는 실행 자체를 봐주십시오.
제시된 후보 중 하나는 코드 분석 도구로는 절대 발견할 수 없는 것이 있었습니다. 응답에 포함되어야 할 안전을 위한 설정(보안 헤더, Security Header)이 통째로 빠져 있었다는 취약점입니다.
이 헤더란 브라우저에게 '이 표시는 다른 사이트에 임베드하지 말라', '통신은 반드시 암호화하라'와 같은 약속을 전달하는 작은 설정입니다. 이것이 누락되면, 표시가 탈취되거나 통신이 도청될 수 있는 틈으로 이어집니다. 코드 내부에는 나타나지 않는, 작동 중인 서비스의 '겉모습 바깥쪽'에 존재하는 설정이기 때문에, 응답을 실제로 받아보지 않으면 빠져 있는지 알 수 없습니다. 코드를 읽기만 하는 도구는 작동하는 응답 자체를 보지 못하므로, 원리적으로 이것을 발견할 수 없습니다. 외부에서 시도해보는 측의 진정한 성과였습니다.
이 '외부에서 시도하여 발견되는 것'과 '코드를 읽어서 발견되는 것'은 구조적으로 다릅니다. 그 차이를 정면으로 나란히 보여주는 것이 다음 시간 주제 중 하나입니다.
여기까지 외부에서 시도하는 측에는 공격 도구를 사용했습니다. 하지만, 외부에서 시도하는 것 자체는 정상적이고 허가된 용도의 도구로도 할 수 있습니다. 게다가 무료부터 시작할 수 있습니다. 동일한 작동 복사본에 정식적인 외부 테스트 도구 두 가지를 구동해 보았습니다.
첫 번째는 누구나 무료로 사용할 수 있는 ZAP라는 도구입니다.
ZAP에는 서비스 진입점 목록(OpenAPI 사양)을 전달합니다. 그러면 그 목록을 기반으로 지정된 검사 항목들을 하나씩 작동 중인 복사본에 적용해 나갑니다. 화면에 '가져온 엔드포인트 8/전체 25 URL'이라는 메시지가 나온 후, 인젝션 및 OS 명령어 삽입 공격, XML 악용 공격, 클라우드 설정 정보 노출 등의 항목을 순차적으로 검사합니다. 총 약 120개의 항목을 구동했습니다(이 중 117개는 문제없이 통과했습니다). 무엇이 나왔는지에 대한 집계는 결과 화면이므로 다음 시간에 보여드리겠습니다. 여기서는 '무료 도구로도 동일한 복사본에 외부에서 체계적인 검사가 진행되는' 실행 과정을 봐주십시오.
두 번째는 회사용 상용 도구인 StackHawk입니다. 영구 무료 플랜은 없지만, 처음 14일 동안은 무료로 체험할 수 있습니다. 이번에는 그 기간을 활용하여 사용했습니다.
StackHawk 역시 실행 중인 복사본에 동일한 진입점 목록을 사용하여 테스트합니다. 먼저 서비스의 진입점을 자동으로 탐색하여 목록을 만들고(17개의 URL 발견), 그 후에 실제로 검사를 실행합니다. '검사 설정 중' → '진입점 탐색 완료' → '검사 시작/완료' 순으로 진행되며, 발견된 항목들은 관리 화면으로 전송되어 종료됩니다. 이 역시 발견된 항목의 집계는 다음 편입니다.
이처럼 이번에는 네 가지 도구를 저희 서비스의 복사본에 적용했습니다. 정식 검사 도구(코드를 읽는 방식), 실제 수준의 공격 도구(외부에서 테스트하는 방식), 그리고 외부에서 테스트하는 두 가지 도구(무료 ZAP과 상용 StackHawk)입니다. 이들 모두 특별한 장비나 고성능의 비싼 AI를 필요로 하지 않습니다. 준비와 최초 실행은 여기까지입니다.
다음 편에서는 이 네 가지 도구가 실제로 무엇을 발견했는지를 정면으로 나란히 비교할 것입니다. 외부에서 테스트하는 도구와 코드를 읽는 도구는 발견되는 취약점의 종류가 구조적으로 다릅니다. 각각 한쪽에서만 볼 수 있는 것들이 있습니다. 또한, 저렴한 AI로 구동된 공격 도구가 제시한 후보 중 어떤 것이 실제인지, 어떤 것이 착오였는지 비교할 것입니다. 정식 도구들은 얼마나 많은 오류를 범했는지, 비용은 얼마였으며, '정식 제품이 비싸다'는 선입견이 여전히 유효한지 보여드리겠습니다. 발견된 내용의 구체적인 부분을 실제 결과 화면에서 나란히 보여드릴 예정입니다.
본 연재에서는 공격 도구가 누구나 무료로 얻을 수 있는 시대에, 자신의 서비스를 직접 검사하고 약점을 미리 발견하여 수정하는 절차를 순서대로 보여드립니다. 검사 대상은 자사 서비스로 한정되며, 타인의 사이트를 공격하는 과정은 다루지 않습니다.
직접 검사가 어려운 분들은 EarthLink Network가 검사를 대행합니다. 약점은 발견했지만 스스로 수정하기 어려운 경우, 저희가 수정까지 책임집니다. 부담 없이 상담해 주십시오.
도움이 되었다고 느끼셨다면, '좋아요'와 기사 구독을 부탁드립니다.
자사 제품은 https://www.eln.ne.jp/products 에 모아두었습니다.
상하라 마사요시(上原正吉)입니다. EarthLink Network Co., Ltd에서 AI 개발을 하고 있습니다. 2025년부터 Claude Code를 개발의 주체로 삼았으며, 현재는 20개가 넘는 제품을 혼자 동시에 개발 및 운영하고 있습니다. 이 연재에서는 그 현장에서 실제로 일어난 일(잘된 일도, 실패한 것도)을 숫자가 함께 기록해 나갈 것입니다.
또한, AI를 활용하여 업무나 개발 방식을 재편하려는 회사/팀을 대상으로 AI 활용 컨설팅도 받고 있습니다. 상담은 www.eln.ne.jp에서 문의해 주십시오.
EarthLink Network는 회사의 모든 업무를 AI로 운영하기 위해 필요한 것을 자체적으로 제작하고 있습니다. 현재 만들고 있는 제품 목록과 개요는 이곳에 모아두었습니다.
회사와 각 제품의 상세 내용은 공식 웹사이트 www.eln.ne.jp 를 참고해 주십시오.
