손기석 Backend Engineer

How I Engineer

이 문서는 제가 어떤 언어나 프레임워크를 쓰는지보다 백엔드 문제를 어떻게 구조화하고 구현한 뒤 실제 동작까지 검증하는지를 설명합니다.

1. 먼저 문제와 제약을 정리합니다

바로 코드를 작성하기보다 다음을 먼저 확인합니다.

  • 누가 이 기능을 사용하는가
  • 실제로 해결해야 하는 문제는 무엇인가
  • 바꿀 수 있는 것과 바꿀 수 없는 것은 무엇인가
  • 어떤 경우를 성공으로 볼 것인가
  • 어떤 실패를 반드시 막아야 하는가

쉽게 말하면 요청을 그대로 구현하는 것이 아니라 무엇을 만들면 일이 실제로 해결되는지부터 정리합니다.

기술적으로는 system boundary, acceptance criteria, state, transaction, trust boundary를 정의하는 과정입니다.

2. AI가 할 일과 서버 또는 사람이 책임질 일을 나눕니다

특히 AI 기능을 붙일 때는 AI에게 모든 결정을 맡기지 않습니다.

AI
-> 초안 생성, 요약, 후보 제안

서버
-> 권한 확인, 데이터 검증, 상태 변경, 중복 방지

사람
-> 중요한 업무 승인과 최종 판단

AI가 틀리거나 응답하지 않아도 중요한 업무 규칙이 무너지지 않도록 설계합니다.

기술적으로는 RBAC, validation, idempotency, fail-closed, auditability를 적용합니다.

3. 언어와 프레임워크는 문제에 맞춰 선택합니다

Java/Spring과 Python/FastAPI를 모두 실무에서 사용해 왔고, SQL, Docker와 LLM을 목적에 따라 연결합니다. 현재 공개 재현 샘플은 Java/Spring 쪽이 더 많기 때문에 Python/FastAPI 기반 데이터·AI 서비스는 별도의 공개 증거로 보강하는 것이 다음 과제입니다.

예를 들면:

  • 복잡한 업무 규칙과 트랜잭션을 다룰 때는 Spring 기반 서버 구조
  • 데이터 처리와 AI API를 빠르게 연결할 때는 Python/FastAPI
  • 데이터 정합성과 조회가 핵심이면 SQL과 DB 설계
  • 배포와 재현성이 중요하면 Docker와 자동화 도구
  • 자연어 해석이나 초안 생성이 필요하면 LLM

중요한 것은 특정 도구 자체가 아니라 문제에 맞는 도구를 선택하고 백엔드 흐름 안에서 안전하게 연결하는 것입니다.

4. AI를 개발 과정에도 사용합니다

AI는 서비스 기능뿐 아니라 조사, 구현과 리뷰에도 활용합니다.

문제 이해
-> 필요한 자료와 코드 탐색
-> 구현 계획 작성
-> 코드와 테스트 작성
-> 다른 관점에서 검토
-> 실제 실행 결과 확인
-> 결과와 한계 기록

AI가 빠르게 조사하거나 코드를 작성해도 최종 완료 여부는 설명이 아니라 테스트와 실행 결과로 판단합니다.

다른 개발자나 AI가 작업을 이어받을 수 있도록 프로젝트 목표, 현재 상태, 작업 목록과 검증 근거를 함께 관리합니다.

쉽게 말하면 AI가 바뀌어도 프로젝트의 목표와 제한을 잃지 않게 하고, AI가 만든 결과도 다시 검증할 수 있게 만드는 방식입니다.

5. 만들었다는 것과 검증했다는 것을 구분합니다

코드가 존재한다고 해서 완료됐다고 보지 않습니다.

가능한 범위에서 다음을 확인합니다.

  • 정상 동작
  • 실패 상황
  • 권한이 없는 요청
  • 중복 요청
  • 잘못된 입력
  • 외부 시스템이나 모델 장애
  • 배포 후 실제 접근
  • 닫기와 복구

공개 포트폴리오에서는 implemented, tested, verified, partial, planned 같은 상태를 구분합니다.

검증하지 않은 대규모 운영, SLA, 실제 사용자 규모나 성능 개선률은 추정해서 쓰지 않습니다.

6. 변경한 범위를 끝까지 봅니다

한 화면의 기능 변경도 실제로는 여러 곳에 영향을 줄 수 있습니다.

사용자 화면
-> API
-> 업무 규칙
-> DB
-> batch 또는 외부 연계
-> 로그와 운영 절차

그래서 문제를 한 파일이나 한 함수의 수정으로만 보지 않고 실제 사용자 흐름 전체에서 영향 범위를 확인하려고 합니다.

7. 운영할 수 없는 코드는 완성으로 보지 않습니다

실행 가능한 코드를 만드는 것뿐 아니라 다음도 함께 고려합니다.

  • 설정을 어디에 둘 것인가
  • 비밀정보를 어떻게 분리할 것인가
  • 배포가 실패하면 어떻게 복구할 것인가
  • 정상 상태를 어떻게 확인할 것인가
  • 로그에 무엇을 남길 것인가
  • 서비스를 안전하게 중단하고 다시 열 수 있는가

기술적으로는 CI/CD, health check, rollback, least privilege, 로그와 runtime 상태 확인 같은 주제로 이어집니다.

8. 업무 결과를 다른 사람이 확인할 수 있게 남깁니다

성과도 기억이나 표현만으로 남기지 않으려고 합니다.

가능하면 다음과 연결합니다.

  • 테스트 결과
  • 실행 결과
  • 검증 데이터
  • 배포 기록
  • 문서
  • 재현 가능한 공개 샘플

첫 화면에서는 테스트 개수보다 무엇이 성공했고 어떤 실패를 차단했는지를 우선 설명합니다. 세부 문서에서는 테스트 수, 응답시간과 환경 정보를 근거로 제공합니다.

회사 자산은 공개하지 않으며, 공개가 필요한 경우 문제와 설계를 일반화하고 합성 데이터로 별도 구현합니다.

한 줄로 정리하면

업무 요구사항을 백엔드 시스템으로 구조화하고, 필요한 경우 AI를 안전하게 연결하며, 테스트와 실제 실행 결과로 검증한 뒤 배포와 복구까지 확인하는 방식으로 개발합니다.