"코드가 지저분해지는 건 실력이 아니라 패턴의 부재입니다." 실무 펌웨어 개발자가 전하는 FSM 패턴 도입 꿀팁과 흔히 하는 실수들을 정리했습니다.
신입 시절, 저는 if문을 5단계까지 중첩해서 쓴 적이 있습니다. 결과는 참담했죠. 수정 하나 하면 다른 곳에서 버그가 터졌거든요. 😭 선배에게 한 소리 듣고 배운 '상태 머신'은 제 개발 인생의 터닝포인트였습니다. 오늘 그 노하우를 아낌없이 공유할게요!
첫 번째 주요 섹션: 스파게티 코드의 징후들 🤔
여러분의 프로젝트가 다음과 같다면 즉시 FSM 도입을 고민해야 합니다.
- bool 타입의 플래그(Flag) 변수가 전역으로 10개 이상 선언되어 있다.
- 특정 버튼을 눌렀을 때의 동작이 현재 상황에 따라 달라져야 하는데 처리하기가 너무 힘들다.
- 코드를 수정할 때마다 의도치 않은 '사이드 이펙트'가 발생한다.
📌 알아두세요!
FSM의 핵심은 '현재 내가 어디에 있는가'를 명확히 하는 것입니다. 이를 통해 불필요한 조건 검사를 획기적으로 줄일 수 있습니다.
FSM의 핵심은 '현재 내가 어디에 있는가'를 명확히 하는 것입니다. 이를 통해 불필요한 조건 검사를 획기적으로 줄일 수 있습니다.
두 번째 주요 섹션: 설계 효율성 자가 진단 📊
FSM을 도입할 때 상태의 개수를 적절히 관리하는 것이 중요합니다. 너무 세분화하면 오히려 복잡해질 수 있기 때문입니다.
🔢 상태 복잡도 분석기
현재 프로젝트의 예상 상태 개수를 입력해 보세요.
상태 개수:
실전 예시: 통신 프로토콜 파싱 📚
실무에서 FSM이 가장 빛을 발하는 순간은 UART나 SPI 통신 데이터를 파싱할 때입니다.
데이터 수신 시퀀스 예시
이런 식으로 설계하면 데이터가 중간에 잘리거나 노이즈가 섞여도 시스템이 멈추지 않고 안전하게 다음 패킷을 기다릴 수 있습니다.
FSM 도입 3대 원칙
단일 책임: 한 번에 하나의 상태만 가지도록 하세요.
명시적 전이: 상태 변화는 반드시 이벤트에 의해서만 일어나게 하세요.
예외 처리: 모든 switch문에 default를 넣어 예측 불가능한 상황을 막으세요.
자주 묻는 질문 ❓
Q: switch-case 말고 함수 포인터 배열을 쓰면 안 되나요?
A: 성능상 이점은 있지만 가독성이 떨어집니다. 상태가 50개 이상인 매우 큰 시스템이 아니라면 switch-case가 실무에서 훨씬 선호됩니다.
Q: 상태 머신 설계를 위한 무료 툴이 있나요?
A: draw.io 나 Lucidchart 같은 다이어그램 툴만 써도 충분합니다. 중요한 건 코딩 전 머릿속 로직을 시각화하는 과정입니다.
