자바 백엔드 실무

들어가며

시스템 운영(SM)이나 구축(SI) 프로젝트를 하다 보면 가장 난감한 순간이 있습니다. 현업 담당자가 이렇게 말할 때입니다.

“이 화면 너무 복잡한데, 엑셀처럼 그냥 편하게 입력하고 저장되게 해주세요.”

주니어 개발자 시절엔 이 말을 듣고 바로 IDE를 켜고 코딩을 시작했습니다. 하지만 결과는 항상 “어? 제가 원한 건 이게 아닌데요?”라는 수정 요청의 반복이었죠.

5년 차 이상의 시니어, 그리고 PL(Project Leader) 역할을 맡고 있다면 이 추상적인 요구사항(Requirement)을 구체적인 기술 명세(Specification)로 통역하는 능력이 필수적입니다. 오늘은 제 경험을 바탕으로 그 과정을 복기해 봅니다.

1단계: 숨겨진 의도 파악하기 (AS-IS 분석)

“편하게 해달라”는 말 뒤에 숨겨진 진짜 불편함을 찾아야 합니다.

• 인터뷰: “현재 어떤 점이 가장 불편하신가요?”
  • 현업: “자산 하나 등록하려면 팝업창 띄우고 저장하고, 다시 닫고 목록 조회하고… 100개 등록하려면 하루 종일 걸려요.”
• 분석: 아하, 이 요구사항은 단순 UI 개선이 아니라 ‘대량 데이터의 일괄 처리(Bulk Insert)’ 기능이 필요하다는 뜻이구나.

이 단계에서 개발자는 NEXACRO의 그리드 편집 모드와 트랜잭션 일괄 처리 기능을 기술적 해법으로 머릿속에 떠올려야 합니다.

2단계: 시각화로 합의하기 (Prototyping)

말로만 “그리드에서 바로 입력하게 해 드릴게요”라고 하면 서로 상상하는 그림이 다릅니다.

• 와이어프레임 작성: PPT나 전문 도구(Figma 등)를 쓰지 않더라도, 엑셀이나 화이트보드에 대략적인 UI를 그려서 보여줍니다.
• 넥사크로 프로토타입: 혹은 넥사크로에서 기능 없는 껍데기(Mock-up) 화면을 빠르게 만들어 보여주는 것이 가장 확실합니다.
  • “여기서 엔터 치면 다음 칸으로 넘어가고, 저장 버튼 한 번만 누르면 됩니다. 맞으시죠?”

이 과정에서 ‘합의(Agreement)’를 이끌어내는 것이 프로젝트의 성패를 가릅니다.

3단계: 기술 명세서 작성 (To-BE 설계)

합의된 내용을 바탕으로 개발자가 구현할 수 있는 언어로 문서를 작성합니다. PL이라면 팀원들에게 나눠줄 작업 지시서가 되겠죠.

1) UI 설계서 (Storyborad)

• 화면 ID: UI-ASSET-001
• 이벤트 정의:
  • Grid.onenterdown: 포커스 이동
  • BtnSave.onclick: 변경된 행(RowType이 Insert/Update인 것)만 추출하여 전송

2) 테이블 명세 및 쿼리 설계

• “엑셀 업로드도 되나요?”라는 추가 질문이 나올 것을 대비해야 합니다.
• 단건 처리용 프로시저를 재활용할지, 배치성 MyBatis foreach 구문을 새로 짤지 결정합니다.

4단계: 방어적 설계 (Exception Case)

현업은 ‘정상적인 흐름(Happy Path)’만 이야기합니다. 하지만 개발자는 ‘예외 상황’을 설계해야 합니다.

• “입력하다가 실수로 브라우저를 닫으면요?” -> onbeforeclose 이벤트에서 경고창 띄우기
• “100건 중에 3번째 데이터가 에러 나면 나머지는요?” -> 6일차에 다뤘던 트랜잭션 전략(전체 롤백 vs 부분 성공)을 결정하고 현업에게 비즈니스 룰을 역제안해야 합니다.

마무리하며

고객의 모호한 말 한마디를 [UI 화면 - 데이터 흐름 - 테이블 설계 - 예외 처리]로 구체화시키는 것. 이것이 코딩 실력만큼이나 중요한 분석/설계 역량입니다.

특히 방산/공공 분야 프로젝트는 요구사항 추적표(RTM) 관리와 산출물 작성이 매우 중요합니다. “코딩만 잘하면 되지”라는 생각보다는, “내가 설계한 대로 시스템이 움직이고, 고객이 만족한다”는 것에서 더 큰 성취감을 느끼는 개발자가 되어야 합니다.

이제 설계는 끝났고, 기능도 구현했습니다. 하지만 시스템은 한 번 만들고 끝나는 게 아닙니다. 10년 넘게 돌아가는 시스템도 있죠. 다음 글에서는 아무도 건드리고 싶어 하지 않는 오래된 코드, [레거시 시스템 유지보수와 리팩토링의 균형]에 대해 이야기해 보겠습니다.