DB/ETL 쪽 일을 오래 하다가 최근에 PLC를 처음 공부하기 시작했습니다. 검색해보니 PLC 관련 글은 대부분 두 부류였습니다. 하나는 이미 전기·제어 전공자를 대상으로 한 심화 강의성 자료, 다른 하나는 특정 회사 제품(미쓰비시, LS산전, 지멘스 등)의 매뉴얼을 그대로 옮긴 듯한 글이었습니다. 정작 "소프트웨어 쪽에서 넘어온 완전 초보가 처음 며칠, 몇 주 동안 뭘 헷갈리고 뭘로 막혔는지"를 기록한 글은 거의 없더라고요.
이 글은 그 빈자리를 채우려는 시도입니다. 화려한 지식 전달보다는, 제가 실제로 처음 PLC를 만지면서 겪은 혼란과 시행착오를 최대한 솔직하게 기록해보려고 합니다. 비슷하게 소프트웨어 개발 배경에서 PLC로 넘어오시는 분들, 혹은 완전히 처음 제어를 접하시는 분들께 "아 나만 헷갈렸던 게 아니구나" 하는 위안이라도 됐으면 합니다.
돌이켜보면 처음 며칠은 이해를 못 해서 답답한 것보다, 뭘 모르는지조차 몰라서 더 답답했습니다. 소프트웨어 쪽에서는 에러 메시지라도 뜨면 그걸 검색해서 실마리를 찾을 수 있는데, 래더 로직은 문법 오류 없이 그냥 "의도한 대로 동작하지 않는" 경우가 대부분이라 디버깅 방식 자체를 새로 배워야 했습니다. 그래서 이 글은 완성된 지식보다는, 그 답답했던 과정을 시간 순서에 가깝게 풀어보려고 합니다.
코드에 익숙한 개발자가 PLC 앞에서 처음 느낀 이질감
처음 래더 다이어그램(Ladder Diagram)을 봤을 때 느낌을 아직도 기억합니다. 세로선 두 개 사이에 접점과 코일이 나열된 그림을 보고 "이게 무슨 회로도인가, 코드는 어디 있지?" 싶었습니다. 텍스트 기반 언어에 익숙한 입장에서는 이걸 프로그램이라고 부르는 것 자체가 낯설었습니다.
가장 크게 부딪힌 개념은 "스캔(Scan)" 방식이었습니다. 일반적인 소프트웨어는 이벤트가 발생하면 그 시점에 반응하는 이벤트 기반 사고에 익숙한데, PLC는 전원이 들어와 있는 동안 프로그램 전체를 처음부터 끝까지 반복해서 훑는 방식으로 동작합니다. 이 한 바퀴를 스캔이라고 부르고, 이 스캔이 계속 반복되면서 입력을 읽고, 연산하고, 출력을 갱신하는 사이클이 끊임없이 돌아간다는 걸 이해하는 데 생각보다 시간이 걸렸습니다. "그럼 사이에 낀 조건들은 언제 처리되는 거지?"라는 질문에 답을 찾다가, 결국 "매 스캔마다 위에서 아래로, 왼쪽에서 오른쪽으로 순서대로 평가된다"는 원리를 체득하고 나서야 감이 잡히기 시작했습니다.
두 번째로 낯설었던 건 변수 대신 "번지(주소)"로 모든 걸 다룬다는 점이었습니다. 소프트웨어에서는 의미 있는 이름의 변수를 선언해서 쓰는 게 당연한데, PLC 입문 단계에서는 X0, X1, Y0, Y1, M0, M1처럼 입력·출력·내부 릴레이를 전부 번지 체계로 다뤘습니다. 나중에 알고 보니 요즘 소프트웨어(GX Works2, XG5000 같은 프로그래밍 툴)에서는 번지에 별도로 이름(디바이스 코멘트)을 붙일 수 있다는 걸 알게 됐지만, 처음엔 그런 기능이 있는지도 모른 채 번지만 보고 이게 뭘 의미하는지 계속 헷갈렸습니다.
세 번째는 "디버깅"이라는 행위 자체가 완전히 다르게 느껴졌다는 점입니다. 소프트웨어에서는 브레이크포인트를 걸고 변수 값을 하나씩 찍어보며 원인을 좁혀가는 게 익숙한데, PLC 초기 단계에서는 이게 어색했습니다. 물론 모니터링 모드로 접점이 켜지고 꺼지는 걸 실시간으로 볼 수 있다는 걸 나중에 알게 됐지만, 그걸 알기 전까지는 그냥 전체 회로를 눈으로 읽으면서 "여기가 문제인가?" 하고 추측하는 식으로 접근하다가 시간을 많이 허비했습니다.
실습하며 부딪힌 진짜 헷갈렸던 것들
이론서를 읽을 때보다 실제로 손으로 래더를 짜보면서 부딪힌 문제들이 훨씬 많았습니다. 몇 가지 대표적인 것들을 정리해봅니다.
1) a접점과 b접점의 방향이 계속 헷갈렸습니다.
a접점(Normally Open)은 평소에 열려 있다가 신호가 들어오면 닫히고, b접점(Normally Closed)은 반대로 평소에 닫혀 있다가 신호가 들어오면 열립니다. 개념 자체는 금방 외웠는데, 실제 회로를 짤 때 "이 버튼을 눌렀을 때 정지시키고 싶으면 a접점을 써야 하나 b접점을 써야 하나"를 계속 반대로 생각해서 틀렸습니다. 특히 비상정지 버튼처럼 "평소엔 눌려있지 않은 상태가 정상"인 안전 관련 회로에서는 b접점을 써서 단선 시에도 안전 쪽으로 동작하게 만든다는 설계 철학을 이해하고 나서야 헷갈림이 줄었습니다.
2) 자기유지회로(Self-Holding Circuit) 원리를 이해하는 데 오래 걸렸습니다.
버튼을 짧게 눌렀다 떼도 출력이 계속 유지되는 회로인데, 처음엔 "버튼에서 손을 떼면 신호가 끊기는데 왜 계속 켜져 있지?"가 이해가 안 갔습니다. 직접 시뮬레이터로 스캔 단위로 하나씩 따라가면서, 자기 자신의 출력 접점을 병렬로 걸어서 "내가 이미 켜져 있다면 나를 계속 켜진 상태로 유지한다"는 논리 구조라는 걸 눈으로 확인하고 나서야 완전히 이해가 됐습니다.
text
[기동 버튼 X0] --+-- [정지 버튼 X1(b접점)] --( Y0 )
|
[자기유지 접점 Y0(a접점)]
기동 버튼을 누르면 Y0가 켜지고, 이후 자기유지 접점을 통해 Y0 스스로가 자기 회로를 계속 살려주는 구조입니다. 정지 버튼을 누르면 b접점이 열리면서 전체 회로가 끊어지고 Y0가 꺼집니다.
3) 타이머와 카운터 명령어의 파라미터 단위를 자주 착각했습니다.
타이머 설정값이 100ms 단위인지 10ms 단위인지 제품군마다 다르고, 같은 제품이라도 타이머 종류(온딜레이, 오프딜레이)에 따라 동작 방식이 달라서, 초반에는 의도한 시간보다 훨씬 길거나 짧게 동작하는 경우가 많았습니다. 이후로는 반드시 시뮬레이터에서 타이머 값을 눈으로 확인하고, 실제 배수를 계산해서 적어두는 습관을 들였습니다.
4) 소싱(Sourcing)과 싱킹(Sinking) 배선 방식 차이 때문에 입력이 아예 안 들어오는 문제.
이건 소프트웨어와 무관한, 순수 전기적인 개념이라 더 어려웠습니다. 센서나 스위치가 소싱 타입인지 싱킹 타입인지에 따라 PLC 입력 모듈의 커먼(COM) 단자를 어디에 연결해야 하는지가 달라지는데, 이걸 모르고 배선했다가 시뮬레이터에서는 멀쩡하던 로직이 실제 배선에서는 입력이 아예 안 잡히는 경험을 했습니다. 결국 매뉴얼의 배선도를 몇 번이고 다시 보고 나서야 원인을 찾았습니다. 소프트웨어만 다루던 입장에서는 "논리적으로 맞으면 당연히 동작해야 하는 것" 아니냐고 생각했는데, 실제 전기 신호의 방향과 극성까지 신경 써야 한다는 걸 여기서 처음 체감했습니다.
왕초보가 정리한 PLC 입문 학습 순서와 시행착오 노하우
몇 주간의 좌충우돌을 겪고 나서, 처음부터 이렇게 했으면 좋았을 것 같다는 순서를 정리해봤습니다.
시뮬레이터로 먼저 스캔 개념을 눈에 익힌다. 실제 하드웨어 없이도 프로그래밍 툴 자체에서 제공하는 시뮬레이션 기능으로 접점과 코일이 켜지고 꺼지는 걸 스캔 단위로 확인할 수 있습니다. 이 과정을 생략하고 바로 이론서만 읽으면, 왜 그렇게 동작하는지 감이 안 잡힌 채로 암기만 하게 됩니다.
기본 회로 4~5개는 직접 손으로 그려보고 왜 그렇게 동작하는지 설명할 수 있을 때까지 반복한다.
자기유지회로, 인터록 회로, 지연 기동/정지 회로, 플리커(점멸) 회로 정도는 눈으로 봐서 아는 것과 손으로 직접 짜서 의도대로 동작시키는 것 사이에 꽤 큰 차이가 있었습니다. 특히 인터록 회로는 두 출력이 동시에 켜지지 않도록 서로의 b접점을 상대방 회로에 넣는 구조인데, 이것도 직접 짜보기 전까지는 원리가 와닿지 않았습니다. 누군가에게 설명할 수 있을 정도로 이해했는지를 스스로 기준으로 삼으니, 어설프게 안다고 착각했던 부분들이 훨씬 잘 드러났습니다.
번지 체계와 디바이스 코멘트 기능을 처음부터 같이 쓴다.
번지만 보고 프로그램을 읽으려면 초반에는 거의 암호 해독 수준입니다. 사용하는 프로그래밍 툴에서 디바이스에 이름(코멘트)을 붙이는 기능을 찾아서, 처음부터 "기동버튼", "모터출력" 같은 이름을 붙여가며 작업하면 훨씬 빠르게 로직을 이해할 수 있습니다.
배선 기초(소싱/싱킹, 접지, 노이즈 대책)는 전기 전공자에게 직접 물어보는 게 가장 빠릅니다. 소프트웨어 개발자 입장에서는 검색으로 해결하려는 습관이 있는데, 전기 배선 관련 문제는 현장 경험이 있는 분에게 실물을 보여주면서 물어보는 게 훨씬 정확하고 빨랐습니다. 자존심 세우지 않고 물어보는 게 시간을 가장 많이 아끼는 방법이었습니다.
모니터링 모드를 처음부터 적극적으로 활용한다.
앞서 말한 디버깅 방식의 차이 때문에 초반엔 모니터링 기능을 거의 안 썼는데, 나중에 보니 이 기능만 제대로 써도 어느 접점이 살아있고 어느 접점에서 막히는지 실시간으로 눈으로 확인할 수 있었습니다. 소프트웨어의 디버거에 해당하는 기능이라고 생각하고 처음부터 익혀뒀다면 초반 시행착오를 훨씬 줄일 수 있었을 겁니다.
작은 목표를 스스로 정해서 완성해보는 경험이 중요합니다. 이론만 계속 읽으면 진도가 나가는 것 같아도 실제로 손에 익지 않았습니다. "버튼 하나로 램프 켜고 끄기", "3초 뒤에 자동으로 꺼지게 하기"처럼 작더라도 스스로 정한 목표를 끝까지 완성해보는 경험이, 두꺼운 이론서 한 권을 읽는 것보다 체감상 훨씬 크게 도움이 됐습니다.
아직 갈 길이 멀지만, 소프트웨어 개발과는 전혀 다른 사고방식을 요구하는 PLC를 조금씩 이해해가는 과정 자체가 꽤 흥미롭습니다. 특히 스캔 방식이라는 개념 하나를 제대로 이해하고 나니, 그 이후에 배운 인터록이나 순차 제어 같은 개념들도 훨씬 수월하게 받아들여졌습니다. 결국 기초 개념 하나를 제대로 짚고 넘어가는 게, 여러 응용 예제를 얕게 훑는 것보다 훨씬 효율적인 학습 방법이라는 걸 다시 한번 느꼈습니다. 조급하게 진도를 나가기보다, 막힌 부분에서 충분히 헤매보는 시간도 결국은 필요한 과정이었던 것 같습니다. 다음 글에서는 실제 소형 PLC로 컨베이어 벨트 정지/기동 시뮬레이션을 만들어본 경험을 좀 더 구체적으로 다뤄보겠습니다.