AI 에이전트의 판단 근거, 로그만으로 부족한 이유 — ‘Workflow as Knowledge’ 논문 리뷰

AI 에이전트가 여러 도구를 호출하고 사람의 승인을 받아 결론을 냈습니다. 며칠 뒤 “왜 그 결론이었지?”라고 물었을 때 로그는 남아 있어도 당시 모델이 본 맥락, 판단에 영향을 준 자료, 승인한 사람과 의존관계는 한 번에 찾기 어렵습니다.

2026년 7월 9일 공개된 「Workflow as Knowledge: Semantic Persistence for LLM-Mediated Workflows」는 이 문제에 한 가지 답을 제안합니다. LLM 워크플로를 실행하고 사라지는 절차가 아니라, 정의·실행 인스턴스·모델 판단·맥락·승인·의존관계가 연결된 지식 객체로 남기자는 것입니다. 논문은 이를 semantic persistence, 여기서는 의미 지속성이라고 부르겠습니다.

PR Comic · 다메카솔 — 복잡한 기술 논문을 한국어 만화와 검색 가능한 글로 풀어냅니다.

핵심 내용

• 체크포인트와 로그는 실행을 이어 주지만, 판단의 의미와 관계를 곧바로 설명해 주지는 않습니다.
• 논문은 워크플로 정의와 실행, 모델 판단, 맥락, 승인 기록을 같은 지식 기반 안의 질의 가능한 객체로 표현하자고 제안합니다.
• 결정적 계산인 derive와 LLM이 매개한 판단인 infer를 분리하고, 외부 행동의 권한은 실행기 정책에 둡니다.
• 이 제안은 아직 개념 모델입니다. 구현, 형식 의미론, 비교 실험, 기록 수명주기 정책은 남아 있습니다.

결과 파일이 있다는 사실과 그 결과를 만든 결정의 계보를 설명할 수 있다는 사실은 다릅니다. 이 논문은 바로 그 간극을 다룹니다.

왜 실행 로그만으로는 부족한가

일반적인 LLM 애플리케이션에서 워크플로 정의는 코드나 설정 파일에 있습니다. 실행 중 상태는 런타임이나 체크포인트 저장소가 관리하고, 모델 출력은 로그·트레이스·데이터베이스 행·대화 기록으로 남습니다. 각 시스템은 필요한 일을 하고 있지만, 시간이 지난 뒤 다음 질문에 답하려면 여러 저장 위치를 다시 맞춰야 합니다.

• 이 결정은 어떤 워크플로 버전에서 나왔는가?
• 모델은 그때 어떤 자료와 지시를 볼 수 있었는가?
• 어떤 모델 판단이 다음 분기에 영향을 주었는가?
• 누가 무엇을 승인했고, 그 승인은 어느 행동을 허용했는가?

논문의 문제 제기는 “기존 워크플로 엔진이 아무것도 저장하지 않는다”가 아닙니다. 저장된 흔적에 정의된 의미 역할과 관계가 있는지가 핵심입니다. 모델 판단, 사람 승인, 숙의, 맥락을 나중에 우연히 연결하는 대신 실행 전부터 서로 다른 종류의 객체로 선언하자는 제안입니다.

실행 지속성과 의미 지속성은 무엇이 다른가

실행 지속성은 중단된 일을 이어 가는 문제입니다. 상태, 체크포인트, 로그, 출력이 있으면 런타임은 실패 지점에서 다시 시작하거나 사람이 실행 과정을 검사할 수 있습니다.

의미 지속성은 실행이 끝난 뒤에도 워크플로 자체와 중요한 판단 기록을 지식으로 다루는 문제입니다. “다시 실행할 수 있는가?”를 넘어 “왜 이런 결론이 나왔고 무엇에 의존했는가?”를 질의할 수 있어야 합니다.

논문의 개념을 바탕으로 새로 구성한 설명 도식입니다. 원문 Figure를 복제하지 않았습니다.

논문이 말하는 공유 지식 기반은 특정 데이터베이스 제품을 뜻하지 않습니다. 그래프 데이터베이스, RDF 저장소, 객체 저장소, 이벤트 로그, 관계형 데이터베이스, Lisp 이미지 등은 가능한 구현 선택지일 뿐입니다. 제안의 중심은 저장 기술이 아니라 객체의 정체성, 타입, 맥락, 관계를 실행 경계 너머로 유지하는 모델입니다.

워크플로 정의도 데이터 객체가 된다

논문은 크게 다음 객체를 같은 기반 안에서 연결합니다.

중요한 차이는 활성 상태와 영구 기록도 분리한다는 점입니다. 실행 중 필요한 값이 모두 장기 보존 대상은 아닙니다. 반대로 결과에 영향을 준 판단과 승인이라면 단순한 임시 UI 이벤트로 사라지지 않고, 맥락과 연결된 기록으로 남길 수 있습니다.

derive와 infer: 계산과 모델 판단을 같은 상자로 넣지 않는다

이 논문에서 가장 실용적인 구분은 derive와 infer입니다.

• derive는 이미 있는 상태를 대상으로 한 결정적 계산입니다. 파서, 스키마 검사, 린터, 테스트, 타입 검사, 라우팅 규칙처럼 입력과 규칙을 명시하면 재생하고 검증할 수 있는 작업입니다.
• infer는 선언된 맥락에서 이루어지는 LLM 매개 판단입니다. 분류, 종합, 초안 작성, 의미 검토, 모델 심사처럼 같은 입력에서도 판단이 달라질 수 있는 작업입니다.

논문의 infer는 모델에게 워크플로 전체 권한을 넘기는 명령이 아닙니다. 실행기는 보여 줄 맥락을 구성하고, 반환 형식을 검사하고, 결과를 기록하며, 허용된 전이만 적용합니다. 모델 출력이 이후 분기에 영향을 주더라도 그 의존관계를 기록하고 외부 행동의 직접 권한은 실행기 정책에 둡니다.

또한 이 구분은 보안 증명이 아니며 모든 작업에 하나의 정답 경계가 있다는 뜻도 아닙니다. 어떤 작업은 코드로 계산할 수도 있고 모델 판단에 맡길 수도 있습니다. 논문의 요구는 그 선택을 숨기지 말고 명시하고 검토 가능하게 만들라는 쪽에 가깝습니다.

승인과 숙의는 같은 사람 개입이 아니다

사람이 개입했다고 해서 모든 이벤트가 같은 의미를 갖지는 않습니다.

approval은 권한에 가깝습니다. 다음 전이나 외부 행동을 허용할지, 거부할지, 나중으로 미룰지를 결정합니다. 반면 panel은 구조화된 숙의입니다. 무엇을 논의했는지, 어떤 선택지가 있었는지, 찬반 근거와 불확실성이 무엇이었는지, 어떤 맥락에서 결론을 냈는지를 남깁니다.

이 구분이 있으면 나중에 “사람이 확인했다”는 한 줄을 넘어 다음을 살필 수 있습니다.

1. 모델이 어떤 판단 후보를 만들었는가
2. 그 판단에 어떤 맥락이 제공됐는가
3. 사람은 행동을 승인했는가, 아니면 논거를 검토했는가
4. 최종 결과가 어떤 자료와 판단에 의존하는가

저자들이 기대하는 효용은 워크플로 이력을 질의하고, 당시 판단에 보인 맥락을 더 정확히 검토하며, 계산·모델 판단·사용자 승인·실행기 전이의 권한 관계를 분리하는 것입니다. 다만 이것이 실제 감사 품질이나 신뢰를 높이는지는 아직 검증할 문제입니다.

이 논문이 아직 증명하지 않은 것

이 논문은 position paper, 즉 구현 성능을 입증하기보다 문제를 새롭게 정의하고 개념 모델을 제안하는 논문입니다. 저자들은 선별된 77개 워크플로 관련 자료를 살펴 어휘의 빈틈을 점검했지만, 이 자료 모음은 이질적이고 대표 표본이 아닙니다. 논문도 이 수치를 현장의 보편적 빈도나 중심 주장의 실증 근거로 사용하지 않습니다.

또한 다음 과제가 남아 있습니다.

• derive, infer, 승인, 맥락, 재개의 형식적 전이 규칙
• 체크포인트·트레이스 중심 시스템과의 비교 구현
• 저장량, 색인 비용, 검토 비용 측정
• 기록을 유지·요약·대체·보관·삭제하는 수명주기 정책
• 귀속, 재현성, 감사 품질, 신뢰에 대한 사람 대상 평가

모든 중간 출력을 영구 저장하면 의미가 풍부해지는 것이 아니라 잡음과 비용이 커질 수 있습니다. 낮은 품질의 모델 출력, 나중에 반박된 판단, 중복 맥락을 어떻게 대체하거나 삭제할지도 모델의 일부가 되어야 합니다.

PR Comic 해석: ‘모두 저장’보다 ‘다시 물을 구조’

이 논문의 실용적 가치는 당장 새로운 프레임워크를 도입하라는 데 있지 않습니다. 현재 워크플로를 볼 때 다음 네 질문을 분리해 던질 수 있다는 점에 있습니다.

• 무엇이 결정적 계산이고 무엇이 모델 판단인가?
• 그 판단은 실제로 어떤 맥락을 보았는가?
• 누가 어떤 행동을 승인했는가?
• 최종 결과는 어떤 자료와 판단에 의존하는가?

네 질문에 답할 수 없다면 로그가 많아도 결정의 계보는 약합니다. 반대로 중요한 판단만 타입과 맥락, 의존관계로 연결할 수 있다면 실행이 끝난 뒤에도 워크플로를 검토하고 수정하고 다시 사용할 가능성이 커집니다.

가장 작은 시작은 프레임워크 도입이 아닙니다. 모델 호출을 일반 함수 호출과 같은 로그로만 남기지 말고, 판단의 목적, 실제 입력 맥락, 검증 결과, 영향을 받은 분기, 승인 주체를 분리해 기록해 보는 것입니다. 논문의 완전한 구현이 아니라 작은 설계 실험이지만, 위 네 질문에 답할 수 있는 구조가 처음 생깁니다.

이것은 논문이 입증한 운영 효과가 아니라, 논문의 개념 모델을 개발자 설계 점검표로 바꾼 해석입니다.

논문 정보

자주 묻는 질문

의미 지속성은 체크포인트를 대체하나요?

아닙니다. 체크포인트는 실행을 복구하는 데 필요합니다. 의미 지속성은 그 위에 워크플로 정의와 판단, 맥락, 승인, 의존관계를 지식으로 질의하는 층을 추가하자는 제안입니다.

infer 결과가 분기를 바꾸면 모델이 워크플로를 통제하는 것 아닌가요?

논문의 모델에서는 그렇지 않습니다. 모델은 선언된 자리에서 판단 후보를 만들고, 실행기가 검증과 정책을 적용해 허용된 전이를 수행합니다. 판단이 분기에 영향을 주었다는 관계도 별도 기록으로 남깁니다.

기록을 많이 남기면 신뢰할 수 있는 AI가 되나요?

논문도 그렇게 주장하지 않습니다. 지속 기록은 검토할 재료를 제공하지만 정확성, 신뢰, 재현성, 감사 품질을 자동으로 보장하지 않습니다. 기록 수명주기와 권한 정책, 실제 평가가 따로 필요합니다.

출처

• Emanuele Quinto, Carlo Andrea Rozzi, Francesco Zanitti, “Workflow as Knowledge: Semantic Persistence for LLM-Mediated Workflows,” arXiv:2607.08740 (2026)
• arXiv HTML 본문

이 글의 만화 이미지는 AI로 생성했습니다.

LLM은 주가를 예측할 수 있을까? : 국회 입법 데이터 기반 퀀트 시스템 개발기 (정확도 55% 달성 회고)

TL;DR

문제: 입법 정보는 주가에 큰 영향을 주지만, 개인 투자자가 이를 정량적으로 분석하기는 불가능했습니다.

해결: 국회 입법 데이터를 수집하고 GPT-4o로 호재/악재를 분석해 주가 예측 모델(XGBoost)에 반영하는 파이프라인을 구축했습니다.

결과: 5일 후 주가 등락 예측 정확도(Directional Accuracy) 약 55%를 달성했습니다.

교훈: 프롬프트보다 중요한 것은 '데이터 구조화(JSON)'였으며, AI 코딩 시대에도 도메인 데이터(재무제표)의 중요성은 변하지 않았습니다.

1. 프롤로그: 위기감에서 시작된 도전

"1~2년 뒤에도 나는 개발자로 살아남을 수 있을까?"

요즘 일이든 일상생활이든 AI를 사용하지 않는 사람들은 드물 것 같습니다. 사이드 프로젝트든, 실무든 대부분의 상황에서 AI를 사용하다 보니 정말로 개발자가 1,2년 뒤면 사라질 것 같다는 위기의식을 크게 느꼈습니다.
그래서 고민 끝에 내린 결론은 하나였습니다.
"살아남으려면 AI를 엄청 잘 쓰는 개발자가 되거나, AI 자체를 개발하는 개발자가 되어야겠다."

AI 개발에 관심이 있어 패스트캠퍼스에서 LLM 관련 강의를 찾아보던 중, 마침 이론보다는 프로젝트 위주로 진행되는 KDT 프로그램을 발견했습니다. 회사에서 AI에 관심이 많은 동료 개발자 한 명을 꼬셔서 함께 이 프로그램에 합류하게 되었습니다.

2. 프로젝트 개요: 입법 데이터와 주가의 상관관계

기존 퀀트 투자는 주로 이동평균선 같은 기술적 지표나 재무제표에 의존합니다. 하지만 실제 시장은 '정책'에 민감하게 반응합니다.

• 반도체 보조금 법안 통과 → 반도체 소부장 기업 호재
• 전기차 보조금 축소 → 2차전지 기업 악재

이러한 입법 정보는 뉴스보다 빠르고 확실한 시그널이지만, 비정형 텍스트 데이터라 정량화하기 어렵다는 장벽이 있었습니다. 저는 "LLM이라면 이 텍스트를 숫자로 바꿀 수 있지 않을까?"라는 가설을 세웠습니다.

시스템 아키텍처

데이터 파이프라인은 다음과 같이 구성했습니다.

1. 수집: 국회 의안정보시스템 API에서 일일 발의 법안 텍스트 수집
2. 분석 (LLM): GPT-4o에게 법안 내용을 요약하고, 관련 산업(26개 분류)과 영향도(-1.0 ~ +1.0)를 추출 요청
3. 가공: 추출된 데이터를 시계열 데이터로 변환 (Feature Engineering)
4. 예측 (ML): 기술적 지표 + 재무 데이터(DART) + 입법 영향도 → XGBoost로 5일 후 등락 예측

3. 개발 과정: 시행착오와 해결책

Phase 1. "PoC도 LLM으로 하라고요?"

처음 설계 시엔 데이터 수집부터 시작해서 파이프라인 구축, API서버 생성 등 AI 모델 개발 전에 해야 할 일들이 산더미처럼 느껴졌습니다. 이를 멘토님들에게 공유하니 의외의 답변이 돌아왔습니다.

"지금 개발하려는 아이디어를 LLM에게 요청하면 그대로 나올 것 같아요. LLM으로 PoC를 진행해보세요."

반신반의하며 Gemini에 입법 데이터 응답을 통째로 넣고 "이거 주가에 호재야?"라고 물었을 때, 제가 생각한 분석 결과가 그대로 나와서 충격을 받았습니다. 기술 발전 속도가 이 정도면 도대체 개발자가 뭘 해야 하나 하는 고민을 많이 한 것 같습니다. 프로젝트 개발보다는 미래에 대한 방향성과 개발자의 존재 의의, 핵심 가치에 대해 깊게 고민한 시간이었습니다.

하지만 덕분에 깨달은 것도 있었습니다.

"완벽한 설계보다 빠른 실험".

전통적인 PoC보다 훨씬 더 빠르고 정확하게 가설을 검증할 수 있었고, 내가 무엇을 해야 하는지, 상상한 결과물의 현실에서의 느낌이 어떤지 즉각적인 피드백을 받을 수 있었습니다.

Phase 2. "LLM을 신뢰할 수 있는가? (Hallucination 제어)"

PoC는 성공적이었지만, 시스템화는 다른 문제였습니다. GPT-4o에게 "이 법안이 어떤 산업에 영향을 미치는가?"를 물으면, 같은 질문에도 매번 다른 답이 나왔습니다.

문제점:

1. 비일관성: 실행할 때마다 산업 분류를 제멋대로 창조함 (예: '반도체' -> 'IT하드웨어' -> '전자부품')
2. 파싱 불가: 줄글로 된 분석 결과는 DB에 넣을 수 없음

해결책: JSON Mode & 프롬프트 구조화
LLM을 '생성기'가 아닌 '분석기'로 쓰기 위해 엄격한 제약을 걸었습니다.

# OpenAI API 호출 예시 (의사 코드)
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "너는 금융 분석가다. 출력은 반드시 지정된 JSON 형식을 따라야 한다."},
        {"role": "user", "content": f"다음 법안을 분석하라: {bill_text}"}
    ],
    response_format={"type": "json_object"}, # 핵심: JSON 모드 강제
    temperature=0.0 # 창의성 제거, 일관성 극대화
)

개선된 프롬프트 전략:

• Constraint: 26개 한국 표준 산업 분류 리스트를 프롬프트에 하드코딩하여 제공.
• Output Format: sentiment_score, related_sectors, reason 키를 가진 JSON 강제.
• Retry Logic: JSON 파싱 실패 시 자동 재시도 로직 구현.

이 조치들로 데이터의 일관성을 확보할 수 있었습니다.

Phase 3. "쓰레기를 넣으면 쓰레기가 나온다 (GIGO)"

LLM 파이프라인이 안정화된 후, 초기 모델의 예측 정확도는 처참한 36%였습니다. 동전 던지기(50%)보다 못한 결과였습니다. 그냥 찍어도 반은 갈 텐데 터무니없는 수치가 나와서 뭔가 잘못되었음을 직감했습니다.

원인은 '데이터의 편향'과 '기본의 부재'였습니다.
요즘 코딩은 흔히 말하는 '바이브 코딩'으로 AI에게 맡기고, 사람이 검증하고 문제없으면 반영하는 식으로 돌아갑니다. 저 또한 AI로 코딩한 머신러닝 모델들을 제대로 검수하지 않는 실수를 범했습니다. 입법 데이터 반영이 전혀 안 되어 있었습니다.

또한 도메인 지식의 부재도 컸습니다. 주가는 법안만으로 움직이지 않습니다. 기업의 펀더멘탈(재무제표) 없이 뉴스(법안)만 보고 투자하는 꼴이었습니다.

DART(전자공시시스템)에서 매출액, 영업이익 등 재무 데이터를 추가하고, 기술적 지표(RSI, MACD)를 결합하자 비로소 정확도가 오르기 시작했습니다. AI는 거들 뿐, 핵심은 여전히 데이터 품질에 있었습니다.

4. 최종 성과 및 회고

기술적 성과

• Directional Accuracy ~55%: 랜덤 워크(50%)를 상회하는 유의미한 신호 포착.
• 자동화 파이프라인: 매일 새로운 법안이 발의되면 자동으로 분석하여 DB에 적재되는 시스템 구축.
• 개발자용 대시보드: 모델 버전별 성능과 추천 종목을 시각화하여 모니터링.

얻은 인사이트 (Retrospective)

1. LLM 활용: "프롬프트보다 컨텍스트 설계가 중요하다"
   처음에는 프롬프트 문구를 다듬는 데 시간을 썼습니다. 하지만 진짜 중요한 건 LLM에게 무엇을 주느냐(입력 데이터)와 무엇을 받느냐(출력 형식)의 설계였습니다. JSON 모드, 산업 분류 목록 제공, 검증 로직 추가가 프롬프트 단어 선택보다 훨씬 큰 차이를 만들었습니다.
2. ML/MLOps: "모델 성능의 80%는 데이터와 피처에서 결정된다"
   XGBoost 하이퍼파라미터 튜닝보다 피처 엔지니어링(입법 영향 시차 변수, 이동평균 등)이 성능에 더 큰 영향을 미쳤습니다. 또한 충분하지 않은 데이터와 불완전한 가설로 프로젝트를 수행하면 원하는 결과가 나오지 않는다는 것을 뼈저리게 느꼈습니다.
3. 혼자 프로젝트를 끝까지 끌고 가는 힘
   개인프로젝트는 전체 교육기간중 60%정도의 기간이 할당되어 있었습니다.
   처음엔 주제선정에도 고민을 많이했습다. 어떤 주제로 프로젝트를 진행해야 임팩트가 있을까? AI를 제일 활용할 수 있는 주제가 뭘까? 데이터는 어떻게 수집하지?
   그런 고민에 많은 시간을 소모하였는데 마감시간이 다가오면서 더이상 고민할 여유가 사라져 빠르게 진행할 수 있었습니다. 저는 마감일이 얼마 안남아야 집중할 수 있는 타입인 것 같습니다.

아쉬움과 한계

• 실거래 미적용: 시스템은 로컬에서 돌아가고 모의투자(백테스트)로 테스트했지만, 실제 돈을 넣고 운영하는 단계까지는 가지 못했습니다. 솔직히 수치로 55%라고 해도 실제 돈을 넣고 자동투자를 맡겨보기엔 아직 크게 미덥지 않았습니다.
• 단순한 수치화: 법안의 내용을 -1.0 ~ 1.0 점수로만 환산하다 보니 디테일한 뉘앙스가 소실되었습니다.
• 시간 관리: 트레이딩 시스템 개발에 예상보다 훨씬 많은 시간이 들었습니다. Airflow를 활용해 ETL 파이프라인을 구축하고 MLFlow까지 적용하려고 했는데, 단순 구현으로 마무리되어 아쉬웠습니다.

5. 마치며: AI 시대의 엔지니어링

3개월 전 이너서클을 신청할 때는 단순한 'AI 사용자'였던 것 같습니다.
"AI를 좀 더 잘 써보자"라는 막연한 생각으로 시작했는데, 예상보다 훨씬 많은 것을 얻었습니다.

현업 멘토님들의 피드백, 그리고 PM과 함께 프로젝트를 수행하며 비즈니스를 바라보는 시각도 넓어졌습니다. 이전에는 '고객'과 '제품' 중심의 사고방식이었다면, 이제는 '시장', '사업 가치', '근거 데이터'까지 시야가 확장된 느낌입니다.

앞으로 개발자들은 더이상 회사에서 일을 하는게 아닌, 1인 기업으로서 개발 외에 전략, 기획, 영업, 마케팅 등의 업무도 수행할 수 있어야 한다고 생각하는데, 이번 경험이 큰 밑거름이 될 것 같습니다.

Next Step

• 개인 프로젝트는 이너서클 외에 별도로 진행 중인 AI 스터디 주제인 '실시간 주식 트레이딩'으로 확장할 계획입니다.
• UI를 조금 더 다듬어 배포하고, 관심이 생길 때마다 조금씩 업데이트해 볼 생각입니다.

2025년 회고: AI와 함께한 격변의 한 해

들어가며

2025년이 끝난지 3주가 되어간다. 돌이켜보면 IT업계에는 AI라는 큰 변화가 있었던 해이자, 개발자로서 세상을 바라보는 시각이 완전히 달라진 해였다. 창업의 마무리, 새로운 회사로의 합류, 그리고 AI라는 거대한 파도 속에서 개발자로서의 정체성을 다시 정립한 한 해를 다시 돌아보았다.

1. 새로운 시작: 창업 이후, 다시 직장인으로

잠시 멈춤, 그리고 재충전

2024년 창업을 마무리한 뒤, 2025년 초반은 의도적으로 여유롭게 보냈다. 약 3개월간의 백수 생활. 그동안 밀렸던 게임도 하고, 평소 읽고 싶었던 기술 서적도 읽으며 재충전의 시간을 가졌다. 창업이라는 롤러코스터에서 내린 뒤 필요한 회복 시간이었다.

예상치 못한 제안

그렇게 느긋하게 지내던 중, 이전 창업 때 함께했던 개발자분에게서 연락이 왔다. 개발자 겸 인프라 엔지니어를 구하는데 면접 볼 생각이 있냐는 제안이었다.

사실 이 제안은 내가 오랫동안 고민하던 부분과 밀접한 연관이 있었다. 2024년 창업 당시 혼자서 AWS와 Kubernetes로 서비스 인프라를 구축하고 운영했었다. 서비스 운영에는 문제가 없었지만, 개발과 병행하다 보니 인프라 영역에서 깊이 있는 학습이 부족하다는 느낌을 지울 수 없었다. 현업에서 전문가들과 함께 실무를 경험하며 실력을 쌓고 싶다는 갈증이 있었다.

하지만 현실적인 고민도 있었다. 개발 업무를 완전히 놓기는 아쉽고, 그렇다고 인프라 엔지니어 경력 신입으로 전환하자니 기존 커리어를 너무 많이 포기해야 했다. 이도 저도 아닌 애매한 상황이라 생각했는데, 개발자로 일하면서 DevOps에 가까운 인프라 업무도 함께 할 수 있다는 이야기에 바로 면접을 보았다. 몇 가지 조건을 조율한 뒤 합류를 결정했다.

다시 금융 도메인으로

새로 합류한 회사는 QR결제 핀테크 회사였다. 첫 회사에서 금융권 SI/SM 업무를 하다가 스타트업 업계로 넘어왔었는데, 다시 금융 도메인을 맡게 될 줄은 몰랐다. 커리어라는 게 참 신기하다. 다른 길로 가려 해도 결국 자신의 경험과 도메인 지식이 이끄는 방향으로 흘러가게 되는 것 같다.

2. AI 시대의 개발자: 패러다임의 전환

AWS Summit에서 만난 Agent AI

출근을 다시 시작하면서 세웠던 계획이 있었다. AWS 자격증을 따서 이른바 '황금 잠바'를 얻자는 것이었다. 평소 실무는 이론이 뒷받침되어야 튼튼하게 쌓인다는 생각으로, 꾸준히 공부해서 자격증을 하나씩 취득하면 전문성도 쌓이고 커리어에도 도움이 될 거라 생각했다.

그런데 2025년 AWS Summit Seoul에 참가하면서 생각이 완전히 바뀌었다. 행사 전반에 걸쳐 Agent AI에 대한 쥊가 메인이었다. 이전에 사용하던 GPT같은 단순한 챗봇 수준이 아니라, 실제로 코드를 작성하고 문제를 해결하는 AI의 데모를 보면서 바로 써봐야겠다는 생각이 들었다.

패러다임의 변화

직접 Agent AI를 사용하고, 실무에서도 활용하면서 AI의 발전을 체감한 이후로는 이제는 계단식으로 학습에 시간을 투자하는 것이 과거의 방식처럼 느껴지기 시작했다. 물론 기초 지식은 여전히 중요하다. 하지만 AI가 세부코딩을 의도만 전달하면 구현하는 시대에서 특정 서비스의 세부 옵션을 외우고, 익숙해지는데 수십,수백 시간을 쓰는 것이 과연 의미가 있을까?

AI가 빠르게 발전하면서 개발자에게 요구되는 역량의 무게 중심이 이동하고 있다. 예전에는 "코드를 얼마나 잘 짜느냐"가 핵심이었다면, 이제는 "AI를 얼마나 잘 활용하느냐", "사람들과 얼마나 잘 소통하느냐", "시스템을 얼마나 잘 설계하느냐"가 더 중요해졌다.

이전에는 시니어 엔지니어로 성장하면서 천천히 갖추면 되는 역량이었다. 주니어 때는 코딩 실력을 키우고, 경력이 쌓이면서 점차 설계와 커뮤니케이션 능력을 발전시키는 순서였다. 그런데 AI가 코딩 영역을 빠르게 대체하면서, 이 순서가 압축되고 있다. 주니어 개발자도 이제 설계 능력과 소통 능력을 일찍부터 갖춰야 하는 시대가 된 것이다.

AI와 함께 일하는 법

처음에는 AI 도구들이 어색했다. GitHub Copilot으로 시작해서 ChatGPT, Claude까지. 처음에는 간단한 코드 자동완성 정도로만 사용했다. 하지만 점점 사용법을 익히면서 업무 방식 자체가 바뀌기 시작했다.

이전에는 새로운 기술 스택을 배울 때 공식 문서를 정독하고, 튜토리얼을 따라 하고, 삽질을 반복하며 익혔다. 지금은 AI에게 먼저 물어본다. 전체적인 구조를 파악하고, 핵심 개념을 이해한 뒤, 구체적인 구현은 AI와 페어 프로그래밍하듯 진행한다. 생산성이 이전과는 비교할 수 없을 정도로 높아졌다.

체감상 AI는 실무에 필요한 능력의 890%까지 대체할 수 있는 것 같다. 제로베이스여도, AI를 활용하면 주니어미들급의 역량으로 성과물을 만들 수 있는 것처럼 느껴진다. 하지만 나머지 10~20%는 아직 AI가 채울 수 없는 것처럼 느껴지고, 이를 완성하려면 결국 기본기가 탄탄해야 한다. 틀린 코드를 알아볼 수 있어야 하고, 더 나은 방향으로 가이드할 수 있어야 한다. 요즘 주니어를 뽑지 않고 시니어만 찾는 이유가 다들 비슷하게 생각해서 그런게 아닐까?

3. 2025년의 성과들

카드추천 AI 개발

회사에서 맡은 첫 번째 큰 프로젝트는 정부과제인 카드추천 AI를 개발하는 것이었다.
이전 코로나시대에 취업이 늦어져 데이터역량을 쌓고자 통계전공+빅데이터 분석 기사 자격증을 취득한 것이 큰 도움이 되었다. PoC수준의 ML기반 프로젝트로 시작하여 프로젝트를 리딩하다가 중간에 사정으로 인하여 프로젝트가 중지되긴 하였지만, AI와 함께라면 데이터쪽 업무도 충분히 수행할 수 있다는 역량과 가능성을 확인하였다.

선불시스템 개발과 라이센스 취득

두번째 프로젝트는 선불시스템 개발이었다. 핀테크 회사에서 선불 전자지급수단을 다루려면 금융당국의 라이센스가 필요하다. 시스템을 설계하고 개발하면서 금융 규제와 보안 요구사항을 충족시켜야 했다. 쉽지 않은 과정이었지만, 결국 라이센스 취득에 성공했다. 인프라 업무도 병행하면서 PCI-DSS 라이센스도 함께 진행하였는데 이전에 기능개발과 프로젝트 구현에만 머물러있던 시선이 현실세계의 제약과 요구사항까지 넓어진 느낌을 받았다.

React Native로 모바일 앱 개발

주 언어가 아닌 React Native로 모바일 앱을 개발한 것도 올해의 도전이었다. 모바일 포스(POS) 시스템을 만들어야 했는데, 네이티브 개발 경험이 없는 상황에서 React Native를 선택했다. 웹 개발 경험이 있으니 진입 장벽이 낮을 거라 판단했고, AI의 도움을 받으며 빠르게 구현할 수 있었다.

솔직히 AI 없이 이 속도로 새로운 기술 스택을 익히고 프로덕션 레벨의 앱을 만들 수 있었을까? 아마 두세 배는 더 걸렸을 것이다. AI 시대의 개발자는 "모르는 기술"에 대한 두려움이 줄어드는 것 같다. CS 지식을 기반으로 AI와 함께 빠르게 구현할 수 있기 때문이다.

인프라 자동화: Kubernetes와 Ansible

인프라 엔지니어로서의 역할도 충실히 수행했다. 기존에 수동으로 관리되던 서버들을, Ansible로 프로비저닝을 자동화했다. 반복적인 작업을 코드로 만들어 놓으니 운영 부담이 크게 줄었다.

IaC(Infrastructure as Code)의 철학이 몸에 배는 한 해였다. 항상 반복되는 작업보다 재사용할 수 있는 코드, 스크립트들을 작성하고 이런 자산을 쌓아가는 것에 큰 만족감을 느꼈었는데, 이전에 취미로 공부하던 것을 실제 업무에서 사용하며 편리함을 체감하니 만족스러웠다.

HashiCorp Vault 전자책 출간

개인 프로젝트로 HashiCorp Vault에 관한 책을 집필했다. 사내에서 Vault를 사용하여 업무에 필요하여 공부하였는데, 한국어 자료가 부족하다고 느껴서 도전해볼만하다고 생각했다.

AI를 활용해 초안을 작성하고, 예제 코드를 만들고, 테스트 환경을 구축했다. 출판사와 미팅도 했는데, 비슷한 생각을 가진 사람들이 많았는지 출판 시장이 포화 상태라는 이야기를 들었다. 결국 정식 출판 대신 전자책으로 출간했다. 처음 책을 쓴다는 것 자체가 의미 있는 경험이었다.

공개SW 개발자대회 참가

회사 동료들과 팀을 꾸려 공개SW 개발자대회에도 참가했다. 대회를 준비하면서 이전에 함께 게임하던 게임친구들과 기획자와 개발자로서 다시 만나서 인연의 소중함을 한번 더 체감했다. 결과와 별개로, 같은 목표를 향해 달리는 경험 자체가 값졌다.

패스트캠퍼스 이너서클 AI

하반기에는 패스트캠퍼스에서 진행하는 이너서클 AI 과정에 참여했다. AI를 활용한 개인 프로젝트를 진행하면서 다양한 사람들과 교류할 수 있었다. 혼자 공부할 때와는 다른 자극을 받았고, AI 활용 능력을 한 단계 끌어올릴 수 있었다. 팀 프로젝트도 26년에 이어갈 예정이다.

마치며: 2026년을 향해

두서없이 쓴 것 같지만, 2025년은 정말 열심히 달려온 한 해였다. 새로운 회사에 적응하면서 개발도 하고 인프라도 배우고, 격변하는 시대에 뒤쳐지지 않게 빠르게 AI에 적응하고, 책도 쓰고, 대회도 나가고. 돌이켜보면 어떻게 이 많은 일을 했나 싶다.

2026년에도 지금처럼 업무에 집중하고, 주변 사람들과 함께 성장하며, 그 성과를 나누는 해가 되었으면 한다. AI 시대의 파도는 계속될 것이고, 그 파도를 두려워하기보다 즐기며 격변의 시대에 새로운 기회를 발견하고 붙잡는 개발자가 되고 싶다.

한 해 동안 함께해 준 모든 분들께 감사드린다. 2026년에도 잘 부탁드립니다.

1. 서론 - 도전의 배경

지난 7~9월에 2025년 공개SW개발자대회에 참가하였습니다. 연 초부터 LLM GPT 기반의 에이전트 AI가 화제가 되고 5월에 AWS 컨퍼런스를 통해서 소개받았던 아마존 Q와 바이브 코딩 등 새로운 AI 도구들을 많이 알게 되었습니다. 이를 활용해보고 싶은 생각을 계속 가지고 있던 와중에, 출퇴근 시 읽던 개발책에서 실력향상을 위해 개발자대회에 참가하는 것을 추천하여 찾아보니 공개SW개발자대회 일정이 마침 맞아서 참가를 결정하였습니다.

대회 일정은 6월 30일 접수 마감, 8월 21일 최종 마감으로 약 1달 반의 기간이 주어졌습니다. 기획부터 개발까지 한 달 안에 완성하는 것은 평소라면 불가능했겠지만, AI를 적극 활용하면 가능할 것 같아 도전하기로 결심했습니다.

팀내 역할, 구성과 목표

팀내 역할은 백엔드 개발자이자 팀장으로서 총 6인 팀을 구성했습니다. 기획 1명, 디자인 1명, 프론트엔드 2명, 백엔드 2명으로 팀을 빌딩했고, 프로젝트 기획과 일정관리, 기술 스택 결정을 담당했습니다. 1달의 짧은 기간 동안 AI를 최대한 활용하여 기능 구현을 완료하고 프로젝트를 완성시켜 입상하는 것을 목표로 설정했습니다.

2. 팀 빌딩과 기획 단계

팀원 모집

대회 참여를 결심한 뒤, 평소 업무와 매사에 열정적이던 분과 아이디어를 주고받아 기획자로 영입하고, 주변 개발자들에게 이야기하여 6명의 팀을 구성했습니다. 대부분이 직장인이었기 때문에 업무 외적으로도 커리어 확장을 위해 개인 시간을 투자할 수 있는 열정 있는 분들을 기준으로 팀을 빌딩했습니다.

아이디어와 피봇

최초 아이디어는 일상생활에서 발생하는 불편함을 민원을 통해 개선하는 시스템이었습니다. 하지만 필요한 데이터를 조사하면서 데이터 획득의 어려움을 발견했고, 피봇을 통해 서울시 공공데이터를 활용한 개인 맞춤형 지도 및 알림 시스템으로 방향을 전환했습니다.

기획 단계의 고민

기획 단계에서는 다음과 같은 점들을 중요하게 고려했습니다:

• 기술적으로 1달의 짧은 시간 동안 구현 가능할 것
• 너무 간단하지 않은 도전적인 과제일 것
• 사회적 가치로서 보편적으로 많은 사람들에게 유용할 것

도중에 피봇으로 인해 약 50일의 개발기간 중 20일 가까이를 기획에 소비하게 되었습니다. 되돌아보면 아쉬운 부분이지만, 올바른 방향을 찾기 위한 필수적인 과정이었다고 생각합니다.

협업 방식

이전 창업 경험을 바탕으로 다음과 같은 협업 도구들을 활용했습니다:

• GitHub: 코드 관리 및 버전 관리
• Notion: 칸반 시스템으로 프로젝트 관리
• Discord: 팀 커뮤니케이션
  특별한 경우를 제외하곤 온라인미팅을 기본으로 하기로 했기때문에 협업 방식을 결정하고 업무와 진행사항을 공유하는 것에 신경을 많이 썼습니다.

3. 개발 과정 - 기술적 시도와 시행착오

개발 진행 방식

팀별로 주 단위 목표를 설정하고 애자일, 스프린트 방식으로 개발을 진행했습니다. 매주 진행 상황과 이슈 내용을 공유하며 투명한 협업을 유지하려 노력했습니다.

주요 기술적 도전

백엔드에서는 트리거 기반 맞춤형 알림 시스템 구현이 주된 도전 과제였습니다. 짧은 기간이기 때문에 오버 엔지니어링을 지양하기 위해 MSA 등으로 구현하지 않고 단일 프로젝트에서 모듈로서 분리하는 방식을 선택했습니다.

초기에는 복잡한 아키텍처를 고려했지만, 주어진 시간과 리소스를 고려하여 실용적인 접근을 택했습니다. 이는 프로젝트 완성도 측면에서는 옳은 결정이었지만, 대회 심사 기준에서는 아쉬운 부분이 되었습니다.

4. 결과와 탈락 이후의 분석

1차 탈락과 원인 분석

1차 탈락 후, YouTube에 올라온 다른 팀들의 작품을 살펴보았습니다. 2~3년 전부터 준비한 프로젝트들도 있었고, 기업 팀으로 참가한 팀들도 있었습니다. 수상작을 분석한 결과, 이전 수상작들도 이미 3~4년 운영되고 활성화된 오픈소스 프로젝트인 경우가 많았습니다.

스스로 느낀 부족한 부분

완성도 부족: 짧은 준비 기간으로 기능 구현은 했지만 전체적인 완성도가 부족했습니다.

기술적 깊이: 실용적인 접근을 선택한 결과, 기술적 깊이가 부족했던 것 같습니다.

오픈소스 관점: 기술 구현에만 집중하다 보니 오픈소스다운 문서화와 접근성이 부족했습니다.

일정 관리: 일정이 촉박하다 보니 AI를 활용해서 개발 속도는 매우 빨라졌지만, AI를 사용하는 사람은 지치고 휴식이 필요하다는 점을 간과했습니다.

5. 팀장으로서의 배움과 성찰

스터디나 사이드 프로젝트로 팀을 구성할 때마다 느끼지만, 팀원들의 참여를 독려하는 것과 동기부여 유지, 스케줄 관리가 가장 어려운 것 같습니다.

리더로서의 도전

각 팀원들에게 적절한 업무를 찾아 분배해야 하고, 의견 충돌이 있을 시 중재와 적절한 합의점을 제시해야 합니다. 합의점이 팀원을 설득하지 못한 경우 참여율 저하로 이어지고, 이는 프로젝트 성공에 직접적인 영향을 미치는 것을 경험했습니다.

중요한 깨달음

예전에는 기능 구현이 가장 중요해 보였고, 기능 구현이 해결된 뒤에는 아이디어가 더 중요하다고 생각했습니다. 하지만 이번 경험을 통해 아이디어만큼이나 한정된 자원 안에서 최고의 성과를 내기 위해 동기부여와 목표의식 공유가 중요하다는 것을 배웠습니다.

팀이 작을 때는 업무를 대신하여 일을 마무리할 수 있지만, 팀이 커지고 일이 많아지면 땜빵식 업무 처리로는 한계가 있을 것이라 느껴 리더십에 대한 필요성을 크게 느꼈습니다.

6. 다음 도전을 위한 다짐

이번에는 짧은 기간 동안 AI를 활용하여 어느 정도 성과를 낼 수 있는지 시험하기 위한 프로젝트로 실험적 성격이 강했습니다.

앞으로의 계획

다음에는 충분한 기간을 확보하여 성과를 내고 싶습니다. 구체적으로는:

• 오픈소스로서 커뮤니티에 기여할 수 있는 과제 탐색
• 더 도전적인 기술 과제 설정
• 프로젝트의 오픈소스화를 통한 커뮤니티 피드백 수용
• 장기적인 관점에서의 프로젝트 운영

7. 마무리

약 한 달 반 동안의 프로젝트를 통해 많은 성장이 있었습니다.

AI 도구 활용 경험

짧은 기간 동안 성과를 내기 위해 다음과 같은 AI 도구들을 적극 활용했습니다:

• Claude Code Max (200달러 투자)
• 바이브 코딩 (여러 세션으로 활성화하여 프론트/백엔드 동시 작업)
• AI 기반 영상 제작

팀원들에 대한 감사

직장과 병행하여 개인 시간을 할애하여 프로젝트 완성까지 고생하신 팀원들에게 감사를 드립니다.

개발자로서의 성장

대회 참여를 통해 기능 개발과 비즈니스 모델 고려뿐만 아니라 팀원들의 목표의식과 열정까지 고려할 수 있게 되었습니다.
또한 빠듯한 일정 안에서 결과를 내기위해서 바이브코딩과 에이전트 AI를 활용하는 방법들을 숙련할 수 있어 AI숙련도가 크게 늘었습니다.
결과는 탈락이었지만, '좋은 팀'이란 무엇인가를 배운 가장 값진 시간이었습니다.

탈락의 아쉬움보다 배움의 가치를 더 크게 얻었고, 이 경험은 앞으로의 도전에서 더 나은 결과를 만드는 밑거름이 될 것입니다.

https://youtu.be/ygblqzjCevs

Design Docs: 소프트웨어 개발의 필수 설계 문서

 " "First, solve the problem. Then, write the code." — John Johnson

들어가며

개발자들은 주로 코드를 작성하며 비즈니스 가치를 만들어내고, 현실 세계의 문제를 해결하며 일을 합니다.

문제를 해결하기 위해선 문제인식을 공유해야 하고 이때 작게는 바로 옆의 팀원이나 팀장님, 크게는 조직이나 회사 차원의 설득이 필요할 때가 있습니다.
내가 해결해야 한다고 생각했던 문제가 다른 사람은 동의하지 않을 때가 생각보다 자주 있으며 그럴때는 근거에 기반한 합리적인 설득 과정이 필요하게 됩니다. 이러한 문제를 해결하기 위해 Google, Amazon, Uber 등 세계적인 기술 기업들이 공통적으로 사용하고 있는 도구가 바로 Design Docs(설계 문서)입니다.

Design Docs는 단순한 기술 문서가 아닙니다. 이는 프로젝트의 성공과 실패를 가르는 핵심 도구이며, 개발팀의 규모가 커질수록 그 중요성은 더욱 증대됩니다.

Design Docs란 무엇인가?

정의와 핵심 개념

Design Docs(또는 Technical Spec, RFC)는 코드를 작성하기 전에 작성하는 경량화된 계획 문서입니다. 이 문서는 특정 문제를 어떻게 해결할 것인지를 기술하며, 팀의 피드백을 수집하고 합의를 도출하며 향후 참고할 수 있는 문서화를 제공합니다.

핵심 특징

- 비공식적이지만 구조화된 문서: 엄격한 형식보다는 문제 해결에 초점
- 협업 중심: 작성자 혼자만의 문서가 아닌 팀 전체의 지혜가 담긴 결과물
- 결정의 기록: 왜 이런 선택을 했는지에 대한 트레이드오프와 의사결정 과정을 문서화
- 미래를 위한 투자: 단기적 시간 투자로 장기적 개발 효율성 확보

역사적 배경과 진화

RFC의 기원 (1960년대)

Design Docs의 뿌리는 1960년대 IETF(Internet Engineering Task Force)에서 시작된 **RFC(Request For Comments)** 프로세스에서 찾을 수 있습니다. 초기 인터넷 개발자들은 복잡한 기술적 결정을 내리기 위해 공개적으로 아이디어를 제안하고 커뮤니티의 피드백을 받는 방식을 도입했습니다.

현대 기업으로의 전파

1990년대와 2000년대를 거치며 소프트웨어의 복잡성이 급격히 증가했습니다. 이에 따라 대형 기술 기업들은 각자의 방식으로 Design Docs 문화를 발전시켰습니다:

- Google: 2000년대 초부터 Design Docs 문화를 정착시켜 현재까지 핵심 개발 프로세스로 유지
- Amazon: Working Backwards 문서와 함께 기술 설계 검토 프로세스 도입
- Uber: 수십 명에서 수천 명으로 성장하면서 RFC 프로세스를 체계화하여 급속한 확장 지원

원격 근무 시대의 재조명

COVID-19 팬데믹 이후 원격 근무가 일반화되면서 Design Docs의 중요성이 더욱 부각되었습니다. 비동기 협업과 명확한 의사소통의 필요성이 증대되면서, 많은 기업들이 이 방법론을 적극적으로 도입하고 있습니다.

Design Docs의 핵심 구성 요소

1. 헤더 정보

```
제목: [RFC-001] 사용자 인증 시스템 마이크로서비스 전환
작성자: 김개발 (kihttp://m.dev@company.com)
검토자: 이아키텍트, 박시니어, 최리드
상태: Draft | Under Review | Approved | In Progress | Completed
최종 수정일: 2025-07-08
```

2. 개요 (Overview)

모든 팀원이 이해할 수 있는 고수준 요약입니다. 3문단 이내로 작성하며, 다음을 포함합니다:
- 해결하려는 문제
- 제안하는 솔루션의 핵심
- 예상되는 영향과 이익

3. 배경 (Background)

프로젝트가 필요한 이유와 현재 상황을 설명합니다:
- 비즈니스 요구사항
- 기술적 제약사항
- 기존 시스템의 한계점

4. 목표와 비목표 (Goals & Non-Goals)

명확한 범위 설정을 위해 무엇을 할 것인지, 무엇을 하지 않을 것인지를 구분합니다.
목표:
- 인증 서비스의 99.9% 가용성 확보
- 응답 시간 100ms 이하 달성
- 일일 100만 요청 처리 능력
비목표:
- 기존 사용자 데이터 마이그레이션 (별도 프로젝트)
- OAuth 2.0 외 다른 인증 방식 지원

5. 제안된 솔루션 (Proposed Solution)

기술적 세부사항을 포함한 구체적인 해결책을 제시합니다:
- 시스템 아키텍처 다이어그램
- API 설계
- 데이터베이스 스키마
- 보안 고려사항

6. 대안 고려사항 (Alternatives Considered)

왜 다른 방법이 아닌 이 방법을 선택했는지 설명합니다:
- 고려했던 다른 아키텍처
- 각 대안의 장단점 분석
- 비용-효과 분석

7. 구현 계획 (Implementation Plan)

프로젝트 실행을 위한 구체적인 로드맵입니다:
- 마일스톤별 작업 분할
- 타임라인과 담당자
- 위험 요소와 완화 방안

언제 Design Docs를 작성해야 할까?

작성이 필요한 경우

1. 1 엔지니어-월 이상의 프로젝트: 상당한 시간 투자가 필요한 모든 프로젝트
2. 크로스 팀 영향: 여러 팀이나 시스템에 영향을 미치는 변경사항
3. 아키텍처 변경: 기존 시스템의 구조적 변화가 필요한 경우
4. 새로운 기술 도입: 팀에서 처음 사용하는 기술이나 도구 적용 시
5. 외부 의존*: 서드파티 서비스나 라이브러리와의 복잡한 통합

실제 적용 예시

Git 전환 방안

상태: Under review, 날짜: 2025/07/13, 담당: 개발팀 다메카솔 (damecasol@damecasol.com)

Objective

현재 프로젝트의 소스 코드 관리 시스템(SCM)으로 사용 중인 SVN(Subversion)은 중앙 집중식 버전 관리 시스템으로, 최신 개발 환경의 요구사항을 충족하기에는 여러 한계가 있습니다. 특히 분산형 버전 관리 시스템(DVCS)인 Git에 비해 협업 효율성, 브랜치/머지(Branch/Merge)의 유연성, 오프라인 작업의 용이성, 그리고 개발자 생산성 측면에서 개선이 필요합니다. 따라서 본 문서에서는 이러한 문제점들을 해결하고 개발 프로세스의 효율성을 높이기 위해 Git으로의 전환을 제안합니다.

Proposal

1. Git 도입
Git은 현재 소프트웨어 개발 업계에서 가장 널리 사용되는 분산형 버전 관리 시스템입니다. 각 개발자가 독립적인 저장소 복사본을 가지므로, 네트워크 연결 없이도 작업이 가능하며, 빠르고 유연한 브랜치 및 머지 기능을 제공하여 병렬 개발 및 기능별 개발에 최적화되어 있습니다.
향상된 협업: 각 개발자가 로컬 저장소에서 독립적으로 작업하고, 필요한 시점에 중앙 저장소와 동기화함으로써 충돌을 최소화하고 협업 효율성을 높일 수 있습니다.
유연한 브랜치 전략: Git의 가볍고 빠른 브랜치 기능은 다양한 개발 워크플로우(예: Git Flow, GitHub Flow)를 적용할 수 있게 하여, 안정적인 릴리즈 관리와 신속한 기능 개발을 가능하게 합니다.
성능: SVN에 비해 커밋, 브랜치 생성, 머지 등의 작업 속도가 훨씬 빠릅니다.

2. GitHub 또는 GitLab 도입
Git 저장소를 호스팅하고 팀 협업 기능을 제공하는 플랫폼으로 GitHub 또는 GitLab을 도입하는 것을 제안합니다. 이 플랫폼들은 코드 리뷰, 이슈 트래킹, CI/CD 연동 등 개발 생명주기 전반을 지원하는 강력한 기능들을 제공합니다.
코드 리뷰: 풀 리퀘스트(Pull Request) 또는 머지 리퀘스트(Merge Request) 기능을 통해 효율적인 코드 리뷰 프로세스를 구축할 수 있습니다.
이슈 트래킹 및 프로젝트 관리: 내장된 이슈 관리 시스템을 활용하여 개발 진행 상황을 투명하게 관리하고, 프로젝트 계획을 효율적으로 수립할 수 있습니다.
CI/CD 연동: Jenkins, CircleCI, GitLab CI/CD 등 다양한 CI/CD 도구와 연동하여 자동화된 테스트 및 배포 파이프라인을 구축할 수 있습니다.

3. 전환 전략 (선택)
SVN에서 Git으로의 전환은 여러 가지 방식으로 진행될 수 있습니다. 현재 프로젝트의 규모와 이력을 고려하여 가장 적합한 방식을 선택해야 합니다.
히스토리 전체 마이그레이션: SVN의 모든 커밋 히스토리를 Git으로 가져오는 방식입니다. 히스토리 보존이 중요할 때 적합합니다. git svn clone 등의 도구를 사용할 수 있습니다.
새로운 Git 저장소 시작: 기존 SVN 히스토리는 보존하고, 특정 시점부터 새로운 Git 저장소에서 작업을 시작하는 방식입니다. 빠르고 간단하지만, 이전 히스토리는 SVN에서만 확인할 수 있습니다.

Check Points

개발자 교육: Git은 SVN과 사용 방식이 다르므로, 개발자들이 Git에 익숙해질 수 있도록 충분한 교육과 연습 시간이 필요합니다.
기존 CI/CD 파이프라인 변경: SVN 기반으로 구축된 기존 CI/CD 파이프라인이 있다면 Git 저장소와 연동되도록 수정해야 합니다.
대규모 저장소 히스토리 마이그레이션: 프로젝트의 SVN 히스토리가 매우 크다면, Git으로의 마이그레이션에 시간이 오래 걸리거나 추가적인 설정이 필요할 수 있습니다.

Limits

초기 학습 곡선: Git의 강력한 기능만큼이나 처음 접하는 사용자에게는 학습 곡선이 존재할 수 있습니다. 이는 교육을 통해 완화해야 합니다.
전환 기간 동안의 혼란: 전환 과정에서 일시적으로 개발자들의 혼란이나 생산성 저하가 발생할 수 있습니다. 이를 최소화하기 위한 명확한 전환 계획과 지원이 필요합니다.

Alternatives

Mercurial (Hg): Git과 유사한 분산형 버전 관리 시스템이지만, Git만큼 보편적으로 사용되지는 않습니다.
Perforce (Helix Core): 대규모 프로젝트와 바이너리 파일 관리에 강점이 있는 중앙 집중식 시스템이지만, 라이센스 비용이 발생할 수 있습니다.
기존 SVN 유지: 현재 시스템을 유지하는 방안도 있지만, 앞서 언급된 문제점들(협업 효율성, 유연성 등)은 해결되지 않을 것입니다.

Reference

Git 공식 홈페이지: https://git-scm.com/
GitHub: https://github.com/
GitLab: https://about.gitlab.com/

작성 시 주의사항

DO: 해야 할 것들
- 간결하고 명확한 언어 사용
- 시각적 다이어그램 적극 활용
- 트레이드오프와 의사결정 근거 명시
- 구체적인 예시와 시나리오 제공
- 정기적인 업데이트와 버전 관리

DON'T: 하지 말아야 할 것들
- 과도하게 세부적인 구현 코드 포함
- 불확실한 추측이나 가정에 의존
- 일방적인 결정 강요
- 완벽한 문서 작성에 과도한 시간 투자
- 작성 후 방치하여 실제와 다른 내용 유지

조직 차원의 도입 전략

점진적 도입 방법

1단계: 파일럿 프로젝트 (1-2개월)
- 소규모 팀에서 시범 적용
- 간단한 템플릿으로 시작
- 초기 저항 최소화에 집중

2단계: 프로세스 정립 (2-3개월)
- 파일럿 결과를 바탕으로 프로세스 개선
- 팀별 특성에 맞는 템플릿 커스터마이징
- 리뷰 프로세스와 승인 기준 수립

3단계: 전사 확산 (6개월+)
- 성공 사례 공유와 교육 프로그램 실시
- 도구와 인프라 개선
- 문화 정착을 위한 지속적 노력

마무리: Design Docs로 만드는 더 나은 개발 문화

Design Docs는 조직의 기술적 의사결정 능력을 향상시키고 개발팀의 협업 문화를 발전시키는 강력한 도구입니다.

성공적인 Design Docs 문화 정착의 핵심은 완벽한 문서를 만드는 것이 아니라, 문제를 함께 해결하고 지식을 공유하는 과정에 있습니다. 오늘부터 작은 프로젝트 하나에 Design Docs를 적용해보세요. 그 작은 시작이 여러분의 팀과 조직에 큰 변화를 가져올 것입니다.

📚 도메인 주도 개발 시작하기 - 최범균

📋 기본 정보

- 제목: 도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지
- 저자: 최범균
- 출판사: 한빛미디어
- 출판일: 2022년 3월 21일
- ISBN: 9791162245385
- 링크: 교보문고, 알라딘 , 예스24

⏱️ 독서 데이터

- 독서기간: 2025.06.20 - 2025.07.05
- 독서시간: 18H
- 평점: ⭐⭐⭐⭐⭐
- 한줄평: "DDD 입문자에게 최고의 가이드북, 이론과 실무의 완벽한 조화"

🎯 독서 목표

- 배경지식: Spring Boot, JPA 기반 웹 개발 경험, 계층형 아키텍처에 대한 이해
- 해결과제: 복잡한 비즈니스 로직을 계층형 아키텍처가 아닌 다른 방법으로 효과적으로 설계하고 구현하는 방법론 습득
- 활용계획: 현재 진행 중인 프로젝트에 DDD 패턴을 점진적으로 적용하여 프로젝트 리팩토링
- 기대효과: 도메인 중심의 설계를 통한 코드 품질 향상과 유지보수성 증대

💡 주요 인사이트

1. 도메인 모델 패턴의 핵심은 비즈니스 규칙을 코드로 구현하는 것
    - 단순한 데이터 저장소가 아닌 비즈니스 로직을 담는 객체로서의 도메인 모델
    - 엔티티와 밸류 타입의 명확한 구분을 통한 개념적 명확성 확보
    - 실제 적용 예시: 주문(Order) 엔티티에서 배송지 변경 가능 여부를 주문 상태에 따라 판단하는 로직을 도메인 모델 내부에 구현

2. 애그리거트를 통한 일관성 경계 설정
    - 연관된 엔티티와 밸류 객체들을 하나의 군으로 묶어 일관성을 관리
    - 애그리거트 루트를 통한 외부 접근 제어로 데이터 무결성 보장
    - 실제 적용 예시: 주문 애그리거트에서 주문항목(OrderLine) 추가/삭제를 주문(Order) 루트를 통해서만 가능하도록 설계

3. DIP(의존역전원칙)를 통한 인프라스트럭처 의존성 해결
    - 고수준 모듈이 저수준 모듈에 의존하지 않도록 하는 설계 원칙
    - 리포지터리 인터페이스를 도메인 영역에 정의하고 구현을 인프라 영역에 배치
    - 실제 적용 예시: OrderRepository 인터페이스를 도메인에 정의하고 JpaOrderRepository 구현체를 인프라 계층에 분리

📝 인상적인 구절

도메인에서 사용하는 용어를 코드에 반영하여, 코드만 읽어도 자연스럽게 이해하는 방향으로 가야한다.

업무에서 기획자와 개발자들이 서로 다른 용어를 사용하여 의사소통 비용이 증가하는 경험을 자주 하는데, 유비쿼터스 언어의 중요성을 강조하며, 개발자와 도메인 전문가 간의 소통 단절을 해결하는 DDD의 핵심 철학을 간결하게 표현하였습니다.

🔄 실무 적용 포인트

- 현재 업무에 적용할 수 있는 점: 기존 Service 계층에 흩어진 비즈니스 로직을 도메인 모델로 이동시켜 응집도 향상
- 앞으로 개선할 수 있는 영역: 애그리거트 단위로 트랜잭션 경계를 재설정하여 데이터 일관성 문제 해결
- 새롭게 시도해볼 아이디어: 도메인 이벤트를 활용한 마이크로서비스 간 느슨한 결합 구현

🏆 결론 및 추천

도메인 주도 개발은 저에겐 헥사고날 아키텍처나 클린 아키텍처와 유사하게 느껴졌었습니다.

요즘 관련 서적들을 쭈욱 읽어나가며 어떤 차이점이 있는지 조금씩 보이기 시작하지만, 모든 개발 서적의 근간이 되는 아이디어는 항상 유사한 것 같습니다.

"결합도를 낮추고, 응집도를 높이며 읽기 쉽고 유지보수 하기 쉬운 소프트웨어를 개발하여 적은 비용으로 비즈니스 가치를 만들어 내는 것"

이 책의 장점은 추상적인 개념 설명에 그치지 않고 Spring Boot와 JPA를 활용한 구체적인 구현 예제를 제공하여 개발자로서 코드를 읽으며 실제 상황에 어떻게 적용할 지 구체적인 예제를 확인할 수 있다는 점입니다. 또한 초보자가 놓치기 쉬운 함정들과 주의사항을 적절히 언급하여 시행착오를 줄여주었습니다.

DDD를 처음 접하는 개발자, 복잡한 도메인을 다루는 시니어 개발자, 그리고 아키텍처 설계에 관심 있는 모든 개발자에게 도움이 될 것 같습니다.

🔍 연관 도서

- [도메인 주도 설계 - 에릭 에반스]- DDD의 원류이자 바이블
- [도메인 주도 설계 핵심 - 반 버논] - DDD 핵심 개념의 간결한 정리
- [클린 아키텍처 - 로버트 C. 마틴] - 아키텍처 설계 원칙의 현대적 접근