안녕하세요! 그로스로그 입니다!😊 🌱
같은 일을 하는 두 가지 방법이 있을 때, 무엇을 보고 고를까요. 2기 6회차 세 편입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.
2기 6회차, 2024년 11월 하순입니다. 이번 회차에는 "두 가지 방법"을 나란히 놓고 비교한 글이 세 편 모였어요. 층위가 전혀 다른데도 고민의 모양이 닮았습니다.
01
🗄️ MyBatis, 직접 대입 방식 vs 전자정부 방식
한지수 님
MyBatis로 DB에 접근하는 두 가지 구조를 비교한 글입니다. 컨트롤러에서
SqlSession을 직접 쓰는 방식과, 전자정부 표준프레임워크의 EgovAbstractMapper를 거치는 방식이요.두 방식 각각에 개요 · 예제 코드 · 장단점을 붙였고, 마지막에 다섯 항목짜리 비교표로 정리했습니다.
그리고 결론에서 "어느 쪽이 좋다"가 아니라 어떤 상황에 어느 쪽인지를 적었어요.
조금 더 들어가 보면
🧵 SqlSession이 무슨 일을 하는가
비교로 바로 넘어가지 않고 공통 부품부터 설명하고 시작합니다. 두 방식 모두 결국 SqlSession을 쓰기 때문이에요.
트랜잭션 관리 —
commit 및 rollback 메서드를 통해 트랜잭션 처리를 제어Mapper 인터페이스 연결 —
getMapper() 메서드를 통해 Mapper 인터페이스를 가져올 수 있으며그리고 동작 흐름을 세 단계로 끊었습니다. Mapper 연결 → SQL 실행 → 결과 반환. 특히 첫 단계 설명이 정확해요.
sqlSession.getMapper(Service.class)와 같은 방식으로 Service 인터페이스를 구현하는 프록시 객체를 생성합니다."프록시 객체"라는 단어가 여기서 중요합니다. 우리가 만든 건 인터페이스뿐인데, 구현체 없이도 메서드가 호출되잖아요. MyBatis가 실행 시점에 대신 일해줄 객체를 만들어 끼워 넣기 때문입니다.
그 프록시가 하는 일은 단순합니다. 호출된 메서드 이름을 보고, 같은 이름으로 매핑된 SQL을 XML에서 찾아 실행하는 것. 인터페이스 이름과 XML의 namespace·id가 규칙으로 연결되어 있어서 가능한 구조입니다.
이걸 먼저 짚어둔 덕분에 뒤의 비교가 명확해집니다. 두 방식은 SQL을 다르게 실행하는 게 아니라, SqlSession을 어디서 붙잡느냐가 다를 뿐이거든요.
🏗️ 계층을 나누면 무엇이 달라지나
첫 번째 방식은 컨트롤러에서 곧장 씁니다.
@Controller
public class ExampleController {
@Autowired
private SqlSession sqlSession;
@RequestMapping("/insertExample")
public String insertExample(@RequestParam String name) {
Service service = sqlSession.getMapper(Service.class);
service.insertData(name);
return "redirect:/exampleList";
}
}
한 파일로 끝납니다. 요청을 받고, 매퍼를 꺼내고, 저장하고, 리다이렉트까지요.
두 번째 방식은 같은 일을 하는 데 파일이 넷으로 늘어납니다. 매퍼 XML, DAO, 서비스 인터페이스, 서비스 구현 클래스, 그리고 컨트롤러요. 글이 그 다섯 개를 전부 순서대로 올려뒀습니다.
DAO는 이렇게 짧아집니다.
@Repository
public class ExampleDAO extends EgovAbstractMapper {
public int insertExample(ExampleVO exampleVO) {
return insert("ExampleMapper.insertExample", exampleVO);
}
}
SqlSession이라는 단어가 사라졌습니다. EgovAbstractMapper가 MyBatis의 SqlSessionDaoSupport를 상속받아서 그 부분을 감춰버렸거든요. 글이 그 관계를 정확히 적어뒀습니다.
EgovAbstractMapper 추상 클래스 : MyBatis의 SqlSessionDaoSupport를 상속받아, MyBatis와 전자정부프레임워크의 서비스 계층이 자연스럽게 통합될 수 있도록 지원파일이 다섯 개로 늘어난 대가로 얻는 게 뭘까요. 글이 든 이유는 재사용성입니다.
여기서 핵심은 인터페이스입니다. 컨트롤러는 ExampleService라는 약속만 알고, 실제로 누가 어떻게 처리하는지는 모릅니다. 그래서 구현을 통째로 갈아끼워도 컨트롤러는 그대로예요. 테스트할 때 가짜 구현을 넣기도 쉽고요.
첫 번째 방식에는 이 틈이 없습니다. 컨트롤러가 매퍼를 직접 붙잡고 있으니, DB 접근 방식이 바뀌면 컨트롤러도 함께 바뀝니다.
⚖️ 표로 만들어 고른다
이 글에서 가장 실용적인 부분은 다섯 항목짜리 비교표입니다.
| 항목 | 직접 접근 방식 | 전자정부 템플릿 방식 |
|---|---|---|
SqlSession 사용 |
직접 호출 | EgovAbstractMapper를 통해 |
| 서비스 계층 | 생략 가능 | DAO 호출, 역할 분리 |
| 코드 재사용성 | 낮음 | 높음 |
| 비즈니스 로직 위치 | 컨트롤러 | 서비스 계층 |
| 복잡성 | 낮음 | 높음 |
마지막 줄이 재미있습니다. 복잡성이 "높음"인데, 그걸 단점 칸에 숨기지 않고 표에 그대로 적었어요.
비교표를 쓸 때 흔한 실수가 결론을 미리 정해놓고 표를 채우는 것입니다. 그러면 한쪽이 전 항목에서 이기는 표가 나오는데, 그런 표는 볼 필요가 없죠.
이 표는 그렇지 않습니다. 직접 접근 방식이 복잡성 항목에서는 유리하다고 적혀 있어요. 그래서 표를 읽고 나면 내 상황에 무엇이 중요한지를 스스로 물어보게 됩니다.
📝 원문에서는 이렇게 닫습니다
결론이 두 문장인데, 두 문장 다 조건절이 붙어 있습니다.
전자정부 템플릿 방식은 역할을 명확히 분리하여 코드 재사용성과 유지보수성을 높이지만, 상대적으로 구현이 길어질 수 있습니다. ⇒ 코드 표준화와 유지보수가 중요한 프로젝트에서 사용.
"~할 때 유용하지만", "~높이지만". 둘 다 장점 뒤에 바로 단점을 붙였습니다.
그리고 마지막에 화살표로 적용 조건을 적었어요. "코드 표준화와 유지보수가 중요한 프로젝트에서 사용."
이게 비교 글이 도달할 수 있는 가장 좋은 형태라고 생각합니다. "A가 낫다"가 아니라 "이런 조건이면 A"요. 다음에 비슷한 갈림길에 섰을 때, 결론이 아니라 조건을 꺼내 쓸 수 있으니까요.
큐레이터 노트
표준프레임워크를 다뤘다는 점에서 고른 글입니다.
전자정부 표준프레임워크는 국내 공공 SI 프로젝트에서 널리 쓰이는데, 정작 학습 자료로 정리된 글은 많지 않습니다. 실무에서 처음 만나면 왜 이렇게 파일이 많아야 하는지부터 막히거든요.
이 글은 그 지점을 정확히 붙잡았습니다. 파일이 다섯 개인 이유를 "원래 그렇게 쓴다"로 넘기지 않고, 한 파일짜리 버전과 나란히 놓고 무엇을 얻는지 보여줬어요.
그리고 SqlSession부터 설명하고 들어간 순서. 두 방식의 차이만 보면 겉모습만 남는데, 공통 부품을 먼저 이해하면 차이가 어디서 생기는지가 보입니다.
02
🖼️ 리액트에서 이미지 관리하는 방법 2가지
정원석 님
리액트에서 이미지를 두는 자리를
assets 폴더와 public 폴더 두 가지로 나눠 비교한 글입니다.각각 언제 유리한지를 밝히고,
assets 방식의 불편함을 줄이는 개선 코드까지 함께 올렸어요.판단 기준이 하나로 정리되어 있습니다. 이미지가 몇 개냐.
3회차와 5회차에서도 이분의 구현 기록을 소개해드렸습니다. 이번에는 구현이 아니라 구조 선택에 관한 글이에요.
조금 더 들어가 보면
📦 번들에 넣는가, 그냥 두는가
두 폴더의 차이를 글이 이렇게 갈랐습니다.
public폴더 — 이미지 관리 작업 시 새로고침을 할 때마다 이미지를 서버에서 다운을 받는다
핵심은 import를 하느냐 안 하느냐입니다.
assets에 두고 import img1 from "./assets/img1.jpg"로 불러오면, 이미지가 빌드 과정을 통과합니다. 번들러가 파일을 인식하고, 이름 뒤에 해시를 붙이고, 코드 안의 경로를 그 해시 이름으로 바꿔치기해요.
해시가 붙으면 좋은 점이 생깁니다. 파일 내용이 안 바뀌면 이름도 안 바뀌니까, 브라우저가 오래 캐시해도 안전하거든요. 반대로 이미지를 교체하면 이름이 달라지니 낡은 그림이 남아 있을 걱정이 없습니다.
public에 두면 그 과정을 전부 건너뜁니다. 파일이 있는 그대로 복사되고, 코드에는 /img/foo.png처럼 경로를 문자열로 적어요. 빌드가 관여하지 않으니 해시도 없고, 캐시 처리도 직접 정해야 합니다.
대신 얻는 게 있습니다. 파일이 몇 개든 빌드 시간이 늘지 않아요. 그리고 경로를 문자열로 조립할 수 있어서, 이미지 이름을 데이터에서 받아오는 경우에 편합니다.
🗂️ import 스무 줄을 한 파일로
assets 방식의 불편함을 글이 정확히 짚었습니다.
import img1 from "./assets.img.jpg"를 작성해줘야한다. 이와 같은 번거로움을 제거하기 위해 이미지를 관리하는 파일을 작성한다.그래서 util/get-img.js 하나를 만듭니다.
import img1 from "./../assets/img1.png";
import img2 from "./../assets/img2.png";
// ...
export function getImages(imgId) {
switch (imgId) {
case 1: return img1;
case 2: return img2;
// ...
default: return null;
}
}
import 문을 한 파일에 몰아넣고, 밖에서는 번호만 넘깁니다.
이 구조의 값어치는 경로가 한 군데에만 적힌다는 데 있습니다. 이미지 폴더를 옮기거나 파일명을 바꿔도 이 파일만 고치면 되죠. 컴포넌트 쪽 코드는 손댈 필요가 없습니다.
그리고 default: return null. 없는 번호가 들어와도 터지지 않게 막아뒀습니다. 5회차에서 소개해드린 이분의 코드에도 빈 값 처리가 들어 있었는데, 여기서도 같은 습관이 보입니다.
언제 어느 쪽인가
글이 든 기준은 하나입니다.
하지만 이미지가 많을 시 public폴더에 이미지를 관리하는 것이 효율적일 수도 있다.
"몇 개"와 "많을 시". 숫자로 딱 떨어지진 않지만, 판단 축이 하나로 정해져 있다는 게 중요합니다.
이유도 자연스럽게 이어집니다. assets 방식은 이미지 하나당 import 한 줄이 필요하니, 개수가 늘면 관리 파일이 끝없이 길어져요. switch 문이 수백 줄이 되면 그건 더 이상 정리가 아닙니다.
📝 원문에서는 이렇게 정리합니다
폴더 구조까지 함께 제안했습니다.
"역할에 따라"가 좋습니다. 확장자별도 아니고 크기별도 아니고, 쓰이는 자리별로 나누자는 거예요.
이미지를 많이 쓰는 프로젝트에서 실제로 겪는 문제가 이겁니다. 폴더 하나에 파일 수백 개가 쌓이면, 이 그림이 지금도 쓰이는지 아닌지를 알 수 없어요. 지우기가 무서워서 계속 남겨두게 되고요.
역할별로 나눠두면 그 화면을 지울 때 폴더째로 정리할 수 있습니다. assets를 골랐을 때는 번들러가 안 쓰는 이미지를 알아서 빼주지만, public은 그런 정리를 안 해주니까 구조로 대신하는 셈입니다.
큐레이터 노트
둘 중 하나를 고르라고 하지 않은 게 이 글의 미덕입니다.
이런 주제는 "무조건 assets" 같은 결론으로 끝나기 쉽습니다. 그런데 개수라는 조건을 걸어두니, 읽는 사람이 자기 프로젝트를 대입해볼 수 있어요.
그리고 assets 방식의 단점을 발견한 뒤 그냥 넘어가지 않고 개선안까지 만들어본 것. 불편함을 느꼈을 때 "이 방식은 별로네"로 끝내는 대신 "불편한 부분만 걷어낼 수 있나"를 해본 겁니다.
두 선택지를 공정하게 재려면 각각을 최선의 상태로 만들어놓고 비교해야 하는데, 이 글이 그걸 하고 있습니다.
03
🧱 [C++] 구조체와 클래스
강단 님
C++의 구조체와 클래스를 나란히 놓고 정리한 글입니다.
같은 "원"을 구조체로 한 번, 클래스로 한 번 만들어서 코드로 차이를 보여줘요.
그리고 C와 C++의 차이를 짚습니다. C에서는 구조체와 함수가 따로였는데, C++에서는 하나로 묶을 수 있다는 것요.
2회차에서 이분의 컴파일 과정 정리를 소개해드렸습니다. 이번에는 묶는 단위에 관한 글이에요.
조금 더 들어가 보면
🧩 데이터만 묶는가, 동작까지 묶는가
두 개념의 정의를 글이 이렇게 적었습니다.
클래스 — 대상의 데이터(속성)와 함께 그 대상이 할 수 있는 동작을 나타내는 함수(행위)들을 묶어서 선언한 것
"데이터 집합"과 "데이터 + 행위". 한 단어 차이인데 여기서 갈립니다.
그리고 C와 C++의 차이를 짚었어요.
C++에서는 구조체와 구조체를 사용해 처리하고자하는 함수들을 하나의 단위로 묶을 수 있음
C에서 원의 면적을 구하려면 이렇게 씁니다.
double circleArea(CircleType c) {
return c.radius * c.radius * PI;
}
함수가 구조체 바깥에 있습니다. 구조체는 데이터를 담는 상자일 뿐이고, 그 상자를 다루는 함수는 어디에 있어도 상관없어요.
문제는 상자와 함수가 떨어져 있다는 겁니다. CircleType을 만든 사람이 함께 만든 함수가 어디 있는지, 헤더 파일을 뒤져야 알 수 있죠. 그리고 아무나 radius에 음수를 넣을 수 있습니다.
🔒 public 앞에 적은 것들
클래스 예제에서 가장 눈여겨볼 부분은 주석 두 줄입니다.
class CircleClass {
C2dType center; // 중심좌표
double radius; // 반경
//public 이전에 선언된 것은 외부에서 사용할 수 없음
public: // public뒤에 선언된 멤버들은 외부에서 사용할 수 있다.
void init(double cx, double cy, double r) { ... }
double area() const { ... }
bool chkOverlap(const CircleClass& c) const { ... }
void display() { ... }
};
public: 위에 데이터가 있고, 아래에 함수가 있습니다.
C++ 클래스는 아무것도 안 적으면 기본이 private입니다. 그래서 center와 radius는 밖에서 손댈 수 없고, init()을 거쳐야만 값이 들어가요.
이게 구조체와의 실질적인 차이입니다. 구조체로 만들면 c1.radius = -5;가 그냥 됩니다. 클래스로 만들면 문 하나를 통과해야 하고, 그 문에서 검사를 할 수 있어요.
그리고 area()와 chkOverlap() 뒤에 붙은 const. 이 함수들이 객체의 값을 바꾸지 않는다는 약속입니다. 면적을 구하는 함수가 반경을 건드릴 이유는 없으니까요.
약속을 어기면 컴파일이 안 됩니다. 주석이 아니라 컴파일러가 지켜주는 규칙이라는 게 차이입니다.
📐 네 가지 동작을 먼저 적어놓고
코드보다 앞에 설계 메모가 있습니다.
✅ 원 클래스 * init : 원의 초기회 * area : 원의 면적 계산 * chkOverlap: 다른 원과 중첩 여부 검사 * display : 원의 정보 디스플레이 ------------------------- * center : 중심좌표 * radius : 반경
행위 넷을 위에, 속성 둘을 아래에 적고 선을 그어 나눴습니다.
순서가 눈에 띕니다. 보통은 데이터부터 정하고 함수를 붙이는데, 여기서는 무엇을 할 수 있어야 하는지를 먼저 적었어요.
이 순서가 왜 나은가 하면, 필요 없는 데이터를 안 만들게 되기 때문입니다. 네 가지 동작을 하는 데 중심좌표와 반경이면 충분하니, 그 둘만 두면 되죠. 데이터부터 정하면 "혹시 몰라서" 필드를 늘리기 쉽습니다.
그리고 이 메모가 그대로 public: 아래 목록이 됐습니다. 설계 메모가 인터페이스가 된 셈입니다.
큐레이터 노트
같은 대상을 두 방식으로 만들어본 것. 그게 이 글을 고른 이유입니다.
구조체와 클래스의 차이는 문장으로 설명하면 한 줄로 끝납니다. "클래스는 함수도 넣을 수 있다"요. 그런데 그 한 줄을 읽고 나면 그래서 뭐가 달라지는지가 안 남습니다.
이 글은 원이라는 같은 대상을 붙잡고 두 번 만들었어요. 그러니까 circleArea(c)가 c1.area()로 바뀌는 게 눈에 보입니다. 함수가 밖에 있다가 안으로 들어온 거죠.
그리고 //public 이전에 선언된 것은 외부에서 사용할 수 없음이라는 주석. 교재에 있는 문장을 옮긴 것일 수도 있지만, 코드 안 정확한 위치에 붙여둔 게 좋습니다. 나중에 다시 볼 때 문법 설명을 따로 찾을 필요가 없으니까요.
💡 세 편을 겹쳐 읽으며
세 글의 주제가 전혀 다릅니다. 자바 백엔드 구조, 리액트 자산 관리, C++ 문법이요.
그런데 글의 형태가 똑같습니다. 세 편 다 "A 방식"과 "B 방식"을 나란히 놓고, 예제를 각각 붙이고, 장단점을 적었어요.
무엇을 어디까지 묶을 것인가
세 글이 실은 같은 질문을 다루고 있습니다. 어디까지를 한 덩어리로 볼 것인가.
한지수 님의 두 방식은 컨트롤러가 어디까지 알아야 하는가를 묻습니다. DB 접근까지 알 것인가, 서비스라는 약속만 알 것인가.
강단 님의 구조체와 클래스는 자료형이 어디까지 품는가를 묻습니다. 데이터만 담을 것인가, 그 데이터를 다루는 함수까지 안에 둘 것인가.
정원석 님의 get-img.js도 같은 이야기입니다. 컴포넌트마다 import를 흩어둘 것인가, 한 파일에 모아 번호만 주고받을 것인가.
셋 다 "밖에서 알아야 할 것을 줄이는" 쪽이 두 번째 선택지입니다. 그리고 세 글 모두 그 대가로 파일이나 코드가 늘어난다고 적었어요.
비용을 언제 치를 것인가
두 번째 공통점은 비용의 시점입니다.
한지수 님 글의 비교표 마지막 줄이 "복잡성: 낮음 / 높음"이었죠. 전자정부 방식은 처음에 치릅니다. 파일 다섯 개를 만드는 수고를요. 대신 나중에 고칠 때 싸집니다.
정원석 님의 두 폴더도 같은 구조입니다. assets는 빌드 때 치릅니다. 번들러가 파일을 처리하는 시간이요. 대신 실행할 때 빨라집니다. public은 빌드 때 안 치르고 요청할 때 치르고요.
강단 님의 클래스도 그렇습니다. private으로 막고 init()을 만드는 건 처음에 드는 품입니다. 구조체는 그냥 값을 대입하면 끝이니 처음엔 빠르죠. 대신 잘못된 값이 들어갔을 때 어디서 들어갔는지 찾는 비용을 나중에 치릅니다.
공짜인 선택지는 없고, 언제 낼지를 고르는 것이라는 게 세 글에서 공통으로 읽힙니다.
그래서 기준을 적어두는 일
세 글이 모두 판단 기준을 문장으로 남겼다는 점도 같습니다.
"코드 표준화와 유지보수가 중요한 프로젝트에서 사용." "이미지가 몇 개만 필요할 때." "구조체를 사용해 처리하고자 하는 함수들을 하나의 단위로 묶을 수 있음."
기술 글에서 결론보다 오래 쓰이는 게 기준입니다. 결론은 상황이 바뀌면 못 쓰는데, 기준은 새 상황에도 대볼 수 있거든요.
이번 회차에서 가져갈 것
1. 비교표에 지는 항목도 적기.
한쪽이 전 항목에서 이기는 표는 읽을 필요가 없습니다. 직접 접근 방식이 "복잡성" 칸에서는 유리하다고 적혀 있어야, 읽는 사람이 자기 상황을 대입해볼 수 있습니다.
2. 결론이 아니라 조건을 남기기.
"A가 낫다" 대신 "이런 프로젝트면 A". 조건으로 적어두면 다음번 갈림길에서 그대로 꺼내 쓸 수 있습니다.
3. 두 선택지를 각각 최선의 상태로 만들고 비교하기.
assets 방식의 import 반복을 그대로 두고 재면 불공정합니다. 불편한 부분을 걷어낸 뒤에 비교해야 진짜 차이가 남습니다.
4. 데이터보다 행위를 먼저 적어보기.
"무엇을 할 수 있어야 하는가"를 먼저 나열하면 필요한 데이터가 따라 나옵니다. 반대 순서로 하면 혹시 몰라서 만드는 필드가 늘어요.
5. 공통 부품을 먼저 이해하고 차이를 보기.
두 방식의 차이만 외우면 겉모습만 남습니다. SqlSession이 무슨 일을 하는지 알고 나면, 왜 한쪽에서는 그 이름이 사라지는지가 보입니다.
2기 6회차는 2024년 11월 하순이었습니다. 학기 막바지로 향하며 각자 다루는 주제가 두꺼워지던 무렵이에요.
공공 프레임워크와 리액트 프로젝트와 C++ 교재라는 전혀 다른 자리에서, 세 분이 나란히 두 갈래를 놓고 재는 글을 썼습니다. 서로 약속한 것도 아닌데요.
좋은 글 남겨주신 한지수 님, 정원석 님, 강단 님께 감사드립니다. 그리고 2기를 함께 채워주신 모든 멤버분들께도요! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.