<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://ogongchill.github.io/</id><title>507</title><subtitle>507의 서비스와 고민을 정리하는 공간입니다</subtitle> <updated>2026-04-01T16:50:00+09:00</updated> <author> <name>ogongchill</name> <uri>https://ogongchill.github.io/</uri> </author><link rel="self" type="application/atom+xml" href="https://ogongchill.github.io/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://ogongchill.github.io/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 ogongchill </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>바로 자동화 - Phase 1. 이슈 자동화 생성</title><link href="https://ogongchill.github.io/posts/%EB%B0%94%EB%A1%9C-%EC%9E%90%EB%8F%99%ED%99%94-Phase1/" rel="alternate" type="text/html" title="바로 자동화 - Phase 1. 이슈 자동화 생성" /><published>2026-03-25T00:00:00+09:00</published> <updated>2026-03-26T21:12:32+09:00</updated> <id>https://ogongchill.github.io/posts/%EB%B0%94%EB%A1%9C-%EC%9E%90%EB%8F%99%ED%99%94-Phase1/</id> <content type="text/html" src="https://ogongchill.github.io/posts/%EB%B0%94%EB%A1%9C-%EC%9E%90%EB%8F%99%ED%99%94-Phase1/" /> <author> <name>ogongchill</name> </author> <category term="Git" /> <category term="DevOps" /> <category term="AI" /> <summary>1. 목표 이 시스템의 목표는 사용자의 자연어 입력을 구조화된 기능 명세서로 변환하는 것이다. 시스템은 Slack을 Approval Gate로 사용하는 human-in-the-loop 방식을 전제로 한다. 따라서 기능 명세 자동화 시스템은 처음부터 Slack 친화적인 상호작용 구조를 갖추어야 한다. 즉, 다음 조건을 만족해야 한다. 자연어 요청을 입력으로 받는다. 코드와 문서를 분석해 기능 명세 초안을 생성한다. Slack에서 사용자가 검토·수정·승인할 수 있어야 한다. 승인 이전에는 다음 단계로 넘어가지 않도록 통제되어야 한다. 2. 시스템 추상화 에이전트를 전체 시스템의 주체가 아니라, workflow 내부의 실행 단위로 제한하도록 구성하였다. 앞서 보았듯이 ‘에이...</summary> </entry> <entry><title>바로 자동화 - Phase 2 구현하기</title><link href="https://ogongchill.github.io/posts/%EB%B0%94%EB%A1%9C-%EC%9E%90%EB%8F%99%ED%99%94-Phase2-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0/" rel="alternate" type="text/html" title="바로 자동화 - Phase 2 구현하기" /><published>2026-03-24T00:00:00+09:00</published> <updated>2026-03-24T00:00:00+09:00</updated> <id>https://ogongchill.github.io/posts/%EB%B0%94%EB%A1%9C-%EC%9E%90%EB%8F%99%ED%99%94-Phase2-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0/</id> <content type="text/html" src="https://ogongchill.github.io/posts/%EB%B0%94%EB%A1%9C-%EC%9E%90%EB%8F%99%ED%99%94-Phase2-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0/" /> <author> <name>ogongchill</name> </author> <category term="Git" /> <category term="DevOps" /> <category term="AI" /> <summary>0. 들어가며 지난 글에서 자동화 시스템의 설계 방향과 Phase별 로드맵을 정리했다. 요약하자면 자연어를 직접 코드 생성에 쓰는 것은 위험하며, 자연어 → 명세 → 코드라는 이단 구조가 핵심이었다. 이번 글에서는 그 계획을 실제로 어떻게 구현했는지를 다룬다. Phase 1에서 Phase 2로 전환하는 오케스트레이터, BE-claude-dev-worker를 설계하고 만들면서 겪은 것들이다. 1. 현재 위치: Phase 1 → Phase 2 기존 로컬 워크플로우는 다음과 같았다. 개발자가 터미널에서 직접 claude --print '/dev:start-task 123' 실행 → plan.md 생성 → 눈으로 확인 → claude --print '/dev:continue-task 12...</summary> </entry> <entry><title>바로 자동화-계획하기</title><link href="https://ogongchill.github.io/posts/%EB%B0%94%EB%A1%9C-%EC%9E%90%EB%8F%99%ED%99%94-%EA%B3%84%ED%9A%8D%ED%95%98%EA%B8%B0/" rel="alternate" type="text/html" title="바로 자동화-계획하기" /><published>2026-03-21T00:00:00+09:00</published> <updated>2026-03-24T18:14:05+09:00</updated> <id>https://ogongchill.github.io/posts/%EB%B0%94%EB%A1%9C-%EC%9E%90%EB%8F%99%ED%99%94-%EA%B3%84%ED%9A%8D%ED%95%98%EA%B8%B0/</id> <content type="text/html" src="https://ogongchill.github.io/posts/%EB%B0%94%EB%A1%9C-%EC%9E%90%EB%8F%99%ED%99%94-%EA%B3%84%ED%9A%8D%ED%95%98%EA%B8%B0/" /> <author> <name>ogongchill</name> </author> <category term="Git" /> <category term="DevOps" /> <category term="AI" /> <summary>0. 들어가며 현재 팀은 두명으로 모바일 어플리케이션과 서버, 인프라를 모두 작업하고 있다. 따라서 개발 속도가 빠르지 못하여 릴리즈 주기가 점점 늘어지고 있다. 이대로 가다가는 스토어에서 철퇴를 맞을수도 있다. 다행히 시대가 바뀌었다. 더이상 코드를 생성하는 것은 사람만이 할 수 있는 작업이 아니다. 오히려 LLM이 이를 더욱 효과적으로 수행하고 있다. 그러나 기업은 더이상 이전처럼 사람을 구하지 않는다. 비극일까 구인난이 심화되었지만 동시에 개개인의 생산성도 매우 증가했다. 이는 현재 우리에게는 기회이다. 빠르게 변화하는 흐름에 탑승하여 적은 인원으로 최대의 효율을 내고자 한다. 엔터프라이즈급 자동화가 목표는 아니다. 우리는 툭툭 던지는 아이디어를 빠르게 개발하여 릴리즈 하는 것을 목표로 한...</summary> </entry> <entry><title>코드 자동화를 위한 설계 - 에이전트 이해하기</title><link href="https://ogongchill.github.io/posts/agent/" rel="alternate" type="text/html" title="코드 자동화를 위한 설계 - 에이전트 이해하기" /><published>2026-03-15T00:00:00+09:00</published> <updated>2026-03-23T14:30:04+09:00</updated> <id>https://ogongchill.github.io/posts/agent/</id> <content type="text/html" src="https://ogongchill.github.io/posts/agent/" /> <author> <name>ogongchill</name> </author> <category term="Git" /> <category term="DevOps" /> <category term="AI" /> <summary>Barlow Automation 0. 들어가며 Slack 슬래시 커맨드로 개발자가 기능/리팩토링/버그 요청을 입력하면, AI가 GitHub 코드를 분석해 GitHub 이슈 초안을 자동 생성하는 시스템을 구축하고자 한다. 현재 상당히 거지이므로 최대한 비용 효율적이며 관리하기 용이한 Github Issue 자동화 워크플로우를 구축한는 것을 목표로 시작하였다. 그러나 진행할수록 여러 무엇을 어떻게 만들어야 할지에 관한 방향성을 확실하게 잡지 못한 상태로 프로젝트의 진행이 모처럼 되지 않았다. LLM 과 Agent 그리고 이를 지원하는 여러 소프트웨어 생태에 관한 이해 없이 무작정 시작했기 때문이다. 현재 프로젝트의 방향성을 보다 명확히 하고, 설계를 확실하게 하기 위해 글을 통해 정리하고자 한다. ...</summary> </entry> <entry><title>Play Store 배포를 위한 CI/CD 구축하기</title><link href="https://ogongchill.github.io/posts/PlayStore%EB%B0%B0%ED%8F%AC/" rel="alternate" type="text/html" title="Play Store 배포를 위한 CI/CD 구축하기" /><published>2025-08-31T00:00:00+09:00</published> <updated>2025-08-31T00:00:00+09:00</updated> <id>https://ogongchill.github.io/posts/PlayStore%EB%B0%B0%ED%8F%AC/</id> <content type="text/html" src="https://ogongchill.github.io/posts/PlayStore%EB%B0%B0%ED%8F%AC/" /> <author> <name>ogongchill</name> </author> <category term="Git" /> <category term="DevOps" /> <summary>들어가며 현재 barlow 어플리케이션은 Google Play Store에 입점해있습니다. Play Store에 어플리케이션을 업데이트하는 과정은 다음과 같습니다. [수정사항 빌드] ↓ [Play Console에 번들 추가] ↓ [특정 트랙 버전 승급] ↓ [Google에 의한 심사] ↓ [심사통과/거절] Play Store의 정책이 바뀌어 신규 개발계정에 대해 까다로운 심사를 요구하므로 이에 대응하기 위해 Play Console을 통해 빌드 산출물은 수동으로 업데이트하고 트랙을 관리했었습니다. 현재는 이를 Github Actions를 사용하여 workflow단위로 자동화 하였습니다. 왜 Github Actions인가? Jenkins, GitLab 등 강력한 기능을 ...</summary> </entry> </feed>
