반례를 생각하니 규칙이 더 명확해졌다

내가 작년까지 참여해왔던 프로젝트들은, 설계 문서를 꼼꼼히 읽거나 요구사항에 대해 면밀히 파악하며 개발을 진행할 수 있었던 프로젝트가 아니었다.
기간은 촉박하지, 결과물은 빨리 내야 하지...솔직히 개발자가 독단적으로 판단해서 바로 개발했던 일도 부지기수였다.
지금에야 돌이켜보면, 집 짓는 공사를 하는 데 뼈대를 대충 세우고 공사를 한 것이나 다름 없었다.

그래서 얼마 전 부트캠프를 시작하고 첫 번째 과제로 설계 문서 작성을 받았을 때, 몹시 막막했다.
이제껏 개발이나 구현은 해오긴 했는데, 설계는 어떻게 해야 할지 한 번도 제대로 생각해 본 적이 없었다.

 

1. 어떤 상황이었나

내가 만들어야 하는 설계 문서는 이커머스 쿠폰 할인 시스템에 대한 설계 문서였다.
기준 문장을 바탕으로 규칙을 정하고 외부 계약과 내부 경계를 선택해야 했는데, 이 모든 과정이 낯설었다.
특히 명확한 규칙을 정하고 시작하는 것이 매우 새로웠다.
새롭기는 했지만 직접 설계를 하는 것이 쉽지 않다는 것을 깨달았다. 구현에 틈이 없으려면, 그만큼 설계가 튼튼해야 했기 때문이다.
기준 문장과 화인된 사실, 제품 담당자에게 물을 질문을 작성하는 부분까지는 비교적 수월하게 작성했으나, 규칙 여섯 개와 반례를 연결하는 부분이 문제였다.

 

2. 처음 쓴 규칙에는 답이 없었다

규칙 여섯 개에 대한 기초적인 내용은 이미 과제 가이드 문서에 명시되어 있었다.
가장 낯설었던 부분은 반례였는데, 지금까지는 개발을 하면서도 테스트 중 예외 상황이 생기면 그때마다 기능을 수정했던 경험들이 생각났고 반례에 대해 깊이 생각하지 않았기 때문에 이런 경험들을 해왔음을 깨달았다.
규칙을 세우는 것 만큼이나 반례를 공들여 세워 규칙을 더 단단히 만들어야 했던 것이다.

맨 처음으로 맞닥뜨린 규칙은 할인 적용은 그 주문을 소유한 구매자의 요청에서만 성공한다였는데,
너무 당연한 명제라고 생각했었기 때문에 반례를 반드시 연결해야 한다는 설계 요구사항이 어렵게 느껴졌었다.

 

3. 반례 하나가 답을 강제했다

하지만 규칙을 쪼개서 생각해보니, 주문을 소유하지 않은 구매자의 요청이 들어올 경우에 대해서 생각해볼 수 있었다.
더 나아가 주문을 소유하지 않은 관리자가 요청을 하게 된다면?과 같은 경우까지 생각해냈다.
견고하고 당연하다고 생각했던 규칙이었는데, 반례가 등장하니까 이 경우를 어떻게 처리해야 할지, 기대 결과와 책임 소재까지 연결할 수 있었다.

 

4. 배운 것

설계에 왜 공을 들여야 하는지 조금이나마 그 이유를 알게 되었다.
설계가 중요하다는 것을 자주 듣긴 했지만 실제로 설계를 하며 직접적으로 느끼게 된 경험은 처음이었다.
그리고 아무리 ai로 코드를 구현한다 한들, 설계의 영역에서는 파일럿이 방향을 잘 잡고 지속적으로 ai를 감시해야 단순한 설계 문서 하나라도 빈틈 없이 정교하게 만들 수 있다는 것을 배웠다.