장비 제어 소프트웨어 개발에 관한 몇 가지 조언

장비 제어 SW 개발은 일반적인 소프트웨어 개발과 환경이 다릅니다. 양산 장비 위에서 돌아가는 코드가 갖는 제약과, 한 번의 실수가 만드는 비용을 고려해 꾸준히 갱신해 온 실전 가이드라인을 모아 둡니다.

장비 제어 개발 및 코딩에 대한 조언

장비 제어 SW 개발과 관련된 특수한 환경이 있기 때문에, 일반적인 소프트웨어 개발과는 다른 점이 있을 수 있습니다.

• 디버거 최소화 — 장비 동작 중에는 디버거를 붙이기 어렵습니다. 로그를 적극 활용하고 소스 코드 자체를 빠르게 읽어 내려갈 수 있는 능력을 기르세요.
• 구조 설계 — 큰 그림을 먼저 본 뒤, 코딩에 들어가면 그때부터 세부 사항에 집중합니다.
• 고객 요구 분석 — 표면적인 요청 그 자체가 아니라 근본적인 원인을 찾는 데 시간을 쓰세요.
• 공통 조건 도출 — 여러 조건을 포함하면서 핵심을 관통하는, 단순한 공통 조건을 찾으세요. 분기를 줄여 줍니다.
• 수정의 부작용 — 한 가지 수정이 10 가지 문제를 만들기도 합니다. 체크박스 옵션 하나를 추가하면 경우의 수와 버그가 2 배가 됩니다.
• 코드 분기 비용 — 같은 장비를 2 개의 코드 베이스로 분리해 관리하면 업무량은 1.5 배, 유지보수 비용과 버그는 2 배로 늘어납니다.
• 드라이버 테스트 — 신규 드라이버는 1 대 장비에서 충분히 테스트한 뒤에 양산 장비에 적용하세요.
• 배포 체크리스트 — 실행 파일만 배포하지 말고, 버전 업에 필요한 추가 파일이 모두 포함됐는지 확인하세요.
• 로그 전략 — 핵심 조건·시퀀스·데이터는 반드시 로그를 남기세요. 특히 예외 상황에서는 필수입니다. 그리고 더 이상 의미 없어진 로그는 정리하세요.
• UX 기본 — 결국 사용자에 대한 배려심이 중요합니다.

조건문 작성 원칙

조건문은 읽으면서 의미가 바로 들어오는 순서로 배열합니다.

• 가장 큰 대전제부터 앞에 둡니다.
• 같은 레벨이면 true 가 되기 어려운 조건부터 앞에 둡니다 (단축 평가로 비용 절감 + 오류 회피).
• 전체 부정(!(...)) 을 사용하지 마세요. 사람이 머리속에서 한 번 더 뒤집어야 합니다.

// GOOD
if (A == false && B == false && C == false) { ... }
 
// BAD
if (!(A || B || C)) { ... }

비교식에서는 변수를 앞에, 상수를 뒤에 둡니다 (자연스러운 한국어/영어 어순과 동일).

// GOOD
if (A > 2) { ... }
 
// BAD
if (2 < A) { ... }

포인터 리턴 함수 설계

포인터를 리턴하는 함수에서 에러가 발생했을 때 NULL 을 던지면, 호출자가 매번 null 체크를 깜빡할 위험이 있습니다. 그 결과는 보통 장비 정지로 이어집니다.

• 가능하면 의미 있는 Dummy 데이터 포인터를 리턴해 프로그램이 멈추지 않도록 합니다.
• 단, 이 경우에도 로그는 반드시 남겨 어디서 fallback 이 발생했는지 추적할 수 있어야 합니다.

UI / UX

• XEdit 같은 입력 컨트롤을 추가할 때 적절한 기본값을 함께 설정하세요. 빈 값으로 두면 사용자가 매번 채워야 합니다.
• 저장하지 않고 화면을 벗어나면 데이터를 원상 복귀시키세요. "저장 안 함" 의 기대 동작이 일관되어야 합니다.

관리 및 최적화

• 고객사 요구를 너무 쉽게 들어 주면 그것이 당연한 기준이 됩니다.
• 중복 코드는 보이는 즉시 함수로 모듈화하세요. 미루면 두 코드가 갈라집니다.
• Include Path 는 전체 옵션이 아니라 개별 프로젝트 옵션으로 설정하세요. 환경 의존성을 줄여 줍니다.
• 프로젝트 중반 이후부터 출구 전략(인수 인계·문서화·로그 정비) 을 생각하세요.

로그 / 검색 친화적 표기

로그 메시지에서 함수 이름을 쓸 때는 괄호 () 를 붙이지 마세요. 검색이 어려워집니다.

// GOOD
LOG_PRINTF("", "DoFunc 함수 실행");
 
// BAD
LOG_PRINTF("", "DoFunc() 실행");

호환성과 시나리오

• 기능 추가 시 기존 데이터의 호환성과 양산 장비 적용 가능성을 먼저 따져 보세요. 데이터 마이그레이션 비용이 의외로 큽니다.
• 시퀀스 문제가 발생하면 명확한 타이밍과 시나리오를 재현해 낼 때까지 추적을 멈추지 마세요. "가끔 발생합니다" 로 끝내면 양산 후에 더 큰 비용이 발생합니다.

개발 도구와 언어

강력하고 편리한 개발 도구·언어를 사용하세요.

• 범용: Visual Studio (C++, C#)
• 제어 전용: BeckHoff TwinCAT, CodeSys
• ICT 자체 통합 개발 도구: QMachineStudio — 시퀀스·GUI·런타임 디버깅을 한 IDE 에서

좋은 도구와 강력한 언어는 개발 효율성을 크게 끌어올립니다. 익숙해진 도구가 있더라도 주기적으로 환경을 점검해 보는 것이 장기적으로 도움이 됩니다.