본문 바로가기

전체 글104

[회고록] CRM 개발 인턴으로 보낸 4개월 인턴 하기 전엔 현업에서 개발을 어떻게 하는지 사실 거의 몰랐다. 학교에서 프로젝트를 계속 했으니까 그냥 그게 개발인 줄 알았다. AI도 쓰고 있었지만 지금 보면 정말 보조 도구 정도였다. 코덱스나 Claude Code 옆에 띄워놓고 "이거 해줘", "저거 해줘" 정도, Context7이나 file-system MCP도 붙여봤지만 결국 코드 만들고 구조 고민하는 건 내 몫이었다. 그래도 나름 AI를 잘 쓰는 사람이라고 생각했는데, 회사 들어가고 그 생각은 완전 착각이었다. 제일 놀란 건 팀 전체가 이미 AI 중심으로 개발하고 있다는 점이었다. 회사에서 AI 지원해주는 건 물론이고 로컬 LLM도 직접 운영했고, 채팅창에 질문하는 수준이 아니라 Agent.md, CLAUDE.md 만들어서 AI가 프로젝트를 .. 2026. 7. 12.
[Docker & Azure] Azure Functions 직접 배포를 Container Apps로 전환한 이유와 구현 요약Pyro API는 Azure Functions에 코드를 직접 배포하는 구조였다. 이를 Azure Functions 런타임을 포함한 Docker 이미지로 패키징하고, Azure Container Apps에서 실행하도록 전환했다. 이 글은 단순한 호스팅 변경이 아니라 런타임, 시크릿, 배포 산출물, 롤백 경계를 어떻게 다시 설계했는지에 초점을 맞춘다.1. 시작점: 코드 배포는 편했지만, 운영 단위가 불명확했다전환 전 Pyro API는 Node.js 기반 Azure Functions 애플리케이션이었다. 로그인과 토큰 갱신, 서비스 케이스 조회·생성, 첨부파일 처리, Dataverse 연동 등 HTTP API를 제공했고, 고객 알림을 위한 Service Bus 워커도 동일 프로젝트 안에 존재했다.배포는 단순.. 2026. 6. 24.
[Azure] Azure Service Bus Queue Trigger로 고객 알림 메일 발송하기 이 글에서는 고객 포털에서 문의가 접수되거나 담당자가 처리 내역을 등록했을 때, 고객에게 HTML 이메일을 안정적으로 전달하기 위해 설계한 비동기 알림 구조를 정리한다.실제 조직명, 고객사명, 리소스명, 도메인, 식별자, 환경 변수명은 모두 일반화했다.1. 왜 “문의 접수 API에서 바로 메일 보내기”로 시작하지 않았는가고객 포털에 문의 접수 기능을 만들면 자연스럽게 다음 요구가 따라온다.고객이 문의를 등록하면 “정상적으로 접수되었다”는 안내를 받고 싶다.담당자가 처리 내역을 등록하면 고객에게 새 업데이트가 있다는 사실을 알려주고 싶다.최종 처리 완료 시에도 고객이 포털을 직접 열어 보지 않아도 결과를 확인할 수 있으면 좋겠다.처음에는 단순하게 생각할 수 있다.문의 접수 요청→ 데이터 저장→ 이메일 발송.. 2026. 6. 22.
[Azure] 프론트엔드의 Dataverse 의존성 제거: 백엔드 API로 추상화하기 이 글은 특정 회사/고객사/운영 환경과 직접 연결될 수 있는 값들을 모두 블라인드 처리한 기술 정리 글입니다.실제 환경명, 테넌트 ID, 클라이언트 ID, 시크릿, 리소스 그룹명, Dataverse 테이블의 일부 내부명, 도메인, 저장소명 등은 공개하지 않습니다.들어가며이번 작업은 단순히 API 몇 개를 추가한 작업이 아니었다. 기존에는 프론트엔드가 Dataverse, Blob Storage, CRM 리치텍스트 이미지, 포털 첨부파일, 토큰 발급 흐름을 너무 직접적으로 알고 있었다.이전 포스트에서 이미지 개선 구조에서 잔존하는 문제점을 빨간 네모로 체크했다프론트는 고객 포털 UI를 담당해야 하는데, 실제로는 내부 시스템의 API 구조와 인증 방식까지 상당 부분 떠안고 있었다.그래서 이번 작업의 핵심 목표.. 2026. 6. 13.
[RPA] 184개의 액션을 41개로 줄이기: Power Automate 레거시 플로우 리팩토링 기록 1. 한 줄 요약이번 작업은 Power Automate로 구현되어 있던 SharePoint 폴더 생성 자동화 플로우를 리팩토링한 작업이다.기존 플로우는 특정 업무 유형마다 필요한 폴더를 하나씩 직접 만드는 방식이었다. 그래서 폴더 구조가 조금만 바뀌어도 플로우 내부 액션을 직접 수정해야 했고, 조건문도 길어졌고, 비슷한 액션이 계속 반복됐다.새 플로우는 이 구조를 바꿨다.폴더 구조를 플로우에 박아두는 대신, Dataverse의 산출물 마스터 데이터를 읽고, 그 데이터를 기준으로 레벨2/레벨3 폴더 트리를 만든 뒤, 반복문으로 SharePoint 폴더와 Dataverse 산출물 레코드를 생성하는 방식으로 바꿨다.정리하면 다음과 같다.구분레거시 방식신규 방식폴더 구조 관리 위치Power Automate 액션.. 2026. 6. 8.
[Azure] CRM 리치 텍스트 이미지 저장 구조 개선기: Dataverse에서 Azure Blob Storage로 들어가며이번 작업은 단순히 “이미지를 어디에 저장할 것인가”를 정하는 문제가 아니었다.처음에는 CRM에서 제공하는 기본 리치 텍스트 이미지 저장 방식을 활용하면 충분할 것이라고 생각했다. 실제로 CRM 화면에서 엔지니어가 리치 텍스트 에디터에 이미지를 첨부하면, 이미지는 CRM 안에서 정상적으로 저장되고 본문에서도 잘 표시됐다.프론트엔드에서도 비슷한 방식으로 구현하면 고객이 문의를 접수할 때 첨부한 이미지가 CRM에서도 그대로 보일 수 있을 것 같았다. 기능 관점에서는 꽤 자연스러운 접근이었다.하지만 구현을 진행하면서 중요한 문제가 보였다.이미지 파일이 Dataverse 쪽에 계속 쌓이는 구조였고, Dataverse의 파일/이미지 저장 용량은 무한하지 않았다. 문의 접수 기능은 운영이 시작되면 이미지가 .. 2026. 6. 7.
반응형

티스토리툴바