여러분, 혹시 열심히 작업하고 있는데 갑자기 시스템이 멈추거나, 예상치 못한 오류 메시지를 마주하고 식은땀을 흘려본 경험 있으신가요? 특히 데이터베이스나 복잡한 시스템을 다루는 분들이라면 ‘STATUS_INVALID_LOCK_SEQUENCE’ 같은 알 수 없는 코드에 당황했던 기억이 분명 있을 거예요.
저도 예전에 비슷한 문제로 밤샘 작업을 해본 적이 있어서 그 답답함을 누구보다 잘 이해합니다. 이런 종류의 오류는 단순히 프로그램이 멈추는 것을 넘어, 중요한 데이터가 손상되거나 시스템 전체의 안정성을 위협할 수 있기 때문에 결코 가볍게 볼 수 없죠. 최근에는 클라우드 환경이나 대규모 분산 시스템이 일반화되면서 여러 작업이 동시에 진행될 때 락(Lock)의 순서가 꼬이는 경우가 더욱 빈번하게 발생하고 있는데요, 이 문제를 제대로 이해하고 해결하는 것이 그 어느 때보다 중요해졌습니다.
단순한 코드 오류처럼 보이지만, 사실 시스템의 핵심적인 동작과 밀접하게 연결되어 있답니다. 이 골치 아픈 ‘STATUS_INVALID_LOCK_SEQUENCE’가 도대체 무엇이고, 왜 발생하는지, 그리고 어떻게 대처해야 하는지에 대해 아래 글에서 확실히 알려드릴게요!
엉뚱한 락 순서, 시스템을 멈추게 하는 주범은?
락(Lock)이 도대체 뭐길래?
여러분, 우리가 평소에 사용하는 시스템은 마치 수많은 사람이 동시에 책을 빌리고, 쓰고, 반납하는 도서관과 같아요. 여러 사용자가 동시에 같은 자료(데이터)에 접근하려고 할 때, 혼란이 발생하지 않도록 규칙이 필요하겠죠? 이때 등장하는 개념이 바로 ‘락(Lock)’입니다.
락은 특정 데이터에 대한 접근을 일시적으로 제한해서 데이터가 엉망진창이 되는 걸 막아주는 중요한 장치예요. 예를 들어, 은행에서 계좌 이체를 할 때 송금 계좌에서 돈이 빠져나가고 수신 계좌로 돈이 들어오는 과정이 완벽하게 동기화되어야 하잖아요? 만약 락이 없다면, 동시에 여러 거래가 발생해서 계좌 잔액이 맞지 않는 황당한 일이 벌어질 수도 있어요.
락은 이런 데이터 불일치나 손상을 방지하고, 시스템의 무결성과 안정성을 지키는 핵심적인 역할을 한답니다. 마치 ‘잠시만요! 제가 이 책을 읽는 동안은 아무도 수정하지 말아 주세요!’라고 외치는 것과 같아요.
그런데 이런 중요한 락에도 문제가 생길 수 있다는 거 아세요? 바로 ‘STATUS_INVALID_LOCK_SEQUENCE’ 같은 오류가 그 예시죠.
어긋난 순서가 불러오는 대혼란
‘STATUS_INVALID_LOCK_SEQUENCE’ 오류는 말 그대로 락을 획득하고 해제하는 순서가 잘못되었을 때 발생해요. 시스템이 정해진 규칙대로 락을 걸고 풀어야 하는데, 이 순서가 꼬이면 전체 작업 흐름이 멈춰버리는 거죠. 예를 들어, 컴퓨터를 켜고 끄는 과정이 정해져 있는데, 끄는 버튼을 먼저 누른다거나, 잠금장치를 풀지 않고 문을 열려고 하는 것과 비슷하다고 볼 수 있어요.
특히 여러 프로세스가 동시에 데이터를 사용하려고 하거나, 복잡한 분산 환경에서는 이런 순서 오류가 더 자주 발생할 수 있어요. 제가 예전에 금융 시스템을 개발할 때 비슷한 경험을 했는데, 동시에 여러 사용자가 주식 거래를 시도하면서 락 순서가 뒤죽박죽이 되어 서버 전체가 멈춘 적이 있었어요.
정말 식은땀이 줄줄 흐르더라고요. 이 오류는 단순한 경고가 아니라, 시스템의 핵심 로직에 심각한 문제가 생겼다는 경고등이라고 생각해야 합니다. 잘못된 락 순서는 데드락(Deadlock) 같은 더 심각한 문제로 이어질 수 있는데, 이는 여러 작업이 서로의 락이 풀리기를 기다리며 무한 대기하는 상태를 말해요.
마치 두 사람이 좁은 길에서 서로 비키기를 기다리다 꼼짝 못 하는 상황과 똑같죠.
‘STATUS_INVALID_LOCK_SEQUENCE’ 오류는 왜 생기는 걸까?
엇갈린 트랜잭션, 비극의 시작
이 오류가 발생하는 가장 흔한 원인 중 하나는 여러 트랜잭션이 동시에 같은 자원에 접근하면서 락을 획득하는 순서가 꼬이는 거예요. 트랜잭션이란 데이터베이스에서 하나의 논리적인 작업을 수행하는 단위인데, 예를 들어 아까 말씀드린 계좌 이체가 하나의 트랜잭션이 될 수 있죠.
만약 두 개의 트랜잭션이 각각 A 자원과 B 자원을 필요로 하는데, 한 트랜잭션은 A 락을 먼저 잡고 B 락을 잡으려 하고, 다른 트랜잭션은 B 락을 먼저 잡고 A 락을 잡으려 한다면 어떻게 될까요? 서로가 원하는 락을 놓아주지 않으면서 시스템이 꼼짝 못 하게 됩니다.
이게 바로 데드락의 전형적인 모습이에요. 제가 경험했던 주식 거래 시스템도 이런 상황이었어요. 짧은 시간 안에 수많은 매수/매도 트랜잭션이 동시에 특정 종목의 데이터를 건드리면서 락 순서가 꼬였고, 결국 시스템이 마비되었죠.
이런 상황은 정말 예측하기 어렵고 디버깅하기도 까다로워서 개발자들을 멘붕에 빠뜨리곤 합니다.
개발자의 작은 실수, 시스템의 큰 장애
때로는 개발자의 코드 실수도 큰 영향을 미칩니다. 락을 걸고 해제하는 로직을 잘못 구현했거나, 락의 범위를 너무 넓게 또는 너무 좁게 설정했을 때 문제가 생길 수 있어요. 예를 들어, 특정 데이터에 대한 락을 잡아야 하는데, 실수로 전혀 다른 데이터에 락을 걸었다거나, 혹은 락을 잡았으면 반드시 풀어야 하는데 그렇지 않은 경우도 있겠죠.
이렇게 락이 제대로 해제되지 않으면, 다른 트랜잭션들이 계속 기다리게 되면서 결국 시스템 전체가 느려지거나 멈춰버릴 수 있어요. 저는 초보 시절에 락을 잡는 로직을 반복문 안에 넣었다가 엄청난 수의 락이 동시에 걸리면서 서버가 먹통이 된 적도 있었어요. 그때는 정말 땅을 치고 후회했죠.
작은 코드 한 줄이 얼마나 큰 파급력을 가질 수 있는지 뼈저리게 느꼈답니다. 특히 분산 시스템에서는 여러 서버나 서비스 간에 락을 공유하고 관리해야 하는데, 이때 동기화 문제가 발생하면 더 복잡한 오류가 발생할 수 있습니다.
락 순서 오류, 데이터 무결성을 위협하다
깨진 데이터, 복구는 가능한가?
‘STATUS_INVALID_LOCK_SEQUENCE’ 오류가 심각한 이유는 단순히 시스템이 멈추는 것을 넘어, 중요한 데이터의 무결성을 해칠 수 있기 때문이에요. 락이 제대로 작동하지 않으면 여러 트랜잭션이 동시에 같은 데이터를 수정하게 될 수 있고, 이 과정에서 데이터가 손상되거나 예측 불가능한 값으로 변경될 수 있어요.
예를 들어, 온라인 쇼핑몰에서 상품 재고를 관리하는데, 동시에 여러 고객이 마지막 남은 상품을 구매하려고 할 때 락이 제대로 걸리지 않으면 실제 재고는 1 개인데 2 명에게 판매되는 사태가 발생할 수 있죠. 이렇게 되면 고객 불만은 물론이고, 재고 데이터가 엉망이 되어 시스템 전체의 신뢰도가 바닥으로 떨어지게 됩니다.
잘못된 데이터는 결국 비즈니스에 치명적인 손실을 가져올 수 있기 때문에, 이 오류는 반드시 초기에 진단하고 해결해야 합니다.
성능 저하와 시스템 불안정의 그림자
락 순서 오류는 또한 시스템의 전반적인 성능 저하와 불안정성을 야기합니다. 락 경합이 심해지면 트랜잭션들이 락을 획득하기 위해 대기하는 시간이 길어지고, 이는 전체 처리 속도를 현저히 떨어뜨려요. 제가 과거에 경험했던 시스템도 오류 발생 전부터 응답 시간이 눈에 띄게 느려지는 징후가 있었어요. 사용자들은 시스템이 느리다고 불평했고, 결국 오류가 터지고 나서야 문제의 심각성을 깨달았죠. 특히 대규모 트래픽이 발생하는 서비스에서는 이런 성능 저하가 바로 서비스 중단으로 이어질 수 있습니다. 락이 제대로 관리되지 않으면 시스템 자원이 낭비되고, 최악의 경우 시스템 전체가 불안정해지면서 주기적으로 다운되는 상황까지 발생할 수 있어요.
락 순서 오류, 어떻게 해결하고 예방할까?
원인 파악이 핵심: 데드락 탐지 및 분석
이런 오류가 발생했을 때 가장 먼저 해야 할 일은 정확한 원인을 파악하는 거예요. 대부분의 데이터베이스 시스템은 데드락 탐지 기능을 제공하고, 어떤 트랜잭션들이 서로 락을 잡고 대기하고 있는지 정보를 확인할 수 있게 해줍니다. 이 정보를 분석해서 어느 시점에, 어떤 자원(테이블, 행 등)에서 락 경합이 발생했는지 알아내는 것이 중요해요. 마치 범죄 현장에서 단서를 찾는 형사처럼 말이죠. 저도 오류가 터지면 가장 먼저 로그를 뒤지고, 데이터베이스 모니터링 툴을 확인해서 데드락 발생 지점을 찾아냈어요. 이 과정에서 어떤 트랜잭션들이 어떤 순서로 락을 획득하려 했는지 명확히 파악하는 것이 해결의 실마리가 됩니다.
락 전략 재정비: 비관적 락 vs. 낙관적 락
락 순서 오류를 해결하고 예방하기 위해서는 락 전략을 신중하게 검토하고 적용해야 합니다. 크게 ‘비관적 락(Pessimistic Lock)’과 ‘낙관적 락(Optimistic Lock)’ 두 가지 방식이 있어요.
| 구분 | 비관적 락 (Pessimistic Lock) | 낙관적 락 (Optimistic Lock) |
|---|---|---|
| 개념 | 데이터 충돌이 자주 발생할 것이라 예상하고, 데이터를 읽는 순간 락을 걸어 다른 트랜잭션의 접근을 차단해요. | 데이터 충돌이 드물 것이라 가정하고, 락을 걸지 않고 진행하다가 데이터 수정 시점에 충돌 여부를 확인해요. |
| 장점 | 데이터 무결성 강력 보장, 확실한 동기화. | 읽기 작업이 많을 때 성능 우수, 락 대기 시간 없음. |
| 단점 | 락 경합 시 성능 저하 및 데드락 발생 가능성. | 충돌 시 재시도 로직 필요, 데이터 정합성 보장이 상대적으로 약함. |
| 주요 활용 | 금융 시스템처럼 데이터 일관성이 절대적으로 중요한 환경. | 게시판 조회수 증가처럼 읽기 빈도가 높은 환경. |
보통 데이터의 일관성이 매우 중요하고 충돌이 잦을 것으로 예상되는 은행 시스템 등에서는 비관적 락을 사용하고, 읽기 작업이 압도적으로 많고 충돌 가능성이 낮은 환경에서는 낙관적 락을 사용하는 것이 일반적입니다. 제가 개발했던 금융 시스템에서는 중요 거래에 비관적 락을 신중하게 적용하고, 조회성 데이터에는 낙관적 락을 활용해서 균형을 맞췄어요. 중요한 건 우리 시스템의 특성에 맞춰 어떤 락 전략이 가장 적합할지 신중하게 결정하는 겁니다.
시스템 안정성을 높이는 현명한 락 관리
일관된 락 획득 순서 지키기
락 순서 오류를 예방하는 가장 기본적인 원칙은 ‘일관된 락 획득 순서’를 지키는 거예요. 시스템 내의 모든 트랜잭션이 여러 자원에 락을 걸어야 할 때, 항상 동일한 순서로 락을 획득하도록 규칙을 정하고 이를 철저히 따르는 거죠. 예를 들어, A, B, C 세 자원에 락을 걸어야 한다면, 어떤 트랜잭션이든 항상 A -> B -> C 순서로 락을 잡고, 반대로 풀 때는 C -> B -> A 순서로 푸는 식으로요. 이렇게 하면 락 경합으로 인한 데드락 발생 가능성을 크게 줄일 수 있습니다. 제가 일하던 곳에서는 모든 개발자가 이 락 획득 순서 규칙을 공유하고 코드 리뷰 시에도 항상 확인하는 과정을 거쳤어요. 처음엔 좀 귀찮게 느껴졌지만, 덕분에 치명적인 데드락을 여러 번 피할 수 있었답니다.
트랜잭션 범위 최소화와 타임아웃 설정
락이 걸리는 시간을 최소화하는 것도 매우 중요해요. 불필요하게 긴 시간 동안 락을 잡고 있으면 다른 트랜잭션들이 대기하면서 병목 현상이 발생하고, 결국 락 순서 오류나 데드락으로 이어질 가능성이 커지거든요. 따라서 트랜잭션의 범위를 가능한 한 작게 유지하고, 필요한 시점에만 락을 획득해서 작업이 끝나면 즉시 해제하는 것이 좋아요. 그리고 또 하나, 락 타임아웃을 설정하는 것도 현명한 방법이에요. 만약 어떤 락이 예상보다 오랫동안 해제되지 않거나, 데드락이 발생해서 무한정 대기하는 상황이 발생할 경우, 일정 시간이 지나면 자동으로 락을 해제하거나 트랜잭션을 취소하도록 설정하는 거죠. 이렇게 하면 시스템이 완전히 멈추는 최악의 상황은 피하고, 최소한의 복구라도 가능하게 할 수 있습니다.
미래를 위한 시스템, 꾸준한 모니터링과 튜닝
이상 징후, 놓치지 않을 거예요!
시스템은 살아있는 생물과 같아서 늘 관심을 기울여야 해요. 특히 락 관련 문제는 갑자기 터지기보다는, 서서히 징후를 보이면서 나타나는 경우가 많아요. 평소보다 시스템 응답이 느려진다거나, 특정 작업의 완료 시간이 길어진다거나 하는 이상 징후들을 꾸준히 모니터링해야 합니다. 데이터베이스에서 제공하는 성능 모니터링 도구를 활용해서 락 대기 시간, 데드락 발생 횟수 등을 주기적으로 확인하는 것이 좋아요. 저도 매일 아침 출근하면 가장 먼저 시스템 대시보드를 확인하면서 이런 지표들을 체크하는 습관이 생겼어요. 혹시라도 뭔가 이상한 점이 발견되면, 바로 전문가들과 논의해서 선제적으로 대응하는 것이 큰 사고를 막는 지름길입니다.
최적화를 통한 시스템 튜닝
마지막으로, 락 관련 문제를 줄이기 위해서는 지속적인 시스템 튜닝이 필수적입니다. 불필요한 락을 줄이거나, 락의 범위를 최적화하는 방법들을 고민해야 해요. 인덱스를 적절히 사용해서 데이터 접근 속도를 높이거나, 쿼리를 최적화해서 트랜잭션 시간을 단축하는 것도 락 경합을 줄이는 데 큰 도움이 됩니다. 때로는 아예 락 없이 동시성을 처리하는 방법인 ‘MVCC(Multi-Version Concurrency Control)’ 같은 대안 기술을 도입하는 것을 고려해볼 수도 있어요. 물론 모든 시스템에 정답이 하나로 정해져 있는 건 아니지만, 우리 시스템의 특성과 요구사항에 맞춰 가장 효율적인 방법을 찾아 나가는 과정이 중요합니다. 끊임없이 개선하고 발전시키려는 노력이 바로 안정적인 서비스를 만들어내는 원동력이 된다는 것을 잊지 마세요!
글을 마치며
오늘은 시스템 안정성의 숨겨진 영웅이자 때로는 골칫덩이가 되는 ‘락(Lock)’에 대해 이야기해 보았어요. 특히 ‘STATUS_INVALID_LOCK_SEQUENCE’ 같은 오류가 발생했을 때 우리가 왜 이 문제에 주목해야 하는지, 그리고 어떻게 해결하고 예방할 수 있는지 저의 경험을 녹여 설명해 드렸는데요. 복잡해 보이지만 결국 일관된 규칙과 꾸준한 관심이 시스템의 건강을 지키는 가장 중요한 요소라는 것을 다시 한번 깨닫게 됩니다. 우리 시스템이 언제나 쾌적하게 잘 작동하도록, 락 관리에 조금 더 신경 써보는 건 어떨까요?
알아두면 쓸모 있는 정보
1. 락은 여러 사용자가 동시에 데이터를 안전하게 공유할 수 있도록 돕는 핵심 장치입니다. 시스템 무결성과 안정성을 위해 없어서는 안 될 존재죠.
2. ‘STATUS_INVALID_LOCK_SEQUENCE’ 오류는 락 획득 순서가 어긋나 데드락이나 시스템 마비로 이어질 수 있는 위험 신호예요. 절대 간과해서는 안 됩니다.
3. 비관적 락은 강력한 데이터 일관성을 보장하지만 성능 저하 가능성이 있고, 낙관적 락은 읽기 성능이 좋지만 충돌 시 재시도 로직이 필요하니 시스템 특성에 맞게 선택해야 해요.
4. 락 순서 오류를 예방하려면 모든 트랜잭션이 동일한 락 획득 순서를 따르도록 규칙을 정하고, 락이 걸리는 시간(트랜잭션 범위)을 최소화하는 것이 중요합니다.
5. 주기적인 시스템 모니터링과 성능 튜닝은 락 관련 문제를 사전에 감지하고 해결하여 서비스 중단을 막는 가장 현명한 방법이에요. 평소 작은 징후라도 놓치지 않는 것이 핵심이랍니다.
중요 사항 정리
우리가 사용하는 모든 시스템은 데이터의 동시성을 안전하게 관리해야 해요. 특히 ‘STATUS_INVALID_LOCK_SEQUENCE’와 같은 락 순서 오류는 단순히 시스템을 멈추게 하는 것을 넘어, 데이터 무결성을 심각하게 훼손하고 전반적인 성능 저하를 야기할 수 있는 치명적인 문제입니다. 이 오류를 해결하고 예방하기 위해서는 먼저 정확한 원인을 파악하는 것이 중요하며, 시스템의 특성과 요구사항에 맞춰 비관적 락이나 낙관적 락과 같은 적절한 락 전략을 선택해야 합니다. 더불어 모든 개발자가 일관된 락 획득 순서 규칙을 철저히 지키고, 트랜잭션 범위를 최소화하며 락 타임아웃을 설정하는 등의 노력은 데드락 발생 가능성을 크게 줄여줍니다. 마지막으로, 시스템은 살아있는 생명체와 같아서 늘 꾸준한 모니터링과 성능 튜닝을 통해 이상 징후를 조기에 발견하고 선제적으로 대응하는 것이 중요해요. 이런 체계적인 락 관리만이 사용자에게 최고의 경험을 제공하는 안정적이고 신뢰할 수 있는 서비스를 만들어낼 수 있음을 잊지 말아야 합니다.
자주 묻는 질문 (FAQ) 📖
질문: “STATUSINVALIDLOCKSEQUENCE” 오류는 정확히 무엇이고, 이게 왜 그렇게 중요한 문제로 다뤄지는 건가요?
답변: 여러분, 이 길고 복잡한 이름의 오류를 마주하면 저처럼 머리가 지끈거릴 거예요. ‘STATUSINVALIDLOCKSEQUENCE’는 쉽게 말해, 시스템이 여러 작업을 동시에 처리할 때 사용하는 ‘잠금(Lock)’이 올바른 순서나 방식으로 작동하지 않았다는 신호예요. 마치 여러 사람이 한 문을 통과해야 하는데, 누가 먼저 들어가고 나갈지 규칙이 엉켜서 다들 문 앞에서 옴짝달싹 못 하는 상황과 비슷하죠.
데이터베이스나 중요한 시스템에서는 데이터 일관성을 유지하기 위해 특정 데이터에 접근하는 순서를 잠금으로 제어하거든요. 그런데 이 잠금 순서가 꼬이거나, 이미 잠겨있어야 할 것이 잠겨있지 않거나, 반대로 해제되어야 할 것이 잠겨있는 등 ‘유효하지 않은’ 상태가 되면 문제가 발생해요.
이게 중요한 이유는 단순히 프로그램이 멈추는 것을 넘어, 잘못된 데이터가 저장되거나 중요한 정보가 유실될 수도 있기 때문이에요. 심하면 시스템 전체가 먹통이 될 수도 있고요. 제가 예전에 한 프로젝트에서 이런 오류 때문에 새벽까지 로그만 들여다봤던 기억이 있는데, 정말 아찔했답니다.
질문: 이런 ‘락 시퀀스’ 문제가 발생하는 주된 원인은 무엇이고, 어떤 상황에서 특히 조심해야 할까요?
답변: ‘STATUSINVALIDLOCKSEQUENCE’ 오류가 발생하는 원인은 정말 다양한데요, 대부분은 여러 프로세스나 스레드가 동시에 같은 자원에 접근하려 할 때 발생해요. 예를 들어, 데이터베이스에서 동시에 여러 사용자가 같은 테이블의 데이터를 수정하려고 할 때, 잠금 메커니즘이 제대로 작동하지 않으면 이런 오류가 뜰 수 있죠.
가장 흔한 원인 중 하나는 ‘교착 상태(Deadlock)’예요. 이건 마치 두 사람이 서로 상대방이 가진 것을 기다리느라 아무것도 못 하는 상황과 같아요. 또 다른 원인은 잠금을 획득하고 해제하는 순서가 잘못되었을 때예요.
A를 잠그고 B를 잠근 다음, B를 해제하고 A를 해제해야 하는데, 실수로 순서가 바뀌거나 중간에 잠금 해제를 빼먹으면 오류가 터지는 거죠. 분산 시스템이나 클라우드 환경처럼 복잡한 구조에서는 더욱 자주 발생할 수 있어요. 여러 서버가 동시에 같은 리소스를 공유할 때 동기화 문제가 생기기 쉽거든요.
특히 트랜잭션 처리가 많은 금융 시스템이나 대용량 데이터 처리 환경에서는 이 부분에 대한 설계와 구현이 정말 중요하다고 느꼈습니다.
질문: ‘STATUSINVALIDLOCKSEQUENCE’ 오류가 발생했을 때 어떻게 대처해야 하고, 애초에 이런 오류를 예방하려면 어떤 노력을 해야 할까요?
답변: 만약 이 오류를 마주했다면, 너무 당황하지 마세요! 일단 가장 먼저 해야 할 일은 시스템 로그를 꼼꼼히 살펴보는 거예요. 로그에는 어떤 잠금에서 문제가 발생했는지, 그리고 어떤 프로세스들이 관련되어 있는지 힌트가 들어있을 확률이 높거든요.
저도 예전에 로그에서 특정 트랜잭션 ID를 찾아내서 원인을 파악했던 경험이 있어요. 해결을 위해서는 문제가 되는 잠금을 강제로 해제하거나, 시스템을 재시작하여 잠금 상태를 초기화하는 방법도 있지만, 이는 데이터 유실의 위험이 있으니 신중하게 접근해야 해요. 가장 좋은 방법은 예방입니다!
소프트웨어 개발 단계부터 ‘동시성 제어(Concurrency Control)’를 염두에 두고 설계해야 해요. 예를 들어, 데이터베이스 트랜잭션의 ‘격리 수준’을 적절히 설정하거나, 잠금 메커니즘을 더욱 견고하게 구현하는 거죠. 특히 여러 단계의 잠금이 필요한 경우, 정해진 순서대로 잠금을 획득하고 해제하는 ‘잠금 계층(Lock Hierarchy)’을 잘 설계하는 것이 핵심이에요.
그리고 주기적으로 코드 리뷰를 통해 잠금 관련 로직에 실수는 없는지 확인하고, 스트레스 테스트를 통해 시스템이 부하를 받았을 때도 잠금이 제대로 작동하는지 검증하는 것이 정말 중요해요. 저도 이런 문제 예방을 위해 개발 단계부터 꼼꼼히 설계에 참여하려고 노력한답니다.