제가 예전에 했던 고민을 지금 하시고 계신거 같네요..
저 또한 웹 개발을 하다가. DBA가 되고 싶어서 오라클을 많이 공부하게 되었지요..

개발자에서 DBA가 된다는거 생각보다 훨씬 어려운거 같습니다.
특히 DBA 경험이 없다는 것이 가장 큰 어려움이었죠.. 개발했던 경험만으로는 한계가 있었던거 같습니다.
물론 DBA 분들이 개발자의 DB 지식을 좀 가볍게 여기는 풍토도 있는거 같고요..

SI 프로젝트에서 사용하는 오라클과 DBA입장에서 사용하는 오라클은 많은 차이가 있습니다.

뻔한 얘기겠지만 많이 공부하는 방법 밖에 없습니다.

오라클 아키텍처가 머리속에 확실히 잡혀 있어야 합니다.
오라클 메모리 구조와 프로세스 구조들, 그리고 논리적 물리적 구조들..
몇 가지 상황에서의 백업과 복구 시나리오를 말 할 수 있는 실력이 되어야 합니다.

SI 프로젝트에는 주어진 업무에 맞게 INSERT/SELECT 문장을 작성하는 것 만으로 끝날지 모르겠지만..
DBA가 되고 싶다면..
INSERT하면 어떤 프로세스를 따라 데이터가 저장되는 것일까
저장된 데이터는 어떤 프로세스에 따라 백업이 되는 것일까.
자동 백업과 수동 백업..어떻게 처리되는 것일까.
백업된 데이터는 어떤 프로세스에 따라 복구가 되는 걸까.

SELECT 할 때도 일반적인 SQL 실행계획도 중요하지만,
SELECT를 효율적으로 하기 위한 메모리 구조, I/O 분산 이런 것에 초점을 맞추어
좀 더 깊이 있게 알려고 하는 노력을 해야 합니다

구체적으로 깊이있게 알려고 노력 하세요..
그리고 SI개발자에게 DBA가 되고 싶다는 것은..
SI 개발도 할 수 있는 상태에서 DBA도 할 수 있는 능력을 키우시겠다는 거니깐..
남 들 보다 두 배 이상 공부 하셔야 합니다.
그냥 남 보다 조금 더 공부하면.. 좀 더 DB를 잘 아는 SI 개발자에서 끝나게 됩니다.

DBA가 되겠다고 결심하고서 가장 어려웠던 점은 장애시 대응 방법이었던거 같습니다.
면접관이 이런 장애가 발생하면 어떻게 대응 할 것인가, 어떻게 모니터링 할 것인가.. 이런 질문들..
참 포괄적이면서도 어려운 문제들 이었던거 같습니다.

주의에 DBA분들이 있다면 그들의 업무를 알려고 많이 관심있게 보세요..
모니터링은 어떤 툴로 하는지, DB 작업할 때 주로 사용하는 스크립트들도 알 수 있으면 좋을 텐데요..

가장 중요한건 자신이 DBA가 되겠다는 확실한 의지를 DB 관련 회사에 보여주는 겁니다.
어떻게든 면접을 보시고요, 꼭 DBA가 되겠다는 의지를 보여주세요..
한 두 번 실패 할지도 모르겠지만요.. 면접 보는 경험이 늘어 날 수록 더욱 더 준비를 잘 할 수 있게 되고 DBA에 점점 더 가까워 집니다.

나중에 DBA가 되신다면 SI  개발자도 잘 아는 DBA가 되기 때문에..
더 잘 할꺼라 생각됩니다.