프레임워크: 두 판 사이의 차이
편집 요약 없음 |
|||
| 6번째 줄: | 6번째 줄: | ||
또한 많은 응용프로그램은 비슷비슷한 패턴을 가지고 있다. 예를 들어 웹 프로그램은 사용자의 요청이 들어오면 [[데이터베이스]]에서 데이터를 꺼내오고 이를 적당히 가공해서 사용자에게 HTML 형식으로 응답을 보내준다. 때로는 사용자의 요청으로부터 데이터를 받아서 [[데이터베이스]]에 새로 데이터를 넣거나 기존 데이터를 업데이트할 수도 있다. 많은 프로그램들은 이러한 과정이 많이 닮아 있다. 만약 어떤 뛰어난 프로그래머가 이를 패턴화하여 공통으로 쓸 수 있는 코드를 만들고, 실제 프로그램을 만드는 개발자는 이 코드에 자신이 구현하고자 하는 기능만 얹으면 개발에 들어가는 시간과 노력을 대폭 단축할 수 있을 것이다. 예를 들어 [[피자]]를 만들 때, 그 기반이 되는 밀가루 빵, 즉 도우는 미리 만들어 늫은 다음에 내가 먹고 싶은 토핑만 얹으면 [[피자]]를 만드는 데 드는 시간도 크게 단축될 것이고, [[밀가루]]를 반죽하고 [[발효]]시키고 빙빙 돌려가면서 원판 모양으로 만들려면 시간과 노력은 물론 상당한 기술도 필요한데 이런 것도 생략할 수 있다. 도우를 만드는 기술과 토핑 뿌리는 기술을 생각해 보면 누가 봐도 토핑이 훨씬 쉽다. | 또한 많은 응용프로그램은 비슷비슷한 패턴을 가지고 있다. 예를 들어 웹 프로그램은 사용자의 요청이 들어오면 [[데이터베이스]]에서 데이터를 꺼내오고 이를 적당히 가공해서 사용자에게 HTML 형식으로 응답을 보내준다. 때로는 사용자의 요청으로부터 데이터를 받아서 [[데이터베이스]]에 새로 데이터를 넣거나 기존 데이터를 업데이트할 수도 있다. 많은 프로그램들은 이러한 과정이 많이 닮아 있다. 만약 어떤 뛰어난 프로그래머가 이를 패턴화하여 공통으로 쓸 수 있는 코드를 만들고, 실제 프로그램을 만드는 개발자는 이 코드에 자신이 구현하고자 하는 기능만 얹으면 개발에 들어가는 시간과 노력을 대폭 단축할 수 있을 것이다. 예를 들어 [[피자]]를 만들 때, 그 기반이 되는 밀가루 빵, 즉 도우는 미리 만들어 늫은 다음에 내가 먹고 싶은 토핑만 얹으면 [[피자]]를 만드는 데 드는 시간도 크게 단축될 것이고, [[밀가루]]를 반죽하고 [[발효]]시키고 빙빙 돌려가면서 원판 모양으로 만들려면 시간과 노력은 물론 상당한 기술도 필요한데 이런 것도 생략할 수 있다. 도우를 만드는 기술과 토핑 뿌리는 기술을 생각해 보면 누가 봐도 토핑이 훨씬 쉽다. | ||
==장점== | |||
프레임워크를 사용함으로써 개발자는 응용프로그램을 만들 때마다 작성해야 하는 많은 양의 비슷비슷한 코드, 이른바 보일러플레이트 코드를 크게 줄일 수 있다. 따라서 자신이 구현하고자 하는 기능에 더 많이 집중하고 시간을 쓸 수 있다. 또한 잘 만든 프레임워크는 응용프로그램을 효과적으로 만들 수 있는 좋은 패턴을 제공해 주므로, 이러한 패턴을 따라가면 경험이나 실력이 아직 충분하지 않은 개발자도 효율이 좋은 코드를 만들 수 있다. 여기에 더해 프레임워크는 많은 테스트를 거치고 계속해서 사용자의 피드백을 받아서 문제점을 개선하므로 버그가 적다. 만약 프레임워크를 사용하지 않고 직접 다 코드를 짰다면 어마어마한 버그에 시달렸을 텐데 적어도 프레임워크에 해당하는 코드는 직접 짰을 때와 비교하면 버그가 큰 폭으로 적을 것이다. | 프레임워크를 사용함으로써 개발자는 응용프로그램을 만들 때마다 작성해야 하는 많은 양의 비슷비슷한 코드, 이른바 보일러플레이트 코드를 크게 줄일 수 있다. 따라서 자신이 구현하고자 하는 기능에 더 많이 집중하고 시간을 쓸 수 있다. 또한 잘 만든 프레임워크는 응용프로그램을 효과적으로 만들 수 있는 좋은 패턴을 제공해 주므로, 이러한 패턴을 따라가면 경험이나 실력이 아직 충분하지 않은 개발자도 효율이 좋은 코드를 만들 수 있다. 여기에 더해 프레임워크는 많은 테스트를 거치고 계속해서 사용자의 피드백을 받아서 문제점을 개선하므로 버그가 적다. 만약 프레임워크를 사용하지 않고 직접 다 코드를 짰다면 어마어마한 버그에 시달렸을 텐데 적어도 프레임워크에 해당하는 코드는 직접 짰을 때와 비교하면 버그가 큰 폭으로 적을 것이다. | ||
==단점== | |||
물론 반대급부도 있다. 최적화라는 측면에서 본다면 직접 바닥부터 코드를 짰을 때와 비교했을 때 프레임워크는 불필요한 코드가 들어갈 가능성이 높다. 프레임워크는 광범위한 응용프로그램에 사용될 것을 전제로 하고 만들기 때문에 개별 프로그램의 관점으로 보면 자신에게는 필요 없는 코드가 들어가 있을 가능성이 높다. 따라서 불필요한 코드 때문에 프로그램의 덩치가 커지거나, 속도가 느려지거나 할 수 있다. 이른바 '맥가이버 칼'로 알려진 스위스 아미 나이프는 여러 가지 공구가 들어 있기 때문에 그거 하나만 가지고 다니면 여러 가지 작업에 사용할 수 있지만 개개의 도구만으로 놓고 보면 전용 공구보다는 떨어지며 그 중에 일부만 사용하는 사람들이라면 불필요한 공구까지 함께 가지고 다녀야 한다. 범용성을 추구할수록 공구의 종류가 많아지므로 일부 도구만 사용하는 사람들은 더더욱 불편해진다. 예를 들어 드라이버와 나이프만 사용하는 사람이라면 8개 공구가 들어 있는 거나 12개 공구가 들어 있는 거나 사용하는 건 두 가지 뿐인데 12개 공구는 훨씬 불편할 것이다. | 물론 반대급부도 있다. 최적화라는 측면에서 본다면 직접 바닥부터 코드를 짰을 때와 비교했을 때 프레임워크는 불필요한 코드가 들어갈 가능성이 높다. 프레임워크는 광범위한 응용프로그램에 사용될 것을 전제로 하고 만들기 때문에 개별 프로그램의 관점으로 보면 자신에게는 필요 없는 코드가 들어가 있을 가능성이 높다. 따라서 불필요한 코드 때문에 프로그램의 덩치가 커지거나, 속도가 느려지거나 할 수 있다. 이른바 '맥가이버 칼'로 알려진 스위스 아미 나이프는 여러 가지 공구가 들어 있기 때문에 그거 하나만 가지고 다니면 여러 가지 작업에 사용할 수 있지만 개개의 도구만으로 놓고 보면 전용 공구보다는 떨어지며 그 중에 일부만 사용하는 사람들이라면 불필요한 공구까지 함께 가지고 다녀야 한다. 범용성을 추구할수록 공구의 종류가 많아지므로 일부 도구만 사용하는 사람들은 더더욱 불편해진다. 예를 들어 드라이버와 나이프만 사용하는 사람이라면 8개 공구가 들어 있는 거나 12개 공구가 들어 있는 거나 사용하는 건 두 가지 뿐인데 12개 공구는 훨씬 불편할 것이다. | ||
2021년 10월 11일 (월) 11:54 판
Framework.
사전에서는 '뼈대, 틀, 체계'와 같은 의미로 설명하는 단어다. 컴퓨터 소프트웨어에서 많이 쓰이는 용어로, 어떤 플랫폼을 기반으로 응용프로그램을 빠르고 간편하게 만들 수 있도록 여러 가지 함수, 클래스, 데이터, 그밖에 필요한 것을 묶어서 제공하는 소프트웨어를 뜻한다. 이는 응용프로그램을 만들기 위한 하나의 틀, 즉 템플릿을 제공한다.
윈도우, 맥, 안드로이드, iOS와 같은 운영체제, 또는 웹과 같은 플랫폼에서 돌아가는 프로그램을 만들려면 많은 양의 코드를 필요로 한다. 'Hello world' 달랑 한 줄을 출력하는 프로그램을 만들려고 해도 바닥부터 직접 만들려고 하면 수백 줄의 코드를 써야 할 수도 있고 추가로 이런 저런 설정 파일까지 작성해야 한다. 여기에 뭔가 쓸만한 기능을 붙이려면 코드의 양은 크게 늘어난다. 그런데 이러한 코드 중에는 중복되는 것도 많고, 새로 프로그램을 만들 때마다 규칙에 따라 똑같은 코드를 수십 수백 줄 씩 작성해야 할 때도 많다. 실제 내가 구현하고 싶은 기능을 위한 코드보다 어떤 플랫폼에서 그 프로그램이 돌아가기 위해서 작성해야 할 코드의 양이 더 많을 때도 비일비재하다.
또한 많은 응용프로그램은 비슷비슷한 패턴을 가지고 있다. 예를 들어 웹 프로그램은 사용자의 요청이 들어오면 데이터베이스에서 데이터를 꺼내오고 이를 적당히 가공해서 사용자에게 HTML 형식으로 응답을 보내준다. 때로는 사용자의 요청으로부터 데이터를 받아서 데이터베이스에 새로 데이터를 넣거나 기존 데이터를 업데이트할 수도 있다. 많은 프로그램들은 이러한 과정이 많이 닮아 있다. 만약 어떤 뛰어난 프로그래머가 이를 패턴화하여 공통으로 쓸 수 있는 코드를 만들고, 실제 프로그램을 만드는 개발자는 이 코드에 자신이 구현하고자 하는 기능만 얹으면 개발에 들어가는 시간과 노력을 대폭 단축할 수 있을 것이다. 예를 들어 피자를 만들 때, 그 기반이 되는 밀가루 빵, 즉 도우는 미리 만들어 늫은 다음에 내가 먹고 싶은 토핑만 얹으면 피자를 만드는 데 드는 시간도 크게 단축될 것이고, 밀가루를 반죽하고 발효시키고 빙빙 돌려가면서 원판 모양으로 만들려면 시간과 노력은 물론 상당한 기술도 필요한데 이런 것도 생략할 수 있다. 도우를 만드는 기술과 토핑 뿌리는 기술을 생각해 보면 누가 봐도 토핑이 훨씬 쉽다.
장점
프레임워크를 사용함으로써 개발자는 응용프로그램을 만들 때마다 작성해야 하는 많은 양의 비슷비슷한 코드, 이른바 보일러플레이트 코드를 크게 줄일 수 있다. 따라서 자신이 구현하고자 하는 기능에 더 많이 집중하고 시간을 쓸 수 있다. 또한 잘 만든 프레임워크는 응용프로그램을 효과적으로 만들 수 있는 좋은 패턴을 제공해 주므로, 이러한 패턴을 따라가면 경험이나 실력이 아직 충분하지 않은 개발자도 효율이 좋은 코드를 만들 수 있다. 여기에 더해 프레임워크는 많은 테스트를 거치고 계속해서 사용자의 피드백을 받아서 문제점을 개선하므로 버그가 적다. 만약 프레임워크를 사용하지 않고 직접 다 코드를 짰다면 어마어마한 버그에 시달렸을 텐데 적어도 프레임워크에 해당하는 코드는 직접 짰을 때와 비교하면 버그가 큰 폭으로 적을 것이다.
단점
물론 반대급부도 있다. 최적화라는 측면에서 본다면 직접 바닥부터 코드를 짰을 때와 비교했을 때 프레임워크는 불필요한 코드가 들어갈 가능성이 높다. 프레임워크는 광범위한 응용프로그램에 사용될 것을 전제로 하고 만들기 때문에 개별 프로그램의 관점으로 보면 자신에게는 필요 없는 코드가 들어가 있을 가능성이 높다. 따라서 불필요한 코드 때문에 프로그램의 덩치가 커지거나, 속도가 느려지거나 할 수 있다. 이른바 '맥가이버 칼'로 알려진 스위스 아미 나이프는 여러 가지 공구가 들어 있기 때문에 그거 하나만 가지고 다니면 여러 가지 작업에 사용할 수 있지만 개개의 도구만으로 놓고 보면 전용 공구보다는 떨어지며 그 중에 일부만 사용하는 사람들이라면 불필요한 공구까지 함께 가지고 다녀야 한다. 범용성을 추구할수록 공구의 종류가 많아지므로 일부 도구만 사용하는 사람들은 더더욱 불편해진다. 예를 들어 드라이버와 나이프만 사용하는 사람이라면 8개 공구가 들어 있는 거나 12개 공구가 들어 있는 거나 사용하는 건 두 가지 뿐인데 12개 공구는 훨씬 불편할 것이다.
라이브러리와의 차이
라이브러리나 패키지도 클래스, 함수, 데이터가 묶여서 어떤 기능을 제공한다는 점에서는 닮아 있지만 가장 큰 차이점이라면 라이브러리는 어떠한 '기능'을 편리하게 구현할 수 있는 소프트웨어의 묶음이라면 프레임워크는 하나의 완전한 응용프로그램을 만들 수 있을 정도로 각종 기능을 제공하는 묶음이다. 즉 라이브러리는 어떤 프로그램이 필요로 하는 최소 한 가지의 기능만 제공해 주면 되며 그것만으로는 하나의 완전한 응용프로그램을 만들 수 없다.[1] 프레임워크는 하나의 완전한 응용프로그램을 만들 수 있는 각종 기능을 제공하며 따라서 하나의 프레임워크는 거의 대부분 여러 개의 라이브러리를 품고 있다.
각주
- ↑ 어떤 라이브러리가 완전한 응용프로그램을 만들 수 있을 정도로 기능을 제공한다면 이미 프레임워크라고 하지 라이브러리라고 하지 않을 것이다.
