과정을 공개하며,함께 만듭니다

goodtek

Git으로 Obsidian 노트를 동기화할 때 충돌을 줄이는 원칙

Android에서 Obsidian으로 메모를 수정하고, Termux에서 Git으로 "pull", "commit", "push"를 해보면서 중요한 걸 하나 배웠습니다. Git은 파일을 잘 합쳐주지만, 같은 파일의 같은 위치를 여러 기기에서 동시에 수정하면 자동으로 처리하기 어렵다는 점입니다. 예를 들어 PC에서 "content/backlog/tasks.md"를 수정하고 GitHub에 push했습니다. 그런데 Android에서도 같은 "tasks.md"를 수정한 상태에서 "git pull --rebase"를 실행하면 충돌이 날 수 있습니다. GitHub: A → B Android: A → C Git은 GitHub의 최신 변경사항 "B" 위에 Android의 변경사항 "C"를 다시 얹으려고 합니다. A → B → C 하지만 "B"와 "C"가 같은 파일, 같은 줄 근처를 수정했다면 Git은 어느 쪽 내용을 살려야 할지 판단하지 못합니다. 그래서 이런 충돌이 발생합니다. CONFLICT (content): Merge conflict in content/backlog/tasks.md 이건 Git이 망가진 것이 아니라, 오히려 내용을 함부로 덮어쓰지 않기 위해 멈춘 것입니다. 동시에 수정하면 왜 어려운가 서로 다른 파일을 수정하면 Git이 대부분 자동으로 합칠 수 있습니다. PC → content/blog/idea.md 수정 Android → content/backlog/tasks.md 수정 이 경우는 충돌 가능성이 낮습니다. 하지만 같은 파일을 양쪽에서 수정하면 충돌 가능성이 높아집니다. PC → content/backlog/tasks.md 수정 Android → content/backlog/tasks.md 수정 특히 같은 줄 근처를 수정하면 Git은 사람이 판단해야 한다고 보고 멈춥니다. 결국 문제는 “Git을 못 써서”가 아니라, 하나의 파일을 여러 기기에서 동시에 편집하는 구조 자체가 충돌에 취약하다는 점입니다. 앞으로의 운영 원칙 Goodtek notes는 Android, PC, GitHub가 함께 쓰이는 구조입니다. 그래서 앞으로는 아래 원칙으로 운영하는 것이 좋겠습니다. 수정 전에는 먼저 받기 수정 후에는 바로 올리기 Android에서 작업할 때는 먼저 최신 상태를 받습니다. pull-notes 그 다음 Obsidian에서 메모를 수정합니다. 수정이 끝나면 바로 올립니다. sync-notes PC에서 작업할 때도 마찬가지입니다. git pull --rebase origin main 메모 수정 git add content git commit -m "Update notes" git push 핵심 흐름은 단순합니다. 받고 → 쓰고 → 올리기 파일을 쪼개면 충돌이 줄어든다 "tasks.md" 하나에 모든 백로그를 계속 적으면 충돌이 자주 날 수 있습니다. 특히 Android와 PC에서 자주 열어보는 파일이라면 더 그렇습니다. 그래서 하나의 큰 파일에 모든 걸 넣기보다, 역할별로 나누는 편이 좋습니다. 예를 들면 이렇게 나눌 수 있습니다. content/backlog/ ├── inbox.md ├── tasks.md ├── ideas.md └── content-ideas.md 더 충돌을 줄이려면 날짜별 파일도 괜찮습니다. content/backlog/daily/ ├── 2026-06-03.md ├── 2026-06-04.md └── 2026-06-05.md 또는 월별로 나눌 수도 있습니다. content/backlog/ ├── tasks-2026-06.md ├── ideas-2026-06.md └── content-ideas-2026-06.md 이렇게 하면 PC와 Android가 같은 파일을 동시에 수정할 확률이 줄어듭니다. Goodtek notes 추천 구조 Goodtek notes에서는 Android와 PC의 역할을 나누는 방식이 좋아 보입니다. Android → 빠른 메모, 순간적으로 떠오른 생각 기록 PC → 정리, 편집, 블로그 글로 확장, 구조화 그래서 Android에서는 주로 "inbox.md"를 사용합니다. content/backlog/inbox.md 생각난 것은 일단 여기에 빠르게 적습니다. 나중에 Android Git 동기화 글 블로그로 정리하기 notes.goodtek.xyz 백로그 구조 정리하기 sync-notes 충돌 방지 로직 개선하기 그리고 PC에서 시간이 날 때 정리합니다. inbox.md → tasks.md → content-ideas.md → build-log → blog.goodtek.xyz 글 이렇게 하면 Android에서는 빠르게 기록하고, PC에서는 천천히 정리할 수 있습니다. 정리 이번에 배운 것은 단순한 Git 명령어가 아닙니다. Obsidian 노트를 여러 기기에서 운영하려면 Git 충돌을 없애는 것보다, 충돌이 덜 나게 쓰는 구조를 만드는 것이 더 중요하다는 점입니다. 앞으로 Goodtek notes는 이렇게 운영합니다. Android에서 쓰기 전 pull-notes Android에서 쓴 후 sync-notes PC에서 쓰기 전 git pull --rebase PC에서 쓴 후 git push Android는 inbox 중심 PC는 정리와 편집 중심 하나의 큰 파일보다 작은 파일 여러 개 동시에 같은 파일 수정하지 않기 결국 핵심은 이것입니다. Git을 잘 쓰는 방법은 충돌을 잘 해결하는 것만이 아니다. 충돌이 덜 나는 기록 구조를 만드는 것이다. Goodtek notes도 이런 작은 운영 원칙을 하나씩 쌓아가면서 더 오래 유지할 수 있는 기록 시스템으로 만들어가야겠습니다.

goodtek

무작정 만들고 나중에 고치면 될까?

요즘 ● goodtek-web을 만들면서 계속 드는 생각이 있습니다. “일단 만들고, 나중에 구조 잡으면 되지 않을까?” 초반에는 이 말이 꽤 합리적으로 들립니다. 너무 처음부터 완벽한 구조를 잡으려고 하면 속도가 안 나고, 아직 아무도 쓰지 않는 제품에 과한 시스템을 붙이는 것도 낭비처럼 보입니다. 저도 처음에는 일단 돌아가게 만드는 쪽에 가까웠습니다. 화면이 뜨고, 기능이 동작하고, 서버에 올라가면 일단 다음으로 넘어갔습니다. 그런데 계속 만들다 보니 생각이 조금 바뀌었습니다. 나중에 붙이는 게 생각보다 쉽지 않습니다. 배포 자동화든, CI/CD든, 브랜치 전략이든, 무중단 배포든 겉으로 보면 “나중에 붙이면 되는 것”처럼 보입니다. 하지만 실제로는 기존 구조를 꽤 많이 건드리게 됩니다. 배포 방식이 바뀝니다. 브랜치 흐름이 바뀝니다. 서버에 코드가 반영되는 방식이 바뀝니다. 환경 변수 관리 방식이 바뀝니다. 컨테이너를 재시작하는 방식도 바뀝니다. 이건 단순히 설정 파일 몇 개를 추가하는 일이 아니었습니다. 제품이 돌아가는 흐름 자체를 바꾸는 일에 가까웠습니다. 더 큰 문제는, 그때 이미 고객이 쓰고 있을 수도 있다는 점입니다. 고객이 사용하는 제품에 배포 구조를 크게 바꾸는 건 단순한 리팩토링이 아닙니다. 서비스가 중간에 멈출 수 있습니다. 예상하지 못한 502가 날 수 있습니다. 새 컨테이너가 정상적으로 뜨지 않을 수 있습니다. 롤백이 준비되어 있지 않으면 대응도 어려워집니다. dev 환경에서는 괜찮습니다. “잠깐 안 되네. 다시 보자.” 이렇게 넘길 수 있습니다. 하지만 고객이 돈을 내고 쓰는 production 환경에서는 다릅니다. 그 잠깐의 중단도 사용자 경험이 됩니다. 그리고 그 경험은 신뢰와 바로 연결됩니다. 그래서 이번에 ● goodtek-web에 Git Flow + GitHub Actions 기반 dev CI/CD를 먼저 붙였습니다. 흐름은 이렇게 잡았습니다. task 브랜치 → PR → CI 검증 → develop 머지 → dev 서버 자동 배포 → health check 겉으로 보면 기능은 하나도 늘지 않았습니다. 사용자 화면이 좋아진 것도 아니고, 새로운 버튼이 생긴 것도 아닙니다. 하지만 제품을 계속 운영할 수 있는 기반은 조금 더 단단해졌습니다. 이번 작업의 목적은 “자동 배포 붙였다”가 아니었습니다. 나중에 고객이 쓰고 있는 제품 위에서 위험하게 구조를 갈아엎지 않기 위해, 지금 dev 환경에서 미리 흐름을 잡아두는 것이었습니다. 처음부터 모든 걸 완벽하게 만들 필요는 없다고 생각합니다. 하지만 나중에 붙이기 어려운 것들은 분명 있습니다. 배포 구조. 데이터 구조. 인증 구조. 권한 구조. 운영 환경. 이런 것들은 제품이 커지고 사용자가 생긴 뒤에 바꾸려면 비용이 커집니다. 그때는 코드만 바꾸는 게 아니라, 이미 사용 중인 서비스를 건드리는 일이 되기 때문입니다. 요즘은 그래서 이런 기준을 세우고 있습니다. 빠르게 만들어도 된다. 하지만 나중에 붙이면 제품을 흔들 수 있는 것들은 너무 늦기 전에 바닥을 깔자. 이번 dev CI/CD 작업도 그런 맥락이었습니다. 아직 완전한 무중단 배포까지 간 건 아닙니다. 하지만 다음 단계로 갈 수 있는 길은 열어뒀습니다. 앞으로는 이런 것들을 차근차근 붙여가야 합니다. production 배포 workflow. 운영 배포 승인 절차. GHCR 기반 이미지 배포. blue/green 배포. 롤백 가능한 구조. 오늘도 화려한 기능은 아니었습니다. 하지만 나중에 고객이 쓰고 있는 제품 위에서 식은땀 흘리며 구조를 바꾸지 않기 위해, 지금 작은 dev 환경에서 먼저 연습하고 있습니다. 여러분은 어떤 것들이 **“나중에 붙이면 늦는 구조”**라고 생각하시나요?

goodtek

AI 코딩을 쓸 때, 여러분은 어디까지 AI에게 맡기시나요?

최근 goodtek-web 첫 작업을 하면서 느낀 건, AI가 코드를 빨리 만들어줄수록 작업 기준이 더 중요해진다는 점이었습니다. 예를 들면 이런 기준입니다. 작업 시작 전에 범위를 먼저 정한다 무엇을 하지 않을지도 함께 정한다 구현 전에 Plan을 남긴다 완료 기준과 테스트 결과를 기록한다 작업은 PR 단위로 닫는다 저는 이번에 Task → Plan → Build → Test → PR 흐름으로 정리해봤습니다. 여러분은 AI 코딩할 때 어떤 방식으로 프로젝트가 어지러워지는 걸 막고 계신가요? 좋았던 방식, 실패했던 방식, 아직 고민 중인 방식 모두 궁금합니다. [블로그 글 확인하기] https://t.co/WaaG9afLRf