예로 드신 소켓접속 같은 경우 사용자 라이브러리로 처리하는 것이 더 낫긴 합니다.
만약 소켓접속이 빈번하게 사용되는 경우가 아니라면(일부 한정된 컨트롤러에서 사용되는 경우라면)
모델에 넣고 사용하는 것도 방법입니다.
사이트 전반에 걸쳐 사용이 된다면 라이브러리화 하는 것이 맞구요. ^^

MVC 로 나누는것 자체가 추상레벨에서 모듈화 한다는것이고, 그 이유가 프로그램의 복잡도를 감소시키기 위해서 라고 봅니다.
소스코드 레벨에서는 사실상 좀 더 코드가 길어지거나 복잡해 질 수도 있지만, 전체 프로그램을 조망해 보면 좀 3등분으로 나누어져 있으므로 한번에 신경써야 하는부분이 작아지는 효과가 있습니다.  
질문 하신부분에 대한 제 생각은 Model에는 Database  연동코드만 들어갈 필요는 없지만, model의 역할에 대해 일반적으로 기대하는부분만 들어가야 합니다.
Database 이든 text 이든 data를 저장하고 읽어오는것에 관련된 코드만 model 에 넣어야지 향후 데이터 관련 코드는 model 쪽 소스코드만 보면 된다 라는 MVC의 효과를 누릴수 있지, 다른 용도의 코드까지들어간다면 model을 별도로 분리하는 의미가 퇴색하게 됩니다.

MVC의 긍정적인 효과는 프로그램이 복잡해 질 수록 더 커진다고 생각합니다.

원론적인 이야기라 도움이 되실지 모르겠지만 혹시 다른분들께라도 도움이 될까하여 올려봅니다.

감사합니다!!

MVC패턴이란게.. 사실 정답이란게 없는것 같습니다. 또, 작업을 하다보면 더우기 M,V,C를 나누기가 참 모호할 경우가 종종 있습니다..

개발에서 뭐가, 누가 정답이기는 사실 어렵겠죠.. 서로의 장단점은 늘 존재하는 것이니까요...

용운님 말씀따라.. 점점 개발을 하면서 점점 더 멀찌감치에서 바라보게 되는 것 같습니다. 아직 멀었지만서도용...

OOP, MVC를 막론하고.. 넓게 같이 봐보아용~

재밌는 생각이네요.

예를 들어 블로그를 만들때 Posts 라는 모델이 있고 이 모델은 get_posts, save_post 등의 메소드를 가지고 있다고 하죠. 처음에는 데이터베이스가 입출력을 담당했지만, 서비스 중간에 데이터베이스로부터 원격지의 서버에 openapi를 이용하여 포스트를 가져오거나 저장하는 로직으로 바뀌었다면... 저라면 model에 말씀하신 소켓 부분을 넣겠습니다.  만약 이 부분을 라이브러리로 뺀다면 컨트롤러를 수정해야 할 필요가 있게 되지 않을까요?

라이브러리->모델 또는 모델->라이브러리로 바꾸는 경우는 어쨌든 작업을 해야합니다. ^^

부연설명을 하자면 라이브러리 이야기를 한 것은 소켓통신이 그 사이트(서비스)의 큰 근간일 경우이고
해당 컨트롤러에서만 사용될 수준이라면 모델에 넣는게 낫다는 거죠. ^^

 kirrie 님의 말씀처럼 그런상황이라면 소켓통신은 당연히 model에서 구현되어야 한다는 생각입니다.

model 안에서 data를 처리할때 database를 이용한다면 data 처리하는 api를 사용할테고, file을 사용한다면 file핸들링 api를 내부적으로 사용하겠지요. 상황에 따라 말씀하신대로 openapi를 사용할 때도 있을것이고 때에따라서는 webservice등을 사용할 수도 있고 등등..
model 안에서 어떤 라이브러리를 써서 데이터를 처리하든 그것이 model의 역할에 필요하다면 당연히 model에 들어가야 합니다. 

제가 생각하는 중요한 부분은 model 은 개념적으로 data를 핸들링 한다는 "기대"를 만족시켜야 한다는 점입니다.

그렇게 될때 model을 호출하는 CONTROLLER 는 model이 내부적으로 어떠한 방법으로 data를 핸들링 하든, 항상 save(data); 식으로 데이터를 핸들링 할 수 있고 model과 controller를 분리하는 잇점이 유효하게 되는거라고 봅니다.