오랫동안 DB/ETL 분야에서 일해 온 저는 최근 처음으로 PLC에 대해 배우기 시작했습니다. 인터넷에서 검색해 보니, PLC 관련 글 대부분이 두 가지 유형으로 나뉘는 것을 발견했습니다. 하나는 전기 공학이나 제어 시스템 배경 지식을 가진 사람들을 대상으로 한 고급 강의식 자료였고, 다른 하나는 특정 기업(미쓰비시, LS 산업시스템, 지멘스 등)의 제품 설명서를 그대로 옮겨 쓴 듯한 글들이었습니다. 하지만 “소프트웨어 배경을 가진 완전 초보자가 처음 며칠 또는 몇 주 동안 실제로 무엇을 헷갈려 했는지, 어떤 부분에서 막혔는지”를 기록한 글은 거의 없었습니다.
이 글은 바로 그 공백을 메우기 위한 시도입니다. 화려한 지식을 전달하기보다는, 제가 처음 PLC를 다룰 때 실제로 겪었던 혼란과 시행착오를 가능한 한 솔직하게 기록하고자 합니다. 이 글이 소프트웨어 개발 배경에서 PLC로 전환하는 분들이나 제어 시스템을 처음 접하는 분들에게, 비록 조금이라도 위안이 되어 “아, 혼란스러워한 건 나뿐만이 아니었구나”라고 생각할 수 있는 계기가 되기를 바랍니다.
돌이켜보면, 처음 며칠이 더 답답했던 이유는 내용을 이해하지 못해서가 아니라, 내가 무엇을 모르는지조차 몰랐기 때문이었습니다. 소프트웨어 개발에서는 오류 메시지가 뜨면 검색을 통해 단서를 찾을 수 있지만, 래더 로직에서는 대개 구문 오류가 발생하지 않고 단순히 “의도한 대로 작동하지 않을” 뿐이라, 저는 디버깅에 대한 완전히 새로운 접근 방식을 배워야 했습니다. 따라서 이 글은 완성된 지식을 제시하기보다는, 그 좌절스러운 과정을 대략적인 시간 순서대로 되짚어 보는 데 목적을 두고 있습니다.
코드에 익숙한 개발자가 PLC를 처음 마주했을 때 느꼈던 혼란감
래더 다이어그램을 처음 봤을 때의 기분이 아직도 생생합니다. 두 개의 수직선 사이에 접점과 코일이 배열된 다이어그램을 보며 저는 “이게 도대체 무슨 회로도지? 코드는 어디에 있는 거야?”라고 생각했습니다. 텍스트 기반 언어에 익숙한 배경에서 온 저로서는, 이것을 “프로그램”이라고 부르는 것 자체가 낯설게 느껴졌습니다.
가장 큰 난관이었던 개념은 바로 “스캔” 방식이었습니다. 일반 소프트웨어에서는 이벤트가 발생하면 시스템이 반응하는 이벤트 주도형 사고방식에 익숙해져 있었지만, PLC는 전원이 켜져 있는 한 전체 프로그램을 처음부터 끝까지 반복적으로 스캔하며 작동합니다. 이 한 번의 통과를 ‘스캔’이라고 부른다는 사실과, 이러한 스캔이 지속적으로 반복됨에 따라 입력 읽기, 계산 수행, 출력 업데이트의 사이클이 끝없이 진행된다는 것을 이해하는 데 예상보다 더 오랜 시간이 걸렸습니다. “그렇다면 그 사이의 조건들은 언제 처리되는가?”라는 질문에 대한 답을 찾던 중, “조건은 매 스캔마다 위에서 아래로, 왼쪽에서 오른쪽으로 순서대로 평가된다”는 원리를 내면화한 후에야 비로소 그 개념을 파악하기 시작했습니다.
두 번째로 낯설게 느껴졌던 점은 모든 것이 변수가 아닌 “주소”를 사용하여 처리된다는 것이었습니다. 소프트웨어에서는 의미 있는 이름을 가진 변수를 선언하고 사용하는 것이 당연하지만, PLC 프로그래밍 입문 단계에서는 입력, 출력, 내부 릴레이가 모두 X0, X1, Y0, Y1, M0, M1과 같은 주소 기반 시스템으로 처리되었습니다. 나중에야 현대적인 소프트웨어(GX Works2나 XG5000 같은 프로그래밍 도구)에서는 주소에 별도의 이름(장치 주석)을 할당할 수 있다는 사실을 알게 되었지만, 처음에는 그런 기능이 존재한다는 사실조차 몰라 주소가 실제로 무엇을 의미하는지 계속 헷갈렸습니다.
셋째, “디버깅” 행위 자체가 완전히 다르게 느껴졌습니다. 저는 소프트웨어에서 중단점을 설정하고 변수 값을 하나씩 확인하며 원인을 좁혀가는 데 익숙했지만, PLC 작업을 시작한 초기 단계에서는 이 방식이 어색하게 느껴졌습니다. 물론 나중에 모니터링 모드에서 접점이 켜지고 꺼지는 것을 실시간으로 확인할 수 있다는 사실을 알게 되었지만, 그 사실을 알기 전까지는 단순히 전체 회로를 눈으로 훑어보며 “문제가 여기 있는 건가?”라고 추측하는 데 많은 시간을 낭비했습니다.
실습하면서 정말 혼란스러웠던 점들
이론 책을 읽을 때보다 실제로 사다리 회로를 손으로 조립할 때 훨씬 더 많은 문제를 겪었습니다. 여기서는 가장 흔한 문제 몇 가지를 요약해 보겠습니다.
1) “a”와 “b” 접점의 방향에 대해 계속 헷갈렸습니다.
a 접점(Normally Open)은 평상시에는 열려 있다가 신호를 받으면 닫히며, b 접점(Normally Closed)은 평상시에는 닫혀 있다가 신호를 받으면 열립니다. 개념 자체는 금방 외웠지만, 실제로 회로를 조립할 때는 계속 헷갈려서—“이 버튼을 누르면 회로를 멈추고 싶다면 a 접점을 써야 할까, b 접점을 써야 할까?”라고 고민하다가 실수를 저지르곤 했습니다. 제 혼란은 “정상 상태는 버튼이 눌려 있지 않은 상태”인 비상 정지 버튼과 같은 안전 관련 회로의 설계 철학을 이해한 후에야 비로소 가라앉았습니다. 이러한 회로는 접점을 사용하여 전선이 끊어지는 상황에서도 시스템이 안전한 방식으로 작동하도록 보장합니다.
2) 자가 유지 회로의 원리를 이해하는 데 오랜 시간이 걸렸습니다.
이 회로는 버튼을 잠시 눌렀다가 놓아도 출력이 활성화된 상태로 유지되는 회로입니다. 처음에는 버튼을 놓았을 때 신호가 끊어졌는데도 출력이 켜진 상태로 남아 있는 이유를 도무지 이해할 수 없었습니다. 시뮬레이터를 사용하여 각 스캔 유닛을 하나씩 추적하고, 회로 자체의 출력 접점이 병렬로 연결되어 “이미 켜져 있다면 스스로 켜진 상태를 유지한다”는 논리 구조를 시각적으로 확인한 후에야 비로소 완전히 이해할 수 있었습니다.
text
[시작 버튼 X0] --+-- [정지 버튼 X1 (b-접점)] -- ( Y0 )
|
[자가 유지 접점 Y0 (a-접점)]
시작 버튼을 누르면 Y0이 켜지고, 그 후 Y0은 자가 유지 접점을 통해 회로를 스스로 유지합니다. 정지 버튼을 누르면 b-접점이 열리면서 전체 회로가 차단되고 Y0이 꺼집니다.
3) 타이머 및 카운터 명령어의 매개변수 단위를 자주 혼동했습니다.
타이머 설정이 100ms 단위인지 10ms 단위인지는 제품군에 따라 다르며, 동일한 제품 내에서도 타이머 유형(온딜레이, 오프딜레이)에 따라 작동 방식이 다릅니다. 그 결과, 초기 단계에서는 작동 시간이 의도한 것보다 훨씬 길거나 짧아지는 경우가 잦았습니다. 그 후로는 시뮬레이터에서 항상 타이머 값을 직접 확인하고, 실제 배수를 계산하여 기록하는 습관을 들였습니다.
4) 소싱(sourcing)과 싱킹(sinking) 배선 방식의 차이로 인해 입력이 전혀 들어오지 않는 문제.
이 문제는 소프트웨어와 무관한 순수한 전기적 개념이었기 때문에 해결하기가 훨씬 더 어려웠습니다. 센서나 스위치가 소싱(sourcing) 유형인지 싱킹(sinking) 유형인지에 따라 PLC 입력 모듈의 공통(COM) 단자 연결 지점이 달라집니다. 한 번은 이 사실을 모르고 배선을 잘못한 적이 있었는데, 시뮬레이터에서는 로직이 정상적으로 작동했지만 실제 배선에서는 입력을 전혀 감지하지 못했습니다. 결국 매뉴얼의 배선도를 여러 번 검토한 후에야 원인을 파악할 수 있었습니다. 오로지 소프트웨어 작업만 해온 배경 탓에 “논리가 맞다면 당연히 작동할 것”이라고 가정했었지만, 실제 전기 신호의 방향과 극성에 주의를 기울여야 한다는 사실을 진정으로 깨달은 것은 이때가 처음이었습니다.
PLC 학습을 위한 완전 초보자 가이드: 학습 순서와 시행착오를 통한 팁
몇 주간의 우여곡절 끝에, 제가 처음부터 따랐더라면 좋았을 단계별 순서를 정리해 보았습니다.
먼저, 시뮬레이터를 사용하여 스캐닝 개념을 익히세요. 실제 하드웨어가 없더라도 프로그래밍 도구 자체에서 제공하는 시뮬레이션 기능을 활용해 접점과 코일이 스캔 단위별로 어떻게 켜지고 꺼지는지 관찰할 수 있습니다. 이 단계를 건너뛰고 바로 이론 서적을 읽기 시작하면, 왜 그런 방식으로 작동하는지 이해하지 못한 채 개념을 암기하는 데 그칠 것입니다.
기본 회로 4~5개를 손으로 직접 그려보고, 왜 그런 방식으로 작동하는지 설명할 수 있을 때까지 이 과정을 반복하세요.
자가 유지 회로, 인터록 회로, 지연 시동/정지 회로, 플리커 회로와 같은 회로들의 경우, 단순히 시각적으로 알아보는 것과 실제로 손으로 조립하여 의도한 대로 작동하게 만드는 것 사이에는 상당한 차이가 있었습니다. 특히, 두 회로의 “b” 접점을 서로 연결하여 두 출력이 동시에 켜지지 않도록 설계된 인터록 회로의 경우, 직접 조립해 보기 전까지는 제대로 이해되지 않았습니다. 다른 사람에게 설명할 수 있을 만큼 충분히 이해했는지 스스로 판단하는 기준을 적용해 보니, 표면적으로만 알고 있다고 착각했던 부분들이 훨씬 더 명확하게 드러났습니다.
처음부터 핀 번호 체계와 장치 주석 기능을 함께 사용하세요.
처음에는 핀 번호만 보고 프로그램을 이해하려는 것은 마치 암호를 해독하는 것과 비슷합니다. 프로그래밍 도구에서 장치에 이름(주석)을 지정할 수 있는 기능을 찾아, 작업을 진행하면서 처음부터 “시작 버튼”이나 “모터 출력”과 같은 이름을 지정하세요. 이렇게 하면 논리를 훨씬 더 빨리 이해할 수 있습니다.
배선 기본 사항(소스/싱크, 접지, 노이즈 대책)에 대해서는 전기 공학 전공자에게 직접 물어보는 것이 가장 빠른 방법입니다. 소프트웨어 개발자들은 문제를 해결할 때 검색 엔진에 의존하는 경향이 있지만, 전기 배선과 관련된 문제의 경우 현장 경험이 있는 사람에게 실제 부품을 보여주며 직접 물어보는 것이 훨씬 더 정확하고 빠릅니다. 자존심을 접고 물어보는 것이 시간을 가장 많이 절약할 수 있는 최선의 방법이었습니다.
*처음부터 모니터링 모드를 적극적으로 활용하세요. *
앞서 언급한 디버깅 방식의 차이 때문에, 저는 처음에는 모니터링 기능을 거의 사용하지 않았습니다. 하지만 나중에 이 기능을 제대로 활용하기만 해도 어떤 접점이 활성화되어 있고 어떤 접점이 차단되어 있는지 실시간으로 시각적으로 확인할 수 있다는 사실을 깨달았습니다. 이 기능을 소프트웨어 디버거와 동등한 것으로 생각하고 처음부터 숙달했더라면, 초기의 시행착오를 상당히 줄일 수 있었을 것입니다.
자신에게 작은 목표를 설정하고 이를 끝까지 완수하는 것이 중요합니다. 이론만 계속 읽다 보면 진전이 있는 것처럼 보일 수 있지만, 실제로는 요령을 터득하지 못하게 됩니다. “단 하나의 버튼으로 램프를 켜고 끄기”나 “3초 후에 자동으로 꺼지도록 설정하기”처럼 아무리 사소한 목표라도, 스스로 세운 목표를 끝까지 완수해 본 경험은 두꺼운 이론서를 읽는 것보다 훨씬 더 큰 도움이 되었습니다.
아직 갈 길이 멀지만, 소프트웨어 개발과는 완전히 다른 사고방식을 요구하는 PLC를 서서히 이해해 나가는 과정 자체가 꽤 흥미롭습니다. 특히 스캔 사이클의 개념을 완전히 파악한 후에는 인터록이나 순차 제어와 같은 후속 개념들을 훨씬 더 쉽게 이해할 수 있게 되었습니다. 결국, 수많은 응용 예제를 겉핥기식으로 훑어보는 것보다 단 하나의 기초 개념을 철저히 파악하는 것이 훨씬 더 효율적인 학습 방법이라는 사실을 다시 한번 깨달았습니다. 내용을 서둘러 훑어보기보다는, 막히는 부분을 완전히 헤쳐 나가기 위해 시간을 투자하는 것이 결국 이 과정에 있어 필수적인 부분이었나 봅니다. 다음 글에서는 실제 소형 PLC를 사용하여 컨베이어 벨트를 정지 및 가동시키는 시뮬레이션을 구축한 제 경험을 더 자세히 다루겠습니다.