안녕하세요! 그로스로그 입니다!😊 🌱
save()를 두 번 불렀는데 INSERT는 한 번만 나가는 이유, 코딩을 배우기 전에 먼저 봐야 할 것, 그리고 개발자가 피그마를 여는 이유. 4기 1회차 세 편입니다.
4기 1회차는 2025년 9월, 기수가 막 시작하던 무렵입니다. 이번 회차에는 누군가 알아서 해주던 자리를 한 번 열어본 기록 세 편이 모였습니다. 프레임워크가 알아서 해주던 것, 학원이 알아서 가르쳐준다고 믿었던 것, 디자이너가 알아서 넘겨주던 것이요.
01
🗄️ [JPA] save()는 두 번인데, INSERT는 한 번만? - 영속성 컨텍스트
한대천 님
save()를 두 번 호출했는데 INSERT 쿼리는 한 번만 나가는 현상을 파고든 글입니다.원인은 JPA의 영속성 컨텍스트입니다. 첫 호출에서 엔티티가 등록되고, 두 번째는 이미 관리 중인 객체라 새 INSERT를 만들 필요가 없다는 것이죠.
flush() · clear()를 넣으면 INSERT가 두 번 나가는 것까지 로그로 확인합니다.글을 시작하는 문장이 이 기록의 성격을 정합니다.
패턴으로 쓰던 것을 원리로 바꿔놓는 작업입니다. 돌아가는 코드를 이미 갖고 있는 사람이 그 코드가 왜 도는지를 나중에 확인하는 순서예요.
조금 더 들어가 보면
착오가 생기는 자리를 두 가지로 나눠 보여줍니다.
하나는 같은 메서드 안에서 save()를 연달아 부르는 경우입니다. 다른 하나는 저장한 엔티티를 다른 서비스 계층에 넘겼는데 그쪽에도 save()가 들어 있는 경우고요. 저자는 후자가 더 흔하다고 적었습니다.
실무에서 헷갈리는 쪽이 정확히 그쪽입니다. 내가 쓴 코드에는 save()가 하나뿐인데 로그를 보면 뭔가 이상한 상황이요.
⚙️ 왜 한 번만 나가는가
원문이 짚는 동작은 이렇습니다.
· 새로운 엔티티 → EntityManager.persist() 호출
· 이미 관리 중인 엔티티 → EntityManager.merge() 호출
첫 번째 save()에서 엔티티가 영속성 컨텍스트에 등록되고, 두 번째 호출 시점에는 이미 관리되는 객체라 새 INSERT를 만들 이유가 없습니다.
그리고 영속성 컨텍스트를 이렇게 정리합니다 — "엔티티를 영구 저장하는 환경 + 상태 변화를 추적하는 1차 캐시". 여기서 따라오는 성질 세 가지를 함께 적었어요.
· 같은 엔티티를 여러 번 조회해도 동일 객체가 돌아온다
· 트랜잭션 커밋 시점이나 flush() 시점에 DB로 SQL이 나간다
· 변경된 값만 감지해 자동으로 UPDATE 한다 (더티 체킹)
📝 원문에서는 이렇게 확인합니다
설명에서 멈추지 않고 반대 경우를 만들어 봅니다.
save() 사이에 em.flush()와 em.clear()를 넣었어요. flush로 DB에 반영하고, clear로 영속성 컨텍스트를 비웁니다. 그러면 두 번째 save()는 새 엔티티를 만난 것처럼 처리됩니다.
로그에 INSERT가 두 번 찍힙니다.
설명이 맞다면 이 조건에서는 결과가 달라져야 한다 — 그걸 실제로 돌려서 확인한 겁니다. 짧은 글인데 검증 절차가 들어 있습니다.
마지막에는 이 내용으로 답할 수 있게 된 질문 세 개를 남겨뒀습니다. 영속성 컨텍스트의 역할, 엔티티 동일성 보장 방식, flush/clear의 영향이요.
큐레이터 노트
"이상하다"에서 멈추지 않고 원인까지 내려간 기록이라 뽑았습니다.
save() 두 번에 INSERT 한 번은 에러가 아닙니다. 그냥 지나가도 아무 일도 안 생겨요. 그래서 대부분 그냥 넘어갑니다. 이 글은 그 지점을 붙잡고 프레임워크가 대신 해주던 판단을 열어봤습니다.
정상 동작이라는 결론에 도달한 것도 값어치가 있습니다. 버그를 찾아 고친 이야기가 아니라, 왜 이게 정상인지를 설명할 수 있게 된 이야기예요. 이런 확인이 쌓이면 나중에 진짜 문제가 생겼을 때 어디를 볼지 알게 됩니다.
02
🧭 [CS 공부 #1] 코딩 학원 등록 전에, 진짜 알아야 할 것
홍범영 님
10편짜리 CS 시리즈의 1편입니다. 코딩 기술이 아니라 문제 해결을 위한 사고방식을 다루겠다고 선언하는 글이에요.
문제를 '찾는 힘'과 '푸는 힘'으로 나누고, 컴퓨터과학을 "세상에 늘 존재했던 문제들을 디지털 세상으로 가져와 더 똑똑하게 해결하는 학문"으로 정의합니다.
마지막에 앞으로 다룰 9개 주제를 순서까지 적어 공개했습니다.
서비스 기획 일을 하면서 CS를 공부하게 된 사람의 시작점입니다.
조금 더 들어가 보면
출발점이 자기 인식입니다.
그리고 생각이 바뀐 자리를 씁니다 — 서비스를 바꾸는 것이 "화려한 코딩 기술"이 아니라 "문제를 체계적으로 분석하고, 가장 효율적인 해결책을 설계하는 사고의 힘"이었다고요.
🔍 문제를 '찾는 힘'
추상적으로 말하지 않고 일상 상황 두 개로 보여줍니다.
· 일의 순서 문제 — 마감과 중요도가 제각각인 10개 업무가 쌓였을 때. → "어떤 순서로 처리해야 가장 효율적일까?"
· 정보의 구조 문제 — 문서 폴더에 수백 개 파일이 뒤죽박죽일 때. → "어떻게 정리해야, 필요할 때 10분씩 헤매지 않고 원하는 파일을 바로 찾아낼 수 있을까?"
그리고 이 둘에 컴퓨터과학이 각각 알고리즘과 자료구조·데이터베이스로 답한다고 연결합니다.
교과 이름을 먼저 꺼내고 설명하는 대신, 문제를 먼저 보여주고 거기에 이름을 붙이는 순서입니다.
🧮 문제를 '푸는 힘'
'푸는 힘'이 뭔지도 구체적으로 나눕니다. 업무 순서 문제를 예로 들어 세 단계로 적었어요.
· (정의) 업무 시간과 이동 거리를 측정 가능한 숫자로 바꾼다
· (분석) 가능한 경로를 따져보고 최적을 찾는 규칙을 설계한다
· (절차) 그 규칙을 컴퓨터가 수행할 수 있는 명확한 단계로 만든다
그러면서 대부분은 "감에 의존해 순서를 정합니다"라고 대비시킵니다. 감과 절차의 차이를 이 세 단계로 보여준 거예요.
📝 원문에서는 이렇게 정의합니다
컴퓨터과학을 무엇이라고 보는지 직접 씁니다.
근거로 든 대응이 셋입니다.
· 옛날 상인들의 장부 → 오늘날의 데이터베이스
· 도서관 사서의 책 정리 노하우 → 자료구조
· 최고의 맛을 내는 요리 레시피 → 알고리즘
"컴퓨터과학은 없던 것을 창조한 게 아닙니다" — 인류가 쌓아온 문제 해결 방법을 집대성해 컴퓨터로 풀어내는 학문이라는 정리입니다.
이어서 왜 개발자가 아니어도 배울 만한가에 답합니다. 시스템적 사고(일머리), 협업을 위한 공통 언어, 세상의 동작 원리를 보는 관점 — 세 가지를 들었어요.
그리고 시리즈 계획을 순서까지 공개합니다. 네트워크 → 운영체제 → 알고리즘 → 자료구조 → 데이터베이스 → 컴퓨터 구조 → 프로그래밍 언어 → 정보 표현 → 총정리.
순서를 정한 이유도 밝힙니다.
가장 친숙한 네트워크에서 출발해 아래로 내려가겠다는 겁니다. 교과서 순서를 그대로 따르지 않고 자기 기준으로 다시 배열한 것이죠.
큐레이터 노트
1회차에 10편 전체 계획을 공개한 글이라 뽑았습니다.
성장일지는 대개 그때그때 쓴 것이 쌓여 연재가 됩니다. 이 글은 반대예요. 먼저 지도를 그리고 시작합니다. 그러면 다음 회차마다 "무엇을 쓸까"를 고민하지 않아도 되고, 읽는 쪽도 어디까지 왔는지 알 수 있습니다.
독자를 정해놓고 쓴 것도 눈에 띕니다. 제목이 「코딩 학원 등록 전에」예요. 코딩을 배우려는 사람이 학원 등록 직전에 읽을 글로 상정한 겁니다. 대상이 정해지니 예시가 업무 목록과 문서 폴더처럼 비전공자가 바로 아는 것으로 골라집니다.
같은 기수에 비전공 출신 회원이 여럿입니다. 그분들에게는 먼저 지나간 사람의 정리로, CS 전공자에게는 아는 내용을 어떻게 설명할지에 대한 참고로 읽힙니다.
03
🎨 개발자도 피그마(Figma)를 배우면 좋은 이유와 기초 가이드
주시원 님
개발자가 피그마를 배우면 좋은 이유 다섯 가지와, 익혀두면 좋은 기능을 정리한 글입니다.
핵심은 Inspect 패널입니다. CSS 속성·폰트·색상 코드가 자동으로 표시돼서, 디자이너에게 묻지 않고 바로 코드로 옮길 수 있다는 것이죠.
배울 범위도 정해줍니다 — "디자이너처럼 깊게 배울 필요는 없습니다." 꼭 알아야 할 것 3가지, 있으면 좋은 것 3가지로 나눴어요.
"굳이 디자인 툴까지 배워야 할까?" 라는 질문에서 시작합니다.
조금 더 들어가 보면
이유 다섯 개가 협업 → 개인 작업 순으로 배열돼 있습니다.
1) 디자이너와의 협업. 예전에는 시안을 PNG·PSD로 받아 작업했고, 그러다 보니 "이 여백 몇 픽셀이에요?" 같은 질문이 끊임없이 오갔다고 합니다. 피그마에서는 개발자가 직접 열어 레이아웃·폰트·색상 코드를 확인합니다.
2) 디자인 명세 확인. Inspect 패널이 CSS 속성과 색상 코드를 자동으로 보여줍니다. "바로 코드로 옮길 수 있는 자료"를 스스로 얻는 것이죠.
3) 프로토타입 이해. 디자인이 "단순히 '화면 그림'이 아니라 사용자 흐름(UX)까지 포함"한다는 관점입니다. 화면 전환과 버튼 동작을 개발 전에 체험해 본다는 것이고요.
4) 작은 수정은 직접. 텍스트 변경이나 버튼 위치 조정 정도는 디자이너에게 요청하지 않고 처리합니다.
5) 개인 프로젝트·스타트업. 작은 팀에서는 개발자가 기획과 디자인까지 맡는 경우가 있습니다. 이때 와이어프레임 → 프로토타입 공유 → 피드백 반영 사이클을 혼자 돌릴 수 있다고 적었어요.
📝 원문에서는 범위를 정해줍니다
이 글에서 가장 실용적인 대목이 여기입니다.
그러고는 두 단으로 나눕니다.
✅ 꼭 알아야 할 기초
· 프로젝트 열기 & 파일 구조 이해 — 페이지별로 어떤 화면이 있는지 파악
· Inspect 기능 활용 — CSS 속성·폰트·색상 코드 확인하고 복사
· 코멘트 확인 & 작성 — 디자이너 설명을 읽고 필요하면 질문 남기기
🔥 있으면 좋은 기능
· 와이어프레임 제작 — 네모 박스와 텍스트 정도로 화면 구상
· 컴포넌트 이해 & 재사용
· 프로토타입 미리보기
어디까지만 하면 되는지를 알려주는 것이 새 도구를 소개할 때 가장 필요한 정보입니다. 그게 없으면 끝이 안 보여서 시작을 미루게 되니까요.
결론도 선을 지킵니다 — "개발자가 피그마를 배운다고 해서 디자이너가 되는 건 아닙니다."
큐레이터 노트
범위를 좁혀준 안내문이라 뽑았습니다.
도구 소개 글은 대개 기능을 늘어놓습니다. 읽고 나면 배울 게 많아 보여서 오히려 시작을 미루게 돼요. 이 글은 "꼭"과 "있으면 좋은"으로 나눠 진입 지점을 세 개로 줄였습니다.
Inspect 하나로 좁힌 것이 특히 그렇습니다. 개발자가 피그마에서 실제로 가장 자주 쓰는 기능이고, 그것만 알아도 "이 여백 몇 픽셀이에요?"를 안 물어보게 됩니다. 가장 먼저 없어지는 불편을 먼저 놓은 순서예요.
기수 안에 개인 프로젝트를 진행하는 회원이 많습니다. 디자이너 없이 혼자 화면을 잡아야 하는 상황에서 바로 참고할 수 있는 기록입니다.
💡 세 편을 겹쳐 읽으며
세 편 다 누군가 알아서 해주던 자리를 한 번 열어본 기록입니다.
한대천 님은 프레임워크가 대신 하던 판단을 열었습니다. save()를 두 번 불러도 INSERT가 한 번인 건 JPA가 알아서 처리해준 결과예요. 그냥 써도 되는데 안을 들여다봤습니다.
홍범영 님은 학원이 알아서 가르쳐준다고 믿었던 자리를 열었습니다. 코딩을 배우기 전에 코딩으로 무엇을 할 것인지가 먼저라는 이야기죠.
주시원 님은 디자이너가 알아서 넘겨주던 자리를 열었습니다. 시안을 받아서 물어보는 대신 직접 열어 확인하는 쪽으로요.
열어보는 깊이가 저마다 다른 것도 눈에 띕니다. 한대천 님은 flush/clear까지 내려가 로그로 확인했고, 주시원 님은 "디자이너처럼 깊게 배울 필요는 없습니다"라며 선을 그었어요. 홍범영 님은 아예 10편 분량으로 계획을 잡았고요.
어디까지 열어볼지를 각자 정했다는 게 세 편의 공통점입니다. 전부 다 알 필요는 없지만, 어디까지는 알아야 하는지는 스스로 정해야 하니까요.
이번 회차에서 가져갈 것
1. 정상 동작도 설명할 수 있어야 안다.
save() 두 번에 INSERT 한 번은 에러가 아니라 그냥 지나가도 됩니다. 왜 정상인지 말할 수 있게 되면 나중에 진짜 문제가 생겼을 때 어디를 볼지 알게 됩니다.
2. 설명이 맞는지 반대 조건으로 확인하기.
flush/clear를 넣으면 INSERT가 두 번 나가야 합니다. 예상이 맞는 조건을 만들어 돌려보는 것이 이해했다는 증거예요.
3. 도구를 배우기 전에 무엇을 풀지 정하기.
문제를 찾는 힘과 푸는 힘은 다릅니다. 코딩은 푸는 도구고, 찾는 쪽은 따로 연습해야 합니다.
4. 연재는 지도를 먼저 그리면 이어진다.
1회차에 10편 주제를 순서까지 적어두면, 다음 회차마다 소재를 고민하지 않아도 됩니다. 읽는 쪽도 어디까지 왔는지 압니다.
5. 교과서 순서를 그대로 따르지 않아도 된다.
작은 단위부터 쌓아 올리는 대신 친숙한 것에서 출발해 내려가는 배열도 있습니다. 자기 기준으로 다시 놓아보면 남에게 설명하기도 쉬워집니다.
6. 새 도구는 "어디까지만"을 정하고 시작하기.
꼭 알아야 할 것 셋, 있으면 좋은 것 셋. 끝이 보이면 시작하게 됩니다. 피그마라면 Inspect 하나로 충분한 것처럼요.
좋은 글 남겨주신 한대천 님, 홍범영 님, 주시원 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.