크롬이면 충분한 줄 알았습니다…ego lite를 써보기 전까지

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

크롬이면 충분하다고 느꼈더라도, ego lite는 로그인 상태를 활용하고 별도 공간에서 에이전트를 작업하게 해 브라우저 자동화의 번거로움을 줄여준다.

📌 핵심 요점

1. 에고라이트는 사용자와 에이전트가 함께 쓰도록 설계된 크로미움 기반 브라우저로, 익숙한 크롬 형태의 화면을 제공한다.
2. 크롬 정보를 가져오거나 에고라이트에서 직접 로그인하면 에이전트도 해당 로그인 상태를 활용할 수 있다. 반복 인증의 불편을 줄이는 대신 계정 접근 범위를 주의해야 한다.
3. 에이전트는 별도 스페이스에서 작업하므로 사용자는 자신의 브라우저 작업을 이어갈 수 있다. Option+S로 작업 공간을 확인하고 Takeover로 제어권을 가져올 수 있다.
4. 영상에서는 코덱스에 연결한 아스트라가 소개글을 Threads·Reddit에 맞게 입력하고, 네이버 블로그에서는 팝업을 처리하며 초안을 임시 저장하는 모습을 보여준다.
5. 직접 만든 자동화 프로그램은 사이트 변경에 따른 유지보수가 필요하고, AI 방식은 실행할 때마다 토큰을 소비한다. 반복 절차의 스킬화와 게시 전 사람의 검토가 운영상의 핵심이다.

🧩 배경과 문제 정의

서비스 개발을 마친 뒤 여러 커뮤니티에 소개글을 올리는 작업은 사이트마다 접속하고 형식을 맞춰야 해 번거롭다. 발표자는 기존 자동화를 쓰면서 마우스 제어권을 빼앗기거나 별도 브라우저에서 로그인과 2단계 인증을 반복해야 했다고 설명한다.

에고라이트는 사용자의 로그인 상태를 활용하고 에이전트가 별도 스페이스에서 작업하도록 해 이 불편을 줄이는 도구로 소개된다. 영상은 설치와 코덱스 연결, 커뮤니티 초안 작성, 네이버 블로그 입력을 시연하면서 계정 접근과 최종 승인에 대한 주의사항을 함께 다룬다.

🕒 시간순 섹션별 상세정리

1. 서비스 홍보를 어렵게 만드는 반복 작업

• 도입부에서는 로그인된 커뮤니티에 에이전트가 소개글 초안을 준비하고, 사용자가 최종 게시 여부를 결정하는 활용 장면을 제시한다. [00:24]
• 마이베스트 포토 소개글을 X나 디스코드 개발자 커뮤니티에 맞게 올리는 작업이 번거롭다고 보여준다. [00:51]
• 기존 자동화에서 마우스 커서가 작업 중 끼어들고, 별도 브라우저에서는 로그인과 2단계 인증을 반복해야 하는 문제를 짚어 본다. [01:35]

2. 에고라이트 설치와 코덱스 연결

• 사용자와 에이전트가 함께 쓰는 브라우저로 에고라이트를 보여준다. 영상 당시에는 맥을 지원하고 같은 달 윈도우 출시가 예정돼 있다고 드러낸다. [01:59]
• 크로미움 기반이며 크롬 정보를 가져와 로그인 상태를 활용할 수 있다. 화면과 확장 프로그램도 기존 크롬과 비슷한 모습으로 묶인다. [02:57]
• 코덱스 연결과 설치된 플러그인 사용을 보여주고, 아스트라가 에고라이트를 통해 브라우저를 조작하고 데이터를 가져오는 모습을 보여준다. [03:40]

3. 별도 스페이스와 로그인 공유의 양면성

• Option+S로 에이전트가 제어하는 별도 스페이스를 확인한다. 에이전트가 데이터를 가져오는 동안 사용자는 자신의 화면으로 돌아와 작업을 계속한다. [04:34]
• 사용자가 로그인해 둔 네이버 계정에 에이전트도 접근할 수 있어, 의도와 다르게 로그인된 계정으로 댓글을 작성할 가능성을 경고한다. [05:08]
• 작업 전 로그인 상태를 확인하고 민감한 계정은 신중히 선택하라고 권한다. [05:17]

4. 커뮤니티 초안 작성과 제어권 인계

• 준비한 마크다운 소개글을 Threads와 Reddit에 맞게 바꿔 입력하도록 요청하면서, 사용자 확인 전에는 게시하지 말라는 조건을 명시한다. [05:59]
• Takeover로 사람이 제어권을 가져오면 에이전트의 브라우저 조작이 중지된다. Return to Agent로 권한을 돌려준 뒤 작업을 이어가도록 요청한다. [06:48]
• 두 커뮤니티에 초안이 준비되고 제어권이 사용자에게 돌아온다. 게시까지 맡길 수 있지만 마지막에는 사람이 검토하길 권한다. [07:25]

5. 자체 자동화와 AI 방식의 비용·유지보수 비교

• 발표자가 직접 만든 네이버 입력 프로그램은 사이트 개편에 따라 수정해야 하며, 시연 중에도 제목 누락이 확인된다. [08:42]
• 미리 만든 프로그램은 실행 시 AI 토큰을 쓰지 않는 장점이 있지만 유지보수가 필요하다. AI 방식은 화면을 판단하며 동작하는 대신 실행마다 토큰을 소비하며, 반복 절차를 스킬로 만들면 소모를 줄이는 데 도움이 된다고 보여준다. [09:45]
• 네이버 블로그의 작성 중인 글 안내 팝업을 처리하고 소개글과 링크를 입력한다. 이어 초안을 임시 저장해 사용자가 나중에 발행 여부를 결정하도록 한다. [10:36]

6. 기존 도구와의 차이와 최종 활용 권고

• Playwright·Puppeteer와 비교하며, 에고라이트는 사용 중인 브라우저의 로그인 상태를 활용하고 별도 스페이스에서 동시에 작업한다는 점을 강조한다. [11:16]
• 공식 사이트에 제시된 데이터 수집, 이력서 제출, 테스트 자동화를 언급한다. 폼 입력 시간을 줄이는 활용을 설명하면서 엉뚱한 글의 게시를 막기 위해 마지막 승인 절차를 두라고 재차 권한다. [12:31]
• 제품 다운로드와 지원 환경 링크를 영상 설명과 고정 댓글에 안내하겠다고 드러낸다. 기존 브라우저 자동화에 불편을 느낀 사용자에게 사용을 권하며 마무리한다. [12:56]

🧾 결론

• 에고라이트의 핵심 가치는 로그인 상태 활용과 별도 작업 공간을 결합해 사용자와 에이전트의 동시 작업을 지원하는 데 있다.
• 홍보글 작성처럼 여러 사이트의 입력 양식을 오가는 업무에서 초안 준비를 맡기고 사람이 최종 게시를 결정하는 활용법을 보여준다.
• 로그인 공유는 편의성과 계정 오사용 가능성을 함께 만든다. 작업 전 계정 확인과 최종 검토를 운영 절차에 포함해야 한다.
• 시연은 팝업 대응과 초안 작성 가능성을 보여주지만, 모든 사이트에서의 안정성이나 비용 우위까지 입증하지는 않는다.

📈 투자·시사 포인트

• 도입 효과는 자동 입력 기능뿐 아니라 반복 로그인, 작업 방해, 초안 검토에 드는 시간이 얼마나 줄어드는지로 평가할 수 있다.
• 자체 자동화와 AI 에이전트의 경제성은 실행 빈도, 토큰 사용량, 사이트 변경에 따른 유지보수 부담을 함께 비교해야 한다.
• 로그인 활용, 별도 작업 공간, 제어권 회수 기능은 브라우저 자동화 도구를 비교할 때 살펴볼 구체적인 제품 기준이다.
• 영상에는 가격, 사용량별 비용, 기업 실적 자료가 없어 특정 기업이나 자산에 대한 투자 판단을 도출하기는 어렵다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상에서는 당시 맥만 지원하며 같은 달 윈도우 출시를 예고한다. 촬영 기준일이 없으므로 현재 지원 환경과 실제 출시 여부는 별도 확인이 필요하다.
• 로그인 상태를 가져오는 구체적인 범위, 민감한 계정의 접근 제한 방식, 세션 정보의 보관 방식은 설명되지 않는다.
• 팝업 대응과 게시글 작성은 개별 시연이다. 사이트 개편이나 다양한 예외 상황에서도 같은 수준으로 동작하는지는 확인되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 영상 설명과 고정 댓글에 안내된 제품 링크에서 현재 지원 운영체제와 설치 방법을 확인한다.
• 크롬 정보를 가져오기 전에 에이전트가 사용할 계정을 점검하고, 민감한 계정의 로그인 상태를 신중히 선택한다.
• 첫 작업은 소개글 초안 입력처럼 검토하기 쉬운 범위로 정하고, 확인 전에는 게시하지 말라는 조건을 명시한다.
• Option+S, Takeover, Return to Agent를 직접 확인해 작업 감시와 제어권 회수 방법을 익힌다.

❓ 열린 질문

• 로그인 상태를 공유하면서 특정 계정이나 사이트에 대한 에이전트 접근을 얼마나 세밀하게 제한할 수 있을까?
• 반복 실행 횟수와 사이트 변경 빈도가 어느 정도일 때 AI 방식이 자체 자동화보다 경제적일까?
• 승인 조건을 지키는지, 작업이 중단됐을 때 초안과 제어권을 안전하게 복구하는지는 어떻게 검증할 수 있을까?