※ 이 글은 실제 RM 개발 과정과 작업 기록을 바탕으로 AI와 함께 정리한 글입니다. 내용은 제가 실제로 적용하고 있는 개발 방식과 경험을 기준으로 작성했습니다.

병원 검사실에서 일하면서 필요한 기능을 직접 만들어 쓰고 있는데, 제가 RM(Reagent Manager)을 만드는 과정을 간단히 정리해봅니다.

개발을 전문적으로 배운 건 아니고, 실제 업무에서 반복되는 불편을 하나씩 줄이다 보니 지금 형태까지 오게 됐습니다.

전체 흐름은 대략 이렇습니다.

1. 현장에서 불편한 부분 찾기

처음부터 큰 시스템을 만들려고 한 건 아니었습니다.

업무를 하다 보면

수기 입력 → 확인 → 다시 검색 → 엑셀 정리 → 출력

처럼 사람이 반복해서 처리해야 하는 일이 꽤 많습니다.

여기서

“이걸 꼭 사람이 매번 해야 하나?”

싶은 부분을 먼저 찾았습니다.

↓

2. 가장 단순한 기능부터 구현

처음에는 Flask + DB로 아주 작은 기능부터 시작했습니다.

예를 들면

• 시약 등록

• LOT 관리

• 재고 확인

• 사용 이력

• 검색

처럼 바로 업무에 사용할 수 있는 기능부터 만들었습니다.

처음부터 완벽하게 설계하기보다는
실제로 쓸 수 있는 최소 기능을 먼저 만드는 방식으로 진행했습니다.

↓

3. 실제 업무에 사용

직접 만든 프로그램을 실제 업무에서 사용해봅니다.

여기서 중요한 게 개발할 때 생각했던 것과
실제 사용하면서 불편한 부분이 상당히 다르다는 점입니다.

그래서

만들기 → 실제 사용 → 불편 발견 → 수정

과정을 계속 반복합니다.

↓

4. 반복되는 입력은 최대한 자동화

사용하면서 가장 많이 줄이려고 한 부분이 사람의 직접 입력입니다.

예를 들어

• 기존 DB 정보 자동 불러오기

• 기본값 자동 입력

• LOT 정보 연결

• 바코드/DataMatrix 활용

• 조건에 따른 자동 판정

• Pending 자동 생성

같은 식입니다.

가능하면 사람이 판단해야 하는 부분만 남기고
단순 입력이나 계산은 프로그램이 처리하게 합니다.

↓

5. 기능이 아니라 업무 흐름을 시스템화

처음에는 단순한 시약관리 프로그램이었지만
사용하다 보니 자연스럽게 기능이 확장됐습니다.

현재는 대략

시약 등록
→ LOT 관리
→ 검증 필요 여부 확인
→ 검증 수행
→ 자동 계산/판정
→ 결과 저장
→ 보고서 생성
→ 다음 검증 시점 관리

같은 흐름으로 발전하고 있습니다.

AMR, Parallel, Cut-off, Qualitative validation 같은 검사실 검증업무도 같은 구조 안에서 관리하는 방향으로 만들고 있습니다.

↓

6. 큰 작업은 코드보다 설계문서부터

기능이 복잡해진 뒤부터는
바로 AI에게 코드를 작성시키기보다 먼저 설계문서를 작성하는 방식으로 바꿨습니다.

설계문서에는 보통

• 이 기능을 왜 만드는지

• 현재 구조는 어떤지

• 무엇을 변경할지

• 무엇은 변경하지 않을지

• DB 구조

• 상태값과 처리 흐름

• 예외 상황

• 완료 조건

• 테스트해야 할 항목

같은 내용을 먼저 정리합니다.

AI에게 초안을 만들게 하더라도
설계문서는 제가 먼저 검토하고 방향을 확정한 뒤에 코딩을 시작합니다.

이렇게 해두면 작업 도중 AI가 다른 방향으로 가더라도

“처음 설계와 다른데?”

라고 비교할 기준이 생깁니다.

저한테는 이게 꽤 중요한 안전장치였습니다.

↓

7. 설계문서를 기준으로 작업을 작게 쪼개기

설계가 확정되면 한 번에 전체 기능을 만들게 하지 않습니다.

예를 들면

DB 변경
→ 백엔드 로직
→ 계산 엔진
→ UI
→ 테스트
→ 보고서

처럼 작업을 단계별로 나눕니다.

AI에게

“Validation 기능 전체를 완성해줘”

라고 하는 것보다

“설계문서의 3번 항목만 구현하고 다른 부분은 건드리지 마”

라고 하는 편이 훨씬 안정적이었습니다.

↓

8. AI는 개발자가 아니라 보조자로 사용

AI는 주로

• 코드 초안

• 기존 코드 분석

• SQL 개선

• 오류 원인 분석

• UI 개선 아이디어

• 문서화

• 테스트 항목 정리

등에 활용합니다.

다만 여기서 중요한 건
AI에게 너무 넓은 권한을 주지 않는 것이라고 느꼈습니다.

AI는 똑똑하지만 지시가 애매하면
제가 원하지 않은 범위까지 수정하려고 할 때가 있습니다.

그래서 작업 지시에는

이 파일만 수정
DB 스키마 변경 금지
기존 동작 유지
새 라이브러리 추가 금지
커밋·Push 금지
요청한 기능 외 리팩터링 금지

처럼 해야 할 것뿐 아니라 하지 말아야 할 것도 같이 적습니다.

특히 운영 중인 시스템에서는
AI가 좋은 의도로 주변 코드까지 정리하는 것이 오히려 문제가 될 수 있습니다.

그래서 가능하면

설계 확인
→ 작은 단위 구현
→ diff 확인
→ 테스트
→ 다음 단계

순서로 진행합니다.

↓

9. 중요한 결정은 사람이 직접

AI가 구조나 방법을 제안해도

• 실제 업무에 맞는지

• 기존 데이터와 충돌하지 않는지

• 인증이나 규정상 문제가 없는지

• 운영 중 장애가 발생하지 않을지

같은 부분은 사람이 최종 판단해야 합니다.

특히 검사실 업무용 시스템을 만들고 있어서
“AI가 이렇게 하라고 했다”는 이유만으로 반영하지는 않습니다.

AI는 설계 후보를 만들고 구현 속도를 높여주는 도구이고,
최종 설계와 승인 책임은 결국 사람에게 있다고 생각합니다.

↓

10. 실제 사용하면서 계속 개선

현재도 완성된 프로그램이라기보다는 계속 발전시키는 중입니다.

제가 중요하게 보는 기준은 단순합니다.

사람이 반복해서 입력하는 것을 줄이고
 실수할 수 있는 지점을 시스템이 막아주는 것.

처음부터 거대한 프로그램을 만들려고 하면 어려운데,

불편 발견
→ 설계
→ 작게 구현
→ 직접 사용
→ 문제 확인
→ 다시 개선

이 과정을 반복하다 보면 생각보다 꽤 큰 시스템까지 만들 수 있었습니다.

AI를 쓰면서 가장 크게 느낀 건

“좋은 프롬프트 한 번보다, 좋은 설계문서와 명확한 작업 범위가 더 중요하다”

는 점입니다.

결국

무엇을 만들지 결정하는 것,
 AI가 어디까지 작업할지 정하는 것,
 결과를 최종 판단하는 것

이 세 가지는 여전히 사람이 해야 한다고 생각합니다.

추가 팁 — 작업에 따라 추론 강도도 조절

AI는 항상 가장 높은 추론 강도로 쓰는 게 좋은 건 아니었습니다.

단순한 작업은 오히려 너무 깊게 생각하게 하면
요청하지 않은 구조 개선이나 주변 코드 수정까지 제안하는 경우가 있었습니다.

그래서 저는 작업 성격에 따라 나눠서 사용합니다.

단순 수정 / 문구 변경 / 작은 버그 수정
→ 낮거나 중간 정도의 추론

원인 분석 / 성능 문제 / DB 구조 검토
→ 중간~높은 추론

아키텍처 설계 / 복잡한 검증 로직 / 여러 파일이 얽힌 문제
→ 높은 추론

다만 추론 강도가 높아질수록
AI가 스스로 빈칸을 채우고 작업 범위를 넓게 해석할 가능성도 커질 수 있어서,

추론 강도를 높일수록 작업 범위와 금지사항은 더 명확하게 적는 편이 좋았습니다.

예를 들면

현재 변경분만 확인
추가 리팩터링 금지
DB 변경 금지
커밋만 수행
다른 파일 수정 금지

처럼 범위를 명확하게 줍니다.

결국 중요한 건

“가장 강한 모델을 쓰는 것”이 아니라
 “작업 난이도에 맞는 추론 강도와 범위를 같이 설정하는 것”

이라고 느꼈습니다.

추가 팁 — 구현 전에 대화로 아이디어를 충분히 풀어봄

기능을 만들기 전에 바로 코딩부터 시키기보다
AI와 대화를 하면서 아이디어를 먼저 정리하는 편입니다.

처음에는 그냥

“이런 불편이 있는데 어떻게 줄일 수 있을까?”

정도의 가벼운 이야기로 시작합니다.

그러다 보면

문제 설명
→ 가능한 방법 여러 개 제안
→ 실제 업무에 안 맞는 방법 제외
→ 예외 상황 발견
→ 필요한 기능 정리

처럼 자연스럽게 요구사항이 구체화됩니다.

이 단계에서는 정답을 바로 얻으려 하기보다
생각하지 못했던 선택지나 예외를 찾아내는 브레인스토밍 도구로 AI를 사용합니다.

그리고 대화에서 나온 내용을 정리해서

아이디어
→ 요구사항
→ 설계문서
→ 작업 단위
→ 구현

순서로 넘깁니다.

저는 이 과정을 거치면 바로 코딩을 시작했을 때보다
중간에 설계를 다시 뒤집는 일이 줄어드는 편이었습니다.

다만 브레인스토밍 단계의 AI 답변은 어디까지나 아이디어 후보라서
실제 업무에 맞는지 판단하고 최종 방향을 정하는 것은 사람이 합니다.