난 대학생 3학년 때 슬슬 버전 관리를 접하게 되었다. 처음엔 같이 졸업작품을 만들면서 선배가 Git에 대해서 알려주면서 접하게 되었다.

확실히 파일을 압축해서 메일로 보내고, 다시 다운로드해서 세팅하고, 수정한 파일을 또 보내는 이러한 귀찮고 비효율적인 작업이 Git을 통해 많이 편해졌다.

Git을 사용하면서 코드를 수정한 뒤 변경 사항을 기록하고, 이전 코드와 비교하거나 필요하다면 과거의 코드로 돌아갈 수도 있었다.

처음에는 단순히 "코드를 저장해두는 도구" 정도로 생각했지만, 여러 명이 하나의 프로젝트를 함께 작업할 때 Git이 왜 필요한지 점점 이해하게 되었다.

정보처리기사 자격증을 공부하면서 Git 외에도 SVN(Subversion)이라는 버전 관리 도구가 있다는 것을 알게 되었다.

그렇다면 SVN은 뭘까?

SVN은 Subversion의 줄임말로, Git과 마찬가지로 소스 코드의 변경 이력을 관리하기 위한 버전 관리 시스템(VCS, Version Control System)이다.

쉽게 말하면, "파일이나 소스 코드가 언제, 어떻게 변경되었는지를 기록하고 관리하는 도구" 라고 생각하면 된다.

난 여기서 한 가지 의문이 생겼다.

"Git도 여러 개발자가 코드를 공유하면서 버전을 관리하는데, SVN은 Git과 무엇이 다른 걸까?"

차이는 버전 관리 저장소를 구성하는 방식에 있다.

① SVN은 중앙 집중식 버전 관리 시스템(CVCS, Centralized Version Control System)이다.

쉽게 말하면 하나의 중앙 서버에 저장소(Repository)를 두고, 모든 개발자가 이 저장소를 중심으로 작업하는 방식​이다.

예를 들어 A와 B라는 개발자가 하나의 프로젝트를 개발한다고 해보자.

개발자는 중앙 저장소에서 소스 코드를 받아 작업하고, 작업이 끝나면 변경된 내용을 다시 중앙 저장소에 Commit한다.

다른 개발자가 변경한 내용이 있다면 Update를 통해 중앙 저장소의 최신 내용을 받아온다.

즉, SVN에서는 중앙 저장소가 프로젝트 버전 관리의 중심이 된다.

그렇다면 Git은?

Git도 원격 저장소를 사용하기 때문에 겉으로 보면 SVN과 비슷하게 느껴질 수 있다.

하지만 Git은 분산 버전 관리 시스템(DVCS, Distributed Version Control System)이다.

Git에서는 단순히 최신 소스 코드만 가져오는 것이 아니라, 각 개발자의 로컬 저장소에도 프로젝트의 버전 이력이 함께 존재한다.

각 개발자는 자신의 로컬 저장소에서 Commit을 하면서 버전 이력을 관리할 수 있다. 필요할 때 원격 저장소와 변경 내용을 주고받으며 다른 개발자와 작업 내용을 공유한다.

따라서 가장 간단하게 정리하면,

결국 SVN과 Git 모두 여러 개발자가 함께 코드를 관리할 수 있는 버전 관리 도구이지만, 가장 큰 차이는 버전 이력을 어디에 가지고 있느냐에 있다.

SVN은 중앙 서버를 중심으로 버전을 관리하고, Git은 각 개발자의 로컬 저장소에도 버전 이력을 가지고 분산해서 관리한다.

처음에는 Git과 SVN이 단순히 "코드를 공유하는 도구"라고 생각했지만, 공부해보니 그보다 더 중요한 차이는 버전 관리 구조 자체에 있었다.

SVN은 어떻게 사용하는 걸까?

SVN의 기본적인 흐름은 다음과 같다.

Checkout → 수정 → Commit → Update

먼저 SVN 서버에 저장되어 있는 프로젝트를 Checkout하여 내 컴퓨터로 받아온다.

그다음 필요한 코드를 수정하고, 작업이 끝나면 변경한 내용을 Commit한다.

Commit을 하면 내가 수정한 내용이 SVN 서버의 저장소에 반영된다.

다른 개발자가 먼저 서버에 변경 사항을 반영했다면, Update를 통해 서버의 최신 변경 내용을 내 작업 공간으로 가져올 수도 있다.

이 과정을 반복하면서 여러 개발자가 하나의 프로젝트를 함께 개발하게 된다.

Git과 SVN은 무엇이 다를까?

여기서 처음에는 Git과 SVN이 비슷하게 느껴졌다.

둘 다 코드를 저장하고 변경 이력을 관리하며 여러 명이 협업할 수 있도록 도와주기 때문이다.

하지만 가장 큰 차이점은 저장소를 관리하는 방식에 있다.

SVN은 기본적으로 중앙 집중식 버전 관리 시스템(CVCS)이다.

반면 Git은 분산 버전 관리 시스템(DVCS)이다.

SVN에서는 중앙 서버에 있는 저장소가 중심이 된다.

개발자가 작업하기 위해 서버에서 코드를 받아오고, 작업한 내용을 다시 중앙 서버에 Commit하는 방식이다.

반면 Git은 각각의 개발자가 저장소의 전체 이력을 가지고 작업할 수 있다.

그래서 Git에서는 로컬 환경에서도 Commit을 하거나 과거의 변경 이력을 확인하는 등의 작업을 할 수 있다.

처음에는 단순히 "Git과 SVN 모두 버전 관리 도구구나"라고 생각했지만, 실제로는 버전 관리 방식을 바라보는 구조 자체가 다르다는 것을 알게 되었다.

결국 중요한 것은 특정 도구의 이름을 외우는 것이 아니라 "왜 버전 관리가 필요하고, 개발자들은 어떤 방식으로 코드를 공유하고 변경 이력을 관리하는가?" 를 이해하는 것이라고 생각한다.

요약

1. SVN의 Commit = 중앙 저장소 직행: SVN은 중앙 집중형 구조(CVCS)이기 때문에, Commit을 실행하는 순간 내 컴퓨터의 변경 사항이 네트워크를 통해 중앙 서버(중앙 저장소)로 직접 전송 및 반영된다.

2. Git의 Commit = 로컬 저장소 저장 / Push = 원격 저장소 전송: Git은 분산형 구조(DVCS)이므로, Commit은 내 컴퓨터(로컬 저장소) 스냅샷 저장일 뿐이고, Push를 해야 비로소 Server/GitHub(원격 저장소)로 전송된다.

• 제목 : 뱅킹 분야의 대화형 AI란 무엇인가요?
• 출처 : IBM
• 기사 링크 : https://www.ibm.com/kr-ko/think/topics/conversational-ai-banking

📖 기사 핵심 요약

• 바이브 코딩은 단순한 코드 자동 생성을 넘어 프로토타입이나 풀스택 애플리케이션을 짧은 시간 안에 구현하고 반복적으로 개선할 수 있다는 장점이 있다.
• 전문가들은 바이브 코딩이 기존 소프트웨어 개발을 완전히 대체하기보다는, 개발자의 역할과 개발 방식이 변화하는 하나의 진화 과정이 될 가능성이 높다고 보고 있다.
• 바이브 코딩을 활용하면 아이디어를 빠르게 실제 동작하는 형태로 구현할 수 있어 프로토타이핑과 MVP 개발에 특히 효과적이다.
• 반면 AI가 생성한 코드를 충분히 이해하거나 검증하지 않고 사용하면 버그, 보안 취약점, 접근 제어 문제, 개인정보 유출 등의 위험이 발생할 수 있다.
• AI가 생성하는 코드의 양이 많아질수록 개발자가 이를 직접 검토하고 테스트해야 하는 부담도 커질 수 있다.
• 바이브 코딩으로 생성된 코드가 실제 운영 환경에 사용될 경우에는 코드 리뷰, 테스트, 권한 관리, 보안 점검 등의 거버넌스가 필수적이다.
• 특히 운영 데이터베이스나 인프라에 AI를 직접 연결할 경우, 잘못된 명령으로 인해 실제 서비스와 데이터에 피해가 발생할 가능성도 있다.
• 따라서 현재의 바이브 코딩은 운영 환경의 모든 개발을 대체하기보다는 아이디어를 빠르게 검증하거나 프로토타입을 만드는 용도로 활용하는 것이 적절하다는 의견이 많다.
• 앞으로 바이브 코딩이 발전하면 개발자는 직접 코드를 작성하는 역할에서 벗어나 AI가 생성한 결과를 검토하고, 아키텍처를 설계하고, 테스트와 보안을 관리하는 역할이 더욱 중요해질 것으로 전망된다.

🔑 주요 키워드 정리

1️⃣ 소프트웨어 개발 생명주기(software development lifecycle, SDLC) 소프트웨어를 개발하고 운영하기까지의 전체 과정을 의미하며, 일반적으로 요구사항 분석 → 설계 → 개발 → 테스트 → 배포 → 유지보수 등의 단계로 이루어진다.

2️⃣ 레플릿(Replit) 웹 브라우저에서 코드를 작성하고 실행할 수 있는 클라우드 기반 개발 플랫폼으로, 최근에는 생성형 AI를 활용해 자연어로 애플리케이션을 만들 수 있는 기능도 제공한다.

3️⃣ 엣지 케이스(edge case) 오류 일반적인 상황에서는 잘 발생하지 않지만, 특정한 극단적인 조건에서 발생할 수 있는 예외적인 상황이나 입력을 의미한다. 이러한 상황을 충분히 고려하지 않으면 실제 서비스에서 예상하지 못한 오류가 발생할 수 있다.

4️⃣ 로우코드 개발자가 직접 작성해야 하는 코드의 양을 최소화하고, 시각적인 인터페이스나 미리 만들어진 컴포넌트 등을 활용해 소프트웨어를 개발하는 방식이다.

5️⃣ AI 거버넌스 AI를 안전하고 책임감 있게 활용하기 위해 권한, 보안, 데이터, 검증 및 운영 기준 등을 관리하는 체계

6️⃣ 데브섹옵스(DevSecOps) 개발(Development)과 운영(Operations)에 보안(Security)을 통합한 개발 방법론으로, 소프트웨어 개발의 모든 단계에서 보안을 함께 고려하는 방식이다.

7️⃣ 시프트 레프트(shift left) 보안 프랙티스 개발이 완료된 이후 보안을 점검하는 것이 아니라 기획·설계·개발 초기 단계부터 보안을 고려하는 개발 방식

8️⃣ MVP(Minimum Viable Product) 핵심적인 기능만 구현한 최소 기능 제품으로, 실제 사용자의 반응을 빠르게 확인하고 서비스를 개선하기 위해 활용한다.

💡 나의 생각

평소 바이브 코딩을 직접 사용해보면서 개발 속도를 크게 높일 수 있다는 장점을 체감했기 때문에, 이번 기사에서 이야기하는 바이브 코딩의 가능성에 공감했다. 실제로 간단한 기능이나 화면을 구현할 때 AI에게 요구사항을 설명하는 것만으로 빠르게 결과물을 만들 수 있어 아이디어를 확인하거나 프로토타입을 제작하는 데 상당히 유용하다고 느꼈다.

하지만 이번 기사를 통해 빠르게 만들어지는 것과 실제 서비스에 사용할 수 있는 것은 다른 문제라는 점을 다시 생각하게 되었다. AI가 만들어준 코드가 겉으로는 정상적으로 동작하더라도 보안 취약점이나 예외 상황, 유지보수의 어려움과 같은 문제가 존재할 수 있기 때문이다.

특히 기사에서 바이브 코딩을 주니어 개발자와 협업하는 것처럼 다뤄야 한다는 의견이 인상적이었다. AI가 만들어준 코드를 그대로 신뢰하기보다는 개발자가 코드 리뷰와 테스트를 수행하고, 필요한 부분은 직접 수정해야 한다는 의미로 받아들였다.

결국 바이브 코딩이 개발자를 없애는 기술이라기보다는 개발자의 역할을 변화시키는 기술에 가깝다고 생각한다. 단순히 코드를 작성하는 능력뿐만 아니라 AI가 생성한 코드를 이해하고 검증하며, 보안과 아키텍처까지 판단할 수 있는 역량이 앞으로 더욱 중요해질 것 같다.

특히 나 역시 바이브 코딩을 활용해 프로젝트를 진행하고 있기 때문에, "AI가 만들어줬으니 동작한다"에서 끝나는 것이 아니라 "왜 이렇게 구현되었고, 실제 서비스에서도 안전하게 동작할 수 있는가?"를 확인하는 과정이 중요하다는 점을 기억해야겠다고 생각했다.

• 제목 : 뱅킹 분야의 대화형 AI란 무엇인가요?
• 출처 : IBM
• 기사 링크 : https://www.ibm.com/kr-ko/think/topics/conversational-ai-banking

📖 기사 핵심 요약

• 대화형 AI는 음성과 텍스트 전반에서 자연스러운 상호 작용을 가능하게 하기 때문에 디지털 뱅킹 서비스의 필수 요소로 자리 잡았다.
• 기술이 발전함에 따라 주요 금융 기관은 금융 규칙과 보안 요구 사항을 이해하는 시스템을 채택하고 있다.
• 뱅킹 분야에서 대화형 AI가 중요한 이유:
• 뱅킹 분야의 대화형 AI 사용 사례: 결제 알림 및 처리 / 데이터 캡처 및 분석 …
• 뱅킹 분야에서 대화형 AI의 이점: 옴니채널 및 다국어 도달 / 효율성 향상 및 비용 절감 …
• 뱅킹 분야에서 대화형 AI의 일반적인 배포 실수와 이를 방지하는 방법: AI 모니터링 및 재학습을 하지 않으면 시간이 지날수록 변화하는 고객의 요구나 새로운 데이터를 제대로 반영하지 못할 수 있다 → 지속적인 성능 모니터링과 개선이 필요하다.

🔑 주요 키워드 정리

1️⃣ 대화형 AI(Conversational AI) 자연어 처리(NLP), 머신러닝 등의 기술을 활용해 사용자의 음성이나 텍스트를 이해하고, 사람과 대화하듯 자연스럽게 상호작용하는 인공지능 기술을 의미

2️⃣ 핀테크(FinTech) 금융(Finance)과 기술(Technology)의 합성어로, AI, 모바일, 빅데이터 등의 기술을 금융 서비스에 적용해 새로운 금융 서비스를 제공하는 것을 의미

3️⃣ 옴니채널(Omnichannel) 웹사이트, 모바일 앱, 전화, 채팅 등 여러 채널을 연결해 사용자가 어떤 채널을 이용하더라도 일관된 서비스를 제공하는 방식을 의미

4️⃣ AI 모니터링 및 재학습 AI 서비스를 배포한 이후에도 성능과 사용자 반응을 지속적으로 확인하고, 오류나 개선이 필요한 부분을 분석해 데이터를 업데이트하고 성능을 개선하는 과정을 의미

💡 나의 생각

나도 은행 앱을 사용하면서 최근 생성형 AI가 도입된 것을 직접 확인했다. 은행 앱은 제공하는 서비스와 메뉴가 많아 원하는 기능의 위치를 찾기 어려운 경우가 있는데, 이때 생성형 AI를 통해 필요한 메뉴나 기능의 위치를 찾았던 기억이 있다. 이처럼 일상적으로 사용하는 금융 서비스에도 생성형 AI가 점차 도입되고 있다는 것을 느끼고 있다.

실제로 이런 기능이 어떻게 구현되는지 궁금해 찾아보니, 생성형 AI가 은행 앱의 모든 정보를 단순히 학습하는 것이 아니라 사용자의 질문과 관련된 메뉴나 기능 정보를 검색한 뒤, 이를 AI에게 함께 제공하는 방식을 활용할 수 있다는 것을 알게 되었다. 예를 들어 은행 앱 내부의 메뉴 정보를 다음과 같이 관리할 수 있다.

메뉴명: 해외송금
경로: 전체 메뉴 > 외환 > 해외송금
설명: 해외 계좌로 송금할 때 사용하는 기능
딥링크: bankapp://transfer/overseas

이때 사용자가 “미국에 있는 친구에게 돈을 보내려면 어디로 들어가?”라고 질문하면, 시스템은 질문의 의도를 파악한 뒤 해외송금, 외환, 송금과 관련된 정보를 검색한다. 이후 해당 정보를 생성형 AI에게 함께 제공하면 AI는 이를 바탕으로 사용자에게 자연스럽게 기능을 안내할 수 있다.

평소에는 단순히 “AI가 앱을 잘 알고 있구나”라고 생각했는데, 직접 구현 방식을 찾아보니 AI의 자연어 이해 능력과 기존 서비스의 메뉴 데이터 및 화면 이동 기능을 연결해 사용자 경험을 설계하는 과정이라는 점이 흥미롭게 느껴졌다.

다만, 금융 서비스는 개인정보와 자산을 다루는 만큼 다른 서비스보다 정확성과 보안이 더욱 중요하다고 생각한다. 따라서 생성형 AI를 단순히 도입하는 것에 그치지 않고, 잘못된 정보를 제공했을 때 어떻게 대응할 것인지, 사용자가 해결하지 못한 문제를 어떻게 기존 상담 시스템이나 사람에게 연결할 것인지까지 함께 고려해야 한다고 생각한다.

• 제목 : 에이전틱 AI 시대 국내 금융기관 96% 준비 중, 거버넌스 확신은 48%에 그쳐
• 출처 : IT World
• 기사 링크 : https://www.itworld.co.kr/article/4188180

📖 기사 핵심 요약

• 전 세계 금융기관의 96%가 에이전틱 AI 도입을 추진하고 있지만, 실제 운영 단계까지 진전한 비율은 19%에 불과했다.
• 콘텐츠, 커뮤니케이션, 거래 데이터를 실시간으로 연결할 수 있는 금융기관은 9%에 불과했으며, 분산된 데이터와 불명확한 책임 구조가 주요 과제로 지적됐다.
• AI 도입이 확대될수록 직원의 역할 역시 단순 시스템 운영에서 AI의 작업 과정을 감시하고 검증하는 방향으로 변화할 것으로 예상된다.
• 결국 에이전틱 AI의 성공적인 도입을 위해서는 기술 자체뿐 아니라 데이터 관리, 책임 구조, 보안, 인력 역량까지 함께 준비해야 한다.

🔑 주요 키워드 정리

1️⃣ AI 거버넌스(AI Governance) AI가 조직 내에서 안전하고 책임감 있게 사용될 수 있도록 데이터 관리, 보안, 규정 준수, 책임 범위 등을 관리하는 체계를 의미

2️⃣ 데이터 거버넌스(Data Governance) 조직 내 데이터를 정확하고 일관성 있게 관리하고, 누가 어떤 데이터에 접근할 수 있는지 등의 기준을 정하는 관리 체계

3️⃣ Human-in-the-Loop AI가 모든 결정을 독립적으로 내리는 것이 아니라, 중요한 판단이나 실행 과정에서 사람이 검토하고 개입할 수 있도록 설계하는 방식을 의미

💡 나의 생각

AI 에이전트는 단순히 답변을 생성하는 수준을 넘어 실제 시스템과 연결되어 정보를 조회하거나 작업을 수행하는 방향으로 발전하고 있다. 하지만 AI가 직접 행동할 수 있는 범위가 넓어질수록, 잘못된 판단이 단순한 잘못된 답변에서 끝나지 않고 실제 서비스나 사용자에게 영향을 줄 수 있다는 점에서 더욱 신중한 설계가 필요하다고 생각한다.

특히 기사에서 금융기관의 AI 도입 비율은 높지만 실제 운영 단계에 도달한 비율은 낮다는 점이 기억에 남았다. 이는 단순히 AI 기술을 도입하는 것과 실제 서비스 환경에서 안정적으로 운영하는 것은 전혀 다른 문제라는 것을 보여준다고 생각한다.

개발자의 관점에서도 앞으로는 AI를 서비스에 연결하는 것만으로 끝나는 것이 아니라, AI가 어떤 데이터에 접근할 수 있는지, 어떤 작업까지 실행할 수 있는지, 문제가 발생했을 때 누가 확인하고 책임질 것인지까지 함께 설계해야 하는 게 중요할 것 같다고 생각한다.

이전에는 AI를 얼마나 잘 활용하느냐에 집중했다면, 앞으로는 AI가 실수하더라도 큰 문제로 이어지지 않도록 안전장치를 설계하는 능력도 개발자에게 중요한 역량이 될 것이라고 생각한다.

• 제목 : 에이전틱 AI 시대 국내 금융기관 96% 준비 중, 거버넌스 확신은 48%에 그쳐
• 출처 : IT World
• 기사 링크 : https://www.itworld.co.kr/article/4188180

📖 기사 핵심 요약

• 전 세계 금융기관의 96%가 에이전틱 AI 도입을 추진하고 있지만, 실제 운영 단계까지 진전한 비율은 19%에 불과했다.
• 콘텐츠, 커뮤니케이션, 거래 데이터를 실시간으로 연결할 수 있는 금융기관은 9%에 불과했으며, 분산된 데이터와 불명확한 책임 구조가 주요 과제로 지적됐다.
• AI 도입이 확대될수록 직원의 역할 역시 단순 시스템 운영에서 AI의 작업 과정을 감시하고 검증하는 방향으로 변화할 것으로 예상된다.
• 결국 에이전틱 AI의 성공적인 도입을 위해서는 기술 자체뿐 아니라 데이터 관리, 책임 구조, 보안, 인력 역량까지 함께 준비해야 한다.

🔑 주요 키워드 정리

1️⃣ AI 거버넌스(AI Governance) AI가 조직 내에서 안전하고 책임감 있게 사용될 수 있도록 데이터 관리, 보안, 규정 준수, 책임 범위 등을 관리하는 체계를 의미

2️⃣ 데이터 거버넌스(Data Governance) 조직 내 데이터를 정확하고 일관성 있게 관리하고, 누가 어떤 데이터에 접근할 수 있는지 등의 기준을 정하는 관리 체계

3️⃣ Human-in-the-Loop AI가 모든 결정을 독립적으로 내리는 것이 아니라, 중요한 판단이나 실행 과정에서 사람이 검토하고 개입할 수 있도록 설계하는 방식을 의미

💡 나의 생각

AI 에이전트는 단순히 답변을 생성하는 수준을 넘어 실제 시스템과 연결되어 정보를 조회하거나 작업을 수행하는 방향으로 발전하고 있다. 하지만 AI가 직접 행동할 수 있는 범위가 넓어질수록, 잘못된 판단이 단순한 잘못된 답변에서 끝나지 않고 실제 서비스나 사용자에게 영향을 줄 수 있다는 점에서 더욱 신중한 설계가 필요하다고 생각한다.

특히 기사에서 금융기관의 AI 도입 비율은 높지만 실제 운영 단계에 도달한 비율은 낮다는 점이 기억에 남았다. 이는 단순히 AI 기술을 도입하는 것과 실제 서비스 환경에서 안정적으로 운영하는 것은 전혀 다른 문제라는 것을 보여준다고 생각한다.

개발자의 관점에서도 앞으로는 AI를 서비스에 연결하는 것만으로 끝나는 것이 아니라, AI가 어떤 데이터에 접근할 수 있는지, 어떤 작업까지 실행할 수 있는지, 문제가 발생했을 때 누가 확인하고 책임질 것인지까지 함께 설계해야 하는 게 중요할 것 같다고 생각한다.

이전에는 AI를 얼마나 잘 활용하느냐에 집중했다면, 앞으로는 AI가 실수하더라도 큰 문제로 이어지지 않도록 안전장치를 설계하는 능력도 개발자에게 중요한 역량이 될 것이라고 생각한다.

• 클라우드 환경에서는 서버를 단순히 클라우드로 옮기는 것만으로는 효율적인 운영이 보장되지 않으며, 처음부터 아키텍처를 고려한 설계가 중요하다.
• 클라우드 비용 문제는 단순히 리소스를 많이 사용해서 발생하는 것이 아니라, 불필요한 리소스 유지와 관리되지 않는 서비스 증가 등 아키텍처와 운영 방식의 문제에서 발생할 수 있다.
• 클라우드 환경에서는 컴퓨팅, 스토리지, 네트워크 등 다양한 서비스를 목적에 맞게 선택하고 관리해야 한다. 특히 서비스가 확장될수록 누가 어떤 리소스를 사용하고 있는지 파악하기 어려워질 수 있기 때문에, 태그 관리와 리소스 구조화 같은 운영 기준이 필요하다.
• 장애와 비용 문제를 줄이기 위해서는 확장성, 가용성, 보안, 비용 등을 서비스 개발 이후가 아닌 아키텍처 설계 단계부터 함께 고려해야 한다.

🔑 주요 키워드 정리

1️⃣ 클라우드 아키텍처(Cloud Architecture) 클라우드 환경에서 애플리케이션과 서버, 데이터베이스, 네트워크 등의 구성 요소를 어떻게 배치하고 연결할지 설계하는 구조를 의미한다.

2️⃣ 가용성(Availability) 장애가 발생하더라도 서비스가 가능한 한 중단되지 않고 안정적으로 제공되는 정도를 의미한다.

💡 나의 생각 최근 개인 프로젝트를 GitHub Actions를 이용해 배포하면서, 개발한 기능이 정상적으로 동작하는 것만큼 어떤 환경에서 어떻게 운영되는지를 이해하는 것도 중요하다는 것을 느꼈다. 로컬 환경에서는 문제가 없었지만 배포 환경에서는 화면이 정상적으로 표시되지 않았던 경험을 통해, 개발 과정에서 보이지 않는 설정과 환경의 차이가 실제 서비스의 안정성에 직접적인 영향을 줄 수 있다는 것을 경험했다.

이 기사를 읽으며 클라우드 역시 단순히 서버를 올려두는 공간이 아니라는 생각이 들었다. 서비스를 운영하기 위해서는 비용, 확장성, 가용성, 보안 등 다양한 요소를 함께 고려해야 하고, 이러한 문제들이 결국 아키텍처 설계와 연결되어 있다는 점이 인상적이었다.

아직 클라우드 서비스를 직접 깊게 다뤄본 경험은 많지 않지만, 앞으로 백엔드와 데이터베이스를 추가해 서비스를 운영하게 된다면 단순히 “배포에 성공하는 것”에서 끝나는 것이 아니라, 왜 이런 구조를 선택했고 어떤 문제가 발생할 수 있는지까지 고민하는 개발자가 되어야겠다고 생각했다.

• 제목 : PM은 LLM을 어디까지 이해해야 할까?
• 출처 : 요즘 IT
• 기사 링크 : https://yozm.wishket.com/magazine/detail/3784/

📖 기사 핵심 요약

• LLM(대규모 언어 모델)은 복잡한 사고를 하는 것이 아니라, 다음에 올 단어를 확률적으로 예측하는 방식으로 동작한다.
• LLM은 텍스트를 토큰(Token) 단위로 처리하며, 언어에 따라 토큰 사용량과 비용이 달라진다.
• LLM은 컨텍스트 윈도우라는 제한된 단기 기억만 가지고 있어 장기 기억을 위해서는 별도의 시스템 설계가 필요하다. 같은 질문에도 답변이 달라지는 이유는 추론 과정에서 확률적으로 토큰을 선택하기 때문이다.
• AI는 사실 여부를 검증하지 않고 가장 그럴듯한 답을 생성하기 때문에 환각(Hallucination)이 발생할 수 있다.
• 기업에서는 환각 문제를 줄이기 위해 RAG(Retrieval-Augmented Generation)를 활용해 내부 문서나 외부 자료를 참고하도록 한다.
• 에이전트(Agent)는 LLM에 다양한 도구를 연결해 실제 작업을 수행할 수 있도록 확장한 개념이다.
• PM은 AI의 기술적 세부사항을 모두 알 필요는 없지만, 토큰·컨텍스트·추론·RAG·에이전트 정도는 이해해야 올바른 의사결정을 내릴 수 있다.

🔑 주요 키워드 정리

1️⃣ LLM 대규모 언어 모델(LLM)은 방대한 양의 데이터로 사전 학습된 초대형 딥 러닝 모델.

2️⃣ 에이전트 LLM이 단순히 답변하는 것을 넘어 검색, 예약, 이메일 발송 등 실제 행동을 수행할 수 있도록 확장한 구조.

3️⃣ RAG(Retrieval-Augmented Generation) LLM이 답변을 생성하기 전에 관련 문서를 검색하여 참고하도록 하는 기술. 기업용 AI 서비스에서 환각을 줄이는 핵심 방법.

4️⃣ 컨텍스트(Context) LLM이 현재 대화에서 참고할 수 있는 정보 범위. 컨텍스트 한도를 초과하면 이전 내용을 잊어버린 것처럼 동작한다.

💡 나의 생각

이번 기사는 PM을 대상으로 작성된 글이지만, 필자와 같은 주니어 개발자나 개발자를 준비하는 사람들에게도 도움이 되는 내용이라고 생각한다. LLM이라는 개념을 막연히 어렵고 복잡한 기술로만 생각했는데, 대학 시절 ML/DL을 공부하며 접했던 내용들이 실제로 LLM의 동작 원리와 연결되어 있다는 점이 흥미로웠다.

특히 같은 질문에도 서로 다른 답변이 나오는 이유를 설명하는 추론(Inference) 부분이 인상 깊었다. 과거 프로젝트를 진행하면서 항상 가장 높은 정확도의 결과만 선택하는 방식에 한계를 느꼈고, 다양한 후보를 두고 그중에서 선택하는 방식도 고민했던 경험이 있다. 그런데 기사에서 LLM 역시 확률 분포를 기반으로 답을 '계산하는 것'이 아니라 '선택하는 것'에 가깝다는 설명을 보고 반가웠다.

• 알고리즘: DFS/BFS
• 문제 링크: 타겟 넘버

풀이 과정

import java.util.*;

class Solution {

    public int solution(int[] numbers, int target) {

        // return dfs(0, 0, target, numbers);

        return bfs(numbers, target);
    }

    private int dfs(int idx, int sum, int target, int[] numbers) {

        if(idx == numbers.length) {
            return sum == target ? 1 : 0;
        }

        return dfs(idx + 1, sum + numbers[idx], target, numbers)
             + dfs(idx + 1, sum - numbers[idx], target, numbers);
    }

    private int bfs(int[] numbers, int target) {

        int answer = 0;

        Queue<Node> queue = new LinkedList<>();
        queue.offer(new Node(0, 0));

        while(!queue.isEmpty()) {

            Node now = queue.poll();

            if(now.idx == numbers.length) {

                if(now.sum == target) {
                    answer++;
                }

                continue;
            }

            queue.offer(
                new Node(
                    now.idx + 1,
                    now.sum + numbers[now.idx]
                )
            );

            queue.offer(
                new Node(
                    now.idx + 1,
                    now.sum - numbers[now.idx]
                )
            );
        }

        return answer;
    }

    static class Node {
        int idx;
        int sum;

        Node(int idx, int sum) {
            this.idx = idx;
            this.sum = sum;
        }
    }
}

• 문제 핵심:
• DFS는 재귀,깊게 끝까지 파고 넘어가는 걸 이해하기.
• BFS는 Queue로, 순차적으로 넓게 진행 된다는 걸 이해하기.

📌 느낀 점

DFS/BFS 패턴의 감을 익힌다면 쉽게 풀릴것이라 생각한다. 그래서 패턴을 익히기 이전엔 '재귀'와 '큐'를 이해하고 푸는 것이 수월할 것이다.

DFS

DFS(node) ① DFS(Depth-First Search, 깊이우선탐색)는 시작 노드에서 한 방향의 끝까지 탐색 후, 다시 되돌아와 다른 경로를 탐색하는 방식이다.

그래서 다시 돌아오는 형질이 있기 때문에 '스택(Stack)' 자료구조나 '재귀 함수'를 사용해야 한다. 완전 탐색과같은 특징을 파악해야 한다.

BFS

Queue<Integer> queue = new LinkedList<>(); ② BFS (Breadth-First Search, 너비 우선 탐색)는 시작 노드에서 가까운 노드부터 방문하는 넓에 퍼져나가는 탐색 방식이다.

그래서 FIFO 방식인 큐(Queue) 자료구조를 사용해야 한다. 최단 경로를 구할 때 주용 사용된다.

✅ 정점의 수를 V, 간선의 수를 E라고 할 때, 두 알고리즘 모두

• 인접 리스트 방식을 사용하면 O(V+E)
• 인접 행렬 방식을 사용하면 O(V²)

의 시간이 소요된다.

1️⃣ 대표적인 문제

2️⃣ DFS 문제 공식

언제 DFS를 의심할까? 문제에 이런 단어가 보이면 DFS 가능성이 높다.

• 모든 경우의 수
• 가능한 모든 경로
• 조합
• 순열
• 백트래킹

📌 DFS는 크게 2가지로 나뉜다. 1️⃣ 그래프 DFS (네트워크/연결 요소 찾기/트리 탐색)

void dfs(int node){
    visited[node] = true;

    for(int next : graph[node]){
        if(!visited[next]){
            dfs(next);
        }
    }
}

2️⃣ 완전탐색 DFS(타겟 넘버/N-Queen/순열/조합/피로도)

dfs(depth + 1);
dfs(depth + 1);

< DFS 사고 과정 >

✅ STEP 1. 현재 상태 정의 현재 내가 무엇을 탐색하고 있는가?

예)

타겟 넘버 → 현재 인덱스, 현재 합

N-Queen → 현재 행

순열 → 현재 선택 개수

✅ STEP 2. 종료 조건 정의

if(종료조건){
    return;
}

예) if(idx == numbers.length)

✅ STEP 3. 다음 상태 탐색 dfs(다음상태); 가능한 모든 선택지를 재귀 호출한다.

✅ STEP 4. 방문 안 했으면 재귀

if(!visited[next]){
    dfs(next);
}

2️⃣ BFS 문제 공식

언제 BFS를 의심할까? 문제에 이런 단어가 보이면 BFS 가능성이 높다.

• 최단 거리
• 최소 이동 횟수
• 가장 빨리 도착
• 몇 번 만에 도달

Queue<Integer> queue = new LinkedList<>();

queue.offer(start);
visited[start] = true;

while(!queue.isEmpty()){

    int now = queue.poll();

    for(int next : graph[now]){

        if(!visited[next]){

            visited[next] = true;
            queue.offer(next);
        }
    }
}

< BFS 사고 과정>

✅ STEP 1. 시작점 Queue 삽입

queue.offer(start);

✅ STEP 2. 방문 처리

visited[start] = true;

✅ STEP 3. Queue에서 꺼내기

int now = queue.poll();

✅ STEP 4. 다음 노드 확인

for(int next : graph[now])

✅ STEP 5. 방문 안 했으면 Queue 삽입

if(!visited[next]){
    visited[next] = true;
    queue.offer(next);
}

⚠️ DFS/BFS 문제의 핵심

DFS/BFS에서 가장 중요한 것은 중복 방문 방지이다.

이미 방문한 노드를 다시 탐색하면 무한 루프에 빠질 수 있기 때문에 방문 배열을 사용한다.

boolean[] visited = new boolean[n + 1];

혹은

boolean[][] visited = new boolean[n][m];

와 같이 관리한다.

3️⃣ 그리디 알고리즘 문제

• 프로그래머스 DFS/BFS 문제 정리 사이트
• LeetCode LeetCode DFS Problem List LeetCode BFS Problem List

• 알고리즘: 구현 알고리즘
• 문제 링크: 신규 아이디 추천

풀이 과정

import java.util.*;
import java.io.*;

class Solution {
    public String solution(String new_id) {

        return checkId(new_id);
    }

    private String checkId(String new_id) {

        // 1. 대문자 -> 소문자
        new_id = new_id.toLowerCase();

        // 2. 특정 문자 외 특수 문자 제거
        new_id = new_id.replaceAll("[^a-z0-9-_.]","");

        // 3. (.) 2번 이상 연속 -> 1개로 치환
        new_id = new_id.replaceAll("\\.{2,}",".");

        // 4. 처음과 끝이 마침표
        new_id = new_id.replaceAll("^\\.|\\.$","");

        // 5. 빈 문자열
        if(new_id.equals("")){
            new_id = "a";
        }

        // 6. 16자 이상일 경우
        if(new_id.length() > 15){
            new_id = new_id.substring(0, 15);
            new_id = new_id.replaceAll("^\\.|\\.$","");
        }

        // 7. 3자리 이하일 경우
        if(new_id.length() < 3){
            char last = new_id.charAt(new_id.length() - 1);

            while(new_id.length() < 3){
                new_id += last;
            }
        }

        return new_id;
    }
}

• 문제 핵심:
• 자바의 여러가지 함수가 필요함.

📌 느낀 점

문제 자체의 난이도는 높지 않았지만, 평소에 자주 사용하지 않던 문자열 관련 함수와 정규식을 알고 있어야 수월하게 해결할 수 있었다. 특히 replaceAll(), substring(), charAt() 등의 사용법을 다시 정리할 수 있는 문제였다. 알고리즘적인 아이디어보다는 문자열을 조건에 맞게 구현하는 능력이 중요했으며, 관련 함수만 익숙하다면 누구나 충분히 접근할 수 있는 문제라고 느꼈다.

• 제목 : 코드는 AI가 짠다, 책임은 누가 지나
• 출처 : IT WORLD
• 기사 링크 : https://www.itworld.co.kr/article/4177478

📖 기사 핵심 요약

• 실리콘밸리는 SW 개발이 '프롬프트 입력 후 즉시 배포'하는 작업으로 변모하기 직전이라고 외쳐왔다.
• 구글의 신규 코드 중 75%가 이제 AI로 생성되어 엔지니어의 검토를 거치고 있다고 밝혔다.
• 오픈클로를 개발한 엔지니어는 '바이브 슬롭' 범람에 대한 이야기를 했다.
• AI 열풍을 떠받치는 전제를 재점검해야 할 시점이 온 것이다.
• 숙련된 사람에게는 더 많은 일을 더 빠르게 해낼 수 있는 힘을 준다. 반면 미숙하거나 부주의한 사람에게는 더 큰 실수를 더 큰 자신감으로 저지를 수 있는 힘을 준다.
• 진짜 문제는 대규모 언어 모델이 매우 빠르게 그럴듯한 결과물을 생성한다는 점이다. 빠르고 그럴듯한 것은 정확히 프로덕션 환경에 슬그머니 침투하는 종류의 오류다.
• AI는 결과물이 해당 시스템, 보안 모델, 성능 범위, 사용자 요구, 기업 기준에 부합하는지 빠르고 정확하게 판단할 수 있는 사람에게 보상한다.
• AI 슬롭의 추악한 경제학이다. 생성 비용은 저렴하지만 검토 비용은 비싸다.
• 실질적인 질문은 결함이 줄었는지, 납기가 빨라졌는지, 장애가 줄었는지, 고객이 더 만족하는지다.

🔑 주요 키워드 정리

1️⃣ 바이브 슬롭(vibe slop) 생성형 AI 기술이 발전하면서 파생된 두 가지 신조어인 '바이브(Vibe)'와 '슬롭(Slop)'이 결합된 개념.

2️⃣ 슬롭(slop) 인공지능(AI) 기술을 이용해 대량으로 생산되는 저품질의 디지털 콘텐츠를 의미.

3️⃣ 엔터프라이즈 AI 대규모 조직의 비즈니스 과제를 해결하기 위해 기업용 시스템과 데이터에 인공지능을 결합하는 것을 뜻

💡 나의 생각

이번 기사는 AI 활용에 대해 비교적 현실적인 시각을 담고 있다.

특히 인상 깊었던 문장은 “생성 비용은 저렴하지만 검토 비용은 비싸다”는 부분이었다. 실제로 AI는 빠르게 그럴듯한 결과물을 만들어내지만, 그 결과물이 정말 맞는지 검증하는 데에는 오히려 더 많은 시간과 책임이 필요하다. 코드도 마찬가지다. AI가 코드를 작성할 수는 있지만, 그 코드가 보안적으로 안전한지, 기존 시스템과 충돌하지 않는지, 유지보수가 가능한지는 결국 사람이 판단해야 한다.

최근 바이브 코딩이나 노코드 자동화에 관심을 가지며 Zapier 같은 툴을 직접 사용해보면서도 비슷한 점을 느꼈다. 처음에는 AI와 자동화 도구만 있으면 금방 완성될 것처럼 보였지만, 실제로는 흐름 설계와 예외 처리, 검증 단계가 훨씬 중요했다. AI는 빠르게 초안을 만드는 데에는 강하지만, 그 결과물을 실제 서비스 수준으로 끌어올리는 과정에서는 여전히 사람의 경험과 판단이 필요했다.

다만 기사에서 말한 “숙련된 사람에게는 더 많은 생산성을, 미숙한 사람에게는 더 큰 실수를 저지를 힘을 준다”는 문장에서 AI를 제대로 이해하지 못한 상태에서 무분별하게 사용하는 것은 위험할 수 있기에 더 숙련된 사람들이 옆에서 멘토 역할을 해줘야 한다고 생각한다. 예전에도 신입 개발자들은 선배 개발자의 코드 리뷰와 피드백을 통해 성장했듯이, AI 시대에도 결국 중요한 건 협업과 학습 문화라고 느꼈다.

AI는 사람을 완전히 대체하는 존재라기보다는, 잘 이끌어주고 방향을 잡아줄 사람이 있을 때 더 큰 시너지를 낼 수 있는 도구에 가깝다고 생각한다. 그래서 앞으로는 단순히 AI를 잘 쓰는 능력보다도, 다른 사람이 AI를 더 안전하고 효과적으로 활용할 수 있도록 도와주는 역량 역시 중요할 듯 하다.

• 알고리즘: 구현 알고리즘
• 문제 링크: [[프로그래머스 - [카카오 인턴] 키패드 누르기]](https://school.programmers.co.kr/learn/courses/30/lessons/67256)

풀이 과정

class Solution {
    public String solution(int[] numbers, String hand) {
        String answer = "";
        int target = 0; // 눌러야할 키패드
        int[] lefts = new int[]{1, 4, 7};
        int[] rights = new int[]{3, 6, 9};
        int left = 10; // 현재 위치 '*'
        int right = 12; // 현재 위치 '#'

        for(int i = 0; i < numbers.length; i++){
            target = numbers[i];

            if(target == 0) target = 11;

            if(isLeft(target, lefts)){
                answer += 'L';
                left = target;
            } else if(isRight(target, rights)){
                answer += 'R';
                right = target;
            } else { // 거리 계산
                int ifL; int ifR;
                ifL = Math.abs(left - target) / 3 + Math.abs(left - target) % 3;
                ifR = Math.abs(right - target) / 3 + Math.abs(right - target) % 3;

                if(ifR < ifL) {
                    answer += 'R';
                    right = target;
                } else if(ifR > ifL) {
                    answer += 'L';
                    left = target;
                } else { // 거리 같을 때
                    if(hand.equals("right")) {
                        answer += 'R';
                        right = target;
                    } else {
                        answer += 'L';
                        left = target;
                    }

                }
            }
        }
        return answer;
    }

    private boolean isLeft(int target, int[] lefts){

        for(int i = 0; i < lefts.length; i++) {
            if(target == lefts[i]){
                return true;
            }
        }
        return false;
    }

    private boolean isRight(int target, int[] rights){

        for(int i = 0; i < rights.length; i++) {
            if(target == rights[i]){
                return true;
            }

        }
        return false;
    }

}

• 문제 핵심:
• 함수를 따로 만들어 left/right 키패드 분리
• 거리 계산은 (절대값 / 3 ) + (절대값 % 3)
• 이때 절대값은 '왼쪽, 오른쪽 손가락 위치 - 타겟 위치'

📌 느낀 점

역시 구현 알고리즘은 코드는 길어질지라도 내가 생각한 대로만 코드를 짜면 어느정도 풀리는 것 같다. 그러나 단순히 코드만 작성하는 것이 아닌 어느정도의 논리적인 부분도 필요하다. 위의 문제인 경우 키패드는 3열 4행이니까 /와 %를 이용해야 거리를 계산할 수 있다.

• 제목 : 바이브 코더 11명과 함께 사내 플랫폼 만들어봤습니다
• 출처 : 요즘 IT
• 기사 링크 : https://yozm.wishket.com/magazine/detail/3758/

📖 기사 핵심 요약

• AI에게 중요한 건 똑똑함이 아니라 맥락이다.
• 개발자들은 그 맥락을 어떻게 안저적으로 전달할 수 있을지 설계한다.
• AI 대화 세션이 하나 열릴 때마다 서버 안에서 해당 프로젝트의 코드베이스를 통째로 복제했다.
• 글의 핵심 메시지는 “개발자의 역할이 코드를 작성하는 사람에서, AI와 사람이 함께 일할 환경을 설계하는 사람으로 이동하고 있다”는 점이다.

🔑 주요 키워드 정리

1️⃣ 바이브 코딩 (Vibe Coding) AI와 자연어 기반으로 대화하며 서비스를 구현하는 개발 방식. 비개발자도 기능 제작에 참여할 수 있다는 특징이 있다.

2️⃣ 가드레일 (Guardrail) AI와 사용자가 실수하더라도 전체 시스템이 망가지지 않도록 제한과 검증 장치를 두는 개념. E2E 테스트와 격리된 작업 환경이 대표 사례로 소개됐다.

3️⃣ E2E End-to-End(엔드투엔드)의 약자로, ‘처음부터 끝까지’, ‘시작점부터 종착점까지’의 전체 과정을 의미.

4️⃣ 플랫폼 사고(Platform Thinking) 한 사람을 돕는 것이 아니라, 여러 사람이 동시에 서비스를 만들 수 있는 기반 자체를 만드는 사고방식.

💡 나의 생각

예전에는 AI를 잘 활용한다는 것이 단순히 “프롬프트를 잘 작성하는 것”이라고 생각했다. 하지만 이 글을 읽고 나서는 AI를 잘 활용하는 사람은 결국 “AI가 일할 수 있는 환경 자체를 설계하는 사람”이라는 생각이 들었다.

특히 인상 깊었던 부분은 AI에게 계속 더 좋은 답변을 요구한 것이 아니라, AI가 참고할 공통 문서와 규칙을 만들었다는 점이었다. design-system, docs, 스키마 문서화 같은 작업은 사람 입장에서는 귀찮고 반복적인 정리처럼 보일 수 있지만, AI에게는 정확한 맥락을 제공하는 핵심 장치였다. 결국 AI의 성능 차이는 모델 자체보다도 어떤 컨텍스트를 주느냐에서 나온다는 걸 다시 느꼈다.

무엇보다 가장 흥미로웠던 건 개발자의 역할 변화에 대한 부분이다. 예전에는 개발자의 핵심 역량이 “얼마나 빠르고 정확하게 코드를 작성하느냐”에 있었다면, 이제는 “AI와 사람이 함께 일할 수 있는 판을 얼마나 잘 설계하느냐”로 이동하고 있다는 느낌을 받았다.

• 제목 : 12분 49초 만에 한 달치 기획이 나왔다: 콘텐츠 AX 실험기
• 출처 : 요즘 IT
• 기사 링크 : https://yozm.wishket.com/magazine/detail/3647/

📖 기사 핵심 요약

• AI에게 한 번에 모든 작업을 맡기기보다, 리서치·기획·글쓰기·검수를 역할별 에이전트로 분리했을 때 더 높은 품질의 결과물이 나왔다.
• AI 검색 시대에는 “AI에게 잘 읽히는 콘텐츠”의 중요성이 커지고 있다고 분석했다.
• 슬랙 명령어 하나만으로 한 달치 콘텐츠 기획안과 제목, H2 구조, CTA까지 자동 생성되는 시스템을 구축했다.
• 결국 자동화는 단순히 “AI가 글을 써주는 것”이 아니라, 사람의 업무 과정을 어떻게 구조화하고 분리할 것인지의 문제라고 설명한다.

🔑 주요 키워드 정리

1️⃣ GEO(Generative Engine Optimization) ChatGPT, Gemini, Perplexity 같은 생성형 AI 검색 엔진이 콘텐츠를 더 잘 인용하고 활용할 수 있도록 구조화하는 최적화 방식

2️⃣ 콘텐츠 자동화 파이프라인(Content Automation Pipeline) 콘텐츠 기획, 생성, 검수, 발행, 뉴스레터 변환 등을 단계별로 자동화하는 시스템 구조

3️⃣ AI 에이전트(AI Agent) 특정 역할과 목적을 가지고 독립적으로 작업을 수행하는 AI 시스템. 리서치, 기획, 작성 등 역할을 분리해 협업 가능

4️⃣ Trigger–Condition–Action(T–C–A) 자동화의 기본 구조로, 특정 이벤트(Trigger)가 발생하면 조건(Condition)을 검사한 뒤 작업(Action)을 수행하는 방식

5️⃣ 프롬프트 엔지니어링(Prompt Engineering) AI에게 원하는 결과를 얻기 위해 작업 맥락, 역할, 조건 등을 구조적으로 설계하는 과정

💡 나의 생각

최근 노코드와 자동화에 관심이 생겨 직접 Zapier를 이용해 뉴스 리뷰 요약을 Google Docs에 자동 삽입하는 실습을 해보았다. 그래서 처음에는 이 글도 단순히 Zapier, Make, n8n, Dify 같은 자동화 툴들의 차이점을 설명하는 글이라고 생각했다.

하지만 실제로는 “자동화를 어떻게 설계해야 하는가”에 대한 이야기였다는 점이 인상 깊었다. 자동화는 단순히 툴을 연결하는 작업이 아니라, 사람이 반복적으로 수행하던 업무를 어떻게 분리하고 구조화할 것인지에 대한 설계 과정이라는 걸 느꼈다.

특히 가장 흥미로웠던 부분은 AI에게 한 번에 모든 작업을 맡기지 않고, 리서처 에이전트와 플래너 에이전트처럼 역할을 나눠 단계별로 처리했다는 점이었다. 처음에는 AI가 한 번에 다 처리할수록 더 효율적일 거라고 생각했는데, 오히려 작업을 세분화할수록 결과물의 품질과 신뢰도가 높아진다는 점이 새롭게 다가왔다.

또한 이 글을 통해 AI 자동화에서 중요한 것은 단순한 개발 능력이 아니라, “업무 흐름을 이해하고 기획할 수 있는 능력”이라는 생각도 들었다. 결국 AI도 사람이 어떤 맥락과 목표를 주느냐에 따라 결과가 완전히 달라지기 때문이다.

앞으로는 단순히 코드를 잘 작성하는 개발자보다, 반복 업무를 구조적으로 분석하고 AI에게 적절히 역할을 위임할 수 있는 사람이 더 중요한 역량을 가지게 될 것 같다고 느꼈다.

• 제목 : Zapier vs Make vs n8n 보다 미리 알아야 할 것들
• 출처 : 요즘 IT
• 기사 링크 : https://yozm.wishket.com/magazine/detail/3580/

📖 기사 핵심 요약

• 자동화는 툴 고르기가 아닌 업무 흐름에서 반복 작업을 분리해 위임하는 설계의 문제다.
• 업무에서 줄여야 할 반복이 어디에 숨어있나 찾는 일부터 시작해야 한다.
• 툴은 수단인데, 수단이 목적을 끌고 가는 순간 실패 확률이 올라간다.
• 업무 자동화는 분리 -> 표준화 -> 위임 프레임으로 보는 것이 좋다.
• 자동화 툴들은 대부분 같은 문법을 따른다. [트리거 - 조건 - 액션] 구조
  • "만약 [트리거]가 발생하면, [조건]을 검색해서, 맞으면 [액션]을 실행한다".
• 업무 흐름을 이 단계로 잘 나누면 사람이 손으로 넘기는 지점이 나타나고, 자동화는 보통 그 지점에 들어갈 때 가장 큰 효과가 나며, 사람이 시스템 사이를 오가는 순간을 찾아 대체하는 느낌이다.
• 거창한 설계는 실패의 지름길이다.
• 첫 자동화는 끝까지 목표로 하지 않는 게 안전하다.
• 자동화의 목적을 자주 점검해야 한다.(리드타임을 줄이고, 누락을 막고, 중복 없애기)
• 현업에서는 돌아가긴 하는데 불안한 자동화가 가장 위험하다. (권한/보안, 책임 소재)

[Zapier]

• 분기가 적을수록 속도가 난다. 연결을 빠르게 해서 도입 초반엔 일단 돌아가게 하는데 강하다.
• 복잡한 설계보다 실행이 먼저인 팀에 잘 맞는다.
• 다만 조건이 늘고 시나리오가 커질수록 관리가 어렵다. [Make]
• 한 번의 트리거에서 여러 액션으로 뻗는 형태에 유리하다.
• 시각화는 처음에는 좋지만, 복잡해지면 오히려 어디에 손을 대야하나 싶은 감각을 주기도 한다. [n8n]
• 사내 시스템 연동 같은 케이스에 적합하다.
• 커스터마이징에 초점이 맞춰진 도구다.
• 코드 기반 처리를 할 수 있다.
• 통제권을 온전히 쥐는 자동화에 적합하다.
• 입문에 난이도가 있다. [Dify]
• 생각하는 단계에 맡기는 도구에 가깝다.
• n8n보다 조금 더 난이도가 있다.

🔑 주요 키워드 정리

1️⃣ 업무 자동화(Workflow Automation) 반복적으로 수행되는 업무를 시스템이나 소프트웨어가 대신 수행하도록 만드는 과정이다.

2️⃣ Trigger–Condition–Action(T–C–A) 자동화의 기본 구조이다. Trigger(시작 조건) → Condition(실행 조건 판단) → Action(실제 수행) 순서로 동작한다.

💡 나의 생각

요근래 노코드의 개념부터 직접 실습까지 해보자는 생각으로, 최근에는 Zapier를 활용해 뉴스 리뷰 요약 내용을 Google Docs에 자동으로 삽입하는 자동화 흐름을 만들어보고 있다. 그래서 이 기사를 처음 봤을 때만 해도 단순히 Zapier, Make, n8n 같은 자동화 툴들의 차이점과 특징을 비교해주는 글이라고 생각했다.

하지만 글을 읽으면서 느낀 건, 자동화의 핵심은 “어떤 툴을 쓰느냐”보다 “어떤 업무를 어떻게 분리하고 설계하느냐”에 더 가깝다는 점이었다. 특히 반복되는 업무를 단순히 줄이는 것이 아니라, 업무 흐름 속에서 반복성과 규칙성을 찾아 시스템에 위임하는 과정이라는 설명이 인상 깊었다.

또한 Trigger–Condition–Action(T–C–A) 구조로 자동화를 바라보는 방식도 굉장히 실무적이라고 느꼈다. 예를 들어 내가 하고 있는 뉴스 리뷰 자동화 역시:

Trigger: 새로운 뉴스 리뷰 작성 Condition: 특정 키워드 또는 형식 만족 Action: Google Docs에 자동 저장

처럼 구조화할 수 있다는 점에서 자동화를 조금 더 체계적으로 이해하게 되었다.

특히 인상 깊었던 부분은 “자동화는 사람을 완전히 대체하는 것이 아니라, 사람이 반복적으로 하던 전달·복사·확인 같은 작업을 시스템에 위임하는 설계”라는 관점이었다. 이전에는 자동화를 단순히 편리한 기능 정도로 생각했는데, 이제는 업무 흐름 자체를 분석하고 병목을 찾아내는 사고방식이 더 중요하다는 걸 느꼈다.

툴 비교 부분도 흥미로웠다. Zapier는 빠르고 단순한 연결에 강하고, Make는 복잡한 흐름 설계, n8n은 높은 자유도와 자체 호스팅, Dify는 AI 기반 판단과 분류에 강점이 있다는 점에서 각각의 역할이 명확하게 다르다는 걸 알게 되었다. 결국 “어떤 툴이 최고인가”가 아니라, “현재 내 업무의 병목이 무엇인가”에 따라 선택해야 한다는 점도 공감됐다.

앞으로는 단순히 AI나 자동화 툴을 사용하는 수준을 넘어, 반복 업무를 구조적으로 바라보고 이를 효율적으로 위임할 수 있는 설계 능력이 더 중요해질 것 같다. 나 역시 작은 자동화부터 직접 만들어보면서, 단순 사용자가 아니라 업무 흐름을 설계할 수 있는 개발자로 성장해보고 싶다는 생각이 들었다.

• 알고리즘: 구현 알고리즘
• 문제 링크: 프로그래머스 - 실패율

풀이 과정

import java.util.*;

class Solution {
    public int[] solution(int N, int[] stages) {
        int[] answer = new int[N];

        HashMap<Integer, Double> map = new HashMap<>(); // 스테이지 번호, 실패율

        int users = stages.length; // 총 참여 인원
        double rate = 0; // 실패율

        for(int i = 1; i <= N; i++){

            int count = 0; // 실패자 카운트

            for(int j = 0; j < stages.length; j++){

                // ex) 1번 스테이지(N) 다 돌며 1번 실패자 찾기.
                if(i == stages[j]){
                    count++;
                }
            }

            if(users == 0) {
                rate = 0;
            } else {
                rate = (double) count / users;
            }

            map.put(i, rate);

            users = users - count;
        }

        // 실패율 정렬(내림차)
        List<Map.Entry<Integer, Double>> list =
                new ArrayList<>(map.entrySet());

        list.sort(Map.Entry.<Integer, Double>comparingByValue().reversed());

        for(int i = 0; i < N; i++){
            answer[i] = list.get(i).getKey();
        }

        return answer;
    }
}

• 문제 핵심:
• HashMap을 이용해 stage 마다 실패율 저장.
• 현재 스테이지에 머물러 있는 사람 수(count)를 이용해 실패율 계산.
• 스테이지를 순회하면서 이전 스테이지 실패 인원을 제외하기 위해 users -= count 처리.
• Map.Entry와 comparingByValue()를 사용하여 실패율 기준 내림차순 정렬.

📌 정렬 핵심 (Map.Entry)

HashMap = 저장용
List<Entry> = 정렬용 변환 구조
Comparator = 정렬 기준
-------------------------------------------------------------------------
✔ comparingByValue()
- value 기준 정렬
- 기본은 오름차순
✔ reversed()
- 정렬 방향 반전 → 내림차순
- list.sort(Map.Entry.<Integer, Double>comparingByValue().reversed());
    ☞ 실패율 높은 순으로 정렬

+추가 정리 ✔ comparingByKey() key 기준 정렬 가능 스테이지 번호 기준 정렬할 때 사용

📌 느낀 점

처음에는 문제 설명이 직관적으로 와닿지 않아 혼란이 있었지만, “현재 스테이지 = 아직 클리어하지 못한 위치”라는 구조를 이해한 뒤 풀이 방향이 명확해졌다.

구현 알고리즘은 머릿속에 있는 문제 해결 과정을 코드로 정확하게 표현하는 문제 유형이다. 그래서 논리적으로는 이해가 가지만 코드로 작성하게 되면 길어지는 경우가 있다.

즉, 복잡한 아이디어보다는 조건에 맞게 하나씩 그대로 작성하는 능력이 중요하다.

대표적으로는 다음과 같은 상황에서 사용된다.

문자열 처리 시뮬레이션 문제 좌표 이동 문제 배열 회전 문제

1️⃣ 대표적인 문제

🕹️ 상하좌우 문제

N x N 크기의 공간에서 사용자의 이동 계획에 따라 위치를 이동하는 문제

이동 가능한 방향:

L : 왼쪽 R : 오른쪽 U : 위 D : 아래

<풀이 핵심> : 이동 방향에 따라 좌표를 직접 변경한다.

int n = 5;

String[] move = {"R", "R", "R", "U", "D", "D"};

int x = 1;
int y = 1;

for(String dir : move){

    if(dir.equals("L") && y > 1){
        y--;
    }

    else if(dir.equals("R") && y < n){
        y++;
    }

    else if(dir.equals("U") && x > 1){
        x--;
    }

    else if(dir.equals("D") && x < n){
        x++;
    }
}

System.out.println(x + " " + y);

2️⃣ 그리디 알고리즘 문제 공식

구현 문제를 보면 보통 아래 흐름으로 접근한다.

✅ STEP 1. 문제 조건 정리하기 ex)

• 무엇을 이동하는가?
• 무엇을 출력해야 하는가?
• 예외 조건은 무엇인가?

✅ STEP 2. 변수와 상태 정의하기

현재 위치, 방향, 시간, 배열 상태 등을 변수로 저장한다.

예시:

좌표(x, y) 방향(dx, dy) 시간(time) 방문 여부(boolean)

✅ STEP 3. 조건대로 그대로 코드 작성하기

구현 문제는 알고리즘 아이디어보다 “문제에서 하라는 것을 정확하게 구현”하는 것이 핵심이다.

반복문과 조건문을 이용해 문제 흐름을 차근차근 코드로 옮긴다.

구현 문제는 문제 조건을 꼼꼼히 읽고 직접 흐름을 따라가는 연습이 핵심이다

3️⃣ 구현 알고리즘 문제

• 프로그래머스
  • 시뮬레이션 기둥과 보 설치
  • 문자열 구현: 문자열을 직접 하나씩 처리하는 문제 문자열 압축 신규 아이디 추천
  • 완전탐색 + 구현: 모든 경우를 직접 구현해서 검사 모의고사 체육복
  • 배열 구현(2차원) 키패드 누르기 프렌즈4블록
  • 조건 처리 구현 비밀지도 실패율

• 알고리즘: 그리디 알고리즘
• 문제 링크: 프로그래머스 - 구명보트

풀이 과정

import java.util.*;

class Solution {
    public int solution(int[] people, int limit) {
        Arrays.sort(people);

        int left = 0; // 가장 가벼운 사람
        int right = people.length - 1; // 가장 무거운 사람
        int answer = 0;

        while(left <= right) {
            if(people[left] + people[right] <= limit) {
                left++;
            }
            right--;
            answer++;
        }


        return answer;
    }
}

• 문제 핵심: 가장 무거운 사람 기준으로 생각하기.
• 투포인터를 이용해 턴 마다 가장 무거운 사람을 무조건 태워 보내야 한다는 개념으로 코드 설계

• 알고리즘: 그리디 알고리즘
• 문제 링크: 프로그래머스 - 조이스틱

풀이 과정

class Solution {
    public int solution(String name) {
        int answer = 0;

        // 좌우 이동 최소값
        int move = name.length() - 1;

        for(int i = 0; i < name.length(); i++) {
            char c = name.charAt(i);

            // 위/아래 이동 계산
            answer += Math.min(c - 'A', 'Z' - c + 1);

            int next = i + 1;

            while(next < name.length() && name.charAt(next) == 'A') next++;

            // 좌우 이동 최소값 갱신(예: AAAABBA)
            move = Math.min(move, i+name.length() - next + Math.min(i, name.length() - next));
        }

        answer += move;

        return answer;
    }
}

[핵심코드]

• 위/아래 조작(알파뱃 조작)

  • Math.min(c-'A', 'Z'-c+1)
    • c - 'A': 위로 이동 (A → B 방향)
    • 'Z' - c + 1: 아래로 이동 (A → Z 방향)

• while문의 역할: 연속된 A 구간의 끝 위치(next) 찾기

• 커서 이동 최소화

  move = Math.min(
      move,
      i + name.length() - next + Math.min(i, name.length() - next)
  );

  • name.length() - next 뒤쪽 남은 거리
  • Math.min(i, name.length() - next) 방향 전환 비용 최소 선택

• 알고리즘: 그리디 알고리즘
• 문제 링크: 프로그래머스 - 체육복

풀이 과정

import java.util.*;

class Solution {
    public int solution(int n, int[] lost, int[] reserve) {
        int answer = 0;

        int[] clothes = new int[n+2]; // 배열 범위 에러 방지 & 1부터 시작하기 위함

        Arrays.fill(clothes, 1);

        for(int l : lost) {
            clothes[l]--;
        }

        for(int r : reserve){
            clothes[r]++;
        }

        // 빌려주기
        for(int i = 1; i<=n; i++){
            if(clothes[i]==0) {
                if(clothes[i-1] == 2) {
                    clothes[i-1]--;
                    clothes[i]++;
                }
                else if(clothes[i+1] == 2) {
                    clothes[i+1]--;
                    clothes[i]++;
                }
            }
        }

        for(int i = 1; i<=n; i++) {
            if(clothes[i]>=1){
                answer++;
            }
        }

        return answer;
    }
}

• int[] clothes = new int[n+2]; → n+2를 함으로써 배열을 1부터 시작하게 한다 & 배열 범위 초과 에러를 방지한다.
• for문 + if문을 통해 앞/뒤 학생에게 빌릴 수 있다.